v0.8.0!

Adds support for handling SmartStart meta extension fields.

These fields give more information about the current status, inclusion methods,
and product information for the SmartStart device.

There are two breaking changes:

1. All SmartStart meta extensions were moved from Grizzly.CommandClass.NodeProvisioning
   namespace into the Grizzly.SmartStart.MetaExtension namespace.
2. Upon finalizing the meta extension behaviour and API we made changes to how
   previously supported meta extensions worked. Namely, we added a new/1
   callback that does parameter validation, and returns {:ok, MetaExtension.t()}.
   This breaks the previous behaviour of to_binary/1 functions in previously
   implemented meta extensions.

• Enhancements
  • Full support for SmartStart meta extensions
  • Add meta_extensions field to Grizzly.CommandClass.NodeProvisioning
    commands that can handle meta extensions
  • Update Grizzly.Conn.Server.Config docs
• Fixes
  • Invalid keep alive (heart beat) interval
  • Set correct constraints on Time command offset values

Thank you to those who contributed to this release:

• Jean-Francois Cloutier
• Ryan Winchester

v0.8.1!

• Enhancements
  • Update docs and resources
• Fixes
  • An issue when the unsolicited message server would cause a
    no match error that propagated up the supervision tree

Thank you to those who contributed to this release:

• Ryan Winchester

v0.9.0-rc.0

This is release is a massive rework of the entire API and internal works of Grizzly. Please see the release notes for more details as there are a number of breaking changes.

The reasons for this was to provide a better API, better startup times, more robustness with the runtime, and hopefully better long term maintenance. Grizzly does a lot in the way to handle the sequencing of commands the lifecycle of sending and receiving them. Some of this a little complex and was hard to test. Now, while still a little complex, these sections of the code that had a higher risk for regressions are not built in such a way that we can test them. This makes maintaining and releasing code much less low risk.

Also, we did not use OTP in such a way to provide a self-healing system in areas that would greatly benefit from that. With this release all that has better supervision, meaning that the underlining Z-Wave communication should never get into a state that isn’t self-healing. This is very important for embedded devices as they should be able to run indefinitely without human interaction and having a self-healing system is key to achieving this.

For more detailed guide to the breaking changes and how to upgrade please see
our Grizzly v0.8.0 -> v0.9.0 guide.

This release presents a simpler API, faster boot time, more robustness in Z-Wave communication,
and resolves all open issues on Grizzly that were reported as bugs.

Removed APIs

• Grizzly.Node struct
• Grizzly.Conn module
• Grizzly.Notifications module
• Grizzly.Packet module
• Grizzly.close_connection
• Grizzly.command_class_versions_known?
• Grizzly.update_command_class_versions
• Grizzly.start_learn_mode
• Grizzly.get_command_class_version
• Grizzly.has_command_class
• Grizzly.connected?
• Grizzly.has_command_class_names
• Grizzly.config
• Grizzly.Network.busy?
• Grizzly.Network.ready?
• Grizzly.Network.get_state
• Grizzly.Network.set_state
• Grizzly.Network.get_node
• Grizzly.Node.new
• Grizzly.Node.update
• Grizzly.Node.put_ip
• Grizzly.Node.get_ip
• Grizzly.Node.connect
• Grizzly.Node.disconnect
• Grizzly.Node.make_config
• Grizzly.Node.has_command_class?
• Grizzly.Node.connected?
• Grizzly.Node.command_class_names
• Grizzly.Node.update_command_class_versions
• Grizzly.Node.get_command_class_version
• Grizzly.Node.command_class_version_known?
• Grizzly.Node.update_command_class
• Grizzly.Node.put_association
• Grizzly.Node.get_association_list
• Grizzly.Node.configure_association
• Grizzly.Node.get_network_information
• Grizzly.Node.initialize_command_versions

Moved APIs

• Grizzly.reset_controller -> Grizzly.Network.reset_controller
• Grizzly.get_nodes -> Grizzly.Network.get_node_ids
• Grizzly.get_node_info -> Grizzly.Node.get_node_info
• Grizzly.Notifications.subscribe -> Grizzly.subscribe_command and
  Grizzly.subscribe_commands
• Grizzly.Notifications.unsubscribe -> Grizzly.unsubscribe
• Grizzly.add_node -> Grizzly.Inclusions.add_node
• Grizzly.remove_node -> Grizzly.Inclusions.remove_node
• Grizzly.add_node_stop -> Grizzly.Inclusions.add_node_stop
• Grizzly.remove_node_stop -> Grizzly.Inclusions.remove_node_stop
• Grizzly.Client -> Grizzly.Transport
• Grizzly.Security -> Grizzly.ZWave.Security
• Grizzly.DSK -> Grizzly.ZWave.DSK
• Grizzly.Node.add_lifeline_group -> Grizzly.Node.set_lifeline_association

We moved all the commands and command classes to be under the the
Grizzly.ZWave module namespace and refactored the command behaviour.

Grizzly.send_command Changes

The main API function to Grizzly has changed in that it only takes a node id,
command name (atom), command args, and command options.

Also it no longer returns a plain map when there is data to report back from
a Z-Wave node but it will return {:ok, %Grizzly.ZWave.Command{}}.

Please see Grizzly and Grizzly.ZWave.Command docs for more information.

Connections

Grizzly uses the zipgateway binary under the hood. The binary has its own
networking stack and provides a DTLS server for us to connect to. Prior to
Grizzly v0.9.0 we greatly exposed that implementation detail. However, starting
in Grizzly v0.9.0 we have hidden that implementation detail away and all
connection functionally is handle by Grizzly internally. This leaves the
consumer of Grizzly to just work about sending and receiving commands.

If you are using %Grizzly.Conn{} directly this is no longer available and you
should upgrade to just using the node id you were sending commands to.

When Grizzly is Ready

We use to send a notification to let the consumer to know when Grizzly is
read. Staring in v0.9.0 the consumer needs to configure Grizzly’s runtime
with the on_ready module, function, arg callback.

config :grizzly,
  runtime: [
    on_ready: {MyApp, :some_function, []}
  ]

See Grizzly.Runtime for more details

Inclusion Handler Behaviour

Adding and removing a Z-Wave node can be a very interactive process that
involves users being able to talk to the including controller and device. The
way Grizzly < v0.9.0 did it wasn’t vary useful or robust. By adding the the
inclusion handler behaviour we allow the consumer to have full control over the
inclusion process, enabling closer to Z-Wave specification inclusion process.

See Grizzly.InclusionHandler and Grizzly.Inclusions for more information.

Command Handler Behaviour

If you need to handle a Z-Wave command lifecycle differently than the default
Grizzly implementation you can make your own handler and pass it into
Grizzly.send_command as an option:

Grizzly.send_command(node_id, :switch_binary_set, [value: :on], handler: MyHandler)

See Grizzly.CommandHandler for more information.

Supporting Commands

At the point of the rc.0 release are not fully 100% supporting the same
commands as in < v0.8.8, but we are really close. The commands that we haven’t
pulled over are not critical to average Z-Wave device control. We will work to
get all the commands back into place.

Thank you to Jean-Francois Cloutier for contributing so much to this release.

30%20AM660×362 114 KB

I can’t wait to try it out!

New release v0.5.0

TLDR; Provides better error handling when trying to encode command arguments. Improves robustness of Grizzly.

Introduces Grizzly.Command.EncodeError exception and updates encoding and
decoding functions to return tagged tuples. We now use these things when trying
to send a command via Grizzly.send_command/3 so if you have invalid command
arguments we can provide useful error handling with
{:error, Grizzly.Command.EncodeError.t()}. The EncodeError.t() implements
Elixir’s exception behaviour so you can leverage the standard library to
work with the exception.

Unless you have implemented custom commands or used one of the many command
encoders or decodes explicitly this update should not affect you too much. If
you have used the encoder/decoders explicitly please see the documentation for
the ones you have used to see the updated API. If you have written a command we
encourage you to validate the arguments and return the {:error, EncodeError.t()}
to improve the usability of and robustness your command. The new
Grizzly.Command.Encoding module provides some useful functionality for
validating specs for command arguments.

• Enhancements
  • Provide command argument validation and error handling via
    Grizzly.Command.EncodeError.()
  • Update all the command arg encoder/decoder to use tagged
    tuples for better handling of invalid command arguments
  • Introduces new Grizzly.Command.Encoding modules for helping
    validate command argument specifications
• Fixes
  • Crashes when providing invalid command arguments

Big thanks to @jfcloutier for the hard work on this!