forum

I am probably doing something wrong here, but after a reboot it turns out I am unable to stop the z-way-server by issuing: pi@raspberrypi:~ $ sudo /etc/init.d/z-way-server stop If I try and run "top" right after attempting to stop the server by using the line above, I still see z-way-serve...

Starting it with the exact command line you suggested writes a lot of numbers to console. How exactly do I redirect to only file?

Ok, it is restarted but it is running extremely slow now, and at times is so busy that it temporarily seems to stop responding. Is it writing log data to both PuTTY console window and to a file? Is there anything I can do to make logging affect performance a bit less by any chance?

/J

Ok, good to know.

I seem to recall rebooting the RPi before the server launch in the log above, but will make a clean start tonight to make sure.

Hm, this is strange - if you look in the log from the PuTTY window, you can see that I did just that in the first line:

"pi@raspberrypi:/opt/z-way-server $ sudo /etc/init.d/z-way-server stop
Stopping z-way-server: done."

Ok, the new debug build installed and seems to run although there are some errors reported that I don't know if they are to be considered normal/expected at this stage: Error: 'debug-port' number is out of range. Skipping it. [2020-03-09 21:48:59.416] [E] [core] result: Error: Error: Failed to bind ...

I gave the new test build a go and still get a crash within the usual <=2 days of uptime (this time around 1d 18 hours). GDB results: 3 0x712a65e0 4 0x712a6610 used_nodes_ = 53 5 0x3cf28 6 3 0x712a6610 4 0x712a6620 used_nodes_ = 54 5 0x3cf28 6 3 0x712a6620 4 0x712a6640 used_nodes_ = 55 5 0x3cf28 6 3...

I see a new z-way dev build (z-way-3.0.4-48-gbfd8c05_armhf.deb) was uploaded yesterday evening. Was there anything changed in regard to the stability problems?

Regards,

/Joakim

I noticed something in one of the log files which got me thinking: [2020-02-06 01:13:56.840] [I] [core] http://192.168.1.3:1025/ZWave?Cmd=CBck&Dev=%DEVICE%&Lev=%VALUE% : ZWayVDev_zway_6-1-50-2 : 0.6 : http://192.168.1.3:1025/ZWave?Cmd=CBck&Dev=ZWayVDev_zway_6-1-50-2&Lev=0.6 [2020-02-...

Ok thanks for pointing that out. Does the "gap" of silence also mean that the z-wave server is on some level locked as well since there seems to be no internal handling of z-wave data logged during this period of time either?