I can’t comment on node red but I saw you earlier posts on it.
For the sensor, you can see if the options of the panel visualizations help. Otherwise a stacked chart might work using the unit as a date and the other axis as the last tripped time. You could then format the epoch number using math to something you want or any number to signify.
Has anyone had any luck getting total power usage for a device yesterday? For example, i have a pump and I simply want to see how much power it consumed between 00:00 and 11:59 yesterday or maybe all of last week etc… Every time I try to do this I get crazy numbers. In another forum I stumbled across someone saying:
use Integral function to calculate WH from W - first aggregation
use Sum function with daily time agggregation - second aggregation
=> 2 aggregations are required = subqueries are required = you need to switch to raw query editor in Grafana and you need to write it on your own
This makes sense conceptually, but then there is in practice. Any thoughts from anyone who has done this?
SELECT integral(“Watts”,1000h) FROM “urn:micasaverde-com:serviceId:EnergyMetering1” WHERE (“description” = ‘Total Energy’) AND $timeFilter GROUP BY time(1d) fill(linear)
That log entry just means that the polling/data sending cycle is running. You get a different log entry if you’ve disabled the device.
As for your error - are you writing to the same InfluxDB from Openluup that previously you were using with Vera?
@akbooer can correct me if I’m wrong here, but vaguely recall reading that Openluup represented some Vera variables as 0 or 1 (type float or integer) where Vera used boolean true/false.
In which case Influx is complaining that your variable is now coming in as a float from openluup where before it was a boolean. The fix would be to delete that time series from your InfluxDB and let it be recreated as a float.
No, Vera reports to a different influxdb. I’ve made a new influxdb server on the same machine that’s running openLuup and z-way, so the vera have never been in touch with this one.
I’ll try to delete the time series then, the whole "urn:micasaverde-com:serviceId:SecuritySensor1" then, not particular devices?
one difference frome before is that I have securitysensors from both Z-Way Bridge and RFXTRX plugin, so they might save in different formats… any way to fix that? I guess all security sensors should be boolean?
All Vera variables are represented unchanged by the VeraBridge plugin.
There is an underlying flaw in Vera’s implementation, though, in that all device variables are actually stored as strings. Whilst the UPnP formalism is able to specify data types, and valid ranges/values, this is not fully utilised (indeed, often misused) by Vera implementation files.
It’s therefore impossible to tell what type a variable is, and just basing a judgement on its current value is likely to be fragile. It’s a particularly hard call, for example, if you’re trying to distinguish a Unix epoch date/time from just some random integer value. This also gave me some grief in the implementation of openLuup’s Data Historian, deciding which variables were likely to be valid numbers for long-term archiving.
Definately sounds like a pain in the ass… But in this case the result seems to be because of either z-way bridge, Reactor or RFX plugin is calling for float on security sensors, and i think its the Z-Way based on the number of sensors dropped (6 is boolean and earlier 14 float). Haven’t had an issue with Reactor and rfx earlier, so they seem to agree.
EDIT: Checked my vera database, and its Reactor and RFX plugin that passes these as float. Z-way is the one using Boolean then, which to me sounds correct. @rigpapa/@tinman: Is this something that can be changed on plugin side? Or is it the Veraflux that interprets this from a string value?
How can I mend this? Some conversion in Lua startup?
All state variable values in Luup are strings. The strings may contain representations of numbers, but the precision of those representations depends entirely on what sets them, so you need to follow the chain to find out what code/plugin is setting that value.
Ok, but that sounds like a potentially futile exersise… @BlueSmurf, is there an apropriate place in the veraflux.lua I can place a ‘IF “Securitysensor1”, toBoolean(measurement)’ ?