forum

Hello,

I have an issue that occurs every now and then (could be weeks or months between instances) but is fairly annoying. I have a cron job set up to restart z-way-server every minute, as I found in the past that it will occasionally crash. This usually helps to keep things running.

However, there is something that happens where, for certain crashes, upon restart, the z-wave binding fails and the log fills with lines such as this: What I believe may be interesting logs prior to that are these: This repeats, it retries: I believe when it's in this state, issuing a "shutdown -r now" does NOT resolve the problem. I actually need to shut down, kill power to the Raspberry Pi (and the Razberry, I'm assuming is the key) to fully reset the device.

I suspect (pure speculation) that the problem is that the Razberry needs some sort of reset. I'm wondering if there's any commands that I can issue to the Razberry to avoid having to actually do a hard reset. It'd be much more convenient if I could automate this process.

As of now, I have to put the RPi on a Wemo switched outlet so that it is possible for me to revive things while away from the device, but this requires a lot of manual intervention and the system is down until I actually notice it.

Any thoughts?

Thanks!

Hi, are you really restarting the z-wave service every minute? Seems very often to me.
Sorry, can´t help you out with your real question, but maybe there are some task not done and you start again to early.
Once a day should be enough, I have to systems that I restart once a month while testing or updating.

Hello,

I tested it and the start appears to be a no-op if the service is already running. So, it just attempts to start the service every minute, but if it's already running, it doesn't affect the running service.

My intention isn't to restart the service to clean up memory leaks or anything. It's to quickly restart the service in the case that it crashes, which does happen occasionally. If I only restart once a day, then the service could be down for a number of hours (or until I notice and then manually start it).

That said, it is during some of these service crashes that it's somehow leaving the Razberry in a bad state that the service can't recover from. Hence my question as to whether there's a programmatic way to reset the device instead of having to power cycle.

This is because the chip is answering some crap. May be because it was left in some undermined step.

You can reset it via and echo command (same as hard reboot).

echo -ne "\x01\x03\x00\x08\xf4" > /dev/ttyAMA0

Has anyone tried the Hard Reset below?

echo -ne "\x01\x03\x00\x08\xf4" > /dev/ttyAMA0

I have tried it after my Razberry 5 seized up as from 07:00 am, but it still won't switch anything. Normally I would have to power off the Pi (3) and turn it back on again, as mentioned in other posts, but it would be so much better if I could do this remotely by using a command such as this one.

I also have a Razberry 7, maybe it works for that?

See the screenshot for my commands. I checked to see the serial port first, which seems to be the TtyAMAO one.

A bit of further information. Following running that command, I re-booted the Pi (I did not power it off, just a soft re-boot), and it all seems to work again. This has never happened before, so I assume the hard reset worked, and re-booting the Pi reset the software. I will try the Soft Reset next time after the hard reset, and without re-booting, to see if that works. At least I have a means of remotely recovering from this situation.

For further info, I have reason to believe that a fridge, which is situated a couple of yards away from 2 or 3 ZWave devices, may cause interference sufficient to interrupt the ZWave signal and cause a loss of connection. The system normally revovers, but occasionally it seizes up. Any views on that?

Further info: The Soft Reset after the Hard one does not work. Hard Reset followed by a reboot of the Pi does.

What firmware are you running on the Razberry 7?
That is the latest which has fixed many bugs from Silicon Labs SDK.

Hi,

Serial API Version was: 07.13

I've now managed to update, via several stages and, initially, two Update Failed messages, to your version:

Firmware
Library Type: Static Controller
SDK Version: 7.21.00
Serial API Version: 07.42

So many thanks for the info. I am now hoping for a major imprevement. Fingers crossed!

Just confirmingg the results of updating to Serial API Version 07.42 etc as above. The improvement after a Re-organisation and 4 days use has been remarkable. Before the re-organisation I had some communication failures similar to before, which normally resulted in a steady degadation and Razberry faiture. This time there was no failure. However, following the Re-organisation, the system has been very much more stable with low times showing on the Timing Info screen, and constant times rather than bouncing around. I have had a few failed communications from a Fibarro Motion Sensor when doing a two-hour wake-up (probably the most distant device in terms of it's route) but not causing any problem. Otherwise, devices that used to cause issues have been fine. All good! Many thanks for the advice, lanbrown.