period selector doesn’t work. Selecting 3 days or one week does nothing. It always shows data from current day. it’s inconsistent with documentation which says that default purge_keep_days is 10
meaning of “period selector” is misleading. When I select period of 1 day I expect to see recent 24 hours of data. HA at 1am HA only one hour from 12am to 1am. It’s a design flaw. And together with issue #1 makes it unusable in some scenarios.
graphs (those with units) mixes data from various sensors. Often in a useless way. I found no any information how to affect this behaviour.
order of graphs seems to be random. Again, no information about possibility of configuring this order. For a God sake, even alphabetic order would help.
selector always show the date when displayed period ENDS. Means if you want to display last week data you need to select date one week in the past and then select display period to be 1 week.
history is always shown from midnight of selected date to current time. So if you select yesterday as starting date and select 1 day view you will see 24 h of data from yesterday. If you then change view to 3 days you will see 24 h od data from yesterday and data from midnight up to now for current day. Obviously no data for future.
Graphs are grouped by sensors using the same units. So if you have several temperature sensors these will be grouped. If you have pressure sensors will be grouped together. Do not expect to have temp and pressure data from the same physical sensor being displayed on the same graph. There is also one catch i found in my config - sometimes sensors seems to display data in the same format, but sometimes it is number and sometimes text. Text will be shown as bar, numbers as graph.
Lets put use_include_order: True
in your history configuration. This will enforce specific order of graphs to be displayed. Obviously there will be limitations: bars will always go first, same type of sensors will be grouped on graphs.
@mirekmal, thank you for the tips. It really helps. I wouldn’t expect I need to use include directive for anything else than including. Also use_include_order is not mentioned in documentation in configuration variable section. It can be found in examples below, but how to find something you don’t know you even exists. Selecting history range is a design diamond on its own.
I must confirm that the design decisions taken for this part of the system are ridiculous. If HA has ambitions to target other users than software developers and computer geeks it must change.
Yeap, history is not very intuitive and there is huge area for improvement… Personally I’d vote for having some control over colors of bars/graphs, as now these are randomly selected and sometime eyes bleed from watching them
On your second comment… you are right, it is not the simplest automation system to use, but it is still work in progress… As you can see it even not yet the first major release version, just continuous beta! I must admitt it changed a lot since I started to use it (some time around 0.80) and more and more configuration items are going to UI and system becomes more and more user friendly… This is the price for flexibility and capability it brings in return under the hood!
Speaking about colors, those are not even fixed for the same states. Maybe except on/off which are green/red. But other states seem to be random and change over time.
I know HA is presented as WIP. Unfortunately it’s today’s trend to use WIP/beta/whatsever term as excuse (look at gaming industry as another example). Especially with conjunction with agile methodology (which is of cause wrong because no agile methodology allows/suggest such attitude) or open source model.
The problem lays not in the fact it’s WIP. The problem is that there is no (or minimal) effort to make things right at project start.
