0.95: AdGuard, Life360, Plaato Airlock

Blog
23

To be clear about my circumstances.
I reinstalled hassio, I run on a pi3.

24

oh right I see

25

Have may errors as below


2019-06-27 10:18:31 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/esphome/__init__.py", line 171, in complete_setup
    infos, services = await entry_data.async_load_from_store()
  File "/usr/src/homeassistant/homeassistant/components/esphome/entry_data.py", line 76, in async_load_from_store
    **restored.pop('device_info'))
  File "/usr/src/homeassistant/homeassistant/components/esphome/entry_data.py", line 106, in _attr_obj_from_dict
    return cls(**{key: kwargs[key] for key in attr.fields_dict(cls)
TypeError: __init__() missing 1 required positional argument: 'esphome_core_version'
2019-06-27 10:18:31 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/esphome/__init__.py", line 171, in complete_setup
    infos, services = await entry_data.async_load_from_store()
  File "/usr/src/homeassistant/homeassistant/components/esphome/entry_data.py", line 76, in async_load_from_store
    **restored.pop('device_info'))
  File "/usr/src/homeassistant/homeassistant/components/esphome/entry_data.py", line 106, in _attr_obj_from_dict
    return cls(**{key: kwargs[key] for key in attr.fields_dict(cls)
TypeError: __init__() missing 1 required positional argument: 'esphome_core_version'
All my ESPhome devices are not integrated
26

My ESPhome appears all funcioning and listed after the update, what version of ESPhome are you using?

28

same for me (after re-install HA to get it launch without error)

29

@finity
That’s the fix frenck mentioned in this post (you’ll remember it when you read it).

For all other readers who may be unfamiliar with this issue, I had identified a negative side-effect of using initial_state: true in this post. Someone’s automation was occasionally failing and it was due to the last_triggered property sometimes failing to contain a value.

I discovered that when you add initial_state: true to an automation, upon restart the automation’s last_triggered property is reset (i.e. set to ‘None’). Any templates you may have that perform calculations with this property will be negatively affected after a restart.

I mentioned this observation in another thread:

RE: initial_state
What it does is it overrides Home Assistant’s restore feature. It also resets an automation’s last_triggered attribute after each restart (you lose the record of the last time the automation was triggered).

I intended to update the documentation to mention this side-effect. The issue came to the attention of frenck who proceeded to implement three corrections:

  1. Fix the bug with Home Assistant’s restoration feature that was causing people to use initial_state: true beyond what it was originally intended for (implemented in 0.94.1 by baloob via PR 24390).
  2. Fix the bug that caused an automation’s last_triggered to be reset on startup if the automation used initial_state. This was deemed to be entirely new behavior and so is considered to be a ‘breaking change’ and the fix was relegated to a major release version (0.95).
  3. Corrected the documentation.
2 Likes
30

aarch64 docker image is still 0.95.0b1

31

Same error after a re-install too :frowning:

32

hi,
no that you mention this again, let me ask this:

because of the update to 0.94, I took out all my ‘initial_state: on’ settings. ever since, my upgraded system (which had no config errors reported) behaves rather unpredictable and at worst suffers huge lags and timing errors. Ive deleted all changes since the update, but the behavior remains.

I see this flooding the log:

2019-06-27 11:00:52 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c2ec348>
2019-06-27 11:00:52 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c227390>
2019-06-27 11:00:52 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c495db0>
2019-06-27 11:00:52 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6e55a300>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c212348>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c212e40>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6ce08e40>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6c17cfa8>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6d2e0618>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6d5fba98>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function async_track_point_in_utc_time.<locals>.point_in_time_listener at 0x6aea6a08>
2019-06-27 11:00:53 WARNING (MainThread) [homeassistant.core] Unable to remove unknown listener <function

could it possibly be caused by the automations not having the initial_state: ‘on’ anymore?

33

Life360 is not present in integration … ?

34

I don’t know.

The correction was implemented in 0.94.1 (Fix automation failing to restore state #24390)

35

Should be, mine was

36

my 94.4 system has the issue, and all initial_state s taken out, my 94.3 system is behaving very nicely indeed, and has initial_state in each automation…

of course my now 94.4 system was updated from 84.3, but Ive stepped through all breaking changes, and, as said, have no config errors

37

My test system runs 0.94.3, none of the automations use initial_state, and I’ve never seen it generate the log messages you posted.

The issue you’re experiencing is unrelated to version 0.95, so it should be posted as a separate topic … otherwise it will be lost within this one.

38

bluepy 1.3.0 seems like to be working with python 2.7, 3.3 and 3.4. HA (0.95) in docker is running Python 3.7.3, could that be the reason why its Bluetooth is not working in docker?

39

I’m interested in the bluetooth issue since updating to .94 every now and then it will stop tracking around 3am and wont kick back in until I restart.

Also now I’m finding this week when I restart after it stops tracking it fails to restart and I need to hard reboot

Yet there are no errors in the log

I’m running hassio on RIP 3b

40

is it just me or is .95.1 not showing as an available update?
If i try a manual update…
Could not find a version that satisfies the requirement homeassistant==0.95.1

41

it can take a few hours for it to be available

42

SynologyDSM sensors are not working post 0.95 upgrade. The docs show the new “name” setting as optional but that is not the case.

Downgrading to 0.94.4, the sensors still work.

1 Like
43

Maybe read the release about the breaking change?