openHAB 3.3 Release discussion

I don’t thing ther’e was any change to GoogleTTS between M7 and final release.
Could you check that the problem is not in your (Python) rule engine ?
Just try the say command in the console to see if GoogleTTS is working or not.

It was not me.

In version openHABian 3.2. (it was a totally new installation) everything was fine, then I did the Upgrade to 3.3 and these 3 devices have been disabled, by … the Upgrade (?)

In the MainUI, i wasnt able to set the parameter correctly (only on/off = 0 and 1 i guess), was manually only possible in the Yaml section.

After the first manual correction … now the configuration sets correct the parameters (true/false) in the yaml section. Strange but it works :kissing_smiling_eyes:

Hmmm… perhaps I have the same issue, because there are some “Init” rules, that are not executed anymore, if the openhab is restarted. Where I could find information about log files of openhab/openhabian? /var/log/openhab/openhab.log do not show any information about startlevel?!

UPDATE: Perhaps I found the problem in this log. There are Netatmo-Things that are invalid (I could not delete them via GUI: State changed to REMOVING, but nothing happens. How can I drop this 3 Things) and there are some errors in Blockly rules (I will check this later).

If you click again on delete the thing can be forefully deleted

2 Likes

openhab> voice ttsservices                                                                                                                                                                          
* Google Cloud (googletts)

openhab> voice voices
  Google Cloud - Afrikaans (South Africa) - af-ZA-Standard-A (googletts:afZAStandardA)
  Google Cloud - Arabic (XA) - ar-XA-Standard-A (googletts:arXAStandardA)
   ..
  Google Cloud - Vietnamese (Vietnam) - vi-VN-Wavenet-D (googletts:viVNWavenetD)

openhab> voice say test
An unexpected error occurred during execution.

and in the log I get:


2022-06-29 11:06:06.404 [DEBUG] [.googletts.internal.GoogleTTSService] - Synthesize 'test ' for voice 'googletts:deDEWavenetC' in format AudioFormat [codec=PCM_SIGNED, container=WAVE, bigEndian=true, bitDepth=16, bitRate=705600, frequency=44100channels=1]
2022-06-29 11:06:06.411 [DEBUG] [lient.internal.OAuthStoreHandlerImpl] - Decrypting token: AccessTokenResponse [accessToken=LdEWmHAg7GjsYW8XBtoBIWPo7Y1oW3lX4tWVbxkZUw4yzxsrVPhAm2YJHEyB3vvO9mK3h6RJ26OCCfGz5lhZ6j4nmHIyiRkv/GNKdeK7yey85xsMRaPfK6Fd48a+5rQh17Iamybo1ZvC8Xlb5YAfCrmCN0Mx/Ziu1D7cMLKl8iKqvlXa5x3PL8TtQyrCILUWG/AebJ7WmWETjwDJ0Gt1+Zj73By8G4O6PEOHQ+hZfiMlA8l3CCayCNvABy0RqxQP, tokenType=Bearer, expiresIn=3461, refreshToken=null, scope=https://www.googleapis.com/auth/cloud-platform, state=null, createdOn=2022-06-28T17:53:33.196313]
2022-06-29 11:06:06.612 [ERROR] [b.core.io.console.ConsoleInterpreter] - An error occurred while executing the console command.
java.lang.NullPointerException: null
	at org.openhab.voice.googletts.internal.GoogleCloudAPI.synthesizeSpeechByGoogle(GoogleCloudAPI.java:456) ~[?:?]
	at org.openhab.voice.googletts.internal.GoogleCloudAPI.synthesizeSpeech(GoogleCloudAPI.java:356) ~[?:?]
	at org.openhab.voice.googletts.internal.GoogleTTSService.synthesize(GoogleTTSService.java:335) ~[?:?]
	at org.openhab.core.voice.internal.VoiceManagerImpl.say(VoiceManagerImpl.java:241) ~[?:?]
	at org.openhab.core.voice.internal.VoiceManagerImpl.say(VoiceManagerImpl.java:176) ~[?:?]
	at org.openhab.core.voice.internal.VoiceConsoleCommandExtension.say(VoiceConsoleCommandExtension.java:246) ~[?:?]
	at org.openhab.core.voice.internal.VoiceConsoleCommandExtension.execute(VoiceConsoleCommandExtension.java:112) ~[?:?]
	at org.openhab.core.io.console.ConsoleInterpreter.execute(ConsoleInterpreter.java:57) [bundleFile:?]
	at org.openhab.core.io.console.karaf.internal.CommandWrapper.execute(CommandWrapper.java:77) [bundleFile:?]
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [bundleFile:4.3.7]
	at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [bundleFile:4.3.7]
	at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [bundleFile:4.3.7]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]

Both org.openhab.core.auth.oauth2client and org.openhab.voice.googlettsare set to TRACE

However, I get this now with M7, too

Update:

After seeing the failure on M7 this morning I did a restart, generated a new authCode, put that in and voice say test worked again from console.
So I re-installed 3.3.0-1, starting up googletts did not work, so generated a new authCode, put that in and voice say test worked again from console.
Thus, my impression that the released version comes with completly broken googletts was wrong.
Still, the outh2 authentication appears to be super fragile and the process to renew it with copying the authCode from the address line feels clumsy, to put it mildly.

I’m not 100% certain if the error which I now keep getting when opening the Apple Watch App upon launch ("Request explicitly cancelled") is related to my upgrade from 3.2 to 3.3, but if others have the same issue, feel free to contribute to the thread here.

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: