Not a bad idea. I also wonder if it would make sense to have a option do a emergency post that does something like move the entire backlog to a field value that puts the data in memory and then posts it to influxDB. InfluxDB can handle many thousands of records at once in a single post.
I know Denny does have some protective functions he added to the app that should prevent the backlog from getting to big when the failure isnt in the Hub. I would strongly suggest using the recently added function to post the backlog count to a hub variable. Then you can have RM send you messages when the backlog starts to build but before it gets way out of hand.
Yeah that's exactly how I had it set up, but unfortunately, that is what was causing it to fail. The setGlobalVar() throwing an exception I mentioned before, that was on the hub variable tracking the backlog size. The RM rule apparently never triggered (had set it to >1,000). I didn't have anything relevant in the location events log for that variable until after the reboot. Something was really wrong with that hub variable somehow.
I gave another look at the code and believe the second quote is the answer to the first one, @dennypage .
If that runIn() doesn't get called for any reason, the chain is broken and the queue never gets processed again, unless, as @mavrrick58 suggested, one goes into the app config and presses "Done" (and in my edge scenario, it wasn't enough to get things going again). All the while, events continue to pile in.
Some thoughts
should there be a backlog size check on handleEvent and similar handlers (and pruned if over the limit ?)
should there be scheduled calls to writeQueuedDataToInfluxDb() instead of relying on runIn() chains, or in addition to them as a failsafe?
I vaugely remember there being a firmware that had a problem with corrupting hub variables. It was fixed quickly if i remeber right but i have to wonder if that is related somehow. I don't see why it would be, but just a thought.
Yes, that is correct. FWIW, I tested previously with a recurring (scheduled) failsafe timer previously, and when it got into the state of runIn() not functioning, the recurring timer failed as well.
I'll have to look at a safety valve that will impose dataloss if the backlog goes to 2-3x or some such to prevent a runaway.
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)
}
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
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.
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:
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?
