[RELEASE] IKEA Zigbee drivers

tbo3 · June 25, 2024, 4:12pm

First, was so excited to see the IKEA driver support, thanks! Picked up several of the devices and have been trying them out.

Hoping someone can point me in a direction to solve my problem with this STYRBAR Remote Control E2002. Got it paired and upgraded to 2.4.11, but the device has not be reliable with button 1 & 2 presses. So I thought, just delete the device & driver, reinstall the driver and then zigbee repair.

Basically my question is, HPM thinks the E2002 driver is installed, but its not and I can't get it reinstall because of this error. In the log says "Error retrieving driver source: groovy.net.http.HttpResponseException: status code: 500"

Provided some screen shots for context, any help would be nice.

Log error when using HPM to remove the E2002 driver:
Screenshot 2024-06-25 at 10.39.03 AM

Driver Code from Hubitat:
Screenshot 2024-06-25 at 10.39.53 AM

Using HPM to uninstall the E2002 driver, which is really not installed:

dandanache · June 25, 2024, 4:20pm

The good news: Use the "Repair" option in HPM to reinstall all the selected drivers in the package. This should fix your HPM problem.
The bad news: I upgraded my STYRBAR to 2.4.11 and it does not work properly anymore. I need to investigate more when I get a bit of free time. Edit: It works fine after a re-pair.

tbo3 · June 25, 2024, 4:57pm

Thanks for the info on the E2002, version 2.4.11, happy to have the other IKEA devices working thanks to the awesome drivers.

Tried the HPM Repair on the IKEA Zigbee Driver package, it downloaded and reinstalled everything without error, but the E2002 wasn't in the list and not available under Drivers Code.

However in HPM using the modify the IKEA Zigbee Driver package, it still has a green check on E2002, like it's installed. Confused. Is there a reconcile or manual method to uncheck the E2002? Would / Can I uninstall the IKEA Zigbee Driver package without causing harm to all the devices using the other IKEA Zigbee Drivers listed in Driver Code? Thoughts?

dandanache · June 25, 2024, 6:10pm

I was pretty sure that "Repair" would download the missing driver code. Looks like it doesn't.

You need to manually import the missing driver, then do a match up:

Drivers code -> New driver -> Import -> Paste the correct URL from the Readme/Manual install file -> Import -> Save
HPM -> Match Up -> Next -> Wait -> Next -> Check IKEA Zigbee Drivers -> Next
Profit!

tbo3 · June 25, 2024, 7:35pm

Thank you, the manual install was the magic sauce - the E2002 is working again! Now to see if it stays reliable.

tbo3 · June 26, 2024, 2:01pm

For reference, here is my problem I am having with the E2002 with version 2.4.11.
I can't make heads or tails of it... Hopefully this will provide insight.

Put the batteries in the E2002, button push works as expected, log shows button push and button controller app performs assigned action.
After E2002 is not used for a period of time, more than an hour, it will no longer register button push. Log shows button as HELD or RELEASED only. Sometimes there are additional errors in the log, related to pressing the buttons 1-4.

Note: Only buttons 1 & 2 are assigned to action in the button controller app.

[EXAMPLE 1]
dev:4202024-06-25 10:17:41.136 PMinfoSwitch Master Bedroom button 1 () was pushed [physical]

dev:4202024-06-25 10:17:32.993 PMinfoSwitch Master Bedroom button 2 () was pushed [physical]

[EXAMPLE 2]
dev:4202024-06-26 08:33:14.217 AMerrorSwitch Master Bedroom sent unexpected Zigbee message: description=catchall: 0104 0005 01 01 0040 00 F461 01 00 0000 05 00 09FF000D00, msg=[raw:catchall: 0104 0005 01 01 0040 00 F461 01 00 0000 05 00 09FF000D00, profileId:0104, clusterId:0005, clusterInt:5, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F461, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:05, direction:00, data:[09, FF, 00, 0D, 00], endpointInt:1, commandInt:5]

dev:4202024-06-26 08:33:12.326 AMerrorSwitch Master Bedroom sent unexpected Zigbee message: description=catchall: 0104 0005 01 01 0040 00 F461 01 01 117C 08 00 010D00, msg=[raw:catchall: 0104 0005 01 01 0040 00 F461 01 01 117C 08 00 010D00, profileId:0104, clusterId:0005, clusterInt:5, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F461, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:117C, command:08, direction:00, data:[01, 0D, 00], endpointInt:1, commandInt:8]

dev:4202024-06-26 08:33:11.346 AMerrorSwitch Master Bedroom sent unexpected Zigbee message: description=catchall: 0104 0005 01 01 0040 00 F461 01 00 0000 05 00 09FF000D00, msg=[raw:catchall: 0104 0005 01 01 0040 00 F461 01 00 0000 05 00 09FF000D00, profileId:0104, clusterId:0005, clusterInt:5, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F461, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:05, direction:00, data:[09, FF, 00, 0D, 00], endpointInt:1, commandInt:5]

dev:4202024-06-26 08:33:10.858 AMinfoSwitch Master Bedroom button 1 () was pushed [physical]

dev:4202024-06-26 08:33:10.425 AMerrorSwitch Master Bedroom sent unexpected Zigbee message: description=catchall: 0104 0005 01 01 0040 00 F461 01 01 117C 09 00 0000, msg=[raw:catchall: 0104 0005 01 01 0040 00 F461 01 01 117C 09 00 0000, profileId:0104, clusterId:0005, clusterInt:5, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:F461, isClusterSpecific:true, isManufacturerSpecific:true, manufacturerId:117C, command:09, direction:00, data:[00, 00], endpointInt:1, commandInt:9]

dev:4202024-06-26 08:33:07.875 AMinfoSwitch Master Bedroom button 2 () was released [physical]
dev:4202024-06-26 08:26:35.882 AMinfoSwitch Master Bedroom button 2 () was released [physical]

dev:4202024-06-26 08:26:34.666 AMinfoSwitch Master Bedroom button 2 () was held [physical]

dev:4202024-06-26 08:26:32.170 AMinfoSwitch Master Bedroom button 1 () was held [physical]

dev:4202024-06-26 08:26:28.808 AMinfoSwitch Master Bedroom button 1 () was released [physical]

dev:4202024-06-26 08:26:28.704 AMinfoSwitch Master Bedroom button 1 () was held [physical]

dev:4202024-06-26 08:26:25.608 AMinfoSwitch Master Bedroom button 1 () was released [physical]

dev:4202024-06-26 08:26:25.437 AMinfoSwitch Master Bedroom button 1 () was held [physical]

dev:4202024-06-26 08:26:20.125 AMinfoSwitch Master Bedroom button 1 () was held [physical]

dandanache · June 27, 2024, 4:31pm

These error messages appear when you hold and release the Right (3) / Left (4) buttons. These actions send some weird Zigbee messages, and are not implemented / supported by the driver. Maybe I should so something about this issue that keeps popping in the thread

Hold / release are supported only for button 1 () and button 2 ().

tbo3 · June 27, 2024, 9:28pm

Sorry for not being clear, all the physical actions are presses. They only register or show in the log as held/released.

picnicbob · July 3, 2024, 2:59pm

My hubitat updated to the latest version at midnight and started producing excess hub load errors for (method healthCheck) and (method parse) within a few hours. I only noticed because I wasn't receiving triggers today and went to investigate - I had to unplug the hub to restart it.
Edit: Hub was running 2.3.8.139. Upgrading to 2.3.9.158 now.

Logs

dev:82024-07-03 10:36:13.255 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 10:36:10.808 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 10:36:10.770 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 10:26:23.442 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 10:23:02.710 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 10:22:59.727 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 10:22:59.676 AMinfoPARASOLL - Front Gate is open [physical]

dev:52024-07-03 10:00:00.412 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 10:00:00.403 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method healthCheck)

dev:62024-07-03 10:00:00.401 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 10:00:00.401 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method healthCheck)

dev:52024-07-03 09:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 09:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method healthCheck)

dev:62024-07-03 09:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 09:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 08:51:42.324 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:50:49.954 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:50:49.943 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 08:49:45.256 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:49:12.000 AMinfoPARASOLL 4 current group bindings: None

dev:52024-07-03 08:49:11.998 AMinfoPARASOLL 4 current device bindings: None

dev:52024-07-03 08:49:00.932 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:49:00.922 AMinfoPARASOLL 4 battery is 48% full [physical]

dev:52024-07-03 08:48:59.931 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:48:57.904 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:48:56.995 AMwarnPARASOLL 4 [IMPORTANT] Click the "Refresh" button immediately after pushing any button on the device in order to first wake it up!

dev:52024-07-03 08:48:56.992 AMwarnPARASOLL 4 refreshing device state ...

dev:52024-07-03 08:48:53.977 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:48:53.966 AMinfoPARASOLL 4 battery is 48% full [physical]

dev:82024-07-03 08:48:53.927 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 08:48:53.919 AMwarnPARASOLL 4 rejoined the Zigbee mesh; refreshing device state in 3 seconds ...

dev:82024-07-03 08:48:53.890 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 08:39:06.209 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:39:02.973 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:39:02.937 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 08:26:01.911 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:25:59.079 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:25:59.042 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 08:05:02.673 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:04:55.725 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method parse)

dev:82024-07-03 08:04:55.711 AMinfoPARASOLL - Front Gate is open [physical]

dev:82024-07-03 08:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method healthCheck)

dev:62024-07-03 08:00:00.434 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 08:00:00.430 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method healthCheck)

dev:52024-07-03 08:00:00.427 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 07:19:57.692 AMinfoPARASOLL - Pool Gate current group bindings: None

dev:72024-07-03 07:19:57.690 AMinfoPARASOLL - Pool Gate current device bindings: None

dev:72024-07-03 07:19:46.629 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method parse)

dev:72024-07-03 07:19:45.642 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method parse)

dev:72024-07-03 07:19:43.626 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method parse)

dev:72024-07-03 07:19:42.865 AMwarnPARASOLL - Pool Gate [IMPORTANT] Click the "Refresh" button immediately after pushing any button on the device in order to first wake it up!

dev:72024-07-03 07:19:42.863 AMwarnPARASOLL - Pool Gate refreshing device state ...

dev:72024-07-03 07:19:39.701 AMwarnPARASOLL - Pool Gate rejoined the Zigbee mesh; refreshing device state in 3 seconds ...

dev:62024-07-03 07:13:03.387 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method parse)

dev:62024-07-03 07:13:03.375 AMinfoPARASOLL - Back Gate is open [physical]

dev:52024-07-03 07:12:16.673 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:62024-07-03 07:08:59.074 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method parse)

dev:52024-07-03 07:01:34.005 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method parse)

dev:62024-07-03 07:00:00.408 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 07:00:00.409 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 07:00:00.403 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method healthCheck)

dev:52024-07-03 07:00:00.403 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 06:02:38.452 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method parse)

dev:62024-07-03 06:00:00.446 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 6 generates excessive hub load on line 661 (method healthCheck)

dev:72024-07-03 06:00:00.446 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 7 generates excessive hub load on line 661 (method healthCheck)

dev:52024-07-03 06:00:00.446 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 5 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 06:00:00.446 AMerrorcom.hubitat.app.exception.LimitExceededException: Device 8 generates excessive hub load on line 661 (method healthCheck)

dev:82024-07-03 05:28:03.582 AMinfoPARASOLL - Front Gate battery is 52% full [physical]

dev:62024-07-03 05:01:48.442 AMinfoPARASOLL - Back Gate battery is 52% full [physical]

dev:82024-07-03 04:45:57.032 AMinfoPARASOLL - Front Gate current group bindings: None

dev:82024-07-03 04:45:57.031 AMinfoPARASOLL - Front Gate current device bindings: None

dev:82024-07-03 04:45:45.967 AMinfoPARASOLL - Front Gate battery is 53% full [physical]

dev:82024-07-03 04:45:42.305 AMwarnPARASOLL - Front Gate refreshing device state ...

dev:82024-07-03 04:45:39.227 AMwarnPARASOLL - Front Gate rejoined the Zigbee mesh; refreshing device state in 3 seconds ...

dev:62024-07-03 02:12:28.814 AMinfoPARASOLL - Back Gate is closed [physical]

dev:52024-07-03 01:30:48.353 AMinfoPARASOLL 4 current group bindings: None

dev:52024-07-03 01:30:48.351 AMinfoPARASOLL 4 current device bindings: None

dev:52024-07-03 01:30:33.399 AMwarnPARASOLL 4 [IMPORTANT] Click the "Refresh" button immediately after pushing any button on the device in order to first wake it up!

dev:52024-07-03 01:30:33.396 AMwarnPARASOLL 4 refreshing device state ...

dev:52024-07-03 01:30:30.354 AMwarnPARASOLL 4 rejoined the Zigbee mesh; refreshing device state in 3 seconds ...

dev:62024-07-03 12:12:14.890 AMinfoPARASOLL - Back Gate battery is 53% full [physical]

app:352024-07-03 12:00:14.111 AMdebugUpdates found package for https://raw.githubusercontent.com/dan-danache/hubitat/main/zigbee-map-app/packageManifest.json -> null (force production: true)

app:352024-07-03 12:00:14.109 AMdebugUpdates found for package https://raw.githubusercontent.com/dan-danache/hubitat/main/zigbee-map-app/packageManifest.json

app:352024-07-03 12:00:14.016 AMinfoChecking for updates for Zigbee Map

app:352024-07-03 12:00:14.014 AMdebugUpdates found package for https://raw.githubusercontent.com/dan-danache/hubitat/main/ikea-zigbee-drivers/packageManifest.json -> null (force production: true)

app:352024-07-03 12:00:14.009 AMdebugUpdates found for package https://raw.githubusercontent.com/dan-danache/hubitat/main/ikea-zigbee-drivers/packageManifest.json

app:352024-07-03 12:00:13.905 AMinfoChecking for updates for IKEA Zigbee drivers

app:352024-07-03 12:00:13.782 AMinfoChecking for updates for Hubitat Package Manager

app:352024-07-03 12:00:13.343 AMinfoRefreshing repository list

JustinL · July 13, 2024, 9:14pm

I’ve just installed your driver for Aqara Dual Relay Module T2 (DCM-K01). Thanks for putting that together! It’s working as I think you intended it. But is there any way that the driver could know the actual state of the S1 switch (as separate from the state of the relay R1)? I suppose a virtual switch could try to keep track via the button presses, but as soon as it gets out of sync (perhaps after a power outage, etc), then it’s going to get messed up. So, any way for the driver to represent the true state of the S1 switch? Thanks!!

dandanache · July 13, 2024, 9:53pm

I think I know what you are trying to achieve, but unfortunately, the device does not keep the state of the S1 switch, as it does not need it. It just needs to know that the COM+S1 contact was toggled (open/close) so that it can either toggle the state of the L1 relay, or trigger a "pushed" event (in the "decoupled" mode).

I think for your situation, a smart door/window/contact smart sensor is required, as it knows and reports the state of the contact (open/close). I use the IKEA PARASOLL for turning on the lights when the dressing room is opened.

Sorry.

nbrew · August 7, 2024, 2:18pm

Hey, this post came up on a Google search. I wanted to report that the E1744 / Symfonisk 1st gen sound controller puck seems to work with the built-in TRADFRI sound controller driver. I was able to get TRADFRI gateway-like control for my SYMFONISK speaker with the following rules in Rule Machine:

Trigger: When Symfonisk controller level changes

Actions:
1. Set Local Variable `volumeLevel` to Symfonisk controller level
2. Control Music Player -> Sonos device -> Set Volume -> %volumeLevel%

You just need to create a new variable within the rule that maps the puck attribute to the volume control.

I also wanted to say that this set of community drivers is a godsend. I was very frustrated last year with an IKEA bulb where I couldn't get the colour mapping right, and everyone seemed to be up in arms that it wasn't possible. However, this is perfect!

DocNaes · August 20, 2024, 4:39pm

Unsure if I should chime in here or make a new help post…
Been using this community driver for some IKEA Zigbee Rodret and Stryker remotes to control some smart wing Z-wave blinds. Everything seems to work fine, but one of my Rodret remotes triggers a false button 2 push once a day every day, and closes the blinds. It’s always around the same time of day, but I don’t think it’s always the exact same time. The other Rodret does not do this. Logs indicate that the “physical button” was pushed.

Any ideas how to troubleshoot this? I’ll attach a screenshot of the device settings. The event was the 10:18 one that shows as the last device activity in the screenshot.

hydro311 · August 20, 2024, 4:43pm

If you use Alexa, ensure the Alexa "Hunches" option is disabled/off.

dandanache · August 20, 2024, 5:37pm

First try to see if there are any physical conditions that might cause the ghost clicks, like warped plastic, swollen battery, etc. If it happens around the same time of day, maybe the sun is heating the plastic / the button contacts. You can also replace it if you think it's defective; IKEA has a good return / replace policy.

Then, you can try to update the firmware, mine are at 1.0.57, maybe the update fixes it, maybe not. The update can be done directly from Hubitat (see first post) and takes around 1.5 hours.

Searching the Internet, I also found this post where the ST driver author implemented a fix for ghost events. Hope I don't need to also do it I also found my name on that thread .

Note: I don't use the Rodrets so much anymore as I've settled for the Symfonisk Gen2 remotes instead.

sstratmoen · September 14, 2024, 3:51pm

Apparently now a version of the smart plug with energy monitoring are in the stores, known as the INSPELNING

dandanache · September 14, 2024, 4:43pm

I saw the chatter about it on Reddit, seems like it's already available online in the US and Norway.

I'll add a driver for it as soon as I can get my hands on one. Thanks!

rgr · September 24, 2024, 2:54am

@dandanache I have been using your driver for a Parasoll (E2013) contact sensor I bought a few months ago.

I have a request for you, although your driver is simple enough that works well, it would be very helpful if you can add two buttons to set the state open or closed.

There are some situations where there is a power outage, and when power is restored and the state of the device changed in-between, it will show the wrong state, so the user can set a RM rule to toggle the state to correct it.

Thank you for your help.

dandanache · September 27, 2024, 3:38pm

I am somewhat reluctant to add add this functionality to the driver, unless there is no other way.

I did some digging and, for instance, if you have the contact closed, then remove the battery, open the contact, and reinsert the battery, the driver catches the "network join" message from the device and automatically executes a state refresh, so it will show "contact = open" in the end. I could implement a similar state sync if the device also sends some sort of Zigbee message when the hub comes back to life after a power outage (battery-powered devices get out of the Zigbee panic mode). Need to do some testing for this theory, but I don't have a development hub, so I would need to "bring down the house" to test it

Another way to go at this situation is to create a "puppet master" app that will alter the current state for its configured devices.

rgr · September 28, 2024, 3:03pm

Wow! I didn’t know this sensor had this capability

The behavior I didn’t like was precisely the one you described, The sensor changing state when disconnected and then not updating.

The purpose of my request was precisely to be able to correct the state when something unexpected happens, such as a blackout or power outage.

This is something I have done with other Contact Sensors in this situation, with the help of a RM rule I wrote.

But what you propose is much better than my suggestion.

Looking forward to test the results of your modifications, in case you decide to go ahead with it.

Thanks in advance for your feedback.