- Enhancements
- Support
FIRMWARE_UPDATE_MDmeta data report command v5
- Support
mattludwigs
mattludwigs
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.NodestructGrizzly.ConnmoduleGrizzly.NotificationsmoduleGrizzly.PacketmoduleGrizzly.close_connectionGrizzly.command_class_versions_known?Grizzly.update_command_class_versionsGrizzly.start_learn_modeGrizzly.get_command_class_versionGrizzly.has_command_classGrizzly.connected?Grizzly.has_command_class_namesGrizzly.configGrizzly.Network.busy?Grizzly.Network.ready?Grizzly.Network.get_stateGrizzly.Network.set_stateGrizzly.Network.get_nodeGrizzly.Node.newGrizzly.Node.updateGrizzly.Node.put_ipGrizzly.Node.get_ipGrizzly.Node.connectGrizzly.Node.disconnectGrizzly.Node.make_configGrizzly.Node.has_command_class?Grizzly.Node.connected?Grizzly.Node.command_class_namesGrizzly.Node.update_command_class_versionsGrizzly.Node.get_command_class_versionGrizzly.Node.command_class_version_known?Grizzly.Node.update_command_classGrizzly.Node.put_associationGrizzly.Node.get_association_listGrizzly.Node.configure_associationGrizzly.Node.get_network_informationGrizzly.Node.initialize_command_versions
Moved APIs
Grizzly.reset_controller→Grizzly.Network.reset_controllerGrizzly.get_nodes→Grizzly.Network.get_node_idsGrizzly.get_node_info→Grizzly.Node.get_node_infoGrizzly.Notifications.subscribe→Grizzly.subscribe_commandand
Grizzly.subscribe_commandsGrizzly.Notifications.unsubscribe→Grizzly.unsubscribeGrizzly.add_node→Grizzly.Inclusions.add_nodeGrizzly.remove_node→Grizzly.Inclusions.remove_nodeGrizzly.add_node_stop→Grizzly.Inclusions.add_node_stopGrizzly.remove_node_stop→Grizzly.Inclusions.remove_node_stopGrizzly.Client→Grizzly.TransportGrizzly.Security→Grizzly.ZWave.SecurityGrizzly.DSK→Grizzly.ZWave.DSKGrizzly.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.
4
mattludwigs
Breaking Changes
Grizzly.ZWave.IconTypesremovedicon_typefrom the atom values of the
icon name.Grizzly.ZWave.DeciveTypes.icon_name()→
Grizzly.ZWave.DeviceTypes.name()Grizzly.ZWave.DeciveTypes.icon_integer()→
Grizzly.ZWave.DeviceTypes.value()
Enhancements
- Doc updates
- Internal code quality
- Deps updates
- Better types around DSKs
- CI support for elixir versions 1.8, 1.9, and 1.10
- Support all versions of the meter report
- Support a low battery report
0
mattludwigs
Deprecated
Grizzly.Node.get_node_info/1- useGrizzly.Node.get_info/1instead
Added
Grizzly.Node.get_info/1Grizzly.ZWave.CommandClasses.SupervisionGrizzly.ZWave.Commands.SupervisionGetGrizzly.ZWave.Commands.SupervisionReportGrizzly.ZWave.CommandClasses.SensorBinaryGrizzly.ZWave.Commands.SensorBinaryGetGrizzly.ZWave.Commands.SensorBinaryReport
Enhancements
- Support for
DoorLockOperationReport>= V3 parsing
Fixes
- Bad parsing of
NodeAddStatus:failedvalue
Thank you to those who contributed to this release:
- Jean-Francois Cloutier
0
mattludwigs
Enhancements
- Some Z-Wave devices report the wrong value for the switch multilevel
report so we added support for those values.
Fixes
- When two processes quickly sent the same command to the same device only
one process would receive the response
Thank you to those who contributed to this release:
- Jean-Francois Cloutier
0
mattludwigs
Enhancements
- Add
Grizzly.ZWave.Commands.FirmwareMDGet - Add
Grizzly.ZWave.Commands.FirmwareUpdateMDRequestGet - Add
Grizzly.ZWave.Commands.FirmwareUpdateMDRequestReport - Add
Grizzly.ZWave.Commands.FirmwareUpdateMDStatusReport - Add
Grizzly.ZWave.Commands.FrimwareUpdateMDReport - Add
Grizzly.ZWave.Commands.FirmwareUpdateActivationSet - Add
Grizzly.ZWave.Commands.FirmwareUpdateActivationReport - Remove some dead code
Fixes
- When resetting the controller we were not closing the connections to
the nodes. This caused some error logging inzipgatewayand also left
open unused resources. This could cause problems later when reconnecting
devices to resources that were already in the system.
Thank you to those who contributed to this release:
- Jean-Francois Cloutier
0
mattludwigs
Removed the parameter :secure_command_classes from
Grizzly.ZWave.Command.NodeInfoCacheReport. Also updated the param
:command_classes to be a keyword list of the various command classes that
the node can have.
The fields in the keyword list are:
:non_secure_supported:non_secure_controlled:secure_supported:secure_controlled
If you are using :secure_command_classes for checking if the device is
securely added you can update like this:
{:ok, node_info} = Grizzly.Node.get_info(10)
Keyword.get(Grizzly.ZWave.Command.param!(node_info, :command_classes), :secure_controlled)
Enhancements
- Add
Grizzly.ZWave.Commands.AssociationGroupCommandListGet - Add
Grizzly.ZWave.Commands.AssociationGroupCommandListReport - Add
Grizzly.ZWave.Commands.AssociationGroupInfoGet - Add
Grizzly.ZWave.Commands.AssociationGroupInfoReport - Add
Grizzly.ZWave.Commands.AssociationGroupNameGet - Add
Grizzly.ZWave.Commands.AssociationGroupNameReport - Add
Grizzly.ZWave.Commands.MultiChannelEndpointGet - Add
Grizzly.ZWave.Commands.MultiChannelEndpointReport
Fixes
- Internal command class name discrepancies
Thank you to those who contributed to this release:
- Jean-Francois Cloutier
1