Any way to clear attributes or the entire event log?

Have a device with capabilities that enable certain attributes. Some of them are not used by the device but they accidentally got set to something. Now they are stuck there and annoying me. Any way to clear them out with the interface or in driver code? Tried setting them to null and "" but does not seem to make them go away. Not sure if wiping the event history would clear them out but I cant figure out how to totally wipe that out either.

Change that device to use the Device Driver. It has the option to clear states and schedules. Then swap the driver back.

After clicking Delete all States:

I don't think that will delete attributes ("Current States"), though, right? However, in my experience, these disappear on their own if the driver doesn't declare them, either as a custom attribute or implied as part of a capability. "Device" certainly doesn't do either, so my guess is they won't show up...but what I've never tested is if they re-appear if/when you switch back to a driver that does have them. :slight_smile:

Attributes are not deleted, correct. If they are declared but empty they will not appear in the Current States column. If they are not empty, even if not used, they will remain in the Current States column forever... or until you delete/recreate the device.

It's something a lot of us have to deal with... a really good 'modern' example is @thebearmay 's HubInfo driver. Prior to 2.2.8 the Hub offered JVM info and in 2.2.8 they were removed. Thus his driver code has to deal with both. The Attributes are declared and are therefore created in the DB...

attribute "jvmTotal", "number"
attribute "jvmFree", "number"
attribute "jvmFreePct", "number"

...but in v2.28 they never get filled. If you're a 2.2.7 user that upgrades to v2.2.8, those remain displayed in the Current States column with values from a day/week/month ago. They can be zeroed:

Screen Shot 2021-07-21 at 12.22.26 PM

but they don't get deleted except by recreating it... which for that particular driver has no downside. :smiley: (You lose history, but the whole point of the driver is for up to the minute info.)

Screen Shot 2021-07-21 at 12.27.37 PM

2 Likes

This is what I suspected, not possible to delete. Very annoying :frowning: .

If there was a purge event log button I think that would do the trick. I think it is just grabbing the most current event.

1 Like

As I understand it, "Current States" (state history) are where attribute values go first when they are passed to the event subsystem i.e. using sendEvent() or returning an event object from parse().

Then "Events" (event history) are where attribute values end up if the event subsystem determines that it's an event. This is a change in value normally, but sometimes not e.g. in the case of a button value or battery value. Or if the event has been raised with a flag to say to always log it as an event, or if there's an App with subscriptions to ALL events.

So you could have State History of the "switch" attribute with a quantity of 10 being "on", "on", "on" .... etc. But the corresponding Events with a quantity of 1 being "on" (because the value hasn't changed).

You can set limits on both state history and event history from 1-2000 either on the device page, or using a couple of direct urls to set them globally as you probably know:

/hub/advanced/event/limit/COUNT
/hub/advanced/deviceStateHistorySize/COUNT

But there's a new "age" url in recent builds:

/hub/advanced/maxDeviceStateAgeDays/DAYS
/hub/advanced/maxEventAgeDays/DAYS

I think these default to 365 days and have a minimum of 7 days allowed.

I'm not sure if that means "delete anything older than X days" or "keep 7 days maximum even if they are 4 years old".

If it's the formaer then if you were to set to 7 days on the device, the next database cleanup might prune away any older state history (assuming the attributes you need removing were last updated more than 7 days ago).

Might be worth a try?

In any case, this does seem like a useful addition to be able to do from a driver / app, perhaps with a "clearState(String attributeName)" method.

@gopher.ny is that something you'd consider adding?

1 Like

Yeah, there will be a device.deleteCurrentState('nameHere') in the next build. That will delete current value and history - see code sample below. Kinda surpirised there wasn't a way to do it, actually.

metadata {
    definition (name: "deleteCurrentState demo", namespace: "hubitat", author: "gopher.ny") {
        capability "Switch"
        
        attribute "turned", "string"
        attribute "persist", "string"
	}
}

void on() {
    sendEvent(name: 'turned', value: 'on', isStateChange: true)
    sendEvent(name: 'persist', value: 'yes', isStateChange: true)
}

void off() {
    device.deleteCurrentState('turned')
}
8 Likes

You might consider also putting this in the β€œDevice” type driver.

1 Like

Awesome, thanks. Its the little things that really bother me.

A similar issue exist with the device data information. I.e., the info here:

If you switch drivers, sometimes the "original" driver leaves behind a number of data items. It would be nice if there was a device.resetDataValuesToDefaults() which would clear all but the "hubitat defined" data values (and would re-create any that are missing -- I once deleted one by mistake and it was a bit difficult to re-create). Maybe a 2.2.9 or later feature.

Also, I just noticed there is an "unistalled" method here: Device Code - Hubitat Documentation

Was that newly added? I believe there was one for apps, but don't recall it ever being there for drivers.

Thanks!

No, it's been around for years.

I am seeing it delete value but not history. I'm on 2.2.8.143. The history I am referring to is on the Events page linked from the device configuration page. Possible that I misunderstood how it was supposed to affect history?

Those are events, a separate data structure. They will age out.

Ran across this while searching if I could do anything about what looks to be stuck events for one of my Zooz power plugs (besides exclude and include as a new device).

The events only are storing new data for the last 50 entries. Everything older (of the approx. 200 in that device's event page) are from before I chose to only track power, and stop tracking energy, voltage, and high/low values. It's almost like it's reserving those other ones because they are the different type, and it doesn't want to "lose" them. Maybe it's somehow setup that way in the driver? I am less concerned with finding out why than I am with just reclaiming that amount of history.

This is on a freezer in my garage, and I'm trying to troubleshoot if I can use the power output to tell if someone left it open with food thawing. I had hoped it would work like some of the washer/dryer uses I read about on here, but it's trickier than expected because the compressor kicking in on it's regular cycle creates high power peaks that aren't indicative of it being left open. I need more event history (or logs, I guess - the events are easier to drop in excel because they're already tabular format), to try to identify some other pattern in the power consumption when it's left open (3 kids, so it happens more than one might expect).

screenshots



Should I just exclude/include as a new device?

What are your settings at? It is supposed to be a limit PER event type and attribute, so those old records should not be causing less of the other types to save less information.
You could also try setting both of those to 10, and wait overnight for the cleanup which should kill a lot of that old stuff. There is also an endpoint command to force a cleanup cycle. Going to see if I can find those links.

image

UPDATE:
Here is info about the number of days old events are kept. You could set this low enough to purge those, run a cleanup and then set it back if you want.

The database cleanup link is
your.hub.ip/hub/cleanupDatabase

2 Likes

I forgot about that setting - I had been looking at it about a year ago related to the alerts that would show up on the home screen periodically. Thanks for the reminder!

Edit: Now I see that one of the more recent system updates even added the setting about how many events would result in an alert per device. I'll have to look into that too.