Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Zigbee Driver
#1
Is a zigbee driver on the road map for development? I bought a couple of yale locks that where on sale awhile ago. They were 50% off at the time. They have a zigbee radio in them that I currently don't use but thought it would be nice.

https://www.amazon.com/Yale-Security-YRD...B06Y6K48TJ

I don't have any other zigbee device other than the Hue. But have thought about buying some switches.
Reply
#2
It's a big thing to bite off. Zigbee is hugely successful outside of home automation. But in the HA world, they have been caught in a big chicken and egg cycle. Where it is used, it's used in proprietary form mostly (like the Hue.) And the thing is, if we did do it, it would be for the new consolidated HA profile.

Zigbee uses 'profiles' that lets it have different sets of messages that are supported (including proprietary ones.) Previously, it had no really well defined, over-arching HA profile, so it was sort of some bits and pieces in different ones. They have recently defined a new profile to target HA, but it's new so it's likely that nothing you currently have would support it.

OTOH, it's the only profile that makes sense to support if starting at this point. So, again, chicken and egg. Do we put in a huge amount of work to support this new HA profile, when nothing supports it yet. And why would hardware guys make hardware that supports it if nothing can control it. But why would we support the old stuff when we know that the the only real viable scenario is the new HA profile, and it's not likely anything going forward that does get built would use anything else.
Dean Roddey
Software Geek Extraordinaire
Reply
#3
(01-09-2019, 10:06 AM)Dean Roddey Wrote: It's a big thing to bite off. Zigbee is hugely successful outside of home automation. But in the HA world, they have been caught in a big chicken and egg cycle. Where it is used, it's used in proprietary form mostly (like the Hue.) And the thing is, if we did do it, it would be for the new consolidated HA profile.

Zigbee uses 'profiles' that lets it have different sets of messages that are supported (including proprietary ones.) Previously, it had no really well defined, over-arching HA profile, so it was sort of some bits and pieces in different ones. They have recently defined a new profile to target HA, but it's new so it's likely that nothing you currently have would support it.

OTOH, it's the only profile that makes sense to support if starting at this point. So, again, chicken and egg. Do we put in a huge amount of work to support this new HA profile, when nothing supports it yet. And why would hardware guys make hardware that supports it if nothing can control it. But why would we support the old stuff when we know that the the only real viable scenario is the new HA profile, and it's not likely anything going forward that does get built would use anything else.

That all makes sense. Though I got the impression from this site that a lot more devices now support the home automation profile and light link profile then use too. Also it sounded like a lot of the problems has been the gateway device not supporting those profiles. Of course there are still manufactures that do there own thing like Xiaomi, but my impression is their are fewer of those types of manufactures out there.

I was looking at this device,  which claims to support all Zigbee devices that aren't proprietary. Out of the box it supports, home automation, light link, and smart energy profiles. So as long as the device you buy supports one of those profile the hardware will support it.
The gateway stick runs a webserver that has API access. The API was mostly developed for lighting devices but they seem to be adding more and more no lighting devices.

I went ahead and bought there usb gateway stick to mess around with. I am hoping I can use there API through CQC to command my locks.
Reply
#4
They may be talking about the old, limited home automation profile. There's a new version (Zigbee 3.0) basically creates a more Z-Wave like, consolidated profile that covers lots of bases.

But, it looks like the new profile is basically a combination of the previous ones, plus new stuff. So, the old devices it appears would work with a controller that implemented 3.0. So that would make it less of a risk to implement 3.0 I guess, assuming there aren't hundreds of ifs, ands, buts, and gotchas wrt to support of older profile devices.
Dean Roddey
Software Geek Extraordinaire
Reply
#5
Yes, deConz is an interesting approach and supported by a couple of other prominent HA software packages. It’s getting increasing attention.

There is zigbee2mqtt , also worth looking into which is ahem... an interface using MQTT.
https://github.com/Koenkk/zigbee2mqtt

Update... Sorry, I haven’t been keeping up to date with CQC for several years but just naturally assumed it now supported MQTT.. but it doesn’t it seems ? .. really .. so zigbee2mqtt doesn’t provide the ‘can do it now’ solution for CQC that I had expected it would...
Reply
#6
Dean here is yet another example where having an MQTT driver would add what is arguably significant value to CQC. 

CQC doesn't have to be a broker and really only requires a fully implemented client driver (security support, etc.) There is a great deal of information available on MQTT architecture.

Please consider this, by creating a MQTT client driver you open up CQC the doors to a myriad of devices and use case scenarios and provide a level of flexibility that you could not possibly build into the system yourself.  Those devices / use cases that are identified to drive significant core value to CQC could later be integrated as native drivers. It's the best of both worlds...

-Ben
Reply
#7
As a follow on, if there were a CQC MQTT driver I could easily bridge my SmartThings hub to CQC and expose all of the ZigBee sensors managed by ST. I don't have Zigbee locks but they are supported I believe.
Reply
#8
I needed to do some system updates (which take forever when you have multiple VMs and such) so I sat down and read the MQTT spec. It makes basic sense.

What it doesn't talk about is the actual messages that come from devices. Are all of them just ad hoc based on what the device manufacturer wants to send, or are are there the equivalent of our device classes defined for MQTT? If we have to individually add support for every type of device that will become an endless effort. If they do have such things, where are they defined?
Dean Roddey
Software Geek Extraordinaire
Reply
#9
(01-13-2019, 03:19 PM)UIPIf Dean Roddey Wrote: I needed to do some system updates (which take forever when you have multiple VMs and such) so I sat down and read the MQTT spec. It makes basic sense.

What it doesn't talk about is the actual messages that come from devices. Are all of them just ad hoc based on what the device manufacturer wants to send, or are are there the equivalent of our device classes defined for MQTT? If we have to individually add support for every type of device that will become an endless effort. If they do have such things, where are they defined?

First of all you only need the client implemented.   The message (topic) content is arbitrary but usually plain text or JSON, sometimes XML.   A lot of devices like lighting just implement a level value and on/off or ON/OFF or On/Off , yes, ... you can see the issues. The state and command topic are different and need to be defineable for a given MQTT device.

A lot of people use a message and/or topic translator or mapper, something like NodeRED to translate the topic hierarchy or message content between devices. Yes this effectively creates duplication.. but that’s OK as it’s very fast and MQTT brokers are not stretched by this. This allows a very minimal MQTT client implementation to still be very useful, although more configurable clients make things tidier. This approach effectively translates the topic messages into something CQC would expect.

There are two aspects .. one is importing MQTT devices into CQC and the otherexposing CQC devices to MQTT status reporting and control.

There are two emerging attempts at using ‘discovery’ of MQTT devices and their capabilities, one proposed by the HomeAssistant guys and another newer and more generic called homie 3. Most existing apps use more of a manual configuration still though.  Some  3rd party devices like Sonoff, Tasmota, Shelley have started to use these.

I do think MQTT is now becoming somewhat of an expectation in automation apps, which was why I was kinda surprised it wasn’t already supported in CQC. It really opens up the application to interaction and support for many other devices and apps.
Reply
#10
We are more pro oriented, and it's not the kind of thing that would typically be used in a professional system, so it's not been a big priority.

Without any sort of standard format, that's going to push it into Z-Wave territory pretty much, with some sort of means to define a particular type of device and how to get the data out of it.

If I did it, initially it would just be to get other devices into CQC.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  CML Driver IDE [copy/paste] does not work lleo 2 192 11-25-2018, 10:01 AM
Last Post: lleo
  How to update the new zwave stick/driver? ghurty 5 260 11-22-2018, 06:56 PM
Last Post: Dean Roddey
  "Client Side Driver Directory Could Not be Cleaned Out" TurboSam 15 1,270 09-27-2018, 01:43 PM
Last Post: TurboSam
  CML Driver IDE docs - where? rbroders 1 386 09-18-2018, 05:41 PM
Last Post: Dean Roddey
  Timer Driver Question kblagron 5 596 09-14-2018, 02:43 AM
Last Post: znelbok
  reset driver statistics? rbroders 9 1,067 09-11-2018, 07:50 PM
Last Post: Dean Roddey
  Driver Configuration w/8 prompts rbroders 1 546 09-03-2018, 09:28 PM
Last Post: Dean Roddey
  Driver info/stats rbroders 6 889 09-02-2018, 08:34 PM
Last Post: Dean Roddey
  Sonos Driver zra 3 619 09-01-2018, 03:09 PM
Last Post: Dean Roddey
  HTTP Get driver not working znelbok 10 1,253 08-28-2018, 10:10 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)