Yes, but note that not all these bundles are part of the binding. The binding is version 2.4 - the other bundles are the main ZigBee libraries that the binding is using. This is quite normal in OSGi.
Ok. Thanks.
Progress! Did get the first pairing working, using a 3 meter USB cable to keep the CC2531 dongle away from the RPi.
Not sure if that did the difference, but Iām soo glad I finally have a pairing working.
Next step would be to try to get the dimmer paired.
Thank you Chris, it is truly a magnificent job you are doing here!
1 Like
So I did get the dimmer paired now also.
Tip: What worked for me was: put the binding in discovery mode and reset the dimmer clicking the button 4 times. It was discovered right after that.
The dimmer shows up in OH as 3 channels:
Switch (not dimmer nor number)?
Battery voltage and
Battery alarm
But none of them seems to changeā¦
In the logs I can read:
2019-01-14 01:29:48.354 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: MoveToLevelWithOnOffCommand [Level Control: 49609/1 -> 0/1, cluster=0008, TID=71, level=0, transitionTime=1]
and
2019-01-14 01:30:13.684 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: MoveToLevelWithOnOffCommand [Level Control: 49609/1 -> 0/1, cluster=0008, TID=72, level=255, transitionTime=1]
Turning down and up respectively.
I was not able to make it report anything in between 0 and 255, and it did not seem to have any influence on the channel status.
Chris: is the dimmer really supported yet?
Iām not sure what is happening. You say that the dimmer isnāt showing up, but the command that you have provided in the log comes from the dimmer converter. 
No the dimmer is showing up as 3 channels.
Itās just that the channel is a switch, and it does not seem to change when I turn the dimmer.
But the log lines indicates that the binding is receiving something.
What is the device? The binding works by detecting the clusters that devices report so it should provide a dimmer if the level control cluster is supported.
Can you post either a log from the startup or the network xml file in the userdata/ZigBee folder.
Sure.
Donāt know what you mean by ālog from the startupā but here is my network.xml file (it only contains the dimmer and a simple white bulb).
It is just the simple little dimmer with the acceleration sensor to detect turning.zigbee-networkāzigbee_coordinator_cc2531_1d070427.xml (150.3 KB)
Thanks. By log from startup I mean a log that shows the startup. Normally starting logging and restarting the binding or oh will achieve this.
Can you provide a link to the manual?
Iāll take a look at the xml later - thanks.
https://www.ikea.com/ca/en/manuals/tradfri-dimming-kit__AA-1954744-1_pub.pdf
One more thing I noticed is this in the network xml:
<powerDescriptor>
<currentPowerMode>RECEIVER_ON_IDLE</currentPowerMode>
<availablePowerSources>
<PowerSourceType>MAINS</PowerSourceType>
</availablePowerSources>
<currentPowerSource>MAINS</currentPowerSource>
<powerLevel>FULL</powerLevel>
</powerDescriptor>
So it is reporting as a MAINS powered device, but it is in-fact powered by a CR2032 battery.
I restarted OH one or two days ago. Today I lost 4 zigbee devices. They show their supposed states in the events log, but in real life nothing happens. No errors are logged.
I have posted a log to the following issue:
I really need further information - sorry, but itās hard to know what to make of your report as I donāt understand the german, and it doesnāt provide much information about your setup -:
- What version of the library do you use?
- What settings do you have?
- What devices do you have?
- Can you provide a sniffer log?
At the moment, all I can really say is the same thing Iāve said before - these sorts of issues are likely to be related to devices rejoining, but without concrete information, itās really difficult for me to comment on - sorry.
Hi everyone,
Long time lurker, Iāve been using the Zigbee binding for about 6 months now and for the most part its been great, I suspect some of the issues Iāve encountered with tradfri builds not responding, always after multiple days uptime, could be related to the telegesis dongle Iāve been using, its now almost impossible to debug with 30 or so devices on the network, the log fills up very quickly and even with grep its hard to spot what Iām looking for.
My plan is to use the CC2531 which can be bought as little as Ā£5 now + Ā£12 for the smartRF04EB (you can use an Arduino for flashing at a pinch) vs the Ā£60 i paid for the telegesis and hopefully help out with adding devices, once i get eclipse set up with remote debugging, this means i can now play with devices without not having to worry about not having lighting or heating when I inevitably screw up 
My first two devices Iād like to try and help add/improve are the Tradfri motion sensor, which although can be added and appears to have all the right channels but never triggers on a motion event, the second device is the xiaomi lumi motion sensor(great deal at ~Ā£10 each), this again is discovered correctly after a little bit of persuasion pressing the reset button on the motion sensor every second until the binding can do a full discovery, however it has the same issue as the tradfri motion sensor in that it never toggles the switch for motion, I can verify its functioning as the log is updated whenever i wave my hand in front of it -
22:11:18.886 [DEBUG] [531.network.impl.CommandInterfaceImpl] - <-- AF_INCOMING_MSG (FE 1B 44 81 00 00 06 04 F5 49 01 01 00 61 00 2E 8A C2 00 00 07 18 26 0A 00 00 18 01 F5 49 1D EC)
22:11:18.886 [DEBUG] [531.network.impl.CommandInterfaceImpl] - Received Async Cmd: Packet: subsystem=null, length=27, apiId=44 81, data=FE 1B 44 81 00 00 06 04 F5 49 01 01 00 61 00 2E 8A C2 00 00 07 18 26 0A 00 00 18 01 F5 49 1D EC, checksum=EC, error=false
22:11:18.887 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=18933/1, destinationAddress=0/1, profile=0104, cluster=1030, addressMode=null, radius=0, apsSecurity=false, apsCounter=0, payload=18 26 0A 00 00 18 01]
22:11:18.887 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=38, commandId=10]
22:11:18.887 [DEBUG] [rtsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Occupancy sensing: 18933/1 -> 0/1, cluster=0406, TID=26, reports=[Attribute Report: attributeDataType=BITMAP_8_BIT, attributeIdentifier=0, attributeValue=1]]
22:11:18.888 [DEBUG] [m.zsmartsystems.zigbee.ZigBeeEndpoint] - 18933/1: Cluster 1030 not found for attribute response
The fact it at least triggers something each time is very promising, i presume the cluster hasnāt been defined in the binding yet.
Is there any tips for a noob who would like to contribute? Iām familiar with Java, know of karaf and OSGI concepts but iāve never attempted to debug something as complex as a runtime loaded binding which ultimately uses a serial device, which i donāt think respond kindly to large delays introduced while debugging.
What iāve done so far -
- Set up eclipse with openhab packages
- Set up openhab snapshot in a docker container with ttyACM0 pass through
- Added devices (coordinator and both motion sensors)
What iāll try next -
- Build snapshot of the binding and reload binding/bundle in karaf within docker
- Connect eclipse remote debugging <- I suspect this might be more complicated than i presume
The cluster is just the temperature cluster - itās supported. The error means that the binding doesnāt know that the device supports it which probably means there was an error during initialisation. I would suggest to try reinitialising it to see if it resolves the issue - if it doesnāt please provide a log showing the initialisation.
Not really Iām afraid. You just need to work through the binding source 
Whee another TrƄdfri user 
Not sure if this is of any help, but just for the record, this is what I receive from the TrƄdfri dimmer:
Turning up:
2019-01-16 00:33:14.851 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: MoveCommand [Level Control: 49609/1 -> 0/1, cluster=0008, TID=3C, moveMode=1, rate=195]
Stopping:
2019-01-16 00:33:14.890 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: Stop2Command [Level Control: 49609/1 -> 0/1, cluster=0008, TID=3F]
Turning down to OFF:
2019-01-16 00:33:16.560 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: MoveToLevelWithOnOffCommand [Level Control: 49609/1 -> 0/1, cluster=0008, TID=46, level=0, transitionTime=1]
I did pair the dimmer with the bulb AFTER pairing with the zigbee binding (normal IKEA way), and now it seems to send both to the binding AND the bulb.
To confirm: I also receive updates on the binding if I cut power to the bulb.
Hi Chris,
First off, thanks for this binding and all the hard work it must of taken to get to this point!
Iāve tried to repair/re-add the ZED (Xiaomi Lumi motion sensor) to the PAN a few times always with the same result, It seems to successfully join but does not update the switch toggle, Iāve seen else where that Xiaomi have proprietary/off spec implementations so perhaps as you say its not actually providing the correct cluster id or otherwise wrong message type.
Iāve pushed the log to a gist here in this i first remove the ZED, reset the device then attempt to keep it powered on whilst pairing by hitting the reset button every 4-5 seconds.
The last few entries are the message received upon triggering the motion sensor by waving my hand in front of it, though one of them might of been my cat walking past 
Iāve not managed to fire up the debugger yet, hopefully iāll get a bit spare time at the weekend.
@MortenVinding
I tried pairing the tradfri remote some time back but it seemed to āstealā the bulb from the PAN, Iāll certainly look into this when i get the chance as I have about 6 remotes in various cupboards and bags around my home doing nothing 
.
Iād assumed, due to reading elsewhere, that again IKEA where doing something in a ānon-standardā way and other people had issues with the remote never actually speaking to the coordinator and only to the router (the bulb)
Hi @Jonny0stars, I am using these Xiaomi Occupancy sensors and they are working correctly to me.
As you say, they requiere keeping them alive during discovery, but once joined and discovered, these (at least the version I have) correctly report their clusters.
Occupancy is correctly reported and working in my case
Pedro
Hi Chris,
First at all thanks for creating this binding ^^ .
I have recently bought this multisensor āhttps://www.globalsources.com/gsol/I/IR-detector/p/sm/1158868228.htm#1158868228ā. I have tried to include it many times but I can never see the illuminance channel but if I look for the illuminance cluster in the Zigbee XML file itās there:
Also tamper channel doesnāt work (it doesnāt change).
Here is the log file āhttps://mega.nz/#!zPpiFA7I!Z5_q6wac2M04rPBQOPdWaCYrXE-UJ8eomcGLrM1PirAā (I think you can see useful information from 12:53:05.291).
What can I do?
Thanks 
Hey Pedro,
I think you might have the Xiaomi Aqara? as opposed to my Lumi, Iām guessing this as my motion sensor does not provide Illuminance sensing, the Aqara also comes with a stand/arm and the lumi does not AFIK.
Iāll keep this in mind for future purchases as now both appear to be roughly the same price, how is its performance so far? Iāve noticed my other Xiaomi devices (temperature, pressure and humidity) sensors have dropped off the PAN a few times, this was never a problem until recently so iām guessing its either the battery running low or issues with a now larger network, but other than that Iām impressed for the price!
Thanks
Hi @Jonny0stars,
Xiaomi ZigBee devices are a cheap option, but probably not the best choice for a stable network (unless you use the Xiaomi hub, which is not our case): they are āsomehowā ZigBee compliant and can be made to work, but many times with issues.
As you say, my occupancy sensors are probably the aqara, not the lumi ones. I have two of these: one works more or less reliably, while the other gets disconnected from time to timeā¦ probably because it is very far from the hub and I have heard in the forums (maybe āgossipā anyway ) they do not behave well with routers.
If you want to give a try to the lumi occupancy sensor, from the log you sent it seems to have the same issue as the lumi temperature and humidity sensors: I see they are reporting occupancy attributes, but probably the occupancy cluster is not in the list of clusters the device claims to support, so the binding does not know what to do with the received reported occupancy.
If you can post the modelId from the device properties, I can show you how to add a XML file to the binding to āforceā the cluster into the device, and if it works, and @chris thinks it is OK, I can submit a PR for this file to be included in the binding, as there is already one for the lumi HT sensor.
this worked streight away