Help with parse method

🛎️ Get Help
1

I'm learning by analyzing a simple dimmer device handler. The groovy is just starting to sink in. However when I try to reconcile the live logs with the code I have an unexpected situation.

Specifically: see attached also see UPDATE Below.

From the device GUI page I press "ON" (and the light goes on and to the correct dim level);
however I am confused about the debug results:

I have (zw:device:0E, command:2603, payload;23)) going into zwave.parse( zw.....23)

The result is (SwitchMultilevelReport(value:30). I would have thought it would be "SwitchMultilevelSet(value:30).

It works but what am I missing?

Thanks
John

capture_002_26062018_202634
capture_002_26062018_202634.jpg958×462 80.9 KB

Update,

This DH has methods for ON, OFF, set level and refresh. However I don't see how they are called. Perhaps my basic assumption is incorrect. I'm assuming any post installation entry goes into the parse method which interprets it and determine what other methods need to be called. Am I wrong here?

John

2

Just taking a glance here, but isn't Parse for received? Wouldn't SwitchMultilevelSet(x) be what's Sent? while SwitchMultilevelReport(value:30) is what comes back, the ACK if you will.

1 Like
3

I don't know what you mean by this.

In any event, have a look at the on method in the driver, this will contain at least one command basic set or multi level set. It may also contain a multilevel get. Set sends the value to the device, get requests a report.

4

Perhaps I was being too verbose.

The debug lines shown were captured as a result of pressing "ON" from the device page.

The crux of my confusion is the lack of "MultilevelSet(value:30)" in any of the parse method log.debug captured lines (from the live log)

There is a ON method elsewhere in the driver that contains a basicV1.basicSet and switchMultilevelGet.

So I guess what I'm asking is how the parse method runs the ON method. I was expecting one of the log.debug lines in the parse method to give me a hint.

John

5

Parse doesn't run the on method.

6

When an "App" (like Rule Machine, Simple Lighting, Alexa, etc...) or the Device Detailed web page calls the 'on()' command, it does so directly. That is when the code within 'on()' is executed.

If a result of executing that code causes the device (zigbee, z-wave, LAN, etc...) to send a response back to the hub, that data will be handled by the 'parse()' routine.

Since you changed the state of a z-wave switch device, the z-wave switch device responded with a 'Report' response.

The parse() routine only handles replies.

7

@ogiewon

Thanks again for your kind response. You supplied an important (to me) bit of information.

So if I were to draw a flow diagram, any command initiated from withing the HE box (executive, app etc) will go directly to the appropriate method in the driver.

And anything initiated from a device will go to the parse routine.

Can you tell me where a virtual switch command will be processed? i.e. is this an app or device?

You have no idea how much this clears up my understanding of the commands flow. You saved me many strands of hair!

Regards
John

8

@JohnRob

Ok, so one more piece of information that will help you...

Inside a device driver, will will see createEvent (used inside parse() routine) and sendEvent() function calls. Whenever either of these is called, an 'Event' is created that allows other Apps to be woken up. If an App 'subscribes' to a particular device's particular events, that app will be made aware of that event and the specific routine within the App will be called.

So, in a perfect world... An App (let's use Rule Machine) decides that it is Sunset and needs to Turn On a Light. It does so by calling that particular device's 'on()' command. (Note: at this point, the device's 'switch' attribute is still 'off'.)

Inside that device's 'on()' command, the appropriate z-wave command is issued, thereby causing the z-wave radio to emit a signal to the real physical device.

The physical device receives the z-wave command to turn on the switch, it turns on a relay, and then sends a z-wave report back to the Hub. This message states that the 'switch' is now 'on'.

The Hub looks at the DeviceNetworkID of the z-wave packet it just received, and finds a corresponding device. Once it finds it, it passes the z-wave data to the parse() routine of that device.

The device's parse() routine picks apart the z-wave packet and determines that the switch is 'on'. It therefore performs a createEvent( name: switch, value: on) call. Doing so causes the device's internal 'switch' attribute to be changed from 'off' to 'on'.

Any Apps that are subscribed to this device's 'switch' attribute events, are then notified and have an internal function called with the data that the 'switch' is now 'on'. The App then takes any action that is appropriate.

Hopefully this helps.

As for Virtual Switches, they simply have a 'switch' attribute, and implement the 'on()' and 'off()' commands. When these commands run, they simply call 'sendEvent( name: switch, value: on)' or 'sendEvent( name: switch, value: off)' . Virtual devices typically do not have a parse() routine as there is no physical device to send them data.

Dan

5 Likes
9

I wish someone had laid this out as well as @ogiewon did here when I worked on customizing my first driver. Took me weeks of trial and error and many strands of hair to learn everything he just explained in one post.

1 Like
10

A switch would implement on and off like any other switch but since virtual devices do not have a parse method, the on method simpley does sendEvent(name:"switch",value:"on")

11

@mike.maxwell

Thanks Mike. I would rather not bother you guys but not coming from ST (I was VeraPlus) I have a lot to learn and you and the rest of the staff have been great!

John

12

@stephack,

Once I get a better handle on this I plan on writing a short Primer for those who follow in my (our) path.

John

1 Like