Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Some early thoughts on 5.4
#31
Deane's comment on RA2 got my attention, and I thought I missed something, but to be clear the RA2 driver does not have shade support either. It just happens that the shades can be added to the driver as "dimmer" devices and the dimmed value is how the shade will open/close...

In fact the are no class definitions for shades or blinds yet. A while back we got thus far to exchange a few posts on what CQC shade/blind support be, but never defined any.
Reply
#32
In terms of auto-magical support, having a device class definition for shades would be useful if there is enough commonality out there to justify it. But, in terms of practical functionality, defining them as shades works fine AFAIK.

I don't know enough about any breadth of shades products to know what might be a practical device class definition for them. Are all of them basically either scene driven, or individual shades opened or closed to some percentage?
Dean Roddey
Software Geek Extraordinaire
Reply
#33
With in the C-Bus world they are much like a light. 0% is closed, 100% open. There are some special values such as 2% for stop.

There is a timer within the relay that is set according to the time it takes for the blind/curtain/shutter to open and the percentage is based on that time. So a blind that takes 40 seconds to open will run for 20sec when 50% is asked for. There is no feedback for position so it can only be inferred this way.

You would need, open, close, stop and percentage
Mykel Koblenz
Illawarra Smart Home
Reply
#34
It sounds like it could really only be write only if it was going to be something that could be generically applied to a range of shade products. If we can't really get position feedback reliably and across the board, we'd probably need to stick to just sending those commands (open, close, stop and percentage.) Obviously any given driver could expose the position info if the product provided, this is just the generic V2 device class bits we are talking about here.

Is it widely supported to go to a specific percentage open? Or in some cases is just open, close and stop, and you have to stop them where you want?
Dean Roddey
Software Geek Extraordinaire
Reply
#35
it would be read because CQC is not the only system issuing the command (in C-Bus). A light switch would also be configured to send the blinds to any position and CQC would need to be able to update itself with that information - just like a dimmable light
Mykel Koblenz
Illawarra Smart Home
Reply
#36
But the point is, is readability of the position widely supported? If not, then it can't be handled via V2 device class. It would have to be provided on an ad hoc basis by the drivers of those devices that can provide it.
Dean Roddey
Software Geek Extraordinaire
Reply
#37
Dean: I may be completely misunderstanding the concept of V2 drivers here. At some point, I thought slowly but surely all drivers will migrate to v2, to get autogeneration support, or other yet to be defined home/room level grouping and thus further structure automation. As is, CQC will never support any shades or blinds since there is no "consistency" between different providers.
Reply
#38
The point if V2 drivers is to define 'device classes' that can be very close to universally applicable to all products of a given type (or to some subset of functionality, such as audio or switching.) The ultimate point is to create consistent semantic definitions that can always be depended on, no matter what the product. That's the only way that auto-magical functionality can work, if it can use a well defined interface to access some sort of functionality and always can assume it will work as defined, even if you change to another device (that implements that device class.)

If it can't be always depended on, then either some devices just can't be V2 compatible (for that bit of functionality, though other bits might) and you just leave those bits as V1 style and deal with that functionality ad hoc. Or, if there's really no commonality to speak of, you just don't do any device definition for that type of functionality it just stays V1 ad hoc style. We'll never come up with a broad enough set of device classes to allow all drivers to have all their exposed functionality be V2 style stuff. And some just never will at all.

Or, you create a device class but it can only handle some very basic operations that we can manage to implement broadly, and leave anything else as non-V2 fields that you can use if you want device specific functionality. At some point if it's too basic it does little good to have it, since doing anything useful may require more functionality than we can generically enforce to any useful number of devices.

And that's fine. Some of the world just doesn't fit into a box. We just want to handle as much of the most common stuff that we reasonable can. Of course drivers can do a lot of force a particular generic semantic definition onto a device even if the device doesn't natively really work that way. But, ultimately, there's no point in having a V2 device class for some bit of functionality if it can really not be widely applied since it losses the whole point in that case.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  RIVA Web Image Widget support thoughts/questions for post-3.1 SamVimes2 3 1,697 02-01-2010, 06:33 AM
Last Post: wuench
  Thoughts about a post-3.1 world Dean Roddey 10 3,368 01-20-2010, 02:49 PM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)