volca02 / hr20-esp12-master Goto Github PK

This would be usable to upload timers in one payload, list clients, get client values... Could make a nice web page using REST that would render most of the things client-side.

Render a timer table from the timers gathered via the json ajax call after pressing a dedicated icon in the client list.

RFM12 modules are getting more difficult to find.

Basing this project on a RFM69 module used in RFM12-compatible mode would be preferred.

Porting the whole OpenHR20 to RFM69 to reduce power consumption and increase range would be even better, but it involves a lot more work and it's beyond the scope of this project.

I tried to Build the project with PlatformIO.
Builf failed, many errors in webserver.cc.

Dop you have tried a build on actual Version of plaformio ?

After stabilising what should be in the JSON for the HVAC devices, add a templated discovery topic with every client as they are first discovered, and publish this after every reconnect.

https://www.home-assistant.io/docs/mqtt/discovery/

Preferably ERR macro would accept an enum and collect the errors somewhere to publish on mqtt and display on a display once one is used.

Do a bulk subscription to /prefix/# at the start (in setup()), and avoid any by-hand subscriptions later on. Simplifies the code and adds the ability to pre-set mqtt values without needing to see the client first.

This is a low priority feature, but may be a useful one. 32 bytes of plain byte array and 2 32bit integers to persist read/write state of the bytes. Custom code to sync them up. Would use G/S commands to get data to/from clients.

Should help with persistent bugs that we see - missing callback calls and invalid callback values, namely.

It is needed to wake the clients up before their low frequency reporting happens.

Might be CMAC mismatch, could be pkt_cnt mismatch too. Serial console to a client could help debugging the issue.

This way we can be sure nothing changed on the clients and can implement re-reads if it did. Combines well with #24

Especially Publishing Timers seems to sometimes cause a serious time drift, leading to CMAC inconsistencies and clients not able to send updates to the esp.

Currently there is a really lousy web interface present. JSON urls can be used for javascript code to get data from the master as needed, so the way would probably be a small html with inline css and js, doing requests for client lists/timers/error lists/... Might implement value setting later, but for now monitoring webpage is enough.

We will face time drift issues without re-syncing NTP once in a while. It should be as easy as remembering last sync time, but we should preferably do this while RFM radio is off to avoid interference. If there are no force flags in the particular minute, we can do it after :30 sync packet is sent.

Short debug responses are indication of invalid set values in case of 'A' command. Implement a on_temperature method that processes debug responses with invalid byte counts by reseting the requested temperature and issuing an error.

That would save us 1 byte of memory per value - amounting to around 512bytes per valve, or around 4k total.

We could also use the unused bits in flags for this purpose (bits 0-4 are used, bits 5-7 are not), saving another byte per value.

Json formatted topic with temperature, valve position, etc so that we get a transactional behavior for these items - usable for centralized control as that needs consistency between values.

ESP12 seems to like to freeze now if we feed to much output data to mqtt PubSubClient. It goes away if timers are not synced, but the general solution is to use a state machine and update the mqtt broker incrementally piece by piece (Not blocking the main loop for too long).

This could also open the door to a more active mqtt publishing - after triplet of client-master-client packet exchange, there usually is a window to send the updated data to broker before the next second starts. This can easily be made configurable.

Some values could be persisted in FS and read upon reboot. This would be done for changed values every few hours or so to avoid frequent rewrites. This would mean less chatter with clients for stuff like timers and similar, at the expense of possible undetected differences (topic for another change).

Add to/from converters for mqtt - temperature, voltage, time of day.

Not sure if this is HR20 bug or if there's a communication bug with the clients, but they accumulate D responses over time to higher than one (seen 6).

Add support for OTA updates.

Currently it works because we're only sending sync packets. It won't work for other ones. Simply moving cmac calc after the optional encrypt_decrypt should be enough.

The project needs a way to specify configuration - mqtt server, key values, etc. Could use wifiManager for that, it supports custom parameters

Implement smooth transition for secondary (i.e. after first succesful) NTP synchronizations. Currently the change happens so rapidly clients fall out of sync. Shortening/prolonging seconds at the span of a few minutes would resolve this. Investigate if this is possible.

Drift could also be calculated at the end of each sync, meaning some kind of drift compensation could be implemented.

Either:

• Model -> Client (force old cached values to be written again)
• Client -> Model (force re-read of the model values)

Although the client reports this value on every occasion, the model does not reflect the change. Namely wanted temperature is stuck.

Currently we don't seem to indicate well that radio chip is not connected well. Disconnecting NSEL will cause no error reports to happen for a while until the packet queue fills.

Use a different call in the NTPTime class for this, but we don't need localtime for time_t fields (especially true for event table)

Investigate if there's a way to inform HR20 that we no longer need it to be spammy - could save it's battery.

main.cc is crowded as a friday midnight bus station. Splitting it to a separate pieces is prefferable. Reformatting with the included .clang-format is a good simultaneous step.

Should be used to only publish values that changed - publish will knock it up, setting new value will knock it down. Should limit the publishes to just the changed values.

We have limited RAM situation, so currently we only support 4 time table entries a day. We could support 8 if we implemented an allocator for clients in model class and limit their count to some lower number than 32 (heck 16 is probably overkill for most households).

Web server could/should expose /errors URL with list of last few errors in the system, mqtt could/should publish any error that happened (something like /hr20/status/last_error).

Sometimes, the callback is not called after publishing a value to one of the settable topics.

Hopefully the transition to arduino-mqtt #32 solves this, if not, will have to diagnose more.

MQTT interface is the next logical step:

Topic base path should be:
/prefix/addr/*

with fixed but customizable prefix (compile time).

Topics:

• temp
• temp_wtd
• battery
• mode
• timers/*

Timers then should probably be timers/day/slot/... - need feedback here.

Clashes with SPI.h's dislike for interrupts. Needs reworked state handling. Just the low level byte read/write handling should be handled there, not blocking the interrupts for long.

We need a button to reset configuration and bring board back to AP mode. This enables reconfiguration.
Reset button should have these two modes:

1. short press (2s) resets WiFi only
2. long press (10s) resets WiFi and set default configuration

Similary to #23, there could/should be an event log of last N events happening on the master (sort of a space constrained low profile debug log, listing received/sent messages to clients, MQTT activity, etc).

prologue should contain target address for non-sync packets - enlarge it to 6 bytes, add the address there for non-sync packets, and add 1 to length in that case.

Currently the ESP master halts to total stop when the mqtt is unreachable. There should be a logic in place to limit the reconnect attempts to once per few seconds.

Original master does have a sync count limitation, but it is effectively deactivated by frequent time synces from controlling computer.

This leads to (up to <1s) inaccuracies in the set NTP time, breaking continuity of time and communication with clients.

Preferable fix is to include fractional part of time in the ntp updates (successive bytes to the currently used), and implementing slew #37