Thanks, Glenn. I have opened a new github issue here.
Dave
Folks, how do you make groups of alarm zones? It doesn’t appear that the groups helper will let you do that since the zones aren’t binary sensors. I would like to group window zones to tell my HVAC to shut off if the windows are open…
Is there a way to see automation/rules execution in Home Assistant? These are essentially events that do something (e.g. turn on an output) if an even is detected (e.g. F-key press on the panel).
I have a few rules running on my M1 Control and I’m not sure they fire. They are triggered via an RF remote button (tried two remotes). Looking at the integration page doesn’t show anything obvious.
I don’t think we have a logbook descriptions for EVENT_ELKM1_KEYPAD_KEY_PRESSED so they won’t appear in the logbook, but you should be able to see them in automation traces.
What’s an automation trace?
Does this mean this update likely makes its way into core-2022.5.6?
2022.6 will have this change
1 Like
Anybody else is having issues with climate from the elkm1 after the update to 2022.6.0?
The following error for both of my climate areas:
‘140477941995216] Unable to serialize to JSON. Bad data found at $.event.a.climate.lower_floor.a.mode=ThermostatMode.HEAT(<enum ‘ThermostatMode’>, $.event.a.climate.lower_floor.a.fan=ThermostatFan.AUTO(<enum ‘ThermostatFan’>, $.event.a.climate.upper_floor.a.mode=ThermostatMode.HEAT(<enum ‘ThermostatMode’>, $.event.a.climate.upper_floor.a.fan=ThermostatFan.AUTO(<enum ‘ThermostatFan’>’
And warning in the log as follow:
'* State is not JSON serializable: <state climate.upper_floor=heat; hvac_modes=[<HVACMode.OFF: ‘off’>, <HVACMode.HEAT: ‘heat’>, <HVACMode.COOL: ‘cool’>, <HVACMode.HEAT_COOL: ‘heat_cool’>, <HVACMode.FAN_ONLY: ‘fan_only’>], min_temp=1, max_temp=99, target_temp_step=1, fan_modes=[‘auto’, ‘on’], current_temperature=74, target_temp_high=76, target_temp_low=70, current_humidity=0, fan_mode=on, aux_heat=off, name=Upper floor, mode=ThermostatMode.HEAT, hold=False, fan=ThermostatFan.ON, current_temp=74, heat_setpoint=70, cool_setpoint=76, humidity=0, index=2, friendly_name=Upper floor, supported_features=74 @ 2022-06-01T22:24:29.920081-07:00>: Object of type ThermostatMode is not JSON serializable
It looks like some of the attributes are not being stringified by as_dict and are coming through as enums. Would you please open a github issue?
Thanks 
Thanks Nick. btw, nice to see you on the recent release party stream 
So I have 2022.6 on my test system. In order to see these events in the new log section in devices do I need to set the logger to
logs:
elkm1_lib: debug
homeassistant.components.elkm1: debug
like what we’ve done to troubleshoot the serial port issue? Nothing seems to be coming through
Hi Thomas,
If you access the logbook panel at /logbook and mash a few buttons on the keypad, they should appear. The panel only reports some of the buttons so I suggest manually arming/disarming while watching the logbook page as I know that generates at least one event.
Also make sure elk events are not excluded in your recorder filters.
The list of keys that the ElkM1 generates can be found here on page 27 here. FYI, there are no events for number keys.
1 Like
I have been pondering adding binary sensors for the zones to get on/off status. This would not remove the existing sensors, it would be in addition to.
One of the challenges is that there is no automatic way of mapping a zone to the “correct” device class (motion, door, window, etc). This can be done through YAML config though - so, it would not be entirely automatic.
Why do this? Nicer status - for example, instead of violated for a door you would see open. Also, there are more blueprints would be more usable as they are tailored for open/closed rather than violated.
Would people find having binary sensors be useful? Should they be created but disabled by default (is that a HA requirement?)? Other thoughts?
PS: while I’m here, are there other improvements people are thinking of for the ElkM1 integration?
1 Like
Newer versions allow changing the device class in the UI as well as customize so we probably wouldn’t need to add YAML config even
1 Like
This would be really great to have! There are many blueprints that assume binary sensors for things like motion detectors etc…, and right now it’s painful to use all the Elk alarm sensors in this way. Having all zones be binary sensors would be great, though personally I wouldn’t mind if you needed to deprecate the existing ones in favor of these.
That’s an interesting idea. One thought that I had was what to do about a zone that was in a trouble condition (shorted or open when configured for an EOL resistor)… maybe have the binary sensor be in an “unavailable” state? I wonder what other values the state of a binary sensor is allowed to be, other than on/off or open/closed?
I think that you’d have to ensure the zone isn’t in one of the other funky modes, like analog or having a temperature sensor, but I think this is already happening in some form. These types of zones should remain as they are today, “regular” sensor entities.
I’d think that if the binary_sensor entity was created for a zone, the “regular” sensor entity would be created in a disabled state. And then the user could decide to enable it if it made more sense to him. For existing users, the binary_sensor entities could be created in a disabled state, and then enabled as users would migrate over to using them. I suppose you could have both versions around at the same time to facilitate migrating automations over one at a time?
I’ve been pondering this over the weekend and no conclusion yet. What to do with the other values of sensor is the concern I have not reckoned with. Another option is do nothing and use existing HA functionality. I have the following in my config at the moment, which does everything that building it in would do:
- binary_sensor:
- name: "Main Bedroom Left Window"
device_class: window
state: >
{% if states('sensor.l_main_bed_wdw') == 'Normal' %}
off
{% else %}
on
{% endif %}
Note that Normal is off and any other value is on.
What I like about templating is no new code. The code, while simple to implement, would mean a bit less reuse than the other entity types to assign device class and to filter out sensors not applicable (temperature for example).
What I dislike is that it state template code is repeated for each binary_sensor.
With either approach the device class would have to be assigned by the user for most zones as there is no way to infer device class for many zone types (burglar for example).
For binary sensors, I’d think of them as violated or not violated. So its either 2 or not.
If its an uncommon use case, templates are a good solution. If its a common use case, templates aren’t preferred since they are generally orders of magnitude more expensive than adding another entity even if its disabled by default.
1 Like