Suspect inconsistent setup leading to inconsistent Google Assistant behaviour

Hello All,

I would appreciate some direction on where to start to fix an inconsistent behavior - which I strongly suspect is caused by me

  • Platform information:
    • Hardware: _Intel 5i/ 8GB /500 GB
    • OS: _Windows 7 running OH3 and MQTT broker
    • Java Runtime Environment: OPENJDK 11
    • openHAB version: 3.0.2

I have connected my PowerSeries DSC Alarm panel to OH3 through use of an ESP32 module as described here . Works like a charm.

My setup is Google assistant enabled. Thus, when I say “OK Google, switch off the Away Mode” and if the alarm is armed, then GA says: “OK, disarming the Alarm”. If the Alarm is already disarmed GA responds “The Alarm is already disarmed”
Makes perfect sense.

The inconsistency comes in with the gate.
I have a two limit switches which senses if the gate is fully open or fully closed. This is linked to a ESP32 which talks to MQTT which talks to OH3 - standard design for these type of equipment.

When the gate is fully closed and I ask GA
“OK Google is the gate open”,
GA responds “The Gate is closed”
This is correct -since the system knows the gate is fully closed due to the limit switch.

However, if the gate is fully closed and I say: “Ok Google, close the gate” then
GA responds in saying: “Sure, closing the gate” but this incorrect since the gate is already closed.

I would like to have a similar behaviour between gate and alarm. If the alarm is disarmed and I give the disarm instruction I am told it is already disarmed. Likewise, if I instruct the closed gate to close, I want to be told that it is already closed.

Not sure how to share my gate and alarm setup in OH3 with you guys, but any pointers on where I can start investigating would be much appreciated. If this is documented and I have missed it, happy to get a pointer to an URL as well,

Thank you in advance.

This is just how Google Assistant works. If you ask it a question, it answers. If you give it a command, it says that it’ll carry out the command and then does it. So it’s not incorrect, because Google is actually sending a command to close the gate, and you should see it in your log as a received command. OH also isn’t smart enough to reject the command. It just passes it on, and nothing happens since the gate’s already closed.

Your command to close the gate actually has your first question (“is the gate open?”) built into it. Humans instinctively process this IF statement and respond that your command doesn’t make sense since the gate is already closed. Google Assistant doesn’t yet have that logic, so it needs you to ask if the gate is open and then command it to close the gate if necessary.

I imagine we might see this down the line, as there are many ways in which the Assistant AI could be improved.

Security Systems are currently the only device types that support checking the state before firing a command. This is not a configuration issue but a (known) limitation of our Google integration.

It might be possible to implement this also for other types in the future, but for now you have to live with that behavior.

Is the limitation in the OH implementation or in Google’s API? I just assumed it was the latter, but now that I think about it I can only test with OH items.

The OH implementation.
Google provides options to provide specific error messages and responses.

1 Like

See Errors and exceptions  |  Actions on Google Smart Home  |  Google Developers

There is nearly one for every case.

We currently do not check the state and just “fire and forget”.

Oh, cool. But yeah, that would be a lot to implement considering how many device types you’ve added.

Awesome thanks for clarifying

@rpwong Surely one won’t need these responses for every Item Type. If OH can do switch, contact and maybe dimmer, then most scenarios will be catered for - not true?

Then we’ll eventually get people asking the same question that you are, because it will still be inconsistent. Lots of people use fans, blinds and TVs, and they might feel differently about what would be included in “most scenarios”.

Ultimately it’s up to Michael to decide how much time to put into it and how “complete” it needs to be. I don’t have the programming skills to help, but if you do then I’m sure it’d be appreciated.

As we already have some code in place for the Security System, I will have a look if we can “easily” adapt this for other device types.
But definitely no ETA for this :smiley:

1 Like


I figured out a quite nice (and generic) way to provide such error messages and proposed a solution in

1 Like

Awesome. So, GA will know to respond with “locked/unlocked”, “on/off”, “open/closed”, etc. based on the device type?

Yes, but as stated only for devices where you explicitly tell to do so by adding checkState=true to the metadata to save API calls when not needed.

1 Like

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.