ildar170975
commented
4 months ago In addition:
it is unclear how to add sensors & keep a default forecast_days.
Closed ildar170975 closed 4 months ago
ildar170975
commented
4 months ago In addition:
it is unclear how to add sensors & keep a default forecast_days.
Limych
commented
4 months ago In addition: it is unclear how to add sensors & keep a default
forecast_days.
Let's first solve the problem of adding sensors that is unclear.
Now it is possible to change the format of the settings. I see several ways:
sensors group with the show_sensors option and move all the contents of the group to a higher level.Your suggestion?
Limych
commented
4 months ago BTW, minimal config now is
gismeteo:
home_gismeteo: {}My assumptions are based on Docs; so I could be wrong if an implementation is different.
Currently we have this structure:
sensors:
forecast_days: xxxSeems the sensors option is a dictionary with the only sub-option forecast_days.
Probably you may add more sub-options inside.
If you move the sensors options into another option or replace it with another option - it could be considered as a breaking change; not cool to have it again after "3.0.0-beta1" - some users have already considered 1st breaking changes in their HA setups.
From another side, these are still "beta" updates (people are using betas on their own risk), so you still can change everything. Besides, I guess most people using UI config & do not care about changes in yaml config.
Assume you decide to keep the current structure "sensors -> forecast_days".
What we may wish to configure is:
1.Create (or not) forecast sensors; if yes - for how many days.
If forecast_days is 0..6 - then forecast sensors are created.
If forecast_days is missing - not created.
2.Create or not sensors. Here there are 2 ways:
2.1.If "yes" - then ALL sensors are created - but only SOME of them (up to a developer to decide) are enabled, rest are disabled.
By default - none sensors are created (only a weather entity).
This way may be achieved by adding a new option:
sensors:
... other possible options ...
add_sensors: trueIf the option is false or missing - none sensors are created.
Note that forecast_days must be ignored if add_sensors: false: not possible to add forecast sensors if you do not add "usual" sensors.
User may define add_sensors: true, then enable/disable sensors as he wishes.
If needed - may define forecast_days.
2.2.Another way - user may list all sensors which should be created:
sensors:
... other possible options ...
add_sensors:
- temperature
- pressure
- humidityHere 3 sensors are created and enabled, other sensors not even created. This value causes "none sensors are created":
add_sensors: []Same - if the add_sensors is missing.
And probably add_sensors & forecast_days should be independent (contrary to way 1 above), i.e. it could be possible to define
sensors:
... other possible options ...
add_sensors: []
forecast_days: 2since the add_sensors option is only used for "usual" sensors.
Although this way allows to define only needed sensors (and do not depend on UI - which is great for users who prefer configs in packages) - I find it confusing:
-- need to check entries in add_sensors, a user may define temprature instead of temperature;
-- some parameters may be renamed in future, a user have to track these changes;
-- imho there is a little of sense in having options add_sensors & forecast_days independent.
So, I would choose way 1.
As for a minimal config. Assume we have a structure:
gismeteo:
home:
sensors:
add_sensors: true
forecast_days: 2Since both sub-options are optional - this leads to the minimal config
gismeteo:
home:
sensors:which has no sense. So I would choose these minimal configs as allowed:
gismeteo:
home:
sensors:
add_sensors: truegismeteo:
home:As for this
gismeteo:
home: {}imho it does not follow usual ways in HA: check these examples of minimal default config:
input_boolean:
some_boolean:
recorder:
demo:The option with an explicit indication of the sensors to be added is untenable. That's why it was initially removed from version 3.
As for a minimal config. Assume we have a structure:
gismeteo: home: sensors: add_sensors: true forecast_days: 2Correct. But what’s the point in the
sensorgroup? You can write it shorter like this:gismeteo: home: add_sensors: true forecast_days: 2
ildar170975
commented
4 months ago But what’s the point in the
sensorgroup? You can write it shorter like this:gismeteo:
Sure, I proposed to keep forecast_days inside sensors only to avoid "breaking changes".
But it is definitely simpler & clearer to get rid of this sensors option.
So - yes, totally agree with
gismeteo:
home:
add_sensors: true
forecast_days: 2where both add_sensors & forecast_days are optional.
The final question - can it be defined as below? (minimal config)
gismeteo:
home:w/o that "{}".
Limych
commented
4 months ago The final question - can it be defined as below? (minimal config)
gismeteo: home:w/o that "{}".
Already done but not pushed to github yet.
ildar170975
commented
4 months ago Well done, thanks a lot! Awaiting for testing then.
Limych
commented
4 months ago Another question: does it make sense to give the user the opportunity to create forecast sensors without current weather sensors? I'm not sure.
ildar170975
commented
4 months ago create forecast sensors without current weather sensors?
Imho this is meaningless. Earlier proposed:
Note that forecast_days must be ignored if add_sensors: false: not possible to add forecast sensors if you do not add "usual" sensors.
ildar170975
commented
4 months ago I think this issue can be closed. Can see changes in beta4. Tested a bit, works as expected. Thanks a lot!
System Health details
System Information
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 5000 Installed Version | 1.34.0 Stage | running Available Repositories | 1414 Downloaded Repositories | 54 HACS Data | failed to load: timeoutHome Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okDashboards
dashboards | 16 -- | -- resources | 39 views | 469 mode | storageRecorder
oldest_recorder_run | May 11, 2024 at 21:38 -- | -- current_recorder_run | May 18, 2024 at 04:17 estimated_db_size | 578.91 MiB database_engine | sqlite database_version | 3.44.2Checklist
Describe the issue
According to Docs - all options are optional:
But this minimal config
causes an error:
This config
causes an error:
This minimal config (provided in Docs) does NOT cause errors:
Also, it is said in Docs that the
but it is surely not a
sensorsoption is alist:listsince it has one sub-optionforecast_days(declared as optional).Reproduction steps
see above
Debug logs
Diagnostics dump
No response