Switch OFF Command stuck

[BremerButjer]

The problem

A switch bulb item was created. If it is switched via MS Edge or Chrome Browser, only the ON command is sent, not the OFF command. If the item is switched via SAFARI (iPhone), it works without any problems.

Expected behavior

The function should work the same with all browsers.

[roquestrongo]

I can confirm this behavior on my Openhab 3 installation (Ubuntu 18.04.5 LTS, Java 11.0.9.1 Zulu)

I upgraded from openhab 2.5 to Openhab 3.

I got the following MQTT Channel:

    UID: mqtt:topic:wzog_lcu
    label: ogwz_lcu
    thingTypeUID: mqtt:topic
    configuration:
      availabilityTopic: wzog_lcu/status
      payloadAvailable: online
    bridgeUID: mqtt:broker:afc2aaab5a
    location: Wohnzimmer
    channels:
      - id: ogwz_lcu_cct_group_1_state
        channelTypeUID: mqtt:switch
        label: CCT Group 1 - STATE
        description: ""
        configuration:
          postCommand: false
          qos: 1
          formatBeforePublish: '{"state":"%s"}'
          commandTopic: wzog_lcu/light/cct_group_1/command
          stateTopic: wzog_lcu/light/cct_group_1/state
          transformationPattern: JSONPATH:$.state
          off: OFF
          on: ON

If i switch the corresponding switch item inside "Main UI > Settings > Items" on my Windows PC (Chrome) i get the following Karaf output:

    13:45:45.401 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'ogwz_lcu_CCT_Group_1_STATE' received command ON
    13:45:45.402 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'ogwz_lcu_CCT_Group_1_STATE' predicted to become ON

I only see a log output when switching on, if i switch off there is no output in Karaf , neither an error reported, and accordingly i also don´t see a message published on the mqtt topic.

Now if i open MainUI in Chrome on my Android phone, and switch the corresponding switch item inside "Basic UI > Settings > Items" , both on and off command are visible in Karaf and also messages are published to the mqtt topic.

I doubt there might be an issue due the behavior sholud be the same independent the OS that is used?

Regards

Roque

[KenkiCK]

I can confirm that it also in Firefox there. Switch on works, switch off not. Regards, Christian

[genaumann]

I don't have any problems on iOS Safari and Firefox. On desktop Firefox and Chrome I have the same problems.

[onkelphilli]

Same for me. Only ON command is send (although item is already ON). Repeated switching only gives several ON-commands in the event-log.

Status in ITEM-List is displayed correctly:

Switch-Button in ITEM-page is off, however:

However, ON/OFF-switching of the same item in HABpanel is working without any problems.

[Micware2]

I am experiencing the same with Google Chrome en Microsoft Edge (chromium) on Windows 10 Chrome version 87.0.4280.101 on Android 7.0 is working correct and is sending ON and OFF command

runtimeInfo: version: 3.0.0 buildString: Release Build locale: en systemInfo: configFolder: /etc/openhab userdataFolder: /var/lib/openhab logFolder: /var/log/openhab javaVersion: 11.0.9.1 javaVendor: Raspbian osName: Linux osVersion: 5.4.79-v7l+ osArchitecture: arm availableProcessors: 4 freeMemory: 26119936 totalMemory: 131072000 bindings:

• astro
• miio
• mqtt
• remoteopenhab
• zwave clientInfo: device: ios: false android: false androidChrome: false desktop: true iphone: false ipod: false ipad: false edge: false ie: false firefox: false macos: false windows: true cordova: false phonegap: false electron: false nwjs: false webView: false webview: false standalone: false os: windows pixelRatio: 1.5 prefersColorScheme: dark isSecureContext: false locationbarVisible: true menubarVisible: true navigator: cookieEnabled: true deviceMemory: N/A hardwareConcurrency: 8 language: nl-NL languages:
  • nl-NL
  • nl
  • en-US
  • en onLine: true platform: Win32 screen: width: 2560 height: 1440 colorDepth: 24 support: touch: false pointerEvents: true observer: true passiveListener: true gestures: false intersectionObserver: true themeOptions: dark: dark filled: true pageTransitionAnimation: default bars: light homeNavbar: default homeBackground: default expandableCardAnimation: default userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36 timestamp: 2021-01-04T19:06:57.275Z

[ghys]

Is this only for switches linked to MQTT channels?

[onkelphilli]

Is this only for switches linked to MQTT channels?

In my case, the Items are linked to KNX-Channels.

[Micware2]

my experience so far is with MQTT because I don't have any other switches in Openhab 3 yet

[n1kDon]

I have the same problem, I think it has something to do with the auth bundle. When I stop the bundle with karaf (bundle:stop org.openhab.core.io.rest.auth) everything works. The problem is that you can not login in the web gui anymore. So you have to start the bundle to login and stop it after that.

[ghys]

I need someone who's experiencing this to reproduce the issue with the Network tab of the browser's developer tools open and able to provide a HAR file.

Chrome:

Firefox:

Note that these will contain all the network requests in the list so try to keep it short and focused.

[BremerButjer]

I need someone who's experiencing this to reproduce the issue with the Network tab of the browser's developer tools open and able to provide a HAR file.

Chrome:

Firefox:

Note that these will contain all the network requests in the list so try to keep it short and focused.

I have generated it. Should I send it via mail?

[ghys]

Or via PM on community.openhab.org if you can.

[BremerButjer]

Or via PM on community.openhab.org if you can.

done

[ghys]

Okay, I think I have figured it out, at least in @BremerButjer's case. The problem is that you're not receiving SSE updates. In that case the state as known by the switch remains in a state that is interpreted to be "off", that's why only ON works - when going back to OFF it doesn't do anything because as far as the control is concerned the switch's state is already OFF.

To confirm, if you're experiencing this, in the Developer tools section of the UI, go to the Debug tab, and click "Stream Events" so that it changes to "Stop Streaming". Then for instance in another tab, or with another browser/device, try flipping switches on and off. If you don't get events appearing, that means SSE don't work for you. On devices that work, you will get events.

Usually, on desktops, the problem is due to a proxy server that doesn't like these SSE connections and tries to intercept them. This includes developer proxies like Fiddler or Charles, this could also be caused by Privoxy, or even some anti-virus suites. Try to figure out how to disable them or add exceptions for your openHAB server.

I can also make the switch control better i.e. send the command anyway but it won't fix your inherent problem of receiving no SSE updates.

[roquestrongo]

I was about to reproduce the error with developer tools for ghys, when i noticed that the ITEM in "Settings" > "Items" page behaves correctly now, switching ON / OFF both is shown in Karaf log now and also MQTT publish works. Possibly this is due i reset my chrome a few days ago.

What i forgott to mention in my first post is that however on the ITEM Page the switching is not wokring correctly, the item can be used correctly when switched from Habpanel.

However it is confusing to the people when setting up the channel and linking the item then everyone will try to test on the items page and then search for the error instead trying to use the item in a sitemap or on Habpanel.

[n1kDon]

I opened the developer tools in chrome, it shows under Console a 401 error even when I am logged in as admin. On habpanel it shows connection lost...

[BremerButjer]

Okay, I think I have figured it out, at least in @BremerButjer's case. The problem is that you're not receiving SSE updates. In that case the state as known by the switch remains in a state that is interpreted to be "off", that's why only ON works - when going back to OFF it doesn't do anything because as far as the control is concerned the switch's state is already OFF.

To confirm, if you're experiencing this, in the Developer tools section of the UI, go to the Debug tab, and click "Stream Events" so that it changes to "Stop Streaming". Then for instance in another tab, or with another browser/device, try flipping switches on and off. If you don't get events appearing, that means SSE don't work for you. On devices that work, you will get events.

Usually, on desktops, the problem is due to a proxy server that doesn't like these SSE connections and tries to intercept them. This includes developer proxies like Fiddler or Charles, this could also be caused by Privoxy, or even some anti-virus suites. Try to figure out how to disable them or add exceptions for your openHAB server.

I can also make the switch control better i.e. send the command anyway but it won't fix your inherent problem of receiving no SSE updates.

At the moment I have no idea how to fix this at home....

[onkelphilli]

Okay, I think I have figured it out, at least in @BremerButjer's case. The problem is that you're not receiving SSE updates. In that case the state as known by the switch remains in a state that is interpreted to be "off", that's why only ON works - when going back to OFF it doesn't do anything because as far as the control is concerned the switch's state is already OFF.

To confirm, if you're experiencing this, in the Developer tools section of the UI, go to the Debug tab, and click "Stream Events" so that it changes to "Stop Streaming". Then for instance in another tab, or with another browser/device, try flipping switches on and off. If you don't get events appearing, that means SSE don't work for you. On devices that work, you will get events.

Usually, on desktops, the problem is due to a proxy server that doesn't like these SSE connections and tries to intercept them. This includes developer proxies like Fiddler or Charles, this could also be caused by Privoxy, or even some anti-virus suites. Try to figure out how to disable them or add exceptions for your openHAB server.

I can also make the switch control better i.e. send the command anyway but it won't fix your inherent problem of receiving no SSE updates.

That's it!!! In my case, Sophos AV seems to filter SSE updates. Switched to HTTPS... now it's working like a charm.

Many thanks for the right hint!

[ghys]

@n1kDon you are suffering from #699. Go to settings, API security, show advanced, enable "implicit user role for unauthenticated requests"'. It's probably disabled.

[n1kDon]

@ghys thank you! enabled it and now it works.

[comgen89]

@onkelphilli

how do you switch to HTTPS?

[onkelphilli]

@onkelphilli

how do you switch to HTTPS?

The default port is 8443. So you can open that one by adding ":8443" to your address, e.g. "https://localhost:8443" or "https://myopenhabserver:8443" (replace the name with your server name). Depending on your browser, you might get a warning message about an unsecure connection (as long as you do not use a proper ssl-certificate) but you can confirm this.

[wall121]

Hi.

I just migrated from OH 2.5 to 3.10 M4

I also have that issue with a group switch created in a .items file. Group of HUE-lights turned ON, but not OFF in a toggle card

A single items switch works

Using https or http, different browsers on Mac (Chrome/Safari) and iPhone (safari / Chrome)

API Security set as suggested from ghys

It still works with the sitemap from OH2

Any ideas?

Just solved it 30 min later by myself:

I added ":Switch:OR(ON,OFF)" to the Group definition in the items file:

Group:Switch:OR(ON,OFF) F2_AlleHUE_Switch "Schalter Licht oben "

Anyway, maybe it helps others

[lucacalcaterra]

I'm working on a binding with latest version of distro on eclipse. Same issue, command on ok, command off not sent

[smlabonia]

In my case, the elements i changed recently before this issue starts was the HTTPS connection and disable the Implicit user role for unauthenticated requests option.

I re enable Implicit user role for unauthenticated requests, and change to HTTP and the issue is solved.

[mike-bike]

I have the same problem, I think it has something to do with the auth bundle. When I stop the bundle with karaf (bundle:stop org.openhab.core.io.rest.auth) everything works. The problem is that you can not login in the web gui anymore. So you have to start the bundle to login and stop it after that.

This is really an interesting observation which I can confirm. Not sure how you figured that out. I tried on a fresh PI4 openhabian install (openhab 3.1). When auth bundle is active, switch is not working and I also do not see color picker in the UI. When I turn auth off (bundle:stop org.openhab.core.io.rest.auth) switch is working and color picker shows up. I am pretty sure, that this was working with a previous install a few weeks ago. At least I have not played around with the auth bundle.

I can also confirm smlabonia's observation above. Enabling implicit user role with HTTP does also work - even with auth bundle active. Maybe, that's the difference to my previous install.

Strange behavior - but for me it works with enabled Implicit User Role.

Many greetings from Cologne, Germany

Have a great day Michael

[danieldid]

When I stumbled across this comment I couldn't believe that THAT is the solution for me! Thank you so much for pin point that to SOPHOS.

It took me 2 (!) days to find the "solution" for the switch just turning on instead of toggling. What's pretty weird though - why a "ON" is sent and "OFF" get's intercepted by SOPHOS.

Cheers out of Tirol

[jsetton]

@ghys I am actually running into this issue while making changes to a binding and setting the autoUpdatePolicy to veto on some of the channels that are command only. This would be the same issue when autoupdate=false is configured on a Switch item.

Why not have two separate buttons side by side when the current state of a Switch item is NULL or UNDEF?

[amiiit]

, the problem is due to a proxy server that doesn't like these SSE connections

@ghys can you please explain what is it that the proxy server may be dropping? I have OpenHAB installed behing nginx reverse proxy, and while the UI is fine, including authentication (that required a bit of special solutioning due to search params), what is it exactly that I should be looking for in the proxy configuration?