Too Many Temperature Sensors! How to ignore them, and thereby not clog event Database?

🛎️ Get Help
16

Apples and oranges, unfortunately.

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!

1 Like
17

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.

iu

18

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.

:v:

3 Likes
19

@marktheknife It is slightly bizarre to be accused of being "increasingly aggressive" by someone who calls themselves "marktheknife"! :wink:

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.

1 Like
20

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.

7 Likes
21

If one reads the various statements from Hubitat staff on multiple threads, power user functionality development isn't high on the priority list. So, log control/maintenance isn't likely to be high on the list as event logs are used mostly as a trouble shooting tool.

Having said that, they do listen to power user requests. And they've hired a few new developers that are making improvements to the platform and drivers. (And I agree that some of the stock drivers are really at minimum functional levels.) So users should log their requests.

There are external methods to track history that are more powerful and flexible (but not as convenient) than Hubigraph.

1 Like
22

I couldn't agree more. I try to take care not to truly argue about anything, since in addition to it being pointless as you’ve mentioned, those are the threads that invariably get moved to the debate chamber, timeout room, or closed entirely. And that doesn’t end up helping anyone.

I have my viewpoint, OP has his. But when some posts degenerate into name-calling, I like to acknowledge that tempers appear to be flaring and pause for a bit, because that rarely leads to anything productive.

One doesn’t need to have any experience in IT to recognize that.

Edit: but in fairness to the OP, he did warn us in the very first sentence:

:slightly_smiling_face:

3 Likes
23

No argument there! I have to do that often... Lol

2 Likes
24

To be honest I was sure this thread would end up in the timeout room at around 8:01am EDT today, coincident with the temporary ban on a certain participant in the discussion being lifted.

So we’re actually doing better today than I had hoped! :wink:

3 Likes
25

Now THAT's FUNNY!!!

peace... I can kludge something together.

26

SOLUTION

Shockingly, searching for some working source code that handles a similar "generic zigbee contact sensor", what do I find?

I find a built-in driver:

Generic Zigbee Contact Sensor (no temp)

So - don't want eleventy-seven temperature reports per hour from your zigbee devices?
Just SWITCH DRIVERS, it seems.

I am just stunned to have stumbled over this after being blessed with so many diverse opinions as to why I should just be happy with the useless temperature reports from windowframes at 3 residences.

4 Likes
27

Yup. Glad you found the driver - I didn't know that was there. :+1:

1 Like
28

This is totally inaccurate. After you get to 1000 events for an attribute, the number of events in the backup will be constant. It will be 1000. Because that is the number of events that the system keeps. Whether those 1000 are from 1000 days or 2 days, that is the max number of events that will be saves for each attribute.

Correction: Now it limits the database to 100 events as of 2.2.3.

29

Sorry if I was unclear - for 2 identical Iris V1 door sensors, one provisioned with either the "Generic Zigbee Contact Sensor" or the "Iris V1 Contact Sensor" driver, and the other provisioned with the "Generic Zigbee Contact Sensor (no temp)" the one that uses the "no temp" driver will not be getting the temp data.

My database will be that much smaller for the lack of the temp data, it would seem. Regardless of how many points are kept in the database before it starts removing the oldest reading when adding the newest, the database file will be smaller.

My hub will also be that much faster, as it is not having to do all this removal of the oldest data when writing the new. In ancient SQL terms, that saves a query to find the oldest record (the "where" part of a "DELETE WHERE"), the overhead of the DELETE itself, and the INSERT to. Multiply this by a few dozen very chatty sensors, each reporting the ramp up and ramp down of daily temperature between 70s at night and summertime high 80s during the day, degree by degree, and one is avoiding roughly 40 such operations per day per sensor. (Hey people complain about hubs bogging down, and it cannot hurt to eliminate some workload. There is no avoiding the "chatty" nature of the sensor, so we are doing what we can with what we have.

If the database does limit one to only 100 events per data point, that's not well thought-out all all, as this means that I cannot track much of anything at any decent resolution for a 24-hour period. 1440 mins in 24 hrs, so I can't even keep one data point every 10 mins and be able to see it the next day. Looks like that local file manager is gong to get a workout to save the data.

30

If it was 1000, and it was recently changed to 100, how do you know that's not well thought out?

I'm not disputing that there could be a downside to that change as you have suggested.

But perhaps it was very well thought-out nonetheless. Or perhaps they did it for no good reason at all, though that seems less likely.

2 Likes
31

In an attempt to be less judgemental, I used the phrase "not well thought-out" to describe BREAKING THE ENTIRE PURPOSE of deploying home automation sensors, which is to know what happened over the past few days. If I wanted to have to constantly monitor a place, I'd be a security guard, not a happy retired person Kayaking around and enjoying myself.

32

While I often find it helpful to be able to look back at sensor data over time, I would not describe that as:

It's clear that's important for you, since you've mentioned you have multiple houses in more than one country that you'd like to monitor remotely.

I won't pretend to know enough about this topic to suggest whether there are easy workarounds despite that change they apparently made to how database events are saved. You're clearly very experienced and bring a great deal of knowledge in this area to the discussion. But your individual needs and priorities are not necessarily shared by all other Hubitat users.

And an important limitation on all of us, no matter how knowledgeable or experienced, is that we are all users, none of us work for hubitat and couldn't possibly be fully informed as to how/why they made decision X or change Y. So why start from the assumption that it was a dumb idea, vs. considering the possibility that you don't personally know why they felt like they had to make such a change?

2 Likes
33

Here’s another related thread that may provide some context.

34

@marktheknife I don't know if you are well-read enough to be able to know who Dr. Pangloss was, but you seem to be his reincarnation.

Let me save you some time in the future:

a) If someone has a question, they do not need to told that the question is impertinent.

b) If someone has a problem they do not need to be told that their problem is trivial, or somehow not part of a "mainstream marketing plan" to which only fanboys are privy.

This means that you need not comment on the overwhelming majority of my posts, as I would not bother the group at this point with more than questions that I encounter as I try to climb up the long and twisty "learning curve" on this device.

This will save us both much time, and save you some aggravation, as each and every time you respond with a pat on the head, I will make a special effort to respond and point out the specific errors in your reasoning.

In this case, you are making an assumption about something you cannot possibly know anything about - the market for devices like Hubitat. There are about 8 million 2nd homes in the USA... clearly, these are owned by people with the money to afford nice things, so they all likely want to monitor them when away, and various "alarm companies" are a liability, as they cost you steep fines if they call the authorities too often.

Overseas, such services are rare, and infrastructure is far less reliable than here in the USofA.
Infrastructure is also far less reliable in the more pastoral locations where one tends to want a 2nd home. So, a product that can be self-reliant is a good thing.

So, if a neighbor kid becomes an entrepreneur, and starts using my deck electric outlets to charge up 100 electric mopeds to rent to tourists, I'd like to be able to see that unusual power use, so as to rewind the security camera footage and see who it might be, grab some video, and send it along to his parents if I can recognize the young businessman,if not, to the local constabulary.

1 Like
35

Tl;dr but we’ll just agree to disagree.

Your tone often comes off as dismissive of the opinions and efforts of others.

Take care.

Edit: and yes for the record I have seen performances of the operetta candide :roll_eyes:, but seriously man even if you're trying to have a technical conversation with people, see if you can avoid insulting their intelligence or needlessly calling attention to the supposed superiority of yours, my guess is you'll find the discussion becomes even more fruitful as a result.

1 Like