openHAB 3.3 Release discussion

Hello, just wanted to let everyone know that my Openhab 3.2.0 → 3.3.0 upgrade (I’m using Docker) was completed without any errors, hiccups or annoyances at all. This is the first time I had nothing to do (no rule rewrites or redefining things/items) so just wanted to put a big thank you out there for the great work the developers have put into this.

On 3.2.0, I had some issues with jupnp so I had to add some additional configuration on timeouts/retries to make my Sonos speakers work; I haven’t removed that but I will check if those are still needed on 3.3.0. and report separately.

2 Likes

Ok, I think I saw several topics in the forum about google stuff no more working due to changes in way to suthenticate.

The last change in this binding is dated 12th of April.

The NPE at this line is because synthesizeSpeechResponse.getAudioContent() is not tested, So at least this NPE could be avoided in favor of a more appropriate error.

Thanks for looking into it.

Yes, this was in M7 already. I figured how to get it with google but it’s clumsy (copy authCode from addressline of browser, edit the code 4%2F → 4/ ) and authentication seems fragile so I’m forced to repeat that quite often.
Frankly, that part doesn’t feel Ready.

I posted an update to my former post: in a nutshell I see now that M7 and 3.3.0-1 behave quite alike.

1 Like

Hi there,

updated my openhabian using “openhabian-config”. Installation was quite fresh, I did start over 2 month ago from a newly written microSD card, just restoring my files from /etc/openhab/*

I stopped openhabian services before requesting update, cleaned cache, then reboot. Now I can’t see my things in PaperUI and just see continously that message in log viewer:

2022-06-29 14:06:30.012 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:06:45.016 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:07:00.019 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:07:15.023 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:07:30.027 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:07:45.030 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:08:00.034 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:08:15.037 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

2022-06-29 14:08:30.041 [INFO ] [core.karaf.internal.FeatureInstaller] - Some .kar files are not installed yet. Delaying add-on installation by 15s.

Ok, strange, another graceful restart did solve that issue, stop openhab.service, clean cache, reboot …

Not sure of it’s relevant here, but I ran into an issue with reauthorizations after the first auth is a problem because the refresh token is returned only after the first authorization. The net effect is that it works until the access token needs to be refreshed (about an hour), then it breaks.

I pushed this change for the nest binding, but may be relevant for Google TTS, too. Note the addition of &prompt=consent to the URL.

Edit: I should note that this problem drove me absolutely crazy for days. I would do a reauth, then it would work for a while, then it would break. Rinse and repeat. Finally figured it out.

Thanks! Looks like it might be relevant indeed.
There is a line with the values of the decrypted token in the log and I had noticed it always showed refreshToken=null,
Using the &prompt=consent parameter in the uri when requesting the authCode results in a token which does have a value there.

Let’s see if this results in a more stable behavior.

Yep, a null refresh token in the log is a definite indicator of the problem.

If that’s it, we’ll need an update to the Readme to include the change to the authorization url.

And maybe a change to the code to complain if the refresh token is null.

There was an issue but it is now closed. Don’t know if expected.

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.

3 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