First major update in 2.3.0-SNAPSHOT


since 2.2.0 was released in December, we didn’t yet have any updates of the ESH bundles in the nightly builds - I have now just built the first ESH stable build since then, which is included in openHAB Distro #1186. It includes quite some updates, please check out the list of changes yourself.

This is just a heads up - as always, if you encounter any regressions, please file an issue asap so that it can be addressed.

Thanks and happy testing!


Very strange. After upgrading two separate systems, my squeezebox server thing is showing INITIALIZING on both systems. The last thing logged is in the server handler’s initialize method here. Immediately after that, it should attempt to connect to the squeezebox server, but I never see this trace level message here

I didn’t see anything in the change list that would cause this, but maybe there’s something I’m not seeing? Seems like too much of a coincidence.

Edit: Both systems were previously on build 1177. On one system I reverted to my 1177 backup, and the squeezebox things all are online.

2018-01-15 13:24:18.438 [DEBUG] [org.openhab.binding.squeezebox      ] - BundleEvent STARTING - org.openhab.binding.squeezebox
2018-01-15 13:24:18.441 [DEBUG] [org.openhab.binding.squeezebox      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.UpnpDiscoveryParticipant}={,,, service.bundleid=197, service.scope=bundle} - org.openhab.binding.squeezebox
2018-01-15 13:24:18.443 [DEBUG] [org.openhab.binding.squeezebox      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={,,, service.bundleid=197, service.scope=bundle} - org.openhab.binding.squeezebox
2018-01-15 13:24:18.444 [DEBUG] [org.openhab.binding.squeezebox      ] - BundleEvent STARTED - org.openhab.binding.squeezebox
2018-01-15 13:24:18.449 [TRACE] [ox.internal.SqueezeBoxHandlerFactory] - creating handler for bridge thing org.eclipse.smarthome.core.thing.internal.BridgeImpl@fd525cf3
2018-01-15 13:24:18.449 [TRACE] [ox.internal.SqueezeBoxHandlerFactory] - registering player discovery service
2018-01-15 13:24:18.449 [DEBUG] [SqueezeBoxPlayerDiscoveryParticipant] - request player job scheduled to run every 60 seconds
2018-01-15 13:24:18.450 [TRACE] [ebox.handler.SqueezeBoxServerHandler] - Registering player listener
2018-01-15 13:24:18.450 [DEBUG] [org.openhab.binding.squeezebox      ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={, service.bundleid=197, service.scope=singleton} - org.openhab.binding.squeezebox
2018-01-15 13:24:18.452 [DEBUG] [ebox.handler.SqueezeBoxServerHandler] - initializing server handler for thing org.eclipse.smarthome.core.thing.internal.BridgeImpl@fd525cf3

Edit: Also in the unifi binding, I see this message logged. But, the refresh job never runs, because I never see this in the log.

@Kai Is it possible that the change to wrap the ScheduledExecutorService broke something?

Unfortunately, I can confirm the comeback of things remaining in INITIALIZING state at statup :frowning: It concerns almost all bridge things (hue, netatmo, freebox, powermax, …).
I tried 3 startups and same result.
I have the feeling that some bindings are “blocked” as for example my Powermax binding does not finish its init sequence.

I can’t believe that this problem is back again !

I revert to snapshot 1140.

I opened a new issue:

Issue confirmed and under investigation!

Yes, this is my assumption. Somehow the afterExecute does not behave as it should and seems to freeze some threads. But it needs more investigation…

Distro #1187 is now available that fixes the issue!

I was just looking into my own snapshot problems, thanks for the quick response!

I think there still may be an issue with setDiscoveryServiceCallback in 1187.

My GlobalCache binding will not discover devices on my network. Trace logging shows devices on the network being detected successfully. However, they are not being added to the inbox.

Here’s an example of the detection. This device is not in the inbox, nor is there a thing.

2018-01-16 06:45:15.146 [TRACE] [internal.discovery.MulticastListener] - Multicast listener got datagram of length 168 from multicast port:
2018-01-16 06:45:15.147 [TRACE] [internal.discovery.MulticastListener] - Multicast listener parsing announcement packet: AMXB<-UUID=GC100_000C1E00F0E9_GlobalCache><-SDKClass=Utility><-Make=GlobalCache><-Model=GC-100-06><-Revision=1.0.0><Config-Name=GC-100><Config-URL=>
2018-01-16 06:45:15.149 [TRACE] [iscovery.GlobalCacheDiscoveryService] - Device of type GC-100-06 discovered with MAC 000C1E00F0E9 and IP
2018-01-16 06:45:15.149 [TRACE] [internal.discovery.MulticastListener] - Multicast listener looking up thing type for model GC-100-06 at IP

After that last log statement, it checks to see if there already is an inbox entry or thing for that device. In this case, because there is no inbox entry and no thing, I would expect to see the TRACE level statement for creating the discovery result.

In my test environment, I confirmed that the binding’s setDiscoveryServiceCallback method here is not being called.

I will try the same thing with another binding to see if the behavior is consistent.

Edit: I confirmed the same behavior in the bigassfan binding, which uses the discovery service callback in a similar way.

I’m running OH 2.3.0 snapshot 1208, and I see ESH at version Was the ESH version bumped in order to include some fixes, or are we getting more regular ESH updates? Either way, it appears to have included the PR attached to this issue. These changes break JSONPATH functionality in rules where indefinite paths are used. I didn’t see any communication about this, so I thought I’d mention it here for others that find some of their rules failing.

@kai, it has been two days now, but I haven’t gotten any response from the people who worked on this. Should I have opened a new issue, or am I just being impatient? I had hoped this would be addressed before the next ESH update.

2 days isn’t much, especially if people are on vacation and/or sick. So you’d better leave them some more time to respond.
Note that there’s also another JSONPath related issue under discussion, not sure how much this is related to your issue.

1 Like

When trying to update to 2.3.0 (from 2.2.0 stable) via openhabian-config as described in the release notes it does not offer me 2.3.0 although I am following the release notes exactly as described.

The console says

   [openHABian] Updating myself... OK - No remote changes detected. You are up to date!

I even tried via manual/fresh setup:

   /opt/openhabian/functions/ line 171: openhab2_stable_setup: command not found
   /opt/openhabian/functions/ line 172: openhab2_unstable_setup: command not found

Do you have any ideas?

Thanks in advance

Even though I couldn’t get it to run through the openhabian-config, @omr was so kind to explain to me how it could be done manually

cat /etc/apt/sources.list.d/openhab2.list 

shows the old content. Change the file (e.g. with nano) to have the following content

deb unstable main

After changing file, do:

sudo apt-get update
sudo apt-get upgrade

What could have worked though in openhabian config is to go into 40 openhab-related and then switch in 41 to the unstable version. Haven’t tried that though because the manual way did work…

1 Like

It also breaks JSONPATH functionality in item definitions where indefinite paths are used. From 2.3 on, JSONPATH resultsets containing more than a single value are no longer allowed in item definitions. :frowning:

From the Eclipse Smarthome homepage:

While there are approaches of defining common communication protocols that all devices and systems must support in order to communicate with each other, the Eclipse SmartHome™ project accepts the fact that there is a vast variety of communication mechanisms, which all have their right to exist. Eclipse SmartHome™ therefore serves as an abstraction and translation framework that makes interaction possible across system and protocol boundaries.