ZHA Ikea tradfri shortcut Checkin event was fired

Configuration Zigbee
,
1

Good day,

I have recently added HA to my house. Before this I have been running various separate systems (like Ikea, Enphase and Mitsubishi).
So now adding all to HA and I like it.
Yesterday I have been working on migrating my Ikea units directly to the HA using a ZBT-1 and ZHA. This work relatively easy and setup is also ok.
Before I changed over I had the Tradfri hub and later on the Dirigera hub.
In my system I have various remote controllers/light bulbs/outlets and 1 signal repeater.
A few of them are the shortcut buttons. Running with the Tradfri it was working fine (at least what I’m aware of) when later on within the Dirigera system I had 1 of the shortcut buttons (also the one that is used the most) drained the battery very quickly. I always thought due to the amount of uses this was the reason but now when it is within the HA system I see a very strange event occurring randomly but within every 2 hours.
I see the unit shows every time a Checking event was fired.
Have checked if the firmware was updated and that is ok (the other units having the same versions 0x24040006) Tried a reset and added it again into the system (this was also done with the dirigera) but no change.
I thought it maybe is an issue that the shortcut button is switching between Routers of the Zigbee network. I see it is connected to the signal repeater (a few meters away from it) but I’m not sure if this is the cause and if it is possible to fix the button to the repeater router.
Did some searching and digging and found bellow github

It tells me to check the PollControl cluster and then the checkin_intervall attribute and comes back with the value 13200 (this matches also the other units that are not affected)
My though was to change and set it back again as this might fix the problem, so I added a new value and write it. At first it comes back as not write successfully but then I had to press the shortcut button and a green flag shows up.
When reading it again it comes back as none in the value field.
Closed the popup and reading it again shows again the same 13200 value.
So it seems to be not written correctly into the button.
Is there a specific code I need to send or just adding a value?
Is it possible to fix an endDevice to a specific router within the Zigbee network via HA(not the same as binding If I’m correct)?
Has somebody seen a similar issue before and know how to solve this?

2

Not quite clear what your question is… Is it that you are concerned that the check in event may be draining the battery on your button?

Check ins are part of the way a Zigbee network works. The coordinator does not initiate contact with battery-powered devices - if it did they would have to be listening all the time and that really would drain their batteries. Instead the end device “checks in” periodically to confirm that it is still alive - every hour or two is typical.

image
image404×599 9.68 KB

You see check in events less often with sensor devices because they are sending data back to the coordinator anyway. By defailt ZHA will consider a battery device unavailable if it has not checked in for 21600 seconds (6 hours). This can be changed in the Zigbee network settings.

If, as you say, this particular button is the one most often used, that may be the explanation for the battery drain, otherwise factors like temperature can make a difference. If you want to monitor battery life more accurately, you might look as an integration like Battery Notes, which allows you to log each change.

https://andrew-codechimp.github.io/HA-Battery-Notes/

No. Zigbee is self-regulating. You can do the initial pairing through a specific router, but the parent router will change as soon as a better connection is found.

3

HI @jackjourneyman,

Thank you for the detailed information.
Zigbee network setup duly noted and clear.

I agree with you that a button that is more used than the others drains quicker. However, this should not happen within 4 days. It is not that we keep spamming the button.
For a temperature-related issue, I would exclude this also as 2 buttons are in the same room and the other one is not affected.
If I look into the logbook I only see 1 that is Checkin very regular and the other unit is not at all (but still seen into the system)

So I still think it is something internally inside the button and would like to change the Checkin_interval attribute but the system doesn’t allow me to do so. And that is were my question came from is there a specific Hex code that needs to be filled in into the write attribute field or just a value?

4

Absolutely right. :grin:

Have you tried swapping it with another button? That would confirm whether or not usage is a factor.

5

@jackjourneyman
Yes this has been done.
I worked with them yesterday changing them over from the Dirigera to the ZHA and I was not able to get that specific button on the system. The second one came on directly and that has been programmed with the functions the first one had. This one was already working fine on its old setup/location and has now been moved to the 1st location.
This first 1 I got it later on into ZHA and it is just sitting now in the living room without a function at the moment.
It keeps reporting.
I now just think that it is reporting as it is not programmed for a function and because of this it wants to report as the button has not been pressed within a set time, however when I did the readout of the Checkin_interval it has been pressed so I can assume this is also not the case and if I’m correct the button itself does not contain any of the programming ( It is not binding to any other unit)