Same after installing 0.114.1. Supervisor shows a message: You are running an unsupported installation.
Also, this is in my logs:
20-08-15 15:37:21 ERROR (MainThread) [supervisor.core] Using ‘Raspbian GNU/Linux 10 (buster)’ as the OS is not supported
@Tony321 that is not related to the Home Assistant Core 0.114.1 update, but to the supervisor.
It simply tells you, that the system setup you are running is custom and not supported by the Home Assistant project (it doesn’t affect anything else).
Thanks for the clarification. Not sure if I missed it but I think it should be mentioned in release docs. Right now, it seems like Supervised installation just dropped support.
The details are linked with the message. The release documentation is for Home Assistant Core, your are now talking about the Home Assistant Supervisor. Those are not the same things.
Oops…really sorry as I thought someone was asking about how to see the humidity. I was also having the same issue with Precipitation not rounding properly but as I am interested in humidity, changing to that kind of resolves the issue 
Based on this exchange, I don’t expect there will ever be straight answers to those questions.
LOL You are good at throwing gasoline on fires. You basically directed me at figuring something out, you could not do for yourself (even-though it is documented). Just because I’m not personally interested in the inner workings of the updater and could not provide your personal command/wish. I’m sorry to hear you don’t like how I like to spend my time though.
As told in that same thread as well: The updater and the supervisor diagnostics aren’t related either.
Nevertheless, thanks for pulling stuff out of context.
It was a simple question and you said you didn’t know the answer. Fair enough.
When asked who would know the answer you replied I should explore the code and answer it myself. Fair enough.
I tried but was unable to understand its workings, then discovered you directed me to explore code you had just modified 4 days ago. You were clearly knowledgeable enough to modify it so I asked for your help to understand it and you refused.
I wouldn’t call that a “fire”. You simply exercised your right to limit how much assistance you were willing to provide (but with fewer words).
Based on that, I surmised that it’s unlikely you, or anyone else from the core development team, will volunteer to answer the three questions posed in this thread.
- Who are the members of this team?`
Members of the Home Assistant project are listed here:
https://github.com/orgs/home-assistant/people
Please note, that a member can disable that listing, as GitHub allows that for privacy reasons. Not all these people have access. Only people that need to.
- How are they bound to the requirement of not sharing the data?
Simply put, they are not / asked to. However, it doesn’t contain personal data either.
So this all is based on trust. If you trust this GitHub org to handle it, please share, it is appreciated (I guess around 10+ bugs already solved!).
But if you have any doubt, just leave it off.
- Who owns the information and where is it stored?
As Home Assistant isn’t a formal entity, I would probably say Paulus? It is stored and handled by Sentry. All code that handles this is open source as well.
I didn’t, I said it was documented. I never said to read the code.
This is correct.
Thank you frenck for providing answers; better late than never.
Thank you balloob for confirming the answers.
I see. Did you mean updater’s documentation? I had included an excerpt of it in my post. It only provides a general idea of what is reported, not a definitive list of all collected metrics. That’s what I had hoped you would be able to clarify.
Anyway, it’s moot given that you said the data is not being used. So whether “installation method” is or isn’t reported, the end-result is the same.
FWIW, the only reason I turned on updater was to report the fact that I use the Supervised edition. The impression and I and others had was that this information would be tabulated and provide the team with an accurate assessment of how many users actually use Supervised (to guide future decisions about this installation method). If the data hasn’t been used for that purpose since May, I have no further reason to keep updater reporting my system info.
Not to make any fire, but if you @balloob are storing this data, you do need a Uitvoeringswet Algemene verordening gegevensbescherming (you are in the Netherlands, aren’t you?).
It’s none of my business, really, but that could be a costly mistake. Did anyone you/your team took care of that? 
I got this too. plus I’m fairly sure before 0.114 I didn’t have these sensor.battery_xyz entities…?
ahh - hidden in the ‘complete changes’
Add battery sensor to xiaomi_aqara (@shenxn - #38004) (xiaomi_aqara docs)
hmm. how to sort this mess
I was trying the new Pihole switch entity and it works fine when I enable/disable the switch from Lovelace. However, when I disable Pi-hole directly in the Pi-hole admin page, the status of the switch doesn’t update to the right state. For example, if my switch was toggled as ‘on’, but I disable Pi-hole from the Pi-hole admin page, the switch state remains ‘on’ instead of switching to ‘off’. I confirmed that the sensor for the pi-hole does correctly read it as disabled. Is that a bug?
You probably need to add the entity to tha card so lovelace knows to update when that entity changes state.
Ok it does seem to be working. It just seems the polling for the state of the switch is slower than the status sensor from the iintegration. For example, upon changing the state in the Pihole admin page, I notice that the sensor catches the change at least 2-3 minutes before the switch toggles accordingly.
Is the switch state not based on the Pihole sensor status?
Yeah - I got caught by this too (Supervisor shows a message: You are running an unsupported installation.). Having since read around a bit, I am thankful that the Home Assistant Supervised (HA-S) configuration remains supported. But I have to say, I remain confused.
I carefully read all HA update bulletins, but was caught out because updates to Supervisor are not included in those bulletins. Yes, I should probably have known better by monitoring the forums, but there must be plenty of other people who had no idea that HA-S was deprecated, then put back again.
I would love it if the HA devs could include notes relevant to Supervisor in the HA update bulletins. It would be very helpful. I know that the release cadence is different (and automated), but I don’t think this is a reason not to provide updates.
I would also like to know whether my HA-S build is only temporarily supported by stay of execution, or whether it is for the long term.
I am running HA-S on a Debian 10, built on an Intel NUC. I got a shock yesterday when I saw a new message in the Supervisor log saying that I was running in an unsupported environment. After carefully studying ADR-0014, I discovered that I didn’t have docker configured for journald logging. I was able to fix that, and now I don’t get the error message any more.
I don’t have any obsession about staying with an HA-S build, but when I initially built my NUC, this appeared to be the most straight-forward, well documented way to get going. Still today, I can’t find a better supported installation for an Intel NUC with NVME system drive (there are some hackish looking workarounds, but not much more).
I don’t love building a OSs for fun. I’d really appreciate not being caught out again. Some better communication would help.
See my response to you above your last post and that will fix it!
This law applies to businesses, Home Assistant isn’t an business entity and/or commercial entity.
He is originally a Dutchie, but nowadays lives in the United States.