Z-way server goes down spontaneously

[kimifish]

Hello. Have RaspberryPi 3 + Razberry board, Raspbian Stretch + Z-way-server 2.3.8 (+ openHAB).
After upgrade z-way-server to 2.3.8 the server began to spontaneously go down:

Code: Select all

pi@raspberrypi:~$ systemctl status z-way-server.service
● z-way-server.service - LSB: RaZberry Z-Wave service
   Loaded: loaded (/etc/init.d/z-way-server; generated; vendor preset: enabled)
   Active: active (exited) since Sat 2019-02-23 18:08:11 MSK; 22h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 23450 ExecStop=/etc/init.d/z-way-server stop (code=exited, status=0/SUCCESS)
  Process: 23467 ExecStart=/etc/init.d/z-way-server start (code=exited, status=0/SUCCESS)

фев 23 18:08:11 raspberrypi systemd[1]: Starting LSB: RaZberry Z-Wave service...
фев 23 18:08:11 raspberrypi z-way-server[23467]: Starting z-way-server: done.
фев 23 18:08:11 raspberrypi systemd[1]: Started LSB: RaZberry Z-Wave service.

I assume, this status means that daemon no longer active for some indefinite time.
Log doesn't say anything bad to me:

Code: Select all

pi@raspberrypi:~$ tail -n 25 /var/log/z-way-server.log
[2019-02-24 15:33:23.838] [I] [core] Request was successful
[2019-02-24 15:33:24.141] [D] [zway] Job 0x13: deleted from queue                               
[2019-02-24 15:33:24.314] [D] [zway] Job 0x13: deleted from queue                               
[2019-02-24 15:33:24.476] [D] [zway] Job 0x13: deleted from queue                               
[2019-02-24 15:40:00.842] [I] [core] ---  OpenWeatherDaylight_23 performCommand processing: {"0":"update"}
[2019-02-24 15:40:14.934] [D] [zway] RECEIVED: ( 01 0A 00 04 00 02 04 30 03 FF 0A 31 )          
[2019-02-24 15:40:14.935] [D] [zway] SENT ACK
[2019-02-24 15:40:14.936] [D] [zway] SETDATA devices.2.data.lastReceived = 0 (0x00000000)
[2019-02-24 15:40:14.937] [D] [zway] SETDATA devices.2.instances.0.commandClasses.48.data.10.level = True
[2019-02-24 15:40:14.938] [D] [zway] SETDATA devices.2.instances.0.commandClasses.48.data.10 = Empty
[2019-02-24 15:40:14.954] [D] [zway] RECEIVED: ( 01 0F 00 04 00 02 09 71 05 00 00 00 FF 06 16 00 64 )
[2019-02-24 15:40:14.955] [D] [zway] SENT ACK
[2019-02-24 15:40:14.957] [D] [zway] SETDATA devices.2.data.lastReceived = 0 (0x00000000)
[2019-02-24 15:40:14.957] [D] [zway] SETDATA devices.2.instances.0.commandClasses.113.data.6.eventParameters = byte[0]
[2019-02-24 15:40:14.958] [D] [zway]   ( zero-length buffer )
[2019-02-24 15:40:14.959] [D] [zway] SETDATA devices.2.instances.0.commandClasses.113.data.6.event = 22 (0x00000016)
[2019-02-24 15:40:14.963] [D] [zway] SETDATA devices.2.instances.0.commandClasses.113.data.6.eventString = "Window/door is open"
[2019-02-24 15:40:14.964] [I] [core] (Mobile App Support) Notify listener (EventForwarding): "Door opened"
[2019-02-24 15:40:14.965] [D] [zway] SETDATA devices.2.instances.0.commandClasses.113.data.6.status = 255 (0x000000ff)
[2019-02-24 15:40:14.966] [D] [zway] SETDATA devices.2.instances.0.commandClasses.113.data.6 = Empty
[2019-02-24 15:40:14.973] [I] [core] Notification: device-info (device-OnOff): {"dev":"Задняя дверь","l":"on","location":1}
[2019-02-24 15:40:14.975] [I] [core] http://10.8.0.3:8765/set?title=%DEVICE%&message=%VALUE% : ZWayVDev_zway_2-0-48-10 : on : http://10.8.0.3:8765/set?title=ZWayVDev_zway_2-0-48-10&message=on 
[2019-02-24 15:40:15.061] [I] [core] Notification: device-info (device-OnOff): {"dev":"Задняя дверь Access Control Alarm","l":"on","location":1}era
[2019-02-24 15:40:15.063] [I] [core] http://10.8.0.3:8765/set?title=%DEVICE%&message=%VALUE% : ZWayVDev_zway_2-0-113-6-Door-A : on : http://10.8.0.3:8765/set?title=ZWayVDev_zway_2-0-113-6-Door-A&message=on
[2019-02-24 15:40:15.094] [I] [core] [BaseModule-17] Set lastLevel to on for ZWayVDev_zway_2-0-48-10 (was off)

Web-interface and Android app don't work/connect either.
Service restart does nothing, but if i command systemctl to stop and then start service, it goes up for some time (2-10 hours) and repeats.
Can somebody tell me, where and how to find a solution? Because now I have no idea.

Also, I have a suspicion that this is somehow connected with the smart switch toggling, but all my attempts to reproduce it after the service restart failed.

[PoltoS]

It might be that your http requests lead to those crashes. We can try to debug it based on your case if you allow us.

[kimifish]

It might be that your http requests lead to those crashes. We can try to debug it based on your case if you allow us.

Sure, what do i need to do for this?
By the way, maybe we could switch to russian?

[brusan]

Just to save you guys some time, I assume you'd have to enable remote Support Access like:

remote_access.PNG (13.34 KiB) Viewed 21420 times

[brusan]

Кстати, не переключайтесь на русский язык, информация не будет полезна для других //brusan

[z-wavettaja]

It might be that your http requests lead to those crashes. We can try to debug it based on your case if you allow us.

Did you found any resolution on this? It seems that http requests lead same kind of crashes here. If I enable HTTPget app to make http requests, system might crash maybe once a day, or ten times at day. But like kimifish said, I'm also unable to reprocedure crash by mean.
If I disable http requests again, installation seems to be stable again.

[PoltoS]

Which version? We have found few potential places recently. Bee version will fix them.

[z-wavettaja]

Which version? We have found few potential places recently. Bee version will fix them.

v2.3.8
I also found out that my server uses https and this is what causes crasches.
Using http insted, while keeping other configs unchanged seems to work.

[PoltoS]

Your notice about HTTP vs HTTPS Sounds interesting. Can you confirm this correlation? We have never noticed this a d most of our tests were with HTTP only

[z-wavettaja]

Yes I can. I have switched few times between http and https. With http it have been running days without any crashes, but if I switch to https (without any other config changes on zwave and and same web server), it will quite surely crash during the first day.