Bug in Virtual XXX devices?

New to Hubitat so I may be misunderstanding and perhaps this is correct behaviour.

But in a driver (device handler) if I subscribe to say the "switch" attribute on a Virtual Device (Switch, Dimmer, etc), shouldn't my handler fire with every event even if they are the same?

So if I click "on" on the Virtual Switch my handler fires once .... if I click "on" again, it doesn't fire .... and so on. If I then click "off" on the Virtual Switch my handler fires again, but if I click "off" again it doesn't fire ....

The handler only seems to fire if the event changes, which doesn't seem right? It should be up to me to decide whether I want to do something with a duplicate event in the handler!

subscriptions by default only fire on a change of attribute value.

If you want all events regardless of state change, add filterEvents : false to the subscription such:
subscribe(dimmerDevices, "level", handleDeviceEvent, ["filterEvents": false])

I believe that is how it has always been in HE. Although the device logs the event every time, it only gets passed to the subscription if the event value has changed.
@mike.maxwell can confirm this...but in the meantime, can you explain why you would want to have it triggered every time even if there is no actual change in state?

That is correct, you can decide if you want only changed events or all events. The default is to only send events when the value has changed. This cuts down on unnecessary run of the App that subscribes to the event. However when you subscribe to a device, you can tell the system to not filter the events going to the App:

subscribe(device, "switch", "myHandler", [filterEvents: false])
3 Likes

Learn something new everday.

1 Like

@mike.maxwell, @chuck.schwer thanks guys, that helps explain things!

Just for clarity then, how does the "Virtual Button" differ as I do get an event every time for "pushed" even thought it's the same event? Or is that one like a momentary "true" state which then reverts to "false" immediately?

Also, I've not seen "filterEvents" before in ST, a search on the forums finds some really old references to it but nothing in the current docs, was it removed but you reinstated in HE?

@stephack in this particular case I am using a Virtual Switch for "lights on" functionality via the Alexa App (UK so no Skill for me currently). The problem is that if the lights are switched off elsewhere (manually or individually from the dashboard for example) then currently a second "lights on" won't fire the event.

It's also useful for example if you have say a temperature, humidity or such sensor which may report periodically but have the same data value but a new timestamp - so you want the event still in order to log the data point.

on the driver side you force it using: sendEvent(name:<>, value:<>, isStageChange:true)

I would not force attribute changes simply to get your data logging points, If I was doing a data logging app I wouldn't subscribe to any of the attributes, I would simply get the current values of the attributes in question at whatever interval I want, the current value will be the current value at the time you fetch it.
Doing an event based logging system for sensors, leaves you at the mercy of the sensors configured reporting intervals and thresholds, which you don't have much control over.

I think it depends on your application requirements, interval based logging is fine but it's not logging events from the device, just whatever the value is when you read it periodically.

To me a device sends an event (a temperature, humidity, status report, status change, etc) and it's that event that I want to react to whether it be the same (repeat) data or not.

In any case, filterEvents is working for me now :slight_smile: Seems like that was removed from ST for whatever reason, glad it's still in HE.