AQ Firmware Data String Issue and Device Status Update Option

[augustinemwendwa72]

AQ FIRMWARE ENHANCEMENTS

1. Join data strings to 1 main string and send to the API as a single string.
   a. We are currently sending each data string separately.
   b. There are cases where 1 data string is sent successfully while the rest of them fail.
   c. Current firmware does not resend the data on a failed attempt.
   I suggest combining all data strings into one main string based on the number of sensors set to active.

2. There are cases where sensors fail to communicate with the MCU, in such cases we can send the sensor status (Error Log)

3. Also, I suggest we add an extra variable on the server side to record sensor device status. Alternatively, provide an option to record if a sensor is active over a specific period.

4. Lastly, we can have a dedicated channel on Slack to track sensor status or related parameters, necessary for sensor performance tracking.

[gideonmaina]

Hi @augustinemwendwa72 You are referencing an unrelated issue in the heading.

1. I totally agree with sending an array of data from multiple sensors all at once.
   This happens when sending to the Django API because we pass a X-PIN header when posting data to denote the type of sensor.
   This means the data for each type of sensor must be sent one after the other. I will investigate how this is done on other backends such as Influx.

2. Error logging in my opinion is feasible when implementing an external SD storage due to memory constraints. If this is at the point of reading sensor data, then the errors can be sent to an endpoint that monitors errors.

3. We have a Slack channel dedicated to monitoring

[augustinemwendwa72]

• @gideonmaina does that mean that with the current API setup, we are not able to concatenate the strings with all the X-PIN's defined for all the sensors and send that as a single string?

• With the current AQ Board, I guess we can still utilize the available Flash memory and see how that pans out. We still have plenty of that.

• Concerning the title, which one would you suggest? I can still edit it.

[gideonmaina]

Aah I see you have already removed the issue ref #1

Concatenation of the data string is possible but it would not make sense with the current setup. The PIN header defines the sensor data schema. Any update on how we send data will be a breaking change unless a new version of the API is made.

On saving the error log in flash memory, we need to be considerate about the number of write operations. E.g for a mobile sensor with a low sampling rate, the life span of the memory will be much lower if a sensor is not connected for a very long time.

[gideonmaina]

Related to suggestion number 3. I am exploring the advantages of using MQTT to show the device status since it relies on a persistent TCP connection.