You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Enhancement, provide a command to continuously read and compare typeID(s) values.
Typical usage would be to try and find what a given switch/setting affects.
Something like:
monitor <type ID(s)>
This would poll the device and type at second intervals and print the difference between polls if any of the values changed. Ideally would be great if a range of type ID's could be specified.
The text was updated successfully, but these errors were encountered:
I've tought about this. A fixed interval will flood the tx-queue completl if the we need to read more parts of a telegram.
I've made a test with a single telegram, reading all parts, store them and after last part put the next read command to end of queue.
Works, but makes a lot of traffic on the bus. I also don't see any advantage of this.
It's much easier to read a telegram, make the change on boiler/thermostat/controller and send a read again. Then we are sure that the change has happend and we have to compare only 2 reads.
Nevertheless, try out, this bin and have the telnet-monitor command: EMS-ESP-3_4_0b18dev-ESP32.zip
and here is a test log, showing the the output with ww temperature changes and (with log debug) the bus-traffic: 20220520_111345_EMS.log
Enhancement, provide a command to continuously read and compare typeID(s) values.
Typical usage would be to try and find what a given switch/setting affects.
Something like:
monitor <type ID(s)>
This would poll the device and type at second intervals and print the difference between polls if any of the values changed. Ideally would be great if a range of type ID's could be specified.
The text was updated successfully, but these errors were encountered: