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.
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.
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
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:
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.
@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?
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!
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…