Habpanel not updating group switch state

[andyh (Andy Howell)]

I have a simple panel with two light switches that are also controlled by a group switch. The group switch state in the habpanel is not updating when I press it. These are in my kitchen, so I’ll call them K1, K2, and KG for the first, second and group switch. I tried debugging this in the browser, but quickly got lost when it got into vendor.js. The console message were useful though.

Case 1: Test K1 ON and OFF
Press the K1 switch: send K1 ON, update K1 state to ON, update KG state to ON
Press the K1 switch: send K1 OFF, update K1 state to OFF, update KG state to ON

Case 1 works as expected.

Case 2: Test K1 ON, then KG OFF
Press the K1 switch: send K1 ON, update K1 state to ON, update KG state to ON
Press the KG switch: send KG OFF, update K1 state to OFF

At this point, the K1 switch indicates OFF, but the KG switch incorrectly indicates ON. The actual light switches off as expected. The KG switch can not turn the lights on at this point, since its state is ON, when pressed it sends OFF.

Case 3: Turn on both lights with KG, then turn off K1 and K2
Press the KG switch: send KG ON, update K1 state to ON, update K2 state to ON
Press the K1 switch: send K1 OFF, update K1 state to OFF
Press the K2 switch: send K2 OFF, update K2 state to OFF

At this point KG is still ON.

In both case 2 and 3, KG’s state is not being updated, If I reload the panel, it sets the state correctly.

My items are defined as follows:

Switch   kitchen_outer_lightsPower          "Outer kitchen light"                               (gFF,LightsPwr,kitchen) {channel="mqtt:topic:mosquitt
o:kitchen_outer_lights:power"}
Switch   kitchen_inner_lightsPower          "Inner kitchen lights"                              (gFF,LightsPwr,kitchen) {channel="mqtt:topic:mosquitt
o:kitchen_inner_lights:power"}
Group:Switch:OR(ON,OFF) kitchen    "Active lights [%d]"

I’m running OpenHab 2.5M5 on raspberry pi.

I can try debugging more, but I’ll need help. I OK with C++, python etc, but my web skills (javaScript, Java, Angular) are quite limited. Happy to learn more through!

Thanks,

Andy

[rossko57]

I’m not a HABpaneluser, but can comment; there’s no real difference in how the state changes of a Group type Item get flagged to the UI, compared to any other Item type.

There is however a difference in how the Group state gets changed. It’s derived from member states, and this is an iterative process. It’s noticeable in rules that you can get many Group Item updates for a single member update.
I suspect that might be the root cause here - is there a flurry (well, two in this case) of Group state updates - but maybe only one is flagged to HABpanel, or maybe two are sent but not in the “right” order, or maybe HABpanel discards one if another is already being processed.
No answer, just clues to look for!

[andyh (Andy Howell)]

@rossko57 Thanks. I have two groups, one for the two kitchen lights, and one for all lights. From what I can see from the habpanel console in the browser and from watching the events in wireshark. it looks like the kitchen group switch is not getting updated with its new state. I see the same behavior when I hit the ‘all lights’ group.

It looks like the issue is that the back end is not sending group state change messages for the group switch that was hit. It does send it out for other groups containing the same item.

This is sent for my ‘all’ lights group.

{'topic': 'smarthome/items/LightsPwr/kitchen_inner_lightsPower/statechanged', 'payload': '{"type":"OnOff","value":"OFF","oldType":"OnOff","oldValue":"ON"}', 'type': 'GroupItemStateChangedEvent'}

I think there needs to be one for the group switch that was hit, so that the status will update correctly. It can’t be done in the browser, since you could have multiple instances of the habpanel.

@bartus helped me on his discord site. He was able to reproduce it. He also found a paperui setting for the group that fixed it for him. “Enforce an auto update”. I set that but it made no difference. I tried looking at the source to see what paperui does with that, but its buried deep in the code; I didn’t make any progress there.

I can’t help but think there is something screwy with my configuration. A bug in handling group switches would certainly have been addressed by now.

Thanks, Andy

[rossko57]

@andyh

He also found a paperui setting … I set that but it made no difference.

But your Group Item is defined in an xxx.items file. You shouldn’t be able to edit your Group in PaperUI.

“Enforce an auto update” is PaperUI equivalent of {autoupdate="true"}
It’s not an appropriate setting to change for a Group type. It’s greyed out for editing a PaperUI created Group type in PaperUI.

That all seems a bit inconsistent. I wonder if you have at some time created a same name Item from both files and PaperUI, it has happened.

[andyh (Andy Howell)]

@rossko57 Regarding the editing in the paperui, I think I was mistaken. It was showing me the possible settings, but I don’t think it was actually saving them. I commented out the two switches and the group in my config and recreated them using the paper ui. Before and after that, I used the rest API to grab the items and links. The paperui versions have editable: true.

Still no luck. To test out your idea that I created the duplicate items in the config and paper-ui, I moved the config file and restarted. I deleted to the paper-ui created ones, and restarted again. I still had a couple items, but these were from the default sitemap. I commented those out in the sitemap for good measure. Restarted again and I didn’t have any unexpected items.

I moved the config file back and restarted. Still seeing the same behavior.

Just in case it helps, here is the dump of my items and links as created by paperui:

    {
        "link": "http://localhost:8080/rest/items/kitchen_inner_lightsPower",
        "state": "ON",
        "stateDescription": {
            "pattern": "%s ",
            "readOnly": false,
            "options": []
        },
        "editable": true,
        "type": "Switch",
        "name": "kitchen_inner_lightsPower",
        "label": "Inner Kitchen Lights",
        "tags": [],
        "groupNames": [
            "kitchen"
        ]
    },
    {
        "link": "http://localhost:8080/rest/items/kitchen_outer_lightsPower",
        "state": "ON",
        "stateDescription": {
            "pattern": "%s ",
            "readOnly": false,
            "options": []
        },
        "editable": true,
        "type": "Switch",
        "name": "kitchen_outer_lightsPower",
        "label": "Kitchen outer lights",
        "tags": [],
        "groupNames": [
            "kitchen"
        ]
    },
    {
        "members": [],
        "groupType": "Switch",
        "function": {
            "name": "OR",
            "params": [
                "ON",
                "OFF"
            ]
        },
        "link": "http://localhost:8080/rest/items/kitchen",
        "state": "ON",
        "editable": true,
        "type": "Group",
        "name": "kitchen",
        "label": "All kitchen lights",
        "tags": [],
        "groupNames": []
    },

And links

    {
        "channelUID": "mqtt:topic:mosquitto:kitchen_outer_lights:power",
        "configuration": {
            "profile": "system:default"
        },
        "itemName": "kitchen_outer_lightsPower"
    },
    {
        "channelUID": "mqtt:topic:mosquitto:kitchen_inner_lights:power",
        "configuration": {
            "profile": "system:default"
        },
        "itemName": "kitchen_inner_lightsPower"
    },

Those are almost the same as my config file created one. Those have editable=“false” and a couple more groups under groupNames. The links have an empty ‘configuration’.

I’m not sure where to go from here.

Thanks for your help, Andy

[rossko57]

I don’t use PaperUI.
I know that somehow item “label [format %s]” appears differently in JSON for xxx.items and PaperUI, but either should work.

I observe that your Group Item JSON has neither [format] in the label nor a stateDescription with pattern. I wouldn’t expect that to display any state in a UI, though e.g. slideswitch widget and icons should still work.

In your original post you had a [%d] , which does a magic trick for groups and displays a count rather than a state.
EDIT - thinking on it, that %d looks like a potential source of trouble. The “server formatted state” of such a Group would be numeric, not on/off. Does your habpanel widget use that, can it deal with it? Or does it use “raw” state?

[curius (Chris)]

Hello!

I have the same problem but also no solution or an idea how to fix it.
My group switch state doesn’t update as expected.
After clicking on the refresh button, the group switch status gets updatet and works again.

I only use configuration files, no Paper UI…
Normal switches (no groups) works like a charm for me in HABpanel
The group switches also works perfectly in the sitemap.

Very frustrating for me ;-(

My item definition:

Switch switch_ku "Power On/Off" (glpanel, glpanel_EG) {channel="mqtt:topic:curius:lpanel_ku:switch_ku"}
Switch switch_ez "Power On/Off" (glpanel, glpanel_EG) {channel="mqtt:topic:curius:lpanel_ez:switch_ez"}
Switch switch_wz "Power On/Off" (glpanel, glpanel_EG) {channel="mqtt:topic:curius:lpanel_wz:switch_wz"}
Switch switch_kij "Power On/Off" (glpanel, glpanel_OG) {channel="mqtt:topic:curius:lpanel_kij:switch_kij"}

Group:Switch:OR(ON, OFF) glpanel "Lichtpanele - Haus" <light> (Home)
Group:Switch:OR(ON, OFF) glpanel_EG "Lichtpanele - EG" <light> (Home)

Best regards
Christian

[rossko57]

A sample of one of your failing Group Item definitions would be helpful.

I’m beginning to think knowing exactly what habpanel widget you use to display is going to be important too.

[curius (Chris)]

Thanks for your fast reply.
I added my items defintion in the post above.

Is it possible to reset the complete HABpanel or to delete the cache?
My HABpanel configuration still worked on another Raspi.
Very strange… ???

Best regards
Christian

[rossko57]

I note that in these Groups too, there is no label [format]. That shouldn’t matter if you’re not displaying Group state as text anyway, and it shouldn’t affect icon or widget graphic (switch toggle) since those should be chosen on Group raw state, not formatted state.
Does it affect what changes are reported, I wonder.

A lot of “should”, depending on the mystery widget behaviour.

[andyh (Andy Howell)]

I created a sitemap for basic-ui. It displays the number of active lights, and functions as expected. It never gets in a state where the group switch doesn’t work. From looking at it in wireshark, it uses a different mechanism for the updates, It looks like its sending messages directly to each widget in the UI.

I poked around in the rest api again, dumping the items, links etc. My conclusion is that the API does not expose the label for the group. It certainly shows up in my basic-ui page, and it updates for each light I turn on and off.

I found this little snippet in openhab.service.js for the habpanel:

        /**
         * Sends command to openHAB
         * @param  {string} item Item's id
         * @param  {string} cmd  Command
         */
        function sendCmd(item, cmd) {
            $http({
                method : 'POST',
                url    : '/rest/items/' + item,
                data   : cmd,
                headers: { 'Content-Type': 'text/plain' }
            }).then(function (data) {
                console.log('Command sent: ' + item + '=' + cmd);

                // should be handled by server push messages but their delivery is erratic
                // so perform a full refresh every time a command is sent
                //loadItems();
            });

Note the comment at the bottom. There was an issue with this at some point. I uncommented the loaditems() and it works as expected! This is a rather heavy handed fix, because it forces a complete download of all items. Fixing the server side to reliably send updates the proper fix for this, I think.

Alternatively, the habpanel could just query the group item state. The problem with that is we have to wait some arbitrary time before polling, since the state will not update instantaneously.

At least we’re getting closer to the underlying problem.

[rossko57]

@andyh

This is a rather heavy handed fix, because it forces a complete download of all items.

Related discussion

[SOLVED] HABPanel sluggish

When switching dashboards HABPanel retrieves the whole list of items again (GET /rest/items) before displaying the widgets, this was a conscious decision to increase the reliability of the display, there were issues with state management when the SSE connection dropped at some point. This also gave opportunity for some widgets, notably the slider, to initialize themselves and perform initial rendering properly - they would display the wrong state or “flicker” for a split second. It was an accep…

[dotelpenguin (Andrew Baker)]

I have had a similar problem, on both my son’s iMac and an android wall tablet. I fought this for 2 weeks, looking everywhere for a solution and finding none. I finally did figure it out, so I figured I would post here and a couple other threads how I fixed it, maybe it will save some other poor person 2 weeks of their time.

My problem was parental controls/content filtering for the network. No matter what settings I used on OSX’s parental control for web filtering (INCLUDING FULL WHITELIST) prevented habpanel items from updating on their own. If you checked the debug consul in chrome you would see elements timing out, or not answering in time. The browser did not matter on OSX, safari, chrome, etc. all did the same thing unless web content filtering was turned OFF.

The problem was similar on the Android tablet, I had an add blocker plugin that caused the same issue. However on the tablet I could whitelist the local IP of my openhab server and that solved the problem.

Hope this helps somebody out there.