Notes On Firmware

The sensor configuration is stored in parallel global arrays called "sensorName[]" and "activateCode[]". The ordinal number "n" in each array defines what the firmware does with sensor trips that match the activateCode[n]. The name that is published when the log is read out is whatever is the string in sensorName[n]. What we call the "configuration" is the contents of these arrays plus information about the locale (timezone and observe DST and buffer size, and number of sensors supported). At some point we will move this into a single array of a struct.

The EEPROM is used to persist the configuration through resets and power outages, since the RAM is volatile but the EEPROM is not. So in setup(), we check to see if the first part of the EEPROM is a particular unique string (currently SIS-2015) and if it is not, we assume that the EEPROM has no valid information and so we default the configuration values. After setting or changing configuration values (typically via the Client), the new configuration is stored in the EEPROM so that it is retained in the Photon.

The Client does not maintain the configuration data. The Client just writes configuration information to the Photon via the function the Hub exposes: Spark.function("Register", registrar). Note that the function "registrar()" accepts a string argument that contains registration related commands such as "register" (to register a sensor code and sensor name string in the parallel arrays), "read" (to read out a sensor trip code and sensor string name from the parallel arrays), "delete" to reset a sensor trip code and sensor name string in the parallel arrays to the default value, and "store". The "store" command writes the configuration data -- all of it -- to the EEPROM (prepending the SIS-2015 identifying string). You might want to look through the source code for this firmware function (registrar()). The details are documented in comments at the top of the function. This function in the firmware might better be called "command"; maybe we'll change it some day.

The function readBuffer() in the Photon firmware is what takes the contents of the internal Photon circular buffer and formats it into the strings that you see at the client (that you referenced in your e-mail). This function, and its helper readFromBuffer() function, are what would be changed to read out a json or xml formatted string. The buffer itself contains numerical codes for each logged event/inference and the timestamp in epoch (integer, not string) format. This is to keep the buffer entries small, since Photon RAM is limited and we wanted to log 100 entries on the Photon. And note that we do not use the EEPROM for writing the buffer. This would be nice, to keep the buffer non-volatile, but EEPROM is far too slow for our purposes (and wears out with writes over time as well).