Ikea remote E1524 battery drains with new Zigbee Dongle-E

[smarthomejunkie]

What happened?

I tested the new Sonoff Zigbee Dongle-E with various devices. What I notice is that the battery of the Ikea Tradfri Remote is draining within one or two days of using this new dongle. Might be an issue with the dongle itself, because I noticed the same behavior on ZHA. Not sure if that's the case. It seems that it gets polled a lot or something.

I know the dongle is still experimental, but maybe this helps to get it out of the experimental phase.

What did you expect to happen?

I expected that the battery is not getting drained so fast.

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.27.0-1

Adapter firmware version

6.10.3.0 build 297

Adapter

Sonoff Zigbee 3.0 USB Dongle-E

Debug log

No response

[Koenkk]

There shouldn't be any polling from the z2m side, but maybe the dongle is doing something. Could you provide me a sniff of this? Preferably one where it is just the Dongle-E + E1524 in the network. https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531

[MattWestb]

Most IKEA controllers (not Styrbar) is having some bugs that can being triggered then its parent is offline or bad and the device is jumping to one new parent and cant going in sleep and burning the battery in 48 hours. Its fixed in the last SDK from Silabs but IKEA have not updating the firmware enough for getting the last bug away.

Recommended paring the controllers with one good router (not one OSRAM plug) and not with the coordinator so its not need jumping and triggering the bug. Also possible blocking the coordinator having direct children so all end device must using routers and not the coordinator (coordinator is one lazy router then its doing many more things then routing network traffic and is being offline little now and then).

The same behavior have being reported for Philips HUE controllers also with various coordinators (in Tasmota and ZHA issues).

Sonoff ZBB need having factory firmware or one patched then the chip is wrong tuned (or more correct not calibrated radio) from the factory. I have asking the factory if the new E version is being calibrated in the factory but have not getting any answer but i hope they have learning somthing for the ZBB.

[smarthomejunkie]

Most IKEA controllers (not Styrbar) is having some bugs that can being triggered then its parent is offline or bad and the device is jumping to one new parent and cant going in sleep and burning the battery in 48 hours. Its fixed in the last SDK from Silabs but IKEA have not updating the firmware enough for getting the last bug away.

Recommended paring the controllers with one good router (not one OSRAM plug) and not with the coordinator so its not need jumping and triggering the bug. Also possible blocking the coordinator having direct children so all end device must using routers and not the coordinator (coordinator is one lazy router then its doing many more things then routing network traffic and is being offline little now and then).

The same behavior have being reported for Philips HUE controllers also with various coordinators (in Tasmota and ZHA issues).

Sonoff ZBB need having factory firmware or one patched then the chip is wrong tuned (or more correct not calibrated radio) from the factory. I have asking the factory if the new E version is being calibrated in the factory but have not getting any answer but i hope they have learning somthing for the ZBB.

Thank you for this. I will try this as soon as I have time. In the meantime, my tradfri remotes that have been paired close to the stick are all drained. One survived, but has been paired far away from the stick, so I guess you're right indeed! Also my Philips Hue Motion sensors drop off after about a day.

[smarthomejunkie]

@MattWestb

"Also possible blocking the coordinator having direct children so all end device must using routers and not the coordinator (coordinator is one lazy router then its doing many more things then routing network traffic and is being offline little now and then)."

Can you point me in a direction on how to do this?

[smarthomejunkie]

There shouldn't be any polling from the z2m side, but maybe the dongle is doing something. Could you provide me a sniff of this? Preferably one where it is just the Dongle-E + E1524 in the network. https://www.zigbee2mqtt.io/advanced/zigbee/04_sniff_zigbee_traffic.html#with-cc2531

I'm not sure if I'll be able to do this.

[MattWestb]

I dont know how / if its possible making in Z2M but in ZHA i have putting this in HA config:

zha:
    ezsp_config:
      CONFIG_MAX_END_DEVICE_CHILDREN: 0

=> Mustfirst paring one router before doing the change and then restarting HA and all end device can only paring to routers and cant using the coordinator direct. Router can being joined thru all routers OK.

Philips HUE Motion sensors is famous leaving the network or "jumping around" and using very bad routers as its parent and thy is needing more good routers in the near for not leaving the network (its the personality of the device).

[smarthomejunkie]

Ah thanks! I'm running Zigbee2MQTT currently, so I guess I'm out of luck and might have to re-pair all my devices 😢

The Philips Hue motion sensors never had a problem with the Conbee 2 stick. It's just since I use the Dongle-E that they drop off and that batteries of other devices drain. Today, I found out that also the batteries of my Heiman smoke sensors were drained. 😱

[MattWestb]

Rasp/CornBee I/II is having one very strong (too strong) radio and is prefiguring have all device as children if possible but its being problems if its being off line for some short or long time and the devices is not getting contact with its parent and need "jumping" to one new one and it cant the the trust center (its manage the security and is one part of the coordinator) and leaving the network and also the mesh network is not working so good with unbalanced network links.

The original SoOff Zigbee stick (EZSP) was having very bad hardware design and was also have the radio miss tuned from the factory and way fixed by patched firmware from the factory. We have asking the SoOff devs for information but have not getting one answer if we need patching somthing for getting the E-Type working well in our systems.

I dont knowing if the backup is working 110% for EZSP but both Z2M and ZHA is using the same formats for for backups of the coordinator and shall working in both ways if all is OK.

[smarthomejunkie]

Ah okay, so do I understand right that I can create a backup in Zigbee2Mqtt and use that backup in ZAH?

On Thu, Sep 1, 2022 at 7:40 PM MattWestb @.***> wrote:

Rasp/CornBee I/II is having one very strong (too strong) radio and is prefiguring have all device as children if possible but its being problems if its being off line for some short or long time and the devices is not getting contact with its parent and need "jumping" to one new one and it cant the the trust center (its manage the security and is one part of the coordinator) and leaving the network and also the mesh network is not working so good with unbalanced network links.

The original SoOff Zigbee stick (EZSP) was having very bad hardware design and was also have the radio miss tuned from the factory and way fixed by patched firmware from the factory. We have asking the SoOff devs for information but have not getting one answer if we need patching somthing for getting the E-Type working well in our systems.

I dont knowing if the backup is working 110% for EZSP but both Z2M and ZHA is using the same formats for for backups of the coordinator and shall working in both ways if all is OK.

— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/13681#issuecomment-1234586776, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQA4VX4KMW5ZJU7WXL2NIS3V4DTA3ANCNFSM57SHJ7OA . You are receiving this because you authored the thread.Message ID: @.***>

[MattWestb]

It shall working and i knowing TI is doing it OK but i have not testing if its working OK with EZSP.

One thing is that if you is "swapping" host system is the coordinator normally not deleting it NVR and is still having the network credential saved but the host system is not having the information of the device and need reading all the device for knowing them and i dont knowing if its working OK re power router and getting end devices contacting the coordinator then all device is having the right network setting for working in the network. Rasp/CornBee user is oft doing host swapping but its working little different then can manipulating the coordinators network setting also the device link keys.

[kirovilya]

@smarthomejunkie sorry, backup/restore currently not supported in z2m for EZSP adapters :(

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[smarthomejunkie]

How do you remove the stale label? I think this is still the case. Will check it with the latest version of Z2M.

[t112013]

my remotes do the same. spent 8 batteries, i have almost given up. anyne ?

[smarthomejunkie]

The problem indeed still exists in the latest version of Z2M.

[adamxfort]

Same issue here tried the latest dev which was supposed to fix the battery some drain #8072, unfortunately, it didn't help in this case (the Ikea remote died after one night). When running this with Sonoff dongle P, it's all fine, but I'd prefer E, as the transmit power and LQI I get are so much better.

[MattWestb]

Still all Zigbee Sleeping End Device is best practices pared to one good router and not the coordinator.

If using the coordinator as parent its very likely jumping around then its offline or busy doing "other things" then routing traffic.

IKEA still have some bugs that can being triggered if they is jumping to one new parent and is daring the battery in 48 hours.

Im not 110% secure that Sonoff have getting the hardware working after the firmware patching the calibration but they is saying it shall being OK.

If like building one star network with one good coordinator and no router its OK but you is loosing all functionality of the self healing mesh network and is better using WiFi devices then Zigbee ones (= single point of failure and not self healing).

The https://github.com/Koenkk/zigbee2mqtt/issues/8072 is one fix only for tuya TS004X controllers that was having problem with some wrong configuration was made and is not connected to the problem with E or P coordinators.

[gkrystev]

Still all Zigbee Sleeping End Device is best practices pared to one good router and not the coordinator.

How exactly you can choose to pair with a router instead of a coordinator?

[t112013]

Anyone ? i have the same issue and i have changed batteries 20 times now,

[MattWestb]

In ZHA from the device card of the router device clicking on add device via this device. Z2M = KA (NK).

Then opening the network for joining device the system is sending the command to all devices that can joining devices (routers) and the joining device is selecting the best one "from its point of viewer" so putting the controller very near the router you like paring thru and its very likely its using it. After paring look on the network map and you can see how it is connected. If not looks OK redo the paring to the same router or one other and looking how it was working.

Also then changing batter have the device in the near the router you like it shall using then putting the new battery in so its not jumping to one "bad" router and draining the new battery in 42 hours.

[t112013]

hmmm iam running Z2M I have chosen the closest light and press permit join, but dead battery after 1 day. Pluss that the wife is supped pissed coze its not possible to turn the lights on. Any advice on what can i do ?

[MattWestb]

Is the router device one good router ? Osram plugs and some others is very bad and is the LIQ good from the device to the router then you look on the network map ?

In the end i think its normally easier changing Zigbee devices then one wife.

Can also looking if you have strong WiFi networks around the position you remote normally is having with one app in you smart phone (WiFi and Zigbee channels is not the same so must looking its not over lapping) and changing channel of the Zigbee or WiFI network .

[t112013]

i have 30 philips hue spotlights and 3 ikea lightbulbs in each room close to the remote.

[TheLexus]

I suffer from the exact same problem. My E1524 dont last longer than a week. I rejoined the remote because first it was directly connected to the coordinator (Sonoff Stick) and now it is connected to a trafri led strip wich is always powered and half a meter away, I didnt had this problem with a CC2531 stick before at all (battery usually lasts a few months).

Question now is how to make things better.... does the problem is the remote or the sonoff stick... ? Should i change to a conbee stick? (Manufacturer is around 100km away and the availability should be good). From all of the Zigbee3 sticks the only other available one in germany was the sonoff...

[MattWestb]

@TheLexus The last findings (12 hours) is that TI is having problems with real Zigbee 3 end devices (cant setting up end device time out) and they is leaving if they cant jumping to one good Zigbee 3 router (both is bad then it can triggering the bug in the IKEA firmware).

Still try getting the remote using one good Zigbee 3 router so its not jumping around and getting problems is the only way getting the battery not being fast drained..

[TheLexus]

@MattWestb Thanks for the explanation and all your effort! So, if i understand correctly, the remote (even if its an Zigbee 2 remote) tries to connect to an Zigbee 3 router, the nearest router in this case should be my coordinatior because all other routers are even zigbee 2 only (2 tradfri ones, maybe on zigbee 3 one floor underneath but with less reception that directly to the coordinator). Is this correct?

And TI is trying to solve that problem atm or can only ikea solve it by a new firmware? In the meantime only thing todo would be to have some Zigbee 3 router which is "nearer" than the coordinator itself... right?

[t112013]

So "older" ikea bulbs and 3 years old philips hue downlights are zigbee 2? Kind of that the issue? Would resolv it by changing one bulb?

[MattWestb]

IKEA have updating all there devices to real Zigbee 3 for one year ago but the old motion sensor have not getting it so its Zigbee Light Link (ZLL 1.X) so if having your IKEA devices updated they shall working OK.

Also the controllers (remotes) have getting updates for fixing battery draining and loosing the network then changing battery but was not getting the last bug away then was not using the latest SDK fix from Silabs.

If updating your controllers you is losing the group binding to light that is very importing have if working with lights but you is getting lesser bugs in the device firmware.

Philips HUE first gen is Zigbee 1 / 2 / 3 but have some bad bugs and functions i dont like -> In the black box for bad zigbee devices. New HUE (With BT implanted) i dont have experience off but shall being Zigbee 3.

I have one IKEA outlet in the near of all my IKEA controllers and they is the back bone of my Zigbee network and its working great also then changing battery i only must have the remote in the near of its router then putting the new in (was doing it in the living room and putting it back in the bedroom and the new battery was dead in 2 days and the next is working strong then putting the battery in then its on the table in the bedroom).

[TheLexus]

@MattWestb Thats interesting... the 2 devices im talking about (half a meter away from the remote) are this ones https://www.zigbee2mqtt.io/devices/ICPSHC24-10EU-IL-1.html#ikea-icpshc24-10eu-il-1 . Your are correct, the firmware 2.3.086 they have introduced Zigbee 3... so, I think I should have no problem if the remote is connected to them. But I have... that's a thing I don't understand.

[MattWestb]

The power drives is one first gen device (was released with Zigbee Light Link firmware) but have getting Zigbee 3 update and is working OK but the antenna is not so good positioned inside the case.

You can taking the battery out from the remote and waiting one minute and putting it back then the remote is very near the power drive.

Its not guarantee its jumping to the drive but if it doing it and it finding one other router better and jumping = very likely battery draining in 48 hours :-((

Use the Zigbee network map to see how the remote is connected to the network.

[TheLexus]

Seems its not possible in my setup to use the remote atm. The newest battery lasts around 24h and i double check a few times that the remote is connected to the same router and it was... so maybe problem consists of a few bugs. I guess i need to find another remote that solves the problem... wifes acceptace is around the marian sea... so, time for fast exchange.

[TheLexus]

Seems its not possible in my setup to use the remote atm. The newest battery lasts around 24h and i double check a few times that the remote is connected to the same router and it was... so maybe problem consists of a few bugs. I guess i need to find another remote that solves the problem... wifes acceptace is around the marian sea... so, time for fast exchange.

Last try i do is to disconnect the remote from Z2M and try to directly connect them to the lights using the hold near and link method.. dont know if this make a difference.

[MattWestb]

@TheLexus If doing the direct paring (holding the raring button 10 seconds) is the remote forming one own network with only the light and no other devices so cant jumping and is the same thing IKEA is using the the first gen hub.

I have not having any fast battery draining on my controller on the IKEA hub so i think it worth testing.

[maframan]

In my case the workaround not work. The Ikea Button join in the network via router (sonoff zbmini) but the battery drain problem persist

[MattWestb]

@maframan I dont have the sonoff zbmini so i cant saying its one good or bad router but many SoOff devices is having strange problems so if i was you i have testing one other router that is known working well with Zigbee 3 sleeping end devices.

Also using one APP for scanning the WiFi so its not interference with overlapping the Zigbee system and making the device jumping around (WiFi and Zigbee channel is not the same then Zigbee so must looking in some wikis for getting it right).

[maframan]

@MattWestb sorry for my last post, i've confused with other device. The device mentioned in my last post, after coordinator firmware upgrade ('{"meta":{"maintrel":"1 ","majorrel":"7","minorrel":"1","product":9,"revision":"7.1.1.0 build 273"},"type":"EZSP v9"}'.) the problem seem resolved because during 10 minutes of sniffing the device not appear, must I to sniffing more time?

[LeeWiu]

Where did you get the firmware? The official repo shows only the old version https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E

[maframan]

Where did you get the firmware? The official repo shows only the old version https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E

This is the link https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/Zigbee3.0_Dongle-NoSigned/EZSP/ncp-uart-sw_7.1.1.0_115200.gbl

[LeeWiu]

Thanks, please keep us updated with battery drain.

[MattWestb]

@TeHashX EZSP 7.X is not classed as stable then its not so good tested and is not being supported by many devices. Try it out if you like but you is getting problem going back to EZSP 6.10.3.0 that is the candidate for stable and the EZSP 6.7.8.0 (SonOff version 6.7.9) is the recommend stable version for all open Zigbee systems. EZSP 6.7.10.0 is the last bug fix version and shall being OK 2.

[MattWestb]

Un-bricking dongle after flashing EZSP 7.X . https://github.com/xsp1989/zigbeeFirmware/issues/28#issuecomment-1279747520

[maframan]

@TeHashX EZSP 7.X is not classed as stable then its not so good tested and is not being supported by many devices. Try it out if you like but you is getting problem going back to EZSP 6.10.3.0 that is the candidate for stable and the EZSP 6.7.8.0 (SonOff version 6.7.9) is the recommend stable version for all open Zigbee systems.

Ok thanks. After three hours post upgrade i don't have any issue and all device work very well

[MattWestb]

Great and thanks for testing the 7.X firmware then its need more testing for knowing if its working stable or not.

[hnykda]

I have experienced battery drain for one of the switches here: https://github.com/Koenkk/zigbee2mqtt/issues/3444#issuecomment-1310665781 with the same dongle.

[maframan]

@TeHashX EZSP 7.X is not classed as stable then its not so good tested and is not being supported by many devices. Try it out if you like but you is getting problem going back to EZSP 6.10.3.0 that is the candidate for stable and the EZSP 6.7.8.0 (SonOff version 6.7.9) is the recommend stable version for all open Zigbee systems.

Ok thanks. After three hours post upgrade i don't have any issue and all device work very well

After 24 hours the first tradfri button has gone off for battery drain and the second one button is stable on battery usage, same yesteday percentage. The first and second one Button joined in the network in the same time with the same router. The situation is very strange, i must to understand this behavior, please suggest me some ideas For analysis!! Thanks

[gkrystev]

In my setup, the IKEA remote (E1743) works fine for a week, or two, even a month, with no significant battery drop, and then suddenly dies. When I check the battery, it is empty. The only difference around this remote is that the remote is nearby a few IKEA (Zigbee) bulbs that are joined in my network but they are used with hard switches, i.e. they are switched on/off by cutting the mains voltage.

Not sure how can I sniff the Zigbee network for some abnormal behavior. If someone has any clues?

[maframan]

I've snooped all battery drain of Tradfri button device with address 0xd360, who help me to analyze this snoop? I suspect that this device changed routing and start the battery drain situation Find in attach the snoop file: snoop_battery_drain_device_0XD360.zip

[MattWestb]

Without network key (or paring one device then its possible decoding it) is not possible that is inside the frames then is encrypted only network (underlying 154 network) parts i can "see". I can see its using 0X6da2 as parent and jumping to 0xc290 in frame 4814 so it have jumping = very likely triggering one or more bugs in the device and if being triggered is not going in sleep = draining the battery.

[maframan]

Without network key (or paring one device then its possible decoding it) is not possible that is inside the frames then is encrypted only network (underlying 154 network) parts i can "see". I can see its using 0X6da2 as parent and jumping to 0xc290 in frame 4814 so it have jumping = very likely triggering one or more bugs in the device and if being triggered is not going in sleep = draining the battery.

I use default network key (01:03:05:07:09:0B:0D:0F:00:02:04:06:08:0A:0C:0D)

[MattWestb]

Put (wpan.src16 == 0xd360) || (wpan.dst16 == 0xd360) in the filter field and and you see all traffic to and from the device :-))) (is not true then paring one device and also is it have changing the short addressee in the network) Before jumping the device the last pull / data request was 22 minute. After jumping is doing it every 5 minutes = more normal.

All looks normal for one jump and some re sending but no timeout = OK.

Can you looking if you have WiFi interference from your or other WiFi networks ?