Notification Value

[Tyler Clemens]

I may be missing something but I want to subscribe to Grizzly notifications so that when a node's state changes I can act on it.

I'm subscribing via:

Grizzly.subscribe(:node_updated)

I get these messages when I turn on the node (via hitting the physical switch):

{:unsolicited_message, %{command_class: :hail, node_id: 27, value: ""}}
{:unsolicited_message, %{command_class: :hail, node_id: 27, value: ""}}

I also get the same above messages when I turn off the switch.

I'm using a Leviton DZ15S-1BZ Decora Smart Switch

I would expect the value to be on or off.

[Matt Ludwigs]

From looking at https://products.z-wavealliance.org/products/1957/classes

This device seems to only support the HAIL command class, which is obsoleted. Which, really just means new devices should not use this command class. Meaning this particular device is older.

For these devices, you will need to get the node id form the message and send a command to get whatever the state is you're interested in after getting a :hail command. From this, we can see why they have updated their protocol to move away from this command.

In regards to the empty string :value field I assume that we are pattern matching somewhere that does something like: <<command_class_byte, command_byte, rest::binary>> and we through the rest variable into the :value field.

I think the consistency is nice, that is all message will have this field, but an empty string is confusing. I am open to suggestions but it would seem better, if we wanted to keep the :value field, to put nil into that if the value was empty.

There are 3 different lower-level Z-Wave command classes by which we can get messages from the Z-Wave network, so we tried to bring some consistency to it all. These command classes are hail, alarm, and notification.

[Tyler Clemens]

From looking at https://products.z-wavealliance.org/products/1957/classes

This device seems to only support the HAIL command class, which is obsoleted. Which, really just means new devices should not use this command class. Meaning this particular device is older.

For these devices, you will need to get the node id form the message and send a command to get whatever the state is you're interested in after getting a :hail command. From this, we can see why they have updated their protocol to move away from this command.

Sounds good! I ended up doing this and it works well. Here's my example pattern match I used for anyone else that is diving into Grizzly Notifications:

def handle_info({:unsolicited_message, %{command_class: :hail, node_id: 27}}, state) do
  # the switch doesn't report value changes so we have to go get the state
  case Grizzly.send_command(27, Grizzly.CommandClass.SwitchBinary.Get) do
    {:ok, :off} ->
      Logger.info("backyard light switch turned off")

    {:ok, :on} ->
      Logger.info("backyard light switch turned on")

    _ ->
      Logger.info("UNKNOWN backyard light switch status")
  end

  {:noreply, state}
end

In regards to the empty string :value field I assume that we are pattern matching somewhere that does something like: <<command_class_byte, command_byte, rest::binary>> and we through the rest variable into the :value field.

I think the consistency is nice, that is all message will have this field, but an empty string is confusing. I am open to suggestions but it would seem better, if we wanted to keep the :value field, to put nil into that if the value was empty.

There are 3 different lower-level Z-Wave command classes by which we can get messages from the Z-Wave network, so we tried to bring some consistency to it all. These command classes are hail, alarm, and notification.

I'm of the opinion that the less manipulation that Grizzly does with values and the closer to the raw values that the device is sending is probably the best bet. I think each case would have to be considered but in general that's probably a good rule of thumb. I think the less changes the easier it might be to debug problems. Just my $0.02 though!

Thanks @mattludwigs, this solves my problem and gives me a work around for this particular device.