I don’t think it has hit the Debian/Ubuntu repos yet though has it? Possibly because by including it all it may break those installs that did it separately. Not sure of there is an upgrade rout therefore.
I’m with you on that!
I wasn’t looking to convert anyone, tbh I have no real experience of either so I cannot promote either, it’s just that when I got an email about the release towards the end of last year sometime, I was somewhat impressed by the pitch and I thought that might be a good time to get involved, straight into v2 could potentially avoid a second learning curve or confusing transition down the line.
However. It really does depend on what packaging/binaries are available when I go to install, as it stands I’m contemplating v1 purely because I can (lazily) install to a Pi with apt-get. For v2 I would need to compile from source for a Pi, unless (IIRC) I use a Pi 4, of which I only have one, and I have so many spare Pi3’s that I can’t justify buying another.
I learnt yesterday that there is free online access to influxdb v2 online for development, user data is deleted after 30 days. That’s a rolling 30days deletion of data not a account deletion so I could try that until I’m ready to tackle the installation, at which point perhaps the debian packages or Pi binaries might be available 
If I do work on a influxdb script (for emonhub?) it would be good to have both v1 and v2 compatibility if possible, so i would need to compare the api’s and/or db structure’s, maybe separate scripts might be cleaner. I guess I won’t know unless I try both? We’ll see what happens.
Mildly interesting is this article that appeared in my news feed this morning, influxdb’s flux language gets a positive mention.
Don’t know for sure if it would or not, but their download page mentions an in-place upgrade.
Beta 16 was quite some time ago, so it sounds as if it’s upgradeable from v1 to v2 fairly easily.
More info here: https://docs.influxdata.com/influxdb/v2/install/upgrade/v1-to-v2/
No worries. You didn’t sound like you were. 
(I’ve been using Influx/Grafana for about 4 years now, so if anyone sounds like they’re in
“convert mode” it’s more likely to be me. 
I found familiarity with v1 actually made understanding v2 easier and quicker. Although there are many
things new in v2, there are core concepts (line protocol comes to mind) that were carried over to v2.
Pehaps not. Their download page:
https://portal.influxdata.com/downloads/
shows .deb packages for 64-bit ARM as well as generic Linux (.tar.gz) packages for 64-bit ARM.
So if you’ve got a Pi 3, (or 4) load 'er up with a 64-bit OS then rock-n-roll.
Once you install via apt-get upgrading via dpkg is quick and easy.
Only five “executables” and some man page doc files to copy and the upgrade is done.
I’m going to install v1 on a spare Pi, then upgrade the v1 install to v2 just to see how that goes.
One thing to note… The upgrade from v1 to v2 is 64-bit only. i.e there is no 32-bit version available.
That is quite interesting. Not appreciated exactly what Telegraf was and I have several applications that come to mind.
I want to monitor the battery state of the laptops I’m running PVE on. Cannot yet see there is a Telegraf plugin to do it directly, but a combination of Monit and Telegraf might work. I think it can query the Monit API remotely.
If that’s Proxmox Virtual Environment you’re speaking of,
you could use lm-sensor and the lm-sensor Telegraf plugin.
1 Like
Just voltage IIRC.
1 Like
The upgrade itself was quick and easy. (the database I upgraded was very small)
I spent a little time reading their upgrade instructions then installed a clean copy of 64-bit RasPiOS on a 16GB eMMC card. v2 requires authentication, so the instance of v1 that’s getting the upgrade needs to have authentication in place. Admin users are not migrated. They need to be created manually.
The docs say to run the command influxd upgrade. When I ran it as the user pi, it threw a
permissions error. re-ran it via sudo, and the upgrade completed sucessfully.
Overall, an easy, minimal issue experience.
Have a look at this. It sounds like it’s just what you’re after:
Here’s the data from an HP laptop:
Path to the data diplayed above is: /sys/class/power_supply/BAT0/uevent
A one-liner for the SOC:
cat /sys/class/power_supply/BAT0/uevent|grep CAPACITY=
Here’s a couple more:
Yes. The suggestion I found was to use the Telegraf ‘file’ plugin and check that (those) files. I might just go the Monit route as that gives me other information at the same time and the remote Telegraf then just queries the Monit API
1 Like
That was truly, horribly, simple. I am going to have to re-evaluate lots of other things now. I’d already installed Telegraf alongside InfluxDB (I’d not understood what it was at the time).
Added this config
[[inputs.monit]]
## Monit HTTPD address
address = "http://192.168.7.30:2812"
Restarted the service and I have data.
The only thing I had difficulty understanding was how I could have more than one set of data. This doc explains it (plus help from the forum).
I first added a custom tag
[[inputs.monit]]
## Monit HTTPD address
address = "http://192.168.7.30:2812"
[inputs.monit.tags]
machine = "hassio"
But settled on a new measurement
[[inputs.monit]]
## Monit HTTPD address
address = "http://192.168.7.30:2812"
name_override = "hassio-monit"
1 Like
I’ll drink to that! 
Now you have a better idea of why I “kicked the Python script to the curb.”
1 Like