Add Visible Error Reporting on Pico.

[Keegan-Evans]

The general idea here is to implement some way to provide convenient external status/error reporting for individual Pico sensor devices, so that at least basic troubleshooting can be done without any external computing hardware.

Current State Regarding Error Reporting

As of October 2023, the only validation that a pico running a sensor and reporting data to the hub gives, is that if it is successfully publishing a message, then when a reading is taken and the data published to sensor hub, then the light will flash. This is not even getting confirmation from the broker that the message is being logged, but simply that the pico is connected to the hosted network provided by Sensor Hub, that the MQTT client on the Pico can "see" the broker, and that a message packet containing the data has been pushed onto to the network, headed towards the broker.

There is no verification that the message is received by the broker or that the message has successfully been written to the database by the Sensor Hub side MQTT client. MQTT's own packet delivery confirmation/Quality Of Service (QOS) protocol could be used to confirm the success receipt of the message packet by the broker. If different error reporting for things like an error encountered while writing the data to the server are desired, changes to push a packet back to the Pico on the part of the Sensor-Hub side MQTT client would be required, as well as adding a new method that would listen for and log these messages to the self.status attribute of the sensor class would be required.

Project Goals

Avoiding these previously mentioned rabbit-holes, the aim of this issue is to design and implement some system so that when the sensors are being deployed in the field, that the installer can quickly verify that the device is performing correctly, and if it is not, to be able to understand the issue that is being encountered without having to bring a laptop or other piece of hardware into the field to troubleshoot.

Project Components

There will be at-least two parts of this project, the hardware side of things and the software.

The current design of the software should make it reasonably straightforward to implement at least the reporting portion of the software design, by simply examining and reporting the most recent message in the self.status attribute of the sensor class, which already is designed to capture each change in status for the pico.

The bulk of this work will be designing the actual physical method of reporting and whatever driver code is necessary to get it running on the Pico.

Possible Implementations

• Seven Segment Displays: My current thinking is to report a standardized set of status codes on a dual array of 7 segment displays, with the first digit representing some general category of status and the second reporting the exact code. The advantage here is that currently this would very tersely express very specific issues. A downside is that the system is either limited to 16 status codes per category(though the letter codes could expand beyond typical hex-representations), while this is adequate now, it could ultimately prove to be too few, requiring either(backwards compatibility breaking) addition of more digit places for the messages to be displayed on(also requires more hardware/new hardware design to add the new digit) or the creation of more general error messages that could prove to be more ambiguous in their reporting of errors. An additional downside would be the requirement for either the employment of a lookup sheet or the memorization of the sheet.

• LEDs: This could look like either individual LEDs for specific error messages(IE, Unable to Detect WIFI network), or one LED for a specific category of error, this could be further expanded by using multicolor LEDs and lighting the LED for a specific category based on the status of things related to that category(for the network, if a connection was established and strong, the LED could be lit with a green light, if it was in process of establishing a connection yellow, and if there was a failure connecting red). An advantage of this approach would be providing fast reporting of common issues and the ability to observe statuses from a distance. Disadvantages include higher battery consumption, limited bandwidth in terms of the messages that could be displayed, additional hardware complexity/weatherproofing concerns.

• OLED, LCD, E-Ink, or other screen: advantages: direct display arbitrary/highly specific error messages, adds additional interface for other purposes on device. Disadvantages: cost, hardware complexity, weatherproofness, energy(battery!) consumption, size, complexity of software implementation.