Device Event History Usage

[markus]

By now it is clear that Event History is pruned at 1000 events per event type once per day. But what do you use the event history for? I have found myself use the last few events for debugging and very little else. 1000 events I would not have a need for.
The above is true since I, like many others, send events to be stored and graphed outside of HE. With no graphing built-in, there is not much else to be done if graphs are wanted.
Sure, it would, in theory, be possible to write some JS code that used the history and presented a graph in the Dashboard, but this would be an expensive thing to do, especially if automatically refreshed and not updated using current device events, which could be leveraged, of course.

So, what do you use the event history for? Are there use cases for having 1000 events in there? Or have you never even looked at the device event history and only the current status is of interest to you?

EDIT: For me a device event history persisting more than the latest event between reboots is unneeded, any thoughts?

All of this is just an exercise for thought and I don't expect anything to change, just wondering how other people see this.

[mark.cockcroft]

only look when something is not as expected, 1000 seems excessive

[markus]

@mark.cockcroft

only look when something is not as expected

I do suspect this to be the case for most, but maybe someone has a surprising answer?

[mark.cockcroft]

but saying that on ST the new app had little temp graphs, and i did look at them quite (think they were only 24h) a lot in winter. was thinking about a rule to turn on heating when temperature drops.

[markus]

@mark.cockcroft

little temp graphs

This would be helpful for a lot of things, not just temp, but as part of seeing patterns in values to be used as trigger points in rules as well. For this there's the "outside of HE" options, but that feels incomplete and unnecessarily complex...

EDIT: Out of likes, but will come back with them later

[mark.cockcroft]

likes limit! ill have to take that back!

[markus]

Yes, we have to ration them, at least we know the limits now:

Like, Shortage

The limit is per day so I assume when you get the notice it is the amount of time until your likes reset. Trust level "basic user": 50 Trust level "member": 75 Trust level "regular": 100 Trust level "leader": 150

[mark.cockcroft]

its ok im not that nice i need to give out more than 50 a day!!
unless i can like my own.
Anyway back on topic...

[markus]

[gavincampbell]

@markus

So, what do you use the event history for? Are there use cases for having 1000 events in there? Or have you never even looked at the device event history and only the current status is of interest to you?

I rarely look at my events but for people that like to babysit power usage having a lot of events available is very good.

I rewrote a few drivers for some devices recently that report power usage. It is scary how chatty they are. They are sending an event almost ever second as power is being used. Multiply this by multiple devices and this could be a problem as I could see it flooding the mesh. I went and started disabling all the power reports because I don't need them.

With that many reports, the event logs will fill up fast.

[markus]

@gavincampbell

I rarely look at my events but for people that like to babysit power usage having a lot of events available is very good.

Sure, but without visualization, they are very hard to use... At the moment that is only possible off-system, except with some custom app or custom JS in a Dashboard.

@gavincampbell

With that many reports, the event logs will fill up fast.

Most definitely, it is easy to get to more than 1000 per day per event type if one is not careful. And with many different event types... PM really is a prime example of this. In some drivers I've written the default is to update PM readings once every 5 minutes, but it can be set down to once every 10 seconds or up to once an hour... Or it can be based on a minimum change in %... Even with this, there's a lot of data which is probably never going to be used. For many, the current value and the previous value are all that is needed. More than that and an external system is basically required, at the moment at least.

[gavincampbell]

@markus

In some drivers I've written the default is to update PM readings once every 5 minutes, but it can be set down to once every 10 seconds or up to once an hour... Or it can be based on a minimum change in %.

I wonder how many people actually look at these settings and tweak them to minimize the reports.

My first shock was with the zooz powerstrip. I have it setup so that when my tool batteries are done charging it will notify me and cut the power. But while they are charging the report events were crazy.

[markus]

@gavincampbell

I wonder how many people actually look at these settings and tweak them to minimize the reports.

I know, but if I'd set the default to more than 5 minutes, people would start thinking something is wrong since values are not updating. I'd love to be able to update the current value without creating a new event in the event log.

[gavincampbell]

@markus

I'd love to be able to update the current value without creating a new event in the event log.

I think it may be possible, but at the driver level. If you modify the sendevent command for power reporting and use the property "displayed:false" I have a feeling it doesn't log it to the event log but will still update the attributes. I had to reference the ST documentation but it looks like that is the use. I could be wrong though.

[markus]

@gavincampbell

I have a feeling it doesn't log it to the event log but will still update the attributes.

Unfortunately that setting as no effect in HE, this is confirmed by @mike.maxwell if I don't remember incorrectly.

[mike.maxwell]

@gavincampbell

displayed:false

This setting actually hid the event from some display methods, it did not prevent the method from committing to the database.
This has no effect in Hubitat.

[mark.cockcroft]

ive just used the history! it was no help....
notice my thermostat was set to 21deg when it should have been off as everyone was away.
only rules i have is off when away and 17 when the boiler turns on. but 30 after everyone leaving there is an event setpoint change to 21, but no why....

[markus]

@mark.cockcroft

but 30 after everyone leaving there is an event setpoint change to 21, but no why....

It is up to the driver to include a descriptionText explaining the event. My drivers don't have anything useful in that part either, I think most drivers don't. Maybe they should...
And the normal logs will be long gone. Unless you send them out of HE somehow?

[mark.cockcroft]

unless im doing it wrong my driver does, it might show in the event log but not the history

def zwaveEvent(hubitat.zwave.commands.thermostatsetpointv2.ThermostatSetpointReport cmd) {
    if (logEnable) log.debug "ThermostatSetpointReport ${cmd}"
	state.scale = cmd.scale	// So we can respond with same format later, see setHeatingSetpoint()
	state.precision = cmd.precision

	def eventList = []
	def cmdScale = cmd.scale == 1 ? "F" : "C"
	def radiatorTemperature = Double.parseDouble(convertTemperatureIfNeeded(cmd.scaledValue, cmdScale, cmd.precision)).round(1) //reported setpoint
	//def currentTemperature = currentDouble("heatingSetpoint")	//current app setpoint
	//def nextTemperature = currentDouble("nextHeatingSetpoint")	// app next setpoint
	def currentTemperature = device.currentValue("heatingSetpoint").doubleValue()	//current app setpoint
	def nextTemperature = device.currentValue("nextHeatingSetpoint").doubleValue()
    if (logEnable) log.debug "${device.displayName} - setpoint report temps device rep = $radiatorTemperature , next = $nextTemperature"
    def discText = ""
        
	if(radiatorTemperature != currentTemperature){
        if(state.lastSentTemperature == radiatorTemperature) {
			discText = "Temperature changed by app to ${radiatorTemperature}°" + getTemperatureScale() + "."
        	log.info "${device.displayName} - ThermostatSetpointReport - '${discText}'"
        }
		else {
        	discText = "Temperature changed manually to ${radiatorTemperature}°" + getTemperatureScale() + "."
			log.info "${device.displayName} - ThermostatSetpointReport -'${discText}'"
			state.lastSentTemperature = radiatorTemperature
            eventList << createEvent(name:"nextHeatingSetpoint", value: state.lastSentTemperature, unit: getTemperatureScale())
		}
	}
    if (state.productId == "4") { //if device (4) dosent report temp
        eventList << createEvent(name: "temperature", value: radiatorTemperature, , descriptionText: "fake temp" )
        //log.debug "${device.displayName} device type 4 dosent report - temp fake temp"
    }
    if(radiatorTemperature > (quickOffTemperature ?: fromCelsiusToLocal(4))) { //if on
        if (logEnable) log.debug "on heat"
        eventList << createEvent(name: "lastRunningMode",value: "heat")
        eventList << createEvent(name: "thermostatMode", value: "heat" )
        updateDataValue("lastRunningMode", "heat")
    }
    else { // off
        if (logEnable) log.debug "off cool idle"
        eventList << createEvent(name: "thermostatMode", value: "off" )
        eventList << createEvent(name: "thermostatOperatingState", value: "idle")
        updateDataValue("lastRunningMode", "cool")
    }
    eventList << createEvent(name: "heatingSetpoint", value: radiatorTemperature, unit: getTemperatureScale(), descriptionText:discText)
	eventList << createEvent(name: "thermostatSetpoint", value: radiatorTemperature, unit: getTemperatureScale(), descriptionText:discText)
    
	return eventList

[markus]

@mark.cockcroft

createEvent(name:"nextHeatingSetpoint", value: state.lastSentTemperature, unit: getTemperatureScale()) }

This createEvent call doesn't add a descriptionText to the event. There are some more as well, but some of the calls do add a descriptionText. At least you can trace it down to which calls it can be and which it can't.

The device event log is the event log in the device, the "normal" log is the one where log messages go. I might be using the wrong terminology here, but we talk about the same things.