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.
No! It is still only a mean and not the needed/wanted real data. What brings a mean of 5 if the values are in the timeline of the timeframe 00001111599990000.I wand to now, when it was 1 and when 9 for example.
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.
26 posts were merged into an existing topic: Journal issues with supervised install after updating to 2022.11
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.
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)…
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?
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.
Maybe in the future.
We kept that out of scope for this iteration. Initially, it isn’t expected for water to be widely used. The amount of available hardware and integrations that can support it is really low as well at this point.
Who knows what the future has in stock 
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.