openHAB 3.3 Release discussion

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)?

Related to “Handler” issues with Zwave devices: Check the Zwave database for your device and go to the parameter tab. Most of the problems I see reported are with devices that are flagged with “Limit to Options” set to “true” (red funnel), BUT where not all the options allowable between the minimum and maximum are listed. The solution is to either switch the “limit to Options” flag to “false” or to add to the “options” at the bottom of the page.

For instance parameter 2 on this device can only be “0” even though the max is 255.


Hope this helps.

Bob

2 Likes

Do these number starting Items appear in Settings → Items? If so, delete the Items there and then recreate them with new names that do not start with a number (there is no such thing as renaming an Item in OH).

If they do not appear there I’m going to assume that they also do not get returned by the REST API. But on the chance that they do, go to Developer Tools → API Explorer and run a query for one of the numbered Items using the items REST API endpoint. If something is returned then you can use the delete REST API endpoint to delete it. Then recreate the Items normally, this time not starting the name with a number.

If you can’t do that you can just ignore the fact that these Items ever existed and just create new Group Items with allowed names and ignore the fact that the wrong ones are still there.

If you really want to clean this up, stop openHAB. Then go to $OH_USERDATA/jsondb. Search through all the files there for all instances of one of these number starting Items and replace it with a different name that doesn’t start with a number. Then restart openHAB. It’s really easy to mess something up editing the JSONDB file manually so be careful and take backups.

2 Likes

@Kai can you add this note as breaking change openHAB 3.3 Milestone discussion - #60 by ssalonen

As I am relatively new with OH I haven’t done upgrades earlier. So, what is the best strategy to upgrade from 3.2 to 3.3?

I would read the release notes here Release openHAB 3.3.0 · openhab/openhab-distro · GitHub first. If you don’t want to read the whole thing, at least read the Breaking Changes section.

Then take a backup, mine is on a computer that runs debian so I just run “sudo openhab-cli backup” to do this.

Then upgrade. Usually there aren’t any issues, but if you have serious ones you can revert to 3.2 and then restore your backup.

2 Likes

Great, many thanks for your advise.

I tried @openhabgs 's code editing suggestion (thanks!) and found it does persist across restarts. Luckily the “invalid” values are ones I don’t use, so to me it doesn’t matter what they are set to. The only issue I’ve noticed is you get messages in the log complaining about applying an invalid configuration (the old values before you edited the code). But the device still works fine.

2022-06-30 17:11:59.602 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=config_11_1; type=BigDecimal; value=0}, {key=group_5; type=EmptyList; value=[]}, {key=group_4; type=EmptyList; value=[]}, {key=group_1; type=EmptyList; value=[]}, {key=group_3; type=ArrayList; value=[controller]}, {key=group_2; type=ArrayList; value=[controller]}, {key=config_2_1; type=BigDecimal; value=0}, {key=config_7_1; type=BigDecimal; value=-2}, {key=config_8_1; type=BigDecimal; value=3}, {key=config_9_1; type=BigDecimal; value=3}, {key=config_3_1; type=BigDecimal; value=0}, {key=config_4_1; type=BigDecimal; value=-69}, {key=config_5_1; type=BigDecimal; value=-85}, {key=config_6_1; type=BigDecimal; value=-1}, {key=node_id; type=BigDecimal; value=37}]' on thing 'zwave:device:daf3e8da:node37' blocked. This is most likely a bug: {config_7_1=The value -2 does not match allowed parameter options. Allowed options are: [ParameterOption [value="254", label="Default (0xFE)"]], config_4_1=The value -69 does not match allowed parameter options. Allowed options are: [ParameterOption [value="187", label="Default (0xBB)"]], config_5_1=The value -85 does not match allowed parameter options. Allowed options are: [ParameterOption [value="171", label="Default (0xAB)"]], config_6_1=The value -1 does not match allowed parameter options. Allowed options are: [ParameterOption [value="255", label="Default (0xFF)"]]}
1 Like

Thanks for pointing this out. I had gone back to openHAB 3.2, and restored my backup, but now I’ve upgraded to 3.3 again and edited the device code to get me by as @openhabgs suggested. On my 2nd upgrade attempt this mimolite device was the only one that caused me trouble. I removed the z-wave snapshot binding before upgrading this time so I think that may be why it went better.

Anyway, I got access for the database from Chris and edited those parameters so they match the technical guide (which was helpfully attached in the database as well). So this should be fixed (for this one device) in openHAB 3.4.