Yes, I agree, it’s linked to some degree. In ZWave, it’s almost a perfect link ie channels=command classes. In ZigBee it’s not quite true, and in ZWave I might also change the concept as there are some problems with the current link between the two.
In any case, the issue is to find a good way to document it. At the moment, there’s only a few clusters and a few channels - ZWave has dozens and ZigBee probably will in future and (IMO) it would be good to have a single location for the channel definition and the channel documentation which could also describe clusters.
Ok, that’s definately great news. Hopefully you didn’t just get lucky, but I’m quietly confident as I believe the change I made should provide this result.
Regarding the issue you see on the UI while moving a slider (related to binding & reporting) this is because now the OH receives the updated value in a report while the user is still manipulating the slider. I faced a similar issue some time ago developing my own “home system”, and the only good solution I found comes at the UI level: it should not show changes while the user is “manipulating” the slider, and until the user stops the interaction. Any attempt to fix this at the low level driver level ends up being a hack and a nightmare to maintain… and I always found a way to make it fail…
I bought a “new” RGB IKEA bulb and now I wonder what you mean by the old ones, as I recall two different issues with Tradfri
Old firmware versions were incorrectly reporting the profile, so i.e. they could not connect to Hue hub. They fixed this and I upgraded all my bulbs, so I have none with that old firmware.
RGB lights use Color XY, not Hue/Sat. I thought I read somewhere the new ones were OK, but the new one I bought on Saturday still supports only XY.
Anyway, I have already made it work. I did some changes to the converter to support both XY and Hue, and to detect if the attributes are supported. I did it in a generic way updating also ZclCluster to provide this discovery, but will check the last version of the binding you just published to make sure it is still ok before sharing
I’m familiar with the issue - it’s common with ZWave and other bindings I’ve writte, and as I said it will need some tuning. It’s not so obvious how to solve this as the user moves the slider to a position, and they expect it to stay there - not to jump back down and then move back up. I think that ignoring the updates for a second or so after the change might work, but let’s see - for now, the system updates and is usable even if it isn’t 100% ideal.
I would never look to solve this sort of issue at low level - the binding might be ok, but anything lower is a mess. In ZWave, the binding does some manipulation in some instances to help with this.
This is the issue I’m interested in playing with. I’ve recently added commands to check what commands and attributes are supported in the device and would like to check this out but can’t find a bulb to do so.
A use case to fit into future documentation: As an OH user, I see a cool new device and can find specs with the supported clusters and attributes (or command classes), so I go read documentation on the binding to learn which version of the binding it is supported by, if at all. Currently, in order to find this info, one would need to search/ask on the forum, or look through code. What I’m trying to convey, is that IMO it would be useful to document binding version and supported Command Class or Cluster and Attribute.
Just my thoughts on the slider update issue: as you say, it will happen everywhere, not really related to Zigbee,.zwave, etc
That is why the fix should come at UI level. The slider should not reflect any changes in status while being manipulated by the user: “just stick to the user’s finger” till he releases the slider.
Putting a delay in the handler,.or anywhere else other than the UI, only creates a mess with the events and is difficult to maintain. Moreover, what would be the right delay? 1s, 5s? IMHO, of course, this is a generic UI issue and should be fixed there. Will have a look at it.
On RGB bulbs, any IKEA RGB bulb, at least the ones bought in Spain, will accept only XY color commands and attributes. Let me have a look at the last update you pushed and I can send you my code addressing this, as I have it already working.
If you still want some of these bulbs after that, we can see how to do it (BTW, where are you based?)
There are many different UIs - so maybe it’s not so easy to fix in the UI .
That would be great - I’m trying to build up a test base here. I have this for ZWave where I have a LOT of devices - it takes time (and some £££) to do, but it’s useful.
I would be surprised if the IKEA bulbs in the UK supported Hue/Sat instead of XY (better thought, not really that much surprised)…
If you cannot get an XY bulb from Ikea in the UK, I imagine we could arrange for me to send you one from here.
But anyway let me try it here also with the new build update and send you the logs. As I commented, I already made it work with the previous build, so you may want to reuse some code (even if just for the color conversion)
All of my zigbee devices stopped responding… and I had taken the logging out of debug. I changed to DEBUG for about 5 minutes and will send you the log (I didn’t see any errors in the log, Karaf, etc.). I’m not sure when they stopped working, but I’ve had the binding running for about 7 hours. After an OH reboot, all bulbs are online again and controllable. I’ll leave logging in debug this time .
Correct… everything was working, then I lost track for a few hours. I went to the pantry and the light did not come on. Checked other zigbee devices and nothing responded. Zwave devices worked, so OH wasn’t hung.
Correct, all good after a restart (all online and controllable!).
Hi Chris,
just wondering if the support for raspbee/conbee is added with the latest release. If not have you an estimated time frame to release it?
Thanks for your wonderful work
Having a problem after I did a fresh install of build 1084. Migrating the userdata didn’t work, so had to re-add things. I have tried to set the Ember dongle back to the old panid, extended panid and network key. It takes the extended panid and networkkey, but the panid (2232) it won’t take back.
Now I have two orphaned hue lights. I don’t know how to reset them.
I have tried copy-pasting relevant parts to the jsondb as well, but still no luck with the panid, and the lights remain offline. Log is clean.
Hi Chris,
after installing #182, I finally was able to bring EM3588 NCP online. Adding my motion sensor (CLABS Eval Device) also was possible. There are 2 values available: Temperature (Number) and Occupancy.
Trying to link Temperature isn’t possible (nothing happens when clicking +). When linking Occupancy, the following error message appears at console window:
Exception in thread “pool-36-thread-266” java.lang.ClassCastException: java.lang
.Integer cannot be cast to java.lang.Boolean
at org.openhab.binding.zigbee.converter.ZigBeeConverterOccupancy.attribu
teUpdated(ZigBeeConverterOccupancy.java:93)
at com.zsmartsystems.zigbee.zcl.ZclCluster$1.run(ZclCluster.java:505)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I’ve setup a raspberry pi with a CC2531 china clone with the everywhere mentioned firmware. With a newer version of your binding I was able to get the stick online and (obviously) work as a coordinator. The available hardware I have are two Hue bulbs (RGB and white) and a dimmer switch. When I’m resetting the switch and searching in OpenHab, it showed up as “unkown device” with the old binding and even as “Philips RWL021” with the newest binding from todays build. So I’m guessing the general setup is working fine.
But I am not able to connect either one of the two bulbs. When I search for things, take the dimmer switch right next to the bulb, press On/Off to reset (bulbs is flickering shortly after like 10s) nothing else happens.
I’ve posted a full upstart + pairing the switch + efforts to pair the RGB bulb here: Pastebin
Maybe you could have quick look at that please? It looks like the mesh is updating itself, finding the switch as well (though being battery operated) and the bulb runs into timeouts? Is there any trick how I can pair them?
Just a short update - I now have basic communications working with the ConBee stick and can include and control devices. There are two issues I need to resolve before I merge this and I’m waiting for a response from the manufacturer. Hopefully once I get this I’ll be able to get this merged (if the answer is simple, which I expect).
@chris Had some time today to add your binding with the Telegesis stick. I haven’t added any zigbee items yet, but the Telegesis Coordinator is online. You mentioned that there’s an issue with the Telegesis stick which you would try to fix in the firmware, does that issue only affect the ST motion sensor or is it a general problem I might run into?
The Telegesis should work ok. There’s one issue that I can think of that might cause problems with some motion sensors (ST motion sensors!). I now know how to resolve this on the Telegesis stick, but it’s not currently implemented. I’m not sure if that’s what I referred to previously, but I think it’s pretty much the only problem with the Telegesis stick.
)
.