Correct order is: first backup! Then update.
5 Likes
I got a prompt to manually update to 201… First time I saw that
Weird! I’m on 201 already… never seen a prompt to update supervisor… I am on beta though - maybe that’s why?
I am not on beta… Indeed it was strange… It was prompt like a prompt to update to 105.5
@petro I do not think you understand Klagio’s problem.
The format you give is correct YAML. But you cannot enter this in the Automation editor. It only supports the delay: “HH.MM.SS” format. You can click on the YAML edit button and put
delay:
milliseconds: 50
But the minute you continue it becomes garbage saying [object object]
That Automation editor is still very much alpha state.
@Klagio forget the Automation editor. It is fun to play with but you run into trouble with even the most simple things. Make your automations in YAML. Use the Automation Editor to find what is possible but do the real stuff in YAML
2 Likes
I had the same occurrence a week or so ago for an update from 198 to 199. By the time I posted to this forum and received a response of which to update first, it’d already updated the supervisor to 199.
Just checked and I’m already at 201 now, fwiw.
Also, FWIW, and I’m not saying they’re related, but writing this post made me realize the coincidence - I’ve had to completely reboot my NUC twice in the last 10 days or so (including a hour ago) as the frontend hasn’t loaded for me. Running on a NUC and it’s been pretty rock-solid for the past 5-6 months or so - first I’ve had these issues. Haven’t had the time to dive into the logs, so can’t guarantee it’s related to automatic Supervisor updates, but I’m running 104.3 and have been for a few weeks now… 
Why? Can you not just restart the HA container? (with portainer or something like that?) I only restart my NUC if there is a Kernel update or if I want to update the bios… or are you running HassOS on the NUC? Even so you should/could use Portainer to restart the container.
Yeah, probably, but portainer also wanted to update, then ubuntu wanted to update and I figured I’d already shut down HA, so I updated them all and then just rebooted the whole NUC…
I know what the problem is, I just lost interesting in helping the helpless 
FYI: 0.105.5 breaks bmw_connected_drive, bimmer_connected for users in USA.
I have noticed the same thing. Looks like it’s now putting the update notification in the Supervisor tab to allow it to be done manually, but it still auto-updates after a set time.
Yes, the author of the underlying framework is aware of this.
Glad they are aware of the bmw_connected problem, maybe someone could update the above changelog to reflect this so more people can avoid breaking their system.
I just updated from 0.105.x (4 or 5) to 0.106.0b0
It has instantly stopped all my conditional cards within the stack card from working - now red stripe
The xiaomi card is also giving me the message “Cannot add property service, object is not extensible”
I have two VM with HASSOS on the same NUC (two HASSIO).
One at 192.168.1.12 and xxx1.duckdns.org
The other at 192.168.1.13. and xxx2.duckdns.org
Both working fine.
The first gets all the updates, the second no, still 299 supervisor and HassOS previous version.
When I try to update manually it says the version are current.
Any clue?
There is a breaking change for custom cards in 0.106.x
@firstof9 thanks for the reply. I was able to fix it by just going back to the normal vertical-stack instead of the custom one.
1 Like
Is this issue going to be addressed in a dot release or the next major?
Because I’m still seeing it in 0.105.5
Hey @frenck, thanks for the hard work, the integration is working very well 
I’m wondering whether there is a modification I can make somewhere to make it poll faster? I used the old Spotify implementation to turn on my speakers, for instance. I used to have the old version poll every 2 seconds in order to have a decent response time.
Do you know where I might make a modification in order to achieve the same thing?
Thanks!
Great work!