I’d like to get a notification whenever my water usage is above something like 0,5 liter per minute for more than 1.5 hours. This would correspond with my plant watering system running crazy.
My new HomeWizard (HW) water meter sensor measures every liter of water (i.e. the water meter pulses once whenever another liter of water is used). The integration (HW Engergy) shows m³ and liter per minute. Whenever water usage is below 1 liter per measurement cycle, the values of liter per minute start fluctuating between 1.27 liter per minute and 0 liter per minute.
This means, that a simple notification “water value change” “above 0.5” “during 1.5 hours” does not trigger.
I tried several helpers to work around this: a derivative for the total water usage; also the statistical mean for the water meter and also the average step.
None of these result in workable solutions. The derivative seems to stay at its last value (i.e. turning off the tap keeps the derivative at several liters per minute), the mean and the average step say they are “Unknown” whenever the water usage is zero for several minutes.
So how can I see the “real” average water usage when the meter is oscillating between 0 and 1.27? And how can I send a notification whenever water usage has been higher than 0.5 l/m for one hour? (Or if water usage has been higher than 30 liters during the last hour, which is equivalent).
I’m not sure it is erroneous information. It’s a sensor that can only sense 1 liter of water used. So the “liters per minute” is an abstraction that is dependent on the measurement interval. Where can I find the yaml config of the helpers? There are no template sensors in between, the graph comes directly from the integration sensor.
HW energy integration supplies the L/pm sensor? I would assume it’s a bug in their code.
If there are 0 pulses per minute, the L/pm sensor should return 0 during that time interval. The fact it is oscillating between 0 and x when 0 pulses are recieved indicates to me there is some sort of logic error in that sensor. Unless I am misunderstanding something.
I use a QMC5883L mag sensor to detect magnet pole rotations in my water meter which I breakout into rotations of magnet per minute and litres per minute based on a sensor which reports how many mL of water passes through the meter for every magnet pole rotation. All the sensors report correctly which leads me to thinking that the integration that exposes the L/pm to you has a logic error.
I can try and take a quick look at the src to confirm.
Edit: another option is, if they expose the pulse sensor, make your own L/pm sensor.
If you created them using UI, they won’t be visible in yaml. You would need to remove the UI helpers and configure them in yaml configuration.yaml file.
The integration pulls the data from the home wizard python libs and doesn’t seem to do anything besides report what it’s told (the L/pm calcs are done on device in firmware). I haven’t done a deep dive yet but I am assuming it’s an error in the home wizard python libs logic.
AFAICT, they don’t expose the pulse sensor. Only lifetime m3 and L/pm. I would open an issue in the home wizard python libs repo to ask for clarification on how they calculate the L/pm.
OK.
I’m not sure I’m qualified for that, i.e. this feels more like a question than as a “bug” (the latter implying that I know what I’m talking about, which I don’t). Is there any way to “bump” this question with a tag?
Final question: is it normal that the statistical derivative function helper stays at its last value instead of returning to 0? Because simply calculating the derivative over a couple of minutes would help me, too.
I haven’t had the pleasure of using those sensors so I can’t speak on how they work and what their default stuff is.
It may be better to post a new topic asking about the behavior of the statistics algo and reference this topic on that post for context.
I will look a bit deeper into the HW python repo and see if I can spot an issue. If so, I’ll open an issue and/or open a pull request with a fix. It would be helpful if they exposed the pulse sensor as well, which I’ll ask for.
The maintainer replied and said they haven’t seen this before. They asked if you could reach out to support for troubleshooting to determine if it’s a faulty device or some other cause.
Yes, this is a known issue due to how HA handles repeated values. A sensor is not considered changed or updated when its state is updated with the same value, and the derivative sensor only updates when the source sensor updates. Therefore, it is currently impossible to have a derivative sensor report 0 without some silly workarounds.
HA has been updated with a new event which will allow integrations to trigger an update when the source has reported (regardless if the value changed or not). The last step of the puzzle is to update the derivative integration to trigger off this new event. This change was recently made to the Riemann sum integration so hopefully someone works on the derivate integration soon.