Tracking amount with only math and template issue

Configuration
,
1

I have a barrel I fill with water, I know the max amount the barrel holds is 50.

I have a pump to fill the barrel, with a water meter attached.
I have a pump to drain the barrel, with a water meter attached.

When I know the barrel is full, I reset my values, and say its at 50.

The issue:
Say if I use 20 gallons, there is 30 gallons left. So my input_number would say 30.

When I start to fill the barrel, I have an mqtt msg coming in for every pulsemeter change, despite that its a super busy mqtt topic, homeassistant stays caught up. But, what im trying to do is have a label show how full the barrel is at all times, not show whats there when its not being filled. So say in this automation:

     - service: input_number.set_value
       data_template:
         entity_id: input_number.water_amount_left
         value: >-
                 {% set X1 = (states('input_number.water_amount_left')|round(1) + states('sensor.water_amount_filled')|round(1))|round(1) %}
                     {%- if X1 > 50 %}
                         50.0
                     {% else %}
                         {{X1}}
                     {% endif %}

but when each update is pushed via pulse, the number gets all wonky and jumps all over the place because technically the amount_filled makes changes like
1.2gallons
2.5gallons
2.8 gallons…

and when the math is done its being computed like
(amount left) + 1.2 turning into (31.2)
(31.2) + 2.5 turning into (33.7)
(33.7) + 2.8 turning into (36.5)

when really, it should only be 32.8 (starting at that 30 mark said above the code)

A-- I understand variables were added to homeassistant automations, but is that a use case here?

B— Or should I have a secondary, unseen input_text that has the original amount left before the filling automation started?

again the goal is to keep the visual labels actively changing for aesthetics.
I have tried and stopped this goal a few times, have a array of input_text and input_numbers so on, and messy’d the entire thing up.

Almost guarantee im overthinking the entire scenario.
Also, fwiw, when i pump water out, im doing the same thing, so the water being used at the same time as the barrel being refilled, is also a concern, for overlapping redundant headaches.

Any ones input on the situation would be greatly appreciated!

  • Im aware code above may not be exact to what I explained, more or less trying to illustration the usage.
2

How are you calculating the sensor.water_amount_filled?

3

that is just the name of the mqtt sensor that is amount of water (calculated by pulse) that homeassistant is seeing.

      water_amount_filled:
        friendly_name: "Water Meter in Gal"
        unit_of_measurement: 'gal'
        value_template: "{{ (states('sensor.ddd_flow_meter_total')|int *1/115) | round(2) }}"
4

This turning into quite the cascade of sensor calculations…

How is the sensor.ddd_flow_meter_total calculated?

1 Like
5 
  - platform: mqtt
    name: "flow meter total"
    qos: 1
    entity_namespace: "ddd"
    state_topic: "homeassistant/espres/w_meter/total"

which is just the number of pulses from the flow sensor

and looking over the automation, using the water_amount_filled as my trigger, I may be able to do the math with an additional ( - trigger.fromstate.state)

6

is there an MQTT topic that just sends raw pulses instead of a “total”?

If so you create another sensor that uses that information to add that equivalent amount of water to the final sensor template above to get the current total.

Example:

each pulse is one gallon of water.

create a a sensor from that pulse that switches between 0 & 1 based on the pulse. then every time that sensor changes to a 1 then add 1 (gallon) to the water_amount_left sensor.

and then you could do the reverse for the water meter pulses for water removed from the barrel.

EDIT: I just realized you are setting an input number via an automation.

I would use a sensor for this instead of an input_number.

7

using two different water meters, so the pulse count per litre is different. these pulse meters do report current pulses, but depending on water pressure and amount being used, the pulses change super fast and I fear the flooding of the mqtt messages would bog things down, atleast the current total of pulses being reported every X amounts keeps things responsive. each meter is connected to a 8266 running espeasy. reporting total pulses, time, and count.

8

The pulse mqtt messages are already “flooding” your broker if they are already coming in.

If HA is receiving them by being subscribed to that topic then it is already being “flooded” as well.

try it and see if it works. you don’t have much to lose.

9

after multiple attempts the last hour, im still hitting my head with this error atm:

Error rendering data template: TypeError: unsupported operand type(s) for -: 'str' and 'int'

using this

    - service: input_number.set_value
      data_template:
        entity_id: input_number.rez_gallons
        value: >
                {{ (
                 states('input_number.rez_gallons') 
                 + 
                 states('sensor.res_meter_gallons')
                  - 
                 trigger.from_state.state|int
                 ) }}

changing to

{{ (
states('input_number.rez_gallons')|round(1)
 + 
states('sensor.res_meter_gallons')|round(1)
 - 
trigger.from_state.state|round(1)
) }}

actually works! but the rounding makes updating slow. Anyway to change the states to a number without rounding? using |int enforces rounding to no decimals so i only see changes like 12 to 13 and not 12 to 12.34, currently seeing changes from 12.1 to 12.2

10

| float will covert a string (all states are strings) to a floating point number.

1 Like
11

Why not make a water level sensor and get the definitive answer?

1 Like
12

That’s what I was thinking from the beginning…

13

I seriously doubt it makes any difference to how fast the system updates to round a couple of sensors.

Just out of curiosity what is the trigger for the automation? You’ve never provided that info.

1 Like
14

I have two sensors that are being updated by the same origin mqtt sensor. in an attempted example to manage how the rounding and updating frequency can be visually different. the meter that shows 30.2 updates less frequently than the one that would show 30.13, 30.15, 30.18, etc.

- id: 'adjust ro water amount'  # [ADD] raise water amount in rez due to RO meter changing
  alias: auto adjust ro water amount
  description: 'automagically adjust ro water amount'
  mode: single
  trigger:
  - platform: state  
    entity_id: sensor.res_meter_gallons

  condition: []
    
  action:
    - service: input_number.set_value
      data_template:
        entity_id: input_number.rez_gallons
        value: >
                {{ (states('input_number.rez_gallons')|float + states('sensor.res_meter_gallons')|float - trigger.from_state.state|float) }}

almost works like a gem. finding a slight difficulty in going to the original method using:

{% set X0 = (states('input_number.rez_gallons')|float + states('sensor.res_meter_gallons')|float - trigger.from_state.state|float) %}
{% set X1 = X0|round(1) %}
  {%- if X1 > 55 %}
       55.0
  {% else %}
      {{X1}}
  {% endif %}

but the troubleshooting of the X0 via template editor has me a bit struggling, because in template editor i had to do stuff like this instead:

{% set trigger_from_state = "3.45" %}
{% set x2 = (trigger_from_state|float) %}
{{
(states('input_number.rez_gallons')|float
+ 
states('sensor.res_meter_gallons')|float
-
x2)|round(2) 
}}

all templates have been shortend to new lines for forum readability, they all function fine laid out the way i have typed them, incase anyone elses reads this and is curious ‘will they still work like that in 7 lines?’ — yes, they do.

15

Its about software, and not hardware at this point. use-case and functionality by experimenting. an ultrasonic sensor, level tape, touchless float sensors, they all have a place in my heart to tinker with.

however atm, I have this to work with, and have no intention on changing the hardware configuration until the next list of ‘todo’s’ are complete.

for example id like to keep track of how much fresh water was used this week, sometimes the fresh water is used to clean and empty the barrel without using the pump-out and meter, which is used to measure how much nutrient water is fed to my plants. (through a dosatron like siphoning device that injects inline)

16

So now you’ve introduced a completely new “sensor.res_meter_gallons”.

How is that calculated?

Is that really a total gallons sensor (as the name suggests) or is it a “rate of change” sensor or is it just counting pulses?

It seems that the resolution on that sensor is pretty small so I assume it uses the “flood” of pulses from the device via MQTT somewhere in this chain of calculations already?

From your description it seems that the update frequency isn’t really any slower using round() it’s just that it doesn’t show the degree of resolution that you want. If you changed round(1) to round(2) then the resolution and the “visual” would likely be what you expect.

But using float does the same thing so either way will work.

17

in my original very first post, at the very bottom of the post, I had said " * Im aware code above may not be exact to what I explained, more or less trying to illustration the usage."

This continued into the exact coding , as my original post was “dumbed down” while still having the exact same use situation without having to re-explain every part of the poorly named identifiers. sensor water amount filled was actually sensor res meter gallons, input number water amount left was actually input number rez gallons.

when the amount of X changes in the value that sensor.res_meter_gallons says, it adds that amount to the amount that is shown in the input_number.rez_gallons. as the res_meter_gallons changes, the input_number.rez_gallons changes. Which was doubling up the final number due to the missing trigger_from amount.

  • and for what its worth, i had originally intended on changing the entire code to match to avoid this questioning and explanation but have yet to work out the kinks in the code itself, while still maintaining an understanding with anyone interested.
    Thank you again for your efforts.
18

You don’t have to “dumb it down” for our benefit. I think there are users here who can figure out any code you throw out.

Without being precise in your explanations including posting the complete real relevant code and the associated sensors it makes it very hard or impossible to see what you have to work with and makes it hard or impossible to give you suggestions based on incomplete information that you provided.

Even if the identifiers are poorly named if we have all of the code that goes into creating each one it makes it easier (and more likely) we can get a feel for what is really happening and can offer suggestions.

Without that information we are left just asking a string of clarifying questions as happened here.

Please don’t take this as a “scolding”. I’m just trying to explain so that you can help us to help you in the future.

1 Like