I would like to add IR support into my app. Right now I will only focus on devices that use the urn:schemas-micasaverde-com:device:IrDevice:1 device type. This is usually devices created by Vera’s AV setup wizard or adding support for the iTach devices. I will implement a generic type control for this device to try and cover most of the ir devices. I would like to ask which controls would you like to see supported? I have the following in mind:
Power
Volume / Mute
Media Controls (Play, Stop, Pause, etc)
Mind you that not every device will have some of these controls, but they will still be displayed.
Garrett,
You’d be better off looking at the ServiceId’s that are implemented by a Device, instead of looking at the Device Type it’s declared.
The ServiceId’s are restricted to ones like (not a complete list):
[ul][li]urn:upnp-org:serviceId:SwitchPower1[/li]
[li]urn:micasaverde-com:serviceId:DiscretePower1[/li]
[li]urn:micasaverde-com:serviceId:Volume1[/li]
[li]urn:micasaverde-com:serviceId:InputSelection1[/li]
[li]urn:micasaverde-com:serviceId:MenuNavigation1[/li]
[li]urn:micasaverde-com:serviceId:NumericEntry1[/li][/ul]
I’ve listed SwitchPower, since some of the Media devices use it, and can provide “current state” feedback via it’s values. It’s a natural compliment to DiscretePower, for those cases where the current state can be determined.
Going after the Device Type is going to be a loosing battle, since Bugs in Vera force folks to change/customize this in order to get UI’s within Vera… so you’ll be adding them one-by-one if you take that route, and it’ll be painfully slow.
[quote=“guessed, post:2, topic:180116”]Garrett,
You’d be better off looking at the ServiceId’s that are implemented by a Device, instead of looking at the Device Type it’s declared.
The ServiceId’s are restricted to ones like (not a complete list):
[ul][li]urn:upnp-org:serviceId:SwitchPower1[/li]
[li]urn:micasaverde-com:serviceId:DiscretePower1[/li]
[li]urn:micasaverde-com:serviceId:Volume1[/li]
[li]urn:micasaverde-com:serviceId:InputSelection1[/li]
[li]urn:micasaverde-com:serviceId:MenuNavigation1[/li]
[li]urn:micasaverde-com:serviceId:NumericEntry1[/li][/ul]
I’ve listed SwitchPower, since some of the Media devices use it, and can provide “current state” feedback via it’s values. It’s a natural compliment to DiscretePower, for those cases where the current state can be determined.
Going after the Device Type is going to be a loosing battle, since Bugs in Vera force folks to change/customize this in order to get UI’s within Vera… so you’ll be adding them one-by-one if you take that route, and it’ll be painfully slow.[/quote]
Guessed,
We been down this road before. It would require me to rewrite a good portion of the app to accommodate only looking at the service type. The UI controls are based on the device type / plugin. It would also get very complicated to dynamically build the controls. I would still run into the issue of which buttons to show for those service types. By using the device type, I can create a generic UI for the IR Device and have some basic controls. Going by Service Type is great for say HomeWave where you build your own setup, but where I am predefining the control UI, device type is better to know what I need to present to the user.
and, as we’ve discussed privately before, relying on the ServiceId’s means that people could get “partial” UI’s just for implementing services that have already been standardized.
ie. Implement SwitchPower, and you get an On/Off switch in the UI
It’d also avoid the need to implement a complete set of ServiceId’s, just to get a fixed UI, even when the other things aren’t needed (or aren’t implemented yet, like the UPnP AV stuff)
For those more advanced cases, it would need more logic to handle “what” to display, but it would be more adaptable to newly developed plugins.
ie. If I implement AlarmPartition1 and SwitchPower, the UI could display control widgets for both functions (with some internal ordering, as needed for consistency)
Then the reliance upon DeviceType could be relegated to those cases that truly need a custom UI implemented within the Control point.
There are more flexible models to do the UI-Data binding, but the above would go a long way to a default behavior, without the Plugin author having to do anything too special.
Maybe, but relying solely upon DeviceType is going to be slow and painful. It’s a useful “master switch”, for some fixed UI, but having a backup like “I don’t know this Device Type” and having it render an [ordered] set of controls based upon the list of implemented ServiceId’s would give a really good behaviour.
In many ways, this is what Vera itself is doing at the ZWave level. It has a set of defaults, based upon the ZWave capabilities responses it gets, but these can be overridden in the user/sys_zwave.xml files for things that “don’t quite fit” or need something extra.
I’m not talking about replacing the existing logic, but instead augmenting it for the case where you really don’t know what to render.
Yes, and no.
Many existing “AV” devices are using a variety of different Device Types:
Onkyo - urn:schemas-onkyo-com:serviceId:Receiver:1
Denon - urn:schemas-denon-com:device:receiver:1, and urn:schemas-denon-com:device:receiverZone:1
Sonos - urn:schemas-micasaverde-com:device:avmisc:1 (same as the original Onkyo)
Pioneer - urn:schemas-micasaverde-com:device:receiver:1
SQBlaster - urn:schemas-micasaverde-com:device:tv:1 (for generated/converted IRBlaster files)
and there are a bunch more of those “standard” DeviceTypes that MiOS has inside it. These already conflict in Vera’s UI due to the fixed-nature of it using the DeviceType as a rendering vehicle.
Another approach to the Unknown device is to parse the D_XXXX.json entries for the devicetype and dynamically build the UI in a similar manner to how it is generated on the Vera Dashboard.
Yeah, I was avoiding that due to how the JSON file, and it’s rendition, gets changed per rev (UI5 broke UI4, UI6 breaks UI5, etc)
One of the other control points does something like that but, IMHO, I find it very clunky to use… even if it’s technically impressive 
SQRemote does an id=actions call on each new device, so it can describe what services are implemented. It caches the results so it’s a one-time hit to [accurately] understand what’s there. That API call hasn’t changed in yrs, so it would be reliable to use in the case where the DeviceType was not “understood”. Each service is also well know, and doesn’t change often, so building the widget for that would be modular (as I’m sure Garrett’s existing stuff is)
Bottom line, just trying to avoid the cross co-ordination required as each “thing” comes online and needs custom plumbing into everywhere. The model’s not going to scale, not even for basic functionality.