Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Device Classification Discussion, Part II
Now that the device class and V2 stuff has come so far along, the previous discussion thread was pretty much a waste of space because so much spilt milk has passed under the bridge by now that all of that discussion in the other thread could only be misleading. Many things have been settled and having all of that pre-settled discussion would just confuse someone coming along later and trying to figure out what is going on.

So I'm going to toss that one and start a new one that resets the baseline to the current facts on the ground and current thoughts about moving forward.

[INDENT]Just to keep from losing sight of the original reasons for all this, which I'd definitely done and had to really get myself wrapped back around it:
[INDENT]Consistency of device interfaces. A (or an) historical really bonehead technical mistake I made was to just allow all drivers to go their own ways and not attempt to force consistency onto them. In my own defense, even a decade and a half later it's very difficult to figure out how to do this. It's very complex and always a compromise of some sort, no matter how clever you try to be. Even now after a couple releases into this process, it's still somewhat murky.

Auto-Generation. The lack of consistency always prevented us from implementing any real helper tools to auto-generate customization. Even the small amount of progress so far in 4.5 has made a big difference to the auto-generation system. It will get a lot more powerful moving forward.

Customization Reuse. One of the fallouts of that historical misstep is that it's always been very difficult to create user logic or interfaces or any other customization that would work beyond the specific gear it was designed for. This is a huge liability. It would be a huge improvement if you could swap out this device for that device and have everything basically work, possibly with some configuration of course. And the ability to create logic that can be easily reused would be as well.

Though the auto-generation system will be a fertile ground for utiliziation of standard interfaces, I hope it isn't ultimately the biggest one. A major benefit of this stuff will be the ability to create truly reusable logic and interfaces. Autogen makes it easier to get non-customized content, but really reusable logic and interfaces makes it far easier to folks to customize the product, using pre-fab building blocks. Of course this requires very strict standardization to work.

The two aren't totally separate either. The auto-gen system could spit out stuff that can be reused in various ways for customization purposes, i.e. extending the auto-generated content more easily. Some of it it may use itself, and some may be purely to aid in that extension.

Standard System Functionality. Another obvious application of this standardization would be standard functionality that works in terms of well defined interfaces, which we couldn't really do before. V2 should allow us to create more standard functionality for things like occupancy simulation, irrigation, security, power use optimization, and so forth.

Simplification. We really want to make the system easier to setup and ultimately to customize. It's arguable whether these changes will really make the product significantly easier to customize. But the auto-gen stuff will make it easier and easier over time to set up for basic functionality. Other stuff that will be made possible, such as the standard system functionality mentioned above, will lead over time to easier customization, so an indirect relationship but the standardization is key to that.

The answer (or our answer) to these issues was the creation of standardized interfaces called 'Device Classes', which define specific types of functionality that drivers can implement. These are more 'fractional' than the current device categories, in that they often don't generally imply any sort of overall device type, but expose specific types of functionality, e.g. power management, audio/volume management, source switching, and so forth. Most drivers implement more than one, and sometimes a good number of, device classes depending on what functionality they support.

This is very important because it means that you don't have to know anything about a specific type of device to manipulate its power state or its volume. As long as it implements a given interface you know how to use, you can do your thing to any driver that implements that interface.[/INDENT]

Setting the Bar
[INDENT]The big thing we need to do is understand the ramification of these desired outcomes and decide where we can 'set the bar' for the standardization of these device classes. In other words, at what point can devices just not be supported within the V2 system, because doing so would drag everyone down to far too low a level. This is a core issue. We want it to be as accomodating as is reasonable, however every accomodation means more inconsistencies that the users of the system have to deal with themselves, instead of it being dealt with implicitly as part of the defined device classes.

The problem is that, if your purpose is to allow customization that deals with a given type of device functionality, you must be able to assume that any driver that implements that interface reacts in well defined ways, i.e. implements the semantics of that device class, not just its field interface. Every deviation allowed is a deviation that customization (and CQC itself) must deal with every time it uses that device class interface. And it quickly begins to create a situation where customization will not really be reusable or transportable to another system, because people creating that customization will never deal with all of the possible variations, they will only make sure it works with their gear.

If we require very stringient standards for the device class interfaces, so that drivers have to meet the requirements of the device class, that minimizes ifs, ands and buts, and that in turn makes it easier to create quality customization content. The inevitable result of that is that devices that are less automation capable will either not be supportable, or it will require a good bit more complexity in the driver itself so that the driver can make up for the lackings of the device.

Obviously we don't want to arbitrarily make drivers harder to write. But, ultimately, there are vastly fewer drivers and driver writers than their are customers and installers creating customizations. If putting more burden on the drivers makes it far easier to create adaptable, reusable logic, then within reason it's a win.

We obviously also don't want to arbitrarily leave devices out of the V2 fun. But, if supporting them means that we have to lower the bar too much, that's not a win. It makes everyone suffer for the lackings of a minority of gear. We will accept some compromises in the sense that some gear may have functionality above and beyond that required by our standardization requirements. That functionality will not be accessible via V2 interfaces, though it can always still be exposed via non-V2 fields if you want to deal with it in a non-portable way. And some burden may be placed on the creator of customization to do things that aren't strictly required by his own gear, because that allows the customization work even with less capable gear.[/INDENT]
Dean Roddey
Explorans limites defectum
[INDENT]This section will deal with some of the strategies by which we deal with how the bar is set and they rationale behind them. It's always a tricky situation, but we have to find a balance that works and get it figured out as quickly as possible. We still are in the situation where the number of V2 drivers is small, so any tweaks need to be found before there are a lot more of them and it becomes impossible and we end up stuck with evolutionary baggage forever.

Some possible workarounds are suggested. If any of these are used, they MUST be well documented in the driver documentation page so that the user can be aware of the consequences of using that particular piece of gear. And the V2 Compliance indicator must be set to Partial, not Yes.

[INDENT]Readable Fields.One common suckage of some less automation friendly devices is that you might be able to write to the field but not read it, for reasons that are purely just because they didn't implement it, not because it's impossible or meaningless to do so. These types of devices, in many cases, are just going to have to be left behind. In order to create high quality, easy to use, modern interfaces we have to use things like sliders, progress bars, volume knobs, check boxes, etc... These things require that the values they control be readable. If we don't require that values be readable, then portable interfaces could only use pushbuttons to do things, which isn't acceptable.

So we will have to set a fairly high bar wrt to fields being readable. The device class documentation will be updated over the coming days to reflect this. The number of drivers affected will actually be very small if at all, since all of the ones done so far aren't particularly (or at all) lacking on this front.

One way you might get around this is to set a default initial value on driver startup, and any values subsequently written to the field just becomes the new current value. This is not optimal at all, but if it can be done without becoming dangerous or being useless in practical application, then it's a possibility. If the device is only controlled via CQC, then it may be practical. But it does mean that the initial value may not reflect reality. Clearly for certain types of devices this would not be safe.[/INDENT]

[INDENT]Dead if Off. Another particular troubling but all too common aspect of devices is that, when off, they will not respond to commands or serve up current status data. They have to be on in order to interact with or get information. Because of the prevalence of this problem, though it sticks in my craw to do it, we will have to compromise a bit.

The problem of not responding to commands will be the biggest one. We will require that drivers reject command type field writes until they are powered on, even if they are capable of accepting the command. They cannot force the device on or just do the command because it's possible. They must reject the command. If we don't do this, there is zero chance of creating truely portable customization. It forces everyone to follow the global rule that you must power on gear before you can send commands to them. If all drivers enforce this, then any logic that works will work even in the case where the device cannot deal with commands when off.

Ultimately, this is not THAT big of a compromise in itself. It is not unreasonable to expect that you should have to power on gear before you send it commands. However, it also means that all drivers MUST implement the Power interface, even if they don't do anything in reaction to it other than just update the fields. Without this requirement, we again cannot hope to create reusable logic. So it will just become part of V2 compatility checking (once that is implemented) that the driver implements the Power interface. It sucks but without these compromises, then a fairly large group of devices won't be supportable.

In terms of not being able to get initial data, this falls into the 'Readable Fields' bucket above. You must provide default initial field values that are safe and reasonable, until you can get real data.

If the device is powered back off, the driver MUST just maintain the existing data it has. The device is off and can't change state, so the last values gotten from it have to be reasonably reflective of its current state, and makes the values available for display.[/INDENT]

[INDENT]Power Management. As mentioned above in the Dead if Off section, power management is a tricky situation that has to be well standardized. A core requirement is going to have to be that you must power on devices before you interact with them, send them commands. You can count on being able to read the fields of any device that is online, but the device must be powered on before you send commands to it (field writes, and any backdoor commands that aren't just querying information.) That doesn't mean that there won't be device class specific extra constraints, but this is just a general rule that must be enforced.

Because of that, even if a device can accept commands while off, it must reject them. If we don't do this, then it will be a pipe dream to think that folks will create portable customization. They won't deal with constraints that don't exist in their systems, and it will also potentially bite them within their own systems if they replace a device later. This will require all customization to deal with device power on issues.

It also means that all drivers will have to implement the Power interface, even if they don't actually have the concept of a power state. Without this, the logic that knows it must power on on all devices will inevitably fail when it is presented with a device that doesn't implement that interface, accessing non-existent fields. Supporting it in this faux way will be trivial to do.

Another related issue is that of delayed power on. Some devices take a long time to power on. Given that, having a read/write PWR#Power field isn't meaningful. The fact that it is true or false doesn't mean that the device is ready or off, it only guarantees that such a command has at least been invoked to start the transition to those states. To really know this you must look at the PWR#PowerState field and wait for it to go to Ready or Off, respectively.

So, to avoid people accidentally relying on the Power field, we have to make it write only. This will insure that folks have to use the PowerState field. If you do that, then you are guaranteed to deal with any device, whatever it's power up time. Any power on indicators or check boxes must use the PowerState field as well to be accurate. It also tells you if you are in a transitional state as well, powering down or powering up and can be used for more useful display info that the Power field.

This will of course be a small breaking change for those folks who have been using V2 drivers already that implement the Power device class. But it's an important to change to make now before it becomes impossible to deal with.


There may be other such concerns that come up over time, but these are the ones that really impact where we set our bar in a fundamental way. If we could leave out Dead If Off devices, we could take the bar up another nice chunk, but it would come at a pretty big price in terms of breadth of V2 device support.

Forward Thoughts

Just some thoughts about things not yet implemented that could be useful or helpful.

Device Categories in V2. Something that I've been thinking about is how we might use the device categories in the V2 world. We still have them, and they are really just used for categorization for human consumption. But, we might be able to take the standardization another step and define that a device of category X MUST at least implement these device classes. That could also allow us all to make some very productive assumptions about a device based its device class. It MAY and often will implement other device classes, but to assure some basic level of class interface implementation could be useful.

This could also help ease the requirement that every driver implement the Power interface, since there may some types of devices that will never need to, though one doesn't come to mind right off hand.

It is the case that, even if a device cannot support the device classes that represent its core functionality could still benefit from implementing some device interfaces. However, this becomes tricky in terms of what assumptions can be made. For instance, even if you only could implement DeviceInfo, that could be useful. But, if we defined minimal compliance at the device category level, this couldn't be done. It would be a sacrifice but one worth the benefits of standardization I guess.

Caps Flags. It is also possible that some device classes could require that the driver report a set of 'capabilities' so that client logic could adapt to it. For instance they could all have to implement a device caps device class, and report things like do they support power management or not, and a list of all of the device classes they support.

This isn't unusual in these types of circumstances. However, it does again mean that implementing truely portable customization content become less and likely and more and more complex to do because more variations have to be dealt with, variations which the creator may not be able to replicate for testing.

I think that keeping things a simple and fixed and well defined as possible is a better solution, even if possibly more limiting.
Dean Roddey
Explorans limites defectum
(reserved 1)
Dean Roddey
Explorans limites defectum
(reserved 2)
Dean Roddey
Explorans limites defectum
OK, so having had a lot of time over the last year or so to think about this issue, I've created a new discussion thread that restarts us from the current perspective. So much of the old thread was either already decided, or not going to be done, or speculation that would badly muddy the waters for anyone coming along now.

I tried to sum up the issues of where we are now. Any comments would be much appreciated. I know it's a lot to get your head around perhaps, but it will affect you so even if just don't understand something and want clarification, speak up. I can tweak the text to make it more understandable. That was all written stream of consciousness, so I'm sure it could be better.
Dean Roddey
Explorans limites defectum
On possible alternative to every driver having to implement Power would be the availability of a command like Devices::SetPower(moniker, false|true) which would check to see if the device implements Power and, if so, if it is currently in the other state, and issue the appropriate field write if so. And a CML equivalent of that as well of course.

That might be a good option so as only to require drivers that actually have power semantics to have to implement Power.

Within the interface system, a version on the IntfViewer target could be provided something like:

Intf.Viewer::SetPower(moniker, false|true, pathtowaitpopup)

So that it could automatically do a wait popup using a popup you provide, automatically dismissing it when power reaches the indicated state. Doing a short wait first of course to see if it's one of those that does immediate power on and just returning. If nothing after a short period of time it could do the popup that waits for the transition to complete.

That could help a lot to simplify the power management requirements. The auto-generation system obviously would generate one for you and invoke the command where necessary.

You could always choose to use states to disable buttons other than power on so that they can't be used until the device is ready. Or just invoke the above command first in any button that might send the device a command that requires it be on. Either would work reasonably.
Dean Roddey
Explorans limites defectum
I posted this over in the beta section when I should have posted it here...

I woke up in the middle of the night (again) thinking about power stuff last night. I thought of something that makes a lot of sense and which will lessen the Power Management burden. The basic idea is that there are certain devices for which the likelihood of them ever actually having power off/on is so low that, if one of them actually did, it could be treated as an anomaly outside of the V2 realm. It would just have to be dealt with manually outside of the V2 world, or just insure it stays physically on.

We could just limit the requirement to implement Power to a set of devices that are reasonably likely to have to be powered off and on. The validation system could check and say, since you implemented device class X, you must also implement Power. So it could be restricted to those drivers that implement one of those specific power management dependent device classes. That list could grow in the future as new device classes are added, but of the ones currently defined and being implemented:

No Power Requirements

Has Power Requirements

Not Sure

DeviceInfo is a tricky one. It's so simple and may be implemented by a lot of drivers, but many devices will have to be powered on in order to query their current model/firmrware info. But that would also mean that every device that implemented it would have to support power, which would be sort of a disincentive just to get a couple pieces of info that are seldom needed.

We could say that it doesn't require Power, but that if the device can't provide it until powered on that the values be set to some pre-defined 'unknown' value. That probably makes the most sense.[/INDENT]

Anyhoo, this way we have a well known set of device classes that the client needs to make assumptions about wrt to power management. No one is going to make a security system that you can power off and on remotely. Or a lighting system you have to power up before you can control lights. That would make no sense. It's possible that some other things, like maybe a small AIO/DIO box or something might have a power state, but it would just be a requirement that it be physically powered on at all times, or that the power management be dealt with manually outside of V2 generic logic.

This seems like a reasonable approach that limits the hurt to only those types of devices that it is almost ever going to be applicable to. Of course there will still be plenty of drivers that end up implementing faux power support. Few of the media repos really need power, for instance, but they implement various classes that will require it. Still, it'll be a vastly smaller number than all V2 drivers. And, as long as the requirements are well understood, and the validation system helps enforce it, it shouldn't be a huge issue not to have power support available universally.

I will add a Power Management section to each device class indicating if it has to implement Power or not, to help make it easier to track.
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  Device Class Index Dean Roddey 1 3,322 07-25-2014, 05:11 PM
Last Post: Dean Roddey
  Semantic Field Type Discussion Dean Roddey 18 18,848 06-23-2014, 08:29 AM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)