Command line’s configuration changed 6 months ago and you’ve had a warning in your logs to update that configuration. This past release removed the old configuration and only the new configuration works. So update your command_line configuration before or after you update HA.
1 Like
Would anyone know how to change the color for better-thermostat-ui?
At night my heating goes off according to schedule, but it stays green, implying it’s still on.
I’d like it to show in gray when the state is set to off.
Even doing this with card_mod would be fine, just can’t find what elements holds the color.
HA View
Tado App
warnings in logs? Which logs? Can you point me to the log that contains this information?
I was warned about template sensors and moved them from configuration.yaml to ui helpers. Since then warning disappeared. Command_line sensors were never mentioned in any of the notifications or logs - checked again in restored 2023.11.2.
Also am I supposed to dig through gigantic logs every time I decide to update?
No, a repair showed up and you would have clicked “I fixed it” or “ignore”. After that, you would have to dig through your logs.
Sorry, I don’t have a log example handy.
1 Like
The short answer is,
var(-- state-climate-auto-color)
BUT
it appears to me that your BT thermostat card is showing the correct colour.
It is set to auto, meaning it is following your schedule which might be on, off, heating - whatever.
If you look at the climate entity for your card in Dev tools > States, I am sure it will show the state as ‘auto’ not ‘off’.
To prove this you can click on the off icon on the thermostat card and it will give you the result you want.
Also I can see from your screenshot that the BT card is showing a temperature of 20.3 degress and a target of 20.3 degrees BUT your Tado screenshot is showing off.
As I don’t have a Tado setup I don’t know how Tado interacts with HA with setting setpoints, however I would have thought if Tado was ‘off’ then it would have changed the setpoint but this clearly isn’t the case.
Maybe Tado, in this scenario is just overriding the thermostat by turning the boiler off, if this is the case then you wouldn’t be able to change the colour of the card by the climate entity state.
Just a guess 
Regarding
1. I noticed that LTS is not available for MANY (even “gold platin super deluxe”) integrations, for example
- “Switch as X” integration
- Shelly integration
- deCONZ integration
- …
They all do not provide proper settings so that LTS is being generated, therefore the history ends with my previous recorder purge_keep_days setting (14 days):
2. Why does this NOT work for automations and scripts?
Seems like - again - those are not taken into account. And yes, for some people it might be very important to know which automation was switched on or off 18 days ago.
Looking into details - being very thankful for that improvement! - it looks like one should carefully keep InfluxDBs etc. if existing, as not nearly the same amount of data really is available in HA through LTS.
EDIT / Update:
I think all entities I had a look at and they did not have LTS, have one thing in common: they are some kind of binary: switches, binary_sensors etc. - so one question:
Is LTS “only” generated for non-binary (visual/graphical, so numeric) based entities?
That information would at least bring users in a situation where they can decide to e. g. only import data to InfluxDB or similar data warehouses that is not LTS enabled in HA. A ruleset could be “domains switch, binary_sensor, automation, script, …”). That’s really what I’m looking for with this post
Long term stats is only for numerical sensors.
Thank you. That’s very good to know.
But:
- Why (only)?
- Can we change that?
because you can’t run statistics on non-numerical information…
What’s the min and max of on/off? What’s the mean? Long term statistics is for numerical information where you need to generate statistics, like for the energy panel.
Ah I see. It’s so obvious that you need to remind yourself from time to time what the S in LTS stands for
So there are still good, VERY GOOD reasons to keep existing long term infrastructures (like an InfluxDB). At the same time the recommendation…
If you have manually modified the days to keep before purging recorder on your system, consider removing that customization. With the long-term statistics and new feature, you most likely don’t need it anymore, resulting in a smaller database and, thus, faster and smaller backups.
…at 2023.12: Welcome home! - Home Assistant sounds a bit strange. But well, “consider”, “most likely”, the wording leaves quite some room.
Maybe one needs to redefine LTS (LTS 2.0) and focus on more data, not “just” the numeric one. I’d appreciate that because kicking InfluxDB would feel so good.
You could turn an On/Off into percent on for an hour or percent on for a day. This does introduce a concern over summarizing the values. Solve that by storing the minutes in an hour when on. That value is sumerizable.
this doesn’t account for unavailable and unknown, with 4 values, the average would not mean what you think it means.