0.85: ESPHome, Plum Lightpad, OpenSenseMap


#81

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


#82

The problem in your config is obvious, no indentation.


#83

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.


#84

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


#85

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


#86

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


#87

ah im on rpi3b+


#88

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.


#89

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.


#90

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 ?


#91

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


#92

See this Post


#93

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.


#94

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.


#95

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.


#96

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.


#97

See this Post here for clarification.


Status of the automations after restarting the system
#98

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…


#99

Trying to upgrade from 0.85 to 0.85.1


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


#100

Is HA actually running?

Have you tried clearing your browser cache?