Closed lukescott closed 3 years ago
I'm absolutely open for discussion - if you search for TODO in my code, you'll find quite a few places where I still have to figure stuff out. So putting our heads together will surely help us all.
I'm not sure how regularly I can be active in channels, since all my development happens in the free time that is left over after my full time job and family time. Seems like you already found my issue tracker, so discussing there (or here) is probably the way to go for me.
I'm absolutely open for discussion - if you search for TODO in my code, you'll find quite a few places where I still have to figure stuff out. So putting our heads together will surely help us all.
I was thinking about something along the lines of a forum, or some common place for us to ask questions so we can do our best to help each other out. The code bases are different, but the protocol is the same.
I'm not sure how regularly I can be active in channels, since all my development happens in the free time that is left over after my full time job and family time.
I think that describes most (all?) of us here. For me it started with a hobby project wanting to control the lights in my home.
The goal is to be able to leave a question somewhere where we can all see it and (eventually) get an answer. Find places where we're trying to solve the same problems.
AlCalzone, with your command class implementation, is that done all by hand? In this library the command class code is generated with zwave-defs.xml
. There are likely some mistakes here, but that seems to mostly work. I was wondering what your experiences were with this?
Also one of my goals with this project was to find a way to mock a controller for testing. Have you done anything similar in that regard?
AlCalzone, with your command class implementation, is that done all by hand?
Yes. I've got a bunch of boilerplate templates for the tedious parts, but the actual implementation is done manually. When reading the specs, I found so many specific details and gotchas that auto-generating the code never occured to me.
Also one of my goals with this project was to find a way to mock a controller for testing. Have you done anything similar in that regard?
A teeny tiny bit. This is mostly the case why my test coverage is so low. I can test (de)serialization of CCs, I can test some basic driver behavior, but everything beyond that seemed unreasonably difficult to do for now.
Yes. I've got a bunch of boilerplate templates for the tedious parts, but the actual implementation is done manually. When reading the specs, I found so many specific details and gotchas that auto-generating the code never occured to me.
Do you have any notes on those?
A teeny tiny bit. This is mostly the case why my test coverage is so low. I can test (de)serialization of CCs, I can test some basic driver behavior, but everything beyond that seemed unreasonably difficult to do for now.
One big point of convergence for us could be testing. Just having some kind of interface to run tests against on the protocol level would be super helpful. The problem I have is the mock would never be truly "compliant".
If we got access to controller code/binary from Silica Labs (SDK?) we could potentially create one.
Do you have any notes on those?
I tried to comment all the CCs where specific behavior is taken from the specs. In later comments I also included which file the behavior was taken from. Some examples: https://github.com/AlCalzone/node-zwave-js/blob/e306b1944290b8397448fc3903d7a332aeaa5b2f/src/lib/commandclass/ConfigurationCC.ts#L1418 https://github.com/AlCalzone/node-zwave-js/blob/e306b1944290b8397448fc3903d7a332aeaa5b2f/src/lib/commandclass/MultiChannelCC.ts#L691 https://github.com/AlCalzone/node-zwave-js/blob/e306b1944290b8397448fc3903d7a332aeaa5b2f/src/lib/commandclass/WakeUpCC.ts#L219
However most of the specifics are a bunch of conditionals in CC serialization - serialize some field if version >= x or another field is set.
It would seem that there are quite a few people who are interested in building upon Z-Wave:
* Go: https://github.com/stampzilla/gozwave @stamp @jonaz * Go: https://github.com/opendoor-labs/gozw @parrotmac @zacatac * https://github.com/gozwave/gozw * https://gitlab.com/helioslabs/gozw @bjyoungblood * TypeScript: https://github.com/AlCalzone/node-zwave-js @AlCalzone
There is also this:
@AlCalzone I found the official source code: https://www.silabs.com/support/getting-started/mesh-networking/z-wave/controller-kit
Click "Download Z/IP Gateway SDK". It requires an account which you can register free. I found, for example, the full source code to ZW_SendDataMulti
in source/zipgateway-2.81.03-Source/usr/local/src/serialapi/Serialapi.c
.
There also seems to be C# code here https://www.silabs.com/products/development-tools/software/z-wave/embedded-sdk under "PC Controller". I am seeing Layers, Frame, and Command Class code here as well.
We're happy to see that folks are interested in furthering this work. Unfortunately, the Opendoor team isn't planning to invest any time developing this project.
If you have any questions about the changes we've made, feel free to reach out in the #gozwave channel in the Gophers slack.
It would seem that there are quite a few people who are interested in building upon Z-Wave:
On the Go side it would be nice to consolidate our efforts to a single library. I do like Ben's implementation as it lets you work closer to protocol without overly abstracting things. I personally have had issues trying to do things in OpenZWave because it tries to do too much for you (example: resets Jammed status on lock when still jammed).
On the TypeScript side... Holy moly. AlCalzone, I am blown away. I love having pure libraries in my two favorite languages. At the very least I want to get a mind-share going to help each other figure out difficult aspects of the Z-Wave protocol. And share notes on testing methodologies.
I personally do not have a lot of knowledge of the Z-Wave protocol itself. I'm more knowledgeable on the HomeKit side of things. And I write in Go and TypeScript for my day job.
At the very least I want to get a dialog going. Maybe even a shared Slack channel (that is less dead than Gophers Slack #gozwave channel).