openHAB Google Assistant: A new version is released

Dear community,

we have just released a new version of the openHAB Google Assistant integration.
I am very sorry that there was such a long delay after the last one.

As already announced in openHAB Google Assistant: New release with updated device support there are some breaking changes included: namely the removal of tag support. From now on devices that were only exposed by tags will not anymore be available in your Google Assistant. If you miss devices after synchronizing, please check if you use proper metadata.

A full list of changes is attached here:

:warning: Breaking Changes

  • Remove tag support (#194)

:rocket: Features

  • Add separate power switch for specialcolorlight (#215)
  • Support types with dimension (#210)

:bug: Bug Fixes

  • Fix sensor state format (#217)
  • Fix exception when tfa challenge is missing (#211)
11 Likes

Dear community,

another release was just deployed. Thanks to @duanemck, @cromefire and @bccrew for their contributions.

Especially the enhanced security system support includes a lot of interesting new features. Make sure to check out the updated usage documentation.

:rocket: Features

:toolbox: Maintenance

:open_book: Documentation

4 Likes

Dear community,

another release was just deployed.

It mostly contains dependency updates but also one new device type called CHARGER.

:rocket: Features

:toolbox: Maintenance

  • See GitHub :smiley:
1 Like

Dear community,

a new release was just deployed.

:zap: With that a new feature called “generic state validation” is introduced.

This enables you to add the new configuration option checkState=true to your device’s metadata.

When this option is set every command for that device will cause an additional request to the user’s OH instance to get its current state. The state is then compared to the requested one by the command.
Google Assistant should then respond with corresponding error messages when a requested state is already in place. (See the list of various error codes available: Error list)

Important: This change now also requires you to add this config option to SecuritySystem devices. They will no longer by default check the state before firing the arm/disarm command.

:rocket: Features

:toolbox: Maintenance

  • See GitHub :smiley:
3 Likes

Hi @michikrug,

it’s possible that after this update my rollershutter dosen’t work properly anymore?
If I ask to open they close and vice versa.
I’ve tried to add the [ inverted=true ] option to one of my shutter but that made no difference

At least I touched something there. I will have a look.

So the general logic did not change. I would not expect anything to behave differently.
Did you sync your devices after adding the inverted option?

Could you share your item configuration?

Good catch! I didn’t know that I have to sync the devices after adding the inverted option, now it works!
Thank’s

I noticed same change of behaviour today. Inverting and syncing did fix it as well.

And: Many thanks to michikrug for the openHAB Google Assistant integration!

Hmm. Thanks for the update. I will need to check what actually could have caused this…

Hi @michikrug, thank you for all your great work on openHAB Google Assistant, really appreciated!! I noticed that recently my shutters stopped working based on GA commands. It used to send UP and DOWN commands and now sends “0” or “100” which is not understood by (at least) the RFXCOM and KNX bindings. Could this be the result of changes to the GA integration? I did re-sync all items.

edit: I noticed a change in line 22 of “functions/commands/openclose.js” as part of pull request #319:

- return openPercent === 0 ? 'DOWN' : openPercent === 100 ? 'UP' : (100 - openPercent).toString();
+ return (100 - openPercent).toString();

Guess that this is causing the changed behavior. Let me know if there is something I can do or test. Thx!

Yes. This was changed due to the recent “check states” functionality. As openhab translates the command “DOWN” to 100 as the final state (in my tests) and I need the actual state for comparison.

As I do not run rullershutters at my end, I can also not judge if this is actually a correct behavior.

Would you be able to fix this with rules in your end, or do I need to adjust the integration with maybe some configuration options as yours might be a common issue?

I did write rules to make it work again, 2 rules per rollershutter, for me 20 in total, so not ideal. I use the RFXCOM binding to control my Somfy shutters, but I read in another tread that also users using KNX controlled shutters are affected (i.e. do not understand “0” and “100”, only “UP” and “DOWN”).

So if the GA integration could restore the old behavior this would be best, else several bindings (at least RFXCOM and KNX, likely more) will need to be adjusted.

Alright. Thanks. I will have a look in the next days… :sunglasses:

3 Likes

@michikrug while you are at it, in a recent update Google added support for Ikea Shutters, with control buttons inside the app.
Is there a way to make shutters from openHab look like Ikea ones, so we get the in-app controls?

I guess this will come with the reworked Google Home app and has nothing to do with specific configurations of the devices.

See Bring back UP & DOWN for open close devices by michikrug · Pull Request #331 · openhab/openhab-google-assistant · GitHub

Will run some tests and release this asap…

2 Likes

What I still do not understand is that for some users the inverted option had to be set after the last release, as I did not changed the logic of that as far as I am aware of…

I wonder why the values for UP and DOWN have been treated different from the values between 1 to 99. To me its seems that you removed the special handling for UP and DOWN (see comment from mvbergen):

I noticed a change in line 22 of “functions/commands/openclose.js” as part of pull request #319:
	- return openPercent === 0 ? 'DOWN' : openPercent === 100 ? 'UP' : (100 - openPercent).toString();
	+ return (100 - openPercent).toString();


In “# Blinds issue #133” scavenrage commented on 21 Jan 2020

Ok, so I will continue to use a rule to invert only the values from 1 to 99% :D. Thank you very much for your work and your support!

Ah. Thanks for that reminder.

Still, there is no different treatment of UP/DOWN.
Google only tells openPercent values that are “translated” into commands for openHAB.
openPercent=0 will mean DOWN (100 as state) in the OH world. And if the user inverts all values, 0 will be 100 and thus become UP (0 as state).

What we could do is actually introducing different treatment and exclude UP/DOWN from the inversion…

Dear community,

a new release was just deployed.

This is basically just a fix for the last version where the UP/DOWN commands for opening and closing were no longer sent.

:bug: Bug Fixes

:toolbox: Maintenance

  • See GitHub :smiley:
3 Likes