Lidl (Silvercrest) Smart Home (Zigbee version) integration

I’ve bought Motion and Windows/Door sensor. I decided to go with supported Elelabs Zigbee USB Adapter which itself seems to be working fine together with ZigBee binding. I’ve managed to pair the sensor just fine. I even got several channels populated in a short while. However I was facing a problem that I did not see any status change OPEN / CLOSE.
I’ve enabled debug and confirmed there were no messages coming from the sensor. I decided to update the version to 2.5.11-1, removed the sensor and added it again. I even got worse results as not all the channels that were originally populated are not there. I am going to test also the motion sensor if I get any message to the OpenHab.
Any ideas, apart from broken sensor, what could be a problem? Thank you.

Hi,

I have a couple of the IKEA wall switches. As Gateway I have the slaesh’s CC2652RB stick with Zigbee2MQTT. I would like to buy the window contacts from LIDL but i have already the problem that some of the IKEA switches have bad connection. I’m wondering if the LIDL SmartPlug is also a router? I read that the SmartPlug from Ikea is also a router, does this one will then also forward messages from the LIDL window contacts? I think o, because both are Zigbee 3.0, right? Does someone have information about it? Thanks.

Cheers Jonas

I’ve connected to the Lidl Extension Lead using the standard Zigbee Binding for a TI C2531EMK USB Stick:

and all appears to be working well

Hallo
Ich nutze Silvercrest Motion Sensor auf Raspberry / Openhab 2.5.1 / deCONZ / ConBee II

Ich habe sowohl die Version 2.07.02 als auch 2.09.01 installiert. Das Verhalten ist gleich.
Der Sensor wird erkannt und läuft auf/in Openhab gut (die Einbindung ist recht wackelig aber es geht)

Ein offener Punkt ist die Dauer der Detektion Anzeige. Der Sensor zeig 65 Sekunden „detected“ an.
Ich schalte über den Sensor eine Steckdose.

Womit ich nicht zufrieden bin ist die Reichweite ist mit10 m angegeben. DAS stimmt bei meinem Sensor nicht einmal annähernd!

rule "beweg1"
when
  Item Bew1_presence changed to ON
then
    logInfo("Test", "-->> ON  ! Bew1_presence")
    Lidl_onoff.sendCommand(ON)
end

rule "beweg2"
when
   Item Bew1_presence changed to OFF
 then
    logInfo("Test", "-->> OFF ! Bew1_presence")
    Lidl_onoff.sendCommand(OFF)
end

Hallo and Hello,
for the germans in this thread here, English below:
Das hier einige auf deutsch schreiben, Ja man kann mit etwas Aufwand das Gateway von Lidl / Silvercrest in OpenHAB einbinden. Dabei verliert es die Verbindung zur Lidl Cloud, man muss löten können und am besten englisch verstehen, da mir gerade die Zeit fehlt alles einmal zu übersetzen und das ganze wird ja anscheinend in der ganzen EU und Brexitland verkauft.
In Englisch:
The Silvercrest Gateway sold by Lidl can be integrated into OpenHAB as a Gateway for Zigbee.
You will lose:

  • warranty :slight_smile:
    -and the Lidl cloud features by doing so.
    You will get:
  • a network attached Zigbee Modem
  • an elegant way of avoiding any hassle with Zigbee Divers on your NAS + a free USB port
    You need:
  • a Silvercrerst /Lidl Gateway based on the Tuya Chip (see sales ad)
  • soldering skills
  • a 3,3V serial to USB Dongle for setup.
    Additional complications by me :slight_smile:
  • OpenHAB on Docker on NAS

First of all a thank you to Paul Banks who made the bulk of the work and integrated into Home Assistant.
Follow his instructions and code up to the point where he integrates into HA:
Link to his article

(sorry I’m a new User only 2 links allowed …)

My understanding is that we can’t use socket:// in OpenHAB so socat is needed.
For me it was bit more as I use OpenHab on a Docker on a NAS.

  • follow the instructions here OpenHAB Doc to install the script 60-socat-serial-network from the contrib/cont-init.d directory (adjust IP address !!).

After that add EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyNET0" to your Docker Environment.
After that you can add the Zigbee Binding (if I remember right the Name on the install page was “OpenHAB Zigbee” and on the add Page its only “Zigbee”).
Add manually the Ember Coordinator.
If you followed Pauls setup the you can takeover the existing Keys by SSHing into the device. In the /tuya directory you will find a zigbeeNetInfo.txt with the necessary Network Keys to keep existing paired devices.
Have fun.

1 Like

The extension lead only comes up as unknown device for me. No properties.

Can you switch all 3 sockets ?

/M

Nevermind.

I can confirm, that the Lidl Powerstrip indeed does work using zigbee2mqtt and a CC2531 Zigbee Dongle using firmware CC2531_DEFAULT_20190608.

The same goes for the Lidl switched socket.

I can switch each plug individually and they also report their state, when switched by other means, like the on/off button the powerstrip or switched socket. It did take a bit of fiddling, but well happy with that.

Oh, and that’s the UK/Ireland version of both in my case, but that shouldn’t really make a difference.

I can also confirm, that the Lidl Powerstrip does work using the Zigbee Binding on OpenHAB 2.5.12 with a Bitron Zigbee USB dongle.

The names for the items have to be changed during creation, as the default names result in unwanted behaviour, but once that’s taken care of, all 3 sockets can be switched individually.

/M

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. :slight_smile:

@chris

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

grafik

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:

grafik

All off.

Click on ‘All on/off’:

grafik

All on. OK.

Click on ‘All on/off’:

grafik

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

1 Like

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:

grafik

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.