I have a device sending updates every 3 seconds. I do not need the event logs for it, and I think that this is making my hub somewhat slow. I could increase the interval, but I need reaction to the data coming back to be pretty instantaneous.
Is there a way to disable event logs for this device? I really would only need them if I am debugging an issue.
What device is this? Is this a stock driver or custom code? And do you mean logging events (or really anything) to the live (and past) logs, or do you mean placing an event in the "Events" tab of the device?
Custom code can be modified. Most stock drivers have an option to enable or disable description and debug logging. But another consideration is what type of traffic the device is actually sending to the hub. More information will help.
It's a Hubduino sensor that measures SPL. It's to shut off the TV when the kids and their friends are too loud playing video games (I work from home and am on phone calls pretty much all day). I could ramp it down, but it won't change their behavior unless there is an immediate response so they know what caused it to shut down. For example, if I move the polling to 30 seconds, they will have totally forgotten what they did in order to trigger the TV shutoff. The aren't going to remember when they yelled "No!" or smacked the coffee table because they were frustrated.
This thing is working great BTW. I just had the quietest week ever. I went from telling them 5+ times a day to keep it down, to zero.
I just don't have a need to keep all of the events for this. When I click on the events tab, it takes over 1 minute to load. They get deleted every night at 2am, but there's a lot of them in there now. It's 6:30pm, and I have nearly 22,000 entries in the event log. I just want to shut it off for this one device. My voice alerts and rules keep getting more and more delayed as the day goes on and that log starts filling up.
I didn't see any option in Rule Machine to delete event logs. If that was there, I could run something every few minutes to prune the logs.
You can cut down the number of events in half very easily. Just comment out the following line of code in the Child Sound Pressure Level Driver.
sendEvent(name: "lastUpdated", value: nowDay + " at " + nowTime, displayed: false)
Becomes
//sendEvent(name: "lastUpdated", value: nowDay + " at " + nowTime, displayed: false)
That’s a 50% reduction immediately.
I'll do that. However, it seems that these don't go into the event log, they just update the one field in the driver for last updated. As the number of events grows in the database, that seems to be when it gets slower and slower.
Also, when I finally get around to writing my driver for my litetouch system, it's going to poll every 2 seconds, adding additional load. This is because the litetouch doesn't send unsolicited update messages when someone changes a load via a keypad. The only way to keep the HE updated is to continually run through the loads and query the status of them. I have to limit it to one every 2 seconds because if I do them too fast, the responses come back over the serial port out of order. At 2 second intervals, this is up to 96 seconds for the HE to update when someone makes a change with a keypad (since there are 48 loads). My old Vera was able to handle this just fine with no slowness. The logging on that thing was VERY verbose as well, like 100 lines per second. Definitely not going back to it though. 
Maybe I already worked with you to eliminate the lastUpdated attribute updates.
You really should not be collecting data at this high of a frequency. The architecture just isn’t designed for for this.
Slow things down. Polling faster than about every 60 seconds is not advised, IMHO. There are better designs that are event based and thus only send updates when something has changed significantly. I think you’d be much happier with a design like that.
As for your litetouch system, if you can collect data from it via serial communications, why not use an ESP8266 to interface with it? It could poll away and then only send updates to Hubitat when something has changed?
Do you actually need the SPL data? Why not change it to a field that is something like "tooLoud" and it can be true or false.. I imagine you would only get 2 or 3 events per day that way?
This is an interesting idea. Better yet, I could install Openluup on a pi zero w, and reuse my existing code. I have a whole stack of them.
I actually have a newer controller (a 5000LC) that supports unsolicited updates, but I need to program it and I have been having issues with the programming software. And, the protocol is totally different.
@ogiewon, is there a limit to how many switch and relay devices I can have on a single arduino node? And, would Hubduino work for this? These are not physical devices to the arduino, they are devices that I would be controlling over serial. So maybe the dimmer and relay devices you have would not even work for this application.
I don't need the SPL data. However, the trigger is on the HE, not the Hubduino. So I still need to stream that data to the HE.
Such a simple idea Chuck! Not sure why I didn’t think of it.
Just modify parse to only update the contact sensor portion of that child spl driver.
Comment out the following line of code:
sendEvent(name: name, value: value, unit: "dBA")
Only the contact sensor attribute will be updated.
@ogiewon, I thought the contact sensor was being done within the driver on the HE side, NOT in the arduino.
Commenting that out would cause the contact to not have the data it needed to operate.
Edit: Starting on line 58 of the driver is where the comparison is for the contact. Nevermind, I was wrong. The contact comparison still works with this line commented out. I just tested it. Nice!
I poll my UPS every 10 seconds and spent a lot of time reducing events by storing certain data in state variables versus creating events. Then under certain conditions I will create events if say the power does switch from mains to battery. While the UPS is on mains power source I suppress an attribute called batteryRuntime which fluctuates constantly based on power consumption to “mains” but then it changes to a number when power source becomes battery. Thought I would share in case this helps in your design. Code can be found here:
https://raw.githubusercontent.com/HubitatCommunity/NUT-UPS-Monitor/master/nut_ups_driver
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
Download the Hubitat app
