Philips Hue Dimmer switch battery running down rapidly (ZbBridge)

[pingel20]

PROBLEM DESCRIPTION

The battery percentage of my Philips Hue dimmer switch is running down quite rapidly since I paired it with the (Tasmota) ZbBridge.
It decreases some percents per day while the switch is used sparingly

Is the ZbBridge requesting this device very often?
Can I do something to prevent lots of communication?

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): Sonoff ZbBridge
• Tasmota binary firmware version number used: 9.2.0.1
  • Pre-compiled
  • Self-compiled
• Flashing tools used: _____
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:
{"NAME":"Generic","GPIO":[1,1,1,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":18}
{"Module":{"75":"Sonoff ZbBridge"}}
{"GPIO0":{"320":"Led_i1"},"GPIO1":{"3552":"Zigbee Tx"},"GPIO2":{"0":"None"},"GPIO3":{"3584":"Zigbee Rx"},"GPIO4":{"5312":"Zigbee Rst"},"GPIO5":{"0":"None"},"GPIO9":{"0":"None"},"GPIO10":{"0":"None"},"GPIO12":{"640":"I2C SDA"},"GPIO13":{"576":"LedLink_i"},"GPIO14":{"608":"I2C SCL"},"GPIO15":{"0":"None"},"GPIO16":{"32":"Button1"},"GPIO17":{"0":"None"}}

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

TO REPRODUCE

Steps to reproduce the behavior:

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

Add any other context about the problem here.

(Please, remember to close the issue when the problem has been addressed)

[s-hadinger]

Use the latest Tasmota version, reset your IKEA remote and pair again.

The latest Tasmota version doesn't configure attribute reporting anymore which causes the battery drain. But you need to reset the remote first.

[pingel20]

No Zb command to stop the attribute reporting?

A repair will change the 16 bit device identifier, this will also affect my other software. (No big problem though).

[s-hadinger]

Yes you could via a command but it's tricky. And I I'm not sure it will be effective.

Try to use friendly names instead of 16 bits addresses.

[pingel20]

@s-hadinger

Can you please check if this is okay?

I upgraded to today's dev version 9.2.0.3
ZbForget 0x12AD to remove the device

Then a repair

11:53:35.902 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbState":{"Status":30,"IEEEAddr":"0x00178801080AF627","ShortAddr":"0x12AD","PowerSource":false,"ReceiveWhenIdle":false,"Security":false}}
11:53:36.411 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbState":{"Status":32,"ActiveEndpoints":["0x01","0x02"]}}
11:53:36.929 MQT: tele/tasmota_D7F2A1/12AD/SENSOR = {"ZbReceived":{"0x12AD":{"Device":"0x12AD","Manufacturer":"Philips","ModelId":"RWL021","Endpoint":1,"LinkQuality":86}}}
11:53:38.419 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbState":{"Status":33,"Device":"0x12AD","Endpoint":"0x01","ProfileId":"0xC05E","DeviceId":"0x0830","DeviceVersion":2,"InClusters":["0x0000"],"OutClusters":["0x0000","0x0003","0x0004","0x0006","0x0008","0x0005"]}}
11:53:39.060 ZIG: Zigbee Devices Data saved in EEPROM (206 bytes)
11:53:39.926 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbState":{"Status":33,"Device":"0x12AD","Endpoint":"0x02","ProfileId":"0x0104","DeviceId":"0x000C","DeviceVersion":0,"InClusters":["0x0000","0x0001","0x0003","0x000F","0xFC00"],"OutClusters":["0x0019"]}}
11:53:41.426 ZIG: auto-bind `ZbBind {"Device":"0x12AD","Endpoint":1,"Cluster":"0x0006"}`
11:53:41.930 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbBind":{"Device":"0x12AD","Status":0,"StatusMessage":"SUCCESS"}}
11:53:43.429 ZIG: auto-bind `ZbBind {"Device":"0x12AD","Endpoint":1,"Cluster":"0x0008"}`
11:53:43.929 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbBind":{"Device":"0x12AD","Status":0,"StatusMessage":"SUCCESS"}}
11:53:45.455 ZIG: auto-bind `ZbBind {"Device":"0x12AD","Endpoint":2,"Cluster":"0x0001"}`
11:53:45.929 MQT: tele/tasmota_D7F2A1/RESULT = {"ZbBind":{"Device":"0x12AD","Status":0,"StatusMessage":"SUCCESS"}}
11:53:47.445 ZIG: auto-bind `ZbSend {"Device":"0x12AD","Config":{"BatteryVoltage":{"MinInterval":3600,"MaxInterval":14400,"ReportableChange":...
11:53:47.951 MQT: tele/tasmota_D7F2A1/12AD/SENSOR = {"ZbReceived":{"0x12AD":{"Device":"0x12AD","ConfigResponse":{"BatteryVoltage":{"Status":140,"StatusMsg":"UNREPORTABLE_ATTRIBUTE"}},"Endpoint":2,"LinkQuality":86}}}
11:53:57.058 ZIG: {"ZbEZSPReceived":"23000101AD1227F60A080188170004"}
11:53:57.558 ZIG: {"ZbEZSPReceived":"2400AD1227F60A080188170001000000"}

The 16 bit address did not change.
I still see things about BatteryVoltage/MinInterval/MaxInterval ?

Now I should no longer have the battery icon near the device name on the main screen. Correct?

[s-hadinger]

Oh right sorry. I misread. I thought it was an ikea remote.

I didn't know Philips had the same problem. I will add Philips to the list of non-attribute reporting

[pingel20]

OK, fine.

Can I check somewhere when this has been implemented in a next dev version?

[ascillato]

Can I check somewhere when this has been implemented in a next dev version?

Yes, when this got implemented, this issue will be automatically closed with the reference of the PR that implements it. Github will automatically send you a notification when someone writes in this issue or when this issue get closed.

Then, after 1 hour, you can download the latest compiled firmware from http://ota.tasmota.com/tasmota/tasmota-zbbridge.bin.gz

You can set that link directly from the Tasmota WebUI in the update firmware option (in OTAurl) and Tasmota can update directly from it.

[pingel20]

Thank you for the explanation.

[pingel20]

@s-hadinger

Thanks for the new dev version.
I re-paired my dimmer switch there is no configuring for reporting battery voltage anymore.
So this looks okay.

[MattWestb]

I think this problem and the IKEA problem is coming from one bug in the NCP firmware.
ZHA is having problem with IKEA controllers draining batteries in on or 2 days and its not happening on older stack version of EFR32 chips (95% users with the problem is using sonoff zigbee bridge).
deCONZ have implanting reconfiguring pull control that is draining smart things and IKEA controllers batteries because short pulling is not enden and running infit.

The last release of Zigbee EmberZNet SDK 6.7.8.0 GA

3 Fixed Issues
Fixed in release 6.7.8.0

638989 Fixed an issue in the host-ncp sleepy end device configuration, where it continued short polling if the parent connectivity was lost temporarily during data transfer.

Perhaps time requesting one updated firmware for the sonoff zigbee bridge from sonoff ?

[s-hadinger]

@MattWestb You're the best! This would explain the symptoms.

Since the last change in Tasmota, I removed Attribute Reporting for IKEA remote, and verified with a Zigbee sniffer that the remote wouldn't send any packet for over 24 hours. This worked for weeks, and suddenly the remote battery was dead. I didn't have the Zigbee sniffer anymore unfortunately.

Indeed a Zigbee protocol issue between EFR32 and IKEA ncp is a very high suspect in this behavior.

Do you remember who we can ask for a Sonoff signed 6.7.8 ?

[s-hadinger]

Re-opening to track progress on this.

[MattWestb]

The first request we was doing in the huge maint adventure thread but hedda was addressing the same user for the request of 6.8.x in #9316 (comment) The user is named in this issue and is normally fast responding one (time zone difference not included).

Do you have the possibility making one "open / free" version for the user that have j-tagged / open sonoff bridge ?

deCONZ is setting up the pull control for getting the problem solved (not verified if its working) but it can being one tyre and temporary work around until fixed firmware is in place.

[MattWestb]

Do you have some more EFR32 modules that is working you can using them as zigbee sniffer and dont need flashing them only install the right software for piping the stream to wireshark.

The Z2M guide is also working with EFR32 with one EZSP NCP firmware loded as on my IKEA Billy EZSP https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html#with-husbzb-1-stick

I knowing soundring is little to hard core for you but its the opposite for us that is coming from the hardware side and have problem getting simple software coding working at all ;-))

[MattWestb]

By the way, many user in ZHA and Z2M is having problem with that IKEA controlling devices is losing the network credentials after have draining the battery is also pinpointed to on Silabs bug but its in the device and cant being fixed on the coordinator side.

The scenario is that the devices is running very low on battery and have problem writing / updating / erasing flash regions and the frame counters is being not OK saved in NVR and they is getting of sync and / or its corrupting in the NVR storage in the flash and the devices is deleting the NVR on restart then its not valid (Its fixed in 6.6.7.x but its in the zigbee stack in the end devices).

I have confirming it is also happening on IKEA GW with one of my E1743 (of 7 in production) then it have running out of battery.

Only for information if you getting user losing there IKEA controllers on complete battery draining.

[s-hadinger]

I don't know how to compile myself 6.7.8.0 for ZBBridge and would spend too much time...

I do have 2 ZBbridge devices, one erased via SWD and accepting unsigned EZSP firmware, and one with the Sonoff bootloader requiring the signed firmware. I can test both.

[MattWestb]

I think @grobasoz was doing your well working firmware and hi was doing the working one for the Billy.
If hi is having time hi is normally helping if hi can and i think its only asking only need the hardware config (original RX,TX, and reset pins).
As alternative some of the ZHA devs have buying the dev kits and have making good working firmwares for some modules.

For the factory firmware ping the user and kindly asking for one update / bug fix.

I setting my money on Gary is the faster one (down under ones) :-)))

I putting one request on garrys git later for one update of My Billy EZSP.

[MattWestb]

A very good morning Stephan.
Can you trying flashing https://github.com/grobasoz/zigbee-firmware/blob/master/NCP_USW_115k2_ZBBridge_678.gbl on your open bridge ??

Gary have for the moment not testing it on tasmota but its running OK on the same EFR32 chip and hi have doing one 6.9.2.0 if you like testing it but i think its dont have the fixe for the NCP not setting up pull control.
grobasoz/zigbee-firmware#2 (comment)

S37 and hex is also made if needed.

And grating from down under that dont have our snow problems for the moment.

[MattWestb]

Cloned the repro so you can copy what you like / need :-))
zigbee-firmware-master (4).zip

[MattWestb]

I see Gary have also making one new bootloader for sonoff but i dont knowing if its helping.
It was some bugs on srie 2 but i think its was with the hardware security things so should not being one problem for your setup with deleted security setting from the factory.

By the way if you is flashing the "open" bridge with the new firmware then you can using the "secure" one with USB serial for wireshark sniffing !!

Edit: False alarm its not updated :-)

[MattWestb]

My IKEA Billy EZSP is up and running on the fixed firmware :-))

2021-01-15 15:10:01 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: IKEA of Sweden
2021-01-15 15:10:01 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: Billy EZSP by MW
2021-01-15 15:10:01 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

But for the moment with ZHA.
The second one for testing and sniffing is also upgraded and looks working well.

[s-hadinger]

Can you trying flashing https://github.com/grobasoz/zigbee-firmware/blob/master/NCP_USW_115k2_ZBBridge_678.gbl on your open bridge ??

I flashed successfully this firmware on my unlocked Sonoff ZBBridge. For some reason the firmware upload from Tasmota failed to update it, so I did a remote XMODEM transfer. I worked fine. I used the gbl file.

Any news of a Sonoff signed firmware?

{"ZbState":{"Status":55,"Version":"6.7.8.0","Protocol":8,"Stack":2}}

[markokristof]

when is the next release expected? current stabile version of firmware drains batteries for all connected devices, particularly for sensors and ikea fyrtur blinds.

[MattWestb]

Im curious what version is on your Zigbee module ?
And what is behind "all connected devices" ?
How is your setup looking ?
Do you have some router devices ((IKEA blinds is no routers) in the network and perhaps one screenshot on the network map pleas.

Thanks in advance.

[markokristof]

I am using 6.7.8 and battery powered devices drain real quickly - remote controllers and sensors go out first (particularly those that are not close to routers - in less than a day) while fyrtur blinds used to go out after two days (situation improved after I placed a dedicated repeater nearby). Here is my network map, disconnect devices are fyrtur remotes and sonoff motion sensors

[s-hadinger]

Are you using ZHA ? If so it's not under control of Tasmota and you are on the wrong site to report issues.

[MattWestb]

The ZHA issue home-assistant/core#43969

And upgrading the Zigbee module to EZSP 6.7.9.0.

[markokristof]

I use ZHA, tnx for the link.
my initial question was regarding the 6.7.9 - when do you plan to release it?

[MattWestb]

Its released https://github.com/arendst/Tasmota/tree/development/tools/fw_TubeZigbee_efr32
And the factory cooker was positing it for some mouths in this thread.

[MattWestb]

@s-hadinger or some other tasmota devs that have one hacked sonoff ZBB or USB-stick and like testing forcing end device to routers for not getting fast battery draining i have cooked one unsigned EZSP 6.7.9.0 with the patch that the factory is recommending plus direct children stetted to 0.

That is making the coordinator not accepting any children and they must using routers (so you is needing at least on router in the network).

I have not testing it then i dont have and ZBB but i have running one similar firmware on one LIDL / tuya LED stripe drive with the same chip for 3 weeks and its working OK

ncp-679CH.zip

Its only working on "hacked" Sonoff ZBB or the new USB-Stick then its not signed from the factory !!

[s-hadinger]

The solution works only on erased zbbridges so not easy to use for regular users

[MattWestb]

Yes but if its working its possible requesting one signed firmware with the same patching.
But i think its making no sin requesting firmware if its not being verified to working as intended.

[xsp1989]

@MattWestb @s-hadinger Please confirm which parameter configuration is incorrect and there is a problem. I can reissue the signed factory firmware for you, and you can also provide the ISC file for me to rebuild the firmware.

[MattWestb]

Thanks for your attention @xsp1989 !!

Its one try forcing end end device using routers instead off the coordinator by setting:
Plugins, Stack Library, Zigbee PRO Stack Library: Children Table Size = 0.
I have not putting in the button and LED so i think its better that you is cooking one firmware with all the "extras" that is being used in ZBB and the Stick.

I have trying setting the same parameter with command line parameter in ZHA/Zigpy/bellows but its looks that the stack is not changing it and using the parameters in the firmware.

Give the firmware one ending with "NC" or somthing so users easy can reconciling it easy.

As i was saying its one test and its not verified to working for users with the fast battery draining (48 Hours) that some user is still having but all that is possible is worth trying that can helping / solving the problems for our unhappy users.

Thanks in advance.

Mattias

[s-hadinger]

Isn't this parameter MAX_END_DEVICE_CHILDREN ?

If so it is set at startup by Tasmota and wouldn't require a specific firmware

[MattWestb]

I have trying setting it to 0 in ZHA / Zigpy / bellows with CLI commands and the NSP is saying OK and then i reading it back its still 32 (its the default in my NCP firmware) and i can joining end devices to the coordinator.
Also setting it in config file and restating ZHA its still possible (re)joining end devices to the coordinator.

Some of the setting in the NCP can being changed with host commands other is more hard coded but its not documented by Silabs.

Can you setting it to 0 (or 1 if you like trying more devices) and trying (re)adding one or 2 end device to the coordinator and see if its working (refusing end devices on the coordinator but OK on routers) ??

Mvh Mattias

[s-hadinger]

I will not be able to test before next week. If someone wants, it is set here

Tasmota/tasmota/xdrv_23_zigbee_7_0_statemachine.ino

Line 634 in dd624c3

ZBM(ZBS_SET_MAX_DEVICES, EZSP_setConfigurationValue, 0x00 /*high*/, EZSP_CONFIG_MAX_END_DEVICE_CHILDREN, 0x20, 0x00) // 5300111800

[MattWestb]

@xsp1989 Do you have possibility testing if the parameter is working without being set in the firmware ?

In ZHA is made with the config:

zha:
  zigpy_config:
    ezsp_config:
      CONFIG_MAX_END_DEVICE_CHILDREN: 0

I have trying one time but i was still able paring end devices to the coordinator and also the NCP was reporting the valiue from the firmware after it have being sett with commands from the host.

And also if you can trying doing the same with one firmware with Children Table Size = 0.

Thanks in advance

Mattias

[xsp1989]

I can set CONFIG_MAX_END_DEVICE_CHILDREN to 0 in the firmware, but I think this is not a good idea. If the user does not have a routing device, he cannot add any End device

[MattWestb]

Im very ware of that but then the user can using the normal 6.7.9.0 firmware and using only end devices and perhaps having the problems.

For user with some or meany routers i think i can helping then end devices dont have one complete zigbee stack, only one striped one (in Silans is leafe stack) that cant handle all problems so well as on full zigbee stack.

[chvvkumar]

Wanted to leave a comment that upgrading my Sonoff bridge to the following versions seems to have fixed the battery drain issue on my Ikea remotes.

Earlier, they were draining within a day but with the new firmware, they are holding up after 3 days:

ncp-uart-nsw_6.7.9_115200.ota
Tasmota 9.4.0 Leslie

[s-hadinger]

Thanks for reporting

[ascillato2]

upgrading my Sonoff bridge to the following versions seems to have fixed the battery drain issue

Thanks.

If the issue reappears, please open a new one. Thanks

[s-hadinger]

@MattWestb @xsp1989 CONFIG_MAX_END_DEVICE_CHILDREN can be set to zero at runtime by Tasmota. I will add this as an compile option, because I believe it's a dangerous feature for people who don't understand the implications.

No need for a specific firmware.

[MattWestb]

Great if its working.
I was trying setting it in ZHA/bellows but it was not override the configured in the NCP firmware.
And i agree with you is better doing it as one setting if the user like starting with only SED and later adding routers.

Have you testing if its working in real if having one or more routers and SED is not connecting to the coordinator ?

[s-hadinger]

Yes I tried, with no router, the end-device does not pair. It does pair with one router. PR is coming.

[MattWestb]

Great then its possible for user trying forcing SED using router then its possible and hopefully not getting problems with very fast battery draining.

[MattWestb]

I was doing little more testing in ZHA and its working setting the child to zero in the config (if doing it in the right place ;-) ) so no need for one separate firmware !!!

Its only one thing that is the same if setting in firmware or in config is that its not possible adding devices if not having one router already pared with the coordinator (must being one bug in EZSP).

I have putting it on my test network with many IKEA controllers and all was mowing to routers after restarting ZHA and waking the controller so it reconnecting to the mesh so its looks working OK only is if its helping the very fast (48 hours) battery draining problem or not.

[MattWestb]

I was looking thru EZSP 6.10.0.0 and have finding some interesting fixes not in the 6.10.0.0 but in the SDK:

• 703231 Fixed an issue in Power Manager on Series 2 devices where we could get stuck waiting for HFXO to be ready when a hardware request on HFXO was removed in the middle of the restore process in Power Manager.
• 675253 Fixed an issue in Power Manager where, if the HFXO startup failed while actively waiting for it to be ready in a critical section, we could wait indefinitely
• 697483 Fixed bug affecting CTUNE for HFXO on Series 2 devices.

The 2 first is not so likely being one problem then i think the NCP is not using sleep mode.
The last is coming back to the CTune problems with the hardware.

Do you like / can cooking one firmware for testing or shall i doing one or you ??
If you dont have the battery draining problems its not easy testing if its working or not.
Its still some users in ZHA that is complaining and having fast battery draining (48 hours) but i think the most is fixed with the CTune in 6.7.9.0.

I have running one LIDL LED stripe controller (with the same MG21 chip) with direct children = 0 for over one month and its looks working OK and all test end devices is using routers and cant using the coordinator.

[MattWestb]

Cooked and uploaded six ten with Tube0013 setting plus GP, NVM3, Max TC Link keys and so on.

Feel free testing it i dont giving any grantees and have not testing it (only the LIDL version).
It shall being flashed with SWD for getting the NVM3 to initiating OK for the firs time or changing the setting of the NVM3 size.

Not implanted LED and button for the Zigbee stick then its not the target (ZBB is) but shall working OK on it 2.

https://github.com/MattWestb/EFR32-FW/tree/main/Soff_EZSP

Edit: Its untested and i was having problem cooking one FW for tuya ZBGW that was compiling OK but not working and the same setting for IKEA Billy was working and after doing one new project in SS 5 it was start to working (new bugs in SS 5 with the updated tool changes) so no garantee that is working.