I believe pin is alexa’s and google requirement for secure devices (which are locks, covers etc). I don’t think there is a way to open a cover from alexa or google voice assistant without providing the PIN.
funny I am able to open my cover templates just fine via voice
@dshokouhi I am in the HA beta stream but I could not find the beta option for the Android app in the Google Play Store. Does it require sideloading APKs?
Also, thanks for the cover suggestion - it works! The script doesn’t have any pin code in it. I just picked the device and selected open/close.
cover:
- platform: template
covers:
barn_door:
friendly_name: "Barn Door" #just for testing purporses
value_template: "{{ states('binary_sensor.overhead_garage_door') }}"
open_cover:
service: script.open_garage_door
close_cover:
service: script.close_garage_door
I’ll change “Barn Door” to some other fictitious door name and I can finally use open/close commands without getting annoyed by pin codes!
@adorobis - I am curious to know what triggers the pin code requirement, but my “Barn Door” test worked. I can open and close the overhead garage door saying “alexa, open barn door”
EDIT: I removed device_class: garage
as it was causing Alexa to ask for the pin
no its in the play store just need to join the beta
https://play.google.com/apps/testing/io.homeassistant.companion.android
That is interesting. My cover was a template in the first place and it required the pin. I’ve just checked the documentation and it says:
And mine is device_class: gate
- requires PIN when trying to open from Google Assistant…
as well as covers with device types door, garage, or gate.
a cover template will have a different device type
But what is a device type? My gate is a cover template, see below config, and google assistant requires pin to open it:
- platform: template
covers:
gate:
unique_id: gate_template
device_class: gate
friendly_name: "Gate"
availability_template : '{{ not (is_state("cover.brama", "unavailable") or is_state("cover.brama", "unknown")) }}'
value_template: >
{% if states("binary_sensor.gate_left_closing") == "on" or states("binary_sensor.gate_right_closing") == "on" %}
closing
{% elif states("binary_sensor.gate_left_opening") == "on" or states("binary_sensor.gate_right_opening") == "on" %}
opening
{% elif states("cover.brama") == "closed" %}
closed
{% else %}
open
{% endif %}
position_template: >
{% if states("cover.brama") == "closed" %}
0
{% elif states("input_boolean.gate_open") == "on" %}
100
{% else %}
50
{% endif %}
open_cover:
service: script.gate_open
close_cover:
service: script.gate_close
stop_cover:
service: script.gate_stop
remove this line and add some icon_template logic so the UI is untouched
OK, thanks for suggestion. I’ve now added a trigger phrase to the google assistant and trigger the opening script directly from there. Works nice in a few tests. Let’s see after some time.
On another note, the beauty of having the button on a screen in the car is that immediately I can see if the gate is opened or closed. So still would be good to have the screen with favourites to be the default one on AA.
Initially mine had device_class: blind
and when I changed it to device_class: garage
it kept working only because Alexa did not get the updated device type. Once I set it up with the correct ficticious name it stopped working as it updated the device type (see it in the Alexa app).
So I removed the device_class
completely from the template, deleted the device in Alexa and discovered it again, and now it works!
I agree, the default view needs some consideration once favorites are added. It requires building a new home screen and adding more icons etc… So it would be somewhat of a redesign there because we can’t just load the favorites view as that page is not designed to be the main view yet. Once favorites has been merged please feel free to submit a feature request and we can keep that discussion there in how it should look/work with the current feature set.
For those who are in the Play Store beta the favorites PR has been merged and will be in the next push tomorrow night, pending approval. I have also submitted a PR as a bit of a redesign to show favorite entities by default, I am not sure if this will be in tomorrows beta push.
@aruffell, I have a Mazda with a rotary button and I can confirm the fix that @dshokouhi mentioned is working really well. I haven’t experienced any jumping since.
I am indeed now waiting for the Favourites option on the next beta release.
@dshokouhi, is there any plan to add sensors and groups to Android Auto? The favourites list selection does not support either. It would be really useful to see the state of the Gate and Garage door or any other sensors around the house, if possible and permitted by Google.
Otherwise, could you give a hint how to achieve this that you mentioned before?
Is it only for template cover or other entities as well? I have some input_buttons defined which could use it also. To overcome the same issue but without the cover template. But I might just going to create the cover template at the end… (my gate and garage door works with the push button method and there are no in-between states when moving, even the gate is automatically changes direction without stopping when the button pushed.)
Your message must mean the new beta is out, time to go play with the favourites list!
Yes, it is out. I just updated the app this morning.
Indeed, just checked it in my car and it works as advertised. So now if only the Favourites could be the default screen in AA
You can do that in any template entity.
I would go (and I did) a template cover. With this you just have one button in AA that display the state and allows to control your gate. Btw, my gate controller is also just one button but with additional closure sensor and monitoring gate motors (have swinging gate with 2 motors) with Shelly Plus i4 I now know what is the gate state (open, close, opening, closing) so I can make the template cover much more reliable (e.g. if I want to open it and it is opened already it won’t do anything).
existing request
some discussion going on in there
nobody requested this
PR posted a few posts up