The "Pool Monitor Card" is a home assistant plugin that display information of 1 to 12 pre-defined sensors of your swimming pool : temperature, pH, ORP levels and TDS but also if you need them : salinity, CYA, calcium, phosphate, alkalinity, filter pressure , free chlorine, total chlorine
54
stars
13
forks
source link
[FeatureRequest] yaml config arrays VS single configurables #25
Is your feature request related to a problem? Please describe.
To easily enable use cases where there's more than one of a sensor type, it would be really nice to switch the data structure to an array/list object. This could/would be a breaking change, but you could retain much of the existing code to be backward compatible if desired, and add a new branch to support arrays.
Describe the solution you'd like
An example is with my Hayward Omnilogic controller I have multiple sensors for temperature and salinity (instant read and average).
Currently this is solved via a temperature and temperature_2 setting.
I believe moving to a data structure as such for every monitor type would be a better model, offer more flexibility, and potentially support more sensors, pools, combinations thereof out on the market:
We'll use temperature and salinity as an example here:
temperature:
- name: Water Temperature
unit: °F
entity: sensor.mypool_water_temp_sensor
setpoint: 80
step: 2
- name: Air Temperature
unit: °F
entity: sensor.mypool_air_temp_sensor
setpoint: 75
step: 2
salinity:
- name: Average
entity: sensor.mypool_avg_salinity
- name: Instant Read
entity: sensor.mypool_instant_salinity
Describe alternatives you've considered
Add more <MONITOR>_2 per monitor types, which is not very practical in the long run.
Is your feature request related to a problem? Please describe. To easily enable use cases where there's more than one of a sensor type, it would be really nice to switch the data structure to an array/list object. This could/would be a breaking change, but you could retain much of the existing code to be backward compatible if desired, and add a new branch to support arrays.
Describe the solution you'd like An example is with my Hayward Omnilogic controller I have multiple sensors for temperature and salinity (instant read and average).
Currently this is solved via a
temperature
andtemperature_2
setting.I believe moving to a data structure as such for every monitor type would be a better model, offer more flexibility, and potentially support more sensors, pools, combinations thereof out on the market:
We'll use temperature and salinity as an example here:
Describe alternatives you've considered Add more
<MONITOR>_2
per monitor types, which is not very practical in the long run.Additional context N/A