Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Semantic Field Type Discussion
This thread is for discussion of Semantic Field Types. There is a sticky thread at the top of this section that provides definitions of the current types, or at least it provides an indication of the current types. Not all of them are strictly defined at this point. This thread is for discussion of these types, definition of the ones not yet well defined, possibly refinement of those that are.
Dean Roddey
Explorans limites defectum
As a part of these classifications, I think you should provide the field definition info too, i.e. (Type, RO/RW, Limits) if possible in the threads... Also, I wish there was a way we could use descriptive names instead of numbers to iterate fields if possible. So instead of Dimmer_# I would like the option to use Dimmer_Name, etc. I think if the it is available in the unit names are easier for the user to work with than numbers.

Additionally, on the topic of using names in fields, it would be nice if spaces (and maybe more of the ASCII character set) were allowed so that names can be made more easily compatible with the unit names the devices provide. And it would also be nice if the SetFields would have some scheme to automatically convert field names and mitigate duplicates (add an index, etc). I have a couple of drivers where I have written that conversion function myself and others have as well, but if the field rules change that could be a lot work to change in all the drivers.

And as a minor suggestion I think more descriptive classification names could be more user friendly, I know we live in a texting society these days, but... Smile

So something like:

MyLightDriver.(Light)Living Room Sconces


MyLightDriver.Light.Living Room Sconces

Seems more user friendly than:

My Home Theater/Automation Website

[THREAD=5957]BlueGlass CQC Config[/THREAD]
[THREAD=10624]Wuench's CQC Drivers[/THREAD]
Redundantly entering all that info about the fields just isn't practical. It would require updating them all if there were any changes or refinements. I'd prefer to keep the semantic types separate and only reference them.

On the naming thing, it's already the case that named things are supported where that's appropriate in each device class.

Allowing spaces and other things like that in the field names isn't going to be possible. That would cause many issues with parsing that we don't want to deal with. Spaces and parens in particular would be nasty.

There has to be a special character dividing the device class prefix from the rest, so that they can be identified compared to fields that are not part of a device class. So there needs to be single character that is only allowed in that specific case, i.e. if there is one in a field name, the bit between the period and it has to map to a device class name. That way it's possible to work backwards from a field name unambigiously to a device class. And it can't just be another period because that would almost certainly break a lot of our code and user code that assumes a field name is a moniker and field name separated by a period. So it has to be a non-period character providing that division for that reason as well.

On the class name in the fields, that's going to end up creating some really long field names sometimes. They could get quite unwieldy. It could be done, but should be considered carefully.

Bringing over names from devices is always going to be a problem. They often don't enforce anything, which could cause lots of problems with field names they would end up creating. Any driver can do it, but they just have to be sure to enforce the rules, which means that some things will have to be changed on the fly to be compliant. We just couldn't afford to allow any old name format that a device might use. Definitely they need to remain a single, unambigious token, which means no spaces for sure.
Dean Roddey
Explorans limites defectum
BTW, when this is all worked out and moved into more formal form, most likely each reference to a semantic field type will be a link that will pop up a description of that type, in addition to just having a list of them all in one place for reference.
Dean Roddey
Explorans limites defectum
I went through the semantic field type thread and did some refinement and got all of my MUSTs, SHOULDs, and MAYs done correctly, to be consistent with the other documentation in this section.
Dean Roddey
Explorans limites defectum
I have just been looking at what I need to do to update my Meridian and JVC projector drivers. I have one problem with "Power" field This is specified as a Bool field. Yet I have "Power" as an String Enumerated type as

Off: Device Driver is not connected
Standbye: Device Driver is connected and device will respond to a start command.
Starting: Device has been issued with an On command, but is still booting and will not respond to any other commands.
On: Device is On and will respond normally to other commands
Cooling: Device has been issued with an Off command, but is cooling down so it is not yet safe to turn off the power.

Does this need a separate PowerState field?

Let me use the current JVC driver as am example. It has a PowerState field already with the following choices: Standby, On, CoolDown, Warning; My user interfaces only allow the states of "On" and "StandBy" to be passed into that field (and further restricts it so On will be sent only if the field is Standby, Standby only if the field is On).

All the Projector device class does is separate the setting of power with the write-only field of 'Power' and read-only fields of PowerState and PowerTransTime. Effectively you use the Power field to turn on/off the projector and the two other fields to display information to the user and to restrict writes to the Power field.

[Edit] I'd be happy to modify the JVC DLA-RSn driver if you'd like.
Mark Stega
The basic issue is that a power state field is always going to present options that are not settable. So it doesn't make sense to allow that power state field to be used as a writeable field. All that ultimately can be done (leaving aside standby) is power it on or power it off, which the Boolean field provides.

The power field could be readable, but the value would be somewhat limited. It would have to be true in warm up and cool down states, but neither of those should probably allow you to do a power off command, which would be possible if the power field was readable, because in a check box it would then allow the 'set it false' option.

Obviously your user logic could deal with that, but it's best to keep things simple as possible given these sort of messy scenarios that can't be avoided. It probably means separate On/Off buttons instead of a toggle.

Of course the Power field could be an enum and have the values Off, Indeterminate, and On or something like that. But there's no display widgets that could really make use of that very well, for outgoing commands I mean. Display widgets could, but display widgets can already make use of the PowerState field anyway.

Maybe it would be good to have a three way sort of button type or something, but there's not anything currently. It would be a check box but would disable itself when in the indeterminate state I guess.
Dean Roddey
Explorans limites defectum

Why not follow the scheme you have for Media Renderers where there is a write only MediaTransport field to tell the device what to do and a read only MediaState fieldso you can see how the device has responded.

So kept the Power field as Bool, but ReadWrite for simple situations. Then add a ReadOnly PowerState field as an enumerated string with values as I or Mark have suggested. The field should show the simple On and Standbye cases as a copy of the True / False state unless the driver has a more complex situation.

It is only a small addition, but at least it puts the onus on managing Power into the driver where it belongs rather than in ad-hoc event driven logic.


Wait till Dean agrees a specification for this, then it would be a good idea. Even though the Meridian driver is PDL and does not use the base classes, I will change the field names and re-map the enumerated types in strings to make it compatible.

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?
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  Device Classification Discussion, Part II Dean Roddey 6 7,002 08-03-2014, 08:38 AM
Last Post: Dean Roddey
  Semantic Field Types Dean Roddey 2 4,160 08-31-2013, 06:34 PM
Last Post: Dean Roddey

Forum Jump:

Users browsing this thread: 1 Guest(s)