openHAB 4.1 Milestone discussion

Just installed the latest OH 4.1.M4 Milestone and I am having an issue with some Zigbee Things wherein my battery operated Zigbee shades(IKEA) are stuck as UNKNOWN after at least 10mins waiting for them to go ONLINE. My wired Zigbee devices (Inovelli) switches are recognized and go ONLINE without any problems. This is first 4.1 Milestone/snapshot I have evaluated so I can’t say if this issue has existed in prior 4.1.x versions. I am currently running 4.0.4, which was progressively updated from 4.0.0, 4.0.1, 4.0.2, etc., and have not had any issues with any of my Zigbee devices. Reading through all of the Milestone release notes nothing jumps out at me regarding any changes to Zigbee. Am I missing something, or is this a known issue?

Yes, of course, sorry. Therefore is no binding in use. The value is calculated via rule.

strom.items

Group gGesamtPVSelbstverbrauch_Chart
Number:Energy GesamtPVSelbstverbrauch "PV-Selbstverbrauch [%,.1f kWh]" (gGesamtPVSelbstverbrauch_Chart) {unit="Wh"}

rrd4j.persist

 gGesamtPVSelbstverbrauch_Chart* : strategy = restoreOnStartup, everyMinute, everyChange
 GesamtPVSelbstverbrauch : strategy = restoreOnStartup, everyMinute, everyChange

The 2nd line wasn’t present. I added it to check if something changes, but there was no difference.

Until M3 there was no problem. I don’t know, if it happens to other items, as they “restore” their values form their bindings.

No clue really, but you can try to configure your persistence via UI instead of using files.

I’m having a similar problem only my Peanut plug smart plugs are also coming up as UNKNOWN. A wall switch and two smart plugs from another brand are working just fine.

In the logs I see a bunch of errors that are new to the M4 milestone during startup.

2023-12-05 07:24:56.238 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: Cannot invoke "com.zsmartsystems.zigbee.zcl.clusters.ZclPowerConfigurationCluster.getAttribute(int)" because "this.cluster" is null
        at org.openhab.binding.zigbee.internal.converter.ZigBeeConverterBatteryVoltage.getChannel(ZigBeeConverterBatteryVoltage.java:125) ~[?:?]
        at org.openhab.binding.zigbee.internal.converter.ZigBeeChannelConverterFactoryImpl.getChannels(ZigBeeChannelConverterFactoryImpl.java:82) ~[?:?]
        at org.openhab.binding.zigbee.discovery.ZigBeeDiscoveryService$2.run(ZigBeeDiscoveryService.java:248) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:840) [?:?]

It’s always that ZigbeeConverterBatteryVoltage and all the devices that do not work do indeed have a voltage Channel and the ones that work do not.

I never fully understood why the PeanutPlugs had these channels as it doesn’t actually publish anything to them. But the channels are there.

Noticed this was not highlighted in the release notes for OH4.1M4, but for Z-Wave the PR that added the command class needed for 700 chip controllers to deal with device communications was added. It would be good to get some community testing (just in case :wink:).

2 Likes

I made a small test setup on windows with M3 and M4. There is no difference between text based and UI based config. Also there is no difference between windows and linux (openhabian).
For the test I created a switch item with rrd4j persistence. Strategies: everyChange and restoreOnStartup.
After restarting openHAB in M3 the state is restored, in M4 the state is NULL.

I’ve just installed a brand new 4.1.0.M4 to simulate a newbie. Here are my findings:

  1. Installation was quick and easy
  2. When opening the browser a “developer sidebar” appeared. But it is not translated (at least into portuguese). How can I help translate it ?
  3. I think that, instead of showing a “developer sidebar” (this will scare newbies), it would make more sense to have a wizzard to guide through the first steps
    a) ask what lamps, relays, dimmers, etc (if any) the user wants to connect, and list the supported brands. This would install bindings
    b) then ask the user to watch the inbox for detected devices and pick the ones he wants to add. This would create things
    c) show a skeleton model and assist the user into building equipments (in available locations) and assigning channels to these equipments. This would create items
    d) finally tell the user to open the location, equipment and property tabs to see the results of this initial parametrization

Thanks for your feedback, but your number 3 is not really Milestone related but more a wish list.
Some of your suggested stuff might become reality soon …

3 Likes

I did a bit of digging and found that on Nov 20 @chris made changes to the Zigbee binding.

  1. Remove deprecations from battery voltage converter (#814) (commit: 30e60c5) (details / githubweb)

Given that we are seeing issues with devices that have batteries and/or voltage channels I’m wondering if that might not be the root cause for the problem we are seeing in 4.1M4?

1 Like

Can you please try if restoreOnStartup works using another persistence service?
I would recommend MapDB - Persistence Services | openHAB because MapDB does not require any service configuration, just a .persist file.

Do you see that the value is persisted in RRD4j (does it appear in the analyzer/graph)?

This way we can find out whether this is something related to RRD4j or a general issue.

FYI, just for completeness I’ll post the link to the issue I filed.

OH 4.1 M4 Devices with a voltage Channel remain unknown: this.cluster is null · Issue #816 · openhab/org.openhab.binding.zigbee (github.com)

1 Like

I updated to M4 and have no issues since now.

The only problem I have is that when I am navigating in the MainUI page between the location and equipment pages doing some control the view is jumping back randomly.
This means that when I am at the location page and controlling lights the view is jumping back to the page view I have been before. It happens with every browser. And I think I have this problem since I updated to OH4.
It happens not always. And I can not really reproduce the problem.
Is anyone else having similar issues?

1 Like

Yes, I did see this in M3 and M4. Already opened an issue:

2 Likes

I can confirm it happens also on my openHAB 4.1.0.M4.

I tested with MapDB and restoreOnStartup works.

The state of the item is written to the database. Analyze is working. Only the restore does not happen.

It seems that the problem exists “only” with rrd4j.

Upgraded from M3 to M4 this am and had a similar problem with restoreOnStartup from RRD4j. Item values were not restored and dozens of rules bombed with NULL values. Most if not all were “artificial” items. For example, I count the number of lights, so I created items for each light fixture in the house, initialized them to zero and then if a three light fixture is “ON” it goes to 3, off back to ‘0’. I also count the number of watt reports from my devices in a similar manner. Lastly I have some calculated averages as items that wouldn’t work. I had to reinitialize them to zero again to get things working. This has not happened before on an upgrade. All is fine now (I think :wink:). Although I was going to try a restart to see if it was just the upgrade process.

I had simillar problem long time ago :slight_smile:

and moved to MapDB all my item that should be restored after startup.
Actually I use two persistence services:

  • Influx DB for all items with historical data
  • MapDB for all items that should be restored after startup

Maybe it is not related but may help someone.

Regarding restore on startup with rrd4j, I can tell I found no change in rrd4j add-on at all in OH 4.1. If it does no more work, it is probably due to a change in core framework.
@J-N-K @laursen : do you think it could come from recently added feature about persisting data in future?

Leave it. :wink: I restarted multiple times. It is not an update problem. It is a problem of M4. My tests confirmed that. The productive machine is back on M3.

I never had problems with rrd4j since OH2. Somehow the time comes to think about a change. Thanks for the hint.

Thanks for the info :smiley:

So I’ll get null again? I thought it might be the clean-cache during an upgrade somehow. I guess I’ll leave for now (on M4), but get Mapdb as the restore on startup configured. Earlier in the year I separated the restoreOnStartup to RRD4j for numbers and ON/OFF and MapDB for Dates and images. I use RRD4j for graphs.