Official 5.3 Beta Discussion Thread

[Dean Roddey]

Given what I'd learned during all that digging to figure out the lock thing, and having been forced to dig around into some other implementations, I've gone back and started over again from scratch. Well, I'll end up pulling over most of the code I've done so far in one way or another, but just in terms of really getting the architecture right. Simplifying some things, and adding some more abstractions such as for Z-Wave controllers so that it could support things other than COM port based ones if need be.

And also now that I know how it all needs to go together, I can do a strict, top down architecture and try to really get a better layered result and test it well at each level. I really had to jerk the current code around quite a bit trying to figure how to make this work or that work, so I need another run at it to patch the holes in the wall. This also makes it much easier to test via a little standalone program as well.

And also to make it a separate Z-Wave engine facility, not to have it all just in a driver. The driver will end up being just a light wrapper around that engine. This could have some other useful business benefits down the road potentially as well, who knows. We have a number of technologies now thusly implemented so that they can be embedded into any program, like the IR system and the web server and some others.

[JerryB]

For 5.3 I'd like to ask if you'd consider redoing your V2 thermostat driver to include support for heat only systems. I can't use your Autogen system for HVAC because I live in an old house in the northeast where A/C is not a requirement and my thermostats are only concerned with keeping the house warm in winter.

[batwater]

For voice consider adding Google Home / Assistant.

[Dean Roddey]

For 5.3 I'd like to ask if you'd consider redoing your V2 thermostat driver to include support for heat only systems. I can't use your Autogen system for HVAC because I live in an old house in the northeast where A/C is not a requirement and my thermostats are only concerned with keeping the house warm in winter.

It would be a nice thing to. But it also involves more than the auto-gen system. It requires a fundamental change in the V2 system, because it will require adding an ability to and have query options for a device class, which doesn't exist at all now. That opens a very big and ugly door for folks looking to do flexible and re-usable content, one that we've kept closed so far (for good reason because that's the door between us and the road to hell paved with good intentions that have made other standards so difficult to support that they are only barely standards.)

So it's a big thing to consider how best to approach. For the auto-gen system it's not so hard, since it's a dynamic thing that can spit out this or that. But for folks like installers looking to create re-usable interfaces and logic, once we go down the path of having options, that means dynamically adjusting to those options at run/viewing time, which is a much more complicated row to hoe.

[JerryB]

For 5.3 I'd like to ask if you'd consider redoing your V2 thermostat driver to include support for heat only systems. I can't use your Autogen system for HVAC because I live in an old house in the northeast where A/C is not a requirement and my thermostats are only concerned with keeping the house warm in winter.

It would be a nice thing to. But it also involves more than the auto-gen system. It requires a fundamental change in the V2 system, because it will require adding an ability to and have query options for a device class, which doesn't exist at all now. That opens a very big and ugly door for folks looking to do flexible and re-usable content, one that we've kept closed so far (for good reason because that's the door between us and the road to hell paved with good intentions that have made other standards so difficult to support that they are only barely standards.)

So it's a big thing to consider how best to approach. For the auto-gen system it's not so hard, since it's a dynamic thing that can spit out this or that. But for folks like installers looking to create re-usable interfaces and logic, once we go down the path of having options, that means dynamically adjusting to those options at run/viewing time, which is a much more complicated row to hoe.

I'll accept that you know the system better than I do and need to make decisions based on what you feel is best for your business and I'll continue to use the product either way. I'm very appreciative of what you've created. However, I don't see why handling a heat only versus a heating and cooling thermostat is substantially more complicated than what you currently do for lights/switches where the V2 driver can handle lights/switches that only support on/off, lights/switches that support on/off plus dimming, and lights/switches that support on/off plus dimming plus color. The Autogen system recognizes which features the light/switch supports and automatically enables those features and disables the unsupported features in the generated template.

[Dean Roddey]

As I said, the auto-gen system isn't the problem. But the device class system is also very much intended to allow for the hand-creation of reusable logic and user interfaces. That stuff would require building into the created logic and interfaces the ability deal with non-static aspects of a device class. The more such things there are, the less likely anyone will get it right and so the supposedly reusable content will fail when re-applied.

And it's not like adding this one extra thing will suddenly make the wheels come off, but it's a step that requires a pretty significant change in the device class system. We can't just make some ad hoc change to provide a means for querying whether a thermostat supports this or that. We would need to come up with a generic means of querying device capabilities and how to represent those capabilities such that they really are open ended and useful for any possible scenario that might come up. And we need to means to query them, which doesn't exist and would have to be included in drivers and those drivers updated to support that.

Switches vs. dimmers is different because they are simple devices, and telling them apart is easy enough because of both naming convention and semantic field type. And it's easy enough to treat them separately. But thermostats are composite devices (and there may be other such in the future where this comes up) and we'd really need to create a formalized means to define and propagate device class options/capabilities, to avoid ongoing ad hoc schemes.

So, anyway, it's not that I'm against it. I've been thinking about it all along. But it's a big step to take, because it becomes the first real step down this path and so all of the mechanism required to support it would have to be worked out and implemented, and drivers and auto-gen system updated to support that.

[potts.mike]

Dean,

I am not sure if you have settled on the final items for 5.3 but have you considered making the ECHO support compatible with the smart home skill API? It is much easier to use, but more limited, than the custom skill.

https://developer.amazon.com/docs/smarth...l-api.html

[Dean Roddey]

It would have to be a separate thing. We couldn't undo the existing Echo support, which is way more flexible than that. So it would have to be another option. It could be useful. I'd have to dig deeper to really understand it. Somehow they have to be told the names of the controllable things and provide some sort of linkage. How that gets done would be a big part of it.

[potts.mike]

Yeah, something to think about. The above link should get you started.

[Dean Roddey]

Mr. new lock is supposed to show up tomorrow, though I won't be ready to try it for a few more days until I get my last great rearrangement done. It's definitely coming out vastly cleaner than before, though of course I haven't gotten all the way down to the nitty gritty details again so far, and maybe it'll go to hell in a handbasket again, who knows?