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.
You can use ORDER_BY time DESC in your queries.
https://docs.influxdata.com/influxdb/v1.7/query_language/data_exploration/#order-by-time-desc
And LIMIT 1 to return the last.
I can’t figure out the LastTripped time for door sensors.
This is the best I have so far using Tripped variable instead.
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)
I use that to give me a daily kwh summary.
Just installed this plugin in openluup, and it works well as usual!
one little quirk though:
2020-11-05 19:16:48.716 luup_log:199: VeraFlux #199 ERROR: InfluxDB server replied: 400, expected 204
2020-11-05 19:16:48.717 luup_log:199: VeraFlux #199 ERROR: InfluxDB reply: {"{"error":"partial write: field type conflict: input field \"Tripped\" on measurement \"urn:micasaverde-com:serviceId:SecuritySensor1\" is type float, already exists as type boolean dropped=14"}
2020-11-05 19:16:48.717 luup_log:199: VeraFlux #199 Flux Capacitor Online, 1.21 Gigawatts available.
Why is it changing datatype?
Cool BTTF reference in the last sentence, but does it mean anything? 
Back to the future?
BTW, openLuup Historian can send data via UDP to InfluxDB without the need of any plugin.
yes 
, but does the “1.21 Gigawatts available” mean anything? Edit: nevermind, googled it.
I saw that, but from what i read it seems that i have to set watches on the signals i want to send, while this one sends all of it. 
Depends what you want, but most of the interesting variables are automatically collected by the Historian, IIRC.
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?
Ok, tried that, and it disappeared from the key field list, now its back as a float, and thats wrong too!
2020-11-09 07:08:06.526 luup_log:199: VeraFlux #199 ERROR: InfluxDB server replied: 400, expected 204
2020-11-09 07:08:06.526 luup_log:199: VeraFlux #199 ERROR: InfluxDB reply: {"{"error":"partial write: field type conflict: input field \"Tripped\" on measurement \"urn:micasaverde-com:serviceId:SecuritySensor1\" is type boolean, already exists as type float dropped=6"}"}
2020-11-09 07:08:06.526 luup_log:199: VeraFlux #199 Flux Capacitor Online, 1.21 Gigawatts available.
What to do? it seems to change?
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.
Rant over!
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)’ ?
Lately my Raspberry Pi isn’t happy, the CPU is constantly getting hammered by the Influxd service and it’s RAM usage is about 75%
I have just turned this off in the InfluxDB config file and rebooted but its made no change.
[monitor]
# Whether to record statistics internally.
store-enabled = false
I just increased the Swapsize on the Pi from 100 to 2048.
pi@raspberrypi:~ $ sudo du -sh /var/lib/influxdb/data
1.3G /var/lib/influxdb/data
Does anyone know what else to try or look at ?
Thanks.
Best Home Automation shopping experience. Shop at getvera!
© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules