IoT with AME - User contributions [en]

AME Status and Logging

2020-12-28T15:06:17Z

Ctreber:

[[The AME Stack]]

=AME Status Information and Logging=

Since a whole bunch of components are working together things can get tough when there is a problem. The AME stack provides logging via I2C and status information via a RGB-LED.

==Logging with "Logsury"==

Logging can be switched off in production

* at build time
* at run time via switching an I/O pin on or off on Arduino reset

If logging is switched off at build time, the logging code completely disappears from the program (accomplished with C++ macros). Logging library and statements do not consume any space or processing time.

==Event Visualization with the "Event Facility"==

The AME Stack issues events that may be of interest to a user:

* Regarding the WLAN connection:
** Note to self: Description to be done (no connection/ trying/ connected)
* Regarding the TCP connection:
** Note to self: Description to be done (no connection/ trying/ connected)
* When the MQTT connection is in place
** The LED twitches every second, indicating the Arduino is running and not stuck in an endless loop
** Every time a message is sent, it flashes in blue, indicating the attempt is being made
** Every time a message is received, it flashes in ???, indicating a message has been received (the broker did sent it our way)
** Every time a ping response is received, it changes color (either green or magenta), indicating pings are being sent ''and'' received (the broker replied)

These events get handled by an Event Facility that comes in three versions:

* "Do Nothing" (it does what you think)
* Use a programmable RGB LED (using colors and flashing)
* Use an LCD screen (symbols in the top right corner)

The programmable status LED consumes only one Arduino pin while it is able to provide quite a bit of useful information. The library to "talk to it" is very small.

[[The AME Stack]]

The AME Stack

2020-12-28T14:52:51Z

Ctreber:

[[IoT with AME|Home]]

=The AME Stack=

AME =

* Arduino (for brains)
* MQTT (for communicating with devices)
* ESP8266 (for TCP over WLAN)

Contens

* [[AME_Goals|Design Goals]]
* [[AME_Software|Software]]
* [[AME_Hardware|Hardware]]
* [[AME_Status_and_Logging|Status Information and Logging]]

[[IoT with AME|Home]]
__NOTOC__

My IoT projects

2019-02-04T16:24:55Z

Ctreber: /* My IoT Projects - What I Built Over Time */

[[IoT with AME|Home]]

=My IoT Projects - What I Built Over Time=

<table>
<tr>
<td>[[File:20170521T124850.jpg|left|thumb|200px|AC.clock]]</td>
<td>[[File:20170128T201427_scaled.jpg|left|thumb|300px|AC.ticker]]</td>
<td>[[File:20180611T222225_corrected.JPG|left|thumb|200px|AC.home]]</td>
<td>[[File:20170802T120601.jpg|left|thumb|300px|AC.gadget-7Segment]]</td>
<td>[[File:20170128T214017_scaled.jpg|left|thumb|300px|AC.programmer]]</td>
</tr>
</table>

 

* [[AC.balcony]] - Measures temperature, humidity, soil moisture, brightnessy and atmospheric pressure. Controls balcony plants watering system supplied from container.
* [[AC.camper]] - Measures temperature and humidity in the camper van parked outside in the yard. Sends alarms from two motion sensors. Will be upgraded to relaying information from the solar charger obtained via ModBus. Connected to the Internet via mobile internet WLAN router.
* [[AC.clock]] - RGB LED ring showing time as lit pixels, adapted to ambient brightness. Gets time updates via MQTT.
* [[AC.gadget-7Segment]] - Counting up with 7 segment displays (6 digits) salvaged from a long lost calculator. IO multiplexing with shift registers.
* [[AC.gadget-15Segment]] - Showing a scrolling text on 15 segment displays (5 digits) I got from a friend IN THE 80s (gasp!). IO multiplexing with three 8 bit shift registers.
* [[AC.gardenControl]] - Measures inside temperature, inside humidity, outside temperature, outside humidity, and soil moisture at our garden plot about 2km from home. Controls watering system supplied from ground water pump. Connected via mobile internet WLAN router.
* [[AC.gardenPower]] - Controls outside and inside lighting of the hut on our garden plot. Uses motion sensors to control outside lighting and send alarms.
* [[AC.home]] - A wall-mounted "terminal" with touch screen LCD to show outside temperature etc.
* AC.home2 - A 4 x 20 character LCD display in a box (desktop, shelf) displaying sets of data such as temperature, humidity for balcony, garden, camper van.
* [[AC.power]] - Switches up to 8 power outlets on and off. I am using a number of these throughout to house to, in example, control lighting.
* [[AC.programmer]] - An Arduino ISP/ logger with a LCD Screen
* AC.rgui - A "remote GUI" (LCD) that can receive pixel data in rectangular portions, in example to serve as WLAN-fed picture frames
* [[AC.signal]] - Controls a full size train signal replica (showing symbols "off", "full ahead", "slow ahead", "stop")
* [[AC.ticker]] - A LED ticker tape. Text and speed can be controlled remotely.

Plans:

* AC.balcony 2.0 - Wind sensor (direction, strength) and a rain gauge
* AC.kitchen - Report on stove plate and fridge temperature
* AC.power - Add temperature reporting to control the temperature in the camper van and garden plot hut, using an electric heater
* AC.train - Controls my G-gauge garden train. Instead of supplying power and DCC control through the rails (which I found to be very flaky due to oxidation of the rails outside), the trains get powered by rechargeable batteries and controlled through MQTT via WLAN. An older prototype based on a 433GHz radio connection and a proprietary protocol is already working.

AC.programmer

2018-07-07T22:39:30Z

Ctreber:

[[Tools]], [[My_IoT_projects|My IoT Projects]]

=AC.programmer=

AC.programmer is an [https://www.arduino.cc/en/Tutorial/ArduinoISP Arduino as an ISP] (In System Programmer) with some added bells and whistles.

[[file:20170128T214017 scaled.jpg|left|thumb|800px|Version 1 - Just a plain ISP programmer]]

 

==ISP Programming==

* does not use the serial interface of the Arduino and
* does not require a pre-installed boat loader

Instead, the programmer uses the SPI interface to communicate which the target that has been switched into serial programming mode on reset. The work normally performed by the boot loader is offloaded to the programmer.

Why would you do that, adding an ISP programmer to your setup?

# It frees up the serial interface for communications with the ESP8266 WLAN chip. This was the main reason for me to use an ISP. SoftwareSerial is slow, and even at slow speeds it means asking for trouble (lost characters, in example). Seriously, SoftwareSerial is unusable for this purpose.
# It frees up the 2kB of flash memory that the boot loader occupies, all yours to use. This is the only way to get to access to the full 32kB of flash memory the smaller Arduinos have to offer. Here (todo: provide link) is an entry for boards.txt of the Arduino IDE that reflects the gain in memory.

There is one disadvantage, though: Without having the serial interface connected to your computer, you loose that option for logging. I developed a logging facility called "Logsury" that, amongst other channels, supports logging via I2C. That does NOT block the I2C interface as many addressable devices may be connected. AC.programmer forwards log information received via I2C to its own serial interface (connected to the computer), and/ or displays it on its large LCD display, or logs it to a file store on a SD Card (or any combination thereof).

==Building AC.programmer==

LCDs for Arduino often use up pretty much all port pins. Plugging the display directly into an Arduino Uno is convenient but makes all the decisions for you (like, using up the SPI connections to communicate with the SD card often found on the display).

Plus, not all connections are needed. If you have only one LCD, "chip select" can simply be tied to 5V. If you don't need to read from display RAM, you don't need the "read mode" pin. What you really need is pins for "command/data", "write mode", and "reset".

And, of course, 8 data pins - unless you use a shift register. This is quite a bit slower (by a factor of about 4), but it saves you 6 port pins as you only need "data" and "clock" to operate the shift register. By clever placement of parts this even saves quite a bit of wiring as well. That's what I did!

==Requirements==

What should the programmer offer?

* Program Arduinos (duh) - DONE
* Speed. It is possible to crank up the speed between computer and programmer to 115200baud and between programmer and target to whatever the target can handle. - DONE
* Information on the programming process. "Arduino as ISP" uses 3 LEDs to provide status information. We have a whole LCD display. If something goes wrong, I can say exactly what. During programming, I can display what is written where (pages of flash and EEPROM memory). - DONE
* A way to load data into EEPROM memory, if my application needs it. Preconfigured WLAN settings for multiple SSIDs come to mind...
* Run on battery power. When I'm "in the field", I want to be able to update devices without connection to the grid. - DONE (can be powered via USB or externally using a built-in voltage controller)
* Power the target. I have fried a number of Arduinos by connecting them and the programmer to different power sources in ways that were clearly less than optimal ("no common ground" is what you want to avoid). - DONE
* Upload programs from SD card. Again, when I'm "in the field", I don't want to lug around a whole laptop just to program devices the memory of which could not even hold one of the colorful desktop icons.
* Some fun, like information on what exactly the Arduino IDE is sending to and receiving from the programmer. - DONE (though this slows down programming to a crawl)

Sketching a plan:

* Display log messages on the LCD - DONE
* Log IDE/programmer and programmer/target interaction - DONE
* First, get the whole thing to work (program a target) - DONE
* Visually display the programming progress. In example, display bars or rectangles that represent the flash and EEPROM pages and show what is being read and being written. Ditto the fuses. - DONE
* On request, show the signature of the target, fuse bit values - DONE
* Change parameters via the touch screen (like, the SPI speed)

[[file:20170802T120644 scaled.jpg|left|thumb|800px|Version 2 - With LCD and I2C log facility]]

 

==Future Ideas==

These are items that once on my to do list; not sure if I will follow up on them:

* Write complete STK/SPI log to SD card (CTP-1045). Why would I do that? That out of curiosity how the Arduino IDE interacts with the programmer.
* Program to SD (the IDE thinks it's programming an Arduino but the programmer just record what is being done, for later replay; CTP-1047)
* Program from SD card (the replay mentioned above; CTP-1049)
* Record Logsury output on SD card (CTP-1050)
* Program EEPROM (in example, to configure WLAN settings; CTP-1051)
* Save EEPROM contents to SD card (CTP-1052)
* Save Flash to SD card (in example, for duplicating a configured Arduino; CTP-1053)
* Reset target via touch screen (in example, if the reset button can't be accessed easily; CTP-1067)

[[Tools]], [[My_IoT_projects|My IoT Projects]]

AME Hardware

2018-06-26T12:05:30Z

Ctreber: /* Arduino */

[[The AME Stack]]

=AME Stack (Hardware)=

[[File:20170802T115833.jpg|left|thumb|600px|Voltage controller (left), Arduino (top right), and ESP8266 (bottom right)]] 

==Arduino==

The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory for data (EPROM, non-volatile, runtime-programmable), counters, timers, I/O pins, and various interfaces (shared with the I/O pins; interrupts, serial, I2C, SPI). Different models offer different amounts of assets.

Cheap versions can be ordered from Chinese suppliers for 2.50€ a piece. I'm using them all the time, and they just work fine (didn't have a single dud in 20+ Arduinos).

The pins:

* ACC: +5V (if you use the 5V variety of the Arduino, otherwise 3.3V)
* RAW: This feeds the internal voltage regulator. You may apply a higher voltage then on the ACC pin, supposedly up to 12V, but I would not overdo it. In this case, +5V may be obtained on the ACC pin, but the small regulator can't supply much.
* GND: Connect to GND of the ESP8266
* RST: Reset
* TXD: Transmit data (another name for I/O pin 0). Connect to RX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* RXD: Receive data (another name for I/O pin 1). Connect to TX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* 2-13: Digital I/O Pins. Pin 13 is connected to the internal LED (which does not hurt if you want to use the pin for your own purposes).
* A0-A7: Analog I/O Pins (can be used for digital I/O as well)

Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):

* Serial interface: I/O pins 0, 1 become Transmit Data (TXD), Receive Data (RDX)
* External interrupts: I/O pins 2, 3
* Serial Peripheral Interface (SPI): I/O pins 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus with transfer in both directions at the same time. Slaves must be selected using a digital I/O pin, but there is no protocol overhead. Very efficient, but uses a few pins plus one pin for each device.
* Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): I/O pins A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol. More talkative, but uses only two pins for any amount of devices.

Standard-use of pins:

* 7: Logsury on/off (optional if you don't want to use the runtime-configuration option of Logsury)
* 8: ESP8266 reset (optional if you don't want to make use of the reset option of AC_ESP8266)
* 9: Status LED (optional if you don't want to use the LED-version of AC_EventFacility)

==ESP8266==

'' '''Work in progress, stand by. Some information may be plain wrong, so... Last edit 19.06.2018.''' ''

The ESP8266 is IP- and WLAN-connectivity on a chip - SSL, TCP, UDP, WLAN; as a client or even as an access point (limited to 4 connections).

The chip supports a number of modes that exclude each other:

* Single/ multiple connection. Determines if only a single connection can be active at the same time, or up to four connections. The mode can only be changed if there currently is no connection. For SSL only single connection mode is supported (I guess SSL is too demanding for multiple connections). Multiple connection mode is required for server mode. Why would you limit yourself to a single connection? I don't know, but I use single connection mode because I need only one connection (to the MQTT broker), and sending out commands and parsing replies is more complex in multiple connection mode.
* IP client/ server mode. Determines if the chips opens connections as a client or if it accepts incoming connections as a server. The latter requires multiple connection mode.
* WLAN station/ AP mode. Determines if the chip acts as a client that logs into an existing WLAN or if the chip acts as a WLAN access points which other clients can connect to.

The pins:

* Vcc: 3.3V (using a voltage converter if you use a 5V power supply). Really recommended to avoid strange behavior: Use a 100uF or larger electrolytic capacitor between Vcc and GND to buffer power spikes the ESP generates during operation (I'm using 1000uF).
* GND: Connect to GND of the Arduino
* RST: Reset. Tie to 3.3V (optional, but just to make sure OR connect to Arduino pin for allow for programmable hardware resets).
* CH-PD: Chip enable. Tie to 3.3V (mandatory, otherwise the chip won't listen).
* GPIO0: Digital I/O pin 0. Tie to 3.3V (optional, but just to make sure as this pin is used in conjunction with RST to program the ESP).
* GPIO2: Digital I/O pin 2. You can use this pin for your own programs; otherwise just don't connect it.
* TX: Transmit. Connect to RXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).
* RX: Receive. Connect to TXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).

Regarding the level shifting and voltage conversion: I am using a small COTS board that does both (it's the larger blue board that the smaller black ESP8266-board is plugged into). That is not a requirement; I've been using separate level shifters and voltage converters in some projects. It just means more manual wiring and no cost savings.

=== ESP Troubles===

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMNSHO as I spent many hours on dealing with this).

With "misbehave" I mean:

* Simply not reacting as expected (replying to a command in unexpected ways)
* Not be able to establish a WLAN or TCP connection
* Being stuck in some internal odd state that produces gobs of output
* Random reboots

These problems can all be addressed though. Sometimes a software rest helps (a command sent via the serial interface). Sometime a hardware reset is required. On rarer occasions the power needs to be cycled. My software stack uses software and hardware resets. In order to perform hardware resets I connect an Arduino I/O pin to the ESP reset pin (the library supports this). It would be easy to extend that scheme to cycling the power by using another I/O pin, and a transistor that switches the chip off and on again.

The ESP is its own computer on a chip, just like the Arduino. And it can be programmed by you, just like an Arduino. For why I don't use it ''instead'' of an Arduino, please see the next section.

==Why not just an ESP8266?==

Good question! Less hardware, more memory, direct function calls instead of serial communications all sound good. But, the Arduino has more I/O pins. I found programming the ESP is slow, and the ESP is less forgiving when it is handled the wrong way, be it hardware or even software. I fried an ESP by just trying to "blink" all I/O pins, to find out which number corresponds to which pin. After that the ESP did not interact with the programmer any more :-(.

[[The AME Stack]]
__NOTOC__

AME Software

2018-06-24T20:16:19Z

Ctreber: /* AC_ESP8266 */

[[The AME Stack]]

=AME Stack (Software)=

[[File:The_AME_Stack_(Software).png|left|thumb|1200px|Class structure (operations incomplete)]] 

==Introduction/ Random Thoughts==

Because there is no concurrency on the Arduino platform we have to implement it ourselves. The Arduino standard-loop() is extended through all the classes listed below. loop() is executed as often as possible and gives each class its turn to do "its thing" (in example, detect incoming IP data on the lowest level, or perform and publish a temperature measurement on the highest).

Instances on a higher lever of the stack should not have to know how to configure the instances they use on a lower level. In example, the MQTT level needs TCP connectivity but should not have to know whether this is being provided via Ethernet or WLAN. Because every thing needs a buzzword to market the idea, the concept of providing specific configuration from the outside has been called "Dependency Injection". In the case of the AME stack, a factory configures instances for each level and plugs them together.

==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.

[[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===

loop() ensures arriving IP data and chip messages get read and interpreted.

===Event Consumption===

None; this is the lowest level of the stack.

===Event Production===

If IP data arrives or the connection was lost it informs the listener.

==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.

===Looping===

loop() just calls loop() on ESP level.

===Event Production===

See next point.

===Event Consumption===

If IP data arrives is passes it on to the next higher level.

==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.

===Looping===

loop() checks for the need to ping the broker if there was no recent network activity (to keep the connection alive) and whether the wait for a ping request has timed out. It checks, too, if the TCP connection is working.

It probably would be better design to leave that to the TCP level. Some philosophy is involved here as well: Should the TCP level make sure a created connection is being maintained, or is it better to back-delegate error handling to the caller as requirements for error handling may depend on the use of the TCP API?

===Event Production===

If a MQTT publication has been received it informs the listener.

===Event Consumption===

If IP data has been received it decodes the MQTT message.

==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.

===Looping===

loop() re-establishes the MQTT connection if it has been lost. This currently happens on this level as information about device and capabilities is being published when a connection is made (again). It probably would be better design to leave connection maintenance to the MQTT level and just get notified when there was a connection problem and the connection got reestablished.

===Event Production===

See next point.

===Event Consumption===

Passes MQTT publications on to capabilities if the topic name matches or the publication is of generic nature.

==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.

===Looping===

Optional. Can be used to in example perform and publish a temperature measurement every 60 seconds.

===Event Production===

May publish messages via MQTT.

===Event Consumption===

May subscribe to MQTT topics.

==Arduino==

Communications between Arduino and ESP8266 is via serial interface. The timing demands are high as the ESP mercilessly transmits arriving IP data at full speed. SoftwareSerial definitely is ''not'' an option. The hardware serial interface usually is used to program the Arduino, though. I use SPI programming und logging via I2C to free up the hardware interface ([[AC.programmer|details]]). And since we don't need a bootloader anymore, we gain 2kB of flash memory as well.

To avoid problems I increased the size of the receive buffer from 64 to 256 bytes. This does eat RAM memory, but makes for safer operation. Your mileage may vary: if your messages are short 64 Bytes is just fine.

To adjust the receive buffer size, add the line

#define SERIAL_RX_BUFFER_SIZE 256

in HardwareSerial.h before the first #if. In newer installations of the Arduino IDE on Windows the file does not reside south of the program folder, but is located in AppData/Local, in example

C:\Users\<username>\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.16\cores\arduino

[[The AME Stack]]
__NOTOC__

File:20180615T143431 corrected.jpg

2018-06-24T20:15:27Z

Ctreber:

ESP8266 AT Command Reference

2018-06-24T16:55:02Z

Ctreber: /* ESP8266 AT Command Reference */

=ESP8266 AT Command Reference=

Communication with the ESP is via serial connection. The designers of the ESP adopted a scheme known as "AT commands" that stems from the age when computers connected to a network via modem (I am even older than that).

The commands that the ESP understands depend on the firmware version. There are a number of those; here are the ones I found a manual for:

* 0.20
* 0.22
* 0.23
* 0.24
* 0.25
* 0.30
* 1.3 At the beginning of 2017 this was the newest version when ordering from Banggood
* 1.4
* 1.5
* 1.5.4
* 2.0.0
* 2.1.0

REM: A change in FW version does not imply a change in supported AT commands.

Communication with the ESP comes in four flavors:

* test command: To query values parameters can assume, use AT+<cmd>=?
* query command: To query the current value of parameters, use AT+<cmd&gt?
* setup command: To set parameters, use AT+<cmd>=<x>
* execute command: To execute a function, use AT+<cmd>

This scheme does not always apply but gives you an idea.

Generally:

* Strings need to be quoted
* Parameter are separated with a comma
* Each command must be followed with CRLF
* 115200Baud is the default speed

I wrote a Java program that communicates with an ESP8266 to try out things before I put them into my AC_ESP8266 library. Testing out of Eclipse is just way faster and more convenient then uploading a new version to the Arduino each time. And, logging on the desktop offers way more possibilities.

==Basic==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>Basic</td>
<td>AT</td>
<td>Test AT startup</td>
<td>-</td>
<td>OK</td>
<td></td>
</tr>

<tr>
<td>Basic</td>
<td>AT+RST</td>
<td>Restart module</td>
<td>-</td>
<td>OK</td>
<td>x, for error handling</td>
</tr>

<tr>
<td>Basic</td>
<td>AT+GMR</td>
<td>View version info</td>
<td>-</td>
<td>
<AT version info> 
<SDK version info> 
<compile time> 
 
OK</td>
<td>x, for issuing the correct commands</td>
</tr>

<tr>
<td>Basic</td>
<td>AT+GSLP</td>
<td>Enter deep-sleep mode</td>
<td><time in millis></td>
<td><time> 
OK
<td>-</td>
</tr>

<tr>
<td>Basic</td>
<td>ATE</td>
<td>AT</td>
<td>commands echo or not</td>
<td>ATE0, ATE1 
OK</td>
<td>-</td>
</tr>

<tr>
<td>Basic</td><td>AT+RESTORE</td>
<td>Factory reset</td>
<td>-</td>
<td>OK</td>
<td>-
</tr>
<tr>
<td>Basic</td><td>AT+UART</td>
<td>UART configuration, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+UART_CUR</td>
<td>UART current configuration</td>
<td>
<baudrate 110-115200>, <databits 5-8>, <stopbits 1: 1, 2: 1.5, 3: 2>, <parity 0: none, 1: odd, 2: even>, <flow control 0: disable, 1: RTS, 2: CTS, 3: RTS + CTS>
</td>
<td>OK</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+UART_DEF</td>
<td>UART default configuration, save to flash</td>
<td>
</td>
<td>
</td>
<td>once
</tr>

<tr>
<td>Basic</td><td>AT+SLEEP</td>
<td>Sleep mode (station mode only)</td>
<td><sleep mode 0: disable, 1: light, 2: modem></td>
<td>
Query:
+SLEEP:<sleep mode>
Set:
OK
</td>
<td>-</td>
</tr>

<tr>
<td>Basic</td><td>AT+WAKEUPGPIO</td>
<td>Set a GPIO to wake ESP8266 up from light-sleep mode</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+RFPOWER</td>
<td>Set maximum value of RF TX Power</td>
<td><power 0-82> in 0.25dBm</td>
<td>OK</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+RFVDD</td>
<td>Set RF TX Power according to VDD33</td>
<td>
</td>
<td>
</td>
<td>-
</tr>
</table>

==WLAN==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>WLAN</td><td>AT+CWMODE</td>
<td>Wi-Fi mode(sta/AP/sta+AP), [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWMODE_CUR</td>
<td>Wi-Fi mode (station/ AP/ station+AP). Settings not updated in flash.</td>
<td><mode 1: station, 2: softAP, 3: softAP + station></td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWMODE_DEF</td>
<td>Wi-Fi default mode(station/ AP/ station+AP). Save to flash.</td>
<td>
</td>
<td>
</td>
<td>x - what does saving to flash provide?
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP</td>
<td>Connect to AP, [@deprecated]</td>
<td>

</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP_CUR</td>
<td>Connect to AP, won’t save to flash (station mode only)</td>
<td><ssid>,<pwd>[, <bssid>]</td>
<td>
Query:
+CWJAP_CUR:<ssid>, <bssid>, <channel>, <rssi>
OK
Set:
OK 
or
+CWJAP:<error code 1: connection timeout, 2: wrong password, 3: cannot find target AP, 4: connection failed>
</td>
<td>-</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP_DEF</td>
<td>Connect to AP, save to flash (station mode only)</td>
<td>
</td>
<td>
</td>
<td>x - what does saving to flash provide?
</tr>

<tr>
<td>WLAN</td><td>AT+CWLAPOPT</td>
<td>Set the configuration of command AT+CWLAP</td>
<td><sort enable 0: no sort, 1: sort by rssi>,<mask b0: ECN, b1: SSID, b2: RSSI, b3: MAC, b4: chn, b5: freq offset, b6: freq calibration></td>
<td>
</td>
<td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWLAP</td>
<td>Lists available APs</td>
<td><ssid>[, <mac>, <ch>]</td>
<td>
+CWLAP:<ecn 0: open, 1: WEP, 2: WPA_PSK, 3: WPA2_PSK, 4: WPA_WPA2_PSK, 5: WPA2_Enterprise>, <ssid>, <rssi>, <mac>, <ch>, <freq offset>, <freq calibration>
OK
depending on options set with CWLAPOPT
</td>
<td>maybe, for selecting a WLAN</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWQAP</td>
<td>Disconnect from AP</td>
<td>-</td>
<td>OK</td>
<td>maybe, for error handling
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP</td>
<td>Set configuration of ESP8266 soft-AP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP_CUR</td>
<td>Set current configuration of ESP8266 soft-AP. Settings not updated in flash.</td>
<td>
<ssid>, <pwd>, <chl>, <ecn 0, 2, 3, 4>[, <max conn 1-4>][, <ssid hidden 0: broadcast, 1: don't broadcast>]
</td>
<td>
Query:
+CWSAP_CUR:<ssid>, <pwd>, <chl>, <ecn>, <max conn>, <ssid hidden>
Set:
OK
or
ERROR
</td>
<td>-</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP_DEF</td>
<td>Set configuration of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWLIF</td>
<td>Get station IP which is connected to ESP8266 soft-AP</td>
<td>-</td>
<td>
<IP addr>, <mac>
 
OK
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP</td>
<td>Enable/Disable DHCP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP_CUR</td>
<td>Enable/Disable DHCP, changes not save to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP_DEF</td>
<td>Enable/Disable DHCP, save changes to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCPS_CUR</td>
<td>Set IP range of DHCP server, changes not save to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCPS_DEF</td>
<td>Set IP range of DHCP server, save changes to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWAUTOCONN</td>
<td>Connect to AP automatically on power-up</td>
<td><enable 0: disable, 1: enable auto-connect on startup></td>
<td>
</td>
<td>x - quite possibly!
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC</td>
<td>Set MAC address of ESP8266 station [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC_CUR</td>
<td>Set MAC address of ESP8266 station. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC_DEF</td>
<td>Set MAC address of ESP8266 station. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC</td>
<td>Set MAC address of ESP8266 soft-AP [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC_CUR</td>
<td>Set MAC address of ESP8266 soft-AP. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC_DEF</td>
<td>Set MAC address of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA</td>
<td>Set IP address of ESP8266 station, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA_CUR</td>
<td>Set IP address of ESP8266 station. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>x - to query
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA_DEF</td>
<td>Set IP address of ESP8266 station. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP</td>
<td>Set IP address of ESP8266 soft-AP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP_CUR</td>
<td>Set IP address of ESP8266 soft-AP. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP_DEF</td>
<td>Set IP address of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTARTSMART</td>
<td>Start SmartConfig (for AirKiss or ESP-TOUCH)</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTOPSMART</td>
<td>Stop SmartConfig</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTARTDISCOVER</td>
<td>Start the mode that ESP8266 can be found by WeChat</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTOPDISCOVER</td>
<td>Stop the mode that ESP8266 can be found by WeChat</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+WPS</td>
<td>Set WPS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+MDNS</td>
<td>Set MDNS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>
</table>

==TCP==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>TCP</td><td>AT+CIPSTATUS</td>
<td>Get connection status</td>
<td>
</td>
<td>
STATUS:<stat: 2: connected to AP, obtained IP, 3: TCP or UDP connection created, 4: TCP or UDP disconnected, 5: not connected to AP> 
 
+CIPSTATUS:<link ID 0-4>, <type TCP or UDP>, <remote_IP>, <remote_port>, <local_port>, <tetype 0: client, 1: server>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPDOMAIN</td>
<td>DNS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIPSTART</td>
<td>Establish TCP connection, UDP transmission or SSL connection (only one at the same time, high memory consumption)</td>
<td><link ID 0-4>,<type TCP, UDP, SSL>, <remote IP>, <remote port>[, <TCP keep alive>]</td>
<td>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPSSLSIZE</td>
<td>Set the size of SSL buffer</td>
<td>
</td>
<td>
</td>
<td>maybe, SSL would be great
</tr>

<tr>
<td>TCP</td><td>AT+CIPSEND</td>
<td>Send data</td>
<td>AT+CIPSEND=<link ID>, <length>
then receives serial data until length is reached, then
ERROR
or
SEND OK</td>
<td>x</td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPSENDEX</td>
<td>Send data, if <length> or "\0" is met, data will be sent</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPSENDBUF</td>
<td>Write data into TCP-send-buffer</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPBUFRESET</td>
<td>Reset segment ID count</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPBUFSTATUS</td>
<td>Check status of TCP-send-buffer (not for SSL connections)</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPCHECKSEQ</td>
<td>Check if a specific segment is sent or not</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPCLOSE</td>
<td>Close TCP/UDP/SSL connection </td>
<td>
</td>
<td>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIFSR</td>
<td>Get local IP address </td>
<td>
</td>
<td>
+ CIFSR:<IP address> 
 
OK
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPMUX</td>
<td>Set multiple connections mode</td>
<td>
</td>
<td>
</td>
<td>x - to select single mode, but do we need single mode?
</tr>

<tr>
<td>TCP</td><td>AT+CIPSERVER</td>
<td>Configure as server</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIPMODE</td>
<td>Set transmission mode</td>
<td>
</td>
<td>
</td>
<td>- not used so far
</tr>

<tr>
<td>TCP</td><td>AT+SAVETRANSLINK</td>
<td>Save transparent transmission link to flash</td>
<td>
</td>
<td>
</td>
<td>- I get the impression this creates a TCP connection and after that, serial talks transparently to that connection
</tr>

<tr>
<td>TCP</td><td>AT+CIPSTO</td>
<td>Set timeout when ESP8266 runs as TCP server</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIUPDATE</td>
<td>Upgrade firmware through network</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+PING</td>
<td>Function PING </td>
<td><IP></td>
<td>
+<time> 
 
OK
Or
ERROR
</td>
<td>maybe, for error handling
</tr>
<tr>
<td>TCP</td><td>AT+CIPDINFO</td>
<td>Show remote IP and remote port with "+IPD" </td>
<td>
</td>
<td>
</td>
<td>-
</td>
</tr>
</table>

__NOTOC__

Hardware Problems

2018-06-24T13:42:11Z

Ctreber:

[[IoT with AME|Home]]

=Embedded Hardware Problems=

Bugs are not limited to software - plain electricity can be tricky, too! Sometimes it even kills (and I'm referring to Arduinos here).

* [[Staying well-grounded]] - Why not everybody can have their own GND (ground; this is important to the health of your Arduino!)
* [[Sufficient power-supply]] - Some chips suck (power)
* [[Port-Power]] - How to not power an Arduino (via an I/O port)
* Fun with [[pitfalls-power lan|power LAN]] adapters (don't plug your fridge into one)

[[IoT with AME|Home]]

Port-Power

2018-06-24T13:41:08Z

Ctreber: Created page with "Hardware Problems =Port-Power - How to not power an Arduino (via an I/O port)= I powered up my breadboard circuit, the LED on the Arduino came on - all is well. Or not..."

[[Hardware Problems]]

=Port-Power - How to not power an Arduino (via an I/O port)=

I powered up my breadboard circuit, the LED on the Arduino came on - all is well.

Or not, since the Arduino is not connected to power via RAW or ACC. Why then does the Arduino power LED come on?

Turns out GND was connected, and so was 5V to one of the I/O pins. And, there is a path from that pin to ACC: via the internal pullup resistor!

[[Hardware Problems]]

Hardware Problems

2018-06-24T13:32:43Z

Ctreber: /* Embedded Hardware Problems */

[[IoT with AME|Home]]

=Embedded Hardware Problems=

Bugs are not limited to software - plain electricity can be tricky, too! Sometimes it even kills (and I'm referring to Arduinos here).

* [[Sufficient power-supply]] - Some chips suck (power)
* [[Staying well-grounded]] - Why not everybody can have their own GND (ground)
* [[Port-Power]] - How to not power an Arduino (via an I/O port)
* Fun with [[pitfalls-power lan|power LAN]] adapters (don't plug your fridge into one)

[[IoT with AME|Home]]

ESP8266 AT Command Reference

2018-06-24T11:47:28Z

Ctreber: Created page with "=ESP8266 AT Command Reference= ==Basic== <table class="wikitable"> <tr> <th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Rel..."

=ESP8266 AT Command Reference=

==Basic==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>Basic</td>
<td>AT</td>
<td>Test AT startup</td>
<td>-</td>
<td>OK</td>
<td></td>
</tr>

<tr>
<td>Basic</td>
<td>AT+RST</td>
<td>Restart module</td>
<td>-</td>
<td>OK</td>
<td>x, for error handling</td>
</tr>

<tr>
<td>Basic</td>
<td>AT+GMR</td>
<td>View version info</td>
<td>-</td>
<td>
<AT version info> 
<SDK version info> 
<compile time> 
 
OK</td>
<td>x, for issuing the correct commands</td>
</tr>

<tr>
<td>Basic</td>
<td>AT+GSLP</td>
<td>Enter deep-sleep mode</td>
<td><time in millis></td>
<td><time> 
OK
<td>-</td>
</tr>

<tr>
<td>Basic</td>
<td>ATE</td>
<td>AT</td>
<td>commands echo or not</td>
<td>ATE0, ATE1 
OK</td>
<td>-</td>
</tr>

<tr>
<td>Basic</td><td>AT+RESTORE</td>
<td>Factory reset</td>
<td>-</td>
<td>OK</td>
<td>-
</tr>
<tr>
<td>Basic</td><td>AT+UART</td>
<td>UART configuration, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+UART_CUR</td>
<td>UART current configuration</td>
<td>
<baudrate 110-115200>, <databits 5-8>, <stopbits 1: 1, 2: 1.5, 3: 2>, <parity 0: none, 1: odd, 2: even>, <flow control 0: disable, 1: RTS, 2: CTS, 3: RTS + CTS>
</td>
<td>OK</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+UART_DEF</td>
<td>UART default configuration, save to flash</td>
<td>
</td>
<td>
</td>
<td>once
</tr>

<tr>
<td>Basic</td><td>AT+SLEEP</td>
<td>Sleep mode (station mode only)</td>
<td><sleep mode 0: disable, 1: light, 2: modem></td>
<td>
Query:
+SLEEP:<sleep mode>
Set:
OK
</td>
<td>-</td>
</tr>

<tr>
<td>Basic</td><td>AT+WAKEUPGPIO</td>
<td>Set a GPIO to wake ESP8266 up from light-sleep mode</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+RFPOWER</td>
<td>Set maximum value of RF TX Power</td>
<td><power 0-82> in 0.25dBm</td>
<td>OK</td>
<td>-
</tr>

<tr>
<td>Basic</td><td>AT+RFVDD</td>
<td>Set RF TX Power according to VDD33</td>
<td>
</td>
<td>
</td>
<td>-
</tr>
</table>

==WLAN==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>WLAN</td><td>AT+CWMODE</td>
<td>Wi-Fi mode(sta/AP/sta+AP), [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWMODE_CUR</td>
<td>Wi-Fi mode (station/ AP/ station+AP). Settings not updated in flash.</td>
<td><mode 1: station, 2: softAP, 3: softAP + station></td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWMODE_DEF</td>
<td>Wi-Fi default mode(station/ AP/ station+AP). Save to flash.</td>
<td>
</td>
<td>
</td>
<td>x - what does saving to flash provide?
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP</td>
<td>Connect to AP, [@deprecated]</td>
<td>

</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP_CUR</td>
<td>Connect to AP, won’t save to flash (station mode only)</td>
<td><ssid>,<pwd>[, <bssid>]</td>
<td>
Query:
+CWJAP_CUR:<ssid>, <bssid>, <channel>, <rssi>
OK
Set:
OK 
or
+CWJAP:<error code 1: connection timeout, 2: wrong password, 3: cannot find target AP, 4: connection failed>
</td>
<td>-</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWJAP_DEF</td>
<td>Connect to AP, save to flash (station mode only)</td>
<td>
</td>
<td>
</td>
<td>x - what does saving to flash provide?
</tr>

<tr>
<td>WLAN</td><td>AT+CWLAPOPT</td>
<td>Set the configuration of command AT+CWLAP</td>
<td><sort enable 0: no sort, 1: sort by rssi>,<mask b0: ECN, b1: SSID, b2: RSSI, b3: MAC, b4: chn, b5: freq offset, b6: freq calibration></td>
<td>
</td>
<td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWLAP</td>
<td>Lists available APs</td>
<td><ssid>[, <mac>, <ch>]</td>
<td>
+CWLAP:<ecn 0: open, 1: WEP, 2: WPA_PSK, 3: WPA2_PSK, 4: WPA_WPA2_PSK, 5: WPA2_Enterprise>, <ssid>, <rssi>, <mac>, <ch>, <freq offset>, <freq calibration>
OK
depending on options set with CWLAPOPT
</td>
<td>maybe, for selecting a WLAN</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWQAP</td>
<td>Disconnect from AP</td>
<td>-</td>
<td>OK</td>
<td>maybe, for error handling
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP</td>
<td>Set configuration of ESP8266 soft-AP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP_CUR</td>
<td>Set current configuration of ESP8266 soft-AP. Settings not updated in flash.</td>
<td>
<ssid>, <pwd>, <chl>, <ecn 0, 2, 3, 4>[, <max conn 1-4>][, <ssid hidden 0: broadcast, 1: don't broadcast>]
</td>
<td>
Query:
+CWSAP_CUR:<ssid>, <pwd>, <chl>, <ecn>, <max conn>, <ssid hidden>
Set:
OK
or
ERROR
</td>
<td>-</td>
</tr>

<tr>
<td>WLAN</td><td>AT+CWSAP_DEF</td>
<td>Set configuration of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWLIF</td>
<td>Get station IP which is connected to ESP8266 soft-AP</td>
<td>-</td>
<td>
<IP addr>, <mac>
 
OK
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP</td>
<td>Enable/Disable DHCP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP_CUR</td>
<td>Enable/Disable DHCP, changes not save to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCP_DEF</td>
<td>Enable/Disable DHCP, save changes to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCPS_CUR</td>
<td>Set IP range of DHCP server, changes not save to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWDHCPS_DEF</td>
<td>Set IP range of DHCP server, save changes to flash</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWAUTOCONN</td>
<td>Connect to AP automatically on power-up</td>
<td><enable 0: disable, 1: enable auto-connect on startup></td>
<td>
</td>
<td>x - quite possibly!
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC</td>
<td>Set MAC address of ESP8266 station [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC_CUR</td>
<td>Set MAC address of ESP8266 station. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTAMAC_DEF</td>
<td>Set MAC address of ESP8266 station. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC</td>
<td>Set MAC address of ESP8266 soft-AP [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC_CUR</td>
<td>Set MAC address of ESP8266 soft-AP. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAPMAC_DEF</td>
<td>Set MAC address of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA</td>
<td>Set IP address of ESP8266 station, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA_CUR</td>
<td>Set IP address of ESP8266 station. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>x - to query
</tr>

<tr>
<td>WLAN</td><td>AT+CIPSTA_DEF</td>
<td>Set IP address of ESP8266 station. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP</td>
<td>Set IP address of ESP8266 soft-AP, [@deprecated]</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP_CUR</td>
<td>Set IP address of ESP8266 soft-AP. Changes not save to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CIPAP_DEF</td>
<td>Set IP address of ESP8266 soft-AP. Save changes to flash.</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTARTSMART</td>
<td>Start SmartConfig (for AirKiss or ESP-TOUCH)</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTOPSMART</td>
<td>Stop SmartConfig</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTARTDISCOVER</td>
<td>Start the mode that ESP8266 can be found by WeChat</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+CWSTOPDISCOVER</td>
<td>Stop the mode that ESP8266 can be found by WeChat</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+WPS</td>
<td>Set WPS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>WLAN</td><td>AT+MDNS</td>
<td>Set MDNS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>
</table>

==TCP==

<table class="wikitable">
<tr>
<th>Group</th><th>AT Command</th><th>Description</th><th>Parameters</th><th>Response</th><th>MQTT-Relevant?</th>
</tr>
<tr>
<td>TCP</td><td>AT+CIPSTATUS</td>
<td>Get connection status</td>
<td>
</td>
<td>
STATUS:<stat: 2: connected to AP, obtained IP, 3: TCP or UDP connection created, 4: TCP or UDP disconnected, 5: not connected to AP> 
 
+CIPSTATUS:<link ID 0-4>, <type TCP or UDP>, <remote_IP>, <remote_port>, <local_port>, <tetype 0: client, 1: server>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPDOMAIN</td>
<td>DNS function</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIPSTART</td>
<td>Establish TCP connection, UDP transmission or SSL connection (only one at the same time, high memory consumption)</td>
<td><link ID 0-4>,<type TCP, UDP, SSL>, <remote IP>, <remote port>[, <TCP keep alive>]</td>
<td>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPSSLSIZE</td>
<td>Set the size of SSL buffer</td>
<td>
</td>
<td>
</td>
<td>maybe, SSL would be great
</tr>

<tr>
<td>TCP</td><td>AT+CIPSEND</td>
<td>Send data</td>
<td>AT+CIPSEND=<link ID>, <length>
then receives serial data until length is reached, then
ERROR
or
SEND OK</td>
<td>x</td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPSENDEX</td>
<td>Send data, if <length> or "\0" is met, data will be sent</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPSENDBUF</td>
<td>Write data into TCP-send-buffer</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPBUFRESET</td>
<td>Reset segment ID count</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPBUFSTATUS</td>
<td>Check status of TCP-send-buffer (not for SSL connections)</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPCHECKSEQ</td>
<td>Check if a specific segment is sent or not</td>
<td>
</td>
<td>
</td>
<td>
</tr>

<tr>
<td>TCP</td><td>AT+CIPCLOSE</td>
<td>Close TCP/UDP/SSL connection </td>
<td>
</td>
<td>
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIFSR</td>
<td>Get local IP address </td>
<td>
</td>
<td>
+ CIFSR:<IP address> 
 
OK
</td>
<td>x
</tr>

<tr>
<td>TCP</td><td>AT+CIPMUX</td>
<td>Set multiple connections mode</td>
<td>
</td>
<td>
</td>
<td>x - to select single mode, but do we need single mode?
</tr>

<tr>
<td>TCP</td><td>AT+CIPSERVER</td>
<td>Configure as server</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIPMODE</td>
<td>Set transmission mode</td>
<td>
</td>
<td>
</td>
<td>- not used so far
</tr>

<tr>
<td>TCP</td><td>AT+SAVETRANSLINK</td>
<td>Save transparent transmission link to flash</td>
<td>
</td>
<td>
</td>
<td>- I get the impression this creates a TCP connection and after that, serial talks transparently to that connection
</tr>

<tr>
<td>TCP</td><td>AT+CIPSTO</td>
<td>Set timeout when ESP8266 runs as TCP server</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+CIUPDATE</td>
<td>Upgrade firmware through network</td>
<td>
</td>
<td>
</td>
<td>-
</tr>

<tr>
<td>TCP</td><td>AT+PING</td>
<td>Function PING </td>
<td><IP></td>
<td>
+<time> 
 
OK
Or
ERROR
</td>
<td>maybe, for error handling
</tr>
<tr>
<td>TCP</td><td>AT+CIPDINFO</td>
<td>Show remote IP and remote port with "+IPD" </td>
<td>
</td>
<td>
</td>
<td>-
</td>
</tr>
</table>

__NOTOC__

AME Software

2018-06-23T11:20:33Z

Ctreber: /* AME Stack (Software) */

[[The AME Stack]]

=AME Stack (Software)=

[[File:The_AME_Stack_(Software).png|left|thumb|1200px|Class structure (operations incomplete)]] 

==Introduction/ Random Thoughts==

Because there is no concurrency on the Arduino platform we have to implement it ourselves. The Arduino standard-loop() is extended through all the classes listed below. loop() is executed as often as possible and gives each class its turn to do "its thing" (in example, detect incoming IP data on the lowest level, or perform and publish a temperature measurement on the highest).

Instances on a higher lever of the stack should not have to know how to configure the instances they use on a lower level. In example, the MQTT level needs TCP connectivity but should not have to know whether this is being provided via Ethernet or WLAN. Because every thing needs a buzzword to market the idea, the concept of providing specific configuration from the outside has been called "Dependency Injection". In the case of the AME stack, a factory configures instances for each level and plugs them together.

==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.

===Looping===

loop() ensures arriving IP data and chip messages get read and interpreted.

===Event Consumption===

None; this is the lowest level of the stack.

===Event Production===

If IP data arrives or the connection was lost it informs the listener.

==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.

===Looping===

loop() just calls loop() on ESP level.

===Event Production===

See next point.

===Event Consumption===

If IP data arrives is passes it on to the next higher level.

==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.

===Looping===

loop() checks for the need to ping the broker if there was no recent network activity (to keep the connection alive) and whether the wait for a ping request has timed out. It checks, too, if the TCP connection is working.

It probably would be better design to leave that to the TCP level. Some philosophy is involved here as well: Should the TCP level make sure a created connection is being maintained, or is it better to back-delegate error handling to the caller as requirements for error handling may depend on the use of the TCP API?

===Event Production===

If a MQTT publication has been received it informs the listener.

===Event Consumption===

If IP data has been received it decodes the MQTT message.

==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.

===Looping===

loop() re-establishes the MQTT connection if it has been lost. This currently happens on this level as information about device and capabilities is being published when a connection is made (again). It probably would be better design to leave connection maintenance to the MQTT level and just get notified when there was a connection problem and the connection got reestablished.

===Event Production===

See next point.

===Event Consumption===

Passes MQTT publications on to capabilities if the topic name matches or the publication is of generic nature.

==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.

===Looping===

Optional. Can be used to in example perform and publish a temperature measurement every 60 seconds.

===Event Production===

May publish messages via MQTT.

===Event Consumption===

May subscribe to MQTT topics.

==Arduino==

Communications between Arduino and ESP8266 is via serial interface. The timing demands are high as the ESP mercilessly transmits arriving IP data at full speed. SoftwareSerial definitely is ''not'' an option. The hardware serial interface usually is used to program the Arduino, though. I use SPI programming und logging via I2C to free up the hardware interface ([[AC.programmer|details]]). And since we don't need a bootloader anymore, we gain 2kB of flash memory as well.

To avoid problems I increased the size of the receive buffer from 64 to 256 bytes. This does eat RAM memory, but makes for safer operation. Your mileage may vary: if your messages are short 64 Bytes is just fine.

To adjust the receive buffer size, add the line

#define SERIAL_RX_BUFFER_SIZE 256

in HardwareSerial.h before the first #if. In newer installations of the Arduino IDE on Windows the file does not reside south of the program folder, but is located in AppData/Local, in example

C:\Users\<username>\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.16\cores\arduino

[[The AME Stack]]
__NOTOC__

AME Software

2018-06-23T10:15:47Z

Ctreber:

[[The AME Stack]]

=AME Stack (Software)=

[[File:The_AME_Stack_(Software).png|left|thumb|1200px|Class structure (operations incomplete)]] 

==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.

==Arduino==

Communications between Arduino and ESP8266 is via serial interface. The timing demands are high as the ESP mercilessly transmits arriving IP data at full speed. SoftwareSerial definitely is ''not'' an option. The hardware serial interface usually is used to program the Arduino, though. I use SPI programming und logging via I2C to free up the hardware interface ([[AC.programmer|details]]). And since we don't need a bootloader anymore, we gain 2kB of flash memory as well.

To avoid problems I increased the size of the receive buffer from 64 to 256 bytes. This does eat RAM memory, but makes for safer operation. Your mileage may vary: if your messages are short 64 Bytes is just fine.

To adjust the receive buffer size, add the line

#define SERIAL_RX_BUFFER_SIZE 256

in HardwareSerial.h before the first #if. In newer installations of the Arduino IDE on Windows the file does not reside south of the program folder, but is located in AppData/Local, in example

C:\Users\<username>\AppData\Local\Arduino15\packages\arduino\hardware\avr\1.6.16\cores\arduino

[[The AME Stack]]
__NOTOC__

AME Hardware

2018-06-21T20:35:04Z

Ctreber:

[[The AME Stack]]

=AME Stack (Hardware)=

[[File:20170802T115833.jpg|left|thumb|600px|Voltage controller (left), Arduino (top right), and ESP8266 (bottom right)]] 

==Arduino==

The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory for data (EPROM, non-volatile, runtime-programmable), counters, timers, I/O pins, and various interfaces (shared with the I/O pins; interrupts, serial, I2C, SPI). Different models offer different amounts of assets.

Cheap versions can be ordered from Chinese suppliers for 2.50€ a piece. I'm using them all the time, and they just work fine (didn't have a single dud in 20+ Arduinos).

The pins:

* ACC: +5V (if you use the 5V variety of the Arduino, otherwise 3.3V)
* RAW: This feeds the internal voltage regulator. You may apply a higher voltage then on the ACC pin, supposedly up to 12V, but I would not overdo it. In this case, +5V may be obtained on the ACC pin, but the small regulator can't supply much.
* GND: Connect to GND of the ESP8266
* RST: Reset
* TXD: Transmit data (another name for I/O pin 0). Connect to RX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* RXD: Receive data (another name for I/O pin 1). Connect to TX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* 2-13: Digital I/O Pins. Pin 13 is connected to the internal LED (which does not hurt if you want to use the pin for your own purposes).
* A0-A7: Analog I/O Pins (can be used for digital I/O as well)

Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):

* Serial interface: I/O pins 0, 1 become Transmit Data (TXD), Receive Data (RDX)
* External interrupts: I/O pins 2, 3
* Serial Peripheral Interface (SPI): I/O pins 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus with transfer in both directions at the same time. Slaves must be selected using a digital I/O pin, but there is no protocol overhead. Very efficient, but uses a few pins plus one pin for each device.
* Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): I/O pins A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol. More talkative, but uses only two pins for any amount of devices.

==ESP8266==

'' '''Work in progress, stand by. Some information may be plain wrong, so... Last edit 19.06.2018.''' ''

The ESP8266 is IP- and WLAN-connectivity on a chip - SSL, TCP, UDP, WLAN; as a client or even as an access point (limited to 4 connections).

The chip supports a number of modes that exclude each other:

* Single/ multiple connection. Determines if only a single connection can be active at the same time, or up to four connections. The mode can only be changed if there currently is no connection. For SSL only single connection mode is supported (I guess SSL is too demanding for multiple connections). Multiple connection mode is required for server mode. Why would you limit yourself to a single connection? I don't know, but I use single connection mode because I need only one connection (to the MQTT broker), and sending out commands and parsing replies is more complex in multiple connection mode.
* IP client/ server mode. Determines if the chips opens connections as a client or if it accepts incoming connections as a server. The latter requires multiple connection mode.
* WLAN station/ AP mode. Determines if the chip acts as a client that logs into an existing WLAN or if the chip acts as a WLAN access points which other clients can connect to.

The pins:

* Vcc: 3.3V (using a voltage converter if you use a 5V power supply). Really recommended to avoid strange behavior: Use a 100uF or larger electrolytic capacitor between Vcc and GND to buffer power spikes the ESP generates during operation (I'm using 1000uF).
* GND: Connect to GND of the Arduino
* RST: Reset. Tie to 3.3V (optional, but just to make sure OR connect to Arduino pin for allow for programmable hardware resets).
* CH-PD: Chip enable. Tie to 3.3V (mandatory, otherwise the chip won't listen).
* GPIO0: Digital I/O pin 0. Tie to 3.3V (optional, but just to make sure as this pin is used in conjunction with RST to program the ESP).
* GPIO2: Digital I/O pin 2. You can use this pin for your own programs; otherwise just don't connect it.
* TX: Transmit. Connect to RXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).
* RX: Receive. Connect to TXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).

Regarding the level shifting and voltage conversion: I am using a small COTS board that does both (it's the larger blue board that the smaller black ESP8266-board is plugged into). That is not a requirement; I've been using separate level shifters and voltage converters in some projects. It just means more manual wiring and no cost savings.

=== ESP Troubles===

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMNSHO as I spent many hours on dealing with this).

With "misbehave" I mean:

* Simply not reacting as expected (replying to a command in unexpected ways)
* Not be able to establish a WLAN or TCP connection
* Being stuck in some internal odd state that produces gobs of output
* Random reboots

These problems can all be addressed though. Sometimes a software rest helps (a command sent via the serial interface). Sometime a hardware reset is required. On rarer occasions the power needs to be cycled. My software stack uses software and hardware resets. In order to perform hardware resets I connect an Arduino I/O pin to the ESP reset pin (the library supports this). It would be easy to extend that scheme to cycling the power by using another I/O pin, and a transistor that switches the chip off and on again.

The ESP is its own computer on a chip, just like the Arduino. And it can be programmed by you, just like an Arduino. For why I don't use it ''instead'' of an Arduino, please see the next section.

==Why not just an ESP8266?==

Good question! Less hardware, more memory, direct function calls instead of serial communications all sound good. But, the Arduino has more I/O pins. I found programming the ESP is slow, and the ESP is less forgiving when it is handled the wrong way, be it hardware or even software. I fried an ESP by just trying to "blink" all I/O pins, to find out which number corresponds to which pin. After that the ESP did not interact with the programmer any more :-(.

[[The AME Stack]]
__NOTOC__

AME Hardware

2018-06-19T23:20:39Z

Ctreber:

[[The AME Stack]]

=AME Stack (Hardware)=

[[File:20170802T115833.jpg|left|thumb|600px|Voltage controller (left), Arduino (top right), and ESP8266 (bottom right)]] 

==Arduino==

The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory for data (EPROM, non-volatile, runtime-programmable), counters, timers, I/O pins, and various interfaces (shared with the I/O pins; interrupts, serial, I2C, SPI). Different models offer different amounts of assets.

Cheap versions can be ordered from Chinese suppliers for 2.50€ a piece. I'm using them all the time, and they just work fine (didn't have a single dud in 20+ Arduinos).

The pins:

* ACC: +5V (if you use the 5V variety of the Arduino, otherwise 3.3V)
* RAW: This feeds the internal voltage regulator. You may apply a higher voltage then on the ACC pin, supposedly up to 12V, but I would not overdo it. In this case, +5V may be obtained on the ACC pin, but the small regulator can't supply much.
* GND: Connect to GND of the ESP8266
* RST: Reset
* TXD: Transmit data (another name for I/O pin 0). Connect to RX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* RXD: Receive data (another name for I/O pin 1). Connect to TX of the ESP8266 (using a level shifter if you use the 5V variety of the Arduino).
* 2-13: Digital I/O Pins. Pin 13 is connected to the internal LED (which does not hurt if you want to use the pin for your own purposes).
* A0-A7: Analog I/O Pins (can be used for digital I/O as well)

Some I/O pings have alternative meanings depending whether you use certain interfaces (if you don't, they're all yours):

* Serial interface: O, 1 become Transmit Data (TXD), Receive Data (RDX)
* External interrupts: 2, 3
* Serial Peripheral Interface (SPI): 11, 12, 13 become Master Out Slave In (MOSI), Master In Slave Out (MISO), Serial Clock (SCK). This is a serial bidirectional bus. Slaves must be selected using a digital I/O pin, but there is no protocol overhead.
* Inter-Integrated Circuit or Two-Wire Interface (I2C or TWI): A4, A5 become Serial Data (SDA), Serial Clock (SCL). This is a serial bidirectional bus. Communication partners are selected by using addresses transmitted over the bus using a communications protocol.

==ESP8266==

'' '''Work in progress, stand by. Some information may be plain wrong, so... Last edit 19.06.2018.''' ''

The ESP8266 is IP- and WLAN-connectivity on a chip - SSL, TCP, UDP, WLAN; as a client or even as an access point (limited to 4 connections).

The chip supports a number of modes that exclude each other:

* Single/ multiple connection. Determines if only a single connection can be active at the same time, or up to four connections. The mode can only be changed if there currently is no connection. For SSL only single connection mode is supported (I guess SSL is too demanding for multiple connections). Multiple connection mode is required for server mode. Why would you limit yourself to a single connection? I don't know, but I use single connection mode because I need only one connection (to the MQTT broker), and sending out commands and parsing replies is more complex in multiple connection mode.
* IP client/ server mode. Determines if the chips opens connections as a client or if it accepts incoming connections as a server. The latter requires multiple connection mode.
* WLAN station/ AP mode. Determines if the chip acts as a client that logs into an existing WLAN or if the chip acts as a WLAN access points which other clients can connect to.

The pins:

* Vcc: 3.3V (using a voltage converter if you use a 5V power supply). Really recommended to avoid strange behavior: Use a 100uF or larger electrolytic capacitor between Vcc and GND to buffer power spikes the ESP generates during operation (I'm using 1000uF).
* GND: Connect to GND of the Arduino
* RST: Reset. Tie to 3.3V (optional, but just to make sure OR connect to Arduino pin for allow for programmable hardware resets).
* CH-PD: Chip enable. Tie to 3.3V (mandatory, otherwise the chip won't listen).
* GPIO0: Digital I/O pin 0. Tie to 3.3V (optional, but just to make sure as this pin is used in conjunction with RST to program the ESP).
* GPIO2: Digital I/O pin 2. You can use this pin for your own programs; otherwise just don't connect it.
* TX: Transmit. Connect to RXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).
* RX: Receive. Connect to TXD of the Arduino (using a level shifter if you use the 5V variety of the Arduino).

Regarding the level shifting and voltage conversion: I am using a small COTS board that does both (it's the larger blue board that the smaller black ESP8266-board is plugged into). That is not a requirement; I've been using separate level shifters and voltage converters in some projects. It just means more manual wiring and no cost savings.

=== ESP Troubles===

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMNSHO as I spent many hours on dealing with this).

With "misbehave" I mean:

* Simply not reacting as expected (replying to a command in unexpected ways)
* Not be able to establish a WLAN or TCP connection
* Being stuck in some internal odd state that produces gobs of output
* Random reboots

These problems can all be addressed though. Sometimes a software rest helps (a command sent via the serial interface). Sometime a hardware reset is required. On rarer occasions the power needs to be cycled. My software stack uses software and hardware resets. In order to perform hardware resets I connect an Arduino I/O pin to the ESP reset pin (the library supports this). It would be easy to extend that scheme to cycling the power by using another I/O pin, and a transistor that switches the chip off and on again.

The ESP is its own computer on a chip, just like the Arduino. And it can be programmed by you, just like an Arduino. For why I don't use it ''instead'' of an Arduino, please see the next section.

==Why not just an ESP8266?==

Good question! Less hardware, more memory, direct function calls instead of serial communications all sound good. But, the Arduino has more I/O pins. I found programming the ESP is slow, and the ESP is less forgiving when it is handled the wrong way, be it hardware or even software. I fried an ESP by just trying to "blink" all I/O pins, to find out which number corresponds to which pin. After that the ESP did not interact with the programmer any more :-(.

[[The AME Stack]]
__NOTOC__

AME Hardware

2018-06-19T22:33:44Z

Ctreber: /* ESP8266 */

AME Hardware

2018-06-19T22:33:04Z

Ctreber:

AME Software

2018-06-19T22:29:50Z

Ctreber:

File:The AME Stack (Software).png

2018-06-19T22:26:20Z

Ctreber:

IoT with AME

2018-06-19T22:19:35Z

Ctreber:

=IoT with AME - The Internet of Things, with Arduino, MQTT, and ESP8266=

[[File:20170802T115833.jpg|thumb|left|300px|Voltage controller (left), status LED (RGB; top), Arduino (top right), ESP8266 (bottom right, on adapter) - My standard hardware stack]] This is work in progress started in June 2017 - I am in the process of typing out my experiences with IoT, Arduino, and ESP8266, as a documentation for myself and as something that might be helpful to others.

* [[The AME Stack]] - A compact software and hardware stack to build MQTT-connected IoT devices
* [[My IoT projects]] - What I built over time (plenty!)
* [[MQTT]] - A protocol for connecting IoT devices
* [[Software Stack|Software]]: Libraries for devices and capabilities, and access on MQTT-, TCP-, WLAN-, and chip level
* [[Software Problems]]: C++ and very small memory pose diverse challenges
* [[Hardware Stack|Hardware]]: Arduino, ESP8266, and additional hardware
* [[Hardware Problems]]: Bugs are not limited to software - plain electricity can be tricky, too!
* [[Challenges]] - How to overcome hardware and software limitations
* [[IoT Management]] - How to manage an IoT installation
* [[To Do]] - What I would like to improve and add in this Wiki

 Note to self (help on MediaWiki):

* https://www.mediawiki.org/wiki/Manual:FAQ
* https://en.wikipedia.org/wiki/Help:Wiki_markup

AME Hardware

2018-06-19T13:25:48Z

Ctreber: /* ESP8266 */

[[The AME Stack]]

=AME Hardware=

==Arduino==

The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory for data (EPROM, non-volatile, runtime-programmable), counters, timers, I/O pins, and various interfaces (shared with the I/O pins; interrupts, serial, I2C, SPI). Different models offer different amounts of assets.

Cheap versions can be ordered from Chinese suppliers for 2.50€ a piece. I'm using them all the time, and they just work fine (didn't have a single dud in 20+ Arduinos).

==ESP8266==

'' '''Work in progress, stand by. Some information may be plain wrong, so... Last edit 19.06.2018.''' ''

The ESP8266 is IP and WLAN on a chip - SSL, TCP, UDP, WLAN, as a client or even as an access point (limited to 4 connections).

The chip supports a number of modes that exclude each other:

* Single/ multiple connection. Determines if only a single connection can be active at the same time, or up to four connections. The mode can only be changed if there currently is no connection. For SSL only single connection mode is supported (I guess SSL is too demanding for multiple connections). Multiple connection mode is required for server mode. Why would you limit yourself to a single connection? I don't know, but I use single connection mode because I need only one connection (to the MQTT broker), and sending out commands and parsing replies is more complex in multiple connection mode.
* IP client/ server mode. Determines if the chips opens connections as a client or if it accepts incoming connections as a server. The latter requires multiple connection mode.
* WLAN station/ AP mode. Determines if the chip acts as a client that logs into an existing WLAN or if the chip acts as a WLAN access points which other clients can connect to.

I have had ESPs that misbehaved a lot, and the chip and the serial connection are prone to problems in general (IMHO!). With "misbehave" I mean:

* Simply not reacting as expected (replying to a command in unexpected ways)
* Not be able to establish a WLAN or TCP connection
* Being stuck in some internal odd state that produces gobs of output
* Random reboots

These problems can all be addressed though. Sometimes a software rest helps (a command sent via the serial interface). Sometime a hardware reset is required. On rarer occasions the power needs to be cycled. My software stack uses software and hardware resets. In order to perform hardware resets I connect an Arduino I/O pin to the ESP reset pin (the library supports this). It would be easy to extend that scheme to cycling the power by using another I/O pin, and a transistor that switches the chip off and on again.

The ESP is its own computer on a chip, just like the Arduino. And it can be programmed by you, just like an Arduino. For why I don't use it ''instead'' of an Arduino, please see the next section.

==Why not just an ESP8266?==

Good question! Less hardware, more memory, direct function calls instead of serial communications all sound good. But, the Arduino has more I/O pins. I found programming the ESP is slow, and the ESP is less forgiving when it is handled the wrong way, be it hardware or even software. I fried an ESP by just trying to blink on all I/O pins, to find out which number corresponds to which pin. After the ESP did not interact with the programmer any more.

[[The AME Stack]]
__NOTOC__

AME Hardware

2018-06-19T10:16:21Z

Ctreber: Created page with "The AME Stack =AME Hardware= ==Arduino== The Arduino is a computer on a chip - CPU, memory for programs (ROM, flashable), memory for variables (RAM, volatile), memory f..."

AME Software

2018-06-19T09:33:56Z

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..."

[[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__

The AME Stack

2018-06-19T09:31:22Z

Ctreber: Replaced content with "Home =The AME Stack= * Design Goals * Software * Hardware * AME_Status_and_Logging|Status Information..."

AME Status and Logging

2018-06-19T09:29:05Z

Ctreber: Created page with "The AME Stack =AME Status Information and Logging= Since a whole bunch of components are working together things can get tough when there is a problem. The AME stack pr..."

AME Goals

2018-06-19T09:27:36Z

Ctreber:

[[The AME Stack]]

=AME Design Goals=

Functional design goals:

* Support deployment of multiple devices of the same kind, without having to change the configuration in multiple files
* Simply add standard-capabilities like measuring temperature or switching a relay to a device
* Provide status information for debugging and operations, without consuming too much memory and processing time

Architectural design goals:

* Have MQTT interface with TCP, not with the ESP8266
* Use streaming instead of a chain of buffers, as buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns)
* I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment. Without compromising speed and memory consumption.

Hardware design goals:

* As little wiring as possible, as wiring is tiring after when assembling multiple devices

[[The AME Stack]]

The AME Stack

2018-06-19T09:24:43Z

Ctreber:

[[IoT with AME|Home]]

=The AME Stack=

* [[AME_Goals|Design Goals]]

===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.

==Status Information and Logging==

Since a whole bunch of components are working together things can get tough when there is a problem.

The AME stack provides logging via I2C and status information via a RGB-LED.

Logging can be switched off in production

* at build time by simply not compiling it in at all (thus saving space as well) or
* at runtime via switching an I/O pin on or off on Arduino reset

The status LED is programmable and consumes only one Arduino pin. It is able to provide quite a bit of useful information!

* Regarding the WLAN connection:
** Description to be done (no connection/ trying/ connected)
* Regarding the TCP connection:
** Description to be done (no connection/ trying/ connected)
* When the MQTT connection is in place
** The LED twitches every second, indicating the Arduino is running and not stuck in an endless loop
** Every time a message is sent, it flashes in blue, indicating the attempt is being made
** Every time a message is received, it flashes in ???, indicating a message has been received (the broker did sent it our way)
** Every time a ping response is received, it changes color (either green or magenta), indicating pings are being sent ''and'' received (the broker replied)

[[IoT with AME|Home]]
__NOTOC__

AME Goals

2018-06-19T09:24:39Z

Ctreber: Created page with "The AME Stack Functional design goals: * Support deployment of multiple devices of the same kind, without having to change the configuration in multiple files * Simply a..."

[[The AME Stack]]

Functional design goals:

* Support deployment of multiple devices of the same kind, without having to change the configuration in multiple files
* Simply add standard-capabilities like measuring temperature or switching a relay to a device
* Provide status information for debugging and operations, without consuming too much memory and processing time

Architectural design goals:

* Have MQTT interface with TCP, not with the ESP8266
* Use streaming instead of a chain of buffers, as buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns)
* I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment. Without compromising speed and memory consumption.

Hardware design goals:

* As little wiring as possible, as wiring is tiring after when assembling multiple devices

[[The AME Stack]]

The AME Stack

2018-06-19T09:14:31Z

Ctreber:

[[IoT with AME|Home]]

=The AME Stack=

Functional design goals:

* Support deployment of multiple devices of the same kind, without having to change the configuration in multiple files
* Simply add standard-capabilities like measuring temperature or switching a relay to a device
* Provide status information for debugging and operations, without consuming too much memory and processing time

Architectural design goals:

* Have MQTT interface with TCP, not with the ESP8266
* Use streaming instead of a chain of buffers, as buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns)
* I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment. Without compromising speed and memory consumption.

Hardware design goals:

* As little wiring as possible, as wiring is tiring after when assembling multiple devices

And thus generation 3 of my MQTT stack was born (and it is still growing up).

===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.

==Status Information and Logging==

Since a whole bunch of components are working together things can get tough when there is a problem.

The AME stack provides logging via I2C and status information via a RGB-LED.

Logging can be switched off in production

* at build time by simply not compiling it in at all (thus saving space as well) or
* at runtime via switching an I/O pin on or off on Arduino reset

The status LED is programmable and consumes only one Arduino pin. It is able to provide quite a bit of useful information!

* Regarding the WLAN connection:
** Description to be done (no connection/ trying/ connected)
* Regarding the TCP connection:
** Description to be done (no connection/ trying/ connected)
* When the MQTT connection is in place
** The LED twitches every second, indicating the Arduino is running and not stuck in an endless loop
** Every time a message is sent, it flashes in blue, indicating the attempt is being made
** Every time a message is received, it flashes in ???, indicating a message has been received (the broker did sent it our way)
** Every time a ping response is received, it changes color (either green or magenta), indicating pings are being sent ''and'' received (the broker replied)

[[IoT with AME|Home]]
__NOTOC__

The AME Stack

2018-06-19T09:00:35Z

Ctreber:

=The AME Stack=

Functional design goals:

* Support deployment of multiple devices of the same kind, without having to change the configuration in multiple files
* Simply add standard-capabilities like measuring temperature or switching a relay to a device
* Provide status information for debugging and operations, without consuming too much memory and processing time

Architectural design goals:

* Have MQTT interface with TCP, not with the ESP8266
* Use streaming instead of a chain of buffers, as buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns)
* I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment. Without compromising speed and memory consumption.

Hardware design goals:

* As little wiring as possible, as wiring is tiring after when assembling multiple devices

And thus generation 3 of my MQTT stack was born (and it is still growing up).

===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.

==Status Information and Logging==

Since a whole bunch of components are working together things can get tough when there is a problem.

The AME stack provides logging via I2C and status information via a RGB-LED.

Logging can be switched off in production

* at build time by simply not compiling it in at all (thus saving space as well) or
* at runtime via switching an I/O pin on or off on Arduino reset

The status LED is programmable and consumes only one Arduino pin. It is able to provide quite a bit of useful information!

* Regarding the WLAN connection:
** Description to be done (no connection/ trying/ connected)
* Regarding the TCP connection:
** Description to be done (no connection/ trying/ connected)
* When the MQTT connection is in place
** The LED twitches every second, indicating the Arduino is running and not stuck in an endless loop
** Every time a message is sent, it flashes in blue, indicating the attempt is being made
** Every time a message is received, it flashes in ???, indicating a message has been received (the broker did sent it our way)
** Every time a ping response is received, it changes color (either green or magenta), indicating pings are being sent ''and'' received (the broker replied)

__NOTOC__

The AME Stack

2018-06-18T09:02:27Z

Ctreber: /* The AME Stack */

Software Stack

2018-06-18T08:33:15Z

Ctreber: /* Software for Building IoT Devices */

The AME Stack

2018-06-18T08:31:52Z

Ctreber: Created page with " =The AME Stack== I found that I wanted to deploy multiple devices of the same kind, but without having to change the configuration in multiple files. And I would like to sim..."

=The AME Stack==

I found that I wanted to deploy multiple devices of the same kind, but without having to change the configuration in multiple files. And I would like to simply plug in capabilities like measuring temperature or switching a relay. From an architectural standpoint, I prefer MQTT to interface with TCP, not with the ESP8266. As buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns), streaming is the preferred mode of data exchange. I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment.

And thus generation 3 of my MQTT stack was born (and it is still growing up).

===AC_ESP8266===

AC_ESP8266 provides access to the ESP8266 on C++ level, no more, no less. It uses two (blowing my own horn) pretty clever functions to compose commands and to parse responses based on pattern expansion/ matching. The buffer used for commands and responses is the only one in the whole class, as writing and reading IP data is performed streaming. Callbacks announce the arrival of data and loss of connection.

===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 and 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 (or more honestly "0.5" as ACKs message from the broker properly, but arriving ACKs are discarded and missing ACKs dont' 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===

AC_IoT provides convenience on device level with concepts such as centrally setting a device name and an MQTT-ID that get used wherever appropriate. In example, a device with MQTT-ID "garden01" uses "garden" as a prefix for topics in publications and subscriptions.

===Devices===

Devices report the version of the IoT framework, their own version, IP and MAC address, and number of connect attempts when the MQTT connection is established. In example, the messages

* "garden/versionIoT 1.038"
* "garden/version 1.010"
* "garden/connectAttempts 12"
* "garden/ip 192.168.2.76"
* "garden/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, posses 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 produces 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 topic "garden/pressure01/pressure" and "garden/pressure01/temperature".

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

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

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

Software Stack

2018-06-15T18:09:40Z

Ctreber:

[[IoT with AME|Home]]

=Software for Building IoT Devices=

==Generation 1: PubSubClient, ESP8266Client, ITEADLIB Arduino WeeESP8266==

This is the stack I used first, and for quite some time:

* MQTT client: PubSubClient. Regarding the data connection it is based on the standard Arduino Client interface.
* Client: ESP8266Client: This is a library I wrote that provides a Client facade to the ITEADLIB Arduino WeeESP8266 lib. It deals with ESP8266 misbehavior that can't be handled on the ESP8266 level itself (like, lost TCP or WLAN connectivity).
* ESP8266: ITEADLIB Arduino WeeESP8266. This library is quite voluminous (in example, because of the use of String) and has a few small bugs

==Generation 2: AC_MQTT & AC_ESP8266==

After dealing with various problems and repairing and optimizing things to a degree I finally did what all programmers must do at some point: rewrite the whole damn thing :-)

* MQTT client: AC_MQTT. Compact and easy to understand code implementing MQTT operation for QoS levels 0 and 1. Does not reserve buffers and performs only streaming read and write operations.
* "Client": AC_ESP8266Client. This is NOT the Arduino standard Client interface, but a tighter integration between AC_MQTT and AC_ESP8266. While it would have been nice to stick to the Arduino Client interface I found this requires too much of a compromise in terms of excessive memory use and type of access ("Client" is rather serial while the ESP8266 expects reading and writing buffers). It deals with all kinds of problems like WLAN and TCP connection troubles and general ESP8266 misbehavior. Depending on the hardware provided it can even hardware-reset or power-cycle the ESP8266 if necessary. It can even power-cycle a router if so required (yes, sometimes a mobile Internet router deserves and profits from a kick).
* ESP8266: AC_ESP8266. The library only provides access to ESP functions that are needed for MQTT communications. The code is pretty compact as it does not reserve buffers on its own (though it relies on buffers provided by clients). It provides a callback interface in case some data arrived over an IP connection (no need to poll).

My stack does quite a bit more than the stack above regarding error handling, and it does so with less flash and SRAM memory usage while IMHO being more readable at the same time.

==Generation 3: AC_IoT, AC_MQTT, AC_TCP_ESP8266, AC_ESP8266==

And while the generation 2 solution was not bad per se I wanted more. I found that I wanted to deploy multiple devices of the same kind, but without having to change the configuration in multiple files. And I would like to simply plug in capabilities like measuring temperature or switching a relay. From an architectural standpoint, I prefer MQTT to interface with TCP, not with the ESP8266. As buffers are limited and awkward to handle (make them too big and memory is gone; make them too small and you'll get overruns), streaming is the preferred mode of data exchange. I want my code to be readable by humans. And, yes, this can be done. Even in the limited Arduino environment.

And thus generation 3 of my MQTT stack was born (and it is still growing up).

===AC_ESP8266===

AC_ESP8266 provides access to the ESP8266 on C++ level, no more, no less. It uses two (blowing my own horn) pretty clever functions to compose commands and to parse responses based on pattern expansion/ matching. The buffer used for commands and responses is the only one in the whole class, as writing and reading IP data is performed streaming. Callbacks announce the arrival of data and loss of connection.

===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 and 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 (or more honestly "0.5" as ACKs message from the broker properly, but arriving ACKs are discarded and missing ACKs dont' 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===

AC_IoT provides convenience on device level with concepts such as centrally setting a device name and an MQTT-ID that get used wherever appropriate. In example, a device with MQTT-ID "garden01" uses "garden" as a prefix for topics in publications and subscriptions.

===Devices===

Devices report the version of the IoT framework, their own version, IP and MAC address, and number of connect attempts when the MQTT connection is established. In example, the messages

* "garden/versionIoT 1.038"
* "garden/version 1.010"
* "garden/connectAttempts 12"
* "garden/ip 192.168.2.76"
* "garden/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, posses 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 produces 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 topic "garden/pressure01/pressure" and "garden/pressure01/temperature".

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

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

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

[[IoT with AME|Home]]
__NOTOC__

Challenges

2018-06-15T17:15:16Z

Ctreber:

[[IoT with AME|Home]]

=Challenges - How to Overcome Hardware and Software Limitations=

The Arduino hardware is very powerful in the sense of provided functionality and bang for the buck. But, resources are pretty limited.

You get

* 32kB of unmodifiable (at run-time) flash memory for the program
* 2kB of volatile SRAM memory for variables, and
* 1kB runtime-programmable, non-volatile EEPROM memory for data

That's it. Pretty much any icon on your Linux, Apple, or Windows desktop is bigger then the Arduino flash memory. This is a challenge already at compile time. It gets potentially worse at run time: Processing network data requires buffers, and buffer sizes may be variable.

==Configuration==

Another thing is modifiable configuration (in example, WLAN credentials). If you want do to that without re-programming the chip, you need to use an interface of some kind (wireless, SPI/ I2C, or an SD card).

==Updating the Firmware (OTA or Over the Air)==

The Arduino itself does not provide a means to update its flash memory without some external help. But the ESP8266 or another Arduino (€2.50 from China) could do that.

[[IoT with AME|Home]]

Software Stack

2018-06-15T17:09:17Z

Ctreber:

IoT Management

2018-06-15T17:05:46Z

Ctreber:

[[IoT with AME|Home]]

=IoT Management - How to Manage an Installation=

Something that I noticed (even) at home: Once you deployed a number of IoT devices, you'll notice some things need addressing that haven't crossed your mind before:

* How do I know a device has a problem?
* What devices are actually deployed? Where?
* What software versions are in use (IoT framework, devices, capabilities)?
* What topics are in use? Who is publishing, who is subscribing? What topics are being published and subscribed to? What are the latest messages?
* How do I secure the whole thing? Currently I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)

I came up with the following ingredients to the solution

* [[Tools]] to monitor what is going on in the network
* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices

==Operational Status==

All my devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.

==Network==

Similarly, my devices report their IP and MAC addresses. Once devices are able to connect to more than one WLAN, they should report the SSID in use as well. This helps setting up routers, firewalls, and the like.

Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.

==Software==

My devices report the software version of

* the IoT framework
* the device (like, "gardener")
* each capability (like, "watering", "temperature")

This allows me to find devices which need to be, or could be updated.

REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino. Or two Arduinos (€2.50 from China) flash each other. Hmmm...

==Location==

With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?). It would be nice to save the location as part of the configuration, and have the device report on it on request or when rebooting.

[[IoT with AME|Home]]

__NOTOC__

IoT Management

2018-06-15T13:00:09Z

Ctreber:

[[IoT with AME|Home]]

=IoT Management - How to Manage an Installation=

Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions arise:

* Does a device have a problem?
* What devices are actually deployed? Where?
* What software versions are in use (devices, IoT framework, capabilities)?
* What topics are in use? Who is publishing, who is subscribing? What is being published? How often?
* Security - currently I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)

Ingredients to the solution are

* [[Tools]] to monitor what is going on in the network
* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices

==Operational Status==

All my devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.

==Network==

Similarly, my devices report their IP and MAC addresses. Once devices are able to connect to more than one WLAN, they should report the SSID in use as well. This helps setting up routers, firewalls, and the like.

Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.

==Software==

My devices report the software version of

* the device (like, "gardener")
* each capability (like, "watering", "temperature")
* the underlying IoT framework

This allows me to find devices which need to be, or could be updated.

REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino - hmmm...

==Location==

With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).

[[IoT with AME|Home]]

__NOTOC__

IoT Management

2018-06-15T12:59:10Z

Ctreber: Ctreber moved page Management to IoT Management without leaving a redirect

[[IoT with AME|Home]]

=Management - How to manage an IoT installation=

Something that I noticed (even) at home: Once you deployed a number of IoT devices, some questions arise:

* Does a device have a problem?
* What devices are actually deployed?
* What software versions are in use (devices, IoT framework, capabilities)?
* What topics are in use? Who is publishing, who is subscribing? What is being published? How often?
* Security - currently I rely on the privacy of my WLAN, but I guess message exchange via SSL would be "really nice" (and require a reworking of my infrastructure)

Ingredients to the solution are

* [[Tools]] to monitor what is going on in the network
* [[Naming and Behavioral Conventions]] that allow for systematic collection and analysis of data, and for controlling devices

==Operational Status==

All my devices are reporting their status under topic "<mqttID>/status". Subscribing to "+/status" gives me an overview about what devices are deployed, and how they are doing connection-wise.

Sometime devices even don't connect or experience other hangups. My devices use a self-developed logging facility called "Logsury" that, among others things, is able to output logging information via I2C. When I connect my programmer to a device I get logging output displayed on a LCD (note to self: extend to main connector to include A4 and A5; there are enough free pins to use). Of course, any other device capable of receiving I2C transmissions can display that information.

==Network==

Similarly, my devices report their IP and MAC addresses. Once devices are able to connect to more than one WLAN, they should report the SSID in use as well. This helps setting up routers, firewalls, and the like.

Additionally, I use a programmable RGB LED to display the (predominantly network) status of the device in a directly observable fashion. I get information about connecting to the WLAN, connecting to the MQTT broker, pings sent and received, and publications send and received. This actually has often helped me to pin-point troubles.

==Software==

My devices report the software version of

* the device (like, "gardener")
* each capability (like, "watering", "temperature")
* the underlying IoT framework

This allows me to find devices which need to be, or could be updated.

REM The Arduino/ ESP8266 combination I use does NOT allow for over the air updates. But, all devices have a plug that allows for in-place SPI programming. REM On a second thought - the Arduino could download the update to the ESP, and then the ESP flashes the Arduino - hmmm...

==Location==

With enough devices deployed, the MQTT-ID may or may not tell you enough to find out where the device is physically located (maybe it even moves?).

[[IoT with AME|Home]]

__NOTOC__

IoT with AME

2018-06-15T12:58:45Z

Ctreber:

=IoT with AME - The Internet of Things, with Arduino, MQTT, and ESP8266=

[[File:20170802T115833.jpg|thumb|left|300px|Voltage controller (left), status LED (RGB; top), Arduino (top right), ESP8266 (bottom right, on adapter) - My standard hardware stack]] This is work in progress started in June 2017 - I am in the process of typing out my experiences with IoT, Arduino, and ESP8266, as a documentation for myself and as something that might be helpful to others.

* [[My IoT projects]] - What I built over time (plenty!)
* [[MQTT]] - A protocol for connecting IoT devices
* [[Software Stack|Software]]: Libraries for devices and capabilities, and access on MQTT-, TCP-, WLAN-, and chip level
* [[Software Problems]]: C++ and very small memory pose diverse challenges
* [[Hardware Stack|Hardware]]: Arduino, ESP8266, and additional hardware
* [[Hardware Problems]]: Bugs are not limited to software - plain electricity can be tricky, too!
* [[Challenges]] - How to overcome hardware and software limitations
* [[IoT Management]] - How to manage an IoT installation
* [[To Do]] - What I would like to improve and add in this Wiki

 Note to self (help on MediaWiki):

* https://www.mediawiki.org/wiki/Manual:FAQ
* https://en.wikipedia.org/wiki/Help:Wiki_markup

Challenges

2018-06-15T12:58:16Z

Ctreber:

[[IoT with AME|Home]]

=Challenges - How to Overcome Hardware and Software Limitations=

The Arduino hardware is pretty limited - you get

* 32kB of unmodifiable (at run-time) flash memory for the program
* 2kB of volatile SRAM memory for variables, and
* 1kB runtime-programmable, non-volatile EEPROM memory for data

That's it. Pretty much any icon on your Linux, Apple, or Windows desktop consumes more space.

This is a challenge to your software you already have to address at compile time. It gets potentially worse at run time. Processing network data requires buffers, and buffer sizes may be variable. During operations you may want to change the configuration of the device. If you want do to that without re-programming the chip, you need to use an interface of some kind (wireless, SPI/ I2C, or SD card).

* Updating device configuration (ie, MQTT/ WLAN) - ideas: via SD Card (which is enduser-friendly) or via writing config data to EEPROM
* Updating device code - via ISP, or - ideas - OTA with the Arduino uploading a program to the ESP, followed by the ESP flashing the Arduino

[[IoT with AME|Home]]

Flaky ESP8266 Behavior

2018-06-15T12:49:13Z

Ctreber:

[[Hardware Problems]]

=Flaky ESP8266 Behavior=

The EP8266 is great: It gives your IoT device WLAN and IP connectivity for only a few bucks.

On the other hand, the ESP8266 is quite a hand full: It creates power spikes that have negative impact on its own operation and possibly that of your entire circuit, it experiences out-of-the-blue resets that have to be dealt with, and it suffers hang-ups that can only be cured with a hardware reset or uttering "The IT Crowd" mantra ("have you tried turning it off and on again"; https://www.youtube.com/watch?v=nn2FB1P_Mn8).

I have had A LOT of trouble with the ESP8266 before I had a lot of fun. Some problems can be solved with a proper power supply, a bit of hardware, and somewhat sophisticated error handling. Other, more persistent problems can only be addressed with resetting the chip or even cycling its power supply.

My Arduino library uses three levels of measures to straighten out the balking chip:

* Soft-reset, by issuing a "restart" command to the ESP
* Hard-reset, by connecting an Arduino digital port pin to the reset pin of the ESP. This just requires a piece of cable. And an IO pin.
* "Turn if off and on again", by connecting an Arduino digital port pin to a transistor that controls the ESP power supply. That requires a transistor and minor wiring. And another IO pin.

You can't do more without modifying the ESP8266 firmware. Wait, you can: check out [[Sufficient_power-supply|Sufficient Power Supply]] regarding power spikes.

[[Hardware Problems]]

Software Problems

2018-06-15T12:48:06Z

Ctreber:

Software Problems

2018-06-15T12:47:54Z

Ctreber:

[[IoT with AME|Home]]

=Embedded Software Problems=

C++ and very small memory pose diverse challenges. The Arduino runtime environment has its intricacies as well.

And then there is other people's software you may not have access to, such as firmware in components. Yes, ESP8266, I'm looking at you! The EP8266 is great: It gives your IoT device WLAN and IP connectivity for only a few bucks.

On the other hand, the ESP8266 is quite a hand full: It creates power spikes that have negative impact on its own operation and possibly that of your entire circuit, it experiences out-of-the-blue resets that have to be dealt with, and it suffers hang-ups that can only be cured with a hardware reset or uttering "The IT Crowd" mantra ("have you tried turning it off and on again"; https://www.youtube.com/watch?v=nn2FB1P_Mn8).

I have had A LOT of trouble with the ESP8266 before I had a lot of fun. Some problems can be solved with a proper power supply, a bit of hardware, and somewhat sophisticated error handling. Other, more persistent problems can only be addressed with resetting the chip or even cycling its power supply.

* [[C++ is not Java]] - C++ can be harsh for people used to Java. Especially memory handling holds a number of surprises.
* [[Memory Usage]] - The Arduino is small and powerful - and it all needs to fit in 32kB of flash and 2kB of RAM.
* [[SoftwareSerial]] - Sounds great, causes frustration. Emulation thing that need to happen fast has limits.
* [[Flaky ESP8266 Behavior]] - It's not always you, sometime the ESP8266 has it's own mind

[[IoT with AME|Home]]
__NOTOC__

Hardware Problems

2018-06-15T12:46:31Z

Ctreber:

[[IoT with AME|Home]]

=Embedded Hardware Problems=

Bugs are not limited to software - plain electricity can be tricky, too! Sometimes it even kills (and I'm referring to Arduinos here).

* [[Sufficient power-supply]] - Some chips suck (power)
* [[Staying well-grounded]] - Why not everybody can have their own GND (ground)
* Fun with [[pitfalls-power lan|power LAN]] adapters (don't plug your fridge into one)

[[IoT with AME|Home]]

Software Problems

2018-06-15T12:43:13Z

Ctreber: /* Software Problems */

[[IoT with AME|Home]]

=Embedded Software Problems=

C++ and very small memory pose diverse challenges. The Arduino runtime environment has its intricacies as well.

* [[C++ is not Java]] - C++ can be harsh for people used to Java. Especially memory handling holds a number of surprises.
* [[Memory Usage]] - The Arduino is small and powerful - and it all needs to fit in 32kB of flash and 2kB of RAM.
* [[SoftwareSerial]] - Sounds great, causes frustration. Emulation thing that need to happen fast has limits.

[[IoT with AME|Home]]
__NOTOC__

Hardware Stack

2018-06-15T12:42:44Z

Ctreber:

[[IoT with AME|Home]]

=Hardware for Building IoT Devices=

Arduino, ESP8266, and additional Hardware. I have a number of pages on this in German - some work to do.

* [[How to flash the ESP8266]] with new firmware - easy hardware setup, awkward toolkit usage. Is it worth it? Not sure; I get along pretty well with my old and new FW versions. On the con side, I managed to fry one chip while trying to program it.

[[IoT with AME|Home]]
__NOTOC__

Software Problems

2018-06-15T12:42:00Z

Ctreber:

[[IoT with AME|Home]]

=Software Problems=

C++ and very small memory pose diverse challenges. The Arduino runtime environment has its intricacies as well.

* [[C++ is not Java]] - C++ can be harsh for people used to Java. Especially memory handling holds a number of surprises.
* [[Memory Usage]] - The Arduino is small and powerful - and it all needs to fit in 32kB of flash and 2kB of RAM.
* [[SoftwareSerial]] - Sounds great, causes frustration. Emulation thing that need to happen fast has limits.

[[IoT with AME|Home]]
__NOTOC__

IoT with AME

2018-06-15T12:40:08Z

Ctreber: /* IoT with AME - The Internet of Things, with Arduino, MQTT, and ESP8266 */

=IoT with AME - The Internet of Things, with Arduino, MQTT, and ESP8266=

[[File:20170802T115833.jpg|thumb|left|300px|Voltage controller (left), status LED (RGB; top), Arduino (top right), ESP8266 (bottom right, on adapter) - My standard hardware stack]] This is work in progress started in June 2017 - I am in the process of typing out my experiences with IoT, Arduino, and ESP8266, as a documentation for myself and as something that might be helpful to others.

* [[My IoT projects]] - What I built over time (plenty!)
* [[MQTT]] - A protocol for connecting IoT devices
* [[Software Stack|Software]]: Libraries for devices and capabilities, and access on MQTT-, TCP-, WLAN-, and chip level
* [[Software Problems]]: C++ and very small memory pose diverse challenges
* [[Hardware Stack|Hardware]]: Arduino, ESP8266, and additional hardware
* [[Hardware Problems]]: Bugs are not limited to software - plain electricity can be tricky, too!
* [[Challenges]] - How to overcome hardware and software limitations
* [[Management]] - How to manage an IoT installation
* [[To Do]] - What I would like to improve and add in this Wiki

 Note to self (help on MediaWiki):

* https://www.mediawiki.org/wiki/Manual:FAQ
* https://en.wikipedia.org/wiki/Help:Wiki_markup