openHAB 3.4 Release discussion

jptaszyk · December 24, 2022, 11:47pm

Yes, I am also experiencing this. My logs are flooded right now and it seems to even impact performance on my raspberry pi.

goligo · December 25, 2022, 1:32am

Sliders and Setpoints in basic UI are currently broken in 3.4.0, when used with a Number type with dimension (e.g. Number:Temperature) and no explicit unit is set in the pattern.

github.com/openhab/openhab-webui

Slider and Setpoint with Number:Temperature broken after upgrading to OpenHAB 3.4.0

opened 02:17AM - 24 Dec 22 UTC

goligo

bug basic ui

## Which UI are you reporting an issue for? - [X] Basic UI - [ ] HABPanel -… [ ] HABot - [ ] CometVisu ## The problem After updating to OpenHAB 3.4.0 the slider widgets for controlling the target temperature do no longer work. Moving the slider has no effect, the temperature is neither updated on the UI, nor is any event for changing the item state shown in the event log. The reason is that request triggered by the slider is receiving a "400 Bad Request" response. When checking the request payload, I saw that the slider is sending "19 %unit%" as the update value. This seems to be causing the error, when I change the pattern on the item explicitely to "%.1f °C", the issue does no longer occur. ## Expected behavior When moving the slider, the item state should be updated and the target temperature should be changed. ## Steps to reproduce 1. Create an item of type "Number:Temperature" and set the pattern to "%.1f %unit%" 2. Create slider in the basic UI for this item 3. Try to move the slider and check the browser network trace ## Your environment ```yaml runtimeInfo: version: 3.4.0 buildString: Release Build locale: de-DE systemInfo: configFolder: /etc/openhab userdataFolder: /var/lib/openhab logFolder: /var/log/openhab javaVersion: 11.0.10 javaVendor: Azul Systems, Inc. javaVendorVersion: Zulu11.45+27-CA osName: Linux osVersion: 5.10.63-v7+ osArchitecture: arm availableProcessors: 4 freeMemory: 37094744 totalMemory: 194772992 startLevel: 100 bindings: - avmfritz - exec - goecharger - http - icalendar - ipp - mail - mqtt - network - ntp - shelly - telegram - tr064 - vitotronic clientInfo: device: ios: false android: false androidChrome: false desktop: true iphone: false ipod: false ipad: false edge: false ie: false firefox: false macos: true windows: false cordova: false phonegap: false electron: false nwjs: false webView: false webview: false standalone: false os: macos pixelRatio: 1 prefersColorScheme: dark isSecureContext: false locationbarVisible: true menubarVisible: true navigator: cookieEnabled: true deviceMemory: N/A hardwareConcurrency: 4 language: de languages: - de onLine: true platform: MacIntel 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 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36 timestamp: 2022-12-24T02:13:18.376Z ``` ## Browser console ```txt smarthome.js:1 POST http://openhab:8080/rest/items/HaupthausBadLinks_Zieltemperatur 400 (Bad Request) l @ smarthome.js:1 I @ smarthome.js:1 (anonymous) @ smarthome.js:1 o.call @ smarthome.js:1 a @ smarthome.js:1 ``` ## Browser network traffic ![Screenshot 2022-12-24 at 03 15 05](https://user-images.githubusercontent.com/1894593/209417857-5e43b6f1-e45a-47d4-a6aa-a29a96e64096.png) ![Screenshot 2022-12-24 at 03 15 23](https://user-images.githubusercontent.com/1894593/209417861-32de2709-9fef-45ef-934c-f3c6dfa5ed17.png) ## Additional information Slider was working fine with OpenHAB 3.3.0, issue only occured after upgrading to 3.4.0

As a workaround you have to define a pattern for each affected item, which contains the unit you want to use (e.g. %.1f °C).

jlikonen · December 25, 2022, 12:40pm

I just upgraded OH 3.3 to 3.4. My Karaf window under Win11 shows that OH version is 3.4 (see attached screen copy)

but Help&About in MainUI shows 3.2.

I had this same issue when upgrading 3.2 to 3.3 so what I’m missing.

gd35 · December 25, 2022, 12:49pm

Thanks for the feedback. Happy to see that this issue is known. I should have checked this before…

og-openhab · December 27, 2022, 8:02am

Due to this problem, I downgraded back to OH3.3.
Will check on a separate instance if there are possible solution available.

Lolodomo · December 27, 2022, 8:54am

Which one?

og-openhab · December 27, 2022, 9:41am

Problems with the “Bose Soundtouch Binding”.
It does not receive events from the devices in OH3.4.
Also the control from OH is not working as in OH3.3, e.g. selection of presets.

Lolodomo · December 27, 2022, 9:51am

Is it solved if you clear the cache of your WEB browser ?

Lolodomo · December 27, 2022, 10:08am

Work in progress to fix the Bose Soundtouch binding:

github.com/openhab/openhab-addons

[bosesoundtouch] Things don't receive state updates and configurations from the speakers anymore

opened 12:55PM - 24 Dec 22 UTC

closed 12:58PM - 30 Dec 22 UTC

paeddib

bug

I have bose soundtouch speakers 10 and 20. After updating openhab to version 3.4….0, the items do not receive any state updates and configurations from the speakers anymore. Also, it is not possible to switch to a speaker preset number. ## Expected Behavior Items receive states and configurations from the speakers. Power on/off, Presets, etc... ## Current Behavior Generally, a soundtouch thing does not get any updates from the speakers, but the speakers do receive most of the commands from openhab. That leads to a behaviour, that if a speaker is turning on with an openhab switch item, the item immediately switches back to "OFF" and will never has an "ON"-state. If the speaker preset is changed in openhab, nothing happens on the speakers. The log shows a warning message [WARN ] [bosesoundtouch.internal.CommandExecutor] - null: No preset found at id: 3 ## Possible Solution I think the changes from version 3.3.0 to 3.4.0 breaks receiving states and configurations from the speakers. This leads to the described behaviour. ## Steps to Reproduce (for Bugs) 1. Turn on a speaker with a switch item => The item immediately turns back to off, the speaker turns on. 2. Turn on a speaker=> The openhab switch item does not receive power ON state. 3. Change speaker preset with openhab => Speaker does not change preset. ## Context ## Your Environment * Version used: openHAB 3.4.0; add-on version 3.4.0

lsiepel · December 27, 2022, 11:21am

Could you grab the jar from the github [issue ([bosesoundtouch] Things don't receive state updates and configurations from the speakers anymore · Issue #14059 · openhab/openhab-addons · GitHub) and test the latest version and report back with your findings and debug log? Thanks!

jlikonen · December 27, 2022, 12:38pm

No, I tried both FF and MS Edge with cleared caches and Help&about still shows 3.2.0.

Lolodomo · December 27, 2022, 5:17pm

Strange question but are you sure to point your browser to the right server?
How did you run your upgrade?

jptaszyk · December 27, 2022, 5:33pm

After some experiments I think it might have something to do with triggering hue from rules.
Or maybe my rules are written badly, resulting in huge performance issues. But since everything was faster with 3.3.0 it might as well be something different.

Any ideas on how to debug this?

jlikonen · December 28, 2022, 5:12am

I have only one openHAB server in my home network so the browser must point to the correct server. I made the OH3.4 installation according to the manual installation section in Download openHAB | openHAB.

Mick_Smothers · December 28, 2022, 5:38am

I am also having the same problem. Seems to be all my Chromecast enabled devices (I have many) including several minis, a Nest Hub, a Nest Hub Max, a bunch of chromecast enabled Vizio smart TVs, an original Google Home, and even a couple of remaining actual Chromecasts. My logs are getting pounded with the Offline/Online ping pong action. Hopefully this is something that is an easy fix.

Here’s what my logs are filled with:

2022-12-27 23:36:53.427 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:88bad034dd40307e13ba8b775ececedb' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:36:54.978 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:5f704f7973428c949f6287a88e10c6a2' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:36:56.819 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:062abc50874a948a0bb0df136bcc677f' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:36:58.162 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:6a68b880438f43b57ba24d410cb62142' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:36:58.213 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:88bad034dd40307e13ba8b775ececedb' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:37:01.466 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:6a68b880438f43b57ba24d410cb62142' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:37:01.554 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:6a68b880438f43b57ba24d410cb62142' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:37:03.222 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:062abc50874a948a0bb0df136bcc677f' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:37:04.882 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:5f704f7973428c949f6287a88e10c6a2' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:37:05.045 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:5f704f7973428c949f6287a88e10c6a2' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:37:06.481 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:88bad034dd40307e13ba8b775ececedb' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)
2022-12-27 23:37:08.313 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:88bad034dd40307e13ba8b775ececedb' changed from OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable) to ONLINE
2022-12-27 23:37:09.874 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:062abc50874a948a0bb0df136bcc677f' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): No route to host (Host unreachable)

stefan.hoehn · December 28, 2022, 12:14pm

@Mick_Smothers @Lolodomo @higgers @JimT

I finally became so annoyed with the flickering chromecast things (during development I need to look at the logs so often that something like this is extremely distracting ) that I picked up the issue.

There doesn’t seem to be a codeowner around for that binding, so I did at least one simple thing. Even though the binding has a surprisingly good amount of logging implemented, nothing comes up in my cases (or lets say hardly ever) that would hint me why it goes offline. So I went through the code and detected a few white logging spots. I added a number of traces to every location in the code where the binding tells the core to put the thing OFFLINE, built a new jar file based on 3.4, deployed it to my production system and hope to see that something is coming up.

I guess you know what is coming now in a strange world like this: ever since I deployed the new bundle version, there is complete silence (remember, there is no change except more logs on the trace level) …

Anyways, if anyone wants me to join on testing this and is able to deploy an addon manually, please PM me and I will provide you with a snapshot build of that bundle.

higgers · December 28, 2022, 12:17pm

Do you mean that after you added the logging the things do not go offline any more?

stefan.hoehn · December 28, 2022, 12:17pm

Yes

higgers · December 28, 2022, 12:19pm

Ah, the joys of software development!

Does this point to something other than the binding being the issue? Did you reboot your OH server or restart the OH service? Could something else you did have resolved the issue?

JimT · December 28, 2022, 12:19pm

@stefan.hoehn is it in a github branch? I can build the jar and also help debug it.
I’m still seeing this issue on my system.