[SOLVED] Google Assistant "Lock"

Apps & Services Google Assistant
1
  • Platform information:
    • Hardware: Raspberry PI 4 2Gb
    • OS: Raspbian(Buster)
    • Java Runtime Environment: OpenJDK 11.0.8
    • openHAB version: 2.5.7
  • Issue of the topic: Google Assistant Item treating
  • Please post configurations (if applicable):
    • Items is a Switch
    • Sitemap Switch (push button only)
    • Rules code related to the issue N/A
    • Services configuration related to the issue N/A
  • If logs where generated please post these here using code fences: N/A

I created a Switch (a channel of 4CH sonoff boards), used to open the main gate of my house.
Using the openhab console, I added metadata like ga=“Lock”. I expected in Google Assistant a padlock Icons, but Google Assitant display the standard Switch Icon.
Is possible to change the Google Assistant Icons to a padlock? Otherwise I may prefer a push button since is a inching contact.

What does Google Assistant use to define the type of displayed icons?
E.g. I also have a Dimmer. Using the metadata ga=“Fan” (with speeds), Google Assistant display a Fan Icon, but inside the Items only gives the on/off button.

Thanks.

2

I think thats a Google decision. You can operate the fan-speed by voice, but only on/off from app.

1 Like
3

Here is my thing for my Ifan03 running tasmota

    Thing topic fan1 "Dining FAN" {
    Channels:
        Type switch : Power1   "Dining Light "  [ stateTopic="IFANdining/stat/POWER", commandTopic="IFANdining/cmnd/POWER", on="ON", off="OFF" ]
        Type dimmer : fanspeed "Fan Speed"      [ stateTopic="IFANdining/stat/FANSPEED", transformationPattern="JSONPATH:$.FanSpeed", commandTopic="IFANdining/cmnd/FANSPEED", 0="OFF", 1="LOW", 2="MED", 3="HIGH", 2=100  ]
      }

Item

Switch Dining_light "Dining Light" { ga="Light", channel="mqtt:topic:myMQTTBroker:fan1:Power1" }
Dimmer Dining_fan "Dining Fan" { ga="Fan" [ speeds="0=off:zero,1=slow:low:one:on,2=medium:two,3=high:three:100", lang="en", ordered=true, roomHint="Dining" ], channel="mqtt:topic:myMQTTBroker:fan1:fanspeed" }

No for lock item

Switch Lock_Test "Front Door" { ga="Lock" [ tfaPin="1234" ], channel="mqtt:topic:myMQTTBroker:Front_door:Lock" }

“Hey google unlock the front door”
Google Asks"What is your pin"
“One Two Three Four”

Item ‘Lock_Test’ received command OFF

It shows up in google home app as a lock but you need to use voice to control.

For TFA without pin

Switch Lock_Test "Front Door" { ga="Lock" [ tfaAck=true ], channel="mqtt:topic:myMQTTBroker:Front_door:Lock" }

“Hey google unlock the front door”

Google asks “Are you sure”

“YES”

Unlocked is OFF locked is ON

1 Like
4

Its funny because in the google home app on phone I get on off but on the google home display I get a selection.

5

Thanks for complete examples @denominator, before reading them, I was able to see the padlock icons on Google Assistant. But with the gear overlay, and as you say, without touch control.
My problem was the tag “Switchable”, tooghether the metadata the tags was prioritized. Removed the tags, the metadata begin to work.
But open the gate only with voice control is not my goal. I returned to “Switch”, even if I prefer a “push button”.
We will wait for the next versions of Google Assistant API.

6

Yes, that normal. Happens for my Velux windows as well. Thats a stupid Google decision as well :slight_smile:

1 Like
7

Not exactly true, metadata is always prioritized, but the Switch (exposed by tag) was identified before it could actually check for Lock and the system does stop when at least one device type has been detected. (Every item is checked against a predefined list of possible devices, where Switch is before Lock.)
Nevertheless, the result at the end is the same as you described.

1 Like
8

This totally bothers me. For easily every second device type no UI is provided. :frowning:

2 Likes
9

This is interesting and very usefull in the future, thanks for explaint it.

10

To be honest, I would so much love to completely remove all the old tags stuff.
But there were voices against it


11

Previusly I iused only the “switchable” tags.
But now I removed all the tags from my items and I use only metadata put with openhab console or API REST.
The items seams to work ok with google Assistant.

12

Maybe its time to consider remove the old tags once again, (I have to convert all my items first though :-). I can only imaging how much not needed stuff in the code which you could get rid of.

13

Smart as I am there are only a very few code lines.
But it would indeed save many additional test cases.
And even more important, it would save us so many scenarios that can lead to strange behaviors esp. at the enduser’s side.

1 Like
14

Very O.T.: Goolge changed the Home application look. Non the status of items is visible just in the main screen and the Items have active only the actions relative to the actual status.
A small step for an app but a giant leap for the user!! :rofl:

15

That is true.
And for the first time ever I saw bulk queries of device states.
I implemented this as the documentation said, but it was never used before.
Now, when opening the home app, multiple devices at ones are queried and it works quite well. \o/

16

Still needs to improve the updatre speeds, e.g. in case of inching switch, but for a best reaction the query/response protocol is not the best. An event-driven protocols should be better.

17

Yes, there is this active state reporting, but this would need to be triggered from within openHAB directly to Google, which the current architecture (openHAB->Cloud->GA Integration) will not support.

18

Seems like this is only working for switches in my home app. Ligths etc are not.

19

Also for Light, for me. But not Fans. Fans are very hard Items for GA.

20

Strange :frowning: