Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Device Classification Discussion, Part II
#7
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
[INDENT]AIO
ClrLighting
ContactClosure
DIO
Lighting
Lock
MotionSensor
Power
Relay
ResourceMonitor
SceneCtrl
Security
Simulator
Thermostat
Weather
[/INDENT]

Has Power Requirements
[INDENT]Audio
AVProcessor
MediaRenderer
MediaRepository
MediaTransport
Projector
Switcher
Tuner
TV[/INDENT]


Not Sure
[INDENT]DeviceInfo

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
Reply


Messages In This Thread
Device Classification Discussion, Part II - by Dean Roddey - 08-03-2014, 08:38 AM

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

Forum Jump:


Users browsing this thread: 1 Guest(s)