Inverted Switches when item is in two groups

I have some Greenwave Wallsocket that work fine with openHAB 1.83 as long as they are only members of one group. But as soon as I started to implement a second dimension by grouping the items not olly by rooms, but also by devicetype I faced a courious Situation: Trying to switch a device off in the GUI in the “Devicetype-Group” that was turned on in the “Room-Group” gives me a inverted switch in “Device-Group”. If I go back to the “Room-Group” and turn the device off there, I have a normal behaviour of the switch in the “Device-Group”

Example:

Switch EG_Esszimmer_Stern "Stern" (EG_Esszimmer, EG_Licht) { zwave="3:command=switch_binary" }

Switched on in Group “EG_Esszimmer” and turned off in Group “EG_Licht” shows an inverted behaviour in “EG_Licht” as long as the Switch is not turned off in Group “EG_Esszimmer” first.

As I would like to work with different groups to adress different needs on several “Terminals” (RASPI 3 with Toughscreen) in different rooms I need to be sure that the switches work in the correct way.

Any ideas?

Please post your Group definitions and sitemap lines for how you are controlling these groups.

Here you go:

From my items-file:

Group All
Group gEG               (All)

Group EG_Licht          "Licht EG"              <light>         (gEG)
Group EG_Esszimmer      "Esszimmer"             <television>    (gEG)
Group EG_Wohnzimmer     "Wohnzimmer"            <sofa>          (gEG)
Group EG_Kaminzimmer    "Kaminzimmer"           <sofa>          (gEG)

Switch EG_Esszimmer_Stern               "Stern"                                 (EG_Esszimmer, EG_Licht)                { zwave="3:command=switch_binary" }
Switch EG_Esszimmer_Schlauch            "Schlauch"                              (EG_Esszimmer, EG_Licht)                { zwave="12:command=switch_binary" }

Switch EG_Wohnzimmer_Wuerfel            "Würfel"                                (EG_Wohnzimmer, EG_Licht)               { zwave="9:command=switch_binary" }

Switch EG_Kaminzimmer_Deckenfluter      "Deckenfluter"                          (EG_Kaminzimmer, EG_Licht)      { zwave="4:command=switch_binary" }
Switch EG_Kaminzimmer_Licht_Regal_Kamin "Licht Regal Kamin"                     (EG_Kaminzimmer, EG_Licht)      { zwave="10:command=switch_binary" }
Switch EG_Kaminzummer_Licht_Regal_Bar   "Licht Regal Bar"                       (EG_Kaminzimmer, EG_Licht)      { zwave="13:command=switch_binary" }

My sitemap:

sitemap mw19 label="Haussteuerung"
{
        Frame {
                Group item=gS label="Souterrain" icon="cellar"
                Group item=gEG label="Erdgeschoss" icon="groundfloor"
                Group item=gOG label="Obergeschoss" icon="firstfloor"
                Group item=gDG label="Dachgeschoss" icon="attic"
                Group item=gG label="Garten" icon="garden"
                Group item=gLicht_zentral label="Licht" icon="light" {
                        Switch item=LichtEGaus label="Licht EG" icon="light" mappings=["OFF"="aus"] }
                }

}

Following an other thread I know that there are obviously different opinions concerning the definition of groups in the sitemap (I will move this definition back to the items file later), but the gLicht_zentral group is not affected here, as it contains just the “Main-Power-OFF” and no single on/off-switches. The problem with the inverted switches occurs between the “Room-Groups”, eg. EG_Esszimmer and the EG_Licht-Group.

Any ideas?

Try defining your Groups to explicitly define how the states are aggregated.

Group:Switch:OR(ON, OFF) EG_Licht ...
Group:Switch:OR(ON, OFF) EG_Esszimmer ...
...

The OR(ON, OFF) means the Group’s state will be ON if any one of its members are ON. If you only want the Group to be ON if all the members are ON use AND(ON, OFF).

I will try this as a nice feature, but I do not think, that this has something to do with the inverted switches in the groups. Was this menat to be an addition to my thread with the not displayed group, when using an “-on” Icon?

As I do not switch groups, but just individual switches in the groups, I cannot see, that there could be any conjunction between the icon for the group and the behaviour of the switches in the groups. Here I use groups really just to group elements in the GUI.

There seems to be some sort of “priority” of the switch in the group I used first over the switch I use afterwards, so that this is inverted, as long as the switch used first is not used again first.

To be clear about your problem ; the same switch is displayed in different places in your sitemap (via groups) - but when poked in one place, the other display place does not update properly?
Does the Greenwave Wallsocket device respond as you expect?

I think Rik’s suggestion about Group aggregation is relevant, because you want a top-level group to get updated by a middle-level group which gets updated by a switch member. The aggregation will make the middle group update, to trigger the top level

Yes, I do have the same switches in different groups, One dimension of groups is “Groups by Room”, the other dimension is “Devices by Function”. E.g. the switch for a light in the livingroom is displayed in the group “livingroom” and in the group “light”. But there is no hierarchy between these groups. Both exist parallel.

The reason is more comfort using the GUI. If I am in the livingroom and do different things there I use the group livingroom and have all devices in that room on Display (including the light-Switch). Going to bed I would like to switch off different lights in different rooms. So I use the group light (including the switch for the light in the livingroom), where I have all the lights on one display. Another reason is, that I want to install panels in different rooms, that should (by default) Display the group for that room, but should also allow to navigate to the “Device by Function”-groups.

The actual behaviour is, that I do not only face the situation, that the switch in the other group is not updated in the GUI (I could live with that, because this would simply mean to have to switch twice to get it syncronized and to get back to a trustworthy situation), but that the switch in the other group works inverted, and never gets synchronized until I switch back the switch in the group used first.

Example: I go to the group livingroom. The switch for the light is off, and displays as off in the GUI. I switch the light on, the switch is really on, and the GUI displays it as on in the group livingroom.

Later I navigate to the group light to switch off several lights. The switch is displayed off in the GUI, although it is really on (so far no problem, see above). But switching to on in the GUI results in switching the light off and vice versa. So I never get the switch and the GUI synchronized (until switching back in the group used first).

Switching a light from an other room, where I am unable to see it, is impossible this way, when I do not know who used which switch in which group in the meantime. The whole system is not trustworthy.

The more I think about it, the more I see the reason for the problem. Obviously the switch item is just toggling the state, everytime it is used and does not send concrete on- and off-commands. But the funny thing is, that when I am using my tablet or mobile and the panel the behaviour is the other way round. I have the switch in the GUI displayed wrong, but switching it, results in “nothing”, So GUI and switch are in sync the next time i switch. For a remote use this would be sufficient (simply switch on and off, and the GUI is in sync again and trustworthy).

Should I implement rules for every switch to send concrete on- and off-commands?

First try the group aggregation, Group:Switch:OR(ON, OFF) is sensible for lights. I think this may encourage groups to refresh display.

Which GUI are you talking, OH1 with Classic UI ? Which browser? There are display refresh issues.

Perfect, now it works. But as I understand, this Group:Switch:OR(ON, OFF) is something specific for switches. Would this interfere with other devices in the group? Up to now I have just the greenwave-switches in these rooms, but what if I add anything else?

That is actually a really good question. I think the answer is “it depends”. I’m pretty sure you would want to avoid sending a command to such a Group but I’m not sure what will happen with the aggregation function. It might ignore the updates from Items that are not Switches (which will likely put you back in the same boat with UI elements becoming out of sync) or it may fill your log with errors and fail to aggregate the state at all. I’d love to hear the result if someone performs this experiment.

I’ve never tried to mix types of Items in a Group as I’ve long since abandoned using Groups to define my sitemap. I’m sure you will come to this same conclusion too eventually.

The problem is you have no control over the way Items are displayed in the Group. You can’t insert a chart in the sub panel, you can’t use visibility, you can’t use dynamic colors, you can’t control the order the Items appear, and you can’t change which control types are displayed (e.g. if you have a Switch that you just want to show the status of on your sitemap you would want to use a Text on the sitemap for that Switch but when using Groups you will get the Switch and the toggle allowing users to change the state of of what should be “read only” Items).

Groups are great for building a quick and dirty look at the state of your Items and vital to write generic rules but when you really try to build an attractive and functional user interface I am certain you will find that using Groups is the wrong answer.

To get the same functionality (i.e. subpanels) you can use:

Text item=MyItem {
    Frame label="Label"{
        // put each Item here separately
    }
}

That sounds interesting and persuading, and I will try to change my sitemap in this way.

What I am really missing is some sort of “concepts” or “best practices” on how to implement openHAB. There are demo-files and description of files and keywords, and a lot of individual solutions someone found for a special situation, but there is no “guideline”, to check these solutions against, to be able to judge, wether something is a “good” solution or not, or how to find the best solution.

Unfortunately the world of home automation and OH is such that there really are not a lot of best practices that are universally applicable. However there have been a number of posting about that talk about some ideas.

@ThomDietrich, at the risk of proliferating the FAQ into War and Peace, would a “best practices” section make sense? Or do you think a separate thread/wiki posting/or the like make more sense?

Some quick ones off the top of my head:

  • Groups on the sitemap are not flexible enough to use long term

  • Come up with a meaningful naming scheme and stick to it

  • Split your config into multiple files, I recommend splitting them based on function (e.g. lighting, hvac, alarm, etc).

  • Use persistence with restoreOnStartup on just about everything. MapDB is great for this.

  • Try to shoot for not needing a UI at all for your automation. The house should just do it. If you do need manual control, make sure that control is as easy to use or easier than the non-automated control.

  • Look at and apply the Design Patterns (search the forum for Design Pattern).

  • Ask lots of questions on the forum. When asking for help post a description of your problem, your logs, your relevant Items, your relevant Rules, and what you have tried so far. And most importantly, tell us your ultimate goal not just how to do what you think you need to do to solve the problem. Often there can be another way.

That sounds great, and would make startup a lot easier and the "first things done "much more sustainable. Besides a new FAQ-Section I think it would be a great idea to implement some well commented best practices in demo files for the openHABian image and give that thing a “prominent” place in the project. So people interested in openHAB would see, that there is a hazzle free way to start (not only by having a out-of-the-box OS-Image with the software needed, but also with a guide how to implement the own needs the right way).

E.G. before I started I read a lot of things about openHAB, but did not see the openHABian project. So I did many things following a lot of isolated stuff I found on the Internet, and now see that I have to redo some things, because I was unlucky just to find one, but not the best solution.

1 Like

Hey @rlkoshak these are some great points and I guess we could add a lot more. I would love to present these somewhere. Would you agree, that they would better fit into a tutorial like article? Best Practices doesn’t sound like “Frequently asked questions”. I would suggest to write an article covering all kinds of rule related best practices. I would suggest a wiki article just like the FAQ article, with link-able headlines just as the FAQ article. Finally I think every best practice should be shown in a bad example + good example comparison to illustrate the result.

@rlkoshak @jlemmer What do you think? If you agree Rich could create the article right away and we and others can start adding stuff.

Really good ideas!

And very important for me would be a “promiment” position of that stuff, so that people “see it” instead of heaving to search for it. As in many open source projects there is a lot of knowledge available, but for a beginner is is often sort of “too much” and to many details and to little “let me take you by the hand” after a first and short “download package X and copy it to location Y” Especially projects like openHAB with so many features and posibilities need a bit more “Guidance” in the beginning, so that people get a positive first experience.

As I myself are a beginner, I will not be able to support in a way of bringing in own knowledge, but as beeing quite experienced as a corrector/editor I would like to support in reading from a beginners point of view so that the texts are understandable for beginners.

Hey @jlemmer Would you have a look at these ideas and let me know if that would resolve your concerns!?

Well then you could actually help right away to improve the documentation for the version 2.0 release this weekend:

Hi Tom,

I tried to improve the NAS-Installation a little bit:

QNAP-Tutorial
How to install
0. Check if your NAS has the most actual firmware-version. If a new version is announced when opening the admin GUI follow the instructions by first restarting your NAS and then installing the new version.

  1. Download the QPKG from the releases section here on GitHub to your PC and remember the place you saved it.
  2. --* Is this point really still necessary? I simply manually installed the QPKG and it worked fine, Should other methods be supported with the final version?
  3. Check if you already have an installed App called JRE (for x86-CPU based NAS) or “JRE_ARM” (for ARM-CPU based NAS) under “My Apps”. If not, go to the “Developer-Tools” section of the App Center, install the appropriate version (you will not see the wrong Version for your NAS there) and wait for a while until the Java installation has finished.
  4. Open the “Install manually” dialog in the App Center by clicking the gear-wheel on the upper-right corner of the App Center and choose the qpkg from the place you have downloaded it to.
  5. Confirm the installation
  6. Wait while the package is being installed
  7. When finished just close the dialog and wait for a while until openHAB has completly started. This may last several minutes.
  8. Access openHAB from your favorite browser via http://<NAS_IP_or_DNS-Name>:8090. If the interface does not start, retry after another minute. The initial startup takes some time.

How to uninstall
0. If you want to keep configuration files, copy them to a save place outside of the openhab-path.

  1. Go to the “App Center” and remove the app like any other. REMEMBER: All files get removed directly!

With the other linked subjects I am not sure what I could do there exactly.

Hey Jörg!
Thanks, that’s great! I’ve added your improvements here to be reviewed by others, should be merged later today. https://github.com/openhab/openhab-docs/pull/228/commits/7f372271837b994d58721986fdfee39f1c702fac

Regarding the other tickets: Many are just Writing tasks. You’ll have to look at the given details, read a few community forum posts and compose a paragraph on that matter. The iPhone, the Icons or the Binding names tickets look like good candidates to me :wink:

OK, I will take a look tomorrow.

BTW: At the end of the installation manual for Qnap there should be a link to the general manual (first start), so that people are taken directly to the next step.

Where to exactly? To the Tutorials section? You really think we need to point them there?