volca02 / hr20-esp12-master Goto Github PK
View Code? Open in Web Editor NEWRe-implementation (with different features) of the master portion of OpenHR20 wireless project
License: GNU General Public License v2.0
Re-implementation (with different features) of the master portion of OpenHR20 wireless project
License: GNU General Public License v2.0
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).
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.
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.
This way we can be sure nothing changed on the clients and can implement re-reads if it did. Combines well with #24
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
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.
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.
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.
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.
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).
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.
Although the client reports this value on every occasion, the model does not reflect the change. Namely wanted temperature is stuck.
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.
Add support for OTA updates.
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 ?
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.
Might be CMAC mismatch, could be pkt_cnt mismatch too. Serial console to a client could help debugging the issue.
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.
Render a timer table from the timers gathered via the json ajax call after pressing a dedicated icon in the client list.
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.
We need a button to reset configuration and bring board back to AP mode. This enables reconfiguration.
Reset button should have these two modes:
The project needs a way to specify configuration - mqtt server, key values, etc. Could use wifiManager for that, it supports custom parameters
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.
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.
Should help with persistent bugs that we see - missing callback calls and invalid callback values, namely.
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.
Add to/from converters for mqtt - temperature, voltage, time of day.
Either:
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.
MQTT interface is the next logical step:
Topic base path should be:
/prefix/addr/*
with fixed but customizable prefix (compile time).
Topics:
Timers then should probably be timers/day/slot/... - need feedback here.
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).
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.
It is needed to wake the clients up before their low frequency reporting happens.
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.
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 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).
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.
Original master does have a sync count limitation, but it is effectively deactivated by frequent time synces from controlling computer.
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).
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.