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?
Could it be a hardware issue? I have 30+ zigbee devices, all aqara sensors and ikea repeaters, everthing was working well. I added those 4 thermotats one by one with weeks between them. The last one has those issues. I did the day before yesterday a new install of the device to make it work again but yesterday 6 aqara sensors went offline, todat an extra 5, it looks all battery are empty.
Wath is your opion?
Did you have a Tuya zigbee hub?
If yes, then you can pair the problematic 4th thermostat to the Tuya hub temporarily.
If some of the Aqara sensors have been repeating via this thermostat, this would explain why they went offline.. although this scenario is not very possible, Aqara battery powered devices are sticky to the repeater that they have paired to initially.
What driver are you using for the Aqara sensors and what model they are?
nice feature
yes
change the heating setpoint to X degree?
@kkossev OK, this is what I did, After a lot of my Aqara sensors went offline in area of the bad thermostat I made a help request to the vendor of the thermostat, they have replaced the device. The name of the device was Iwijn Thermostat
When I received the new thermostat I renamed the bad thermostat to Iwijn Thermostat OLD. I included the new thermostat down in the house and named it Iwijn Thermostat. I am pretty sure it was connected to the repeater in the garage. I restarted 7 times the hub and everything was still working. I installed the new thermostat upstairs. Did 1 reboot of the hub and I had the same issue as the other "bad" thermostat --> Data section model and manufacturer data disappeared, grrrr
This was the situation of the getChildAndRouteInfo at that moment
I deleted the device in HE
power off the repeater Radio
Did a factory reset of the thermostat
power on the repeater Radio
added it again with the previous name Iwijn Thermostat
This was the situation of the getChildAndRouteInfo at that moment
Could the device null, the previous deleted device has something to do with the issue?
Hi @BrunoVoeten ,
I will read again all the info above tomorrow on a fresh head .. : )
But I have the following idea - can you leave the bad thermostat paired to HE, but without any communication to it? Just assign the 'device' driver and leave it connected to the Zigbee network, but without any commands sent to it. Reset it to the default parameters from the touch-screen menu and leave it to work as a Zigbee repeater only.
I think this is not the problem, this routing table info changes rather dynamically, and I have seen often such null devices, but no any issues.
the first bad one (out of the wall, not connected) or the second bad one (in the wall connected)
