bencorrado
Oral-B support!!! Great work and thanks to the team, so many improvements here!
2 replies
Oral-B support!!! Great work and thanks to the team, so many improvements here!
2 replies
Been running the beta with no ill effects, great release 
Eagerly awaiting it to be pushed to my system so I can play around with the Lifx improvements 
WTH, what a release, again!
Thanks for your ongoing efforts guys.
Nice!! Water meter is really nice and the refinement on automation reloading is great too!! love this.
1 reply
Do you know how to configure it? I have counter counting liters of water. I created a template sensor
sensor:
- platform: template
sensors:
water_m3:
unique_id: "d031e12f-77f1-4270-bde0-0f31eff697bc"
unit_of_measurement: m³
value_template: "{{ states('sensor.boiler_counter_c1')|float(0) / 1000.0 }}"
device_class: water
I see it with correct unit but energy dashboard setup doesn’t show it.
2 replies
There’s a PR in the works for vscode to update the schema for water
The entry asks for sensor with unit m³ or gl. I created exact same template sensor with L and can’t add it to the dashboard
Nice release!
The only warning I received on container restart was ‘certificate’ deprecation from MQTT. Removed and all good.
You are the best! I wanted many things that have been released in this release, e.g.
unique_id fieldsMany thanks!!!
I started to get “ERROR (MainThread) [homeassistant.setup] Error during setup of component ssdp” after updating my HA Docker. Because SSDP isn’t working it broke several other integrations I have. Any recommendations to fix this before downgrading? Thank you!
2 replies
Great release!
But I’m using hassio-addons/google-assistant-webserver at master · AndBobsYourUncle/hassio-addons · GitHub and after updating to this release “rest.notify” no longer works.
“Unable to prepare setup for platform rest.notify: Unable to set up component.”
I didn’t see any mention of something related to it in the breaking changes, so I assume it should still work?
I’ve just updated to this release, so haven’t done any kind of debugging yet to try to figure out why it stopped working.
EDIT:
Disregard this post… for some reason, restarting HA two times after the upgrade got it working again.
That fixed it. Thank you @silvrr as always you’re a huge help!
Newest release of OpenSprinkler integration fixes it. It was just released.
Newest release of OpenSprinkler integration fixes it. It was just released
I’m running HA Supervised in a docker container on Debian and getting an unsupported OS error with this release. Couldn’t find anything in the notes. Anyone got any ideas?
2 replies
The repairs are just highlighting what was already there. There are no new reasons a system is marked unsupported in this release, it’s just now if the system is unsupported HA shows the user with a repair.
If you’re seeing this one then you are running supervised on an unsupported OS. Running supervised on any OS besides Debian 11 (Bullseye) is not supported. That includes derivatives of Debian such as Raspbian, Ubuntu, etc. Those are not the same as Debian 11 and running supervised on them is not supported.
If you’re seeing a different one, please clarify which one you’re seeing by sharing the more info link.
@integray182 same to you as well. Click the links to see the explainer, if you’re still confused then share which links you’re seeing.
1 reply
The Gas section of the energy dashboard is no longer adding additional “Gas sources” e.g. Wh 
I`m unable to setup Airthings BLE. I get very long wait for wizard and then there is an error msg.
I have the Wave model, also I have the right dongle which worked with Airthings on Python script
All of which you can click on and find out why.
Thanks for this - yet another - great release. As for now I’m using Home Assistant mainly to narrow down my utilities costs, the additional Water Usage Integration into Energy is just great.
Getting insights into water usage
Since Home Assistant added energy management, tracking the usage of water🚰 has been requested quite a bit. It was raised again during this month of WTH, and with over 370 votes, it is clearly wanted a lot.
This release adds the ability to monitor your water usage in the energy dashboard!
Although water is not strictly “energy”, it is still a valuable resource to track. It is often tightly coupled with energy usage (like gas) when using hot water, and the gained insight can help you reduce your ecological footprint by using less water
.
Love the Home Assistant ecosystem and a big shout out to all developers making Home Assistant as great as it is.
/m4v3r1ck 
Nice release, as always. Updating from the beta right now.
I have a few Picture Elements cards configured to control my lights, but this is now broken - images on top of the picture are now gone and nothing happens if I click on the spot where the dots (images) should be. Resources (images) are locally accessible.
I didn’t find anything noting why this could be broken (in breaking changes for instance). Anybody else with the same problem?
This is my Picture Elements card config:
After 8 restarts they are back again
I use GitHub - weetmuts/wmbusmeters: Read the wireless mbus protocol to acquire utility meter readings. to track water usage, I think it is quite common and should maybe be mentioned on the Integrating your water usage - Home Assistant page.
Hello , Great HA release, it’s again amazing work !
I see a change in automation mode: restart which now, not stoping the previous automation when automation start again with another trigger.
It’s appearing on automation using trigger with duration. I use motion start and motion stop (for duration:2min).
If a motion is start: light is on
if motion stop for 2min: light is off.
I see that motion start is appearing after 20sec of motion stop but the light is going off with the previous automation
Previously (2022.10.4), if a new trigger is coming, the automation is fired and the previous automation was cancelled (which is the purpose of restart mode).
1 reply
Thanks for the new release!
I’ve discovered one change in my own installation: All locally stored images/icons in my Picture Elements Cards are gone. Files are still in place (folder www) and I made no changes in my cards so far. No error messages in the log files.
Edit: Solution adding “width” as described in the issue below make the icons appear again.
2 replies
I’ll open an issue on Github.
Anyone get Invalid Config Error after restart?
Invalid config
The following integrations and platforms could not be set up:
Please check your config and logs.
Logger: homeassistant.setup
Source: setup.py:357
First occurred: 11:24:11 (2 occurrences)
Last logged: 11:24:11
Unable to set up dependencies of upnp. Setup failed for dependencies: ssdp
Unable to set up dependencies of dlna_dmr. Setup failed for dependencies: ssdp
I love this release. Water uage, First Day of the Week. New cards. Esp. Icons in automationlist Just everything…
… BUT
Long-term statistics in the entity dialogs without giving he user the choice of having it, is really really not good.
During beta times there where a lot of complains about this from a lot of users. And at least I have seen only one user, who wrote, that there might be some cases, where this is helpful.
In all of my cases, it gives no benefits and only hides the real short history data, I’m interested in, when I click on the details. I want to see the raw data, the e,g, raw fuel prices, the raw power values, when it changed to exactly what and when and from what. And no mean or may or min in the used timeframe.
I respect, if the developer, who has implemented this likes this personally and implemented it because of this. But please please give the user the choice to have this or the really useful raw view as before.
2 replies
With this update my state-switch cards don’t work anymore (they don’t show anything at all). Here is an example:
type: custom:state-switch
theme: mashrooms
default: default
entity: user
states:
Famiglia:
type: weather-forecast
entity: weather.openweathermap
show_current: true
show_forecast: true
theme: Mushroom
default:
type: custom:weather-card
entity: weather.openweathermap
current: true
details: false
forecast: true
number_of_forecasts: '5'
Any advice?
It does only show the “long term statistics” with min / mean / max for entities that have such history.
you can change the behave by disabeling the “min” / mean" values, for example:
full statistic:
disabled min & mean:
other sensors, that don’t have a long term statistic, will just show the “state history” as we know it:
I think, that’s a pretty good compromise - it could maybe be optimized… for example while providing the following in the yaml file:
default
tap-action:
action: more-info
idea:
tap-action:
action: more-info-statistics
sure, but the point is, that all of the sensors we are interested in are enabled in the LTS, so now show these graphs.
and they don’t convey what we are after: state changes… we can see the actual state changes by clicking on Show more though. But that is yet another click.
1 reply
And this removes the temporarily “saved” entities of the history view every time. If I put there 5-6 entities I want to monitor during the day, they are gone with every “show more”.
Hi! Great release again. Will tiles support templates in the future?
Arganto, the devs have stated in #beta this is what it is now, and we will have to see what the future brings. Paulus doesnt like the ‘option’ idea (which I personally feel is too bad really, what’s HA without options…)
No matter how I have tried the last week, I can not find any generic use for the new statistics graph. The few occasions I do need them, I use a dedicated statistics-graph card.
The reason we have this is for frontend efficiency, supposedly this would be way faster. Honestly, there’s not a single card in my complete setup that draws faster now.
The few cards combinations using history that in fact cause trouble now and then are apex charts and minigraph cards combined.
the move from 1 hour to 5 minutes is a bit less cluttered, but I still find the graphs terribly unclear, and they dont hold the info I am after. Might as well not show them at all for that matter. But thats me ofc, as always ymmv.
2 replies
sorry - I cannot really agree…
I don’t have much sensors providing / using the long term statistics… most of them are valid for my EV battery… and if I disable “min” and “mean” - and only use the “max” value on the graph, that does exactly match the statistics I had before…
max != mean
Maybe, you can exactly show, what you are meaning with “They don’t show state changes”?
Personally, I have to say, that everywhere - where the new Min / Mean / Max statistics are shown - it does totaly make sense to me …
then you wont have the issue…
well, what are your seeing here then? the mean voltage isnt that useful? or the max/min for that matter. on a certain point in history you need the actual voltage, and not all of those derivatives ?
First. As I said. If you like it fine. Because of this I suggested the option. Currently you are (only) the second who likes this. But only, because you do not see the disadvantages until now?
Secondly, see above. 00001111599990000. If you have this values in the timeframe, you will not see, when it changed to 1 and when to 9, but only see 5. And you will see 0 and 9 for min max. but not that was a long time 1.
1 reply
hm… probably, I am only the second one who replied here that I do like it 
I think - most of the people just don’t care - and don’t reply at all…
The thing is:
When I need the history, I want to see a statistical view of Sensor values.
I don’t care, if my voltage was “0” for a second or two - three days ago.
If it is 0 for a time where I need to worry about, this will be reflected by the Min and max and also by the Mean value…
Every other “immediate” state change - can still be covered by automations, scripts and whatever else.
The “history” should provide a history and a statistic - and this is still the case, in my eyes.
But there’s an easy solution for that:
You can still create template sensors that use the state of your actual sensor - but don’t have “state_class:measurement”… then, you should get the history just as you are used to it.
For the majority of people, I still think, the long term statistics are still working great… and we already had to use templates if we wanted specific sensors to write them (but we were never able to see these without having a dedicated statistics card on the dashboard)…
1 reply
Getting insights into water usage
(…)
Although water is not strictly “energy”, it is still a valuable resource to track. It is often tightly coupled with energy usage (like gas) when using hot water, and the gained insight can help you reduce your ecological footprint by using less water
Perhaps it would make sense to rename the dashboard to Utilities?
1 reply
as said, it all depends on your wishes/needs.
Having a total of 4639 entities, of which 2225 are sensors. I curated my filters on recorder, so it only tracks about 230 or so. Of those, I might need max 10 statistics graphs. Which I added to my frontend.
The rest I ‘need’ the actual state changes. That is because I regularly check the more-infos on those. Power sensors for example, or temp/humidity. I want to check the immediate effect of opening a window etc etc. clouds on the solar panel…
I love the imagery of the statistics graphs, but for my usecase they are only beautiful to look at.
Is anybody else having the issue that long-term statistics / history seem to have been reset/deleted? E.g. if Ido a ‘compare’ in the Energy dashboard I only see today’s data. It worked before I upgraded to 2022.11.
there’s another thing I now notice on stats:
my processor usages has yet again gone up to an average of 11.27%. 2 release ago that was 6/7. Also mem is still creeping up, now to round 22%. huge jumps, and no release, really odd.
no idea what is causing this, but I sincerely suspect the new BT proxies and the devices on those proxies to cause this. It has been the only fundamental change in my config…
So HHCC didn’t make it?
Edit:
No replies, so I’m rephrasing the question. Passive BLE Integration is currently being integrated to Home Assistant. I’m using Tilt Hydrometer (million thanks again @Ernst for this), HHCC plant monitors and RuuviTags. Passive BLE GitHub page says that “Expected in November release, Oral-B and HHCC”. I see Oral-B, but not HHCC. RuuviTag seems to be still in development.
Hi,
I am also having the same problems as Cataseven. Exactly the same errors in my log files, regarding ssdp and default_config
anyone an idea how to solve this?
UPDATE: Problem solved here by putting this into configuration.yaml:
homeassistant:
internal_url: "https://<MYHOST.MYDOMAIN>:8123
Did I perhaps miss a breaking change somewhere (in the past)?
Since this update I receive the following error during rest setup:
Unable to prepare setup for platform rest.sensor: Unable to set up component.
→ Resource not set for RestData
2022-11-03 10:36:02.024 ERROR (MainThread) [homeassistant.setup] Error during setup of component rest
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 235, in _async_setup_component
result = await task
File "/usr/src/homeassistant/homeassistant/components/rest/__init__.py", line 77, in async_setup
return await _async_process_config(hass, config)
File "/usr/src/homeassistant/homeassistant/components/rest/__init__.py", line 97, in _async_process_config
rest = create_rest_data_from_config(hass, conf)
File "/usr/src/homeassistant/homeassistant/components/rest/__init__.py", line 185, in create_rest_data_from_config
raise HomeAssistantError("Resource not set for RestData")
homeassistant.exceptions.HomeAssistantError: Resource not set for RestData
Nope, rest has always required a resource. Make a new thread and post your yaml & error.
Had the same issue. thanks @Bluehawk83 for pointing to fix this. Working again!
Exactly the same experience here. Those cards are not loading faster for me at all. Using MariaDB, 14 days of history in the recorder.
Tile: very interesting card , it should be nice to show attribute of an entity in it .
like
type: tile
entity: sensor.sensor
type : attribute
attribute: name
Thank you for submitting this issue. My floorplan is empty 
cant you use browser-mod to use a history card popup on more-info?
I can see it being useful to detect water leaks, monitor device efficiency. The reality is that to buy the hardware and plumb the device into the home would be costly and labour intensive.
1 reply
it was requested many many times in the wth and feature requests - so, why not having it?
you don’t need to use it, if you don’t want to buy the hardware - but many others already had the hardware up and running - and the only place where it was missing - was the dashboard
The changes to the ZAMG integration should be listed as breaking changes, for
a) some of the monitored_conditions are not recognized anymore
Invalid config for [sensor.zamg]: value must be one of ['dewpoint', 'dewpoint_average', 'humidity', 'precipitation', 'pressure', 'pressure_sealevel', 'snow', 'sun_last_10min', 'temperature', 'temperature_average', 'wind_bearing', 'wind_max_bearing', 'wind_max_speed', 'wind_speed'] @ data['monitored_conditions'][7]. Got 'sun_last_hour'. (See ?, line ?).
b) some of the entity_ids changed (most likely because the friendly names of the sensor family (the “suffix” for all monitored conditions) cannot be overridden anymore)
For example:
- platform: zamg
station_id: 11389
name: St. Pölten/Landhaus # The name fetched from the Server is "ST.POELTEN LANDHAUS"
...
resulted in entity_ids of sensor.st_polten_landhaus_*, instead of sensor.st_poelten_landhaus_* (o→oe).
The dashboard now throws this massive chain of capital letters at you: “ST.POELTEN LANDHAUS dewpoint”, as one example.
And last but not least: For the first time while using this integration (on several HA instances and for more than a year now) I observe a lot of failed data fetches, resulting in unknown sensor states – is it blocked due to too many requests? (I fetch data from 2 stations)
Some log examples:
Logger: homeassistant.components.zamg
Source: helpers/update_coordinator.py:151
Integration: Zentralanstalt für Meteorologie und Geodynamik (ZAMG) (documentation, issues)
First occurred: 11:40:29 (2 occurrences)
Last logged: 11:51:03
Timeout fetching zamg data
Logger: homeassistant.components.zamg
Source: helpers/update_coordinator.py:151
Integration: Zentralanstalt für Meteorologie und Geodynamik (ZAMG) (documentation, issues)
First occurred: 10:15:12 (5 occurrences)
Last logged: 11:45:52
Timeout fetching zamg data
Error requesting zamg data: Cannot connect to host dataset.api.hub.zamg.ac.at:443 ssl:default [Connect call failed ('138.22.160.100', 443)]
Has anyone had issues with authentication to Jandy / Iaqualink? I note there was an upgrade to the integration in the full change log. Restored back to 2022.10.5 all good. Upgraded my test pi to 2022.11 and could not get it to authenticate either
2022-11-03 22:25:44.954 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
File “/usr/local/lib/python3.10/site-packages/aiohttp/web_protocol.py”, line 435, in _handle_request
resp = await request_handler(request)
File “/usr/local/lib/python3.10/site-packages/aiohttp/web_app.py”, line 504, in _handle
resp = await handler(request)
File “/usr/local/lib/python3.10/site-packages/aiohttp/web_middlewares.py”, line 117, in impl
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/security_filter.py”, line 60, in security_filter_middleware
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/forwarded.py”, line 100, in forwarded_middleware
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/request_context.py”, line 28, in request_context_middleware
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/ban.py”, line 82, in ban_middleware
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/auth.py”, line 236, in auth_middleware
return await handler(request)
File “/usr/src/homeassistant/homeassistant/components/http/view.py”, line 136, in handle
result = await result
File “/usr/src/homeassistant/homeassistant/components/config/config_entries.py”, line 180, in post
return await super().post(request, flow_id)
File “/usr/src/homeassistant/homeassistant/components/http/data_validator.py”, line 73, in wrapper
result = await method(view, request, data, *args, **kwargs)
File “/usr/src/homeassistant/homeassistant/helpers/data_entry_flow.py”, line 110, in post
result = await self._flow_mgr.async_configure(flow_id, data)
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 280, in async_configure
result = await self._async_handle_step(
File “/usr/src/homeassistant/homeassistant/data_entry_flow.py”, line 367, in _async_handle_step
result: FlowResult = await getattr(flow, method)(user_input)
File “/usr/src/homeassistant/homeassistant/components/iaqualink/config_flow.py”, line 41, in async_step_user
async with AqualinkClient(username, password):
File “/usr/local/lib/python3.10/site-packages/iaqualink/client.py”, line 72, in aenter
await self.login()
File “/usr/local/lib/python3.10/site-packages/iaqualink/client.py”, line 126, in login
r = await self._send_login_request()
File “/usr/local/lib/python3.10/site-packages/iaqualink/client.py”, line 121, in _send_login_request
return await self.send_request(
File “/usr/local/lib/python3.10/site-packages/iaqualink/client.py”, line 92, in send_request
self._client = httpx.AsyncClient(
File “/usr/local/lib/python3.10/site-packages/httpx/_client.py”, line 1386, in init
raise ImportError(
ImportError: Using http2=True, but the ‘h2’ package is not installed. Make sure to install httpx using pip install httpx[http2].
I have X sensors:
— X1 sensors - provided by integrations;
— X2 sensors - manually created template sensors.
Some sensors from integrations may be stored in LTS - but they are NOT since I excluded them from Recorder.
Some template sensors are excluded from Recorder. Some of not-excluded have “state_class: measurement” - and stored in LTS.
Now we got Statistics in more-info pop up - instead of a real history - and this is:
— less informative;
— confusing - since some sensors are not in LTS, then probably the real history is supposed to be shown.
I would restore the previous more-info - but with one more “Statistics” tab - only if the sensor has LTS.
Does anyone have problems with adding cards to lovelace? I can add cards by entity but adding them by card the list is just blank. Same thing on Home Assistant application on Android.
EDIT: Solved problem by moving atomic-calendar-revive to test dashboard. After that “by card” list is back to normal. Although same problem exist with my test dashboard but problem is clearly with this custom card.
1 reply
I really don’t like what they did with the entity history. When I open an entity I want its exact short term history, with every state change. Not some averaged approximation. I’m going to override them.
Already tried that with couple of reboots also. Strange because by entity everything is normal and this problem exists even on a totally new device. Maybe just waiting for some updates…
the new “Tile” card does recreate the look and feel of the mushroom cards.
Unfortunately, there are some details, which are not working “as a replacement” or addition to existing mushroom cards:
As you can see in the Screenshot, I’ve tried to compare mushroom cards with the new tile card.
also, the mushroom cards use a text style which is a bit more “bolt” than the tile card… that doesn’t look well when you are using the cards together in a layout…
2 replies
Design is a very sensitive thing.
I never used mushroom cards (but I really really admire the work) only because of «too rounded cards». I hate round corners (not more than 4px), round background for icons, very very hate round persons’ avatars.
It is personal…
Isn’t the mushroom card guy working for NC now ? I seem to remember some announcement like this ? Would certainly explain the mushroom-like-but-not-quite design
I already got that “it is not mushroom” - but since Paul is now working for NabuCasa it is clear, where the design came from 
And it would be nice - if we do have at least a “mushroom-alike” card, that the look and feel would match more closer to the original?
at least, what can be done:
In Mushroom Git an issue could be raised that the musroom cards to not apply to the themes font-design (regarding the bold entity status)…
Compared Mushroom / Tile Card with different themes:
Hi guys, I would also like to express my disappointment regarding the more info statistics graphs. No consistency and detailed information are getting lost. Please revert, there are so many other things which could be improved. I have one or two sensors which benefit from this, but this is the minority. A lot of sensor just look unsharp now:
I noticed that with this release if you use the map card in a grid card that your home/device is not centered in the middle but centured at the bottom of the page.
Please reconsider the More Info change from history to statistics data by default.
I think it is great to have better access to the statistics data, but when I click for more info, I want to see the fine grained detail, especially for sensors that might change rapidly like power, voltage, (some) temperature sensors.
I want to know When something changed and often want to see how fast it changed.
If a value briefly dropped or spiked, I want to be able to easily see that. There have been times where casually glancing at More Info has alerted me to something that I didn’t know was happening. If I have to dig for it, I’d rarely find those.
The releases have been really great and over the last year or more. So thanks for all the care that has gone into them.
1 reply
Found a bug. It’s related to a new longer name of CO2 Signal leaf in some languages such as Romanian.
Smart reloading of automations, Water usage, Gigajoule support, What a great release this is! Thanks 
please tell me:
What can you pick from the “old” history information, that you can’t pick from this statistics information?
In my opinion, the new statistics do provide a more detailed way for analysing any potential issues…
And I DO agree, that is doesn’t probably make much sense on all sensors…
But then, it could be considered, if it is required that these sensors have the state_class “measurement” or any other state_class that is writing long term statistics.
In fact, In my opinion, it does make sense to use this type of statistic on sensors that actually generating statistics with min/mean/max information.
For sensors, where I don’t want to use this, I can create templates - or, I haven’t really checked any history … at all…
The correct decission here can be pretty difficult I guess…
We are used to have the History with a clear “state changed from x to y” chart…
But on the other hand - I had to create a Dashboard with statistics card for each entity where I wanted to get such information… having that in the more information is a BIG improvement in my eyes…
What could the compromise be?
A parameter which you can use to decide what type of statistic can should be displayed?
Including both? and make it selectable?
Include a forth option into the graph for “state” - which can then be enabled or disabled?
wtv1211’s comment is correct. It depends on the set language whether the figure falls apart or not. If I change the language to English, the graphics will be ok.
I meant with my example, that you easily can adjust Mushroom via theme.
