Make domoticz restart when z-wave driver fail?

[tjabas]

Hi!

i use monit to monitor domoticz, this works good, but nowdays im, like many others, get problems with open z-wave driver failed while domoticz boots up.

is it a way to get domoticz to automaticly reboot itself if z-wave driver fails?

[JonyBCN]

My experience (on a synology NAS) is that the controller works perfectly for days, but at a time it stops working.
To fix it, it doesn't work by restarting Domoticz, I have to restart the NAS completely to make it reboot. I also use Monit and it would be interesting to control the operation of the Zwave USB driver to act accordingly.

[lost]

To fix it, it doesn't work by restarting Domoticz, I have to restart the NAS completely to make it reboot. I also use Monit and it would be interesting to control the operation of the Zwave USB driver to act accordingly.

There was a setup in domoticz supposed to handle this kind of issue: This was a timeout somewhere that, if not a single frame was sent/received by controler, was triggering a controler soft reset.

At the very beginning, this was causing my system to malfunction as a side effect: I only had a few devices to manage heating, with sometimes hours between setpoint changes (schedule driven). As this timeout was defaulting to a few minutes, with z-wave bring-up duration in the same order of magnitude, this was causing most schedules setup to fail... This is no more the case as I now have lot of devices, almost constantly sending data (kWh, temperatures, movement...), but at the time I had to set this timeout > max delay between schedules to get rid of issues and have a rock-solid z-wave network.

If this timeout does not always work (because the controller just cannot manage this soft reset there?), for a USB device the other option would be to trigger a USB reset.

Had to do this in the past to test the buggy hot restart path of some eUSB storage on telco embedded boards. You have to get the path of the device (after identifying bus etc from lsusb command) in /dev/bus/usb...

Then, as there is in my knownledge no way to trigger this from a sysfs, call this small C program with the device path as an argument, after compiling it on your target platform (build essentials package will be needed on Raspbian, as well as kernel source package ; another option would be cross compiling from a PC but more complex):

Code: Select all

#include <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <sys/ioctl.h>
#include <fcntl.h>

#include <linux/usbdevice_fs.h>

int main(int argc, char **argv)
{
    const char *filename;
    int fd;
    int rc;

    if (argc != 2) {
        fprintf(stderr, "Usage: usbreset device-filename\n");
        return 1;
    }
    filename = argv[1];

    fd = open(filename, O_WRONLY | O_SYNC);
    if (fd < 0) {
        perror("Error opening output file");
        return 1;
    }

    printf("Resetting USB device %s... ", filename);
    rc = ioctl(fd, USBDEVFS_RESET, 0);
    if (rc < 0) {
        perror("Error in ioctl");
        return 1;
    }
    printf("DONE !\n");

    close(fd);
    return 0;
}

Then compile/test it:
gcc -o usbreset usbreset.c

$ ./usbreset
Usage: usbreset device-filename

Then get the device path & call program with the right argument, after stopping domoticz after a z-wave fail, and see if domoticz restart bring back z-wave. This would avoid a full reboot...

Hope this still work as is, this was done about 6 years ago.

You may also do this in python (to avoid installing gnu C toolchain etc...), as we can use ioctl's from there. A small search shows this:
https://iotbytes.wordpress.com/python-s ... pberry-pi/

This is for another kind of USB device (old RTC modems) but this looks exactly similar to the C program hereupper.

[lost]

There was a setup in domoticz supposed to handle this kind of issue: This was a timeout somewhere that, if not a single frame was sent/received by controler, was triggering a controler soft reset.

At home now, so could check for this: It's still there, being the inactivity delay in hardware section when you select the z-wave controller line. Check this delay is not deactivated by default and set it to a value OK for your own setup (compromise between quick restart on failure & avoiding possible explained drawback on low activity z-wave networks).

Currently I have 10 minutes. I don't see any z-wave controller resets in logs due to silences reaching this delay. A few years ago default was 1mn and this was not enough for many setups.

[JonyBCN]

Very interesting. By default it is disabled, I have left it active with a time of 30 minutes, I think more than enough, and I will try. I can save myself restarting the NAS weekly if it works.