First major update in 2.3.0-SNAPSHOT

Kai · January 15, 2018, 5:19pm

All,

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!
Kai

mhilbush · January 15, 2018, 6:35pm

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}={component.name=org.openhab.binding.squeezebox.internal.discovery.SqueezeBoxServerDiscoveryParticipant, component.id=228, service.id=381, 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}={component.name=org.openhab.binding.squeezebox.internal.SqueezeBoxHandlerFactory, component.id=229, service.id=382, 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.id=383, 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?

Lolodomo · January 15, 2018, 7:47pm

Unfortunately, I can confirm the comeback of things remaining in INITIALIZING state at statup 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.

Lolodomo · January 15, 2018, 8:44pm

I opened a new issue: https://github.com/eclipse/smarthome/issues/4931

Kai · January 15, 2018, 9:48pm

Issue confirmed and under investigation!

Kai · January 15, 2018, 9:56pm

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…

Kai · January 15, 2018, 11:11pm

Distro #1187 is now available that fixes the issue!

martinvw · January 16, 2018, 6:05am

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

mhilbush · January 16, 2018, 12:23pm

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: java.net.DatagramPacket@52ad12db
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=http://192.168.1.95>
2018-01-16 06:45:15.149 [TRACE] [iscovery.GlobalCacheDiscoveryService] - Device of type GC-100-06 discovered with MAC 000C1E00F0E9 and IP 192.168.1.95
2018-01-16 06:45:15.149 [TRACE] [internal.discovery.MulticastListener] - Multicast listener looking up thing type for model GC-100-06 at IP 192.168.1.95

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.

github.com

openhab/openhab2-addons/blob/master/addons/binding/org.openhab.binding.globalcache/src/main/java/org/openhab/binding/globalcache/internal/discovery/GlobalCacheDiscoveryService.java#L170




            logger.trace("Device of type {} discovered with MAC {} and IP {}", gcMulticastListener.getModel(),
                    gcMulticastListener.getMACAddress(), gcMulticastListener.getIPAddress());


            ThingTypeUID typeUID = gcMulticastListener.getThingTypeUID();
            if (typeUID != null) {
                ThingUID uid = new ThingUID(typeUID, gcMulticastListener.getSerialNumber());
                logger.trace("Creating discovery result for: {}, type={}, IP={}", uid,
                        gcMulticastListener.getModel(), gcMulticastListener.getIPAddress());
                thingDiscovered(DiscoveryResultBuilder.create(uid).withProperties(properties)
                        .withLabel(gcMulticastListener.getVendor() + " " + gcMulticastListener.getModel()).build());
            }
        }
    }
    gcMulticastListener.shutdown();
    logger.debug("Discovery job is exiting");
}


@Reference
protected void setNetworkAddressService(NetworkAddressService networkAddressService) {
    this.networkAddressService = networkAddressService;

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.

5iver · February 11, 2018, 10:32pm

I’m running OH 2.3.0 snapshot 1208, and I see ESH at version 0.10.0.201801231340. 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.

5iver · February 13, 2018, 10:43pm

@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.

Kai · February 13, 2018, 10:52pm

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.

stefan.hoehn · March 3, 2018, 8:03pm

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/menu.sh: line 171: openhab2_stable_setup: command not found
   /opt/openhabian/functions/menu.sh: line 172: openhab2_unstable_setup: command not found

Do you have any ideas?

Thanks in advance
Stefan

stefan.hoehn · March 3, 2018, 9:16pm

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 http://openhab.jfrog.io/openhab/openhab-linuxpkg 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…

job · March 4, 2018, 12:49am

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.

From the Eclipse Smarthome homepage:

ACCEPT THE DIVERSITY
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.