Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Projector
#11
Quote:PowerTransTime. This is a read only Time based field. When a request is made to the projector to change power state, this field counts down the time until the projector will reach that state.
Shouldn't this field be either a TimeSpan or even more simply an integer? Time doesn't really make sense.

Quote:Source. This is a read/write field used to get or set the currently selected source for the projector. It MUST be marked with the InpSource semantic field type and conform to the definitions of that type.
I think you changed the semantic field type to SourceInp (or the semantic field type is named incorrectly).
Mark Stega
Reply
#12
Time fields can be used either for actual time stamps or time spans. Having it be a time field means you can use the fancy time display stuff to show countdown times and such, so it has advantages.

I'll look at the other thing.
Dean Roddey
Software Geek Extraordinaire
Reply
#13
OK, I updated the first post to use the correct SourceInp semantic type name.
Dean Roddey
Software Geek Extraordinaire
Reply
#14
I started to update the JVC-RSn driver to use the fields defined above and quickly hot two issues:

Aspect - On a DLA-RS2 this is a write only field with the only value allowed of "Aspect+" which cycles through all available modes. Later models added discrete write only aspect ratio commands. There is no report of the current aspect ratio. I'd propose making this field a W or R/W field to accommodate. In my case it would be a W field with a range of only one choice, "Aspect+". Otherwise I would have to implement this as a R/W field that always returns "Aspect+" (or whatever I chose as the one enumerated value to be written) as its value.

PowerState - On all of the JVC's there is an additional power state that is useful to report (called Emergency on later projectors, Warning on earlier models). I propose adding an "Error" state to the list of acceptable states.

PowerState - On the JVC projectors remote buttons & state name for power "Off" is "Standby". This reported state will get mapped to "Off".
Mark Stega
Reply
#15
On the aspect, that would end up just not being within the context of the device class. So it would just have to provide a single 'None' value in the limits and do nothing when written to.

You can provide a separate NextAspectRatio or some such type of field. Or we could incorporate such a field into the standard, since obviously any driver could implement that in terms of a set of discrete ARs by just moving to the next one on its own if the device doesn't provide such a command directly.

So let's go with the NextAspectRatio option. It's just a Boolean, write only, and writing any value to it moves to the next ratio. I'll update the first post.

Adding an Error option to the state is fine. It's read only so it places no burden on drivers that don't support such a thing. I'll update the first post to include that.
Dean Roddey
Software Geek Extraordinaire
Reply
#16
Dean Roddey Wrote:On the aspect, that would end up just not being within the context of the device class. So it would just have to provide a single 'None' value in the limits and do nothing when written to.

You can provide a separate NextAspectRatio or some such type of field. Or we could incorporate such a field into the standard, since obviously any driver could implement that in terms of a set of discrete ARs by just moving to the next one on its own if the device doesn't provide such a command directly.

So let's go with the NextAspectRatio option. It's just a Boolean, write only, and writing any value to it moves to the next ratio. I'll update the first post.

I'd rather not have a separate field because a user of the driver then has to use projector knowledge as to which field to use. So I'd rather use the original aspect field as RW with a single value of "Aspect+". That way an interface template need only to present the user with a menu of allowed aspects no matter what the projector capabilities. Showing Aspect+ or None as a current aspect are equally useless so on balance I think the single field is better.
Mark Stega
Reply
#17
That just seems to hacky to me. The point of the enumerated one is to discretely set and display the current AR. If it can't do either, then it's best to set it up such that any auto-generation tools could be aware that it can't use that field, and should just use the next AR field instead.

If you can't discretely set ARs, but you can read them, then it should be a read only field that just shows the ARs, and they can use the next AR field to select new ones, but still can see the currently selected one.

We don't want to do anything ad hoc in these device classes, since that's really the antithesis of what they are about. It's best to provide ways to indicate where functionality, though present enough not to break anything if you swapped in a new driver to an existing system, is not really useful so that alternatives can be used when generating logic or interfaces.
Dean Roddey
Software Geek Extraordinaire
Reply
#18
I was thinking maybe we could just have the AR enum field always include a Next and Previous entry. Since they would only ever get written, the driver would never return it as a readable value. However, that always is somewhat of an issue (technically and conceptually) when you have values of a read/write field where writing one of those value doesn't result in that value becoming the current value of the field, which would be the case if we did something like this. It's really better to have such things in a separate, write-only type field for consistency.

One thing that could be considered is each device class could provide, in the manifest, a set of 'capabilities flags', where optional functionality is indicated. Or have a backdoor method that reports them, which might be better since sometimes the capabilities might depend on the model the driver finds itself connected to. That could be used by automated/helper tools to figure out if certain things aren't available.

But, on the whole, I'd prefer that functionality that isn't available just not do anything, but not break anything either. Given that any driver that has read/write ARs could implement a Next AR type function, you could always have a Next AR button on a user interface, in addition to a list of ARs from the enum, which could be used when the discrete list isn't available.
Dean Roddey
Software Geek Extraordinaire
Reply
#19
Dean Roddey Wrote:One thing that could be considered is each device class could provide, in the manifest, a set of 'capabilities flags', where optional functionality is indicated. Or have a backdoor method that reports them, which might be better since sometimes the capabilities might depend on the model the driver finds itself connected to. That could be used by automated/helper tools to figure out if certain things aren't available.

But, on the whole, I'd prefer that functionality that isn't available just not do anything, but not break anything either. Given that any driver that has read/write ARs could implement a Next AR type function, you could always have a Next AR button on a user interface, in addition to a list of ARs from the enum, which could be used when the discrete list isn't available.

The Next AR button idea is not good as it requires all templates to include it on the possibility that the template is used with a projector that doesn't have a discrete AR set of choices. Overall, once ytou start adding capabilities, etc, it is far simpler to have the AR filed either RW (meaning it makes sense to display the field value) or WO (meaning it doesn't make sense to display the value) and you always take the toute of letting the user pick from the enumerated list.
Mark Stega
Reply
#20
OK, well, yeh, in this type of case, since the values to display aren't being gotten by reading the field, but by looking at the field limits, that would work.

It's quite possible that someone would have a display of the current AR and that would break if the field was made WO, though it wouldn't break in the won't load sense, it just wouldn't display the value.

But, one place where such a thing could cause problems is when someone sets an AR and waits for the field to change to that AR, since projectors sometimes take a while to make such changes and you might want to delay playback until it's settled. That functionality would break in an error generating way since it would assume readability.

In cases without readability but with discrete setters, we could keep the field read/write but always just assume the write worked and set the field to that newly written value. Start it on an Unknown value when the driver comes up. But, in your case, maybe just having the current value always be the one value for read purposes would be best.

That sort of strategy would most likely go the farthest in terms of maybe not working completely, but also not causing anything to fail in an error causing way.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: Thermostat Dean Roddey 17 9,141 01-29-2016, 10:15 AM
Last Post: Dean Roddey
  Class: SceneCtrl Dean Roddey 20 3,778 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,971 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 2,085 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 2,164 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 5,941 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,628 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,746 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 2,042 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 1,517 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)