I have an attribute in a driver, uptime, that I want to keep updated without filling the Event log with updates. Is there a way of doing this? Setting displayed: false and/or archivable: false for each uptime event has no effect...
For now, I'm just putting uptime in state.uptime...
If it's an Event, then it gets handled as an event and will update the DB. Since the value changes every time, then yes, you'll fill the DB.
Your idea of making it a state variable if that works for you would seem more like what it is.. it's not really an event, it's a status.
Thank you! Then it is as I suspected. Is there anything except attributes from a driver which can be displayed and updated on a tile?
Also, is there any documentation anywhere describing what displayed: true/false and archivable: true/false does?
Displayed is not used in huibitat currently. So, don't bother including that setting. True and False will get you the same outcome. And I have not seen any documentation on Archiveable so I'm pretty sure that one doesn't do anything either.
Not that I can think of, but if this value updates frequently, have you considered making it update only after a certain threshold is reached? In some cases, this might be like "more than x percent different from previous value" or "changes by more than +/- y from previous value," but since it sounds like you're tracking uptime, perhaps a time-based criterion might be better (every minute or every few minutes or however long you can get away without updating it, maybe?).
If you don't need an attribute, then by all means don't use it (don't store things in the database that don't really need to be there). But if you do--and an attribute tile on a Dasbhoard would be one case--you don't have to worry too much as long as you're not doing anything excessive. This is vaguely worded because I don't think we have any formal guidelines on this besides not creating unnecessary events (e.g., if an app isn't likely to want to use the value). I would not do every second myself, but I'd probably feel comfortable with every minute or two. Your comfort level may vary.
Here's what we do know: the device event history DB gets automatically purged to the last 1000 items for each attribute (see: Device Log Housekeeping Procedure - #29 by mike.maxwell), so it won't keep growing forever. This happens as part of the nightly 2 AM maintenance. Logging an attribute every minute will slightly exceed this limit and require pruning every night (once a minute = 60 * 24 = 1440). Updating the attribute once every two minutes would require it only every other day (30 * 24 = 720). Either is probably fine, but it's never a bad idea to limit this (another option would be to update it only during certain times of the day; this might be difficult to do 100% from a driver, but perhaps you have a companion app already and could do that there, or create an option in the driver you can set/unset with a custom command that will start or stop updating this attribute--just some more ideas if you are worried).
Thank you for the very exhaustive answer, I'm very new here, so have not found and read everything yet. All this do give me a good idea of how to write and plan my drivers, so that is great! This with changing frequency based on a schedule could be fun to play with, but probably not very useful for me personally. I have a very changing schedule.
Here's hoping for a future way of displaying data from state in a tile. But I suspect that it will not happen.
I wouldn't expect that to happen either. I don't think there is really widespread need for that, so would be low on the priority list (assuming you submit an email/etc to Hubitat to get it on the development list in the first place - posting in here doesn't guaranteed it is an official feature request).
I find this very annoying as well. With the TP-Link driver, I get so many log messages that fill the log with polling status, power consumption etc. I simply want to see if the switch was turned on or off. Turning off event logging seems to turn everything off except if the device is not reachable.
All of Hubitat's built in drivers follow a pattern... there are two toggles in the Device Info page for Debug and Description:
Debug is intended to be that.. for debugging and it should log a lot of useful info for debugging. Hubitat's drivers automatically disable it after 30 mins.
Description logging is intended to be "everything is working" info... as you suggest, is it turning on and off?
I'd suggest working with the author of the Driver to adjust the driver if it's not closely aligned with the framework set by Hubitat.
With both toggles OFF, logs should be silent except for Errors.
Logging and event history are different. The driver will log whatever the driver author chose to log (this would show up in "Logs" as live logs, or in the same place with the "Past Logs" button for past logs). Often, authors will choose to log "info"/"description text" messages that log device attribute changes, like on/off or power consumption, and many will also have an additional option for more verbose "debug logging" (which may help you or the author if you're trying to pinpoint a problem). Convention is to let you disable one or both of these (and debug logging will, also by convention, disable itself after 30 minutes). Not all third-party authors follow these conventions. (EDIT: This is pretty much what was said above as I was typing.)
Event history (on the "Events" button/tab) is automatically generated by the platform any time a device attribute changes. This is determined by the driver, but the driver is probably just following the device. Some drivers have options for how frequently to report or what amount of change is needed to update the attribute (and in turn generate the event). Disabling info/description text logging does not stop the device from creating these events or the hub from committing this history to the database. If you believe your driver produces too many, you should modify the driver (or with with or suggest to the author that they do the same) to cut down on these events somehow, either with an option to totally disable reporting of this attribute (note that many capabilities will require certain attributes to still be present with some valid value) or some way to reduce its frequency of reporting.
I'm not sure which you're talking about. This thread originated talking about events, but it sounds like you may just be talking about live/past logs. Either can be modified if you're using a custom driver, though.
Having already gone off the original topic, how would the convention recommend to best implement the auto-disable of debug logging after 30 minutes in drivers? I just released my first drivers, but will make sure to implement this and that they are 100% silent when not requested to be otherwise.
When debug is enabled you could forward schedule a method to run in 30 minutes using
RunIn (30,turnOffDebug).
You could use schedule() alternatively which uses cron
here's some 'template' code to be splattered throughout your driver:
input name: "debugOutput", type: "bool", title: "<b>Enable debug logging?</b>", defaultValue: true input name: "descTextEnable", type: "bool", title: "<b>Enable descriptionText logging?</b>", defaultValue: true if (debugOutput) log.debug "Executing getStatus" if (descTextEnable) log.info "Deleting children" void initialize() { unschedule() if (debugOutput) runIn(1800,logsOff) // disable debug logs after 30 min /* logsOff Purpose: automatically disable debug logging after 30 mins. Note: scheduled in Initialize() */ void logsOff(){ log.warn "debug logging disabled..." device.updateSetting("debugOutput",[value:"false",type:"bool"]) // app.updateSetting("debugOutput",[value:"false",type:"bool"]) }
It's just a bunch of non-sequential code that I keep in a text file for inserting into drivers I find or write. It's got MY indents, and spellings.. but perhaps it gives an idea of the total function. Some is even 'hints' for myself.. specifically the initialize() portion.. that's to remind me "oh yea, the 30 min off goes AFTER the unschedule in Initialize." (because sometimes unschedule is NOT in initialize.)
Then disable power reporting for the plug, if you don't need it.
Thank you everyone, this is most informative and useful. Will adapt it to my projects. Does anyone know if the runIn function will keep a scheduled call and execute after a reboot? With the above implementation it will be rescheduled when starting the driver anyway, so probably doesn't matter in this particular case.
Yes.
runin does not survive a reboot. As you surmised, in this case it doesn't matter,
Uhmm....i beg to differ. Unless your Initialize method calls out "unschedule" then scheduled events absolutely survive a reboot. To confirm, I just did one.
After a reboot....scheduled event is still there.
It doesn't survive of the scheduled event occurs while the hub is rebooting, which is the context for this question to Chuck months ago...
He answered:
By default the scheduler will ignore any schedules that it failed to execute and will run the next one in the sequence. So for example if the time is 10 am and you scheduled runIn for 300 seconds, it will run at 10:05am however if the hub was rebooting at the time and did not come up until 10:06am, that job would be ignored.
There is also a misfire option for runIn() (and every other schedule method) that will allow the scheduled method to be run immediately if it was missed, But be aware if you miss more than one, it will run all of the missed schedules.
For that reason, I treat 'runin()' as not restarting.
But an event scheduled by RunIn absolutely survives a reboot. Right?
Download the Hubitat app
