0.85: ESPHome, Plum Lightpad, OpenSenseMap

gazzaman2k · January 13, 2019, 12:41pm

ah im on rpi3b+

andy5211d · January 13, 2019, 2:09pm

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.

TWuerdemann · January 13, 2019, 2:49pm

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.

jay2048 · January 13, 2019, 3:35pm

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 ?

TWuerdemann · January 13, 2019, 3:46pm

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

yan · January 13, 2019, 7:01pm

See this Post

finity · January 13, 2019, 7:24pm

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.

jay2048 · January 13, 2019, 7:28pm

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.

dcnoren · January 13, 2019, 7:30pm

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.

finity · January 13, 2019, 7:32pm

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.

yan · January 13, 2019, 7:52pm

See this Post here for clarification.

Oliviakrk · January 13, 2019, 8:58pm

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…

York_Yu_Chan · January 14, 2019, 2:36am

Trying to upgrade from 0.85 to 0.85.1

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

nickrout · January 14, 2019, 3:43am

Is HA actually running?

Have you tried clearing your browser cache?

cpuram · January 14, 2019, 5:26am

unable to upgrade to 0.85.1
docker pull kept pointing to 0.85.0 and saying my image is upto date

J-CMartin · January 14, 2019, 6:37am

Apparently the “latest” version tag wasn’t updated to 0.85.1 yet. You can always reference an specific version, and get back to latest when they update it:

That’s what I run to get the latest version:
docker pull homeassistant/home-assistant:0.85.1

J-CMartin · January 14, 2019, 6:41am

Anyone else having issues with the envisalink component?

I’m getting an “Invalid Config” error. It worked before and I don’t see any breaking changes on that component.

cpuram · January 14, 2019, 6:50am

Thanks. That worked.

makai · January 14, 2019, 7:11am

Did you use HassOS?
You may have an old configuration file somewhere?
Regarding systemmonitor, since_last_boot has been removed.

York_Yu_Chan · January 14, 2019, 2:25pm

No, the HA seems to be stuck somewhere that is not running. Cleared by browser cache etc, but still doesn’t work. I unplug the cable and plug it back in everything runs back to 0.85.0. Anyway I can do manual updates or seeing the log via ssh?