Correct. At that point in time I had edited the installed code to add a couple of log entries while investigating. Sorry about that.
I did not, and I have not yet re-introduced queue size recording to a hub variable to my InfluxDB Logger instance. I'll give it a shot.
I would try to reuse the same variable and see if it works before recreating one.
1 Like
I've set it up again, so far so good, however I made local changes to the code in two places to reverse the order of scheduling the next run and setting the hub variable, just in case the issue reoccurs when I'm not looking (it's my production hub).
// Go again?
if (loggerQueueSize) {
runIn(1, writeQueuedDataToInfluxDb)
}
// Update queue size variable if in use
if (prefQueueSizeVariable) {
setGlobalVar(prefQueueSizeVariable, loggerQueueSize)
}
Did it work using the same variable as previous?
I'm okay with the swapping of those calls. I assume the other place you changed was the post fail code?
It appears so, yes. However, after I figured out the problem and got the backlog down to 0, I went ahead and updated HE from 2.3.7.144 to 2.3.8.125...
That muddies the waters a bit. I've asked Victor if he has any thoughts about how a call to setGlobalVar() could create excessive hub load, so he may want to look at your hub anyway. I'll let you know if he does.
Yeah I know. I suppose I could have been more patient.
Great, thanks. I did send Victor a PM with lots more details about the incident (and my hub ID) when it happened. There was a lot going wrong with the hub. Left it as is a whole day. Not sure if he got a chance to get to it live... but the house was badly broken so I couldn't leave it longer in that state.
Can't help but wonder if the first item in known issues that appeared shortly after is in any way related, or just a coincidence : Known Issues in Release 2.3.8.123
1 Like
I've a reasonable failsafe in case the chain is broken. I'm also in the process of pulling the old migration stuff out.
I'll put out a release in the next few days.
2 Likes
Update with a failsafe for the timer chain has been pushed.
Please note: This update removes the automatic migration of settings from versions more than one year old. In the unlikely event anyone is still running a version that is more than a year old, it will be necessary to update settings in the app and re-save them after installing this version.
2 Likes
Not sure what I'm doing wrong here. I've got InfluxDB Logger v4.0.0 installed on my C-8 via Hubitat Package Manger.
I have InfluxDB v2.7.5 installed in a Docker on my Synology RS2423+. I'm able to access the webUI at the default port with no problem. I created an org ("Hubitat") and a bucket ("Hubitat").
I have tried to use the login information (user/pass) and also later tried to generate an API token. I put all of this info into InfluxDB Logger, and I always get this:
warn Post of 50 events failed - elapsed time 0.078 seconds - Status: 401, Error: Unauthorized, Headers: [X-Influxdb-Build:OSS, X-Platform-Error-Code:unauthorized, X-Influxdb-Version:v2.7.5, Content-Length:55, Date:Wed, 03 Apr 2024 06:33:17 GMT, Content-Type:application/json; charset=utf-8], Data: null
Hmmm.. I can actually see data from the Hubitat hub in the Data Explorer of influxDB's UI. Hmm... Not sure why I keep getting the Status 401. Is it related to a specific piece of data that is null and it is trying to post unsuccessfully?
regarding login, as the unauth sorta tells the story I think. Initially I tried user/pass but it wouldn't work correctly to my NAS. The solution was dedicating a token.
Setup a new token, then copy paste it into the HE app - I didn't use the admin token, i created a seperate and distinct one for my bucket with all rights. I'm using this token for HE to Influx, Grafana to influx and Telegraf to influx. On the influx screen when creating the token you choose custom or All Access. I initial tried custom but got some errors. deleted the token, started over and set it to all access and I was successful.
1 Like
Check your connection properties. NB: with InfluxDB 2.x, you are going to want to use a token. You also need to ensure that the token has rights to the bucket.
I’m running influx 2.7.6 and this seems to be causing a compatibility error with my influxdb logger instance. At least that is what I think is going on. I’m running the logger on 3 hubs and only one of them is throwing errors however. kind of weird.
edit: well, thats not the problem. i rolled back to 2.7.5 and it didn’t fix anything.
edit2: i suspect i have misformed data in my backlog that won’t post. i think i have corrected the issue, but I’m not sure how to fix/flush the backlog.
edit3: I got the backlog cleared by lowering the allowable size and it deleted everything. Ultimately the data was from MQTT and is defined only as “payload” by the MQTT connection driver. when I turned MQTT back on it immediately broke the influx logger again, so for the time being I am just not including those devices.
I don't use MQTT on Hubitat, but based on the documentation I expect that payload is the actual MQTT message itself, which wouldn't be very useful in InfluxDB.
MQTT messages are strings, with a format that is arbitrarily defined and agreed on between publisher and subscriber. There is no reasonable way for InfluxDB to decode MQTT messages.
FWIW, I think you probably want the resulting device state after the message is processed, yes? Perhaps someone else has done this previously and can comment?
no, the MQTT message is the string. I’ve got a sensor on my water softener that sends the percent and the distance. interestingly, it was working fine and I was graphing it in grafana, until I refilled the water softener salt. once I refilled the salt the whole thing broke. Initially I thought it was b/c I filled it above 100% (based on calculations done on the arduino), but I deleted that data and it still isn’t working. transmitted 25% no problem, but 99.7% and its broken. 
Yes, the issue is that the meaning of the payload string is unknown to InfluxdDB Logger. Just looking at the examples, and assuming ascii, possible interpretations are string, integer, and number (decimal). Even if the '%' is removed, you still have an issue between integer and decimal.
Influx requires all field submissions to be of the same type. InfluxDB Logger needs to know the types in advance in order to format the insert post correctly for InfluxDB.
