So, I like graphs. Nothing makes a graphic point as graphically as a graph.
But these IOT devices are not exactly ready for NASA - sometimes data gets garbled during transmission, and the communications protocol apparently does not correct errors.
No, I did not suddenly draw 35,000 watts from the power grid - even my stereo amp is not THAT powerful. But the single "trash" data point messes up the graph for as long as it takes to get it off the screen. And it should be obvious that the reading was "out of range" data.
So, how to take a vanilla driver, and mess with "parse" to drop outlier data on the floor, or go into the database and overwrite that data point with a null (or a copy of the last value read) to get rid of it? Is this even possible?
Please, no lectures on how my network is to blame - I have invested in extra Z-Wave Aeon power-strip devices to make a "quality mesh", I even have 3 Schlage deadbolts happily running. I also run a Hubitat C4, as I had premonitions of "new" hardware with integrated modems being less solid than a modem bought from a modem-maker, so no C7 for me.
I just want to be able to toss out data that is outside a "reasonable" range for the device, so that the resulting system is more fault-tolerant.
How did you determine that was happening? I have no basis for saying that isn't what is happening other than knowing that error detecting/correction is fairly trivial and I would be surprised if this is the explanation.
Rather, I think the fault lies with the power monitoring in the device. I occasionally see measures reported from my Zooz ZEN15 that make no sense. The author of Better Laundry Monitor accounts for such in his app
What are you using to generate these graphs? Data is data. If you are trying to fix a presentation issue, i would suggest fixing it there rather than trying to remove data you don't like.
I am using Hubigraphs, and yes, I can limit the graph to let the outlier go "off the screen", but the data point is still there, isn't it? One would be hard pressed to do a decent "average" with random readings 100x the rest of the data set.
Because I got a lot more "spike outlier values" before I added the extra Z-Wave devices to reinforce the Z-Wave mesh, and the power panel is out in the garage, which is, like most garages, isolated from the rest of the house by a very sturdy concrete wall, making reception of Z-Wave frequencies that much more difficult.
Yeah, but that is an app - I am hoping to keep the data out of the database in the first place by modding the driver, but I am not sure if the drivers sit between the devices and the database, or sit atop the database, with the lower-level system calls taking data in from the devices, and populating the database.
And regardless of if it is a communications error, or a flaky device, I'd think it wise to allow nonsense readings to be thrown out by setting limits on what is "reasonable".
So, anyone know how readings get saved in the database, and how to intercept them, or am I making another attempt to program down to the bare iron through 3 levels of abstraction?
You should go post in the hubigraphs thread. I would find this option helpful as well. I have had a random spike occur in some sensors as well, it would be nice to be able to set a limit on the data and not just a max on the graph.
Not sure what is going on with hubigraphs they were making daily updates for quite awhile but it has stopped lately.
Agreed on that. And it probably should be done in the driver. A device driver would have no knowledge of any database. But it should be smart enough to throw out a reading that is clearly wrong. If a device has a max rated output of 15A, it should be smart enough to throw out a reading that is ten times that.
The device is a power-panel clamp-on ammeter, the Aeon HEM v1.
The driver is a smartthings driver ported to Hubitat: "SmartThings Device Type for Aeon Home Energy Monitor v1 (HEM v1)"
But, to make it work at all, I had to comment out all the attempts made in the driver to do any/all configuration of the device, and instead use the "Basic Z-Wave Tool" to manually configure it.
So all the "zwave.configurationV1.configurationSet" lines got commented out
I modified a User Driver to filter bad values. Specifically, the Advanced Honeywell T6 Pro thermostat driver occasionally got negative humidity values:
The modification is at:
The driver logs when it has to skip a value, and it happens every so often, maybe once a day or so.
It's possible to modify a user driver to filter impossible values like that. I don't like those values to be sent, so I just log the error. Not sure what to do with system drivers.
