0.85: ESPHome, Plum Lightpad, OpenSenseMap

Upgraded from 84.6. it wasn’t working in 84.6 but at least it still started up

The problem in your config is obvious, no indentation.

No, that was just my poor formatting on mobile. It worked in 84.6 for a few hours and would then stop. It was a known issue.

1 Like

Well, I had zero problem from this upgrade, and I do have 20+zwave devices.
Which is amazing since so many changes have been applied.
Big applause to the developers

But understand the user frustration sometimes

are you using aeotec zwave stick? and try to restart after the first initial start.

i can upgrade and everything works fine, as soon as i restart my zwave has disapeared

Hassio on NUC with Aeotec stick attached to it. No problem encountered

ah im on rpi3b+

Sort of new to Home Assistant but have been using 0.82 to 0.83 and can make most things work even if I don’t quite know why. Come to upgrade to 0.85 with little success. Unable to log-in, duck-DNS does not work, iOS app stopped working I guess to DuckDNS not functioning and most of my sensors, lights and power missing. Node-RED also no longer knows who I am whatever I log in as.

However I have several R-Pi 3’s so a clean install of 0.85 and have now added most of the add-in packages I want such as MQQT, Node-RED, DuckDNS, SSH and TasmoAdmin and all the basics seem to work. Have not added any sensors, lights, switches, automations, etc etc. although HA has found a few things automatically. Just the basic build with the add-ins listed.

But looking at the log I have this error:

[Info] Start install HomeAssistant latest
You are using pip version 18.0, however version 18.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
[Info] Install done, check config now
[Error] Wrong config found!
INFO:homeassistant.util.package:Attempting install of colorlog==4.0.2
Testing configuration at /tmp/config
Failed config
  sensor.systemmonitor: 
    - Invalid config for [sensor.systemmonitor]: value is not allowed for dictionary value @ data['resources'][3]['type']. Got 'since_last_boot'. (See ?, line ?). Please check the docs at https://home-assistant.io/components/sensor.systemmonitor/
    - platform: systemmonitor
      resources: [source /tmp/config/sensors.yaml:50]
        - type: memory_use_percent
        - type: processor_use
        - type: last_boot
        - type: since_last_boot

Successful config (partial)
  sensor.systemmonitor:

Are these items something to ignore or should I be worried as I have not yet added systemmonitor or anything along these lines yet?

I guess no one knows. Seems odd to get this type of errors on a new build with nothing added other than add-on’s.

Also again an issue for 0.85.1 … the latest tag still point to 0.85.0.
It’s not that urgent but very annoying because my update scripts use the latest tag as default.

1 Like

When upgrading to 0.85.1 (from 0.84.6) it seems all my automations got disabled (All toggle switches for the automation.*). Did someone get this as well ?

Also happened here… I had to turn them back one and it worked. Strange thing indeed.

See this Post

But if that (initial_state: true) is not there then they will (should…) maintain their current state thru restarts. At least that was the promise after implementing the new storage system.

I’m curious about that behavior, when would a default initial state set to false make sense? Also, it’s the first time I’m seeing this, and I’ve been using HA for longer than 0.83.

First time I had seen it too, however I did a double reboot and the second was before Hass was able to fully load, so the automations never initialized and then the system rebooted and then they stayed off.

I also had not put the initial state true, but did it and then it’s all fixed.

And, I can think of cases where I want automations to be triggered certain times only; e.g. instead of having a “guests present” boolean, now I can just enable/disable the automations.

If you always want your automations to be in a certain state when you restart HA or reload your automations then you should use initial_state. Otherwise if you want them to maintain the same state thru restarts then don’t use it.

The reason it went screwy now is because there is a new storage implementation that caused the states of the automations to be lost on moving to v85. Supposedly since that change they are supposed to maintain their states thru restarts/reloads. If they are loosing their states now then maybe there is a bug.

See this Post here for clarification.

Is there a problem with xiaomi on 0.85? I have issues with everything:

 Got exception while fetching the state: Unable to discover the device IP_HERE

I checked the component configuration and everything look good…

Trying to upgrade from 0.85 to 0.85.1


Stuck with this. Anyone has the same issues? I tried twice the same result.

Is HA actually running?

Have you tried clearing your browser cache?