Not really.. if I go to a device and turn off all the logging options, typically NOTHING would be logged at all to the logs that I can see from the hub UI. They would still be posted to the events for the device, but not printed into the actual logs. I assume you know this though, you have coded drivers.
It looks like what i am thinking of is generally labled as descriptive text logging. I guess i don't tend to turn that off.
I still stand by that thay information is better at giving a picture in a why did this happen scenario then trying to piece it together by looking at events from different devices.
Probably, assuming you have logging enabled, or you turn on more logging if having issues to troubleshoot, then turn back off.
Still not a fan of the soft polling though. Part of my job is pulling data from SQL, analyzing it and creating reports. I don't want extra garbage in the data, just the real data, the real events. Nice thing is I believe if you don't like it, it can be turned off. So no harm in leaving it in really.
I don't think this chart would work correctly if I had all sorts of extra events in here. I can mouse over any on or off period and see the total time between since there are only the on and off events at start and end, nothing in the middle. Its also color coded based on if the event was physical or digital (or unknown if blue). If you soft poll I think you would just see switch is on, but not know the full event info.
1 Like
Hubitat being event-driven, events are literally triggering everything that happens on the hub... That being said, logs certainly provide much more context. Complementary sources of info.
I totally get that. I think this is totally situational and completely for the purpose of visualization of the data. I have worked for the last 20+ years on IBMi systems managing a billing system. I have heard and said the saying Garbage in garbage out so many time over that 20 years. I totally agree in general allot of use cases you don't want data that is fake in a system. But allot of databases are not about visualization and are regularly dumped data from sources.
I think the issue is really that for some reason the thought is since it isn't an event it isn't true with respect to visualization. That simply isn't the case. Just because a switch doesn't trigger an off event doesn't mean it is in a different state. For the sake of being able to visualize that over the course of few hours where nothing happened you need data points. That is what the polling does.
Your example graph would work completely fine with polling. Though this is kind of apples and oranges since you are doing this through node-Red. I don't know if all the same data is loaded from InfluxDB Logger. The visualization would work. Your other data like how long something is in a particular state may break or need a change to the query.
I will say like I said above in this thread, it is situational. I agree with everyone that polling in it's current form is to heavy handed. It needs a more conservative implementation so it really only runs on devices/attributes that need it.
1 Like
Here is the point in the Node-RED thread about why some data was being re-written, it's pretty easy to follow. Basically it appeared that the fills in Grafana were not working correctly. There were a couple example flows that re-write data that is continuous - temp, lux, battery levels, etc. The posts were from 2019, so I don't know if that situation still exists.
I just found a dashboard that looks very similar to what you have there but with motion detection. It actually provides the exact same data including the time periods between change state despite the devices being polled ever 15 min.
What do the black spaces represent? A light should either be on or off. It is a discreet measure. (I see how adding physical/digital adds complexity in the case of a potential soft poll)
The thing with digital or physical is that it isn't exactly a attribute, but a characteristic of the event itself. I don't think InfluxDB Logger would even send that. It is focused on getting changes to attributes into InfluxDB.
It could be enhanced to send that, but that gets us away from device attributes and into event details.
The transparent (black) is an Off (digital or unknown). The light grey is a Physical Off (someone touched the switch physically).
Since I have a lot of the lighting more automated now I don't use this that often but it does help if I am checking on a new automation working. Also helps to see how late the kids were up and when they turned lights on/off with the switches.
It was kinds of one of those things where I have all this data now what cool stuff can I do with it. I love making beautiful and useful charts, my co-workers can attest to this as well.
Probably not but it was part of the event data I had in NR so I sent it to Influx and its cool what you can do with it.
Good to know, was not sure exactly how Grafana would handle that. Here is my motion and contact sensors chart:
Ah, my bad, I didn't see the black (transparent) label and apparently have a hard time counting to 5.
Looks like that wouldn't take much to add, but i doubt that would work with soft polling as it is part of the event data. The field is "Type" and standard to what is in the events list when looking at past events on a device.
Actaully the more I think about this, what @jtp10181 pointed out may be the perfect solution for what has been brought up in PR 39. Maybe it would make sense to add the type of event to the data field being processed in handleEvent() and then when the soft pool runs it populates the event type with "Polled" value. This has two benifits. First it will capture a real potential state of events that isn't beeing captured now, and then it also then allow a method to track if something is polled.
This along with a filter to prevent polled values from happening at all if any event took place for that attribute could provide better use of the Polling feature and fill the PR request.
Thank you @dennypage and others who are updating this app!
Question, does this new version still support the Influxdb version 1.x?
Request,
I’m using a Qubino 3-Phase Smart Meter with the built in Hubitat driver.
In addition to the Qubino 3-Phase Smart Meter reports total 'power' and 'volts' it also reports per phase individually. I have now manually modified the code as below. Is this possible for you to insert into the code?
Line 311 original:
state.deviceAttributes << [ devices: 'powerMeters', attributes: ['power', 'voltage', 'current', 'powerFactor']]
Line 311 modified:
state.deviceAttributes << [ devices: 'powerMeters', attributes: ['power', 'powerPhase1','powerPhase2','powerPhase3', 'voltage', 'voltagePhase1','voltagePhase2', 'voltagePhase3', 'current', 'powerFactor']]
Yes, it does.
Would you like to submit a PR?
Great, as i have still not yet upgraded to InfluxDB 2.x
FWIW, I am still using InfluxDB 1.8.
1 Like
Yes, but I'm not familiar where and how to do a PR
