Subscribe to non-change report?

I’m trying to subscribe to an event, but it only enters the subscription function if there is a state change Eg:

isStateChange: false
Does not get run

isStateChange: true
Gets run.

Is there a way to run through a function even though there is no state change?

subscribe(locks, "codeReport", codeReturn)

I changed the device type code to always set isStateChange: true, but this seems like a pretty bad hack to make this work. Seems like this should be pretty common use case. What am I missing here?

Yes… filtering.

For example:

This will call “switchHander” every single time the device type creates/sends an event setting it’s “switch” attribute (even if its redundant.)

Does that solve your issue?

Take care

1 Like

This looks promising but doesn’t seem to be working. Is there any documentation around this?

So you want to do something like this?

check every x minutes for the currentValue of a device?

It is really easy.

Just get the device(s) curent value using this code


If you allow a subscription to multiple locks then you will need to each your way through the locks object.

I want to be safe with timeouts, so asking the lock for a code, then if the lock doesn’t respond in 20 seconds, then my code fails.

I’d rather say, hay lock… tell me how those codes are doing sometime in the next two minutes…

Then say, oh thanks for the codes, now let’s make sure those are the right ones! (at whatever time the lock gets around to sending them)

I think I got it figured out how with a little bit of custom device code, which sends the code to the app as an event after a poll to the lock was requested. I’ve moved past requesting for single codes, since being able to get all codes at once with the poll method cuts down on chatter quite a bit.

@Jim, is the filteredEvents attribute no longer working/supported?

See the conversation here for more information:

1 Like

So should we be moving programming questions over to Stack Overflow? I can see the benefits, but, it isn’t a trivial amount of effort to look for support in yet another location…

1 Like

There’s an ongoing discussion about this here:

1 Like

It was a mini experiment on my end to see where I got an answer from. I do also agree with Andrew’s post in that the StackOverflow community seems to be the place for these kinds of questions; For ease of search and also ability to track answered/unanswered questions.

Thanks for replying to this thread. Both forum’s answers helped me to what I choose as my solution.

1 Like

@jim, that’s not an answer. That stackoverflow post doesn’t include any reference to the filterevents attribute. Is the filteredEvents attribute no longer working/supported? That USED to be a mechanism for pulling in events even if/when they weren’t a state change.

However, it no longer seems to work, and also breaks other smartApps (not just related to door locks.)

1 Like

This option is mostly moot now.

Originally if this option was true (the default) then only events that are state changes (i.e. the attribute value is different than the previous value) were returned. If it was false than all events were returned, so you might see multiple events with the same value.

However, we no longer broadcast events that are non-state change events, so this option doesn’t typically have any effect. The main exception is “switch” events from Z-Wave switches where isPhysical is true.

1 Like

I ended up having to create a new device type to handle the information I needed back so that I could ensure the correct values were set on the lock. It was only an extra 4 lines of code added to the default Z-Wave Lock Device Type.

I had originally not wanted to have to edit a device type, because I was hoping to submit my app to ST after I was done with it, but this extra 4 lines of codes in the device type brings my app up from barley working, to working 100% of the time.

My question also became moot when I wanted to extract the list of current values rather than any event that was readily sent by the original device type. The new event sends the object I need with every value, rather than cherry picking for all values.

Still good to know about the filteredEvents attribute. It seems like this still may be convenient for others to be able to use in order to verify that the state is what it should be according to the app, and not the all mighty SmartThings server.

IMHO what would be extremely helpful for apps is, during the poll() response, to create an event by default that apps can subscribe to.

This way it can be the norm to give all of the data of the deviceType inside of one pollEvent(?) that the app can then use to reconcile what the data is, and what it should be, based on more rules than the devicetype itself is aware of…