openHAB 3.4 Release discussion

Hi,
i updated to 3.4 and now i cant access:
Settings
Developer Tools
Help
if i click on them nothing happend.
has anybody else the same problem?
Unbenannt

it only works if i type the ipadress:port/setting in my browser.
in Openhab app they are also not accessable

No, I just checked. I can click on them all and it works. What browser are you using, has your startup finished, have you restarted your browser?

tryed a few times.
after i accesed the setting by ip:port/settings
everything worked.
so for now problem is solved, but its strange

Dear all,
same procedure as every half year, here’s my moderator’s request:

Please only post to this thread on issues specific to 3.4 code, i.e. issues that were introduced with 3.4 and didn’t exist before, that you can reproduce and confirm to be general issues with the code and not your installation.
Help us keep communication clean and effective. So for anything else, please open your own thread.
Thank you.

10 posts were split to a new topic: Setpoints and Drayton binding in 3.4

I upgraded to OH 3.4.0 this morning and had several messages indicating issues with shelly username/password. After 3 or 4 reboots those messages dissapeared though.
All 30+ shellies working fine now on OH 3.4.0…

If this happens you can try Ctrl+F5 (command+R on Mac) or other techniques to Wikipedia:Bypass your cache - Wikipedia.
Or, on Chrome-based browsers, open the developer tools (usually F12), click Application, check all the boxes and then Clear site data. You will be signed out.
Normally you wouldn’t have to do all this but there were some more caching lately introduced so you can try starting with a clean state.

1 Like

There’s a potentially breaking change on UoM (units of measurement), 3.4 introduced default units for all UoM item types now.

It’s a complex, multi-layer implementation and discussion, I moved it here:

Hi there,

let my openHABian update from 3.3 to 3.4 packages, I stopped all services, cleaned cache etc. in prior.

Seems everything is working, on short term, but those messages spams after update my log files:

...
2022-12-21 19:51:50.188 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.

2022-12-21 19:51:50.191 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ShellyRelayHandler tried updating the thing status although the handler was already disposed.
...

It’s barely possible to read logs on WebIF (PaperUI) … all Shelly devices can be controlled properly incl. Shelly Manager App. Message is a warning, so most probably nothing critical.

Any ideas how to fix or get rid of that messages spam?

Thanks.

Cheers

An update, if I start/run my openhab instance w/o Shelly binding, message spam disappears. Re-starting with Shelly binding brings them back.

So, looks like something is fishy with Shelly binding after upgrade from openHAB 3.3 to new stable 3.4 … but what?

Cheers

Hi,

after switching my Docker from 3.3 to 3.4 the MySQL persistence service is no longer working. So I had to switch back to the 3.3 version, which still works fine. The log says:

2022-12-21 20:41:47.530 [INFO ] [persistence.jdbc.internal.JdbcMapper] - JDBC::openConnection: Driver is available::Yank setupDataSource
2022-12-21 20:41:48.412 [ERROR] [jdbc.internal.JdbcPersistenceService] - bundle org.openhab.persistence.jdbc:3.4.0 (304)[org.openhab.persistence.jdbc.internal.JdbcPersistenceService(356)] : The activate method has thrown an exception
	at org.openhab.persistence.jdbc.internal.NamingStrategy.getTableName(NamingStrategy.java:46) ~[?:?]
	at org.openhab.persistence.jdbc.internal.JdbcMapper.populateItemNameToTableNameMap(JdbcMapper.java:344) ~[?:?]
	at org.openhab.persistence.jdbc.internal.JdbcMapper.checkDBSchema(JdbcMapper.java:332) ~[?:?]
	at org.openhab.persistence.jdbc.internal.JdbcPersistenceService.updateConfig(JdbcPersistenceService.java:247) ~[?:?]
	at org.openhab.persistence.jdbc.internal.JdbcPersistenceService.activate(JdbcPersistenceService.java:94) ~[?:?]
2022-12-21 20:41:48.436 [WARN ] [ence.internal.PersistenceManagerImpl] - bundle org.openhab.core.persistence:3.4.0 (209)[org.openhab.core.persistence.internal.PersistenceManagerImpl(231)] : Could not get service from ref {org.openhab.core.persistence.PersistenceService, org.openhab.core.persistence.QueryablePersistenceService}={service.scope=bundle, enableLogTime=false,...........
2022-12-21 20:47:13.523 [WARN ] [nce.extensions.PersistenceExtensions] - There is no queryable persistence service registered with the id 'jdbc'

Any hints what might have been changed between 3.3 and 3.4?

Since I upgraded to 3.4.0 (RC1) the chromecast binding has become pretty flickering in that the device go offline / online every other 10sec (which is the refresh rate).

 [DEBUG] [andler.ChromecastHandler$Coordinator] - Connect failed, trying to reconnect: No route to host (Host unreachable)
 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ChromecastHandler tried updating the thing status although the handler was already disposed.
 [DEBUG] [omecast.internal.ChromecastScheduler] - Canceling connection
 [DEBUG] [omecast.internal.ChromecastScheduler] - Scheduling connection

[INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:5fa9d22389a1977c0cff5326b87dxxxx' changed from ONLINE to UNKNOWN
[INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'chromecast:chromecast:5fa9d22389a1977c0cff5326b87dxxxx' changed from UNKNOWN to ONLINE



which seems to happen in

ChromecastHandler ->
private static class Coordinator { 
....
        private void connect() {
            try {
                chromeCast.connect();

                statusUpdater.updateMediaStatus(null);
                statusUpdater.updateStatus(ThingStatus.ONLINE);

                connectionState = ConnectionState.CONNECTED;
            } catch (final IOException | GeneralSecurityException e) {
                logger.debug("Connect failed, trying to reconnect: {}", e.getMessage());
                statusUpdater.updateStatus(ThingStatus.OFFLINE, ThingStatusDetail.OFFLINE.COMMUNICATION_ERROR,
                        e.getMessage());
                scheduler.scheduleConnect();
            }
        }

Checking the changes on the repo don’t seem to reveal any changes lately,even the used library su.litvak.chromecast.api.v2 hasn’t been changed for a long time.

I checked that the devices ARE available in the network.

The problem is that the devices are now unreliable and I even get a

“No application is running in ChromeCast”

when I try to play a stream

Does anyone has the same effect or an idea what the issue could be?

1 Like

I just upgraded my docker to OH 3.4.
I see issues with the addon “Bose SoundTouch Binding”.
There are no spontaneous events present in events.log.
Does anyone face same issues?

Yes, similar problem here. The status seems not in sync for the connected item to e.g. power on/off.

Sample:
I have a switch item “BoseBueroStefan_Power” connected to channel “bosesoundtouch:20:ReplacedId:power”.

If I switch on the Bose SoundTouch via the OpenHAB sitemap, then the switch moves to ON and I see these events:

2022-12-22 09:43:11.655 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'BoseBueroStefan_Power' received command ON
2022-12-22 09:43:11.655 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'BoseBueroStefan_Power' predicted to become ON
2022-12-22 09:43:11.657 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BoseBueroStefan_Power' changed from OFF to ON
2022-12-22 09:43:11.658 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'BoseBueroStefan_Power' changed from ON to OFF

The last event seems strange for me.

If I then try to switch off the Bose SoundTouch again via sitemap and move the switch to the off position, then nothing happens. If I push it to ON position again, then the Bose SoundTouch is switched off! Means the switch shown on the sitemap and the real status are out of sync.

No docker environment - own virtual machine for OpenHAB - so something with the Bose binding itself and the event handling seems to be wrong.

OK, I have to say;

Big thanks to everyone involved in getting openHAB to this state!

I just upgraded from 3.1 to 3.4, and experienced absolutely not issues at all. This is by far the smoothest upgrade I have seen.

The only thing that I experienced was that one tempest sensor on weatherflow binding was disabled in the things view.

Well done!

2 Likes

Hi there,
based on major problems on my system I did today a fresh install of openhabian and open hab 3.4

I am using

  • Linux 5.15.76-v7l+
  • OH 3.4.0
  • Raspberry Pi 4 Model B Rev 1.1
  • Deconz and Hue Binding

My Problem is now, that in mainUi location I do not see color selections any longer. In 3.3 it still was there. I am not sure if item type for color have changed. If it is a config thing, I will open a new post, but due to having the problem since 3.4, I post it here, sorry Markus.

Color	ZigLightstrip_1        "Lightstrip TV [%s]"         <colorwheel> (gLicht_Wohnen,gChart)     ["Switch","Light"]       { alexa="ColorController.color,Lighting,BrightnessController.brightness", channel="hue:0210:00212E03B617:Lightstrip1:color" }

I would expect the selection field to chose the color, which was possible before I did the cleanup. Is this something. I did from or is it a bug in 3.4.0?

Kindly,
Woogi

Found the solution. Semantic Definition needs to be [“Control”,“Light”]. This changed to 3.3, I assume. For my Dimmer items it is the same [“Setpoint”,“Light”] instead of [“Switch”,“Light”]. Hope this helps someone.

3 Likes

I have started to use rules being triggered by the value of a DateTime Item and now see, that those rules don‘t show up in the UI scheduler after system restart, furthermore, they don‘t get triggered at all.
Only after manually disabling those rules and reenabling them will bring back full functionality.
Anyone else seeing this and/or found a solution?

I can 2. that.
Upgrade from 3.4.0M1 to 3.4.0 went smooth.

Can you try to enable debug logging? This would probably make it possible to see what’s going on just before the problem occurs.

Hi, a largely smooth transition for me so thanks to the team for continuing the great work, and best wishes for the festive season to everyone who celebrates it.

The only problem I’ve spotted is that the light level data from Aeon Multisensor 6 items (Z wave binding) appear to have remained unchanged ever since the update. Other channels (temperature, humidity, presence) are updating fine, but the light level has remained fixed for a couple of days. Anyone else got this, or any suggestions? Happy to post up any additional data if there’s specific information that will help. Update was from a 3.3.x copy, and I’m running on Windows 10.

Al

1 Like