PLUGIN: VeraFlux - Send Device Data to InfluxDB

How about a Table presentation?

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.

1 Like

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? :wink:

Back to the future?

BTW, openLuup Historian can send data via UDP to InfluxDB without the need of any plugin.

yes :smiley: , but does the “1.21 Gigawatts available” mean anything? Edit: nevermind, googled it. :wink:

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. :slight_smile:

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.

  # 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 ?


I know nothing about InfluxDB or VeraFlux, but there are many articles on InfluxDB memory hunger. These may be relevant, search for others:

(see discussion under “InfluxDB Advantages” section in this article)

I also note you have a Java process running. Java’s runtime allocates but never frees memory from the system. It will allocate memory from its configured min/start (-Xms) to its configured max (-Xmx) linearly; it will never return unused memory to the system. You may need to periodically restart the java process to reduce overall system memory use (ideally, of course, you would find a happy setting for max that works for your other system process and the total amount of system RAM, so that java hitting its limit doesn’t cause paging (swap) or system failure).

Increasing your swap size is likely only going to slow your system down and cause excess wear on the drive.

2 posts were merged into an existing topic: Linux Guy’s - Why isn’t this working? .SSH Auth keys for Pi

I have an issue with adding pressure sensors to the sent data types.
I made an issue on GitHub, but mabye @BlueSmurf is more active at this forum?

1 Like

Anyone manage to add additional fields to already existing service tables? I followed the patterns and triple checked. Nothing gets updated for new items.

I’ve added a request on github to look at the possibility to slightly change the plugin so it can be used on Influx 2.x (compared to 1.8.x , there are some changes, concept of a access-token, organisation-id , …)
Hopefully there is still somebody looking at it or we keep stuck on InfluxDB 1.8.x

1 Like

Best Home Automation shopping experience. Shop at getvera!

© 2021 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules