poll command corrupts internal clock/date setting, stops timers from working
ul-gh opened this issue · comments
Hi,
tested just now: issuing the poll commant e.g. via MQTT corrupts the eQ-3 internal clock and prevents timers from working afterwards. There is a description of the problem and solution at:
Quote: "I have also dumped the bluetooth communication of the official app on Android devices. The app also sends date and time each time it requests the status. So we should do it as well."
Basically, an empty query (cmd byte value 0x03, see https://github.com/ul-gh/esp32_mqtt_eq3/blob/c9d807009072f1f4c10faab1cd723178af31933a/main/eq3_main.c#L879) is not sufficient, a date/time setting must be supplied simultaneously. There should be a note in the readme until this is implemented.
HTH, Ulrich
Hi,
I added the 'poll' command for neatness and I don't actually use it with my heating-controller application. I have tested previously too and noticed the time got corrupted but hadn't realised it was the poll command that caused this.
Unfortunately without a real-time-clock in the esp-32 (we could implement something but couldn't rely on access to ntp or a known accurate time reference) it is not possible to re-set the time on the unit for each poll. Assuming you do not use 'boost' mode with your trvs you can simply use the 'unboost' command which will have the same result as 'poll' without corrupting the time.
Regards.
Paul.
Hi,
regarding the poll command, yes if the same functionality can be achieved with the "boost" command (maybe get/reset the status?) that would be an option.
Otherwise, the ESP could receive the time with the same command and only do some plausibility checking. The instruction should then be renamed then from "poll" to "sync_time" or "sync".
Is it possible to increase the reading and posting speed for MQTT?
Or deepends it on the "slow" Valves and its bluetooth connection?
If i poll, or even set the temperature for 2 valves, its taking about 10 or more seconds till i get the message of the last valve.
What if you are controlling like 10 valves with one ESP? it would take up to 1 minute till you get the state of all valves back
The timing is pretty-much dictated by the valves. BLE (bluetooth smart) consumes very little power as the device spends most of it's time with the radio switched off. The transfer will only occur when the trv radio is on. For BLE the radio sends a beacon periodically (I think something like every 10 seconds). These beacons are used when scanning for the trvs initially. When the ESP32 has a transfer ready it first waits until it sees the device (beacon) and then initiates the transfer. So it can take up to ~10 seconds to contact each device.
The commands are queued in a fifo so we only send them sequentially. I don't believe it's possible to have concurrent transactions running to multiple trvs but it may be possible to have a list of devices to look for and connect to each as it appears instead of using the fifo. However even if this is possible it will require a complete rewrite of the application.
My intention has always been to port this application to the latest idf and rewrite some of the scheduling as it's a bit untidy so I may look at concurrent connectivity also if I ever find the time.
For heating control applications using these devices I would recommend separating the command/response handling into separate threads or at least not to block while waiting for a response to the command. For example I use a control thread that sends the commands to the valves based on timers and a background thread that receives the mqtt responses and stores each valve status in a database. I also log the time when a response is received. That way the control thread knows on each poll whether the last command got a successful response without needing to block waiting for that response.
The timing is pretty-much dictated by the valves. BLE (bluetooth smart) consumes very little power as the device spends most of it's time with the radio switched off. The transfer will only occur when the trv radio is on. For BLE the radio sends a beacon periodically (I think something like every 10 seconds). These beacons are used when scanning for the trvs initially. When the ESP32 has a transfer ready it first waits until it sees the device (beacon) and then initiates the transfer. So it can take up to ~10 seconds to contact each device.
The commands are queued in a fifo so we only send them sequentially. I don't believe it's possible to have concurrent transactions running to multiple trvs but it may be possible to have a list of devices to look for and connect to each as it appears instead of using the fifo. However even if this is possible it will require a complete rewrite of the application.My intention has always been to port this application to the latest idf and rewrite some of the scheduling as it's a bit untidy so I may look at concurrent connectivity also if I ever find the time.
For heating control applications using these devices I would recommend separating the command/response handling into separate threads or at least not to block while waiting for a response to the command. For example I use a control thread that sends the commands to the valves based on timers and a background thread that receives the mqtt responses and stores each valve status in a database. I also log the time when a response is received. That way the control thread knows on each poll whether the last command got a successful response without needing to block waiting for that response.
Thanks for your reply.
So, sending a command to two valves at the same time is not a good choise?
Im controlling 2 valves with one Button over only one ESP.
I also removed any actitivty of sending or receiving data and only using a "refresh" button. Thats pretty ok till now.
I always had a not responding ESP after a time when i did a poll to 2 valves each 10 minutes
You can queue many commands to multiple valves on a single ESP. These commands are sent sequentially (fifo) so the next command will be sent after the previous one completes or times-out. This should not cause problems for the ESP. I have tested with 8 queued commands and the ESP copes fine.
When your ESP stopped responding was it still associated with the wifi AP? How long was it working before it stopped responding? Did it need a power-cycle to get it working again? If so could you monitor the serial output from the device using putty/minicom? There is some debug that gets sent which may help to diagnose the problem.
You can queue many commands to multiple valves on a single ESP. These commands are sent sequentially (fifo) so the next command will be sent after the previous one completes or times-out. This should not cause problems for the ESP. I have tested with 8 queued commands and the ESP copes fine.
When your ESP stopped responding was it still associated with the wifi AP? How long was it working before it stopped responding? Did it need a power-cycle to get it working again? If so could you monitor the serial output from the device using putty/minicom? There is some debug that gets sent which may help to diagnose the problem.
Ive not tested any ping and didnt watch the serialport, because it was powerd by an USB Charger.
To make it work again, ive just disconected and connected the device from USB.
I will try later connecting to my PC again and watch it via serial and do a poll command each 5minutes to let it "crash" again after a random time.
Hi Ulrich,
I committed some changes to remove the poll command and replace with a settime command. Let me know if it works OK for you and we can close this issue.
MeisterQ if you get more details regarding the ESP disappearing could you open a new issue?
Regards.
Paul.
Hi Ulrich,
I committed some changes to remove the poll command and replace with a settime command. Let me know if it works OK for you and we can close this issue.
MeisterQ if you get more details regarding the ESP disappearing could you open a new issue?
Regards.
Paul.
I will add a new Issue ofc. But atm its working with "unlock". I will replace it to "poll" again and watch it via serial when it stopped working
As i see, for now the esp32 doesn't get the time from a time source like ntp or rtc in the current code and i need to serve the time through mqtt paramter. is this right or i'm missing something? i would like the have the option to sync the time directly on the esp32. i guess the easiest would be by using some ntpclient code and do the hex-transform.
best regards,
,Joachim
I didn't include sntp within the ESP code as I always envisaged the esp as a bridge-device enabling a controller to interface with distributed eq-3 valves. i.e. the system clock-master (some heating control function) would be the main controller of the heating system and hold real-time.
However adding sntp support is something that looks relatively simple using the idf so I'll see if I can add this as a new feature in a future release.
thanks for the reply. just to demand, with which "master" do you use the esp32s? So on which platform and with which software.
many Greetings
Joachim
In my case the master device is a rpi running openhabian with a mosquitto mqtt broker, a custom heating controller and openhab2. In my network topology the ESP devices have no control, they are simply bridges to allow the mosquitto broker to send commands to the valves.
If you are using ESP32s as simple bridges for user control then I can see how sntp on the ESP would be useful. There are examples in the idf so adding it shouldn't be too difficult.
thanks for including the sntp client.