Call me a curmudgeon, but I am overwhelmed by all the window/door sensors happily reporting temperature along with contact open/close. Don't need 'em all, don't want 'em all. The sensors are all Iris V1 door sensors, which are rock solid performers as compared to the Xiaomis.
But worse than being annoying, they clog up the event database with useless trivia about temperatures that are not actionable. They make the memory of the net system shorter.
Does anyone know of a driver that ignores one or more data elements? I'd like to modify my driver, but I was hoping that someone could point me to an example where a specific report from a device is silently dropped on the floor without creating an exception, and without enlarging the size of the event database.
You're a curmudgeon. But you make an interesting point that hadn't occurred to me so I'll be watching. I believe you are correct in needing a modified driver to make this happen.
The Driver is only part of the problem. Ignoring the Reports is good, of course, but they are still clogging up your mesh. A better path would be to disable/dial back the Reporting interval. But that would depend on that option being part of the firmware of the Sensor. I couldn't find any info.
Setting the reporting interval IS a very good idea, thanks... too bad "never" is not a choice!
It seems to be possible for the V2, looks like I have to mess around to see if I can fling this at the V1 and get anything to stick.
Showing my age here, both SCADA systems and snmp command/control had the ability to "walk" a device with a series of "getnext" commands. This exposes the various registers that one can read (and potentially write), and usually also reveals the device model, serial number and current revision of hardware, firmware, and software. Anything like that in the world of IOT, or did they ignore history, and create a series of isolated silos full of mirrors?
How many reports are you talking about? They should only report a change of a degree or more to the system.
But you can't view the event database directly, so what do you care?
Not true. The system has the same amount of memory regardless of how many devices or events you generate. Memory is static.
You're talking about the least labor intensive part of the whole process. The hub part is fast. What is resource consuming are the mesh messages from your devices. The only reason this would be a problem though is if you are constantly refreshing the devices. If you are, then your battery life is going to be terrible.
I have a total of about 20 door/window sensors per residence, and I am equipping residences in Ocho Rios, Los Cristianos, Virginia, the Jersey Shore, and Manhattan with the aim of simply having better "oversight" when I am away, both for me, and for the caretakers.
I answer that below...
Let me rephrase for the extremely literal, then - the amount of memory available to hold data of value is reduced, so the "lookback time" for graphs of power consumption, water consumption, and temperature readings I DO care about is reduced. The eleventy-seven temperature readings I DON'T need waste memory.
I am not concerned about "labor" here, as the annoyance is that the garage door sensor (par example) reports perhaps two or four events a day - open/close, open/close. Yet to see those events in the log, I have to page through endless reports of the ambient temperature in... the garage! I don't care about the temperature there, I should be able to stop it, moreso with the help of the multiple kind people who have made very worthwhile suggestions.
Yes, I can build summary reports, or graph activity that only look at the events of interest to me, but in a residence that is unoccupied, secured, and doing minimal climate control, the logs I CAN see are clogged with useless temperature reports from the large pile of Iris V1 sensors I bought cheap. As I protoype this in NJ, I can see problems that I'd rather not face from one to several thousand miles away.
It is OK if you think I am wasting my time - it was also likely a waste of time to put a big honking battery backup on the power feeds to the hub, the watercop, the router, and the FiOS gear or cablemodem, but I want bulletproof to the extent I can have it, as I don't want to have things glitching, as power in other countries is less reliable than we enjoy here in the USofA.
I see what he's saying, though - he'd like to be able to see actual events (open/close, etc.) from the devices, without seeing all the temperature reports. Turning off description text logging would stop both.
What driver are you using? If it's not a built-in, you could find and remove the line of code that's outputting the temp to the log; if it is a built-in, perhaps you could find a user-written driver that would work, and could be modified.
The system retains 1000 of EACH attribute. Thus if your contact sensor has two attributes, Contact open/closed and Temp, you'll still have 1000 backwards looking events for Contact.. Put another way, the 1000'th oldest contact data point would be hundreds of days further back than the 1000th oldest Temp data point.
Said another way... 3 days of Temp data points might fill the 1000 and you'll start dropping them off the end. But it would take say... 160 days for the Contact data points to fill the 1000.
I think 1000 is too big anyway.. I'd be OK with 100-200 and assuming 3 garage door open/closes per day would yield more than 2 weeks of Contact data instead of 160
If this is the case, then I do not understand how Hubigraph works, as until I disabled the unneeded reports of kWh for each phase and the sum total kWh, the data for raw watts consumed on each phase truncated sooner, leaving only more limited look-back period on reports that were generated at the same interval.
Regardless, the logs are also filled with such things, and for those who want a quick summary of a week's happenings at one or more unoccupied residences, such things are annoying. Without all the temperature data, the log would contain that summary, as in a low activity scenario the gate open/gate close announces the visit of the lawn mower and the pool guy, the 500 watt increase in the power consumption while the pool guy visits shows that he did actually backwash the filter, and so on. Without all the useless trivia, I am happier, so I don't need to be talked down to with statements that may be accurate, but are neither useful, nor well thought out.
I'm sorry, perhaps you are unaware of the many complaints about the time required to backup the hub, and the sized of these backups. Both would be reduced by grabbing unneeded data and tossing it out before it hits the database or the log. Capturing every babble from an IOT device designed by a teenager and built in China unconditionally seems foolish to me, as some want to be the center of attention by default (for example Aeon power-panel monitor, which needs some manual intervention with the Z-Wave tool to make it slightly more taciturn, rather than being a far too much of a literal chatterbox).
In fairness to the fools that run this place, that's hardly an accurate description of either Iris v1 or Aeotec devices. Made in China sure, but which low-cost electronic devices aren't these days?
I also appreciate the option to turn down the frequency of event reporting in the built-in drivers that support it, for example various "pocket socket" drivers do, because power reporting events can otherwise be quite overwhelming.
But I would suggest keeping a couple things in mind as it relates to Iris V1 devices specifically. For one thing, AFAIK there's no clear evidence the device even allows its temperature reporting events to be configured? And even if it did, Iris v1 devices were meant to be proprietary to the Iris system, they're otherwise end-of-life devices and Hubitat added support for them to make it easier for former Iris users to transition to Hubitat when the Iris platform was axed.
But there's gotta be a point at which they stop actively developing drivers for an entire class of devices that are end-of-life?
Since viewing only certain log events from multiple hubs seems to be a priority for you, have you considered any solutions to export log events to another database that has fuller features related to filtering and sorting?
As I remember Iris was introduced in 2012... to hand-wave it away as "end of life" defeats the entire strategy of a "big tent" device like Hubitat, which is marketed as "supports the widest range of devices and scenarios". If I glance around, I see a very old McIntosh tube amp from the 1970s, speakers from the 70s, a radio tuner from the 1980s, and out the window, a car built in 1952 in my drive. I think your designation of "end of life" is just a bit wasteful in comparison.
I don't understand why I am getting such fierce pushback rather than comprehension. I do NOT expect the device to stop reporting, I am hoping that someone can give me a hint as to how to modify the driver to drop unneeded data before wasting any time on it, to reduce the size of the database, and to reduce clutter in the logs.
Yes, of course I could export the log and run it though an awk script (awk - now there's something you'd call end-of-life, even though many find it useful enough to continue to use and support!) to strip off the extra data, but again, the Hubitat is sold as a stand-alone device that needs no outside servers, for better network security. I'd rather not keep yet another processor running just to tell me what the first processor has been doing all day if I can avoid it.
But this is a question about drivers, NOT about personal opinions on the utility or futility of the effort:
a) Can a driver be modified to drop specific data on the floor rather than log it? (yes)
b) Can it also drop data on the floor rather than putting it in the database? (Still unknown)
c) Can a device be told to stop reporting certain data? (Not the Iris V1 contact sensors, but some devices can be so configured.)
Fools do not run any of the places, what I said was about the USER who captures all that data rather than striving to keep the "idle chatter" to a minimum. If nothing else, there is a limited capacity of the Zigbee and Z-Wave radios to handle all the asynchronous traffic.
Iris went with a proprietary version of the zigbee home automation profile for the devices they branded as part of their home automation subscription platform. If you didn't have Iris, it didn't make much sense to purchase those sensors. Then they shut down that service a couple years ago. Since they offered a buyback of old sensors, there are now many many many of them floating around these days from resellers all over the net that presumably bought them in bulk once Lowe's unloaded all those sensors they bought back from former Iris users.
Hubitat certainly did a solid for former Iris users that held onto their devices by figuring out how to get the old devices to pair with Hubitat. But in the case of this entire class of devices, I would argue that their development time is better spent elsewhere.
I do wish you good luck in finding a solution that works for you, though!
So after all that pushback and sermonizing, you have no information or even guesses on question (b) above...
Gosh, Zigbee and Z-Wave have SO many proprietary variants, it seems that EVERY vendor does something a little different, and no one simply implements the standard cleanly
It has always been thus, my son. We had the same complaint about a serial port spec called RS-232 back in the 1970s. By the 1980s, I sat on the T-1 Committee, which fought endlessly over a simple set of 24 subchannels sharing a single telecom line.
To throw up one's hands and walk away from any device that does not comply with one's own view of a industry standard is to say "we are NOT interoperable - we are prima donnas".
I see that you call yourself an "Ambassador", so maybe you work for Hubitat, maybe you are just a big fan, but I have recently read this same excuse applied to Iris and Ikea devices. Sure, there are limits, but when a USER and CUSTOMER asks about the feasibility of adding a feature that others find useful to YOUR favorite product, the appropriate response is not to argue with him.
Like you said, you probably need a custom driver to fix this specific issue of database log entries, maybe even mesh congestion if the device firmware itself can be configured by a driver. I'm not a developer, so that's about it for me. I certainly hope I was able to paint some picture re: why the Iris v1 sensors are particularly odd ducks, even within the world of competing standards.
Since this is something you're passionate about, and your tone comes off as irritated and increasingly aggressive (perhaps unintentional, but that's a limitation of relying entirely on written words when communicating, unfortunately), I'm out at this point and wishing you a good day.
Last point. The group of users with the ambassador tag are not hubitat employees, we're just fellow users who also enjoy posting here. Hubitat staff have either a "staff" handle, or a little shield icon, next to their forum avatar.
@marktheknife It is slightly bizarre to be accused of being "increasingly aggressive" by someone who calls themselves "marktheknife"!
The line that gets crossed is when perfectly competent people who want to use this tool, and have technical backgrounds, some of us with considerable experience in "development" and "R&D" get patted on the head and told "you don't want to do that" because of a preconceived notion or misunderstanding of intent on the part of the self-appointed critic.
There's a difference between "constructive advise" and "heckling". Constructive advice helps the user to achieve his goal or provides tangible information. Nay-saying and arguing that the user is wrong to want what he wants with 100% fact-free opinion is "heckling". (As you can see, I am far less than "diplomatic" or "ambassadorial", but this is certainly not "irritation" or "aggression", as I am apparently being forced to defend my need as a valid one.
I used to run code reviews where the need for this enhancement or that one were weighed and subjected to group consensus, and we never heckled anyone. The result was a little operating system named "Unix" you might have heard of.
You made your feature request, and you really don't have any obligation to defend it - anyone that thinks an enhancement would be value added can make a request. That is always welcome.
Now, when you post in a public forum, everyone else has the ability to add their thoughts as well. That doesn't mean they are heckling - it means they are posting their opinion on your idea - and their opinions/ideas may differ from yours. Obviously if you don't want comments from the public, then a PM or email to support would be more appropriate than a public forum post.
All that said, there is no point in arguing about it on here, as none of us are the decision maker on this. I'm sure Hubitat saw your request and will put it on the list for consideration, weighing the engineering effort to do it versus the benefit of the feature.
If you want it sooner than that, yes, you would have to make a custom driver to add that feature.
But you make an interesting point that hadn't occurred to me so I'll be watching. I believe you are correct in needing a modified driver to make this happen.
