Semantic Tags: Add missing POINT tags

[andrewfg]

This thread lists POINT tags that should potentially be added

See https://next.openhab.org/docs/developer/bindings/semantic-tags.html

[ccutrer]

Honestly, Control (with Switch subclass), SetPoint, Measurement, and Status cover just about everything for Point for me. I view different Point types as a way to distinguish between multiple of the same Property on an Equipment, based on their intended usage. My only possible suggestion is a "Desired", "Target", or "Call" Point, as in the following example of a thermostat:
*

• Thermostat (Thermostat)
  • Ambient temperature (Measurement, Temperature)
  • Set point (SetPoint, Temperature) - many thermostats have both a heating and a cooling set point for some sort of auto mode. Do we want to be able to distinguish between the two as a subclass of SetPoint?
  • Set Mode (Control, Mode) - i.e. is it supposed to be in heating, cooling, drying, auto, off, etc.
  • Current Mode (Status, Mode) - i.e. what it's currently doing - heating, cooling, drying, idle, off. In particular, this would never have "auto" mode, because auto isn't something it can actually do. And even when in heating set mode, it could be idle, or blower only, or something, because it's reached the set point. For multi-stage/multi-speed system, the speed of the compressor, or use of auxiliary heat, may or may not be exposed in the same point. I don't think it's particularly concerning which way it's modeled. For my main heat pump, it's a separate "aux heat" status. But interestingly, my primary zone (and only my primary zone) has a set mode called "EHeat", which you can use to force aux heat on, even if the heat pump itself is not working for some reason.
  • Thermostat Call (???) - I have no idea how to classify this. It's basically what the thermostat wants to do, given the set mode, but it may not be in that state yet. For example, a multi-zone unit might have one zone set to heat, and another set to cool. It cannot honor both at once. So one thermostat will be in heating set mode, heating current mode, and heating stage 1 call. The other thermostat would be in cooling set mode, idle current mode, and cooling stage 2 call. Another reason current and call can differ is if a compressor cannot cycle on for some period of time after it shut off for some reason. Another is if there's some sort of error lockout, preventing it from honoring the call. Right now I've modeled this as a new Point type called Desired, with a property of Mode. Not a lot of equipment exposes this level of detail to home automations systems, so I don't know how generally useful it is to even be able to define this. If others have suggestions of a better way to define this, or just think it should be labeled as a Status Point, or think it's too complicated, by all means, let's ignore this.

[rkoshak]

Right now I've modeled this as a new Point type called Desired, with a property of Mode.

I can't think of anything better. The concept of "Desired" makes sense as a Point.

• Alarm: this is an important one we should keep

• Control: makes sense

• LowBattery: I never liked the name of this tag. What if the battery is full? I'd name it something like "BatteryStatus" and make it a subtag to Status. And the only reason this is around at all I think is to distinguish the properties for embedded batteries (as opposed to equipment that are batteries themselves like an UPS). But maybe the proper way to handle that is to use subequipment in which case this tag could be eliminated.

• Measurement: important, maybe have "Observation" as a synonym to broaden it's meaning?

• OpenLevel/OpenState: Probably should be combined

• Prediction: Weather forecasts, energy prices, etc. Maybe we call it "forecast" instead if that makes more sense

• Point: parent tag for all Points

• Setpoint: imporant

• Status: important

• Switch: subclass of Control, I wonder if having it as a separate tag like this makes it confusing though

• Tampered: I would expect this to be a Property, e.g. Alarm/Tampered

• Tilt: Same, I would expect this to be a Property, e.g. Control/Tilt

[andrewfg]

IMHO Desired is a synonym for Setpoint. In a thermostat you have two temperature channels for Measurement:Temperature and Setpoint:Temperature. (In German "IstWert" and "SollWert").

[ccutrer]

IMHO Desired is a synonym for Setpoint. In a thermostat you have two temperature channels for Measurement:Temperature and Setpoint:Temperature. (In German "IstWert" and "SollWert").

I don't think it's a great word for it. But if we add Prediction or Forecast, I think that fills my use case perfectly of "this is what the thermostat says the mode should be", and then we don't need Desired.

[andrewfg]

@rkoshak in general I agree with your comments above; but I do not agree to the following

• LowBattery => this is not a POINT .. it should Point:Alarm Property:LowBattery

• OpenLevel/OpenState => ditto Point:State Property:Level resp. Property:Position resp. Property:OpenClosed

• Setpoint => see above.

• Switch: subclass of Control => the former is a two state digital control which is indeed a specific sub-class the more general (continuous / analog) Control

• Tampered: I would expect this to be a Property, e.g. Alarm/Tampered => no. it should be Point:Tampered Property:OnOff

@ccutrer

• Point type called Desired, with a property of Mode => Point:Setpoint Property:Mode (analog to Point:Setpoint Property:Temperature)

[andrewfg]

I don't think it's a great word for it.

Setpoint is the correct technical word that is universally understood among all control experts worldwide.

[ccutrer]

I don't think it's a great word for it.

Setpoint is the correct technical word that is universally understood among all control experts worldwide.

Allow me to clarify. I don't think "Desired" is a great word for the concept I was trying to express (Thermostat "Call"). Setpoint is definitely the correct word for its concept. And "Prediction" or "Forecast" are satisfactory words for the concept I was trying to express.

[rkoshak]

LowBattery => this is not a POINT .. it should Point:Alarm Property:LowBattery

As currently named I agree. But we are still left with the problem of how do we model embedded batteries.

For example, I have a whole house power meter which has it's own battery. It doesn't feel right to use the same tags for the the power being used in the house and for the status of the battery that powers the device (when there is a power outage). I don't really care if we keep "LowBattery" or rename it or get rid of it. But I think we need to have some idea for how this should properly be modeled before just getting rid of it.

Tampered: I would expect this to be a Property, e.g. Alarm/Tampered => no. it should be Point:Tampered Property:OnOff

That makes no sense to me. Per the rules:

New POINT tags MUST be what you (the binding) does to, or how you (the binding) gets, the state of the Item.

OH isn't "tampering" the device. It's reporting whether it was tampered. "Tampered" is what's being sensed, measured, reported, alarmed, etc. It's a Property. It's the "what", not the "how".

[ccutrer]

For example, I have a whole house power meter which has it's own battery. It doesn't feel right to use the same tags for the the power being used in the house and for the status of the battery that powers the device (when there is a power outage). I don't really care if we keep "LowBattery" or rename it or get rid of it. But I think we need to have some idea for how this should properly be modeled before just getting rid of it.

Yes, I model this as a sub-equipment. For my electronic deadbolt, I have it modeled like so:

Group eDiningDeckDoorLock "Dining Room Deck Door Lock" (lDining) [ "Lock" ]
Switch DiningDeckDoor_Lock "Dining Room Deck Door Lock" <if:mdi:door-closed-lock> (eDiningDeckDoorLock) [ "Control" ] 
Group eDiningDeckDoorLockBattery (eDiningDeckDoorLock) [ "Battery" ]
Number:Dimensionless DiningDeckDoor_Battery "Dining Room Deck Door Lock Battery Level [%d %%]" <if:mdi:battery-50> (eDiningDeckDoorLockBattery) [ "Measurement", "Level" ]

I model my battery powered leak sensors the same way. If the item only exposed a "low battery warning", and not a measurement of the battery level, I'd likely model the point as Alarm, Level instead.

OH isn't "tampering" the device. It's reporting whether it was tampered. "Tampered" is what's being sensed, measured, reported, alarmed, etc. It's a Property. It's the "what", not the "how".

Agreed. This is how my proper (old school DSC) alarm system models a window contact, that has various states it can report:

Status is the normal open/closed state for the window. Tamper is "the wire has been cut", and Fault is "there is a short in the wire". I really don't know what "in alarm" and "tripped" mean. My guess is the former is "the zone is open, while the alarm system is armed", and the latter just being a the Switch form of zone status. Anyhow, my point is that if "Tamper" is a Point, then "Fault" is a point as well. But I view them both as different Alarm statuses on the device.

[andrewfg]

@ccutrer / @rkoshak

OK you changed my mind re Tamper

Apropos LowBattery it should be moved from being a Point to being a Property .. as Point.Alarm Proprerty.LowBattery