Well, just to be sure it's in both places now. 
2 Likes
Doing that triggered an update now and it showed the prior version was N/A in the drop down (probably from when I did the repair earlier). So I suspect everyone will get the update notice now.
2 Likes
Doesn't look like it was due to the repair. I changed my other hpm entries to move version back to the parent. When I tested, all my apps said prior version was N/A.
I have some more clean-up for InfluxDB-Logger, but I'm going to hold off for a day or two to ensure the hpm issues are resolved.
Hi @mavrrick58 , sorry was busy outside yesterday w kiddos.
Yes, I see the logs and have only warn level and above going to the Hubitat log. Do you want me to change this to info level?
I think you're right in that there's a parsing issue going on somewhere. I had to upgrade to 2.X because of my 32bit RaspPi getting running out of room. I moved over to a MacMini so I just used Homebrew to install InfluxDB and use Homebrew services to start it automatically.
Let me know which logs you're wanting and I can DM them to you...
Looking at InfluxDB for the past 24-48 hrs, it seems to be getting data alright from Hubitat. It's just this one error that gets thrown.
I do have a bunch of WARNs but they're related to strings that are being state during device state changes. The warn message is handleEvent(): Found a string value that's not explicitly handled I didn't mentioned this before as I think it wasn't that big an issue considering it's probably data I asked to log but isn't graphical.
You could change it to INFObto get the rest of the details in the logging. You should then be able to see what device os generating that warning and what data that event is trying to pass.
Are you trying to capture data that has special characters or json data. If so turn that off and see of that helps.
You can also ensure only compatible items are processed by turning off the option "Get access to all attribues".
2 Likes
Ok, I will report back tomorrow on what I see in the logs. I turned off access to all attributes and was reselecting my devices when I noticed that almost every device was included under pressure sensors. Let me know if there's a mistake in the code for capabilities selection.
It looks like the Pressure sensor option is looking at anything that has the capability of a sensor instead of pressure sensor. I went as far back as I could in the repo history and it has been that way all along. @walksonair so that means this just impacts the Pressure Sensor options . Most likely none of those devices actually support air pressure so that group can be ignored. I have only every seen one device that does that and the rest would be weather integration. If you do have devices that support air pressure then just select them.
@dennypage looks like on line 126 of the active code base we need to change capability.sensor to capability.pressureMeasurement. Do you want me to go ahead and add that in my current PR.
Sounds good, thanks. I have a collection of cleanup changes that I'm planning to push soon as well. Mostly old SmartThings stuff.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
