I think the problem with the AVATTO is fixed in dev. branch version 1.2.10 now.
The bad news is that I can't test using my BEOK thermostat, by some weird reason I can not enter into the pairing mode, I can't enter into Menu settings mode as well.. Do you have a link to the actual installation manual for this device, I think that I may be looking at a wrong one - there are too many models and variations .. : (
1 Like
1 Like
@kkossev, question, there is a check if commands are received for the mode and temperature. Is the "Set Brightness" checked to if the commands are received?
No, currently only the heating temperature and the mode changes are checked and retired if failed.
1 Like
do you use this functionality together with a presence detector? So if a person is near the thermostat the display will light up? If yes, does it work well?
I was only testing this in a RM rule for few days a couple of months ago, but I will restore the configuration tonight.
After I switched over mmWave radars for lightning control in all rooms, I have now a plenty of cheap PIR sensors left to experiment with … : )
1 Like
do you already have some experience to share concerning the display lighting up in combination with your mmWave radars?
I am using a rule like this :
I am using an ordinary PIR motion sensor here, the keep time is 30 seconds.
EDIT: and unfortunately, the RM commands fail sometimes.. : (
Is the rule failing or the command on the device?
The command is ignored by the device sometimes - same like the on/off failures. But here we have a very simple single command to control the brightness!
is it not an option to use the same "fix"?
Implemented in dev. branch version 1.2.11 - please give it a try.
Yes, it works, You can see it clearly when the command is not received or accepted because there is some delay but ik works:-).
I guess as a developer it is not you preferred way to solve those issues with those buggy devices but what is te alternatieve?
Anyway, there are working well now. I have 4 "BEOK" devices running now (the last one has AVATTO on the box), Maybe we should use the name AVATTO 2.0 for the hardware:-). For me the model can be add to the pictures on the head of this topic, it is a well deserved place:-)
1 Like
hmmm, So I have 4 exact devices, the first one had a time sync issue, device 2&3 has different firmware that solves the time problem (but the same firmware version), the fourth one has warn logs.
4 same devices, same firmware, different behavior
I start to understand whey some people hate those devices.
EDIT: It was a driver issue, for some reason the model was not available/recognized, even choosing the model manual was not helping , only after remove the device and added again it was solved
1 Like
@kkossev something strange, the problem above is coming back.
This is how I could simulate the problem:
Install as a new device, everything is working, I see that:
after x time and a reboot I see only the endpoint ID
Those fields are disappeared:
Temperature Celling
LCD Brightness
Disable/enable frost protection
Disable/enable sound
I start see this bug in the logs
The setpoint is not correct anymore
20.0 ° is 02.0° on the device
I have the feeling it is still working as long I don't restart the hub
To solve the issue I need to delete and add the device
Any suggestions?
1 Like
Wow !
If the Data section model and manufacturer data disappear, nothing will work... the driver logic depends a lot on the model/manufacturer of the device!
I am not using the removeDataValue() function anywhere in this driver... Will check for any other possible or impossible reasons.
no issues with the 3 other devices, very strange
1 Like
Have you seen recently anything like this ?
only once, a view weeks ago this message
We have two issues here.
First, the cause for the problem - probably it will be very difficult to find out why this device Data values are wiped out. I have some doubts but don't want to speculate before I have proof.
The second problem is something that we can start working on now. It is about how to report / send an alarm when a device was detected to be dysfunctional.
In our case, the driver can check whether the model or the manufacturer data is missing. This is the reason for all other reported oddities ( missing brightness settings and commands, missing sound commands, etc.. - all these depend on the current device manufacturer / model).
The important problem is that the heating setpoint is not correct anymore. So in this situation, the device is not functional and the home automation system must be make aware of the fault situation :
I can send an alarm event, which may trigger other notifications and alarms to be displayed on dashboard, to be sent to mobile phones, etc. Will have to think some more about an appropriate custom event name and what the event values to be, and how these alarm event values will be handed by the standard HE applications.
An idea:
attribute "alarm", "enum", ["clear", "malfunction", "other_alarm_type"]
And a second question : how the thermostat should behave in case of a 'malfunction' state?
Should the driver do anything in addition - as example try to turn the heating relay off?
