The errors look like:
2019-04-12 20:04:44 ERROR (MainThread) [homeassistant.core] Error doing job: Exception in callback <function async_track_state_change.<locals>.state_change_listener at 0x6ecae6a8>
Traceback (most recent call last):
File "uvloop/cbhandles.pyx", line 68, in uvloop.loop.Handle._run
File "/usr/local/lib/python3.7/site-packages/homeassistant/helpers/event.py", line 82, in state_change_listener
event.data.get('new_state'))
File "/usr/local/lib/python3.7/site-packages/homeassistant/core.py", line 333, in async_run_job
target(*args)
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/state.py", line 55, in state_automation_listener
call_action()
File "/usr/local/lib/python3.7/site-packages/homeassistant/components/automation/state.py", line 47, in call_action
}, context=to_s.context))
AttributeError: 'NoneType' object has no attribute 'context'
Configuration validation passes.
This error only appears when the specific automations have been loaded already and are being reloaded (reload automations). And, sometimes there are no errors, other times 3 (the same), with only difference the 0x.
The cause are automations like this:
- alias: Username Sub < Mailbox movement
trigger:
- platform: state
entity_id: automation.system_mailbox_movement
condition:
- condition: template
value_template: "{{ ( ( ( as_timestamp(state_attr('automation.system_mailbox_movement','last_triggered') ) | int ) +10 ) > ( ( as_timestamp(now()) ) | int ) ) }}"
action:
- service: notify.ios_username
data:
message: "{{ as_timestamp(now()) | timestamp_custom('%X') }}: Mailbox movement"
That’s what I call a subscription automation. Easy to turn on and off per user, while the main trigger stays intact, and is only in one location, making editing easier.
It is responding to one of the subscription provider automations:
- id: '117117'
alias: System - Mailbox movement
trigger:
- platform: event
event_type: xiaomi_aqara.movement
event_data:
entity_id: binary_sensor.vibration_158d0002b71b30
movement_type: vibrate
action:
I first though the automations without real actions were the cause, and disabling those subscription provider automations got rid of the errors, but that was of course because the entity id used in the subscription automation disappeared then. Adding dummy/real actions also did not make a difference.
So I believe the error is caused by the subscription automation seen in code block 2. Before, there were even more errors, I optimized the code and got rid of 67% of the errors, but this is left.
Using sensor.date_time_iso does not solve the problem, and would have been an unwanted solution anyways since it doesn’t work in seconds.
Anyone got a clue?
An alternative subscription system could be a solution too.