Parse(): what is an "updated" message?

This may or may not be a silly question… but nearly every example of parse() that I’ve seen checks to see if description == "updated".

In most devices, if description == "updated", then it is simply ignored, and a zwave.parse() is only attempted if the description != "updated". However, I have seen some devices (e.g. battery devices that wake up) respond with some commands if an “updated” message is received. e.g.:

def parse(String description)
	def result = []

    if (description == "updated") {
			result << response(zwave.wakeUpV1.wakeUpIntervalSet(seconds: 60*60, nodeid:zwaveHubNodeId))
			result << response(zwave.manufacturerSpecificV2.manufacturerSpecificGet())

So I’m wondering, what is an “updated” message? what does it mean? is it some kind of ping from the device? is this a feature of some z-wave devices, or does it apply to all devices? what about zigbee devices too?

Can anyone enlighten me?

… I bet @duncan will know… :wink:

The “updated” message is sent to the device every time its settings are updated via the mobile app.

1 Like

Can you clarify this @geko? Surely, if an “updated” message is received by parse() then the message is being sent from the device to the hub, not the other way around?!?

Or are you saying that this message is related to when updated() is called (i.e. after a user edits the settings in the GUI)? If so, I still still don’t get why, as all necessary code would go in the updated() method anyway?

Also, with Z-Wave devices, settings would be updated by sending a ConfigurationSet command, and the device would respond with a ConfigurationReport command, so it’s still not clear to me what the purpose of an “updated” message would be?

Hmm, I will have to do some experiments to see when there messages are actually arriving…

Removed per OP request.

Sorry about that. Just seemed to be related, and it was your thread that sparked my curiosity.

That’s correct. I believe that updated() API was introduced fairly recently. The updated message is still there for backward compatibility. Perhaps @slagle can clarify.

1 Like

Thanks @geko, that certainly sounds plausible.

[UPDATE]: Well I just tried saving a device’s settings several times, and parse() is never called with a message description == ‘updated’. :confused: Perhaps this mechanism has been removed already?

You would think SmartThings would document this kind of stuff… :unamused:

The ST documentation, while significantly improved since 2014, still leaves a lot to be desired.

Agh you’ve figured out that I like to explain the quirks and history of our device platform. Just want to point out that my main work is on hub firmware so although I’ve interacted with this for many years, none of it is my fault :innocent:

tl;dr it’s vestigial

The “updated” event was originally automatically sent by the platform whenever a device record was updated in the database, to notify the mobile app that it needed to refresh the device’s info from the server. I’m not sure if it was intentional that it go through the handler’s parse method or not – at that point all events did.

After we started to get a bunch of exceptions about how the Z-Wave library couldn’t parse “command:upda payload:ted”, and had to add checks for it in parse methods, we decided to switch to a new hub event “DeviceUpdated” that would have more info about the device’s state attached and would go directly out without being passed through the handler.

I think the switch to watching for “DeviceUpdated” was around the same time as an iOS version compatibility drop, so people with the old iOS had to hold on to the older version of the app. The way ZigBee devices were added then was they would first come through as unknown “Thing” devices, then the platform would request their simple description and when that came back they were given a type. The app was listening for the “updated” event to know that the device had its device type assigned, so if we stopped sending it, people on the older version would see everything join as “Thing”.

So the “updated” event was left in, and we kept having to check for it in parse(). As I mentioned in a recent post, it wasn’t originally possible to send commands from the updated() method, so for a few devices we decided to use that “updated” event to send commands on install or device type change. That was a bad idea since the event was basically deprecated, so we added a way to send from updated() instead, but not all of the code checking for “updated” was removed and was copied and pasted all over the place.

We’ve finally stopped sending the “updated” events, though looking at the code it may still be possible to get one in certain situations. It would make more sense to remove mention of it from all DTH code rather than document it, but we’re still at a point where if something isn’t causing problems it’s not a high priority. We’ve been short on bandwidth for testing DTH changes for a long time, and some of these handlers are used for dozens of products, so making even seemingly simple changes can be dangerous.


Ok, so there’s little point checking if (description == "updated") in parse() anymore, right?

What about description.startsWith("Err")? I see this quite often too. Is it still possible to get these? if so, is there any documentation on what Error message might actually crop up?

Right, there’s no need to check for “updated”.

So far the only “Err” that goes to parse() is “Err 106” for secure inclusion failure. The rest show up as hub events.