Release 02_06_02 ALPHA, BETA, MINOR

Release 02_06_00 caused several units to experience failure requiring external editing of the config.txt file. Those problems have been addressed in this new release and the config app will remove some older inactive configuration elements that were associated with the problem.

The release will go to ALPHA auto-update users today.

Decided to try out this release for the influx v2 support.
The uploader says it started in the log but in the status page under uploaders its saying

influxDB2: Running, Last update 2/1/2021 12:00:00 AM
Post failed 400

Not getting any data into influx

400 is not found, so the endpoint in your URL (the URI) is not correct in your influx setup. Can you post the setup?

image

Isn’t HTTP code 400 Bad Request ?

Yes, it is. I’m not in a position to look at this in depth right now, but offhand I’d say you might try adding a slash to the end of the URL.

I tried it both ways

I’ll have to admit that I have only been using the cloud version and do not have an OSS version to test with, but that’s where you ALPHAs come in. My URL for the cloud version is:
https://us-west-2-1.aws.cloud2.influxdata.com/api/v2/
I had assumed the URI was specific to the AWS server but looking at the docs for the OSS version, they use the same URI, so you might have better luck with:
http://192.168.0.6:8086/api/v2/
Give that a try. If that’s it, I’ll consider dropping it from the URL and adding it in the IoTaWatt.

ah yep thats what it was! The data is flowing now ! thanks!

1 Like

Funny how I always miss the little things. I’ll look into it a bit more but probably will not require the URI in the next release.

Not a big deal I don’t think it should automatically include it but maybe a note somewhere or show the path in the default html attribute or something .

Thanks for getting influxv2 support in there!

A thought on a mix of this, just to put it out there. Only really applies if Influx v2 and OSS instances always default their endpoints to the /api/v2/ URL.
You could have the /api/v2/ appear as text off the end of the server URL text field, and as long as the text entered in the field doesn’t end with a slash then you append that to the end of the ip:port that is in the field.
If the URL ends in a slash, then hide the /api/v2/ from the right side of the text field and use the URL exactly as it was entered.

Might be over complicating it, but I thought it would be a nice way to support folks who are using things basically as defaults, who would benefit from the auto-appending, while providing a easy way for users who have customised their influx instance and know they’ll need to do that. The text on the right side of the text field gives a subtle but clear indication of when the URL is being appended or not that way too.
And it would still work for when the /api/v2/ is on the end of a longer URL, more than just an IP:port or domain name, but even if the base URL was something like https://domain.name/influx since leaving the slash off the end of the influx in the base URL would still append the /api/v2/

Anyway, I don’t know if that would be overkill, but I feel like it would be just smart enough to help user’s just getting into it all, while not being so “smart” that it would annoy user’s who most experienced in it all. :slight_smile:

@davidmirv Is this still working for you? I’ve just enabled InfluxDB v2 support in my IoTaWatt but am receiving the following error when trying to send data to my v2 instance.

Last sent query failed. HTTPcode %d-4

InfluxDB Version: 2.0.4
IoTaWatt Version: 02_06_02 ALPHA
URL Used: http://ip_address:8086/api/v2/

-4 is unable to connect, so possibly the IP is wrong or the influx service isn’t running on the remote host?

Thank you for the rapid reply @overeasy. Hmm, when going to the URL in a browser it returns the following:

{"authorizations":"/api/v2/authorizations","backup":"/api/v2/backup","buckets":"/api/v2/buckets","checks":"/api/v2/checks","dashboards":"/api/v2/dashboards","delete":"/api/v2/delete","external":{"statusFeed":"https://www.influxdata.com/feed/json"},"flags":"/api/v2/flags","labels":"/api/v2/labels","me":"/api/v2/me","notificationEndpoints":"/api/v2/notificationEndpoints","notificationRules":"/api/v2/notificationRules","orgs":"/api/v2/orgs","plugins":"/api/v2/telegraf/plugins","query":{"analyze":"/api/v2/query/analyze","ast":"/api/v2/query/ast","self":"/api/v2/query","suggestions":"/api/v2/query/suggestions"},"restore":"/api/v2/restore","scrapers":"/api/v2/scrapers","setup":"/api/v2/setup","signin":"/api/v2/signin","signout":"/api/v2/signout","sources":"/api/v2/sources","swagger":"/api/v2/swagger.json","system":{"debug":"/debug/pprof","health":"/health","metrics":"/metrics"},"tasks":"/api/v2/tasks","telegrafs":"/api/v2/telegrafs","users":"/api/v2/users","variables":"/api/v2/variables","write":"/api/v2/write"}

So the influx service is running and the IP was copied fom the IoTaWatt. Any ideas?

Can I see the influx setup display and the message log?

@overeasy sure, please find below the requested information. It’s still giving a -4 but now says influxDB2: Running, Last update 20/04/2020 08:44:25 Post failed -4

IoTaWatt Message Log:

SD initialized.
4/19/21 22:37:40z Real Time Clock is running. Unix time 1618871860 
4/19/21 22:37:40z Reset reason: Exception
4/19/21 22:37:40z Trace:  31:110, 31:110, 10:18, 10:23, 10:17, 10:17, 10:17, 1:3, 1:1, 1:2[1], 9:0[1], 9:0, 9:1, 8:4, 8:6, 8:8, 8:9, 9:3, 9:5, 9:9, 1:2, 1:3, 1:3, 1:6[1], 1:6[3], 1:5[31], 1:6[4], 31:0, 31:1, 31:2[1], 32:20, 32:20
4/19/21 22:37:40z ESP8266 ChipID: 6196660
4/19/21 22:37:40z IoTaWatt 5.0, Firmware version 02_06_02
4/19/21 22:37:40z SPIFFS mounted.
4/20/21 08:37:40 Local time zone: +10:00
4/20/21 08:37:40 Using Daylight Saving Time (BST) when in effect.
4/20/21 08:37:40 device name: IoTaWatt
4/20/21 08:37:40 HTTP server started
4/20/21 08:37:40 influxDB_v1: Starting, interval:10, url:http:/ip_address:8086
4/20/21 08:37:40 influxDB_v2: Starting, interval:5, url:http:/ip_address:8086/api/v2
4/20/21 08:37:40 timeSync: service started.
4/20/21 08:37:40 statService: started.
4/20/21 08:37:41 dataLog: service started.
4/20/21 08:37:43 dataLog: Last log entry 04/20/21 08:37:35
4/20/21 08:37:45 historyLog: service started.
4/20/21 08:37:45 historyLog: Last log entry 04/20/21 08:37:00
4/20/21 08:37:47 WiFi connected. SSID=SSID_NAME, IP=ip_adddress, channel=6, RSSI -79db
4/20/21 08:37:47 MDNS responder started for hostname IoTaWatt
4/20/21 08:37:47 LLMNR responder started for hostname IoTaWatt
4/20/21 08:37:47 Updater: service started. Auto-update class is ALPHA
4/20/21 08:38:07 influxDB_v1: stopped, Last post 04/20/21 08:36:10
4/20/21 08:38:07 influxDB_v1: stopped, Last post 04/20/21 08:36:10
4/20/21 08:38:09 Updater: Auto-update is current for class ALPHA.
4/20/21 08:44:23 influxDB_v2: Start posting 04/20/20 08:44:30

I see that you are trying to run both influx1 and influx2 at the same time. I do that with a local version of influx1 on a Rpi and the influxcloud v2. You have removed the IP addresses used for the two versions (why?) so I can’t see if they are different. Are they different? Also, your WiFi is pretty weak at -79 RSSI, which could have something to do with the -4 connection failed above.

Habit. I can assure the the two IPs are different and each InfluxDB installation to separate LXC containers.

I’m aware the RSSI is weak on the device, however InfluxDB v1 has no issue, have also tried stopping it and only running the v2 service, same issue.

I’ll get the RSSI fixed but I’m not sure if that is really the issue.

The Exception that you posted is occurring in the V1 handler. Even though you may have them stopped, the uploaders will query their respective influx instances during initialization. If your influxV1 instance works fine without influxv2 defined, then there’s something going on with the V1 installation when the V2 is defined.

I also see two stopped messages for v1 after the restart, then V2 starting. What happens then? Do you have any idea what data has been uploaded to the V2 instance through 8:44:30?

I see. Didn’t realise it was coming from the v1 handler. I can confirm that data is being received by the v1 instance while the v2 is defined.

The stopped messages are me manually stopping and starting.

There has been no data received by my v2 instance, time period was set to past 7d.