Usefulness of "hail" for Leviton dimmers?

(Nicholas Wilkie) #1

I’m trying to flesh out my Leviton VRMX1 dimmer’s functionality, and I’ve noticed that ST doesn’t seem to use the “hail()” command. Just looking around for what that means, it seems that this is the instant update function that you get with Leviton dimmers. Has anybody used this feature or made a Leviton device type?

I only found this use of hailing in the Z-wave relay code:

def parse(String description) {
	def result = null
	def cmd = zwave.parse(description, [0x20: 1, 0x70: 1])
	if (cmd) {
		result = createEvent(zwaveEvent(cmd))
	if (result?.name == 'hail' && hubFirmwareLessThan("000.011.00602")) {
		result = [result, response(zwave.basicV1.basicGet())]
		log.debug "Was hailed: requesting state update"
	} else {
		log.debug "Parse returned ${result?.descriptionText}"
	return result

def zwaveEvent(physicalgraph.zwave.commands.hailv1.Hail cmd) {
	[name: "hail", value: "hail", descriptionText: "Switch button was pressed", displayed: false]

It seems like this would be a useful command to use, but it stops responding to the hail command after a certain hardcoded firmware version. Any insight into why this might be?

(Mike Maxwell) #2

Have a look at this.
It’s a device that I wrote specifically for the aeon micros, which support three physical reporting configurations, none, hail and basic report.
Hail works fine (though not as fast as the basic report), so don’t know why it’s commented out.
You should be able to implement hail for your Leviton.

(Nicholas Wilkie) #3

This is great, thanks! If basic report is faster, then I guess I’ll stick with that. But still cool to see your code, thanks for sharing!

(Mike Maxwell) #4

Yea, from what I could gather from my testing, hail just tells the hub to request a report from the device…
So if your device produces a report on physical state changes, that’s going to be the fastest update.
With the Aeon’s I get state changes in ST in under a second (as long as ST’s not clogged up)