openHAB 3.3 Release discussion

All,
regarding the ZWAVE problem resulting in this error message: “zwave HANDLER_CONFIGURATION_PENDING”, I found an easy way to fix it in the UI.
I had this (german) error message:


then I went in to the “code” section of the thing where I changed the entry from the error message:

and - voila - the thing is online again.

And for further bugfixing, these are the log messages:

2> 022-06-29 17:37:03.839 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration ‘Configuration[{key=config_10_1; type=BigDecimal; value=10}, {key=wakeup_interval; type=BigDecimal; value=3600}, {key=group_1; type=ArrayList; value=[controller]}, {key=binding_pollperiod; type=BigDecimal; value=3600}, {key=group_2; type=ArrayList; value=[controller]}, {key=config_111_2; type=BigDecimal; value=10}, {key=config_112_1; type=BigDecimal; value=5}, {key=config_100_1; type=BigDecimal; value=1}, {key=config_110_1; type=BigDecimal; value=0}, {key=config_101_4; type=BigDecimal; value=7200}, {key=wakeup_node; type=BigDecimal; value=1}, {key=config_102_4; type=BigDecimal; value=0}, {key=config_113_2; type=BigDecimal; value=150}, {key=config_114_1; type=BigDecimal; value=10}, {key=config_12_1; type=BigDecimal; value=10}, {key=config_103_4; type=BigDecimal; value=300}, {key=config_13_2; type=BigDecimal; value=5}, {key=config_14_1; type=BigDecimal; value=0}, {key=config_104_4; type=BigDecimal; value=86400}, {key=config_15_1; type=BigDecimal; value=1}, {key=node_id; type=BigDecimal; value=6}]’ on thing ‘zwave:device:Z-Wave-Controller:node6’ blocked. This is most likely a bug: {config_101_4=The value 7200 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disabled”]], config_12_1=The value 10 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disabled”]], config_104_4=The value 86400 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disabled”]]}

2 Likes

The API Explorer doesn’t support SSE endpoints.

This is the state update SSE endpoint, not the general events SSE which is /rest/events.

For the record, here’s how the state update SSE endpoint works: when you receive that initial ready event, you have to do a HTTP POST to /rest/events/states/{connectionId} with {connectionId} being the GUID that you receive as data for the ready event. In that POST request (this one you can perform with the API Explorer) you also have to specify an array of item names you’re interested in. Then you will begin to see events appearing on the /rest/events/states response when the specified items’ states get updated.

2 Likes

Just updated from 3.3.0M8 to 3.3.0 and had to manually start a bunch of bundles in karaf that were stuck in Resolved and not Active …
Besides from that, things looks OK. (10min after)

Did you try a second start before manually starting the bundles? I have sometimes seen a similar issue in the past, but only on first starts, never on second or later.

Yes, even tried a power-cycle, but I might have been a bit inpatient when pulling the plug, but that was after it had done 2 softrestarts just after the upgrade.
I too have experienced this once a year or so ago, so I knew what to do … :slight_smile:

I’m the maintainer of the node-red-contrib-openhab3 package which is a plugin for Node-RED. This plugin can be used as an alternative to openHABs built-in rules module, which I personally use and prefer.
After the openHAB 3.3 RELEASE it was pointed out to me that there was an error with the plugin (still worked for openHAB 3.2). I had to change two things to get it working again:

  • For receiving updates the plugin makes use of the ServerSent Events connection. I had to change the url from /rest/events?topics=openhab/items to only /rest/events to keep receiving events.
  • For the interactions with the /rest/items endpoint, I wasn’t sending an Accept header. I modified my code to send the Accept: application/json header. That helped.

Maybe sharing this helps others who also rely upon the openHAB rest api.

4 Likes

Did you try with /rest/events?topics=openhab/items/*/* ?

Here is why your request was no more working, I believe:

With the correct topic syntax, it should work, see my previous message.

1 Like

Thank you for referencing the actual change that caused this. That explains why it broke for my plugin usage of that topics filter. Because I also “filter” after receiving the event, and also want to receive all of the events anyway, I’m fine with using no topics filter at all. I think in the end that’s more future proof :slight_smile:

1 Like

Dear all,

I also got a new problem that might (or might not) be linked to the REST API regarding the integrated tabs: OH 3.3 Integrated tabs not working

Best

Could it be this issue?

1 Like

Could be related, but I have no side-dropped JARs at the moment.
This is the list that was all Resolved, not Active: All I did was start them one by one …

235 │ Active │  80 │ 5.9.0                  │ jna-platform
236 │ Active │  80 │ 1.6.2                  │ JavaMail API
237 │ Active │  80 │ 1.0.1                  │ IO.Socket Engine Client
238 │ Active │  80 │ 1.0.1                  │ IO.Socket Socket Client
239 │ Active │  80 │ 20180813.0.0           │ JSON in Java
240 │ Active │  80 │ 5.2.1.OH1              │ nrjavaserial
241 │ Active │  80 │ 3.7.2                  │ Apache Commons Net
242 │ Active │  80 │ 3.8.1.1                │ Apache ServiceMix :: Bundles :: okhttp
243 │ Active │  80 │ 1.13.0.1               │ Apache ServiceMix :: Bundles :: okio
244 │ Active │  80 │ 2.0.0                  │ Californium (Cf) Core
245 │ Active │  80 │ 2.0.0                  │ Californium (Cf) Element Connector
246 │ Active │  80 │ 2.0.0                  │ Californium (Cf) OSGi
247 │ Active │  80 │ 2.0.0                  │ Scandium (Sc) Core
248 │ Active │  80 │ 2.6.1                  │ JUPnP Library
249 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Automation :: JSScripting
250 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Astro Binding
251 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Automower Binding
252 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Daikin Binding
253 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Dresden Elektronik deCONZ Binding
254 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Denon / Marantz Binding
255 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: HarmonyHub Binding
256 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Kodi Binding
257 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Mail Binding
258 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Nanoleaf Binding
259 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Network Binding
260 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Onkyo Binding
261 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: SamsungTV Binding
262 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Shelly Binding
263 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: SqueezeBox Binding
264 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Systeminfo Binding
265 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: TRÅDFRI Binding
266 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: ZWave Binding
267 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Configuration UPnP Discovery
268 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery
269 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery for Linux using sysfs scanning
270 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Configuration USB-Serial Discovery using ser2net mDNS scanning
271 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Configuration Serial
272 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Serial Transport
273 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Serial Transport for RXTX
274 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: Serial Transport for RFC2217
275 │ Active │  80 │ 3.3.0                  │ openHAB Core :: Bundles :: UPnP Transport
276 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: IO :: openHAB Cloud Connector
277 │ Active │  80 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Persistence Service :: InfluxDB
278 │ Active │  75 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Transformation Service :: JavaScript
279 │ Active │  75 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Transformation Service :: JSonPath
280 │ Active │  75 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Transformation Service :: Map
281 │ Active │  75 │ 3.3.0                  │ openHAB Add-ons :: Bundles :: Transformation Service :: RegEx
282 │ Active │  80 │ 3.3.0                  │ openHAB UI :: Bundles :: Basic UI
283 │ Active │  80 │ 3.3.0                  │ openHAB UI :: Bundles :: HABPanel UI

You don‘t know by chance which bundles didn’t start?

I had this same issue with my Z-Wave devices. Initially it affected the following devices for me:

  • Everspring ST812 flood sensor (x1)
  • Kwikset 914TRL lock (x1)
  • GED1800 lock (x3)
  • Honeywell TH6320ZW thermostat (x3)
  • Fortrezz Mimolite (x2)

I was going to roll back to 3.2 but then I remembered in the openHAB 2.x days I would have to restart it 4 or 5 times after an upgrade for everything to work properly (but openHAB 3 has not had this issue for me until now). So I restarted openHAB 3 times (I gave it about 5 minutes between restarts and made sure the logging had died down before restarting) and after the 3rd restart, everything fixed itself except the Mimolite. I restarted another 3 times (left it alone for 11 hours before the latest restart) but the Mimolite is still not working.

I saved the error messages and the thing code from the time of the error if anyone is interested in looking at it. The thing code definitely changed after the restarts.

One wrinkle here is that when openHAB 3.2 was released, my thermostats didn’t work, and I had to install the Z-wave binding snapshot from 3.3 manually (uninstall the binding in the gui, then put the jar in the addons folder) to fix it. More info on that here openHAB 3.2 Release discussion - #80 by poisonsnak . Then when I upgraded to openHAB 3.3 last night, I did the upgrade, noticed errors in the log about the snapshot binding, stopped openHAB, deleted the jar from the addons folder, started openHAB again, and then reinstalled the binding in the GUI. I’m not sure if that has anything to do with these issues.

edit: I just rolled back to 3.2 with the z-wave 3.3.0 snapshot binding (from December?) and everything is working again. I compared the code from the mimolite Thing before and after and it’s identical. So I guess it’s the validation in 3.3 that isn’t working properly.

It looks like you can’t have groups in your model that start with a number any more. I set my model up with a group called “indoor” for my house, then sub groups called “B1”, “1F”, and “2F” for each floor. Since upgrading to 3.3, 1F and 2F have disappeared from my model and I see errors like this in openhab.log every time it starts


2022-06-29 22:14:27.500 [WARN ] [ore.common.registry.AbstractRegistry] - Cannot add "GroupItem" with key "1F": The specified name of the item '1F' is not valid!
java.lang.IllegalArgumentException: The specified name of the item '1F' is not valid!

with a couple of screens of java error text afterward. I can post that if anyone wants to see it.

It’s never been allowed to name any Item starting a number. This has been in the docs since at least 2.5 (we don’t have archived docs that go back farther than that) but I think it’s been the case since the very beginning of OH.

The only characters permitted in an Item name are letters, numbers and the underscore character. Names must not begin with numbers. Spaces and special characters are not permitted.

There is a technical reason why this causes problems internally that I don’t remember. It is only in the last few months though where it’s being enforced.

2 Likes

Ah good to know, thanks for the quick response. It’s too bad the GUI didn’t warn me when I set them but maybe that’s been addressed in 3.3 as well. I’ll probably roll back to 3.2 anyway to get my Z-Wave Mimolite devices working again, so once I do I will rename them and then I should be ready for the upgrade.

Thanks for this suggestion! Do note however that you’re forced to change your color temperature here to get the thing online.

For a color temperature this might not be so bad, but I have another bulb where the ‘factory reset’ option is the problematic one, and it is only accepted to be ‘on’, not ‘off’ …

Btw, does your change persist across OH restarts?

Yes, all in the list above.

Hi Rich,

I migrated to OpenHAB 3.3 yesterday. The migration was flawless except my semantic model was mixed up. It is caused by the enforcement of items starting with numbers - the floors in my house are called 1st en 2nd floor in the semantic model. an intuitive name but not permitted now.

In my openhab log I receive errors pointing to this.

I can not change the names in the semantic model. Can you help me how to solve this (rename the items to first and second floor)?