I’ve just rebooted everything and am now on supervisor 180 and everything appears to be back to normal.
I’m not quite sure if I hit “shutdown” instead of “reboot”, but my RasPi 3 stopped responding, so after ~1 hour (of other DIY ) I just cycled the power and all is working again.
Now… If I could just request the system stays still until I’m ready to update all of these components manually (that also means not an auto upgrade during a reboot), then in my case, I’d be a happier man… 'cos I’d have had a chance to do a backup first ()
And that’s the problem, we can’t control when those supervisor updates happen so our systems are constantly under the threat of being hosed at any time.
I’m at age already as well I agree on the weekend thing, however, in this case… I could intervene because it is the weekend.
Understandable, but this is also the heart of the problem. If nobody runs it, we won’t be getting feedback or reports. Ending up with the illusion it is stable. Yes, I’ve run it on production myself and did not notice issues, nor did some other users who have confirmed working systems.
Maybe this isn’t the right place for this discussion but let’s suppose I opt for the Beta version of Supervisor to try and help, aside from making my own backups and restoring, is there a mechanism to opt out and switch back to a stable version should things go pear shaped without it automatically updating?
There really has to be a way though for people to opt out of the auto update, I’d happily freeze my system where it is now, it’s the uncertainty and now the expectation of an uncontrolled update causing havoc that’s truly concerning. What if this had been malware or an update that opened up access to malware? The more popular home automation becomes and the more popular this system becomes, the more likely this scenario becomes and we’ve already seen one instance of this with the SMB add on.
I prefer the term honest and I’ve acknowledged more than once the effort that is put in this project on zero salary. I’m a huge fan, promoter and supporter of Open Source and you’ll see I’ve offered to help, your offensive comment is less than helpful.
It’s the auto update that is the problem for those of us that don’t run auto everything and want to manage when our systems are updated.
And another thing, I’m a gigging musician but occasionally I’m asked to do a free gig, should it therefore be expected that I don’t bother to tune up, put in less effort and just generally perform less well because it’s free? Of course not so why expect it from Open Source developers, they are mostly professional coders in their day jobs.
Hi Frenck, just a heads up, once the local dns server is setup, at the moment the local hostnames must be fully qualified.
My router is setup with the domaine name: home
Before in my configuration i had short hostnames, like cam-living, but that doesn’t work with the custom DNS in hassio.
I changed it to FQDN: cam-living.home and it works.
It’s ok to change the config, i don’t have much hosts, but IMHO it should work with short names too (like everything else on my network).
This might be down to the fact that the machine calls itself local.hass.io so it will assume everything is in that domain. My DHCP server sets up every device to have the correct public domain .house, I use split horizon DNS on my network. This works for even the simplest device such as my Tradfri gateway which can be pinged by the simple name tradfri from any device with a command line except HA
The fact that esphome devices need to be told which domain to use and ignore the DHCP settings is an interesting theme…
Wow, what a rabbit hole I’ve been down in the last 24 hours. I started to see DNS failures after I installed AppDaemon, saw the core-dns addon and blamed AppDaemon for installing this.
After posting about my experiences, I was referred to this thread, and the solution in #43.
It’s annoying, and I share the frustrations of others, but luckily we have some pretty smart people contributing to this project. Sadly, however, there seems to be some bleed between the beta channel and the stable channel. This should have been caught in the beta. However, I guess there aren’t enough folks running the beta.
I’m still a newbie getting to grips with HA’s architecture, but once I have, I promise to switch to the beta channel to help out where I can.
I’ll throw my vote into this thread for changing the auto-update of the supervisor to a manual only update.
I really despise auto-updates on anything. And for exactly the reasons that this thread (and even more pointedly, especially the other one referenced by @Guff666 above) exists.
I guess I don’t have any idea why it was decided that the supervisor needed to be auto-updated when nothing else in HA is?
Maybe if that question could be answered it would at least help people understand why it was done. If there is no good answer then maybe that wasn’t the correct decision to make.
Whatever the reason, picking a random TLD and using that, is really a bad idea in general.
There are RFC’s for that.
Yes, internally Hass.io started to use *.local.hass.io, to not interfere with your own local setup, stick to RFC’s and following up recommendations from e.g., Microsoft.
As a result of that, fqdn’s must be used (which you should actually always do… .) .
Sorry, I guess I’ve never seen those lots of times.
However, since the supervisor is what people use to update their hassio couldn’t there be a notification that in order to update hassio/add-ons that the supervisor has to be updated first? Then the “update” button(s) could be disabled until the supervisor has been updated.
At least then people wouldn’t have to deal with potentially broken things without knowing why because of an auto-update.
I for one am not using a random TLD, I bought a .house domain and I use split horizon DNS so that hassio.mydomin.house resolves to an internal address when devices are inside and a public IP when elsewhere, it’s simple and RFC compliant to the best of my knowledge. Microsoft do not recommend using .local for Active Directory, it should be for example ad.mycompany.com, no user of this system owns or has access to hass.io, you shouldn’t be forcing the system to be using it in my opinion, it should use our own preferred local domains set via DHCP or manually - even if that is a .local one
@finity I personally agree, as said, that requires work, so maybe in the future. Feel free to help out on that.
@bucksbass Yep! I was commenting on the use of .home there.
As said before, the 180 release was to get rid of initial and unrecoverable issues. We hope to start work on getting information from the host NetworkManager via DBus soon, so we can get DHCP information to enrich the DNS configuration.
) I just cycled the power and all is working again.
)
I agree on the weekend thing, however, in this case… I could intervene because it is the weekend.
) .