I imagine a strategy might be to capture the flow data with time stamps and use a rule to add to a running total.. I searched the community but didn’t find anything.
I can’t offer anything more detailed without more information. In particular what data are you getting be MQTT into OH and how often.
But, once you understand what the data it’s just a matter or keeping a running total every time the Item updates in another Item. Then at midnight transfer that total to another Item and reset it.
The whole “capture the flow data with time stamps” is handled by persistence. That’s literally it’s primary job. But we don’t need it for this. Though I bet you’ll want charts and graphs of this data so you will want to have your Items persisted. See Persistence | openHAB and Persistence | openHAB.
I looked at this but don’t understand how to apply it to my use case. (Luckily my power consumption is handled by my watt meter.)
My understanding is I need a rule that triggers on every Flow update and calculates the elapsed time since the previous update (in seconds?) and use that duration multiplied by the flow (in L/min converted to L/sec ) to calculate the amount of water. Then add that amount to an Item that represents the running total.
Is that right?
There is also occasional Volume data but I have no idea what to do with that.
You don’t care about the flow rate, just the total amount of water used, right? And the device already reports the flow rate.
You just need a rule that triggers on changes to the WaterVolume Item and add the new value to the sum of the old values. You can create a separate Item for this (e.g. ‘DailyWaterUsage’). The code is two lines (JS).
var total = (items.DailyWaterUsage.isUninitialized) ? 0 : items.DailyWaterUsage.numericState;
items.DailyWaterUsage.postUpdate(total + parseFloat(event.newState));
Then you need a rule that runs once a day around midnight that adds the DailyWaterUsage to the MonthlyWaterUsage and resets the Daily Item to 0 and at the first of the month resets the MonthlyWaterUsage Item to 0. That’s what the Historical energy consumption rule template does.
If it were me, I’d configure the all these Items as Number:Volume and set the unit to L and set the MQTT Channel’s unit to L too. Then we can take advantage of UoM but the code changes to:
var total = (items.DailyWaterUsage.isUninitialized) ? Quantity('0 L): items.DailyWaterUsage.numericState;
items.DailyWaterUsage.postUpdate(total + Quantity(event.newState)); // the unit will already be attached to the state
If you want a running total you’d use persistence and you’d have to deal with timing and stuff like that. So the easiest would probably to set a cron triggered rule to run every couple of minutes with the one liner:
I set the WaterVolume item as volume in ml, because that’s what the sensor sends.
I set the DailyWaterUsage to L, thinking that the unit conversion happens automatically.
I get an error every time the rule runs.
09:25:58.130 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'WaterVolume' updated to 1437.97 ml
09:25:58.131 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WaterVolume' changed from 477 ml to 1437.97 ml (source: org.openhab.core.thing$mqtt:topic:63bc5ac12e:Droplet:Volume)
09:25:58.131 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Droplet_Server' updated to Connected
09:25:58.132 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Droplet_flow' updated to 14.36 l/min
09:25:58.132 [ERROR] [l.handler.AbstractScriptModuleHandler] - Script execution of rule with UID 'WaterVolume' failed: TypeError: Cannot get property "isUninitialized" of null in <eval> at line number 3 at column number 13
Maybe because the rule doesn’t reference the WaterVolume?
You should set the channel on the MQTT thing’s unit to “ml”. Then you can set the unit on the Item to what every you want, even “gal”, and the ml will be converted automatically.
If everything is configured correctly it should. But it needs to be lower case “l”. I may have messed that up above but I just checked the docs and liter is “l” and not “L”.
No, the rule doesn’t have to reference that Item. All the information related to the update to the Item is in event. We just need the newState.
As for the error, double check the spelling exactly matches the Item you created to hold the running daily total. The error is saying items.DailyWaterUsage is null which means that Item doesn’t exist.
configuration: {}
triggers:
- id: "1"
configuration:
itemName: WaterVolume
type: core.ItemStateUpdateTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: >
// Get the current total or default to 0 ml if uninitialized
var total = (items.DailyWaterUsage.isUninitialized) ? Quantity('0 ml') :
items.DailyWaterUsage.quantityState;
// Wrap the new state in a Quantity and use the .add() method
var increment = Quantity(event.newState);
var newTotal = total.add(increment);
// Post the update back to the item
items.DailyWaterUsage.postUpdate(newTotal);
type: script.ScriptAction
But still getting an error
Script execution of rule with UID 'WaterVolume' failed: TypeError: TypeError: Argument of wrong type provided, required Item, string or Quantity.
Looking at the rule trigger I now realize it’s an updated trigger, not a changed trigger like I expected. According to the docs for an updated trigger the state is event.receivedState, not event.newState. But logging out total, event.newState, increment, and newTotalwill confirm.
On dirait que vous êtes sur la bonne voie en pensant au MQTT et aux règles. Étant donné que votre capteur de gouttelettes publie des événements de flux ou de consommation via MQTT, vous pouvez capturer chaque message dans openHAB à l’aide d’un objet MQTT lié à un élément numérique représentant le flux actuel. Ensuite, avec une règle, vous pouvez ajouter la valeur à un élément persistant qui représente votre total quotidien. En utilisant le service de persistance d’openHAB, vous pouvez réinitialiser casino retrait immédiat https://trail-rando.fr/ ce total à minuit pour commencer une nouvelle journée. Pour afficher les événements de consommation, vous pouvez soit enregistrer chaque message dans un élément distinct, soit utiliser une liste déroulante dans un plan du site ou un widget d’interface utilisateur principal. Il s’agit essentiellement de combiner les abonnements MQTT, les règles d’accumulation et la persistance pour répliquer ce que fait l’application du fournisseur.
