Automation - only run if available more than 30 seconds?

Configuration
1

I have a digital hand shower, from which I via a BLE proxy can intercept information about water usage.
I have created an automation, that is triggered if the consumption goes above 40L.

Unfortunately, it seems like the shower does not always start a 0 when started again (the device is powered by water flow, so it is not always available).

Can I add some sort of condition, that will check if an entity from the shower has been in a non-unavailable state for at least e.g. 30 seconds ?

Problem illustrated:

image
image1005Ă—468 14.9 KB

Here it goes from unavailable to 54.29 - then down to 0 and starts counting up.
But it is not always, that it starts on the “old” value…
So what I want to achieve is to make sure, that I don’t get these “false positives”…

2

What shower do you have and what did you need to do in HA to get the data please ?

3

I am using this shower head: Oras Hydractiva Digital - Save water and energy in the shower

For HA, you can add the HACS integration “Amphiro Digital Hand Shower”

The Oras/Amphiro are more or less the same - just differentiated by a small bit in the BLE announcement packages - but as far as I remember, the Amphiro integration supports both.
And then of course an ESPHome BLE proxy to intercept the BLE announcements from the shower head (when it is active)

1 Like
4

Thanks
I can’t get the Oras one in the UK but have ordered the Amphiro one

5

Looks like this is the same thing, a subbrand of Oras:

6

I found two, this one for ESP (looks like yours):

and this:

Is it the second that you refer to? I have a esp proxy near so I could pick either.

7

I did the one on GitHub (oras-shower) - but have not done more work to it, as the plugin in HACS doesn’t require a device specifically programmed towards the shower… That was before I was pointed towards the other plugin.

It is the second one, I am referring to …

1 Like
8

Is it an automation you want to run or a cleaner sensor data?

If it’s cleaner data then perhaps you can create a template sensor that removes the first spike.

Just a guess but something like this:

template:
  - trigger:
    - platform: state
      entity_id:
        - sensor.shower_sensor
    sensor:
      - name: shower sensor cleaned
        state: >-
               {%- if trigger.from_state.state | float <= trigger.to_state.state | float -%}
                  {{ trigger.to_state.state  }}
               {%- endif -%}
9

Thanks, I will try that … I will probably have to check other sensors from the shower head as well - to see if they also start up with a spike…

10

Tried to add it like:

template:
  - trigger:
    - platform: state
      entity_id:
        - sensor.dhs_9e8c_volume_dispensed
    sensor:
      - name: sensor.dhs_9e8c_volume_dispensed_cleaned
        state: >-
               {%- if trigger.from_state.state | float <= trigger.to_state.state | float -%}
                  {{ trigger.to_state.state  }}
               {%- endif -%}

This is then the data after a reload of the config:

image
image1155Ă—342 26.9 KB

So the numbers incrementing over time seems OK … Will try to keep an eye on it…

11

That will give you a sensor that can never decrease, which isn’t what you want.

This will just eliminate the first data point after coming back from an unavailable state:

template:
  - trigger:
    - platform: state
      entity_id:
        - sensor.dhs_9e8c_volume_dispensed
      not_from:
        - unavailable
        - unknown
    sensor:
      - name: DHS 9E8C Volume Dispensed Cleaned
        state: >
          {{ trigger.to_state.state }}
        unit_of_measurement: "L"

I also added a unit of measurement so that it will plot as a graph instead of states. And I changed the name so that it will result in the entity id you are wanting. The “sensor” domain will be added to the entity id no matter what you name it.

12

Will try that one…

The CSV output of the start of the graph in the first posting:

entity_id,state,last_changed
sensor.dhs_d6bb_volume_dispensed,unavailable,2024-03-22T04:15:00.000Z
sensor.dhs_d6bb_volume_dispensed,54.3,2024-03-22T04:21:05.166Z
sensor.dhs_d6bb_volume_dispensed,0.33,2024-03-22T04:21:08.656Z
sensor.dhs_d6bb_volume_dispensed,0.73,2024-03-22T04:21:10.907Z
sensor.dhs_d6bb_volume_dispensed,0.93,2024-03-22T04:21:12.158Z
sensor.dhs_d6bb_volume_dispensed,1.43,2024-03-22T04:21:16.645Z

So it might just be the first record, that should be discarded…

13

I can confirm the Hansa Activejet Bluetooth (aka Hasactivejet) is compatible and recognized, as a working well using an ESP bluetooth proxy.

I did notice the water usage and time are registered as state class total by the integration, while they reset to 0 for each new cycle. So they should be state class total_increasing and I used customize.yaml to change it. That will allow to put a utility meter on it to sum total usage.