You mention how you have some custom functions on your hass running with your keypad buttons. Can I get a few samples of the way you get the data from your Elk into mqtt? I am drawing a blank here, and the things I have tried doesn’t seem to work.
Still works this way. When the ElkM1 lib sees that ElkRP has connected it “pauses” the connection to ElkM1 until ElkRP disconnects. On ElkRP disconnect a full sync between ElkM1 and the library happens. Many of the changes can be reflected back in hass. What does not happen is that the set of hass configured entities do not change.
On other notes, there is a hass speak_word and speak_phrase service that can be used. Someone in this mega thread requested that… @lmamakos?
2 Likes
Super! I shared a comment on github with similar code I implemented on my JavaScript system.
This I think is my final gap
Awesome. Looking forward to testing
PR accepted into hass already! My guess is it should land in 0.83.
Awesome. I’ll deploy the first beta as it’s released
That MQTT topic’s structure is unique to Premise.
In Premise, all objects are arranged in a hierarchy where each level represents a location. The topmost level is always Home. Here’s my garage door opener’s full path name:
Home.House.Garage.GarageDoor.Toggler
Each object’s MQTT topic is automatically created and is based on its path name. It begins with the word premise followed by the entity’s path name, and ends with the property you wish to use. The Toggler has one principal property called State therefore its two topics (for status and command) are:
premise/home/house/garage/garagedoor/toggler/statepremise/command/home/house/garage/garagedoor/toggler/state
In Home Assistant, there’s no equivalent structure to define an entity’s location. For example, cover.garage_door_opener is the entity and its location is (optionally) implied by the name you give it (i.e. the word ‘garage’ in garage_door_opener). Most relevant to this discussion is there’s no automatic creation of MQTT topics for an entity. There’s no automatically-generated MQTT topic such as homeassistant/covers/cover.garage_door_opener. That’s not to say it can’t be done, just that there’s a bit more work involved.
For automatically publishing an entity’s state-changes (i.e. its status topic) you can use an automation or a component called MQTT Statestream designed for this very purpose. It publishes the state-changes of one or more entities. However, MQTT Statestream doesn’t allow you to control an entity (i.e. there’s no command topic). For that, it’s my understanding you have to create an automation.
Here’s an example of this scenario. The individual has existing TP-Link switches defined with the switch component and the TP-Link platform. They also want to allow an MQTT client to control the TP-Link switches. In other words, they want Home Assistant to subscribe to command topics and use the received messages to control the TP-Link switches. The solution is an automation:
Alternately, you can control those switch entities via Home Assistant’s existing and comprehensive REST API. However, if you want to control them via MQTT then the example above gets the job done.
I am building up node red rules to use with the HA Elk interface. I know the F keys are coming. I am finding 2 other things I could use a little assistance with.
- I can not seem to find what strings alarm_control_panel.area.data.attributes.alarm_state can be in. I want to build rules based on different alarms (fire, water, burglar, etc). If someone could point me to the code the defines these. I have searched but not too familiar with python or HA structure.
- This is more of a feature request, and may be limited due to trying to fit the alarm states to HA, but can we get a separate state for armed_vacation, it appears in the code that is just mapped to armed_away. If not a complete state can we get another attribute that indicates this?
thanks
Cant help you with #1, but here’s what I’m using to track vacation status for your #2
- platform: template
sensors:
vacation_status:
friendly_name: "Vacation?"
value_template: >-
{% if states.alarm_control_panel.area001.attributes["armed_status"] == "armed_to_vacation" %}true
{% else %} false {% endif %}elkm1/elkm1_lib/const.py at main · gwww/elkm1 · GitHub are the states for alarm. For example BURGLAR_ALARM will show as burglar_alarm – i.e.: change name to all lower and substitute ‘_’ for ’ ’ (blank). Same pattern for all the other constants in that file.
Thank you exactly what i was looking for and could not find for some reason.
Anybody know why the following automation doesn’t trigger? I’m trying to get an alert for any alarms that trigger.
- alias: "alarm testing"
trigger:
- platform: template
value_template: "{% if not is_state('sensor.alarm_state', 'no_alarm_active') %}true{% endif %}"
action:
- service: notify.pushover
data_template:
title: "{{ trigger.to_state.attributes.friendly_name }} Changed"
message: >
{{ trigger.to_state.attributes.friendly_name }} has changed to {{ trigger.to_state.state }} or {{ sensor.alarm_state }}.
My alarm_state sensor looks like this:
- platform: template
sensors:
alarm_state:
value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
friendly_name: 'House Alarm State'
I’ve not used the template platform in a trigger before. I know that recently template sensors (for example) requires you to specify the entity ids that the templates use to cause the template to be re-evaluated when one of the specified entities change. Until recently, if you didn’t specify the entity id, it would always be re-evaluated which was time consuming, thus the change. (See https://www.home-assistant.io/blog/2018/10/26/release-81/ announcement.)
Perhaps something similar is at work here when using the template platform as a trigger?
Alternatively, you could use the state platform as the trigger, based on the template sensor you defined. (And you probably ought to add the entity_id to the template sensor you listed in any case.)
Template sensors will no longer auto update if we can’t find relevant entities in the template. You’ll want to review your template sensors and consider adding relevant
entity_identries or use the newhomeassistant.update_entityservice.
So what’s the ‘relevant entity’ in this template_sensor?
- platform: template
sensors:
alarm_state:
value_template: '{{ states.alarm_control_panel.area001.attributes["alarm_state"] }}'
friendly_name: 'House Alarm State'
Is it alarm_control_panel.area001? Wouldn’t that mean that any change to area001 would cause the template_sensor to update? I’m unclear as to how this works.
For example, I have this in my configuration (for a binary sensor, but same idea for a normal sensor):
binary_sensor:
- platform: template
sensors:
dark:
# states.sensor.time (which is always true) so that the template sensor is evaluated every minute
entity_id:
- sensor.time
- input_boolean.force_dark
- sun.sun
value_template: "{{ states.sensor.time and (is_state('input_boolean.force_dark', 'on') or states.sun.sun.attributes.elevation < 10.0) }}"
friendly_name: 'Dark'
This is sort of hacky, in that I cause the template to get re-evaluated each time sensor.time changes, even though it’s not really used in the template. At one time, changing attributes (the solar elevationz0 didn’t seem to trigger a state change on the sun.sun entity. But this illustrates how you have multiple entities associated with the evaluation of a template.
In your case, I believe that the “relevant entity” is alarm_control_panel.area001
I just recently finally got our “live” HASS environment updated to latest (it was still on an ancient 0.6x with old elk custom code)
While doing so I found some simplifications versus our old automations. The following sends a notification of who accessed the main area when either the front door or back door KAM is accessed (RFID keycards). Used to be separate automations for each KAM and also I had to make value template sensors to access the attributes but this works just fine. They trigger any time the KAM updates, which is only on access / disarm / etc.
- id: '1542678207721'
alias: Main Area Accessed
trigger:
- entity_id: sensor.front_door_kam, sensor.back_door_kam
platform: state
condition: []
action:
- data_template:
message: "[{{now().strftime('%H:%M')}}] {{ trigger.to_state.attributes.friendly_name}} accessed by {{ trigger.to_state.attributes.last_user_name }}"
service: notify.stride
As per my question above, if the relevant entity is alarm_control_panel.area001 doesn’t that mean Home Assistant is monitoring state-changes for all of the entity’s attributes? In other words, although this example matches on one attribute’s state-change, “alarm_state”, Home Assistant is actually evaluating all of alarm_control_panel.area001 attributes. Just want to confirm this is actually what’s happening under the hood.
Hm, interesting… I wasn’t aware of this - I assume you’re talking about this?
Template sensors will no longer auto update if we can’t find relevant entities in the template. You’ll want to review your template sensors and consider adding relevant entity_id entries or use the new homeassistant.update_entity service.
If so, it seems a little vague - in my case, hass must be able to find the ‘relevant entities’ because the template sensors update immediately…
Regardless, you bring up a good point, and it certainly may relate to this. Can you elaborate on this
Alternatively, you could use the state platform as the trigger ?
How would I do this with the not that I’m trying to achieve? I want to ignore the no_alarm_active state…
hrm… so I think it has to do with the fact that I failed to use the states.xxxx.state convention, but i still cant get it to work.
- alias: "alarm testing2"
trigger:
- platform: template
value_template: "{% if not is_state('states.sensor.arm_up_state.state', 'ready_to_arm') %}true{% endif %}"
action:
- service: notify.pushover
data_template:
title: "{{ trigger.to_state.attributes.friendly_name }} Changed"
message: >
{{ trigger.to_state.attributes.friendly_name }} has changed to {{ trigger.to_state.state }} or {{ sensor.alarm_state }}.
Inside the is_state template function, you should use the actual entity name. So sensor.arm_up_state to get the state of that entity. The other form references a data structure that exists within the template.
First Beta is missing your pull sadly 
Ill hold for the next drop