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
-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 - 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.
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.
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:
- openHABian/Linux 10 (buster): openHAB 3.2.0-SNAPSHOT - Build #2613
- ZigBee Binding - downgraded to [OH2] Can't set color on bulbs from certain manufacturers - #41 by chris
Hardware:
- Raspberry Pi B 4GB
- Lidl remote (Lidl FB20-002 control via MQTT | Zigbee2MQTT)
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):
- lremote2.txt (27.3 KB)
- lremote3.txt (22.2 KB)
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.