I made a documentation video on how to get the Lidl powerstrip configured using Zigbee2MQTT on OH3.
Setting up Zigbee2MQTT is not covered, but that’s well documented here: | Zigbee2MQTT
Hope it helps. There were a few tricky things, like getting the right values and needing the JSON transformation to read back the status of the sockets, but it’s working brilliantly now.
/M
Hello Marlow, thank you for the tips. I just completed configuration of the power strip I bought this morning at the local Lidl store, french version, using OpenHAB 2.5.9 running on a raspi + CC2531 zigbee dongle, working like a charm after an update of zigbee2mqtt. Obviously, the previous version of z2m I installed back at the beginning of November was not enough.
So after quite some time I got a chance to test the Elelabs Zigbee USB together with Windows/Door Sensor on new freshly installed v3. After initial problems with openhab not being able to connect to the attached USB dongle it suddenly started working and I was able to add the Windows/Door Sensor and its channels.
Now you have a choice - buy it for EUR 22.95 or for EUR 29.99. 
HW: Silvercrest power strip, 3 sockets, IEEE address 804B50FFFEE11DD7
SW: openhabian 3.2.0-SNAPSHOT - Build #2583, OH Zigbee binding, Ember Coordinator @ 6.7.8.0
Problem:
All three sockets can be individually switched on and off, ‘All sockets on’ works, but ‘All sockets off’ doesn’t work (no reaction).
openhab> zigbee nodes
Total known nodes in network: 5
Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model
0 0000 5C0272FFFE4BC7B4 COORDINATOR ONLINE
14589 38FD 60A423FFFE139306 ROUTER ONLINE 11 ZIGBEE_HOME_AUTOMATION ON_OFF_PLUG_IN_UNIT _TZ3000_kdi2o9m6 TS011F
242 ZIGBEE_GREEN_POWER 0061
17296 4390 00158D00012E5426 ROUTER UNKNOWN 1 ZIGBEE_HOME_AUTOMATION EXTENDED_COLOR_LIGHT MLI tint-ExtendedColor
242 ZIGBEE_GREEN_POWER 0061
49993 C349 804B50FFFEE11DD7 ROUTER ONLINE 1 ZIGBEE_HOME_AUTOMATION ON_OFF_PLUG_IN_UNIT _TZ3000_1obwwnmq TS011F
2 ZIGBEE_HOME_AUTOMATION ON_OFF_PLUG_IN_UNIT
3 ZIGBEE_HOME_AUTOMATION ON_OFF_PLUG_IN_UNIT
242 ZIGBEE_GREEN_POWER 0061
63671 F8B7 00178801094009C0 ROUTER UNKNOWN 11 ZIGBEE_HOME_AUTOMATION DIMMABLE_LIGHT Philips LWA009
242 ZIGBEE_GREEN_POWER 0061
openhab> zigbee fingerprint 804B50FFFEE11DD7
|>| Node Descriptor
| |> Logical Type ROUTER
| |> MAC Capabilities [FULL_FUNCTION_DEVICE, MAINS_POWER, RECEIVER_ON_WHEN_IDLE]
| |> Stack Compliance 22
| |> Server Capabilities []
| |> Buffer Size 82
| |> Incoming Transfer Size 82
| |> Outgoing Transfer Size 82
|
|>| Power Descriptor
| |> Available Power Sources [MAINS]
| |> Current Power Source MAINS
| |> Current Power Mode RECEIVER_ON_IDLE
| |> Power Level FULL
|
|>| ZDO
| |> ManagementBindRequest SUCCESS
| |> IeeeAddressRequest SUCCESS
| |> ManagementLqiRequest SUCCESS
| |> ManagementRoutingRequest SUCCESS
|
|>| Basic Information
| |> Generic Device Class
| |> Generic Device Type
| |> Manufacturer Name _TZ3000_1obwwnmq
| |> Model Indentifier TS011F
| |> Product Code
| |> Product URL
| |> Date Code
| |> Application Version 69
| |> Software Build ID
| |> Hardware Version 1
| |> Zcl Version 3
| |> Stack Version 0
| |
| |>| Endpoint 1
| | |> Profile 0104 ZIGBEE_HOME_AUTOMATION
| | |> Device Type 010A ON_OFF_PLUG_IN_UNIT
| | |> Device Version 1
| | |
| | |>| Input Clusters
| | | |
| | | |>| Cluster 0000 Basic
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 ZCL Version
| | | | | |> 0001 Application Version
| | | | | |> 0002 Stack Version
| | | | | |> 0003 HW Version
| | | | | |> 0004 Manufacturer Name
| | | | | |> 0005 Model Identifier
| | | | | |> 0006 Date Code
| | | | | |> 0007 Power Source
| | | | | |> FFDE Unknown
| | | | | |> FFFD Unknown
| | | | | |> FFFE Unknown
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0005 Scenes
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 Scene Count
| | | | | |> 0001 Current Scene
| | | | | |> 0002 Current Group
| | | | | |> 0003 Scene Valid
| | | | | |> 0004 Name Support
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 0006 On/Off
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 On Off
| | | | | |> 4001 On Time
| | | | | |> 4002 Off Wait Time
| | | | | |> 8001 Unknown
| | | | | |> 8002 Unknown
| | | | | |> FFFD Unknown
| | |
| | |>| Output Clusters
| | | |
| | | |>| Cluster 000A Time
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0019 Ota Upgrade
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 Upgrade Server ID
| | | | | |> 0001 File Offset
| | | | | |> 0006 Image Upgrade Status
| | | | | |> FFFD Unknown
| |
| |>| Endpoint 2
| | |> Profile 0104 ZIGBEE_HOME_AUTOMATION
| | |> Device Type 010A ON_OFF_PLUG_IN_UNIT
| | |> Device Version 1
| | |
| | |>| Input Clusters
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0005 Scenes
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 Scene Count
| | | | | |> 0001 Current Scene
| | | | | |> 0002 Current Group
| | | | | |> 0003 Scene Valid
| | | | | |> 0004 Name Support
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 0006 On/Off
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 On Off
| | | | | |> 4001 On Time
| | | | | |> 4002 Off Wait Time
| | | | | |> 8001 Unknown
| | | | | |> 8002 Unknown
| | | | | |> FFFD Unknown
| | |
| | |>| Output Clusters
| |
| |>| Endpoint 242
| | |> Profile A1E0 ZIGBEE_GREEN_POWER
| | |> Device Type 0061
| | |> Device Version 0
| |
| |>| Endpoint 3
| | |> Profile 0104 ZIGBEE_HOME_AUTOMATION
| | |> Device Type 010A ON_OFF_PLUG_IN_UNIT
| | |> Device Version 1
| | |
| | |>| Input Clusters
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0005 Scenes
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 Scene Count
| | | | | |> 0001 Current Scene
| | | | | |> 0002 Current Group
| | | | | |> 0003 Scene Valid
| | | | | |> 0004 Name Support
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 0006 On/Off
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 On Off
| | | | | |> 4001 On Time
| | | | | |> 4002 Off Wait Time
| | | | | |> 8001 Unknown
| | | | | |> 8002 Unknown
| | | | | |> FFFD Unknown
| | |
| | |>| Output Clusters
Configuration of ‘All on/off’ item:
And for socket 1:
Log file for “All sockets off → Click ‘All on/off’ (result: all sockets on) → Click ‘All on/off’ (no reaction)”:
powerstrip_all_on_off.txt (80.6 KB)
AFAICT from the log, the first click on the toggle switch works as one would expect:
00:19:07.307 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'TZ30001obwwnmqTS011F' received command ON
00:19:07.311 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'TZ30001obwwnmqTS011F_804B50FFFEE11DD7_1_Switch' received command ON
00:19:07.314 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'TZ30001obwwnmqTS011F_804B50FFFEE11DD7_3_Switch' received command ON
00:19:07.317 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'TZ30001obwwnmqTS011F_804B50FFFEE11DD7_2_Switch' received command ON
but there are no lines corresponding to the second click on the toggle switch.
As seen from the UI:
All off.
Click on ‘All on/off’:
All on. OK.
Click on ‘All on/off’:
No reaction: all three socket are on (UI and real life).
Am I correct in assuming that the “all” item is a group that just groups up the individual sockets? If so, I’m not sure why it wouldn’t work from a binding perspective if the individual commands work. An OH group command is expanded to individual commands before it gets to the binding, so it will be exactly the same as sending the 3 individual OFF commands.
I think this must be an issue with the core/ui. I’m going to guess that it’s an autoupdate issue - the device doesn’t send a state update, and the binding doesn’t update the state after sending the command, so the state of the item is still OFF, and therefore the core doesn’t propagate your second toggle to switch it OFF as it already thinks it is OFF.
I’ve just been looking at the way the binding handles this. Normally the binding expects the device to send a report to update the state, but in this case it’s not received so presumably this device doesn’t send it for some reason.
I think I will change the way this works slightly to also update the state if the binding receives the successful response to the command.
FTR -:
To be precise: the ‘All on/off’ UI element is a Toggle List Item within a List Card (type: Media) that references the Power Strip:
That’s all - no ‘grouping’ etc. from my side.
O, but what channel are you linking to? If I look at the log, the binding is receiving individual commands so as far as I can see, this is in some way a group that sends individual commands to the individual channels.
OK, the group was created by adding the Thing to my Model while selecting all three channels/sockets. So yes, something sends an ON command per socket (in quite a strange order: 1, 3, 2), but it doesn’t send OFF commands.
As I said earlier, this is almost certainly because the core thinks the state is still ON, so it doesn’t send another OFF.
New challenge: integration of Lidl remote (HG06323)
Software:
Hardware:
Progress so far:
Remote joined the network as DIMMER_SWITCH:
Network Addr IEEE Address Logical Type State EP Profile Device Type Manufacturer Model
0 0000 XXXXXXXXXXXXC7B4 COORDINATOR ONLINE
2460 099C XXXXXXXXXXXX424A ROUTER UNKNOWN 1 ZIGBEE_HOME_AUTOMATION EXTENDED_COLOR_LIGHT _TZ3000_dbou1ap4 TS0505A
242 ZIGBEE_GREEN_POWER 0061
24445 5F7D XXXXXXXXXXXX3AD4 ROUTER UNKNOWN 1 ZIGBEE_HOME_AUTOMATION EXTENDED_COLOR_LIGHT _TZ3000_dbou1ap4 TS0505A
242 ZIGBEE_GREEN_POWER 0061
29110 71B6 XXXXXXXXXXXX5CDF END_DEVICE ONLINE 1 ZIGBEE_HOME_AUTOMATION DIMMER_SWITCH _TYZB01_bngwdjsr TS1001
Fingerprint:
|>| Node Descriptor
| |> Logical Type END_DEVICE
| |> MAC Capabilities [REDUCED_FUNCTION_DEVICE]
| |> Stack Compliance 22
| |> Server Capabilities []
| |> Buffer Size 82
| |> Incoming Transfer Size 82
| |> Outgoing Transfer Size 82
|
|>| Power Descriptor
| |> Available Power Sources [MAINS]
| |> Current Power Source MAINS
| |> Current Power Mode RECEIVER_ON_IDLE
| |> Power Level FULL
|
|>| ZDO
| |> ManagementBindRequest SUCCESS
| |> IeeeAddressRequest SUCCESS
| |> ManagementLqiRequest SUCCESS
| |> ManagementRoutingRequest SUCCESS
|
|>| Basic Information
| |> Generic Device Class
| |> Generic Device Type
| |> Manufacturer Name _TYZB01_bngwdjsr
| |> Model Indentifier TS1001
| |> Product Code
| |> Product URL
| |> Date Code
| |> Application Version 81
| |> Software Build ID
| |> Hardware Version 1
| |> Zcl Version 3
| |> Stack Version 0
| |
| |>| Endpoint 1
| | |> Profile 0104 ZIGBEE_HOME_AUTOMATION
| | |> Device Type 0104 DIMMER_SWITCH
| | |> Device Version 1
| | |
| | |>| Input Clusters
| | | |
| | | |>| Cluster 0000 Basic
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 ZCL Version
| | | | | |> 0001 Application Version
| | | | | |> 0002 Stack Version
| | | | | |> 0003 HW Version
| | | | | |> 0004 Manufacturer Name
| | | | | |> 0005 Model Identifier
| | | | | |> 0006 Date Code
| | | | | |> 0007 Power Source
| | | | | |> FFDE Unknown
| | | | | |> FFFD Unknown
| | | | | |> FFFE Unknown
| | | |
| | | |>| Cluster 0001 Power Configuration
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 1000
| | | | |> Type Server [Input]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | |
| | |>| Output Clusters
| | | |
| | | |>| Cluster 0003 Identify
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0004 Groups
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0005 Scenes
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0006 On/Off
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 0008 Level Control
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 000A Time
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
| | | |
| | | |>| Cluster 0019 Ota Upgrade
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |
| | | | |>| Commands Generated
| | | | | |> FAILURE
| | | | |
| | | | |>| Commands Received
| | | | |> FAILURE
| | | | |
| | | | |>| Attributes Supported
| | | | | |> 0000 Upgrade Server ID
| | | | | |> 0001 File Offset
| | | | | |> 0006 Image Upgrade Status
| | | | | |> FFFD Unknown
| | | |
| | | |>| Cluster 1000
| | | | |> Type Client [Output]
| | | | |> Manufacturer Spec. No
| | | | |> Unsupported locally
Channels:
UI:
ZigBee debug logs (button 1, 2, 3, 4 (from top → bottom) pressed):
Problem:
No corresponding events in event.log.
@chris
Is there any chance to get this remote working with the ZigBee Binding?
From a quick look at the fingerprint, it looks like it’s mostly using standard functions, so I would have thought it should already work. It looks like it’s just supporting the ON/OFF and LEVELCONTROL clusters (from a functional perspective) and the binding should therefore provide a Dimmer channel (which it has).
The logs don’t show anything - the first one has a single received attribute report. The fact that nothing is received makes me think the initialisation didn’t complete. There is a “limitation” with the way the binding works that’s worth understanding…
Initialisation works in two phases - the initial discovery occurs as soon as the device is joined to the network. During this phase the general information about the device is downloaded - this allows the binding to decide what the device is (give it a name etc). At this point the entry is added to the inbox. The second phase begins after you create the thing from the inbox - this could be some time later although in most instances it’s probably reasonably soon after the entry is added to the inbox. At this point, the binding works out the exact channels, and configures all the “binding and reporting” (the stuff that causes the device to autonomously report its status when you press a button, or the state changes).
The problem here is that for battery devices, the might go to sleep after the initial phase is done, and this might mean the second phase fails, or partly fails.
I do want to change this so that all configuration is done straight away and I’ve started to do this, but it’s not complete.
My guess is that the device is not properly configured as it seems to me that it’s not sending commands when you press the button (since I don’t really see anything in the logs). I would suggest to try and make sure the device is awake (not sure how you do that) and then use the “Reinitialise device” option in the configuration.
Let’s see what that does for starters.
The ZigBee Binding thinks that the device is initialised (zigbee_device_initialised):
Does it mean that phase 1 or phase 2 is finished (from the view of the binding …)? It doesn’t work.
zigbee_powersource is wrong. Just for comparison the parameters of my eWeLink MS01:
Does it make a difference to the binding?
How can I check that the device is properly configured?
BC33ACFFFE615CDF.xml (46.3 KB)
Someone sniffed the remote:
It doesn’t look standard to me …
I think it will still set this to true even if it fails - otherwise it can keep trying forever for devices that don’t work and that will choke the system.
Check if there are any errors in the log - or provide a debug log and i’ll have a look.
Ok, I’m only going on the clusters / channels I saw above, and it apparently supports the ONOFF and LEVELCONTROL and it reports as a DIMMERSWITCH device, so you should get a channel providing these functions, and I would have expected the device to send the respective commands for these clusters. Without more detailed info I’m just guessing.
I will need to find some time to look at the link and try and work out what it’s doing - I’ll try and do that tonight if I can.
openhab> log:display | grep -i cdf
14:42:48.112 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:42:57.845 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:43:07.579 [INFO ] [ing.zigbee.handler.ZigBeeThingHandler] - BC33ACFFFE615CDF: Channel zigbee:device:dbb76ab009:bc33acfffe615cdf:BC33ACFFFE615CDF_1_batteryalarm failed to initialise device
14:43:56.248 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from UNKNOWN to ONLINE
14:43:56.287 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from ONLINE to UNKNOWN
14:48:46.502 [ERROR] [nverter.ZigBeeConverterBatteryPercent] - BC33ACFFFE615CDF: Error 0xffff setting server binding
14:48:56.295 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:49:06.028 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:49:15.760 [INFO ] [ing.zigbee.handler.ZigBeeThingHandler] - BC33ACFFFE615CDF: Channel zigbee:device:dbb76ab009:bc33acfffe615cdf:BC33ACFFFE615CDF_1_batteryalarm failed to initialise device
14:50:04.583 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from UNKNOWN to ONLINE
14:50:04.621 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from ONLINE to UNKNOWN
14:51:12.849 [ERROR] [nverter.ZigBeeConverterBatteryPercent] - BC33ACFFFE615CDF: Error 0xffff setting server binding
14:51:22.574 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:51:32.395 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:51:42.151 [INFO ] [ing.zigbee.handler.ZigBeeThingHandler] - BC33ACFFFE615CDF: Channel zigbee:device:dbb76ab009:bc33acfffe615cdf:BC33ACFFFE615CDF_1_batteryalarm failed to initialise device
14:52:30.834 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from UNKNOWN to ONLINE
14:52:35.534 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from ONLINE to UNKNOWN
14:53:04.729 [ERROR] [nverter.ZigBeeConverterBatteryPercent] - BC33ACFFFE615CDF: Error 0xffff setting server binding
14:53:14.513 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:53:24.245 [ERROR] [.converter.ZigBeeConverterSwitchLevel] - BC33ACFFFE615CDF: Error 0xffff setting client binding
14:53:33.976 [INFO ] [ing.zigbee.handler.ZigBeeThingHandler] - BC33ACFFFE615CDF: Channel zigbee:device:dbb76ab009:bc33acfffe615cdf:BC33ACFFFE615CDF_1_batteryalarm failed to initialise device
14:54:22.746 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'zigbee:device:dbb76ab009:bc33acfffe615cdf' changed from UNKNOWN to ONLINE
It is impossible to get reproducible results from the UI. Unknown device/known device after Scan, status ONLINE/UNKNOWN, zigbee_device_initialised false/true, Initialize device works/doesn’t work (from the view of the UI) - almost any combination of these states seems to be possible … Initialize device doubled etc.
One cannot tell apart whether one is dealing with problems/bugs within the openHAB core, the presentation layer, the binding or the physical device.
This is the error that means reporting is not configured.
I don’t see that here. You don’t have two bindings loaded or something like that? This is provided by the binding itself and I just checked and it’s definitely just there once.
Given the above error, there is something wrong when configuring the device. A debug log might provide a little more information - if there is a timeout or if the device is reporting an error during configuration.
DUT is 7776 / BC33ACFFFE615CDF :
lrup.zip.txt (79.6 KB)
Actions:
2x ZigBee Scan, then Add Thing from Inbox
Intermediate Result:
State: UNKNOWN
Thing properties: 14 (or 15?)
Show advanced → Initialize device → Toggle ON
Final Result:
State ONLINE
Thing properties: 20, zigbee_device_initialised: true
Now there are three Toggle Switches that seem to be synchronized :
Data received when button pressed (buttons #1-#4 (from top to bottom) - excerpt from debug log, see below for a complete log):
Button #1 ("O" - off):
22:38:36.641 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=2, reTx=false, data=6A 90 01 3F 00 03 FD FF 04 01 06 00 01 FF 00 01 00 00 EB 00 00 00]
22:39:26.448 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=0, ackNum=4, reTx=false, data=9C 90 01 3F 00 03 FD FF 04 01 06 00 01 FF 00 01 00 00 EC 00 00 00]
22:40:11.264 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=0, reTx=false, data=C8 90 01 3F 00 03 FD FF 04 01 06 00 01 FF 00 01 00 00 ED 00 00 00]
22:40:51.086 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=0, reTx=false, data=F0 90 01 3F 00 03 FD FF 04 01 06 00 01 FF 00 01 00 00 EE 00 00 00]
22:42:56.104 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=5, reTx=false, data=6D 90 01 3F 00 03 FD FF 04 01 06 00 01 FF 00 01 00 00 EF 00 00 00]
Button #2 ("I" - ON):
22:49:23.364 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=5, ackNum=0, reTx=false, data=F0 90 01 3F 00 00 76 77 04 01 06 00 01 01 40 11 00 00 39 2F 00 00]
22:50:05.504 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=3, ackNum=2, reTx=false, data=1A 90 01 3F 00 00 76 77 04 01 06 00 01 01 40 11 00 00 3A 30 00 00]
Button #3 (dim+):
22:51:24.497 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=4, ackNum=0, reTx=false, data=68 90 01 3F 00 03 FD FF 04 01 08 00 01 FF 00 01 00 00 F6 00 00 00]
22:52:30.437 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=7, ackNum=2, reTx=false, data=AA 90 01 3F 00 03 FD FF 04 01 08 00 01 FF 00 01 00 00 F7 00 00 00]
Button #4 (dim-):
22:53:08.514 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=0, reTx=false, data=D0 90 01 3F 00 03 FD FF 04 01 08 00 01 FF 00 01 00 00 F8 00 00 00]
22:53:55.684 [DEBUG] [le.ember.internal.ash.AshFrameHandler] - <-- RX ASH frame: AshFrameData [frmNum=6, ackNum=7, reTx=false, data=FF 90 01 3F 00 03 FD FF 04 01 08 00 01 FF 00 01 00 00 F9 00 00 00]
Button #2 seems to be special insofar as the message contains the address of the DUT, whereas all messages “from” all other buttons contain FFFD (broadcast?).
Debug log (2x button #1, 2x button #2, 2x button#3, 2x button#4):
buttons1.txt (28.3 KB)
2nd try, same actions:
buttons2.txt (43.5 KB)
Success story:
DUT:
You have to set the Color Channel to ‘XY’, ‘Auto’ doesn’t work:
Works like a charm.
