Closed lopez1de closed 7 years ago
Clearly sounds like a bug to me (some regression as this definitely worked before) - thanks for reporting.
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.
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
But somehow this does not really fit to the logs that you provided above, hm...
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.
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.
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?
@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.
@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.
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.
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.
Why not. Any suggestion where and how to display it?
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);
I really like the last idea.
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:
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?
@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)
@aounhaider1 Could you adapt the Thing-Channel list in the Paper UI accordingly?
Is the initial issue finally an issue with homematic binding only ? Are you using map transformation in your items ?
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
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
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)]"
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.
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?
@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
@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.
@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?
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
Just for clarification: is my issue (mentioned above https://github.com/eclipse/smarthome/issues/3051#issuecomment-295830195) fixed as well?
@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
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:
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
later:
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.