Thank you for your response. I am sure it should but I don’t have the knowledge of Home Assistant for it too. Any chance you could provide some sort of example.
Does this help?
input_text:
alarmPin:
name: alarmPin
initial: nothing
script:
armAlarm:
# Your arming stuff here
- service: input_text.set_value
data:
entity_id: input_text.alarmPin
value: YOUR_PIN
armAlarm:
# Your disarm stuff here
- service: YOUR_ALARM.DISARM
data_template:
entity_id: YOUR_ALARM
value: {{ states.input_text.alarmPin.state }}
~Cheers
yes, thank you, but i think that leaves a place to input a number on the frontend. it did get my brain thinking though. would something like this work:
# Configuration yaml
alarm_control_panel:
platform: alarmdotcom
username: !secret adc_user
password: !secret adc_password
code: {{ states.sensor.lock_door_code.state }}
sensor:
- platform: template
sensors:
lock_door_code:
friendly_name: 'Door Alarm Code'
value_template: >-
{% if is_state('sensor.lock_b_door_status', 'Unlocked with Keypad by user 1') %}
!secret alarmuser1
{% elif is_state('sensor.lock_b_door_status', 'Unlocked with Keypad by user 2') %}
!secret alarmuser2
{% elif is_state('sensor.lock_b_door_status', 'Unlocked with Keypad by user 3') %}
!secret alarmuser3
{% elif is_state('sensor.lock_b_door_status', 'Unlocked with Keypad by user 4') %}
!secret alarmuser4
{% elif is_state('sensor.lock_b_door_status', 'Unlocked with Keypad by user 5') %}
!secret alarmuser5
{% if is_state('sensor.lock_f_door_status', 'Unlocked with Keypad by user 1') %}
!secret alarmuser1
{% elif is_state('sensor.lock_f_door_status', 'Unlocked with Keypad by user 2') %}
!secret alarmuser2
{% elif is_state('sensor.lock_f_door_status', 'Unlocked with Keypad by user 3') %}
!secret alarmuser3
{% elif is_state('sensor.lock_f_door_status', 'Unlocked with Keypad by user 4') %}
!secret alarmuser4
{% elif is_state('sensor.lock_f_door_status', 'Unlocked with Keypad by user 5') %}
!secret alarmuser5
{% if is_state('sensor.lock_g_door_status', 'Unlocked with Keypad by user 1') %}
!secret alarmuser1
{% elif is_state('sensor.lock_g_door_status', 'Unlocked with Keypad by user 2') %}
!secret alarmuser2
{% elif is_state('sensor.lock_g_door_status', 'Unlocked with Keypad by user 3') %}
!secret alarmuser3
{% elif is_state('sensor.lock_g_door_status', 'Unlocked with Keypad by user 4') %}
!secret alarmuser4
{% elif is_state('sensor.lock_g_door_status', 'Unlocked with Keypad by user 5') %}
!secret alarmuser5
{% else %}
0000
{% endif %}
# secrets yaml
alarmuser1: 1234
alarmuser2: 1235
alarmuser3: 1236
alarmuser4: 1237
alarmuser5: 1238I don’t think that would work as the code would only get read at the initilization of the alarm_control_panel component.
For the example I provided I forgot to mention this portion of home assistant you probably are not familiar with.
You can set entities hidden which you should be doing for my example like this:
customize:
input_text.alarmPin:
hidden: true
~Cheers
Yes, thank you. I think where I am getting confused though is your example looks like it uses a static PIN number. One that never changes. I need the PIN number to change depending on who unlocks the door. So if user1 unlocks the door with user1’s code, it uses user1’s code to disarm the alarm. If user2 unlocks the door, it uses user2’s code to disarm the alarm. Make sense? Am I missing something?
Thanks for your help.
Could you provide your current alarm config with disarm and arm scripts? That would make it a lot easier to explain.
~Cheers
Ok, I made some progress this weekend. I haven’t made it to scripts yet. I would love to use this as a spring board to learning them though. I do have a single sensor that accurately reports the code used at each door. I tried to include it entirely in the secrets yaml but didn’t get very far as I got all kinds of errors. I followed your example above for the configuration yaml but couldn’t figure up out how to add it to the secrets file.
Would you do it like this:
sensor:
- platform: template
sensors:
emby_player_uuid:
value_template: !secret emby_player_uuid
secrets.yaml
emby_player_uuid: start sensor here
I also tried to use the sensor in an automation but that failed miserably.
Something similar to
data_template entity_id: my_alarm_panel code: states.sensor.lock_door_code.state service: my_alarm_panel.alarm_disarm
If you don’t have a script how do you arm your alarm? oO
Also you need to make sure your template gets interpreted by using the jinja2 notation.
data_template
entity_id: my_alarm_panel
code: {{states.sensor.lock_door_code.state}}
service: my_alarm_panel.alarm_disarm
~Cheers
+1 I would like this also.
I am trying to set an automation with a required password from the UI.
So I wanted to do the following but it doesn’t work.
condition:
- condition: template
value_template: "{{ states.input_text.action_password.state != !secret action_password }}"
One issue with this is that hidden text_input components still show up in the states panel. So password is revealed in plain text through the UI.
Maybe you could clear the password straight after using it? Would limit the time it is visible but I get your problem. One way around that if you are that worried would be to use a python or bash script. Call that with the shell_command component and write it to a text file. To use it use a python script to trigger what ever you want withing home assistant using the input from that text file. Or go the AppDaemon route. That would probably be easier if you already have AppDaemon running.
~Cheers
I would love to see this, as putting the WHOLE template into the secrets file is messy and makes code reuse useless. It also hides the actual code function!
E.G.
What we want (Note, not working):
camera:
- platform: generic
still_image_url: >
{% if is_state('binary_sensor.image_2_source_online', 'on') %}
!secret image_url_2
{% else %}
https://localhost/local/blank_display.jpg
{% endif %}
The only way to make it work!
camera:
- platform: generic
still_image_url: !secret image_url_1_template
secrets.yaml
image_url_2_template: ‘{% if is_state(“binary_sensor.image_1_source_online”, “on”) %} http://xxx.xxx.xxx.xxx/picture/2/current/?_username=admin&_signature=clashhuhwhe8ufiohdiijjsi9sjmisji {% else %} https://localhost/local/blank_display.jpg {% endif %}’
I did not know you could do this. But still yeah…we are probably not getting secrets in the templating engine as it was up for debate already and decided against it.
~Cheers
Sucks, what’s the alternative? Throwing templates into secrets?
Only way I see it working for now, yes. Or using AppDaemon with a seperate secrets file maybe…but that would be overkill imho.
~Cheers
With the new template alarm panel, this feature would also be really useful!
I will love to understand what the motivations behind this decision are. I don’t understand the security concerns
I have to add that the the workaround with template sensor is not universal, here is an example:
I often have some parameters as secrets and use them to init my components on HA start.
If I need to use it not in a template, !secret my_secret always does the job.
On the other hand, if I create a template sensor to access the secret in another template sensor, on HA startup there is no guarantee that secret template already exists so I will get unknown instead of my_secret.
By not giving us a way to access constants in both templates and normal automations HA makes its use unnecessarily complicated and simply limits our abilities. Pretty sad that there is still no solution to that.
1 Like
Yes, completely agree.
I want to add that I think that having to store a secret on a template input is even less secure, because it is not treated as a secret anymore. It is just another device and for that reason it appears on the dashboards, gets registered on the logs and even appear on the historic register, so you can see an historic of all the secrets that has been on that input.
4 Likes
You sir are an absolute God. There was no way I could have a secret inside my jinja2 code and I really needed it. Following your advice I put the whole logic of deciding on the secret , into a new secret and then passed that secret to the configuration!
Worked to perfection!
Not sure if this has been said, but if you use non-front-end script YAML, secrets work just fine.
# /config/configuration.yaml
...
script: !include_dir_merge_named configuration/scripts/ # Load any .yaml in this dir
...
# /config/configuration/scripts/_scripts.yaml
!include ../../scripts.yaml # Let's us keep the front-end scripts.yaml working
...
# /config/configuration/scripts/back_end_scripts.yaml
set_layout_redtail:
alias: Set Layout PC
sequence:
- service: script.turn_on
target:
entity_id: script.layout_windows
data:
variables:
username: !secret redtail_user
ip: !secret redtail_ip
layout: '{{ states("input_select.screen_layout_redtail") }}'
mode: single
icon: mdi:monitor-multiple
1 Like