This plugin allows the exploitation of Z-Wave modules through the OpenZwave library.
Z-Wave communicates using low power radio technology in the 868.42 MHz frequency band. It is specifically designed for home automation applications. The Z-Wave radio protocol is optimized for low bandwidth exchanges (between 9 and 40 kbit / s) between devices on battery or powered by mains.
Z-Wave operates in the sub-gigahertz frequency range, according to the regions (868 MHz in Europe, 908 MHz in the US, and other frequencies according to the ISM bands of the regions). The theoretical range is around 30 meters indoors and 100 meters outdoors. Z-Wave network uses mesh technology to increase range and reliability. Z-Wave is designed to be easily integrated into low-power electronic products, including battery-powered devices such as remote controls, smoke detectors and security sensors.
The Z-Wave +, brings certain improvements including a better range and improves the life of the batteries among others. Full backward compatibility with the Z-Wave.
Radio receivers must be positioned at a minimum distance of 50 cm from other radio sources.
Examples of radio sources:
If you have a USB controller (Z-Stick), it is recommended to move it away from the box using a simple USB extension cable of 1M for example.
The distance between other wireless transmitters such as cordless phones or radio audio transmissions should be at least 3 meters. The following radio sources should be considered :
The locations of the modules must be chosen in such a way that the direct connection line works only for a very short distance through the material (a wall), in order to avoid attenuations as much as possible.
Metal parts of the building or furniture can block electromagnetic waves.
Mains Z-Wave nodes can transmit and repeat messages that are not within direct range of the controller. This allows greater flexibility of communication, even if there is no direct wireless connection or if a connection is temporarily unavailable, due to a change in the room or building.
The controller Id 1 can communicate directly with nodes 2, 3 and 4. Node 6 is outside of its radio range, however, it is in the radio coverage area of node 2. Therefore, the controller can communicate with node 6 via node 2. In this way, the path of the controller via node 2 to node 6, is called route. In case direct communication between node 1 and node 2 is blocked, there is yet another option to communicate with node 6, using node 3 as another signal repeater.
It becomes obvious that the more sector nodes you have, the more the routing options increase, and the more the network stability increases. Z-Wave protocol is capable of routing messages through up to four repeat nodes. It is a compromise between the size of the network, the stability and the maximum duration of a message.
It is strongly recommended at the start of installation to have a ratio between sector nodes and node on batteries of 2/3, in order to have a good network mesh. Favor micromodules over smart plugs. The micro modules will be in a final location and will not be disconnected, they also generally have a better range. A good start is the lighting of common areas. It will allow you to properly distribute the sector modules at strategic locations in your home. Then you can add as many modules on the stack as desired, if your basic routes are good.
The Network graph as well as Routing table allow you to view the quality of your network.
There are repeater modules to fill areas where no sector module is useful.
|Controller||Knows all the neighbors||Has access to the complete routing table||Can communicate with all devices in the network, if a channel exists|
|Slave||Knows all the neighbors||Has no information on the routing table||Cannot reply to the node it received the message. Therefore, cannot send unsolicited messages|
|Routing slaves||Knows all its neighbors||With partial knowledge of the routing table||Can reply to the node it received the message from and can send unsolicited messages to a number of nodes|
After downloading the plugin, you just need to activate and configure it.
Once activated, the demon should launch. The plugin is preconfigured with default values; you normally have nothing more to do. However you can change the configuration.
This part allows you to validate and install the dependencies required for the proper functioning of the Zwave plugin (both locally and remotely, here locally)
Updating dependencies can take more than 20 minutes depending on your hardware. Progress is displayed in real time and a log Openzwave_update is accessible.
Updating dependencies is normally to be performed only if the Status is NOk, but it is however possible, to solve certain problems, to be called to redo the installation of dependencies.
If you are in remote mode, the dependencies of the local daemon can be NOK, this is completely normal.
This part allows you to validate the current state of the daemon (s) and to configure the automatic management of these. The local demon and all the deported demons will be displayed with their different information
This part allows you to choose the log level as well as to consult its content.
Select the level then save, the daemon will then be restarted with the instructions and traces selected.
Level Debug or Info can be useful to understand why the demon plants or does not go up a value.
In mode Debug the demon is very verbose, it is recommended to use this mode only if you have to diagnose a particular problem. It is not recommended to let the demon run while Debug permanently, if we use a SD-Card. Once the debug is over, don’t forget to return to a lower level like the level Error which only goes back to possible errors.
This part allows you to configure the general parameters of the plugin
Config modules : allows to recover, manually, the OpenZWave configuration files with the parameters of the modules as well as the definition of the commands of modules for their uses.
Module configurations are retrieved automatically every night.
Restarting the daemon after updating module configurations is useless.
If you have an unrecognized module and a configuration update has just been applied, you can manually start the recovery of module configurations.
Once the configurations have been retrieved, depending on the changes made:
Pour un module dont le « mapping » de commandes a été corrigé : the magnifying glass on the controls, see below.
If in doubt, exclude and re-include the module is recommended.
Do not forget to if you make a change.
If you are using Ubuntu : For the daemon to work, you must have ubuntu 15.04 (lower versions have a bug and the daemon cannot start). Be careful if you update from 14.04 it takes once in 15.04 restart the installation of dependencies.
Selecting the Z-Wave Key Port in automatic detection mode, Auto, only works for USB dongles.
Allows you to display or not the mobile panel when you use the application on a phone.
Z-Wave equipment configuration is accessible from the plugin menu :
Below an example of a Z-Wave plugin page (presented with some equipment) :
As in many places on Jeedom, placing the mouse on the far left allows a quick access menu to appear (you can, from your profile, always leave it visible).
The buttons on the top line Synchronize, Zwave Network and Health, are visible only if you are in mode Expert.
Here you find all the configuration of your equipment :
Module : this field only appears if there are different types of configuration for your module (case for modules that can make pilot wires for example). It allows you to choose the configuration to use or modify it later
Deleting equipment does not lead to exclusion of the module from the controller. Deleted equipment that is still attached to its controller will be automatically recreated following synchronization.
Below you find the list of orders :
Depending on the types and subtypes, some options may be missing.
Advanced configuration (small notched wheels) : displays the advanced configuration of the command (logging method, widget, etc.)).
The button Test in the case of an Info type command, will not query the module directly but the value available in the Jeedom cache. The test will return the correct value only if the module in question has transmitted a new value corresponding to the definition of the command. It is therefore completely normal not to obtain a result following the creation of a new Info command, especially on a battery-powered module which rarely notifies Jeedom.
The magnifying glass, available in the general tab, allows you to recreate all the commands for the current module. If no command is present or if the commands are wrong the magnifying glass should remedy the situation.
The magnifying glass will delete existing orders. If the commands were used in scenarios, you will then have to correct your scenarios in the other places where the commands were used.
Some modules have several preconfigured command sets
You can select them via the possible choices, if the module allows it.
You must magnify to apply the new command sets.
For a certain number of modules, specific help for the installation as well as recommendations of parameters are available.
The button Documentation provides access to specific module documentation for Jeedom.
Particular modules also have a specific assistant to facilitate the application of certain parameters or operations.
The button Assistant gives access to the specific assistant screen of the module.
Apply a configuration set recommended by the Jeedom team.
When included, the modules have the manufacturer’s default parameters and certain functions are not activated by default.
The following elements, as applicable, will be applied to simplify the use of the module.
To apply the recommended configuration set, click on the button : Recommended configuration, then confirm the application of the recommended configurations.
The assistant activates the various configuration elements.
A confirmation of the good progress will be displayed in the form of a banner
Battery modules must be awakened to apply the configuration set.
The equipment page informs you if elements have not yet been activated on the module. Please refer to the module documentation to wake it up manually or wait for the next wake up cycle.
It is possible to automatically activate the application of the recommended configuration set when including a new module, see the Plugin configuration section for more details.
This is where you will find all the information about your module
The window has several tabs :
Provides a complete summary of your node with various information on it, such as the status of requests which lets you know if the node is waiting for information or the list of neighboring nodes.
On this tab it is possible to have alerts in case of possible detection of a configuration problem, Jeedom will tell you the procedure to follow to correct. Do not confuse an alert with an error, the alert is in most cases a simple recommendation.
You will find here all the possible commands and states on your module. They are ordered by instance and command class then index. The « mapping » des commandes est entièrement basé sur ces informations.
Force update of a value. The modules on battery will refresh a value only at the next wake-up cycle. It is however possible to manually wake up a module, see the module documentation.
It is possible to have more orders here than on Jeedom, this is completely normal. In Jeedom the orders have been preselected for you.
Some modules do not automatically send their states, in this case it is necessary to activate the manual refresh at 5 minutes on the desired value (s). It is recommended to automatically leave the refresh. Abuse of manual refresh can strongly impact the performance of the Z-Wave network, use only for the values recommended in the specific Jeedom documentation. The set of values (index) of the instance of a class command will be reassembled, activating manual refresh on the smallest index of the instance of the class command. Repeat for each instance if necessary.
Here you will find all the possibilities for configuring the parameters of your module as well as the possibility of copying the configuration from another node already in place.
When a parameter is modified, the corresponding line turns yellow, the setting is waiting to be applied.
If the module accepts the parameter, the line becomes transparent again.
If however the module refuses the value, the line will then turn red with the applied value returned by the module.
On inclusion, a new module is detected with the manufacturer’s default settings. On some modules, functionalities will not be active without modifying one or more parameters. Refer to the manufacturer’s documentation and our recommendations in order to properly configure your new modules.
Battery modules will apply parameter changes only to the next wake-up cycle. It is however possible to manually wake up a module, see the module documentation.
The command Resume from allows you to resume the configuration of another identical module, on the current module.
The command Apply on allows you to apply the current module configuration to one or more identical modules.
The command Update settings forces the module to update the parameters saved in the module.
If no configuration file is defined for the module, a manual wizard allows you to apply parameters to the module. Please refer to the manufacturer’s documentation for the definition of the index, value and size.
This is where you find the management of the association groups of your module.
Z-Wave modules can control other Z-Wave modules, without going through the controller or Jeedom. The relationship between a control module and another module is called association.
In order to control another module, the command module needs to maintain a list of devices that will receive command control. These lists are called association groups and they are always linked to certain events (for example the button pressed, sensor triggers, etc ).
In the event that an event occurs, all devices registered in the association group concerned will receive a Basic command.
See the documentation of the module, to understand the different groups of possible associations and their behavior.
The majority of modules have an association group which is reserved for the main controller, it is used to send information to the controller. It is generally called : Report or LifeLine.
Your module may not have any groups.
The modification of the association groups of a battery module will be applied to the next wake-up cycle. It is however possible to manually wake up a module, see the module documentation.
To know with which other modules the current module is associated, just click on the menu Associated with which modules
All the modules using the current module as well as the name of the association groups will be displayed.
Some module supports a multi-instance associations class command. When a module supports this CC, it is possible to specify with which instance one wishes to create the association
Some modules must be associated with instance 0 of the main controller in order to function properly. For this reason, the controller is present with and without the instance 0.
Tab grouping the module’s system parameters.
Battery modules wake up at regular cycles, called Wakeup Interval). Wake-up interval is a compromise between maximum battery life and desired device responses. To maximize the life of your modules, adapt the Wakeup Interval value for example to 14,400 seconds (4h), see even higher depending on the modules and their use.
Modules Light switch and Dimmer can implement a special Command Class called SwitchAll 0x27. You can change the behavior here. Depending on the module, several options are available. The command SwitchAll On / OFF can be launched via your main controller module.
Allows you to perform certain actions on the module.
Certain actions will be active according to the type of module and its possibilities or according to the current state of the module such as if it is presumed dead by the controller.
Do not use actions on a module if you do not know what you are doing. Some actions are irreversible. Actions can help solve problems with one or more Z-Wave modules.
The Regeneration of node detection allows to detect the module to accept the last sets of parameters. This action is required when you are informed that an update of parameters and or behavior of the module is required for proper functioning. The regeneration of the detection of the node implies a restart of the network, the assistant carries out it automatically.
If you have several identical modules which are required to run the Regeneration of node detection, it is possible to launch it once for all identical modules.
If a module on a stack is no longer reachable and you want to exclude it, and the exclusion does not take place, you can launch Remove ghost node An assistant will perform various actions to remove the so-called ghost module. This action involves restarting the network and may take several minutes to complete.
Once launched, it is recommended to close the module configuration screen and monitor the deletion of the module via the Z-Wave health screen.
Only modules on battery can be deleted via this wizard.
This tab gives some communication statistics with the node.
Can be interesting in case of modules which are presumed dead by the controller “Dead”.
When it leaves the factory, a module does not belong to any Z-Wave network.
The module must join an existing Z-Wave network to communicate with the other modules of this network. This process is called Inclusion. Devices can also leave a network. This process is called Exclusion. Both processes are initiated by the main controller of the Z-Wave network.
This button allows you to switch to inclusion mode to add a module to your Z-Wave network.
You can choose the inclusion mode after clicking the button Inclusion.
Since the appearance of the Z-Wave +, it is possible to secure exchanges between the controller and the nodes. It is therefore recommended to do the inclusions in mode Secured.
If however, a module cannot be included in secure mode, please include it in secure mode Insecure.
Once in inclusion mode : Jeedom tells you.
An ‘unsecured’ module can order ‘insecure’ modules’. A ‘non-secure’ module cannot order a ‘secure’ module’. A ‘secure’ module can order ‘non-secure’ modules provided that the transmitter supports it.
Once the wizard is launched, you must do the same on your module (refer to its documentation to switch it to inclusion mode).
As long as you do not have the banner, you are not in inclusion mode.
If you click on the button again, you exit the inclusion mode.
It is recommended, before the inclusion of a new module that would be “new” on the market, to launch the order Config modules via the plugin configuration screen. This action will recover all the latest versions of the openzwave configuration files as well as the Jeedom command mapping.
During an inclusion, it is advised that the module is near the main controller, or less than one meter from your jeedom.
Some modules require an inclusion in mode Secured, for example for door locks.
Note that the mobile interface also gives you access to inclusion, the mobile panel must have been activated.
If the module already belongs to a network, follow the exclusion process before including it in your network. Otherwise the inclusion of this module will fail. It is also recommended to execute an exclusion before inclusion, even if the product is new, out of the box.
Once the module in its final location, it is necessary to launch the action to take care of the network, in order to ask all the modules to refresh all the neighbors.
This button allows you to switch to exclusion mode, to remove a module from your Z-Wave network, you must do the same with your module (refer to its documentation to switch it to exclusion mode).
As long as you do not have the banner, you are not in exclusion mode.
If you click on the button again, you will exit exclusion mode.
Note that the mobile interface also gives you access to the exclusion.
A module does not need to be excluded by the same controller on which it was previously included. Hence the fact that it is recommended to execute an exclusion before each inclusion.
Button allowing synchronization of the Z-Wave network modules with Jeedom equipment. The modules are associated with the main controller, the devices in Jeedom are created automatically when they are included. They are also automatically deleted when excluded, if the option Automatically delete excluded devices is activated.
If you have included modules without Jeedom (requires a battery dongle like the Aeon-labs Z-Stick GEN5), synchronization will be necessary after plugging in the key, once the daemon has started and is operational.
If you do not have the image or Jeedom has not recognized your module, this button can be used to correct (provided that the module interview is complete).
If on your routing table and / or on the Z-Wave health screen, you have one or more modules named with their generic name, synchronization will remedy this situation.
The Synchronize button is only visible in expert mode :
Here you will find general information about your Z-Wave network.
The first tab gives you the basic summary of your Z-Wave network, you will find in particular the status of the Z-Wave network as well as the number of elements in the queue.
A set of information on the current state of the network, namely :
Once the network has at least reached Topology loaded, internal mechanisms of the Z-Wave server will force updates of values, it is therefore completely normal to see the number of messages rise. This will quickly return to 0.
The network is said to be functional when it reaches the status Topology loaded, that is to say that all the sector nodes have completed their interviews. Depending on the number of modules, the battery / sector distribution, the choice of the USB dongle and the PC on which the Z-Wave plugin is running, the network will reach this state between one and five minutes.
A network Ready, means that all sector and battery nodes have completed their interview.
Depending on the modules you have, the network may never reach status by itself Ready. Remote controls, for example, don’t wake up on their own and will never complete their interview. In this kind of case, the network is fully operational and even if the remote controls have not completed their interview, they ensure their functionality within the network.
Used to find out whether the controller is a primary or secondary controller.
Displays various system information.
Here you will find all the possible actions for your entire Z-Wave network. Each action is accompanied by a brief description.
Certain actions are really risky or even irreversible, the Jeedom team cannot be held responsible in the event of improper handling.
Some modules require inclusion in secure mode, for example for door locks. Secure inclusion must be launched via the action on this screen.
If an action cannot be launched, it will be deactivated until it can be executed again.
Here you will find general statistics for your entire Z-Wave network.
This tab will give you a graphic representation of the different links between the nodes.
Explanation of the color legend :
Only active equipment will be displayed in the network graph.
The Z-Wave network consists of three different types of nodes with three main functions.
The main difference between the three types of nodes is their knowledge of the network routing table and subsequently their ability to send messages to the network.
Each node is able to determine which other nodes are in direct communication. These nodes are called neighbors. During the inclusion and / or later on request, the node is able to inform the controller of the list of neighbors. Thanks to this information, the controller is able to build a table that has all the information on the possible communication routes in a network.
The rows of the table contain the source nodes and the columns contain the destination nodes. Refer to the legend to understand the cell colors that indicate the links between two nodes.
Explanation of the color legend :
Only active equipment will be displayed in the network graph.
A module presumed dead, does not participate / no longer in the networking of the network. It will be marked here with a red exclamation point in a triangle.
You can manually start the neighbor update, by module or for the whole network using the buttons available in the routing table.
This window summarizes the status of your Z-Wave network :
You have here :
Disabled equipment will be displayed but no diagnostic information will be present.
The name of the module can be followed by one or two images:
Modules supportant la COMMAND_CLASS_ZWAVE_PLUS_INFO
Modules supportant la COMMAND_CLASS_SECURITY and securisé.
Modules supportant la COMMAND_CLASS_SECURITY and non Secured.
Module FLiRS, routeurs esclaves (modules à piles) à écoute fréquente.
The Ping command can be used if the module is presumed dead “DEATH” in order to confirm if this is really the case.
Sleeping modules will only respond to Ping the next time they wake up.
Timeout notification does not necessarily mean a problem with the module. Launch a Ping and in most cases the module will respond with a Notification NoOperation which confirms a fruitful return from ping.
The Delay and% OK on nodes on batteries before the completion of their interview is not significant. Indeed the node will not respond to the controller’s interrogations of the fact that it is in deep sleep.
The Z-Wave server automatically takes care of launching tests on the modules in Timeout after 15 minutes
The Z-Wave server automatically tries to reassemble the modules that are presumed dead.
An alert will be sent to Jeedom if the module is presumed dead. You can activate a notification to be informed as soon as possible. See the Message configuration in the Jeedom Configuration screen.
If on your routing table and / or on the Z-Wave health screen you have one or more modules named with their generic name, synchronization will remedy this situation.
If on your routing table and / or on the Z-Wave health screen you have one or more modules named Unknown, this means that the module interview has not been successfully completed. You probably have a NOk in the constructor column. Open the details of the module (s), to try the suggested solutions (see section Troubleshooting and diagnostics, below).
Step of interviewing a module after starting the daemon.
Details of notifications sent by modules
The backup part will allow you to manage the backups of your network topology. This is your zwcfgxxx file.xml, it constitutes the last known state of your network, it is a form of cache of your network. From this screen you can :
Following an update of the Z-Wave plugin it is possible that Jeedom asks you to update the Z-Wave dependencies. A dependency NOK will be displayed:
An update of the dependencies is not to be done with each update of the plugin.
Jeedom should launch the dependency update by itself if the plugin considers that they are NOk. This validation is carried out after 5 minutes.
The duration of this operation can vary depending on your system (up to more than 1 hour on raspberry pi)
Once the update of dependencies is completed, the daemon will restart automatically upon validation of Jeedom. This validation is carried out after 5 minutes.
In the event that the updating of the dependencies does not complete, please consult the log Openzwave_update who should inform you about the problem.
You will find the list of compatible modules here
Start the Regeneration of the node detection from the Actions tab of the module.
If you have several modules in this scenario, launch Regenerate the detection of unknown nodes from the screen Zwave network tab Actions.
If the module is still connected and reachable, follow the solutions proposed in the module screen.
If the module has been canceled or is really defective, you can exclude it from the network using delete the node in error via tab Actions.
If the module has been repaired and a new replacement module has been delivered, you can launch Replace failed node via tab Actions, the controller triggers the inclusion then you must proceed with the inclusion on the module. The id of the old module will be kept as well as its commands.
It is available via your controller node. Your controller should have Switch All On and Switch All Off commands.
If your controller does not appear in your module list, start synchronization.
Class Switch All Command is generally supported on switches and drives. Its behavior is configurable on each module that supports it.
So we can either:
The choice of options depends on the manufacturer.
You must therefore take the time to review all of its switches / dimmers before setting up a scenario if you do not control only lights.
You can add the command in the command mapping screen.
This is an order Info in CC 0x2b Instance 0 commande data \ [0 ]. val
Scene mode must be activated in module settings. See the documentation for your module for more details.
It is possible to force the request to refresh the values of an instance for a specific class command.
It is possible to do via an http request or create an order in the equipment mapping screen.
This is an order Action choose the CC desired for a Instance given with the command data \ [0 ]. ForceRefresh()
All the instance indexes for this Class command will be updated. The nodes on batteries will await their next awakening before carrying out the update of their value.
You can also use by script by sending an http request to the Z-Wave REST server. Replace ip_jeedom, node_id, instance_id, cc_id and index
For different reasons, you may have to transfer all of your modules to a new main controller.
You decide to go from raZberry has a Z-Stick Gen5 or because, you have to perform a Reset complete of main controller.
Here are different steps to get there without losing your valuable scenarios, widgets and history:
How to redo the inclusion of a failing module without losing your value scenarios, widgets and histories
If the module is assumed to be “Dead” :
If the module is not presumed to be “Dead” but is still accessible:
If you have lost all communication with a battery-powered module and want to exclude it from the network, it is possible that the exclusion does not succeed or that the node remains present in your network.
Automatic ghost node assistant is available.
This wizard is only available for battery modules.
It is recommended to perform the inclusion at least 1M from the main controller, or this will not be the final position of your new module. Here are some good practices to follow following the inclusion of a new module in your network.
Once the inclusion is complete, we must apply a certain number of parameters to our new module in order to get the most out of it. Reminder, the modules, following inclusion, have the manufacturer’s default settings. Take advantage of being next to the Jeedom controller and interface to properly configure your new module. It will also be easier to wake up the module to see the immediate effect of the change. Some modules have specific Jeedom documentation to help you with the different parameters as well as recommended values.
Test your module, confirm the feedback, status feedback and possible actions in the case of an actuator.
During the interview, your new module looked for its neighbors. However, the modules in your network do not yet know your new module.
Move your module to its final location. Launch the update of its neighbors and wake it up again.
We see that he sees a certain number of neighbors but that the neighbors do not see him.
To remedy this situation, it is necessary to launch the action to take care of the network, in order to ask all the modules to find their neighbors.
This action can take 24 hours before being completed, your battery modules will perform the action only the next time they wake up.
The option to treat the network twice a week allows you to do this process without any action on your part, it is useful when installing new modules and or when moving them.
Z-Wave modules very rarely send their battery status to the controller. Some will do it at inclusion then only when it reaches 20% or another critical threshold value.
To help you better monitor the status of your batteries, the Batteries screen under the Analysis menu gives you an overview of the status of your batteries. A low battery notification mechanism is also available.
The value returned from the Batteries screen is the last known in the cache.
Every night, the Z-Wave plugin asks each module to refresh the Battery value. The next time you wake up, the module sends the value to Jeedom to be added to the cache. So you generally have to wait at least 24 hours before obtaining a value in the Batteries screen.
It is of course possible to manually refresh the Battery value via the Values tab of the module, then either wait for the next wake-up or even manually wake the module to obtain an immediate rise. The Wake-up Interval of the module is defined in the System tab of the module. To optimize the life of your batteries, it is recommended to space this delay as long as possible. For 4h, apply 14400, 12h 43200. Certain modules must listen regularly to messages from the controller such as Thermostats. In this case, you have to think of 15 min, i.e. 900. Each module is different, so there is no exact rule, it is case by case and according to experience.
The discharge of a battery is not linear, some modules will show a large percentage loss in the first days of commissioning, then do not move for weeks to empty quickly once past the 20%.
When you start the Z-Wave daemon, if you try to immediately start an inclusion / exclusion, you may get this message: * “The controller is initializing, please try again in a few minutes”
Following the start of the daemon, the controller goes on all the modules in order to repeat their interview. This behavior is completely normal in OpenZWave.
If however after several minutes (more than 10 minutes), you still have this message, it is no longer normal.
You have to try the different steps:
We must now start the hardware tests:
If the problem still persists, reset the controller:
No more orders are transmitted to the modules, but status returns are sent back to Jeedom.
Controller message queue may be full. See the Z-Wave Network screen if the number of pending messages only increases.
In this case you have to restart the Demon Z-Wave.
If the problem persists, you must reset the controller:
Several errors can occur when updating dependencies. Check the dependency update log to determine what exactly is the error. Generally, the error is at the end of the log in the last few lines.
Here are the possible problems and their possible solutions:
The mercurial package does not want to install, to correct launch in ssh:
sudo rm /var/lib/dpkg/info/$mercurial* -f sudo apt-gand install mercurial
At 75% this is the start of the compilation of the openzwave library as well as the openzwave python wrapper. This step is very long, you can however view the progress via the update log view. So you just have to be patient.
arm-linux-gnueabihf-gcc: internal compiler error: Killed (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions. error: command 'arm-linux-gnueabihf-gcc' failed with exit status 4 Makefile:266: recipe for targand 'build' failed make: *** [build] Error 1
This error can occur due to a lack of RAM memory during compilation.
From the jeedom UI, launch the compilation of dependencies.
Once launched, in ssh, stop these processes (consumers in memory) :
sudo systemctl stop cron sudo systemctl stop apache2 sudo systemctl stop mysql.
To follow the progress of the compilation, we tail the log file openzwave_update.
tail -f /var/www/html/log/openzwave_update
When the compilation is complete and without error, restart the services that you stopped
sudo systemctl start cron sudo systemctl start apache2 sudo systemctl start mysql
To use a Razberry controller on a Raspberry Pi 3, the Raspberry’s internal Bluetooth controller must be disabled.
Add this line:
At the end of the file:
Then restart your Raspberry.
The Z-Wave plugin provides developers and users with a complete API in order to be able to operate the Z-Wave network via HTTP request.
You can use all of the methods exposed by the REST server of the Z-Wave daemon.
The syntax for calling routes is in this form:
To know all the routes, please refer Github of the Z-Wave plugin.
Example: To ping the node id 2
I get the error “Not enough space in stream buffer”
Unfortunately this error is hardware, there is nothing we can do about it and we are looking for the moment how to force a restart of the daemon in the event of this error (but often it is also necessary to unplug the key for 5 min so that it starts again)