PiBox » Iron Man

Here is a discussion on using multicast with the ESP8266.

There should be a function that handles sending multicast packets. It tests for a flag. If the flag is not set, send the packet. If it is then skip it. The flag is set by the response from the PiBox server.

The sendRegistration() function does this:

  Serial.println("Sending UDP multicast packet");
  // send a reply, to the IP address and port that sent us the packet we received
  Udp.beginPacketMulticast(ipMulti, portMulti, WiFi.localIP());
  Udp.write(byte1);
  Udp.write(byte2);
  Udp.print(ESP.getChipId(), HEX);
  Udp.print(":");
  Udp.print(WiFi.localIP());
  Udp.endPacket();

It seems likely that the response will include a UUID for the device node but the registration won't need anything like that. It should probably send one or more bytes, with the bytes being bit fields for device type and version values. A third byte may be used for encryption info, perhaps.

There are good examples of using Multicast in C programs for both client and server on the web.

I just realized that device registration needs to survive a power cycle. Since PiBox is not depending on cloud-based data storage, this means a local-storage-based database has to be used. Both MySQL and sqlist are enabled in PiBox. This use-case doesn't need the power of MySQL. Even sqlite could be overkill.

A simpler solution would be to use an abstract block of name/value pairs. This could easily be done in JSON using the parson library. Data is added/removed/etc from the data block and the data block as a whole is saved to disk using a double-buffer mechanism (write to new file, save old file, move new file to old file, remove saved file) to avoid data corruption. We will never have that much information to store - even thousands of devices wouldn't be that much data and we expire old data when devices go away.

Parson is a single C file. I use it at work for a message passing library. The library wraps Parson and exposes an API that uses namespaces for name/value pairs. The same idea works here. A namespace is a device and it contains the name/value pair of data we maintain about those devices.

I can't reuse the code from work, but since I wrote it I can recreate it from scratch. It's extremely simple in our case since we drop all the message passing stuff. We just need a simplified wrapper around parson.

The bonus will be that piboxd will then have a JSON library embedded in it for other uses. And we can use the simplified data-block API I'll add for device nodes or call parson directly. Very cool.

Integration of parson for data stores is an MVP issue. It will not be implemented for proof-of-concept. In the PoC if we lose power devices have to re-register. Note that this might be something we'd want to do in MVP - reregister a device if it hasn't heard from the server in a while. But that's a power drain on the IoT device, to keep track of when it was last contacted. It wouldn't be able to run in low-power mode (unless low-power mode supports multicast).

UPDATE: duh. Parson makes perfect sense for in-memory storage too. There's no reason to write a link list library to handle new device registrations. Parson can handle that now. So I'll integrate parson now, for the IoT registration in the PoC. That will speed implementation. I'll abstract the data block later, for MVP.

Added aJSON library and code for using JSON-formatted registration of device features for damper device. This is necessary for PoC implementation but will probably be broken into libraries later for different devices.