Semantic Field Type Discussion

[pjgregory]

But, wouldn't the appropriate type of display of status be something like an enumerated image, which shows maybe one thing for off, one thing for fully up and ready, and a third thing for not off but not ready?

I have just implemented this on my Cinema template for the JVC projector and Oppo96 drivers. I have a small Enumerated Image widget with Red, Orange and Green square images for Standby, Cool-down(Starting) and Power-on. This is linked to the Power field, but would eventually be linked to a PowerState field.

The first thing I have found is that there is an issue with the JVC Driver. These are the states.

1. No Power to the projector so the Device driver is not on line. No image is displayed. OK

2. Power is On and the Red light is illuminated showing the PowerSate is in Standby. OK

3. Send a write command Power-on. The Power field turns to Green showing Power-on for 1-2 sec, but then goes back to Red as standby. If remains Red for some 15-20 seconds while the projector is booting up, then it goes to a permanent Green showing that the projector is ON.

4. Send a write command Standby to turn the projector off. The light goes Red for 1-2 sec showing standby, then goes Orange for cooling 10-15 sec before finally turning Red as it reaches standby.

I think this reinforces the point the that the write command for Power should be separated from the read command to access the state of the device. I see that you have specified this in the Projector section. I think it should be universally applied to all devices. Since adding these indicators, I have found the same problem with the Oppo93 driver where the single bol Power field switches backwards and forwards as the device boots.

Is this the best place to discuss this? If not , maybe you could move this to the device driver section to start people thinking about the issues with Power fields.

PJG

[Dean Roddey]

Well, for most devices, there is no issue having a Boolean power field that is read/write. And, given that it is the most natural representation of power state, and the most convenient to use, that should be done where it's possible. And it almost always is possible. Most devices are either on or off and they don't bounce back and forth between the two in any usual way when powered on or off.

Projectors are just fairly unusual in that that they don't have discrete power on/off status, but also have in between states. It's only because of that that we need this separation of read and write for power. It's not something you'd want to do unless you have to.

[Mark Stega]

I think Blu-Ray players are, in general, closer to a projector than to most other devices. Startup in particular is liable to go through multiple states.

[Mark Stega]

The first thing I have found is that there is an issue with the JVC Driver. These are the states.

1. No Power to the projector so the Device driver is not on line. No image is displayed. OK

2. Power is On and the Red light is illuminated showing the PowerSate is in Standby. OK

3. Send a write command Power-on. The Power field turns to Green showing Power-on for 1-2 sec, but then goes back to Red as standby. If remains Red for some 15-20 seconds while the projector is booting up, then it goes to a permanent Green showing that the projector is ON.

4. Send a write command Standby to turn the projector off. The light goes Red for 1-2 sec showing standby, then goes Orange for cooling 10-15 sec before finally turning Red as it reaches standby.

I am not certain that it is an issue with the JVC driver as much as these are the states being sent by the projector. I suppose one could modify the driver to not report what the projector is reporting and to have knowledge such that "If I receive a power-on I'll set the field to "warming up" for 30 seconds before I report what the projector reports" and similarly on "power down immediately sets 'cooling'. We could use the same type of rule to transition to the 'final' state if we get that from the projector. OTOH, these states are what the projector is reporting...

[Dean Roddey]

In the case of media players, I guess the deal is that some of that could be considered 'media state' as opposed to 'power state'. The device itself probably powers on and off easily enough, but loading media is a multi-stage process. And that is represented in the media renderer device class with the MediaState field, and presumably would also be in any regular media player device class once we get that worked out.

Or does the actual power on process go through multiple states even if no media is present?

[pjgregory]

I am not certain that it is an issue with the JVC driver as much as these are the states being sent by the projector. I suppose one could modify the driver to not report what the projector is reporting and to have knowledge such that "If I receive a power-on I'll set the field to "warming up" for 30 seconds before I report what the projector reports" and similarly on "power down immediately sets 'cooling'. We could use the same type of rule to transition to the 'final' state if we get that from the projector. OTOH, these states are what the projector is reporting...

Mark

I think the problem is with using the same field for both commands and status. after all, if the Projector is in "Power-up" and you send "Standby", the field must pass through that state even if the Projector goes directly to "Cooling". I think it is the same on Power-up. The only issue then is do you leave it reporting reporting "Standby" until it finishes booting or do you create an artificial "Starting" state.

In my view, it would be much better to put this stuff in a driver, rather than have to write an explanation and have the user put ad-hoc timers and event triggers in their code.

Maybe you find time to create a V2 driver to try out how it would work in practice.

PJG

[wuench]

The important thing is a user and/or driver should not send:

Power=False if not in the fully ON state
Power=True if not in the fully OFF state

Either situation could cause issues, but the latter could actually cause harm to the projector/bulb. Not all projectors protect themselves from these conditions, especially via the control interfaces.

[Dean Roddey]

That's certainly something the driver should protect against.

[Dean Roddey]

The SecZoneStatus semantic field type was updated to include an Unknown value. This was traditionally supported, and it's one of the values of the standard CML zone status enum that some of the drivers use. And it's a useful thing to know if the zone goes into some unknown value (i.e. not one of the standard three states.)

However, it's not a valid Zone Alarm event trigger, so the CML driver helper methods that send Zone Alarm events will also be updated (for 4.4.931 and forward) to ignore any calls with an Unknown value and not send a trigger.

This way, we can have the useful Unknown state as a field value, but avoid getting into event triggers where it shouldn't be.