Can't get "OR"-group item to work as expected

Hi,

I’m new to openhab2, but read the documentation extensively… Still I must have misunderstood how to properly group items in a group. So any help would be very much appreciated.

I’ve got a rather small KNX setup (that I got to work after many hours of trial & error and searching through the forums). But now I’ve stumbled on a basic issue using groups. Here are the relevant items:

Group:Switch:OR(ON,OFF)         Garden_Lights   "Luuchten"      <light>
Switch          LargeTerrace_Outlet     "Steckdous grouss Terrass"      <poweroutlet>   (Garden_Lights) { knx="1/1/9+1/7/1" }
Switch          Garden_Outlet           "Steckdous Gaart"               <poweroutlet>   (Garden_Lights) { knx="1/1/8+1/7/1" }
Switch          SmallTerrace_Outlet     "Steckdous kleng Terrass"       <poweroutlet>   { knx="1/1/7+1/7/1" }

and here’s the corresponding part of my sitemap:

Frame label="Gaart" {
    Switch item=Garden_Lights
    Switch item=LargeTerrace_Outlet
    Switch item=Garden_Outlet
    Switch item=SmallTerrace_Outlet
}

As you can see I have three power outlets in my garden, two of which are used to power some garden lights. What I intended to achieve using my above configuration is to have single switches for each outlet and additionally one switch that can be used to turn on the two outlets that are used for lighting. Based on the documentation I expected the state of the individual switches to be in sync with the group switch. In other words:

click to turn ON the group switch in Basic UI → both outlets are turned on, both individual switch items change state to ON, the corresponding UI switches reflect this ON state and, consequently, the group item turns ON also and, finally, the UI representation reflects the group’s ON state.

Conversely if at least one light is turned individually, the group switch should reflect this ON state due to the logical OR aggregator.

What actually happens is that the power outlets do turn on and off nicely using the individual switches, but the UI never changes the group’s state. Furthermore I can use the group switch to turn the lights on but in the UI the “ON” state doesn’t stick. It immediately reverts to OFF (but the actual lamps stay on). Since the UI group switch is off I can’t use it to turn off the light either.

Somehow the “OR” aggregator seems to be broken. Or I’m misusing it…

Any help or insight would be appreciated!

(I’m aware that having four UI switches for 3 outlets could be considered bad design/overkill, but for now it’s my test case for group items.)

  • Platform information:
    • Hardware: x86
    • OS: Ubuntu 16.04
    • Java Runtime Environment: oracle java 8 update 161
    • openHAB version: 2.2
  • If logs where generated please post these here using code fences:
    The log excerpt below is the result of me clicking around in the UI and using actual KNX wall switches (by Gira). At no point did the group switch correctly reflect the ON state.
2018-04-12 18:01:48.743 [thome.event.ExtensionEvent] - Extension 'binding-knx1' has been installed.
2018-04-12 18:32:51.043 [ome.event.ItemCommandEvent] - Item 'Garden_Lights' received command ON
2018-04-12 18:32:51.092 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:32:51.100 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:33:21.684 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:33:32.555 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command OFF
2018-04-12 18:33:52.208 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:33:52.447 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command OFF
2018-04-12 18:34:19.202 [ome.event.ItemCommandEvent] - Item 'Garden_Lights' received command ON
2018-04-12 18:34:19.211 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:34:19.217 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:36:11.144 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:36:13.017 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:36:27.843 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command ON
2018-04-12 18:36:32.791 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command OFF
2018-04-12 18:36:35.204 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command ON
2018-04-12 18:36:39.508 [vent.ItemStateChangedEvent] - LargeTerrace_Outlet changed from NULL to OFF
2018-04-12 18:36:39.518 [GroupItemStateChangedEvent] - Garden_Lights changed from ON to OFF through LargeTerrace_Outlet
2018-04-12 18:36:39.524 [vent.ItemStateChangedEvent] - Garden_Outlet changed from NULL to OFF
2018-04-12 18:36:39.529 [vent.ItemStateChangedEvent] - SmallTerrace_Outlet changed from NULL to OFF
2018-04-12 18:36:52.202 [ome.event.ItemCommandEvent] - Item 'LivingRoom_Outlet' received command ON
2018-04-12 18:36:52.215 [vent.ItemStateChangedEvent] - LivingRoom_Outlet changed from NULL to ON
2018-04-12 18:41:56.810 [ome.event.ItemCommandEvent] - Item 'Garden_Lights' received command ON
2018-04-12 18:41:56.819 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:41:56.823 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:41:59.097 [ome.event.ItemCommandEvent] - Item 'Garden_Lights' received command ON
2018-04-12 18:41:59.114 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:41:59.119 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:42:00.716 [ome.event.ItemCommandEvent] - Item 'Garden_Lights' received command ON
2018-04-12 18:42:00.728 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:42:00.732 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:43:11.915 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command ON
2018-04-12 18:43:19.264 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command OFF
2018-04-12 18:43:20.725 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command OFF
2018-04-12 18:43:21.780 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command OFF
2018-04-12 18:43:35.706 [ome.event.ItemCommandEvent] - Item 'LargeTerrace_Outlet' received command ON
2018-04-12 18:44:09.103 [ome.event.ItemCommandEvent] - Item 'Garden_Outlet' received command ON
2018-04-12 18:44:11.459 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command ON
2018-04-12 18:44:15.268 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command ON
2018-04-12 18:44:19.962 [ome.event.ItemCommandEvent] - Item 'SmallTerrace_Outlet' received command OFF

Did you already restart openHAB?

Your Items get all the same GA 1/7/1 (I guess this is a central knx switch). This is not the intended way to define items. For every switch actuator there are should be two GA, one to set the state, one to get the state. But central GA should not be mentioned within the item, and there is no need for this GA either:

Let’s think about a switch actuator:

Command ON/OFF: 1/1/1+1/7/1
Recall Scene: 1/2/1
Get state: 1/1/11 (actuator object has flags CRT set)

Switch mySwitch "Label" {knx="1/1/1+<1/1/11"}

So, if the Item is switched, openHAB will send the new state to 1/1/1. But if there is some command from knx, which will cause the actuator to change the state, the actuator will send its new state to 1/1/11 and openHAB will receive this state and set the item state accordingly, regardles, if the actuator was set through 1/1/1, a central GA 1/7/1, a scene 1/2/1 or even a builtin timer function.

As the R flag is set, the actuator will answer on read requests for GA 1/1/11, and openHAB will do a read request (this is the <) when starting up, so the state will be correct from start.

Ok, thanks for your input. Yes, I did restart openhab2 and I even reset the whole setup after I got it working to make sure there were no remnants of an old config. (apt purge; delete cache and tmp folders)

As for the KNX setup, it’s a house that we’ve bought and unfortunately we don’t have the ETS files. So I bought a TPUART module (http://shop.busware.de/product_info.php/products_id/599) and checked all the messages on the bus using knxd and knxtool. That’s how I figured out the physical addresses and group addresses of various devices.

In fact all of the lighting actuators on the ground floor are listening to their own respective GA and additionally to GA 1/7/1. This allows turning off all the lighting at once. (The message “00” i.e. “off” is sent via a physical Gira wall button.) I added this listening GA in order for openhab to be able to correctly keep track of the different states independently of how the light is switched: specific wall button addressing a single light’s GA, “all off” wall button addressing 1/7/1, openhab basic UI.

I didn’t observe any reply messages of the actuators when sniffing the KNX traffic via “knxtool vbusmonitor1”. AFAICT the whole setup is just physical wall buttons sending commands to a programmed GA and the subscribed actuators execute their programmed action. And that’s it. No “successful” or “new state” messages are sent. As for the indicator LEDs on the physical Gira buttons, I suppose their also listening on the right GAs so that a light that can be switched via multiple wall panels are always in sync.

Since posting my original post I figured out how to check device state using openhab’s console and to my surprise the state given for the lighting devices always stays at “NULL”. This would be consistent with commands being sent but no “new state” replies being returned. But the Basic UI still correctly shows the button state: lights on or off! Even when I switch a light on or off through the wall button.
Hmm, scratch that last sentence. It now no longer detects when I switch the lights through the physical buttons.

It’s slowly driving me insane :slight_smile:

As for the ‘<’ is it always safe to add it to my devices? I hesitated since I didn’t want to mess too much with my house infrastructure and send potentially unknown commands to various devices.

The < will only work for readable group addresses. ETS5 is able to read the configuration from most devices. There may be devices, which will need addons (such as HVAC switch combinations).

To be honest, knx without full access (i.e. knx project plus ETS) is very poor for home automation.

I’m aware that it’s quite suboptimal. (And I’ll contact the electrician who programmed the installation almost 10 years ago. Wish me luck.) But since it’s only a very minimal setup (lighting and shutters on the ground floor, some more shutters on the upper floors, nothing else) there’s not much to “automated” or “smart”. To be honest it’s a rather expensive way to switch a few lights. And for the nerd that I am a challenge to get some basic stuff working like controlling the lights via smartphone, etc.

Anyway I’m at a loss: a few hours ago I was happy that it worked so well, at least for the basics, including an immediate update in the Web UI when I pushed a physical wall button. That’s when I moved on to group items.

Do you have any idea what configuration setting could have such an effect?

Hmm, I’m being sidetracked by this more fundamental KNX issue that is not directly related to the group-item-problem. Fortunately I have openhab2 installed in a LXD container (sorry, forgot to mention this) and took a snapshot when the interaction with the wall-mounted buttons actually worked. I’ll first figure out what - if anything - changed between both versions, the working one from this afternoon and the later one where I copied my items, sitemap and knx configs to a fresh and clean openhab setup (but still based on the exact same container that I snapshotted earlier!).

Ironically I reinstalled openhab specifically to make sure I wasn’t spamming the forum with a broken setup due to built up cruft from earlier experiments.