The Node Bridge & Creating Vdev's for non supported devices

Discussions about Z-Way software and Z-Wave technology in general
Post Reply
tornadoslims
Posts: 2
Joined: 02 Mar 2016 07:58

The Node Bridge & Creating Vdev's for non supported devices

Post by tornadoslims »

Hey folks -

This is my first post, but I've been a deep reader of the forum for many months now. After buying 6 "smart hubs" I've finally decided to put all my eggs in the Z-way basket because of the openness of the platform. I think there is an IMMENSE amount of value in the abstraction of the Z-wave protocol into native javascript, and Z-way is truly the only thing out there that does that. I have thoughts on ways to augment that but thats another post - no suggestions allowed on post #1 :)

I'm an experienced javascript developer and am getting close to open sourcing a Z-way -> Node bridge over websockets. I've heavily leveraged the previous work and insights of all the awesome active members of this forum (especially PoltoS, pz1, pofs and others), and couldn't get to where I am without all their informative posts - so thanks to all of you (and that 07 github repo :).

I believe a Z-way->Node bridge could very quickly raise Z-way to the status of Openhab. Virtually every openhab binding has a NodeJs equivalent, and the node community is probably 1000X the size of the Openhab community. No disrespect to openhab - again I have personally bought every hub out there and have ran my home on all of them, as well as virtually every open source HA system. There as just some things I personally don't like about openHab, but they are all primarily personal preference stuff - not negative comments about the platform.

More on all the above soon. I'm building a normalization engine so as I plug in Zigbee and other protocols every device will be abstracted the same json format, etc, etc. For now - I need some help one one thing!

The 07 code (https://github.com/Z-Wave-Me/O7) elegantly uses vDev's to push device updates out. The only problem I have found with it (which is not necessarily a Z-way problem - Z-way strictly implements the Z-wave protocol so it can be compatible with devices it has not seen before), is that devices that don't properly implement the Z-wave protocol - and there's a lot of them - don't have vdev's created automatically. One example is the Leviton Scene Controller (http://www.leviton.com/OA_HTML/SectionD ... tion=44147).

I still get events - when I push a button on my Leviton controller Z-way gives me the command class the action and a ton of other data in the logs and in the raw event bus (which is how I am currently tapping into events) -

16-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.supported = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.supported = True
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.version = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.version = 1 (0x00000001)
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.security = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.security = False
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewDone = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewCounter = Empty
[2016-02-27 10:39:26.044] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewDone = False
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewCounter = 10 (0x0000000a)
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.currentScene = Empty
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.dimmingDuration = Empty
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.supported = False
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.version = 1 (0x00000001)
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.security = False
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewDone = False
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.interviewCounter = 10 (0x0000000a)
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.currentScene = 4 (0x00000004)
[2016-02-27 10:39:26.045] [D] [zway] SETDATA devices.13.instances.0.commandClasses.43.data.dimmingDuration = 0 (0x00000000)

currentScene is the key element here which I can derive from the Z-wave standard for command class 43, but the device does not have a vDev auto created because the interview fails on Version, so I can't elegantly use vDev's to trap events. I'm 100% fine continuing down my current path (you register the command classes you are interested in and all devices with those command classes automatically get forwarded to node running on the same PI or on multiple other PIs, and then get emitted as events in the node event loop). But I figured I should ask the experts here if there is a simpler way - if I can iterate all devices and write code to create vDevs for devices that don't normally have them created I can use the vDev api. OR maybe somebody has an even better idea.

I'm happy to write all the code - I'm really close to being done :), but figured its time for me to start posting and asking those more experienced than me with Z-way.

Thanks again for everyone's work on this project - it doesn't get the public recognition it deserves IMHO and I'm hoping to help change that.

Tslims
Post Reply