RaspBee binding compatibility

raspbee
zigbee
Tags: #<Tag:0x00007f014823aaf0> #<Tag:0x00007f014823a960>

(Jonas L) #21

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.

Thanks for your work!


(Arne) #22

@David_Graeff Do you have any plans for additional sensor types like humidity and air pressure?


(David Graeff) #23

I don’t have those sensor types so not planning to add anything at the moment.

Cheers, David


(Rick Sanchez) #24

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).


(David Graeff) #25

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.

Cheers David


(Jens) #26

Hi @David_Graeff

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 :wink:

Thanks and best regards.


(Chris Jackson) #27

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 :wink:

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 -:


(David Graeff) #28

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 :smiley: 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.


(Chris Jackson) #29

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).