Group aggregation OR(ON,OFF) has state NULL

shutterfreak · January 29, 2020, 4:26pm

Running openHAB2.5 on openHABian buster (RPi3B+).

I want to use Group:Switch:OR(ON,OFF) group aggregation to check whether a fire alarm has any alarm set (e.g., heat alarm, smoke alarm, tamper alarm, system alarm, low battery level).

According to the Group item documentation, the state of the group defined this way can only be one of:

ON if at least 1 of the group items has state ON
OFF in all other situations

However, my sitemap tells me otherwise. The textual representation of the aggregation group state is ‘-’ (which happens to be NULL) which is unexpected.

Is this a bug or an undocumented behaviour?

Here’s one fire alarm (Fibaro Smoke Alarm 3) item definition:

// Group item containing all items relating to the fire alarm at AT_Attic:
Group AT_Attic_SmokeAlarm (gSmokeAlarms)
// The following line is the group aggregation that should only be ON or OFF:
Group:Switch:OR(ON,OFF) AT_Attic_SmokeAlarm_Alarm "Attic Hall Smoke Alarm [%s]" <alarm>
// The individual items linked to this fire alarm sensor are defined below:
Number:Temperature AT_Attic_SmokeAlarm_Temperature "Attic Temperature [%.1f %unit%]" <temperature> (AT_Attic_SmokeAlarm, gHome_AT_Attic, gPersist_everyChange) {
    channel="zwave:device:controller:node13:sensor_temperature"
}
Switch             AT_Attic_SmokeAlarm_Alarm_Heat    "Heat alarm"       <my_alarm> (AT_Attic_SmokeAlarm, AT_Attic_SmokeAlarm_Alarm, gHome_AT_Attic, gPersist_everyChange) {
    channel="zwave:device:controller:node13:alarm_heat"
}
Switch             AT_Attic_SmokeAlarm_Alarm_Smoke   "Smoke alarm"      <my_alarm> (AT_Attic_SmokeAlarm, AT_Attic_SmokeAlarm_Alarm, gHome_AT_Attic, gPersist_everyChange) {
    channel="zwave:device:controller:node13:alarm_smoke"
}
Switch             AT_Attic_SmokeAlarm_Alarm_System   "Hardware failure alarm"      <my_alarm> (AT_Attic_SmokeAlarm, AT_Attic_SmokeAlarm_Alarm, gHome_AT_Attic, gPersist_everyChange) {
    channel="zwave:device:controller:node13:alarm_system"
}
Switch             AT_Attic_SmokeAlarm_Alarm_Tamper   "Tamper alarm"      <my_alarm> (AT_Attic_SmokeAlarm, AT_Attic_SmokeAlarm_Alarm, gHome_AT_Attic, gPersist_everyChange) {
    channel="zwave:device:controller:node13:alarm_tamper"
}
Switch             AT_Attic_SmokeAlarm_Alarm_Battery   "Battery Low"      <lowbattery> (AT_Attic_SmokeAlarm, AT_Attic_SmokeAlarm_Alarm, gHome_AT_Attic, gPersist_everyChange, gBatteryLow) {
    channel="zwave:device:controller:node13:alarm_battery"
}
Number              AT_Attic_SmokeAlarm_Battery          "Attic Smoke Alarm: Battery Level [%.1f %%]" <battery>     (AT_Attic_SmokeAlarm, gHome_AT_Attic, gPersist_everyChange, gBattery, gBatteryLevel, gBatteryType_CR123A) {
    channel="zwave:device:controller:node13:battery-level"
}

On my sitemap I define:

	Frame label="Fire Alarms" icon="alarm" {
		Text item=AT_Attic_SmokeAlarm_Alarm icon="my_alarm"
		Default item=AT_Attic_SmokeAlarm_Alarm icon="my_alarm" labelcolor=[
			"ON"="red", "OFF"="green", "NULL"="orange", "UNDEF"="#777"
		]
	}

I have the following custom dynamic icons stored in $OPENHAB_CONF/icons/classic:

openhabian@openhab:/etc/openhab2/icons/classic$ ls -l my_alarm*
-rw-rw-r-- 1 openhabian openhabian 8510 Jan 29 16:56 my_alarm-null.png
-rw-rw-r-- 1 openhabian openhabian 3239 Jan 29 17:00 my_alarm-null.svg
-rw-rw-r-- 1 openhab    openhab    5094 Mar 11  2016 my_alarm-off.png
-rw-rw-r-- 1 openhab    openhab     261 Mar  7  2016 my_alarm-off.svg
-rw-rw-r-- 1 openhab    openhab    3256 Mar 10  2016 my_alarm-on.png
-rw-rw-r-- 1 openhab    openhab     691 Mar  7  2016 my_alarm-on.svg
-rw-rw-r-- 1 openhab    openhab    1502 Jan 29 15:55 my_alarm.png
-rw-rw-r-- 1 openhab    openhab    1299 Jan 29 15:36 my_alarm.svg
-rw-rw-r-- 1 openhab    openhab    8957 Jan 29 16:58 my_alarm-undef.png
-rw-rw-r-- 1 openhab    openhab    3239 Jan 29 16:58 my_alarm-undef.svg

Here’s a screenshot of the reported states:

And here are the custom dynamic icons:

Icon	State	File name (dynamic icon)
	(default / fall-back)	my_alarm
	`ON`	my_alarm-on (Source: Wikimedia)
	`OFF`	my_alarm-off (Source: Wikimedia)
	`NULL`	my_alarm-null (Source: Wikimedia)
	`UNDEF`	my_alarm_undef (Source: Wikimedia - changed color in Inkscape)

rossko57 · January 29, 2020, 4:38pm

No bug.
All Items, including Groups, begin life at boot time with a state NULL.
That’s the way it stays until something happens.

In the case of a group, one of the members needs to change to trigger the group aggregation function to calculate.

There is also state UNDEF which I think can be imposed on a group with a nonsense type/members/function combination.

As you hopefully don’t expect fire alarms to trigger very often, and battery zwave devices might not even report OFF daily, you can narrow down your interest in group state to be “ON or not-ON”.
Rules, icons, texts etc. can all be set up to work in that way.

shutterfreak · January 30, 2020, 8:09am

So you would rather use the following group aggregator then?

Group:Switch:OR(ON,NULL) AT_Attic_SmokeAlarm_Alarm "Attic Hall Smoke Alarm [%s]" <alarm>

Note: probably I shoud use Contact items rather than Switch items, as in:

Group:Contact:OR(OPEN,NULL) AT_Attic_SmokeAlarm_Alarm "Attic Hall Smoke Alarm [%s]" <alarm>

rossko57 · January 30, 2020, 11:15am

It’s your decision,do what you like. But no, I wouldn’t use that rather odd aggregation. I’d leave it as it was.

Example, I’d have custom icons
my_alarm = green tick. Nothing’s ON, all is good
my_alarm-on = red warning. Eek, a fire
and maybe
my_alarm-undef= question mark. Because I wasn’t expecting that and it’s probably me that messed up.

Technically this kind of thing is best represented as a Contact i.e. “sensor only”. But many bindings struggle with the type, it’s not always practical.

shutterfreak · January 31, 2020, 3:41pm

I see.

However I find it strange that some bindings have difficulties with Contact items. Maybe because their states are of type OpenClosedType instead of OnOffType?

Since the smoke sensors I’m using are Fibaro FGSD-002 Z-Wave devices (firmware version 3.3), I’d like to know if @chris can tell whether it is okay to define the alarm items as Contact instead of Switch.

chris · January 31, 2020, 3:44pm

The device supports the following items -:

The alarm is defined as a Switch so you need to use this.

shutterfreak · January 31, 2020, 3:49pm

Okay. I’ll define them as Switch then.

I wonder whether in the future these should be defined as Contact as the values are read-only.

Probably I should be using proxy items in this case.

rossko57 · January 31, 2020, 3:53pm

Don’t forget breaking things for existing users without really good cause is frowned upon.
The weight of history is against you.

Having said that, it is technically possible for bindings to offer channels for the same data in more than one type.
Or we could imagine a channel profile that allowed type conversions.

chris · February 1, 2020, 10:25am

For info, I’ve opened an enhancement to introduce a base BooleanType to all of these types. This should (I think ) allow bindings to provide channel data in a more abstract type and allow users a bit more flexibility to choose the item type.