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.
I know nothing about InfluxDB or VeraFlux, but there are many articles on InfluxDB memory hunger. These may be relevant, search for others:
https://medium.com/cobe-io/memory-adventures-with-influxdb-28b8157aebe8
https://www.dummylabs.com/post/2019-01-13-influxdb-part1/
(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
I am wondering the same thing, if this plugin would work with the newer InfluxDB 2.0 ?
If you are using Multi System Reactor that supports InfluxDB 1.8.X and 2.0, so might be able to use that instead of this VeraFlux plugin.
1 Like
Hey guys…
At the moment I don’t have any plans to update the plugin - I’m weighing up whether I stick with the Vera platform. Ezlo seems to be a long way from delivering anything that has feature parity, and even if/when they do I suspect all plugins will need an extensive rewrite.
If rigpapa has got 2.x Influx code in his repo then it might be easy to update it. I’ll take a look. But not making any promises.
It’s in a whole new Reactor (Multi-hub) product that works with both Vera and eZLO, but it’s not Lua so I don’t think it would do you much good. It’s all node (JS) now, and I’m using the @influxdata/influxdb-client package for the interface.