Thanks for your effort! I already installed your Snapcast binding. Afterwards i tried to search for new things, without any finding. Do i have to configure your binding or do something else?
I am using the openHabian Image with deconz/raspbee installed. I already connected a working xiaomi door sensor to deconz and want to use it with openHab.
I have no clue how your binding works but do you really need to manually add each sensor Type? As deconz is already providing all the Information, couldn’t you make some kind of dynamic classes in your binding based on the deConz information? Maybe this thought is just to simple and therefore not working but I just wanted to mention.
Apart from this, is the only reason for not integrating the lights that you can already access them via the Hue Binding? The benefit of having the lights in your binding would be the realtime external change information (i. e. zigbee wall switches which could trigger rules).
Yes the reason for not supporting lights is the original hue binding, I don’t want to duplicate code. The devonz binding is more like a temporary thing until rasbees are directly supported by the ZigBee binding (which might take a few years).
I still hope that Philips adds a websocket connection to their API, that was the two bindings could be united.
It is not possible to dynamically generate channels without applying a ton of heuristics. And then the cleaner approach is just to add the sensor in question, I mean it is a finite amount of devonz supported sensors.
I have a bunch of Xiaomi ZigBee sensors/switches already paired with my deconz/raspbee, but they are actually not (completely) supported in your new binging. What do you exactly need to add the sensors/values to your deconz binding? I already got the responses from the raspbee REST API for my sensors, except my water detection sensor, which cannot be paired in the moment, but should be fixed in deconz 2.05.51…
I also took a short look into your binding source code and perhaps I can try to help adding my sensors, if this is okay for you? Java programming is some time ago, but maybe I can help
I know we’ve had this discussion in the past, but if someone was to actually spend some time to work on it, it would likely take a few days - not years. Of course, if no-one spends any time, then yes, it will be years or longer
The majority of code is written, it just needs someone to pick it up and try get it working reliably.
If there’s someone out there interested, then please feel free to contact me, or discuss on this issue -:
That’s the issue. So far nobody jumped in, and I have the mqtt subsystem to maintain, busy with extending the hue emulation to the state that even the original hue app can’t tell any difference, and writing a new binding for coap.
It was faster for me to write the deconz binding than to dive into the zigbee code base.
It would help a lot of you put together a small instruction list for building, debugging and where you think that unstable code is located or more testing is required.
Time You can help by creating a pull request where you add all the missing sensor things and channels to the thing xml file already and add missing fields to the sensor value class.
Sure - I was simply trying to advertise the issue here so that people are aware of it.
Maybe - maybe not…
Just to reiterate (again, for anyone who wants to look at this) that you don’t need to jump in to the whole codebase. The driver fundamentally works, and is quite self contained. You had thought that the writing of the code would take a LONG time (I think you said many man months of work when we discussed this on GH) and really I don’t think this is the case.
Please see the issue I referenced above. I’m happy to answer questions etc if someone wants to look at it - that was the purpose of this issue.
I’m not sure where the “unstable” code is as it was a long time ago that I looked at this. However, there are only a couple of Java files that form the main part of the driver (yes - that really is 2 files, and under 1000 lines of code!), so it’s a pretty small codebase (there are maybe another dozen or so that are used for formatting frames, but I doubt the issue is there).
I am happy to read someone else tries the same. Currently, I am struggling with getting xiaomi aqara things recognized by deconz binding in OH. Of course without success, then I found your comment while looking for helpful hints. For now it seems, the best way for me is to use http binding until someone implements the additional sensor types (water, window/door).
If you follow github a little, you’ll notice that sensor types are added like crazy recently. I recommend the binding instead of http for real-time updates. Polling is never a good solution, but you probably know that.
Hi @David_Graeff, thanks for the hint. I am aware of that and would prefer the binding. To be honest, I haven’t seen the github repository but only that the currently delivered deconz binding version in OH2.4 does not offer the device types I need. Do you know when will be an update provided which will be easier for me than pulling the github repository and compiling all the code for my raspberry?