Hello Paul, apologies for the delay with this. Reading through the above again here is my attempt at summarising the key items raised for our ongoing reference.
- Establish our approach: interfacers, reporters or reporter-like interfacers
- Establish our approach: seperate interfacer files vs core interfacer file.
- Review EmonHub internal message queue implementation
- Consider process chain, standardise on correct approach for use of run, read, send, action, add, flush, process_post.
- Consider interfacer naming
- Buffer persistance: Option to save or load a buffer from disk?
- Review rx & tx node definition in emonhub.conf used by emon-pi variant
- Document and explain distinction between QoS1/QoS2 unbuffered/buffered interfacers/reporters.
- Document further use of socket interfacer
- Consider backwards compatibility when switching from reporters to interfacers or vice versa.
- MQTT: What should the format of the generic MQTT Interfacer be?
- MQTT: Specific format MQTT Interfacers can re-use the generic interfacer
- MQTT: Keep a per-topic MQTT Interfacer QoS1 unbuffered
- MQTT: how do we handle on_message case
- MQTT: Implement a bulk mode, buffered QoS2 MQTT reporter-like interfacer
- MQTT: Pass MQTT data through emonhub from ESP devices
- EmonHub HTTP interfacer that can call the emoncms fetch api to retrieve data into emonhub
- Emoncms changes: Implement the input/post and input/bulk formats in MQTT, perhaps extend to other api’s e.g fetch.
- Emoncms changes: option to have indexed inputs, and seperate sending of inputnames.
- Emoncms changes: support multiple emoncms accounts from the mqtt_input script.
- Emoncms: review timestamp processing
- Review threaded exception handling
- Review error handling in core interfacers
- systemd service unit
- simultaneous tx of settings resulting in potential serial crash
- Review list and single word settings in emon-pi variant