@BrunoVoeten Yes, this makes sense! Will add it in the next update.
@iEnam I have changed this log level from 'warning' to 'debug' in the latest dev. branch. It will be visible only when the Debug logging preference is turned on. I don't know what is the meaning of this Tuya message, but it is something informative that does not affect the normal operation.
@kkossev I have played with the brightness function, do you have suggestions to make it better?
2 rules, "Force Manual Mode" is ON
The only annoying thing is commands are not always received (or send?) even when "Resend failed commands is ON", that makes the device "unpredictable"
Probably you could combine/merge the two rules into just one? I have to experiment with RM5 in the next days...
When the backlight brightness is turned off, how do you wake up the display if needed to manually correct the heating temperature or just look at the display? Which button do you press first?
This is the biggest problem!
Last week I was working on a Tuya Siren driver, and I observed the same unpredictable behavior. Seems like I managed to patch it with sending a harmless 'wake up' command first, before sending the actual alarm on command to the device. I will try the same approach with this thermostat, hopefully it will do the trick.
With the left button (forced manual mode on)
Hi @BrunoVoeten , sorry for the delay - I got retracted (again!) with other projects.. 
I have made a progress on the pollPresence issue, I have found a bug that unfortunately affects also other of my drivers... The periodic polling may stop after HE hub is rebooted.
I have implemented the fix yesterday in another driver and so far the tests are OK. I will transfer the fix here today and will let you know.
I have uploaded ver. 1.2.8. timestamp "2022/11/20 8:37 PM" into the dev. branch in GitHub.
You will need to click on ''Save Preferences button once that the scheduled 'pollPresence' job is initialized.
ok, I see the pollPresence now
can this workaround not cause an overload of messages? For example If a user changes the set point from 16° to 20° (steps in 0.5°)?
No, the additional data sent by HE is negligible when compared to the overload generated by the Tuya device itself. Unfortunately, this is a bug in the thermostat firmware itself, I see exactly the same multiple repeated reports when connected to Tuya Zigbee hub. Obviously, they don't care about the network bandwidth possible congestion and it is unlikely to be fixed from their side.
As you are using and monitoring the thermostat much more often than me, what are your observations - is it typically only the first commands send from HE to the device being lost after a long period of inactivity, but all other commands that follow shortly are accepted?
Sometimes the commands don't arrive at the device, it is no problem when it is manual action, you just sent it again, for example if you want to change the brightness, I notice that the brightness is sometimes not adjusted, not a big deal because the intention is to automate stuff without manual interventions. Worse is that I send a command via Thermostat Schedulers that does not arrive, e.g. changing the setpoint or if I use with rule machine to turn off the thermostat when the window opens and it turns out that the thermostat is still set to HEAT. You certainly cannot say that it is always after a period of inactivity. If I open (OFF) and close (HEAT) the window 6 times in a row for example, it works 2 times, then 1 time it doesn't, then 3 times it works. When I do a second time a test in a row, it works 4 times well, one time not, 1 time well, sometimes it works 6 times in a row...
Very annoying, especially when the setpoint or the status is not adjusted when it should.
Is this the BEOK or Avatto thermostat or both?
The BEOK, I don' use the Avatto at the moment...
Hi @BrunoVoeten ,
Just to let you know that I am back working on a final resolution of this 'missing commands' problem. I have added some additional statistics and checks, and in my case, it shows that 8 commands out of 273 have failed, i.e. the thermostat did not report back the mode change :
I
I am refactoring the Resend failed commands option and for now it works well for the mode change control and retry. I still have to implement the same logic for heatingSetpoint commands, when ready will notify you to test in your environment.
@kkossev, I received another 2 devices of the BEOK thermostat. Same model number as the one you have. How much time does it take to sync the time from the hub to the device? Working on dev 1.2.8 2022/11/20 8:37 PM
What is the application (firmware) version of the new BEOK devices shown in the Data section?
I read in Github that BEOK have "fixed" the problem with the clock... gues how... - by disabling the time synchronization !!!
And even worse - seems like they have not increased the firmware version after this "fix" !
OK, I will experiment next days on whether the time synchronization can be made forcibly grom the HE driver side.
If you set the correct time from the thermostat panel, will the time drift after a day?
Is the time shown correctly after midnight?
O
Correct, I changed the time of all 3 thermostats, only the first was synchronized
Will test
Download the Hubitat app
