Transform plant into a new type of entity component with platforms

[Djebouh]

Context

When defining a plant from a miflora device, you need to configure a miflora sensor (generating 4 sensors) and a plant device referencing these 4 sensors. When defining a plant from a remote device connected thru MQTT (I have intermediate ESP32 connecting to the device via BLE and broadcasting the data via MQTT), you have to configure 4 MQTT sensors, and a plant device referencing these 4 sensors.

This is feasible but hardly manageable at scale (I have 10+ local devices and 5+ remote ones). A first change was proposed under home assisitant PR #23889.

Proposal

The plant component should become a new entity component with platforms. Different plant platforms could therefore be implemented. It could also be instantiated from other components.

Consequences

It will be possible to define new components, creating at once sensors and plants. It would largely reduce copy/paste (and typo) and simplify home assistant configuration

[MartinHjelmare]

Please also describe the plant entity interface in the proposal, with required and optional entity properties.

[Djebouh]

@MartinHjelmare I do not propose any change to the properties of the initial plant. The current PLANT_SCHEMA remains unchanged, with the exception of SCHEMA_SENSORS that is delegated to the platforms. Plant entities will therefore have the same way of monitoring conditions (battery, temperature, brightness, moisture). The different platforms will only defer in the way they reference sensors. For illustration, I have started to try this idea here:

• plant component is updated as explained above
• _plant_fromsensors is equivalent to the initial entity
• _plant_fromprefix allows to create plans from sensors sharing a common prefix
• _parrotplatform is a component that creates sensors and plants at once for parrot pot. This is not yet aligned with home assistant standards as the library accessing the device is not externalized.
• _plantparrot is a plant entity that also creates the sensors, so equivalent to _parrotplatform

The configuration becomes:

sensor
  # needed for plant_from_sensors and plant_from_prefix
  - platform: parrotpot
    mac: 'A0:14:3D:CD:C5:C5'
    name: "Parrot_pot C5C5"

plant:
  # equivalent to the current plant identity configuration
  - platform: plant_from_sensors
    name: plant_with_initial_configuration
    sensors:
      battery: sensor.parrot_pot_c5c5_battery
      conductivity: sensor.parrot_pot_c5c5_conductivity
      brightness: sensor.parrot_pot_c5c5_light_intensity
      moisture: sensor.parrot_pot_c5c5_moisture
      temperature: sensor.parrot_pot_c5c5_temperature
  # the equivalent configuration as previous but for lazy ones
  # -> one single line to reference all sensors
  - platform: plant_from_prefix
    prefix: parrot_pot_c5c5
  # one single line, creating the plant and  the sensors (no need for the above sensor definition)
  - platform: plant_parrot
    mac: 'A0:14:3D:CD:C5:C5'

# one single line, creating the plant and  the sensors, equivalent to plant_parrot above
parrot_platform:
  - mac: 'A0:14:3D:CD:C5:C5'

[MartinHjelmare]

We have to define what attributes, moisture, battery, temperature, conductivity, brightness, etc should be required and should be optional for the platforms to implement and report. This will define the plant entity interface.

If we add platforms, the component will no longer be responsible for adding the entities, but this will shift to the platforms. The plant entities will be created in the platforms by using the base plant entity class from the plant component.

[Jc2k]

I really like the idea of having a plant platform - thanks for pushing it forward @Djebouh

I have a couple of Mi Flora sensors myself and it would be great if they were using this sort of approach. If you didn't need to do manual configuration.yaml changes to get the plant sensor then eventually we might even be able to automatically find MiFlora in the Discoveries list and configure them via config entries without touching any yaml at all.

[Djebouh]

@MartinHjelmare, ref

We have to define what attributes, moisture, battery, temperature, conductivity, brightness, etc should be required and should be optional for the platforms to implement and report. This will define the plant entity interface.

Is it enough to add a dictionary in the plant entity to pass the couples (condition, sensor)? The current plant.READINGS describes already the list potential conditions monitored.

@Jc2k, ref

we might even be able to automatically find MiFlora in the Discoveries list

It would be indeed nice, yet it may be tricky for miflora (or parrot pot) connected thru Bluetooth as BLE scan usually requires root access. There are work arounds yet I don't know the rules that home assistant recommends on such "system level" dependencies. For MQTT sensors, this should be easier to create plants "on the fly".

[MartinHjelmare]

If we make this change to a plant component with platforms, the new platforms won't necessarily take their values from other existing sensors. So the sensor: reading dict doesn't make sense to keep anymore in the base component plant entity. That will be a platform detail. The existing behavior will probably be part of a general or template platform.

We should define each reading as an entity property and either raise if not implemented if the reading is required or return None for optional readings.

[Djebouh]

It's more ambitious :). It would indeed avoid creating these intermediate sensors. In the current implementation, no plant condition is defined as mandatory and I find it convenient to keep all properties optional.

[Djebouh]

@MartinHjelmare, sorry for asking, but can you please advise on the way forward.

[MartinHjelmare]

I think we first need a greater consensus support from more members.

[balloob]

There are different types of integrations in Home Assistant. There are integrations that get their data directly from devices and services and publish that to Home Assistant.

Then there are integrations that aggregate/process data in Home Assistant and show that as a new entity (statistics, template, plant).

It is important that we do not mix these things.

So to propose a plant platform means that we know of multiple plant sensors and we can define multiple all-in-one sensors that all report a similar set of info that we can standardize.

[Jc2k]

I know of at least:

• MiiFlora (seemingly sold under many different names on amazon)
• Parrot Pot (https://www.parrot.com/uk/connected-garden/parrot-pot)
• Parrot Flower Power (https://www.parrot.com/files/s3fs-public/firmware/flower-power_user-guide_uk.pdf)
• FYTA Beam

I imagine we could end up with an ESPHome implementation? (There are quite a few guides on home brew sensors with ESP32 etc).

And from what i've seen, I imagine that the existing plant aggregation type entity could likely become a template type entity, allowing existing use cases to still be supported and not mixing the 2 different types of entity.

The common measurements i've seen are:

• Temperature
• Light intensity
• Moisture
• Conductivity
• Battery level

[dgomes]

There is also:

https://www.aliexpress.com/item/33052608123.html

[balloob]

This change means that sensor is no longer the place for sensor values to go, it could now also be plant. That seems confusing.

The current plant integration does not just collect measurements, it also gives warnings etc. All that will have to be removed and only be made available to an integration that consumes sensor data.

We should not mix raw data with processed data. Those are different entities.

So if you want plant with platforms, it means dropping all the warnings etc.

[MartinHjelmare]

We have weather platforms and weather sensor platforms. Also confusing but at least there's precedence.

[Djebouh]

I don't think we (feeling bold 😎 ) should remove monitoring features from Plant. Plant should still handle the values of the monitored conditions (in a generic way via dictionary ?) and should define a method to update these values. It could therefore keep offering features like monitoring of min/max conditions. It is closer to real time data validation than post processing of data of an other entity (as statistics or template or the current plant are doing.

Integration should be responsible to collect those data. They could also add other conditions (watertank can be also monitored for Parrot Pot for example).

[foreign-sub]

I have not translated the following actions in HA concepts, but i imagine the workflow should be something like:

• Create a garden.
• Add some plants.
• Link sensors to these plants.

A garden could have none, one or many plants. A plant could have none, one or many sensors and be part of a garden, or not. Also it can be a single plant or a group of plants (batches). A plant sensor could be attached to none, one or many plants.

A garden only requires a name, but could provide additional data, like a pot type or surface area. A plant only requires a name, but could provide additional data, like count for batches, date of birth etc... A sensor only provides its own data, name, temperature, ph, ec, moisture, etc...

I believe the best way to do so would be to store the sensors data at the sensor level, plants should only have knowledge of the sensors they're linked to, this way you can also move sensors around the plants and plants between gardens.

Thank you.

[frenck]

This architecture issue is old, stale, and possibly obsolete. Things changed a lot over the years. Additionally, we have been moving to discussions for these architectural discussions.

For that reason, I'm going to close this issue.

../Frenck