Philips Hue Dimmer switch battery running down rapidly (ZbBridge)

pingel20 commented 3 years ago

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!

[x] Read the Contributing Guide and Policy and the Code of Conduct
[x] Searched the problem in issues
[x] Searched the problem in discussions
[x] Searched the problem in the docs
[x] Searched the problem in the chat
[x] Device used (e.g., Sonoff Basic): Sonoff ZbBridge
[x] Tasmota binary firmware version number used: 9.2.0.1
- [x] 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`:
```lua
  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:
```lua
  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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

OK, fine.

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

ascillato commented 3 years ago

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 commented 3 years ago

Thank you for the explanation.

pingel20 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

Re-opening to track progress on this.

MattWestb commented 3 years ago

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 https://github.com/arendst/Tasmota/issues/9316#issuecomment-698219617 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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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. https://github.com/grobasoz/zigbee-firmware/issues/2#issuecomment-759955465

S37 and hex is also made if needed.

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

MattWestb commented 3 years ago

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

MattWestb commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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}}

arendst commented 3 years ago

For some reason the firmware upload from Tasmota failed to update it, so I did a remote XMODEM transfer.

Verified the upload fails. I will investigate.

MattWestb commented 3 years ago

Great news Stepan and also that arendst is trying getting it installed and hopefully also the (no existing) problem with the GUI firmware updating problem solved.

If its going well i like to recommending all sonoff zigbee bridge users in ZHA to updating to the 6.7.8.0 but then i dont have the hardware and its need some more to verifying that its working before doing it for eliminating massive user problems in tasmota.

I was kindly requesting one new unsigned firmware for sonoff zigbee bridge from our cooker then i also was needing one for my "IKEA Billy EZSP" and Gary was very kindly doing one for Tasmota for the Sonoff Zigbee Bridge.

I was thinking that Tasmota was requesting one new signed firmware from the factory then its one pure tasmota thing and have nothing to do with my "IKEA Billa EZSP" but its looks like i have misunderstanding somthing essential here with tasmota.

But as I was the first to kindly requesting the factory for the first signed firmware for the Sonoff Zigbee Bridge i was opening one issue for requesting one updated EZSP 6.7.8.0 for tasmota. https://github.com/xsp1989/zigbeeFirmware/issues/3#issue-787808213.

By the way i was doing one PR for one good reference collection for EZSP documents from Silabs community https://github.com/arendst/Tasmota/pull/10596#issue-556366124 and if you both dont like it i can deleting it.

And if needed its also possible using ESPHome for updating the firmware in the SM-011: https://github.com/zigpy/zigpy/discussions/586#discussioncomment-289144 (Custom Ethernet ESP32 with SM-011 module)

regards Mattias W

s-hadinger commented 3 years ago

@xsp1989 Would you be kind enough to provide 6.7.8 EZSP for ZBBridge signed firmware?

It fixes an important bug for IKEA remotes.

s-hadinger commented 3 years ago

For some reason the firmware upload from Tasmota failed to update it, so I did a remote XMODEM transfer.

Verified the upload fails. I will investigate.

The upload will fail with a stock Zbbridge. The unsigned firmware needs a zbbridge that has been programmed with SWD probe. So you don't need to spend time on this

arendst commented 3 years ago

That could well be the case! I see the file is transferred completely but it's final check is not returned as a valid upload.

Thx. Will wait for the correct binary.

xsp1989 commented 3 years ago

https://github.com/xsp1989/zigbeeFirmware/blob/master/firmware/SM-011/ncp-uart-sw_6.7.8_115200.ota

I have updated the ncp firmware。Please test it

MattWestb commented 3 years ago

Now arendst can do one more try :-))

s-hadinger commented 3 years ago

@xsp1989 You are a legend. Awesome!

s-hadinger commented 3 years ago

Flashing v6.7.8 went ok through the normal process. Everything seems to be working.

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

MattWestb commented 3 years ago

Great then its interesting to see if its setting up the pull control OK so sleeping end devices can going down in long pull and not draining their batteries.

And flashing was going well on the untouched Sonoff i expect :-)

Should we waiting to recommending user up / downgrading the firmware ? I think its better than the older made versions 6.5.5, 6.7.6, 6.8.01 and 6.8.2.0 if not silabs have putting in some new nasty bugs but i think its pretty good proven then was released for nearly 3 months ago.

s-hadinger commented 3 years ago

Let's give us a few days of testing before advising to upgrade

MattWestb commented 3 years ago

Sounds like one good thing and getting the feeling its working well and not having strange behaviour like the 6.8 ones :-))

hatchetation commented 3 years ago

v6.7.8 is working here, no regressions seen. (Wasn't affected by this specific bug.)

I couldn't upgrade the firmware at first. Think it was because the ZHA ZBBridge template config (described here) was interfering with the firmware update process. Temporarily switching to the default module Sonoff ZbBridge (75) allowed the update to complete.

MattWestb commented 3 years ago

I think its the ser2net is trying hijacking the comport if having the ZHA ZBBridge profile loaded and the rule for starting the TCP server in tasmota. Perhaps possible deleting / disabling the rule can being enough. Then loading the profile 75 the ser2net cant starting then the normal com pins that ser3net is using is not configured in profile 75.

@s-hadinger and @arendst is it possible killing the ser2net server then starting the firmware upgrade of the SM-011 module in one easy (do not being nice) ??

alexhk commented 3 years ago

I updated to v6.7.8 on Tasmota 9.2.0.4 yesterday at 14:50, today at 17:00 I had to replace 3 batteries (2x E1743 and 1x E1810) on remotes of which I just replaced the batteries yesterday around the same time I upgraded.

So, I am afraid but the drain doesn't seem to be solved with v6.7.8, on my end at least.

PS: I just moved to the Sonoff zbBridge from Conbee II (couldn't get it to directly bind remotes to lights and requires too many resources/computer IMHO) and after trying the IKEA coordinator. I hope I don't have to move back, I am more of a Tasmota person (dozens and dozens of Tasmota devices, also successful zbBridge/Tasmota at another location but without IKEA stuff).

PPS: I am also using a iluminize 511.210T LED driver w/dimmer in the same network, which throws a few too many errors for my taste. Maybe some others experiencing the problems have similar devices in their zigbee network? Strange is that a few other remotes which are near my coordinator (and probably connect to it directly or via closer bulbs) didn't drain overnight.

MattWestb commented 3 years ago

@alexhk Did you doing one "configure this device" from the device card for the remotes ? Its needed for getting the missing configuration being corrected after the new firmware is flashed or the devices is doing as before the update (draining there batteries).

If you like being on the safe side you can doing the reconfigure on all devices for being on the safe side but i dont knowing how large your network is.

Edit: Sorry i was thinking you was running it on ZHA so not possible boing the reconfig.

For Tasmota i think its best repairing the switches so they is getting the new OK configuration.

alexhk commented 3 years ago

@MattWestb

I am on Tasmota, yes. Tasmota-zigbee 9.2.0.4 and new fw v6.7.8. It's a test network with only

I just had to change another battery on the E1810 TRÅDFRI Remote, it was just changed yesterday. So E1810 fully drained (very close to coordinator, 4-5 meters only), one E1743 down around 15% (distance to coordinator around 10 meters), the second E1743 no drain (furthest away from coordinator, around 15 meters).

I believe the IKEA battery drain issue is not fixed, but I guess that it is somehow related to how (or through what) the remotes connect.

I'll try to force the two remotes with drain through some other device (ie. light or wallplug) and see how that works out.

-- // --

Something seemingly unrelated, but I have a feeling connecting through routers or the lack of connecting through routers could be connected to this issue:

How to Build a Solid Zigbee Mesh https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Zigbee_Mesh

Avoid adding Zigbee lightbulbs to your hub in combination with other Zigbee devices, since the lightbulbs will try to act as routers, but unfortunately they only perform this role properly with other lightbulbs. The exception we have found are Sengled Zigbee lightbulbs, which do not try to take on the role of repeating other Zigbee devices. Zigbee light bulbs do not have issues routing among themselves, therefore a good alternative is a separate Zigbee network via a compatible bridge such as the Philips Hub Bridge, or a second Hubitat Elevation hub with only Zigbee lightbulbs paired to it. This will avoid this issue of bulbs attempting, and subsequently failing to repeat signals for other devices, by establishing two separate and stable Zigbee networks. NOTE: Devices on a separate Zigbee network cannot repeat signals for devices on the main Zigbee network.

MattWestb commented 3 years ago

First the battery problems. Then you have some remotes that was "more normal" that is longer away from the coordinator is it likely that these remotes is not connected to the coordinator and is not having the problems. Try getting the remotes not using the coordinator thru pairing the device nerar on router device if possible. IKEA remotes is changing there parent if they is finding one better so its not 100% they is staying if not having one router in the near.

Can you pairing one of the "problem remote" with your deCONZ (or wath system you is having to it) and testing if its normal or hungry ?

I have one RaspBee in deCONZ but only on first gen EFR32 that is very likely not having this problem so its useless for my tor trying (I have moved one E1743 to deCONZ for one week ago but its the same as on EZSP = no battery eater).

Now to the understanding how one mesh network working. If you is having one Xiaomi sensor (no zigbee 3 ones) and its connected to the coordinator and you is rebooting it and the Xiaomi like talking to it and cant getting contact with it its leaving the network for 110% and dont coming back. If you have good router devices (not good is old OSRAM plugs and many more) that can talking Zigbee 3:sh and not grave interference its being very stable and also can rerouting if its getting local problems. And if sleeping end devices is having one good router in near the can using lesser power and spending lesser time measuring radio signals for communicating and much lesser risk the is leaving the network. I have around 10 sensors that is being online for over 2 years but its not possible getting them longer because they need new batteries. The key is building one good "backbone" in the network with good routers and then connecting sensors to them. And its gets users with 150+ most IKEA lights and have no problems with sensors.

And one more interesting thing is that the Sengled lights is also using EFR32 chips = IKEA, tuya, new Philips HUE and new Sonoff devices so i dont believe its good / bad only if they is having very bad antennas (most IKEA have good antennas and the radio is on of the best on the chip) and is working as old CC-253 chips (old OSRAM and many more= very bad radio performance).

You is one of the fue user that can triggering the problem and also can testing your remotes in different configuration that is known working OK !!

s-hadinger commented 3 years ago

I haven't seen any significant battery drain with my IKEA remote since I upgraded to 6.7.8. There is definitely a big improvement.

MattWestb commented 3 years ago

Great Sephan ! Its looks like ZHA users is also getting it working better in combination with configuring the device after changing batteries. The reconfiguring on device in ZHA is setting up attribute reporting and pull control in the sleeping end device so it can going down from fast pull (then pairing / configuring the device) to long pull (normal sleeping between pulling its parent). Do you having some command like this in tasmota ? or can you implaning it ? Also can you taking one more look if tasmota is setting up the pull control OK on sleeping end devices ?

If the paring was OK and changing the binding of one remote / steering device i recommend doing one reconfig so both the pull control and attribute reporting is working OK or the devices is not reporting OK to ZHA (days instead or some hours).

And zigbee standard is saying that attribute reporting shall being made after groupe (is setted up / changed) binding is made or its likely not working (or can doing bad things then its broken if the firmware is not playing OK with it).

deCONZ have doing changes in pull control setup because smartthings and IKEA was having the same problem with fast draining batteries.

As normal its one step forwards but my feeling is that its more small things that is playing together that is doing the problems and "its not easy to see the tree because of the (black) forest". But i think its slowly getting in the right direction but need more input from user that is / was having problems.

s-hadinger commented 3 years ago

There is no such option in Tasmota, and I don't think we actually need it. These devices are behaving well by default.

For example the IKEA Remote (Round 5 buttons) is sending one packet every 5 minutes and waits for simple ACK from the coordinator. Unfortunately this event is not shown in the EZSP interface.

MattWestb commented 3 years ago

If needed its always possible sniffing little around but for my its not so easy then having 3 active zigbee network and 2 more temporary test networks so its little noisy in the air ;-)

If you is doing more interesting observations pleas posting it !!

Hope tasmota is getting the problem solved on sonoff zigbee bridge and being stabile and that the firmware update is helping in the long run getting there.

I keeping one eye on EZSP updates if its coming more that can helping and pinging you is i finding somthing interesting.

alexhk commented 3 years ago

@s-hadinger @MattWestb

Yesterday 2 more batteries changed, and today 1 other IKEA remote finally fully drained (lasted a few days vs. 24h).

I hope we can figure this out since I believe despite 6.7.8 there is some other factor causing battery drain. I don't need this working urgently, so I don't mind changing batteries daily until we know what is going on.

Changed to fresh batteries.
Unplugged 2 old Osram plugs after @MattWestb comment.
I made sure all remotes connect through (Ikea) routers, not directly to bridge.
I positioned the bridge and paired repaired devices so that they talk to IKEA device router, not directly to coordinator.
Remotes paired to bulbs via group. Also using zBListen. ZbSend {"device":"LED_Livingroom1","Send":{"AddGroup":102}} ZbBind {"Device":"IKEA_Dimmer_Remote1","ToGroup":102,"Endpoint":1,"Cluster":6} ZbBind {"Device":"IKEA_Remote2","ToGroup":102,"Endpoint":1,"Cluster":6} ZbListen2 102
Two remotes which need new batteries every 24h are grouped to a Iluminize LED dimmer driver (zigbee 3.0). Seems they are actually Sunricher OEM devices (deconz reported them as Sunricher IIRC). https://www.sunricher.com/50w-constant-current-zigbee-led-dimmable-driver-srp-zg9105-50w-cc.html https://www.iluminize.com/de/shop/led-steuerung/led-controller/product/597-511-210t-zigbee-vorschaltgeraet-200ma-1500ma-230v-50w.html
Remotes that gave up today (batteries lasted a few days) are grouped to an IKEA bulb, it's also connected via the same Ikea bulb as router.

Here's the map:

Note: A Ikea Wallplug (powered) seems to have disconnected overnight. I might try to replace the USB Signal Extender with a IKEA Bulb but of course the above map was only the latest topology I tested.

If we figure this out we could remove factors that cause battery drain problem, and eventually hopefully find a way to fix it or at least be aware what has to be avoided.

If there is no need for this kind of debugging let me know and I will move back to Deconz for now. But: I have 3 Sonoff zigbee bridges with Tasmota and I planned to use them for good!

alexhk commented 3 years ago

Well, another day another set of batteries.

Moved the IKEA remotes (and lights) back to conbee2 and deCONZ yesterday, still going strong a day later.

MattWestb commented 3 years ago

Pleas report back how its going in deCONZ.

I was not having any problem with my RaspBee I with IKEA remotes in deCONZ but all is in ZHA with IKEA Billy EZSP for 6 mount now and no problems if configuring the pull control.

And thanks for info !!!

hatchetation commented 3 years ago

It took me a few days to realize all my E1743s were dead. :/ So, I can reproduce.

After replacing batteries a couple days ago, I carefully reconfigured and got everything back online. Haven't killed any batteries yet. I'm watching power levels and debug logs.

Poked around the Poll Control cluster - all values seem sane. Overnight, a few (maybe) interesting things:

Duplicate TSN warnings. Mostly from the Tradfri devices (E1743s, and bulbs), but also from my RGB Genie remote.

[homeassistant.components.zha.core.channels.base] [0xBEEF:1:0x0020]: command failed: 'checkin_response' args: '(True, 8)' kwargs '{'tsn': 85}' exception: 'duplicate 85 TSN'

ZHA seems to compulsively call set_long_poll_interval with every checkin response. (55 minutes). Needed? Does this actually hit NVRAM on the Tradfri device? [homeassistant.components.zha.core.channels.base] [0xBEEF:1:0x0020]: executed 'set_long_poll_interval' command with args: '(24,)' kwargs: '{}' result: [2, <Status.SUCCESS: 0>]

Is there anyway to diagnose short polling without sniffing? I'm still trying to understand the interaction between these MAC tunables and application-level polling being exposed in zb clusters like this.

MattWestb commented 3 years ago

I was having some E1743 that was not reporting battery (in 24 H) and was comparing the pull control settings with working one and it was different so i was starting doing the reconfigure thing on them then having changing binding and so on and its is working for 2 month now.

TSN = transaction number. In Zigbee all direct commands sensed is unicast (no broadcast /group commands). For knowing if its have being revived the receiver shall sending one defaultresponse so the sender is knowing its was successful transmitted. If not getting one defaultresponse i right time frame the sender is re sending the same message with the same TSN and the receiver is ignoring the new one if it have receiving the same message with the same TSN (duplicate = already revived = OK). I think its because its one sleeping end device its sleeping little long some time and dont getting the defaultresponse and re sending the last message so i think its OK is its not every time its sending commands. (in both directions device <=> coordinator) All "normal"zigbee commands is acks being done in the stack only commands to no standard cluster (manufacture cluster) must being made in the application that is using that cluster (tuya TRVs have large problems if not doing it on the tuya cluster) and there remotes is sending double message and is locked for some secunds if not getting one defaultresponse).

I have seeing short pull being activated then pairing devices and the its timing out and going down to long pull intervals (if its OK configurated).

The "repairing then battery is empty" can being 2 thing. First every transaction have one transactions number and one counter so all devices is knowing if it have receiving it and if it have sending it to its neighbors. The devices stack is checking every message so its not sending it back to sender or more times for not getting one message going around in the mesh for infinite time. The device must saving this counters for all links (one counter for every neighbors) so its being in sync after one reboot of the device or it cant communicating with its neighbors. Its also one large security mechanism for making replay attacks is some have sniffed your network key (can sending commands with the right network key but the devices is ignoring it if the counter is out of sync. If the battery level is to low so the device cant saving the counters in the NVRAM (perhaps also erasing flash pages is not working OK) and is getting one new battery it cant communicating with its neighbors then the link counters is out of sync. It can also being that the network credential is being corrupted in the NVRAM because of the very low battery and flash writes / page erasing not working OK. I have getting it also on my IKEA GW with one remote but normally its only happens then 100% drained batteries. And its not so frequently hitting the user (compared with the "X-Sonoff fast draining syndrome".

The repairing thing is in the device firmware and Silabs have finding more bugs that can doing it but its still there until IKEA is doing one new one (not only IKEA all Silabs based devices like tuya, smartthings, new sonoff and so on) but its not happening so frequently (its millions of devices delivered out there with "old" firmware) but we can see it and with the fast draining but it was more frequently seen then (2 days instead of 2 years between battery changings).

You need sniffing then its in the very low level and is done between the router and the sleeping end device and the coordinator is not seeing it at all. On the MAC level sleeping end device is pulling its parent for new messages that the parent router have stored for it then its having the device as one child in its neighbor table. Pull in ZHA is not the same as in the MAC level (low level you cant see and in the application level you can see in the logs).

The "sonoff bug" was that the coordinator was setting up the long pull control falsely and the device was trying going down to long pull but was not possible then it was wrong configurated so its stayed in short pull interval for infinite = no sleeping and battery draining.

If you is having one ERF32 with EZSP you can using it as one sniffer but not at the same time its in the network (as coordinator or router). Look on the Z2M sniffing page :-))

Great observations you have making and its helping understanding the problems (it more then one here) and helping our devs finding one solution for our systems !!!

alexhk commented 3 years ago

No problems so far with the IKEA remotes on deCONZ, it has been 5 or 6 days.

I also finally figured out to bind my remotes the LED panel when I moved back.

I just wish I wouldn't need this step since deCONZ is a massive overhead IMHO, Tasmota on the Sonoff ZigBee bridge would be so much easier.

arendst / Tasmota