ok, Thanks for the reply. I’ll do this within the next days 
I updated to the latest snapshot meaning zigbee 1.2.1. Still same behaviour. The Innr FL 130C can be added, but only a “level control” dimmer is shown. Other zigbee devices work.
I debugged the joining until nothing happened anymore (see attached file)
openhab.log (799.2 KB)
Any ideas?
The problem is that this device is not using ZHA - it’s using ZLL. It doesn’t respond to the ZHA requests, so the binding doesn’t find any services. There’s not really much I can do about this at the moment unfortunately.
1 Like
Hi All, I have a problem with hue motion sensor. I made a rule that switch on the light when there is movement and dark state are both ON.
Now, the problem is that when the light is ON, the dark switch go OFF and when the Presence switch update his state to OFF the Dark state don’t update to ON.
It’s like the various status are update only when the presence switch is on.
Maybe I miss some configuration of the channel but I cannot solve the problem.
My configuration:
Openhabian 1.5
Openhab 2.5m2
Zigbee binding 2.5m2
CC2531EMK Coordinator
That’s how the Philips Hue sensor works, no way to change this. Luminance updates are infrequent and when motion triggers. Why is this a problem, anyway? Since you will get an updated luminance when motion triggers, you can then decide whether light is needed or not. Of course your logic will never work to switch the light off, since with the light turned on, it won’t be dark. You will always need to use a timer to turn the light off.
So, could you suggest the best way? 
That is how I though:
rule "sensor"
when
Item Sensor_Motion changed
then
if (Sensor_Motion.state == ON &&
Sensor_Dark.state == ON &&
A_Letto.state == OFF ) {Corridor.sendCommand (ON)}
if (MovimemtoCorridoio_Motion.state == OFF) {
Luce_Corridoio_C.sendCommand (OFF)
}
end
Maybe I have to give it more time to refresh like this:
when Item Sensor_Motion changed Thread::sleep(500) ...
Thread:sleep is not so good, it will block an exection thread and will slow down Openhab as a whole. You should use timers. Like this:
var Timer sensorTimer = null
rule "sensor"
when
Item Sensor_Motion changed to ON
then
if (Sensor_Dark.state == ON && A_Letto.state == OFF ) {
Corridor.sendCommand(ON)
}
if (sensorTimer === null) {
sensorTimer = createTimer(now.plusSeconds(60), [|
if (Sensor_Motion.state == OFF ) {
Corridor.sendCommand(OFF)
sensorTimer = null
}
else {
sensorTimer.reschedule(now.plusSeconds(60))
}
])
}
else {
sensorTimer.reschedule(now.plusSeconds(60))
}
end
This uses a timer to trigger the “OFF” command, and has logic that pushes the timer forward in case movement is detected while the timer is running
1 Like
EDIT: Solved - not further action required.
But leave it for reference - o.k.?
Solution at the bottom.
Hi Chris,
I’ve learned from some of your posts, that you are currently focused on the Ember coordinators and that the future of the TI CC2531 is uncertain due to abandoned support from TI.
So I thought, it would be a good idea to move from CC2531 to Ember too for the rework of my openHAB setup 
So the coordinator is from now on:
Ember EM35x (Bitron Video AV2010/10)
The good thing:
Osram and HUE bulbs are working as expected. HUE motion sensors too… (btw.: having the frequent illuminance reports too as mentioned somewhere else)
AND: One of my LUMI_weather (the square one with TEMP/HUM/PRESSURE) is working as well.
But:
A second LUMI_weather and a LUMI_sensor_HT (the round one) can’t join at the moment.
I tried this several times and even replaced the batteries to rule out power issue…
And yes, I kept them awake during discovery
So I powered up my deCONZ/raspBEE and tried them there:
Surprisingly, they work immediately when I let them join to deCONZ/Phoscon:
According to the nodelist in deCONZ I can confirm having the same firmware running on the two LUMI_weather
LUMI_weather V.20161129 (same as the one yet working with the Zigbee binding)
LUMI_sensor V.20160516
This are the relevant bundle versions:
openhab> list | grep zig
213 x Active x 80 x 1.2.1 x com.zsmartsystems.zigbee
214 x Active x 80 x 1.2.1 x com.zsmartsystems.zigbee.dongle.cc2531
215 x Active x 80 x 1.2.1 x com.zsmartsystems.zigbee.dongle.ember
216 x Active x 80 x 1.2.1 x com.zsmartsystems.zigbee.dongle.telegesis
217 x Active x 80 x 1.2.1 x com.zsmartsystems.zigbee.dongle.xbee
openhab> list | grep Zig
242 x Active x 80 x 2.5.0.M2 x openHAB Add-ons :: Bundles :: ZigBee Binding
243 x Active x 80 x 2.5.0.M2 x openHAB Add-ons :: Bundles :: ZigBee CC2531 Bridge
244 x Active x 80 x 2.5.0.M2 x openHAB Add-ons :: Bundles :: ZigBee Ember Bridge
245 x Active x 80 x 2.5.0.M2 x openHAB Add-ons :: Bundles :: ZigBee Telegesis Bridge
246 x Active x 80 x 2.5.0.M2 x openHAB Add-ons :: Bundles :: ZigBee XBee Bridge
May I ask you looking at the both logfiles if there’s something obvious wrong?
This are the two mac adresses to look after:
LUMI_weather 00158D0001FA3816
LUMI_sensor_HT 00158D0002019E97
LUMI_sensor_HT_join.log (400.7 KB) LUMI_wether_join.log (201.3 KB)
EDIT:
Found status=EMBER_DEVICE_LEFT and policyDecision=EMBER_NO_ACTION in the log of 00158D0002019E97. What does it mean?
… taken from this line:
RX EZSP: EzspTrustCenterJoinHandler [newNodeId=21776, newNodeEui64=00158D0002019E97, status=EMBER_DEVICE_LEFT, policyDecision=EMBER_NO_ACTION, parentOfNewNodeId=65535]
Solution:
It seems to me, that the binding has kept some fragments from former unsuccessful/uncomplete joining attempts. So every new attempt failed until I did the following sequence. Not sure if every step was really required, but at the end I got my sensors joined 
- remove batteries from the problematic and partially discovered devices to prevent them sending any packets.
- remove every thing related to the problematic sensors from the Things configuration list as well as from the inbox
-
shutdown openhab and
openhab-cli clean-cache - start openHAB and let the log calm down
- start discovery for ZigBEE while watching the log (I had zigbee related bundles set logging to DEBUG and the log viewer filtering for the problemeatic mac adress)
- insert the battery and press button on sensor for aprx. 5-8 seconds to reset it. Observe the log and the inbox to notice, when things happen.
- short-press the button on the sensor every 3-5 seconds until the disovery result in the inbox changes from “unknown zigbee device …” to “LUMI …”.
I was just about to reply having looked through the logs and seeing that at least the lumi.weahter seems to be joining.
These devices are a bit of a pain - can you provide some information on what the problem was?
To answer a few of your questions -:
Most of the commercial users of the binding, and the libraries that the binding uses, are using the Ember chips (ie Silabs) so this does get most of the testing and focus. I recently wrote anew driver for the TI chipset for a customer, and during this TI told me that they do not plan any further updates of their firmware to fix the bugs that I found.
This means that the device left the network. It’s hard to say why this happened - I found this in one of your logs when you tried to include it again, so I suspect it happened when you reset the device.
1 Like
Thanks for your answers and clarifications 
Done. I was just updating my former post while you where replying 
2 Likes
That’s don’t work the second time, because:
During first trigger it start the timer and it turn on the light, Sensor_Dark.state turn OFF, when the timer is finished the light turn OFF but the Sensor_Dark.state don’t switch ON.
So the second time
is not true and the light don’t turn on. 
However, someone succeded to pair the Xiaomi Door/Windows Sensor?
I sow the Aqara on compatibility list but my Xiaomi don’t work
I don’t know how that could be. What I do differently, is that I have defined the luminance item as a “Number”, and I compare it to a numeric value to check whether it is dark.
zigbee.items
Number Sensor_Dark {channel="zigbee:device:..."}
zigbee.rules
if ((Sensor_Dark.state as Number)< 1) {
(not sure whether the type cast to Number is really necessary, but if there is one thing I have learned, is to better cast once too many, because I am always battling with object types)
You could also have a look in your events.log to see when luminance updates are sent. If you installed the log viewer, you can just point your browser to port 9001 on your OH server.
1 Like
Thank you, I’ll try that way
Hi,
I’m relatieve new to OpenHAB, I’m testing it now for two months and learned a lot by reading and doing. I hope my question i in the good threat.
I have the zigbee bindingwith a CC2531 setup as a coordinator. In my test setup I have a bulb (LED1733G7), switch (E1743) and motion sensor (E1525)connected. All Ikea Tradfri.
I was hoping the motion sensor would show a “occupancy” channel connected via the zigbee binding. Beside the battery channels I only see a switch that looks dead? I can control my bulb with the switch not by motion.
I’m aware that Ikea designed the motion sensor to be grouped to a bulb (or set off). When I look at the zigbee2mqtt description (https://www.zigbee2mqtt.io/devices/E1525.html) it looks it’s possible to use it as a standalone motion detector.
Is there somebody who knows if it possible to use the Tradfri motion sensor directly connected to OpenHAB?
Regards,
King
- Platform information:
- Hardware: Raspberry PI 4 4Gb
- OS: Raspbian 4.19
- Java Runtime Environment: openjdk 11.0.3 2019-04-16
- openHAB version: 2.5.0.M3 Milestone Build
Hi King and great first post! Welcome to the OpenHAB community! I’m not sure if I can help much because I don’t have any Tradfri stuff. One thing to try if you are using paper user interface would be to check if the thing page has a ‘show more’ button. There may be more channels available.
Also, this is a huge old thread (2275 posts!) feel free to start a new thread with your issue
1 Like
I’m not 100% sure without searching around, but I think the tradfri remote uses group addressing which the binding doesn’t currently support. This is something I will likely look at in the near future and we can then revisit this (assuming that is the issue of course ).
Sorry - reading emails on the phone and I misunderstood this… I think that the motion sensor ought to work - I was thinking about the remote control when I read this earlier…
I think the motion sensor has been tested and it is on the list of devices that people have used in the binding documentation.
Thanks.
Tonight at home I will double check the paper UI. I think there were only four channels, three battery related and one switch.
Thanks for your reply. Searching and reading around I couldn’t find a confirmation the Tradfri motion sensor was working with the zigbee binding (though there are a lot of postings).
I could find some issues,
And some “working” (?) options with the deCONZ binding,
https://github.com/openhab/openhab2-addons/issues/4524
https://github.com/openhab/openhab2-addons/pull/4545
and the earlier mentioned zigbee2mqtt.
As I said earlier, it is listed in the binding documentation, so someone has confirmed that it works.
1 Like