I made the shift to Hubitat in late 2021 and have enjoyed the process.
I successfully followed the instructions here for setting up my influxDB environment:
However, I recently moved and switched ISP (now using Xfinity) and began encountering the following error:
postToInfluxDB(): Something went wrong! Response from InfluxDB: Status: 408, Headers: null, Data: null
After searching for details on http response status codes I learned that 408 implies a client request timeout
I was able to correct the issue by logging into my new ISP provided modem and configuring a port forward for my host machine running the influxDB server allowing inbound/outbound traffic from 8086.
Hope this helps for anyone else running into issues!
More details are needed. What version of Influxdb Logger are you using. What version of Influxdb are you running. Is influx db and your Hubitat on the same network.
My guess is when your changed ISP's the different equipment is using a different class C network for your home. Think of like going from 192.168.1.X to 192.168.86.x. Depending on how everything is setup it may not have gracefully update. My suggestion would be to confirm the IP address of your InfluxDB server and then validate it is right in the InfluxDB Logger Smartapp. If they are on different subnets meaning that third number in my example of 1 or 86 then you will need to make adjustments so they are on the same subnet.
Hav the same issue. Trying to upgrade my 1.8 to 2.6 on another computer. Didn't get to migrate the data so just started a new bucket. Entered all details in the logger pointing to my new internal server.
Anyone know what could be wrong? @jtp10181 would probably know in an instant....help?
I uninstalled the infludxdb logger app, rebooted and then reinstalled it. At first it didn't like my auth being username & pw for the 2.0 bucket but then I switched to token. Looks like it's all good now.
Do you have the latest version of InfluxDb Logger from HPM? It was just updated last week to support InfluxDB2.x. The earlier versions didn't support InfluxDB2.x unless you were running a version that someone forked to add it.
Can you show your settings on the "Connection Settings" menu?
Influxdb2.x requires additional setup to continue to use User name and password. The latest version of INfluxdb-Logger does support the use of a Token though and that is probably the easier option to use.
@walksonair Yes there is a new version of Influx Logger which directly supports 2.x using the token. I have not tried it myself but I trust that it works well.
@mavrrick58 I just noticed I did not get the update to influx via HPM. Looks like the way the version was removed from the top level and then added to the app entry itself in the packageManifest is confusing HPM. Both places are valid, not sure why it was moved. A repair also just fails. I think I will have to unmatch and rematch to get it to work. May want to fix this?
UPDATE: Running the repair twice seems to have gotten it past that and updated. But before that I tried running update more than once and it did not find the update, which means a lot of other people possibly wont see it either.
@dennypage I believe moving the version tag back to where it was in the JSON and updating it to 2.0.0 there would fix it. Unless my HPM was just misbehaving for some reason? No errors in the logs though.
@csteele possible bug in HPM if version is moved from top level to within the app/driver definition. I know on mine I have ADDED it to the top level after the fact and it caused no issues, since you are pulling it from there for your site, but I never tried going the other way.
Yes I noticed that I didn't have the latest app version installed even though HPM said no updates needed. So I deleted the app, then rebooted, then installed via HPM again. I now have the 2.x methodology listed correctly.
Ok so I have Influxdb2.6.1 on my server for testing. I repaired my dev hub environment to the current code that you would get and configured it to send a bunch of data to that influxdb2.6.1 instance. It is working.
That error message appears to be related to the headers. The only part of that which you setup in this process is the Token.
When you setup your token how did you do it and what kind of token did you create. Is it a all access one or limited access. Can you try to put the token in again or recreate it. Can you make sure there is no space before or after the token
I believe everything is working except for this error as I have plenty of data now on the new InfluxDB 2. Therefore I would not suspect an issue with the token.
I generated the token after setting up my user & org. On the InfluxDB Web GUI, I went to Load Data:API TOKENS and then hit the Generate API Token. AFAIK, I only have the one.
By the way, what hardware are you running your influxDB on? If its a Mac...I'm gonna DM with hopefully a quick question.
OK so when I went through any combination of of thing I could trying to create exactly what you show above, And frankly I couldn't. Listed below are the errors you would get if any of those values on the Connections settings page were incorrect.
408 = wrong IP address or Wrong port
404 = incorrect ORG value or Bucket Value
401 = token problem
I also found some evidence that the 400 status code you were getting is related to the data being sent. This is strange as we didn't do anything with data being sent in the updates that were posted to support InfluxDB2.x. Reguardless of that, it appears something is causing a parsing issue when the data is sent to Influxdb.
In live Logging you should be able to filter on InfluxDB Logger and see all of the events handled and then also what the values are. You may need to open the app and adjust the logging level if you don't see it. Can you post all of that data so we can see the information for the devices. My guess is you have a device that is including something that is breaking the InfluxDB Parser now.
This resembles the kind of data i am looking for. The Handle event() items, The Writing Queued data line and then the PostToInfluxDB() line that should be followed by the error.
My production gear runs on a Unraid server in Docker. It actually has multiple instances of InfluxDb on it. My production instance of InfluxDB is still 1.8 and i just haven't managed to find a reason to upgrade it yet. Concern for support is starting to make me anxious though.
@jtp10181, I expect that you are correct that it would fix the issue, however I was advised to move versions out of the top level back in June. @csteele, appreciate your comment on this before I make another change. Thanks.
Yeah that's how I was doing it before and it works good, but was trying to plug in the right stuff to get it to populate the site he made, so I added the top level version.
My interpretation is that HPM tries to be tool for developers and their imagination. HPM deals with Packages, first and foremost. Be that one groovy file or hundreds. I think Dominic allowed version in the top level for single file cases and in the lower level for multi-file packages.
I'd say the top one is for the Package while the per code versions are for the individual code. If I take a biggish package like HubConnect, the current top level version is v2.0, yet individual stub drivers may be at v2.0.2. The Package, as displayed in Browse HPM Packages would / should display as v2.0
A single file Package, such as my AeotecMultiSensor6 would not have any distinction between the Package and the file it contains. It should display as v2.0.2 and ideally wouldn't matter where the version callout was.
If the top level perception to people is that HPM is a way to manage Packages, then there should be an identification of the Package, with the components of the Package secondary.
