Home Assistant shows my alarm not armed when it is

[jshank]

ha-elkm1 commit a5ac1b4
hass 0.56.2 (docker image from 10/23)

Let me know the best way to capture additional debug information. I'm just getting the update failures below. Could this have anything to do with 2 systems connected to the M1EXP (Hass and ISY994i)?

Relavant logs

hass_1  | 2017-10-26 08:30:59 INFO (MainThread) [homeassistant.core] Bus:Handling <Event state_changed[L]: entity_id=alarm_control_panel.elk_area_1, old_state=<state alarm_control_panel.elk_area_1=disarmed; code_format=[0-9]{4}([0-9]{2})?, changed_by=None, Readiness=Ready To Arm, but a zone violated and can be Force Armed, Status=Disarmed, State=disarmed, Alarm=No Alarm Active, friendly_name=Home, last_armed_by_user=0, last_armed_at=0, last_disarmed_by_user=0, last_disarmed_at=0, last_user_code=3, last_user_at=1509031859.0975542 @ 2017-10-25T20:43:55.484215-07:00>, new_state=<state alarm_control_panel.elk_area_1=armed_away; code_format=[0-9]{4}([0-9]{2})?, changed_by=None, Readiness=Force Armed with a force arm zone violated, Status=Armed Away, State=armed_away, Alarm=No Alarm Active, friendly_name=Home, last_armed_by_user=3, last_armed_at=1509031859.1385984, last_disarmed_by_user=0, last_disarmed_at=0, last_user_code=3, last_user_at=1509031859.0975542 @ 2017-10-26T08:30:59.141489-07:00>>
hass_1  | 2017-10-26 08:30:59 ERROR (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 fails
hass_1  | 2017-10-26 08:30:59 ERROR (MainThread) [homeassistant.helpers.entity] Update for alarm_control_panel.elk_area_1 fails
...

config

elkm1:
  host: socket://10.1.10.21:2101
  code: !secret elk_pin
  area:
    exclude: 2-8
  output:
    exclude: 4-208
  task:
    exclude: 1-32
  thermostat:
    exclude: 1-16
  x10:
    exclude: a1-p16
  counter:
    exclude: 1-64
  keypad:
    exclude: 3-16
  zone:
    exclude: 12-208

[BioSehnsucht]

No idea why the error is happening. Been swamped at work lately but hopefully when I get time to finish updating ha-elkm1 to use the latest updates to PyElk a lot of issues will be solved (there's a ton of changes from code cleanup to performance improvements to bug fixes for stupid errors).

Also I don't think I ever ended up actually using the code property for anything, instead requiring a user to enter it on the alarm panel interface (because that's how the existing HA alarm UI does it). In any case, no matter what code (or lack thereof) was used, I wouldn't expect those errors.

You're running HASS docker so we can assume Python etc are fine. It might just be a problem with newer HASS but I don't think anyone else has reported it (though there's not that many using it yet and I myself haven't updated HASS that is connected to the Elk in ages).

Once I have time to work on this and update the Elk integration again I will definitely update my HASS install and test against it though. (I have been running build tests against current version, but haven't actually run it)

[lmamakos]

FYI - I'm running HASS 0.55.1 and there's been no changes that I've observed in the performance of the Elk interface in my circumstance. Still, my situation is not typical, running HASS on OSX on a mac mini rather than a Raspberry Pi.

[jshank]

I think this is working now but it's not reflected properly in recorder

Also another weird error in recorder when dealing with the area. Maybe this is why it can't store the history?

2018-03-28 08:46:50 ERROR (Recorder) [homeassistant.components.recorder.util] Error executing query: Object of type 'Area' is not JSON serializable
2018-03-28 08:46:50 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1522252010.1549854, level=ERROR, message=Error executing query: Object of type 'Area' is not JSON serializable, exception=, source=components/recorder/util.py>
Exception in thread Recorder:
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/remote.py", line 127, in default
    return json.JSONEncoder.default(self, o)
  File "/usr/local/lib/python3.6/json/encoder.py", line 180, in default
    o.__class__.__name__)
TypeError: Object of type 'Area' is not JSON serializable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/src/app/homeassistant/remote.py", line 133, in default
    for child_obj in o]
TypeError: 'Area' object is not iterable

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/src/app/homeassistant/components/recorder/__init__.py", line 320, in run
    dbevent = Events.from_event(event)
  File "/usr/src/app/homeassistant/components/recorder/models.py", line 39, in from_event
    event_data=json.dumps(event.data, cls=JSONEncoder),
  File "/usr/local/lib/python3.6/json/__init__.py", line 238, in dumps
    **kw).encode(obj)
  File "/usr/local/lib/python3.6/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/local/lib/python3.6/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/src/app/homeassistant/remote.py", line 136, in default
    return json.JSONEncoder.default(self, o)
  File "/usr/local/lib/python3.6/json/encoder.py", line 180, in default
    o.__class__.__name__)
TypeError: Object of type 'Area' is not JSON serializable

[BioSehnsucht]

I've seen similar errors occasionally but I can never trigger them intentionally so I've been unable to diagnose them. I've seen it happen for Zone and Keypad at least in addition to Area. I don't know why it would be trying to serialize them though, if HASS is blindly trying to serialize everything including "private" properties of entities then that is not great.

[jshank]

Is there anything I can provide to assist? I'd love to get recorder working correctly so I can see the arming state history.

[jshank]

It's back to showing disarmed when not

Readiness: Armed Fully
Status: Disarmed
State: disarmed

[BioSehnsucht]

Interesting. Readiness is reflected correctly, b ut clearly the State/Status are wrong.

Hopefully once I complete switching Elk libraries to the asyncio based one by gwww, this will be fixed, and if not, we'll re-examine it then.

[jshank]

Fixed in the gwww branch