Before going further I wanted to deal with the user settable per-unit options. That is going to be considerably simpler than before because I'm just going to use the same attribute system that the interface system and various other things use now. That makes it easier to manage them in the driver, and of course easier to present them for editing in the client, and easier for the user to edit them.
Nothing uses them yet, but I was going to do one of those older multi-sensor units next, and it will have user options.
I also may go back and add some user options to some existing handlers to make them more flexible. For instance I current have a super-generic motion sensor handler now. But, with a user option to select what type of sensor it is, that guy could handle all kinds of binary state sensors generically. So I'll definitely do that.
I spent the day today really working out the user configurable unit options scheme, to make sure it's sufficient for the need, but no more complex than required and the least code necessary. I just go that finished up and it looks pretty good. That actually let me get rid of device info file infrastructure that I'd done initially, not thinking about the user configurable option stuff to come.
Tomorrow I'll do the multi-sensor as a more worst case scenario and deal with any issues it might bring up.
After that I think I need to look at the client side driver. That's going to be a bit of work, but best to find out now if there's shortcomings on the server side in terms of what's needed to support the client side. It needs to be considerably better than previous Z-Wave client interfaces, and provide more information about the state of the state and such.
Dean sounds like you are making great progress. Can't wait to toss out my serial port expander.
Will there be a model file for Z-wave devices so we can add new devices going forward without needing to bother you?
You won't be able to add new ones yourself. There is a file, but it works in conjunction with code and you'd have to know a lot about how it works to create them, and it has to be just so to make sure things work right. Trying to do a Z-Wave driver purely by a configuration file per unit just is an exercise in frustration, which is what the current VRC0P driver tries to do, and why it's pretty limited when it comes to more off the beaten path units. This one is more of a combination of a device info file parameterizing various handler classes.
Though, it is set up such that I can often create very generic handlers, which will make it less necessary to have a unit specific handlers to still get good functionality out of a unit. Some will always require a specific handler because they are just too quirky or different.
I got started roughing in the multi-function sensor handler for my Aeon Labs DSB05, which is a test case really badly non-conforming one. But I realized I don't have any AAA batteries, and I couldn't steal some from the others since they all use the lithium type ones. This old, crusty guy uses 4 AAAs and goes through them pretty quickly.
But I also needed to do a CC impl for multi-level sensor anyway, since it uses that command class. So I got started on that as well, and had to work out how it would work and get its setup info. I'll finish it up tomorrow.
And I was looking at how, for more compliant multi-function sensors that use the multi-channel system, how we could have a parameterized, generic handler for those. That made me realize I'd not taken into account the need to handle per-end point extra info in the device info file, so I need to deal with that tomorrow as well. With that, we should be able to tell a generic handler that channel 1 is a temp sensor via multi-level sensor class, channel 2 is a motion sensor via the basic class, channel 3 is a humidity via the multi-level sensor class, all via the device info file. That would make it much easier to support a range of newer, compliant multi-function sensors.
I updated the n-channel outlet generic handler to have a user settable option for each outlet, so you can set the names to something besides Outlet1, Outlet2, and so forth. That's a good use of the option system.
And I changed the generic motion sensor handler to be a generic binary sensor handler, providing a user option to select the sensor type, so that makes that guy very generally applicable for a wide range of single function sensors.
I banged out a lot of stuff today. I got what I think is the stuff needed for the multi-function sensor. A few more tweaks to the architecture makes it doable to handle such a completely non-compliant doohickey. I need to test it out more tomorrow.
I got the multi-level sensor CC impl done which this multi-function sensor guy needed, and lots of other sensors moving forward will use.
I got the multi-end point device info file stuff done. I'll have to look at picking up a modern multi-function one that uses the multi-channel interface and get a generic handler in place that should support various of those with just device info parameters.
I need to get the auto-config command done and the code to spit out the configuration msgs, which won't be a lot of work. To fully get the multi-function sensor working I need to be able to set some parameters.
But, anyhoo, still moving forward pretty 'rapidly' at this point, where rapidly is a relative term of course.
Dean I believe the
Aeotec MultiSensor 6 fits the bill of modern. It can also be calibrated so that might add an even more complex device for you to develop against.
That brings up a question, for devices that allow for parameter changes are you going to handle that as well?
The auto-config stuff handles parameters. The device info file will have the commands required to set up the device appropriately for the driver's needs. If it's not an explicitly supported device, you'll have to make those parameter changes yourself, if any are required. You'll be able to that via the client side driver or whatever you are using for a master if it provides for that.
This new scheme I have allows for more bases to be covered as well. So, for this one I'm doing now, based configuration it can send out motion events via Basic or Binary Sensor CCs. Though the auto-config sets up for binary sensor, and it creates a binary sensor CC impl to manage the motion field, it also creates a non-field based Basic CC impl and watches that as well, just in case. If it sees events there it pushes those into the binary sensor impl's field.
So, even if it lost that particular configuration, or something else change it, it would still see motion sensor msgs and get them sent to the right place.
Looking at that Multi-Sensor 6, the Z-Wave info site shows it doesn't support multi-channel, which I assume means that it STILL uses the totally non-standard scheme that the one I have does. Someone there should be taken out and slapped if that's the case.
I'm going to spend some time to day turning this one into a generic 'Aeotec Stupid Multi-Sensor' handler that should be able to handle any of them, given that they all seem to be done basically the same. That should let us handle whatever variations of that they have.