Unit-Support, KNX 2, Karaf 4.1.5 Upgrade and more!

For all users, it is now confirmed that most of the items for the Yahoo weather and WU weather bindings have to be updated to be compatible with the new snapshot.
The documentation for these bindings has to be updated.

@Dries confirmed!!

Updated today to openHAB 2.3.0 Build #1231 and all my rules stopped working :flushed:

I could reduce it now to this line:

val lastItem = Windows.members.sortBy[lastUpdate].last

2018-03-17 18:45:44.151 [ERROR] [af.features.internal.service.BootFeaturesInstaller] - Error installing boot feature repository mvn:org.apache.karaf.features/framework//4.1.5/xml/features
java.io.IOException: Error resolving artifact org.apache.karaf.features:framework:4.1.5:xml:LATEST : mvn:org.apache.karaf.features/framework//4.1.5/xml/features
        at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:91) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.loadRepository(FeaturesServiceImpl.java:480) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:496) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.service.FeaturesServiceImpl.addRepository(FeaturesServiceImpl.java:491) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.service.BootFeaturesInstaller.installBootFeatures(BootFeaturesInstaller.java:98) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.service.BootFeaturesInstaller.start(BootFeaturesInstaller.java:87) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.features.internal.osgi.Activator.doStart(Activator.java:273) [10:org.apache.karaf.features.core:4.1.5]
        at org.apache.karaf.util.tracker.BaseActivator.run(BaseActivator.java:242) [10:org.apache.karaf.features.core:4.1.5]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.io.IOException: Error resolving artifact org.apache.karaf.features:framework:4.1.5:xml:LATEST
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:729) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:557) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
        at java.net.URL.openStream(URL.java:1045) ~[?:?]
        at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:86) ~[?:?]
        ... 12 more
Caused by: shaded.org.eclipse.aether.resolution.VersionRangeResolutionException: No highest version found for org.apache.karaf.features:framework:4.1.5:xml:[0.0,)
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolveLatestVersionRange(AetherBasedResolver.java:998) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:703) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:659) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:600) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:567) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:557) ~[?:?]
        at org.ops4j.pax.url.mvn.internal.Connection.getInputStream(Connection.java:123) ~[?:?]
        at java.net.URL.openStream(URL.java:1045) ~[?:?]
        at org.apache.karaf.features.internal.service.RepositoryImpl.load(RepositoryImpl.java:86) ~[?:?]
        ... 12 more

I’m getting this after an upgrade to 1231 of a manual installation. I’m using a home brewed backup/restore script that has worked great previously (1224 was the last upgrade I did). I’m guessing there’s something wrong with my script and I need to compare it to the official ones. But any ideas?

Did your restore add back the files:

userdata/etc/overrides.properties
userdata/etc/org.openhab.addons.cfg

If so, you’ll need to remove them and restart openHAB.

2 Likes

Thank you x5! That was it. My script left those in place. Removing them fixed it.

I had 53 instances of…

[280,107]: mismatched character '.' expecting ']'

… which prevented my rule files from loading. This resolved it (thank you @Udo_Hartmann!), but why?

Hi,

happy about the knx2-binding I converted my installation with ~200 KNX-Items.
It somehow works - but throws endless warnings in this style.
(Even after reducing it to a few testitems only)

2018-03-18 08:19:54.209 [WARN ] [Xnet/IP Tunneling 192.168.10.26:3671] - response timeout waiting for confirmation

tuwien.auto.calimero.KNXTimeoutException: no confirmation reply received for 3.1.101->3.1.23 L_Data.req, system priority hop count 6 repeat, tpdu 80

	at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:244) ~[?:?]

	at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:258) ~[?:?]

	at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:178) ~[?:?]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:243) ~[?:?]

	at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:351) ~[?:?]

	at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:222) ~[?:?]

	at tuwien.auto.calimero.mgmt.TransportLayerImpl.connect(TransportLayerImpl.java:327) ~[?:?]

	at tuwien.auto.calimero.mgmt.ManagementClientImpl.send(ManagementClientImpl.java:796) ~[?:?]

	at tuwien.auto.calimero.mgmt.ManagementClientImpl.sendWait2(ManagementClientImpl.java:824) ~[?:?]

	at tuwien.auto.calimero.mgmt.ManagementClientImpl.readDeviceDesc(ManagementClientImpl.java:447) ~[?:?]

	at tuwien.auto.calimero.mgmt.ManagementProceduresImpl.isAddressOccupied(ManagementProceduresImpl.java:310) ~[?:?]

	at org.openhab.binding.knx.internal.client.AbstractKNXClient.isReachable(AbstractKNXClient.java:338) ~[?:?]

	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.pollDeviceStatus(AbstractKNXThingHandler.java:144) ~[?:?]

	at org.openhab.binding.knx.handler.AbstractKNXThingHandler.lambda$1(AbstractKNXThingHandler.java:184) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]

	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

Any hint?

Every 10 minutes, when the Weather Underground binding updates it’s channels, I’m getting the following errors…

I don’t know if this is expected behaviour or an oversight, but I’m finding that items using an extended item type are not being persisted. When I revert an item back to using a regular item type, I am stuck with the default unit (ie, temps are in Celcius with no way to convert to Fahrenheit). I’m using JDBC MariaDB, but I doubt this is specific to the flavor of persistence I’m using. It’s looking like I will need to downgrade to the 1.x Weather binding or scrape my own data since my rules rely heavily on historical weather data.

That is a good question. Is the new type correctly handled by persistence services.

Thanks a lot for KNX2, just finished the migration, it’s really “another world”… You clearly feel that it’s less amateur in the approach !!!

The migration went absolutely well, I’ve integrated all the lights (almost 40 in my case) and I’ll start now with probes and rules.

THANKS A THOUSAND OF TIME !!!

3 Likes

Agree an update like this it might be possible that persistence isn’t working quite as expected. If lasUpdate is returning null for any of the members that line will fail.

You can filter those out

call lastItem = Windows.members.filter[w | w.lastUpdate != null].sortBy...

Though since you are on the snapshot you should be using Member of and triggering item if you are using this line to find what item triggered the rule. Features for Rules that work with Groups

@rlkoshak I think this is something different. In my case the complete rule-file didn’t work anymore. There was a need to add spaces after [ and before ]:

Does not work:
val lastItem = Windows.members.sortBy[lastUpdate].last

Works:
val lastItem = Windows.members.sortBy[ lastUpdate ].last

But thanks anyway…will update the rules to your suggestion :slight_smile:

1 Like

Add a space after .sortBy.

I’m seeing things like this in my log…

2018-03-18 11:51:31.627 [DEBUG] [atherunderground.handler.WeatherUndergroundHandler] - Update channel current#feelingTemperature with state 6 ℃
2018-03-18 11:51:31.639 [DEBUG] [b.persistence.jdbc.internal.JdbcPersistenceService] - JDBC::store: ignore Item 'Weather_Temp_Feel_F' because it is UnDefType

… but some weather channels are being updated and JDBC doesn’t even try to store the item, so it’s not consistent. Or maybe they just hadn’t changed in value. :thinking:

openhab> smarthome:status Weather_Temp_Feel_F <-- USING EXTENDED
42.80 °F

Is it possible that JDBC is being provided the converted value with a unit? I’ll need to look into the database transactions, if there are any to look at.

Thanks a lot for the new KNX 2 Binding, I hope, that it solves the issues with the old KNX Binding.

Before migrating my existing configuration to the new format a few questions:

  • is there any downside in defining only one generic KNX thing and adding all existing GAs to that thing (I have arround 70 KNX devices with probably more than a thousand GAs)? What is the recomended best practice?

  • Does the KNX thing accepts a label string (like the „generic“ in the examples) in a format like the PA auf the device, e.g. 1.1.10? Would it be a good practice to name the things according to the PA of the devices?

I hope I will find the time to test this out soon, ut I fear, that the migration could easily take several weeks with a limited time budget…

Thanks for your help,
Juelicher

No, it is really up to the user how to structure the things as the KNX system can be treated as a single big thing. The only feature you cannot use then is to map it to a physical address that would be pinged and which would go OFFLINE, if it doesn’t answer anymore - but broken or unreachable devices are usually not a problem with KNX, so that is probably no important feature.

I indeed called mine "KNX-1.1.2" and similar. As I am one of the first users, I wouldn’t call this a good/best practice yet, but it feels quite appropriate to me…

Thanks for the clarification!

To be honest I am a bit afraid of having to convert my KNX configuration, maybe some awk „magic“ might help. This is probably a good opportunity for some cleaning up too…

Thank you for drawing attention to the persistence issue and getting it moving forward. Makes me wonder if PlayerType and ImageType could be added to the compatibility layer, so that items of these types could be persisted as well, rather than waiting for the persistence services to be upgraded to support them.


@mashborn Your logs seem to be caused by the “isReachable” check. There seems to be trouble on some installations with this. I have created https://github.com/openhab/openhab2-addons/issues/3364 in order to further track this. In the meantime as a workaround you can disable this ping by commenting out the address="1.2.3" parameter in your thing configuration in order to get rid of these warnings.

1 Like