AME Software - Revision history

Ctreber: /* AC_ESP8266 */

2018-06-24T20:16:19Z

AC_ESP8266

← Older revision		Revision as of 20:16, 24 June 2018
Line 18:		Line 18:

	Regarding command assembly and response parsing I think even that could be migrated to streaming mode, though pattern matching would be not that easy, I guess.		Regarding command assembly and response parsing I think even that could be migrated to streaming mode, though pattern matching would be not that easy, I guess.

			[[ESP8266 AT Command Reference]]

			===Pattern expansion===

			Commands with parameters can be assembled using a pattern string and a "multi" (more on that later) argument string. The pattern string contains '$' (Dollar) signs with are filled with sections of the argument string. The "multi" string simply is a sequence of string terminated by 0.

			In example, pattern string "$, $!" and argument string "Hello\0World\0" get expanded into "Hello, World!".

			===Pattern matching

			Responses with arguments can be parsed using a pattern string, producing a "multi" result string.

			In example, using pattern string "time: $,count: $" to parse response "time: 47, count: 11" yield result string "47\011\0".

			The code for parsing is "a bit" tricky (it took me a day to write it and half a day to really understand it a year later). This is why I explain it here, for myself and other.

			Here is a description of the algorithm. A pattern consists of wildcards and blocks of text that must match. Wildcards and text blocks must alternate.

			Example: Pattern "$ BLOCK_B $ BLOCK_D $" consists of three wildcards and two blocks of text that must match. Another way of seeing this is "wildcards separate fixed blocks of text". What you get is " BLOCK_B " and " BLOCK_D ".

			The next task: Locate the fixed text blocks in the text to parse. All text blocks must be found; otherwise, there is no overall match.

			Example: Text "BLOCK_A BLOCK_B BLOCK_C BLOCK_D BLOCK_E". BLOCK_B and BLOCK_D are contained in the text. Another way of seeing this is "fixed blocks of text separate 'free text'". What you get is "BLOCK_A", "BLOCK_C", and "BLOCK_D".

			Next step: Return matching free text as result.

			While this is not too tricky, the code is because it does it all in one go and not in three separate steps. But knowing how it is done is helpful in understanding the code.

	===Looping===		===Looping===

Ctreber: /* AME Stack (Software) */

2018-06-23T11:20:33Z

AME Stack (Software)

@@ Line 4: / Line 4: @@
 [[File:The_AME_Stack_(Software).png|left|thumb|1200px|Class structure (operations incomplete)]]<br clear="all"/>
 ==AC_ESP8266==
@@ Line 11: / Line 17: @@
 The buffer used for command assembly and response parsing is the only one in the whole class. Writing and reading IP data is performed streaming. Callbacks announce the arrival of data and loss of connection.
 Regarding command assembly and response parsing I think even that could be migrated to streaming mode, though pattern matching would be not that easy, I guess.
 ==AC_TCP_ESP8266==
@@ Line 20: / Line 38: @@
 If you want to, it even can turn the ESP off and on again. I think that does exhaust all options available.
 ==AC_MTTQ==
@@ Line 26: / Line 56: @@
 Unlike other libaries AC_MQTT does not get unhappy if a ping response gets lost while performing publish and subscribe operations.
 ==AC_IoT/ Devices==
@@ Line 44: / Line 88: @@
 would be sent.
 ==Capabilities==
@@ Line 65: / Line 121: @@
 would be sent, indicating the production of two output attributes with the names "pressure" and "temperature" with numeric output format.
 ==Arduino==

Ctreber at 10:15, 23 June 2018

2018-06-23T10:15:47Z

@@ Line 65: / Line 65: @@
 would be sent, indicating the production of two output attributes with the names "pressure" and "temperature" with numeric output format.
 [[The AME Stack]]
 __NOTOC__

Ctreber at 22:29, 19 June 2018

2018-06-19T22:29:50Z

← Older revision		Revision as of 22:29, 19 June 2018
Line 1:		Line 1:
	[[The AME Stack]]		[[The AME Stack]]

	=AME Software=		=AME Stack (Software)=

			[[File:The_AME_Stack_(Software).png\|left\|thumb\|1200px\|Class structure (operations incomplete)]]<br clear="all"/>

	==AC_ESP8266==		==AC_ESP8266==

Ctreber: Created page with "The AME Stack =AME Software= ==AC_ESP8266== AC_ESP8266 provides access to the ESP8266 on C++ level, no more, no less. It uses two (blowing my own horn) clever functions..."

2018-06-19T09:33:56Z

Created page with "The AME Stack =AME Software= ==AC_ESP8266== AC_ESP8266 provides access to the ESP8266 on C++ level, no more, no less. It uses two (blowing my own horn) clever functions..."

New page

[[The AME Stack]]

=AME Software=

==AC_ESP8266==

AC_ESP8266 provides access to the ESP8266 on C++ level, no more, no less. It uses two (blowing my own horn) clever functions to compose commands and to parse responses based on pattern expansion/ matching.

The buffer used for command assembly and response parsing is the only one in the whole class. Writing and reading IP data is performed streaming. Callbacks announce the arrival of data and loss of connection.

Regarding command assembly and response parsing I think even that could be migrated to streaming mode, though pattern matching would be not that easy, I guess.

==AC_TCP_ESP8266==

AC_TCP_ESP8266 provides streaming TCP functionality based on - you guessed it - the ESP8266. It deals with loss of TCP and WLAN connectivity.

It does what is required to get the ESP working again, which, frankly sometimes is not easy and a pain in the back. This includes resetting the chip via software and - optionally - hardware (it uses the reset pin of the ESP).

If you want to, it even can turn the ESP off and on again. I think that does exhaust all options available.

==AC_MTTQ==

AC_MTTQ provides standard MQTT functions with QoS 0 or 1. More honestly QoS "0.5" as it properly produces ACK messages to the broker, but arriving ACKs are discarded and missing ACKs don't prompt retries).

Unlike other libaries AC_MQTT does not get unhappy if a ping response gets lost while performing publish and subscribe operations.

==AC_IoT/ Devices==

Devices are derived from AC_IoT. AC_IoT provides convenience on device level with concepts such as centrally configured device name and MQTT-ID that get used wherever appropriate.

In example, a device with MQTT-ID "garden01" uses "garden01" as a prefix for topics in publications and subscriptions of its capabilities.

When the MQTT connection is established AC_IoT reports the version of the IoT framework, the device version, the IP and MAC addresses, and the number of connect attempts.

In example, the messages

* "garden01/versionIoT 1.038"
* "garden01/version 1.010"
* "garden01/connectAttempts 12"
* "garden01/ip 192.168.2.76"
* "garden01/mac 5d:de:ad:be:ef"

would be sent.

==Capabilities==

Capabilities can easily be added to a device. For a gardening system you maybe add capabilities "temperature", "spoil moisture", "rain", and "relay" (ie, to turn an irrigation system on and off).

A capability encapsulates hardware intricacies, possess a built-in name, and provides configuration options such as a capability ID (a number), update intervals, I/O pins and so on.

In example, a capability encapsulating a BMP280 air pressure and temperature sensor with the built-in name "pressure" has been assigned capability ID "1". The capability will produce publications at a configurable interval using the name of the device, the name of the capability, the capability ID, and the attribute name.

Building on the example above, publications would use the topics

* "garden01/pressure01/pressure" and
* "garden01/pressure01/temperature"

Additionally, Capabilities report their version and input and output parameters when the MQTT connection is established. In example, the messages

* "garden01/pressure01/version 1.001"
* "garden01/pressure01/capa01 <pressure:<d>" and
* "garden01/pressure01/capa02 <temperature:<d>"

would be sent, indicating the production of two output attributes with the names "pressure" and "temperature" with numeric output format.

[[The AME Stack]]
__NOTOC__