Switch Groups changing to UNDEF

lopez1de commented 7 years ago

With OH2 GA (might also occur with other versions) I do face an issue with Group:Switch:OR going to "UNDEF" instead of ON or OFF.

I do own some motion sensors (Homematic HM-Sen-MDIR-O-2) and "itemized" them as follows:

Group:Switch:OR(ON,OFF) gMotion "Motion detected"
Switch M1 "Motion Sensor #1" <motion> (gMotion) { channel="homematic:..." }
Switch M2 "Motion Sensor #2 " <motion> (gMotion)  { channel="homematic:..." }

However, the group's state only is ON or OFF if both sensors have the same state. If their state's differ, the group reports itself as UNDEF.

On motion, the event.log prints

[GroupItemStateChangedEvent] - gMotion changed from OFF to UNDEF through M1
[ItemStateChangedEvent     ] - M1 changed from OFF to ON

later:

[ItemStateChangedEvent     ] - M1 changed from ON to OFF
[GroupItemStateChangedEvent] - gMotion changed from UNDEF to OFF through M1
Source of Issue (issue reported by m0wlheldChristoph Dahlen):
https://community.openhab.org/t/issue-with-group-switch-or-going-to-undef/21403

My findings: If all switches are OFF, the group is OFF If only one or several are ON, then the group is UNDEF If all are ON, the group is ON

################### I checked another group of 30 switches. All have changed from NULL to OFF after starting OH. The group then switches from NULL to OFF too, when the last item of the group switches to OFF. gStickyUnreach changed from NULL to OFF through Win_Kind1_StickyUnreach

So far so good.

But when I change one switch to ON, the group goes UNDEF for some reason.

2017-02-18 11:34:46.020 [ItemStateChangedEvent     ] - Heiz_WohnZ_StickyUnreach changed from OFF to ON
2017-02-18 11:34:46.023 [GroupItemStateChangedEvent] - gStickyUnreach changed from OFF to UNDEF through Heiz_WohnZ_StickyUnreach

kaikreuzer commented 7 years ago

Clearly sounds like a bug to me (some regression as this definitely worked before) - thanks for reporting.

lopez1de commented 7 years ago

More findings: A simple Group:Switch config without any binding works as intended. But at the point where I add a binding/thing to it, it shows up with the problem. The values we got from homematic binding are 0 or 1. This should represent the value of a switch like 0=OFF and 1=ON. But it looks like something went wrong here and OH isn't interpreting a 1 state as ON in groups. But at always, I may totally wrong.

kaikreuzer commented 7 years ago

Ah, that's important then - 0 and 1 are no valid states for Switch items, so I guess the items switch to UNDEF state and as an effect, the Group cannot determine its own state. So this is rather a bug in the Homematic binding then, which should be reported at https://github.com/openhab/openhab2

kaikreuzer commented 7 years ago

But somehow this does not really fit to the logs that you provided above, hm...

lopez1de commented 7 years ago

Homematic is binary (0/1). This transforms well to switches in OH. But not for the groups for some reason. I have to use contacts to get groups working, but it's strange to handle OPEN/CLOSED for switches etc.

kaikreuzer commented 7 years ago

This transforms well to switches

Only if this transformation is done by the binding. As I said, 0 and 1 are no valid values for Switch items, see https://www.eclipse.org/smarthome/documentation/concepts/items.html.

lopez1de commented 7 years ago

Then the only way for Homematic things is to use Contacts if I like to use groups?

EDIT: No, because that would be the same as you sayed before. 0 and 1 are not valid for Contacts.

I'm wondering if no other Homematic user is using Group. Or do I have to use Number item instead?

lopez1de commented 7 years ago

@kaikreuzer How would one know, of which type a value is? The binding should give me some informations about the type. But the binding documentation says nothing about types. You have to guess this. What would be the best approach to find the correct type.

EDIT: removed some incorrect statements. Group:Contact also not working for Contact's bound to homematic devices.

lopez1de commented 7 years ago

@kaikreuzer And again, besides from anything told before in the issue. Is the following statement true?

We have two Items of type Switch. If one Switch updates to ON and the other Switch to OFF which I can see clearly in the events.log. Then the Group:Switch:OR(ON,OFF) should be ON.

kaikreuzer commented 7 years ago

How would one know, of which type a value is? The binding should give me some informations about the type. But the binding documentation says nothing about types.

Yes, this info is unfortunately missing in the Homematic binding docs... You could use the REST API and request your "Thing" - this should give you a list of all channels, which each will have a property "itemType".

We have two Items of type Switch. If one Switch updates to ON and the other Switch to OFF which I can see clearly in the events.log. Then the Group:Switch:OR(ON,OFF) should be ON.

Yes, that should be the case.

MHerbst commented 7 years ago

Yes, this info is unfortunately missing in the Homematic binding docs... You could use the REST API and request your "Thing" - this should give you a list of all channels, which each will have a property "itemType".

@kaikreuzer What do you think of displaying the type in the channel list in Paper UI? This would help especially for bindings that create the channels dynamically and where it is nearly impossible to have an always up-to-date doc of the channels.

kaikreuzer commented 7 years ago

Why not. Any suggestion where and how to display it?

MHerbst commented 7 years ago

We could add the type to the third line of the channel description. Some ideas (Font and color of the text does not exaclty fit):

We could also write it in front of the description:

Or more prominent (either before or after the text);

lopez1de commented 7 years ago

I really like the last idea.

kaikreuzer commented 7 years ago

Actually, the last line seems to display the description, which in most cases does not bring any additional value here (and potentially blows up the list, if someone creates a multi-line description.

I wonder if we should make the list appear the same way as it is for items:

screen shot 2017-03-01 at 12 14 55

This would make the third line to simply show the type. To still make the description available, we could e.g. open a pop-up with it when doing a long-press on the label text of the channel. Wdyt?

MHerbst commented 7 years ago

@kaikreuzer Sounds good. I like the idea to have similar looking lists. A popup for descriptions would also allow to display larger texts (... if available)

kaikreuzer commented 7 years ago

@aounhaider1 Could you adapt the Thing-Channel list in the Paper UI accordingly?

lolodomo commented 7 years ago

Is the initial issue finally an issue with homematic binding only ? Are you using map transformation in your items ?

jpgnz commented 7 years ago

I'm seeing this exact same problem with the network binding, identical setup:

Group:Switch:OR(ON,OFF) gPresence (All)
Group:Switch:OR(ON,OFF) gPresencePing (gPresence)
Switch Phone1 "Phone1 [%s]" <present> (gPresencePing) { channel="network:device:ip_address_1:online" }
Switch Phone2 "Phone2 [%s]" <present> (gPresencePing) { channel="network:device:ip_address_2:online" }

Logs are the same:

18:45:42.841 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone2 changed from OFF to ON
18:45:42.842 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from OFF to UNDEF through gPresencePing
18:45:42.842 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from OFF to UNDEF through Phone2
18:45:42.992 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Phone2' received command OFF
18:45:42.992 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone2 changed from ON to OFF
18:45:42.992 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from UNDEF to OFF through Phone2
18:45:42.993 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from UNDEF to OFF through gPresencePing
18:45:47.593 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Phone2' received command ON
18:45:47.594 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone2 changed from OFF to ON
18:45:47.594 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from OFF to UNDEF through Phone2
18:45:47.594 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from OFF to UNDEF through gPresencePing
18:45:49.683 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Phone1' received command ON
18:45:49.684 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone1 changed from OFF to ON
18:45:49.686 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from UNDEF to ON through Phone1
18:45:49.686 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from UNDEF to ON through gPresencePing
18:45:53.052 [INFO ] [marthome.event.ItemStateChangedEvent] - GarageSensor1Luminance changed from 39 to 37
18:46:00.441 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone1 changed from ON to OFF
18:46:00.441 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from ON to UNDEF through Phone1
18:46:00.442 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from ON to UNDEF through gPresencePing
18:46:00.442 [INFO ] [smarthome.event.ItemCommandEvent    ] - Item 'Phone1' received command OFF
18:46:22.938 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone1 changed from OFF to ON
18:46:22.939 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from UNDEF to ON through Phone1
18:46:22.939 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from UNDEF to ON through gPresencePing
18:46:23.489 [INFO ] [marthome.event.ItemStateChangedEvent] - GarageSensor1Luminance changed from 37 to 35
18:46:52.944 [INFO ] [marthome.event.ItemStateChangedEvent] - GarageSensor1Luminance changed from 35 to 33
18:47:23.417 [INFO ] [marthome.event.ItemStateChangedEvent] - GarageSensor1Luminance changed from 33 to 31
18:47:32.865 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone1 changed from ON to OFF
18:47:32.865 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from ON to UNDEF through Phone1
18:47:32.866 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from ON to UNDEF through gPresencePing
18:47:52.899 [INFO ] [marthome.event.ItemStateChangedEvent] - GarageSensor1Luminance changed from 31 to 29
18:48:23.067 [INFO ] [marthome.event.ItemStateChangedEvent] - Phone1 changed from OFF to ON
18:48:23.068 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresencePing changed from UNDEF to ON through Phone1
18:48:23.068 [INFO ] [ome.event.GroupItemStateChangedEvent] - gPresence changed from UNDEF to ON through gPresencePing

If both devices are ON, group(s) are ON
If both devices are OFF, group(s) are OFF
If devices have different status', group(s) are UNDEF

Versions:

openhab> bundle:list -s | grep openhab
166 | Active   |  90 | 2.0.0                 | openHAB Core                                           | org.openhab.core
167 | Active   |  80 | 2.0.0                 | openHAB Karaf Integration                              | org.openhab.core.karaf
169 | Resolved |  80 | 2.0.0                 | openHAB Sound Support, Hosts: 111                      | org.openhab.io.sound
170 | Active   |  80 | 2.0.0                 | openHAB Dashboard UI                                   | org.openhab.ui.dashboard
176 | Active   |  80 | 2.0.0                 | openHAB 1.x Compatibility Layer                        | org.openhab.core.compat1x
200 | Active   |  80 | 2.0.0                 | openHAB REST Documentation                             | org.openhab.io.rest.docs
201 | Resolved |  80 | 2.0.0                 | openHAB Basic UI Fragment, Hosts: 197                  | org.openhab.ui.basicui
202 | Active   |  80 | 2.0.0                 | openHAB Classic UI Fragment                            | org.openhab.ui.classicui
203 | Active   |  80 | 2.0.0                 | HABmin User Interface                                  | org.openhab.ui.habmin
204 | Active   |  80 | 2.0.0                 | HABPanel User Interface                                | org.openhab.ui.habpanel
205 | Resolved |  80 | 2.0.0                 | openHAB Paper UI Theme Fragment, Hosts: 199            | org.openhab.ui.paperui
209 | Active   |  80 | 1.9.0.201701200211    | openHAB Piface Binding                                 | org.openhab.binding.piface
210 | Active   |  80 | 1.9.0                 | openHAB Mail Action                                    | org.openhab.action.mail
211 | Active   |  80 | 1.9.0                 | openHAB Twitter Action                                 | org.openhab.action.twitter
213 | Active   |  80 | 2.0.0                 | ZWave Binding                                          | org.openhab.binding.zwave
214 | Active   |  80 | 1.9.0                 | openHAB Serial Binding                                 | org.openhab.binding.serial
215 | Active   |  80 | 1.9.0                 | openHAB MQTT Binding                                   | org.openhab.binding.mqtt
216 | Active   |  80 | 1.9.0                 | openHAB MQTT Transport Bundle                          | org.openhab.io.transport.mqtt
217 | Active   |  80 | 1.9.0                 | openHAB RRD4j Persistence Bundle                       | org.openhab.persistence.rrd4j
218 | Active   |  80 | 1.9.0                 | openHAB InfluxDB Persistence bundle                    | org.openhab.persistence.influxdb
219 | Active   |  80 | 2.0.0                 | Network Binding                                        | org.openhab.binding.network

staehler commented 7 years ago

I've a problem which similar to this mentioned above. When a member of a group changes to UNDEF, the state of the group item changes to OFF: Group:Switch:OR(ON, OFF) gFenster "Offene Fenster [(%d)]" // ON: offen, OFF: geschlossenes Fenster

2017-04-19 23:09:13.937 [ItemStateChangedEvent ] - FensterGZ changed from ON to UNDEF 2017-04-19 23:09:13.938 [GroupItemStateChangedEvent] - gFenster changed from ON to OFF through FensterGZ

The group item should count the opened windows. But in case of an UNDEF window, which unfortunateley happens because of my onewire installation, the group item switches to OFF. This behaviour is in my opinion not correct. The group item should also be UNDEF, as long not all members are defined.

If you agree, I would appreciate a correction of this behaviour. Some rules work not correct because of this :-(

Thanks.

triller-telekom commented 7 years ago

I am trying to debug the UNDEF problem, but somehow I cannot reproduce it. What I tried is to narrow it down to the 2 phone example and define my items like this:

Group:Switch:OR(ON,OFF) gPresence (All)
Group:Switch:OR(ON,OFF) gPresencePing (gPresence)
Switch Phone1 "Phone1 [%s]" <present> (gPresencePing) { channel="network:device:ip_address_1:online" }
Switch Phone2 "Phone2 [%s]" <present> (gPresencePing) { channel="network:device:ip_address_2:online" }

First I verified it with the latest ESH and OH2 master branch where it works as expected. But when I downloaded the openhab2.zip and it worked too I got confused.

Could you please also download the openhab2 zip file and run the start-debug.sh/bat and then run the following commands on the console that will show up:

openhab> send Phone1 ON
Command has been sent successfully.
openhab> send Phone2 ON
Command has been sent successfully.
openhab> send Phone2 OFF
Command has been sent successfully.
openhab> send Phone1 OFF
Command has been sent successfully.

The output will be in the userdata/logs/events.log file. My output is that it is working as expected:

2017-04-21 11:46:29.067 [ItemCommandEvent          ] - Item 'Phone1' received command ON
2017-04-21 11:46:29.072 [ItemStateChangedEvent     ] - Phone1 changed from NULL to ON
2017-04-21 11:46:29.077 [GroupItemStateChangedEvent] - gPresence changed from NULL to ON through gPresencePing
2017-04-21 11:46:29.077 [GroupItemStateChangedEvent] - gPresencePing changed from NULL to ON through Phone1
2017-04-21 11:46:53.512 [ItemCommandEvent          ] - Item 'Phone2' received command ON
2017-04-21 11:46:53.515 [ItemStateChangedEvent     ] - Phone2 changed from NULL to ON
2017-04-21 11:47:10.931 [ItemCommandEvent          ] - Item 'Phone2' received command OFF
2017-04-21 11:47:10.934 [ItemStateChangedEvent     ] - Phone2 changed from ON to OFF
2017-04-21 11:47:21.673 [ItemCommandEvent          ] - Item 'Phone1' received command OFF
2017-04-21 11:47:21.676 [ItemStateChangedEvent     ] - Phone1 changed from ON to OFF
2017-04-21 11:47:21.676 [GroupItemStateChangedEvent] - gPresencePing changed from ON to OFF through Phone1
2017-04-21 11:47:21.676 [GroupItemStateChangedEvent] - gPresence changed from ON to OFF through gPresencePing

@jpgnz: If it works for you with sending the events from the console could you please run the test with your 2 real phones connected to your network with that blank openhab2 installation again and post the output?

theRealMCQwerty commented 7 years ago

@kaikreuzer I see this item has moved to 'In Progress' but it is unclear to me from reading the comments what the change will be. I got here because I have a group consisting of different item types that I use in a when clause of a rule using the changed trigger. I was hoping the group.state would reflect the last update meaning the state could change from 'ON' to '0' for example or any other value as a group member state changes. At the moment, my group state is always UNDEF which means the rule never triggers.

I would like to know what the change will be so that I can decide if I should wait for the change (preferred) or try to find a different approach. Thanks

kaikreuzer commented 7 years ago

@theRealMCQwerty I put it to "in progress", because @triller-telekom is looking into it. In case there is no bug, there of course won't be any change, so please discuss with him what there is to do.

triller-telekom commented 7 years ago

@theRealMCQwerty: Can you please post your group setup and the rule you want to trigger? You are saying that your group consists of different types, so what types are in there and what function is attached to the group? Where do you see that the group state changes to UNDEF, in the console output?

triller-telekom commented 7 years ago

With the PR mentioned above I implemented the behavior as described in the PR for the openHAB documentation: https://github.com/openhab/openhab-docs/pull/373

staehler commented 7 years ago

Just for clarification: is my issue (mentioned above https://github.com/eclipse/smarthome/issues/3051#issuecomment-295830195) fixed as well?

triller-telekom commented 7 years ago

@staehler: Indeed you are right that the behavior you experienced is a bug. My PR #3314 fixes this issue.

BUT: The behavior that is now implemented is the correct arithmetic OR. So If you have one group member with status ON and one with status UNDEF the group status will be ON! That is if you define your group like:

Group:Switch:OR(ON, OFF) gFenster

eclipse-archived / smarthome

Switch Groups changing to UNDEF #3051