Trigger an attribute write in a custom device type

I think it should be too, but it doesn’t work and the quote I posted is from ST. Testing that I believe @rpress did showed that the same is true for the updated() method. I can only attest to Zigbee commands because that’s what I’ve worked with, but they simply don’t fire.

It might be a way to prevent loops within a devicetype.

(One exception seems to be for the Enroll Response for Zigbee sensors, which is triggered by a request from the device.)

OK. Well… this is definitely worth me confirming with a test device and some log.debug, etc., commands to confirm.

Indeed, it is certainly understandable that this would be the behavior, even if frustrating … while inside parse(), the communication layer is in “receive” mode (or something), and thus “sending” is prohibited or impossible. Though that could vary by RF protocol.

If this is the case, then I, personally, would first want to understand the bigger “problem we’re trying to solve” before trying to hack around the restriction.

In other words, trying to hack the restriction by using sendEvent() or some other clever coding, could be a waste of time, when we really ought to be putting some eyes on the actual end-result requirements first.

I don’t think anyone is trying to hack around a restriction per se or use particularly clever coding. There are use cases where information from a device is useful to trigger an action on the same device as John layed out with his reboot scenario. To do so he needs a SmartApp just like he would if the action he wanted to take involved a different device.

I just don’t think people realize this aspect of the ST design. It makes perfect sense that you use SmartApps to bridge information from one device to action on another. A device handler is limited in scope to itself, so “triggering” another device requires a SmartApp.

It’s less intuitive that a SmartApp is required when the information and action involve the same device. That is a device effectively can’t “trigger” itself. Again, it makes sense from an overall platform design standpoint, but it’s not intuitive and definitely frustrating from a coding perspective.

ETA: Sorry @JohnR for the thread hijack.

1 Like

I think we’re on Topic :smile:

But I agree that it is “less intuitive”. A Device should be able to do anything with itself … it is in its own scope. A device is just an object. An object instance always has access to all of its methods, public and private.

1 Like

I think you might try your idea about using an app to set it. One thing that would force you to do is to add a command to the device type, setColor(color). If you can trigger the app to run, then it could set the device to the proper state. This is not unlike the Power Outage app, that allows you to turn things on or off after a power outage.

1 Like

Dang it you guys on the west coast having this conversation with out me arrrggg.

So I think @Sticks18 is dead on with everything. I can call the on() method from the parse method as @tgauchat pointed out and it seems to run from the sense it makes an entry in the log but the write attribute command does not get sent.

It all makes sense now. I don’t like it, and I think my only option is a SmartApp that will respond to the “Just Booted” event. That’s not a big deal but not as clean as having it all in the custom device type.

You know the proper way to do this is to catch the device’s ZDO device announce packet. I know SmartThings grabs that packet and responds to it. Every time a device boots and sends a device announce the hub responds with two ZDO commands, one requesting report of suppoted end points and the second a simple description of each. What would be very helpful is if they would pass that device announce to the parse method and allow us to respond to it. I know its a ZigBee device object command not a cluster command but I cant see it being a big deal to catch and pass through.

1 Like

@bravenel Bruce, I completely agree! Thanks very much for all the time you spent with me on this!! It helped a great deal!!

1 Like

Yeah I agree about Device Announce, hopefully if enough of us want this feature it will be implemented. I also lament that we can’t send ZigBee commands in updated() or parse().

3 Likes

This is a really important and tricky scenario. I am trying to do this too -
There are many reasons one would try, that discussion is a fun academic one -
The HOW discussion is an important practical coding one!
I want one Device to connect with in my App and with logic. A Door. I should not have to use two devices.
physicalgraph, right?
This can have an Attribute State of Opened or Closed.
Commands to Open or Close; and
Actions of Open or Close – Names can be tweaked if needed.
It requires an App Controller to mediate from the Lock/Opener, Contact to the Virtual Device.
I can effect the Action from the Virtual Device, creating an Event that the App forwards to teh Lock/Opener.
I have not experimented enough to get the State from the Contact thru the App into the Virtual Device.
That State Change via Event is intricate and causes ping-ponging when done wrong.
Here is my picture and my code.



Let me know if you do or do not have visibility - my first Git file.

(Imagine the errors I got before I learned about Actuator!)

I’m not sure I understand… Is your code working?

Do you want conceptual suggestions / discussion or alternative code?

My code does not yet work flawlessly, nor steadily. I feel it is close, but we know how long that takes…
I can sometimes see the change (Opened/Closed) but still get ping-ponging Event/Actions.
Other changes and it stops seeing the changed State.
Any and all help is appreciated -

George, I don’t think we are talking about the same thing. This thread is about a ZigBee device triggering an update to itself all within the same custom device type.

I think your on to a much more complex set of questions. You may get better results if you re-post your questions under a new topic.

1 Like

I see your point. I read the title and jumped in w/both feet.
And, confused Custom Handler with Virtual Handler!
I will start a thread. Thank you.

2 Likes

I’d love to help or at least follow along… Open a new Topic and tag me there (@tgauchat) and/or Private Message.

Same here George sounds like a fun project!!

Can’t test this out right now, but can’t you do something similar to what is done for enrollResponse():

//------IAS Zone Enroll request------// else if (description?.startsWith('enroll request')) { List cmds = enrollResponse() log.debug "enroll response: ${cmds}" results = cmds?.collect { new physicalgraph.device.HubAction(it) } }
It looks as though parse accepts Zigbee commands that have been wrapped in a physicalgraph.device.HubAction object.

4 Likes

@mitchp do you have a link to the device type that is using this wrapper. I would like to see if I could duplicate what it is doing.

Thanks!

Sure, the SmartSense Open/Closed uses it. https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/smartsense-open-closed-sensor.src/smartsense-open-closed-sensor.groovy

I’m using it in my CentraLite Keypad DTH as well and I’m able to execute arbitrary ZigBee commands from parse.

1 Like

@mitchp Thanks that did the trick!

Now my device (button with a LED ring inside) boots up sends a custom command to my device type. My device type interprets that command and sets the button’s on / off state, brightness level, and current color!

Here is the device type from Github:

1 Like