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