openHAB 3.3 Release discussion

Z0l · June 29, 2022, 11:18am

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.

Lolodomo · June 29, 2022, 11:44am

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.

github.com

openhab/openhab-addons/blob/main/bundles/org.openhab.voice.googletts/src/main/java/org/openhab/voice/googletts/internal/GoogleCloudAPI.java#L456

      
        
                        .withContent(gson.toJson(request), MimeTypes.Type.APPLICATION_JSON.name());
            
            
    try {
                    SynthesizeSpeechResponse synthesizeSpeechResponse = gson.fromJson(builder.getContentAsString(),
                            SynthesizeSpeechResponse.class);
            
            
        if (synthesizeSpeechResponse == null) {
                        return null;
                    }
            
            
        byte[] encodedBytes = synthesizeSpeechResponse.getAudioContent().getBytes(StandardCharsets.UTF_8);
                    return Base64.getDecoder().decode(encodedBytes);
                } catch (JsonSyntaxException e) {
                    // do nothing
                } catch (IOException e) {
                    throw new CommunicationException(String.format("An unexpected IOException occurred: %s", e.getMessage()));
                }
                return null;
            }
            
            
/**

rubens · June 29, 2022, 12:15pm

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.

fnu · June 29, 2022, 12:16pm

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.

fnu · June 29, 2022, 12:30pm

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

mhilbush · June 29, 2022, 12:49pm

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.

github.com/openhab/openhab-addons

[nest] Fix for missing refresh token after reauthorization

openhab:main ← mhilbush:nest-refresh-token

opened 02:30PM - 10 May 22 UTC

mhilbush

+15 -5

By default, the Google OAuth API returns the refresh token only on the first aut…horization. On subsequent authorizations using the same Client ID and Secret, Google does not return the refresh token in the access token response. This causes the binding to fail on the first refresh of the access token after a reauthorization. This affects the SDM and Pub/Sub APIs. However, the failure is more spectacular with the Pub/Sub API as it causes the binding to repeatedly do a pub/sub request against the Google API every 20-40 msec. This PR adds a new query parameter (prompt=consent) to the URL used to get the authorization code. This parameter causes Google to always return the refresh token in the authorization response (via `oAuthService.getAccessTokenResponseByAuthorizationCode`). In addition, this PR adds checks to make sure the refresh token in present in the access token response in order to fail more quickly and gracefully if the refresh token is missing. Further details of my analysis are here. https://community.openhab.org/t/nest-binding-throwing-pub-sub-errors-repeatedly/135721 I know @wborn is pretty time-constrained right now, but I'm hopeful he can find a few minutes to review. 😉 Signed-off-by: Mark Hilbush <mark@hilbush.com>

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.

rubens · June 29, 2022, 1:25pm

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.

mhilbush · June 29, 2022, 1:36pm

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.

Lolodomo · June 29, 2022, 3:06pm

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

github.com/openhab/openhab-addons

Google add-ons use deprecated OAuth out-of-band (flow)

opened 11:37AM - 10 Mar 22 UTC

closed 08:39PM - 12 Apr 22 UTC

wborn

bug

Some add-ons using Google APIs still use the deprecated OOB flow. It is no longe…r possible to create new Google OAuth tokens using the OOB flow since February 28th. See: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html#disallowed-oob As a result it is no longer possible to setup the following add-ons: * Google Cloud Text-to-Speech * Google Cloud Speech-To-Text * Nest Binding These need to be changed to use one of the other flows.

openhabgs · June 29, 2022, 3:22pm

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”]]}

ysc · June 29, 2022, 5:07pm

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.

OMR · June 29, 2022, 9:52pm

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)

J-N-K · June 29, 2022, 9:58pm

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.

OMR · June 29, 2022, 10:13pm

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 …

randomname · June 30, 2022, 6:26am

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.

Lolodomo · June 30, 2022, 6:36am

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

Lolodomo · June 30, 2022, 6:48am

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

github.com/openhab/openhab-core

Fix SSE topic filters

openhab:main ← J-N-K:bug-ssetopicfilter

opened 09:43PM - 29 May 22 UTC

J-N-K

+7 -3

Fixes #2473 According to the [documentation](https://www.openhab.org/docs/de…veloper/utils/events.html), topic filters are regular expressions. The SSE topic filters are converted to regular expressions, therefore `openhab/items/*/state` should result in `openhab/items/.*/state`. The code however adds a `.*` at the end `openhab/items/.*/state.*`. This makes it impossible to filter for `/state` but exclude `/statechanged`, which is IMO expected. Signed-off-by: Jan N. Klug <github@klug.nrw>

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

randomname · June 30, 2022, 8:34am

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

Matthias_Kaufmann · June 30, 2022, 9:00am

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

AndrewFG · June 30, 2022, 12:11pm

Could it be this issue?

github.com/openhab/openhab-core

During OH version upgrades, binding JAR files already in the Addons folder are not picked up

opened 11:21AM - 28 Jun 22 UTC

andrewfg

### Issue When upgrading from one OH version to another (e.g. from v3.2 to v3….3) any binding JAR files (for test versions of bindings) that had been manually dropped in the Addons folder under the prior version (e.g. v3.2) are not automatically picked up (i.e. not installed) during the upgrade process from the prior version (e.g. v3.2) to the newer version (e.g. v3.3). ### Work-around You have to delete such JAR files from the Addons folder and then drop them again in the Addons folder. This causes OH to pick them up and install them in the normal way. ### Solution During a version upgrade process, the OH core should detect binding JAR files in the Addons folder, and install them as if they had been newly dropped in the Addons folder.