I’ve had the cron scheduled to restart the z-way-server in order workaround the terrible memory leak.
Today, I noticed that my z-way-server process was not running for some weird reason.
I tried to relaunch the z-way-server manually.
I checked with ps, still no server process running.
I read the end of /var/log/z-way-server.log :
[2014-09-23 09:13:13.406] [21] 255
[2014-09-23 09:13:13.406] ---------------------------
[2014-09-23 09:13:13.406] Initialization done
[2014-09-23 09:13:13.406] Job 0x07 (Get controller info and supported function classes): success
[2014-09-23 09:13:13.406] Device is not compatible. Terminating...
[2014-09-23 09:13:13.406] Removing job: Get controller info and supported function classes
[2014-09-23 09:13:13.417] Worker thread exit point
[2014-09-23 09:13:13.417] Worker thread successfully finished
I rebooted the device from my shell access. Same thing. “Device is not compatible.”
I unplugged and replugged the power supply. That helped, now the device is compatible again.
"Device is not compatible" anymore. Cold reboot helps.
Re: "Device is not compatible" anymore. Cold reboot helps.
This means some trash came from the RaZberry board. This can happen if you reboot RPi, but not RaZ. Either reboot RaZ too, or don't reboot RPi.
By the way, what is the source of your memory leaks? We have solved all of them so far. At least valgrind was happy with Z-Way
What is your version?
By the way, what is the source of your memory leaks? We have solved all of them so far. At least valgrind was happy with Z-Way

Re: "Device is not compatible" anymore. Cold reboot helps.
Thanks for your reply. I'm sorry for delayed response, I had not activated notifications for replies, now they are on.
I'm confused and new to this, could you please enlighten me how to reboot RaZ? Could it be added to the init script of z-wave-server? I have obviously missed something.
I'm confused and new to this, could you please enlighten me how to reboot RaZ? Could it be added to the init script of z-wave-server? I have obviously missed something.
Re: "Device is not compatible" anymore. Cold reboot helps.
And by the way, my version is now 1.7.2, but I think I was running an older version by the time I had the memory leak troubles. They might be gone now.
I'm still suffering of stability issues though. It might be influenced by my extensive polling (which certainly is not recommended, I'm trying to get rid of it). The consequence is however the state which I don't know how to recover from without a cold reboot (Device is not compatible. Terminating).
I'm still suffering of stability issues though. It might be influenced by my extensive polling (which certainly is not recommended, I'm trying to get rid of it). The consequence is however the state which I don't know how to recover from without a cold reboot (Device is not compatible. Terminating).
Re: "Device is not compatible" anymore. Cold reboot helps.
What is the date written on the RaZberry? May be you will need to exchange it.
Re: "Device is not compatible" anymore. Cold reboot helps.
It's tagged 02.06.2014
Re: "Device is not compatible" anymore. Cold reboot helps.
By the way, it had crashed on Saturday again.
I've changed to log level to 2, here's the end of the output (including a startup attempt of today)
[2014-10-25 10:15:55.267] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:15:55.270] Job 0x13 (Wakeup Sleep): Cancelling job: Wakeup Sleep
[2014-10-25 10:15:55.270] Removing job: Wakeup Sleep
[2014-10-25 10:15:55.271] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:15:55.274] Adding job: Wakeup Sleep
[2014-10-25 10:15:55.440] Job 0x13 (Wakeup Sleep): Delivered
[2014-10-25 10:15:55.445] Removing job: Wakeup Sleep
[2014-10-25 10:16:03.395] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:16:03.398] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:17:16.233] Node 9:0 CC MultiChannel: Received CC 0x3a command from instance 3, but it isn't registered, creating it
[2014-10-25 10:17:16.279] Trying to create command for unknown CC 0x3a
[2014-10-25 10:17:16.280] Command Class 0x3a is not supported (requested for node 9:3)
[2014-10-25 10:17:16.283] Error returned from _zway_cc_call_handler(zway, cmd, node_id, data[3], length - 4, &data[4]): Bad arguments (-1)
[2014-10-25 10:17:29.137] Node 5:35 CC Meter: Unsupported Meter scale 1 received
[2014-10-25 10:18:56.628] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:18:56.642] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:19:10.918] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:19:10.925] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:24:14.814] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:24:14.843] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:26:11.233] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.236] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.247] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.247] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.258] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.258] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.332] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:26:11.338] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:26:11.340] Adding job: Wakeup Sleep
[2014-10-25 10:26:11.351] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:26:11.352] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:26:26.920] Job 0x13 (Wakeup Sleep): Not delivered to recipient
[2014-10-25 10:26:26.980] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-25 10:26:26.991] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-25 10:26:27.002] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-27 08:29:22.500] Adding job: Get controller info and supported function classes
[2014-10-27 08:29:23.733] Unhandled request for function class 0x04
[2014-10-27 08:29:23.744] Unhandled request for function class 0x04
[2014-10-27 08:29:23.754] Unhandled request for function class 0x04
[2014-10-27 08:29:23.792] Get Serial API Capabilities returned zero.
[2014-10-27 08:29:23.792] Removing job: Get controller info and supported function classes
Of course, I cannot access the expert ui to restart the z-wave chip, since the z-way-server fails to start up. Is there any other way to boot the chip?
This crash has happened without using any automation rules (such as sensor polling). Previously I suspected them for causing the instability.
I've changed to log level to 2, here's the end of the output (including a startup attempt of today)
[2014-10-25 10:15:55.267] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:15:55.270] Job 0x13 (Wakeup Sleep): Cancelling job: Wakeup Sleep
[2014-10-25 10:15:55.270] Removing job: Wakeup Sleep
[2014-10-25 10:15:55.271] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:15:55.274] Adding job: Wakeup Sleep
[2014-10-25 10:15:55.440] Job 0x13 (Wakeup Sleep): Delivered
[2014-10-25 10:15:55.445] Removing job: Wakeup Sleep
[2014-10-25 10:16:03.395] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:16:03.398] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:17:16.233] Node 9:0 CC MultiChannel: Received CC 0x3a command from instance 3, but it isn't registered, creating it
[2014-10-25 10:17:16.279] Trying to create command for unknown CC 0x3a
[2014-10-25 10:17:16.280] Command Class 0x3a is not supported (requested for node 9:3)
[2014-10-25 10:17:16.283] Error returned from _zway_cc_call_handler(zway, cmd, node_id, data[3], length - 4, &data[4]): Bad arguments (-1)
[2014-10-25 10:17:29.137] Node 5:35 CC Meter: Unsupported Meter scale 1 received
[2014-10-25 10:18:56.628] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:18:56.642] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:19:10.918] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:19:10.925] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:24:14.814] Packet CC::METER_REPORT is too short: required at least 14 bytes, got 12
[2014-10-25 10:24:14.843] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Wrong packet from Z-Wave network or Discovery got bad data (stick communication failed) (-9)
[2014-10-25 10:26:11.233] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.236] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.247] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.247] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.258] Node 8:0 CC SensorBinary: Unknown command 0x02
[2014-10-25 10:26:11.258] Error returned from _zway_cc_call_handler(zway, command, controller->id, 0, data[4], &data[5]): Not implemented by the library (-3)
[2014-10-25 10:26:11.332] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:26:11.338] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:26:11.340] Adding job: Wakeup Sleep
[2014-10-25 10:26:11.351] Node 4:0 CC Wakeup: Wakeup notification
[2014-10-25 10:26:11.352] Node 4:0 CC Wakeup: Send node to sleep
[2014-10-25 10:26:26.920] Job 0x13 (Wakeup Sleep): Not delivered to recipient
[2014-10-25 10:26:26.980] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-25 10:26:26.991] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-25 10:26:27.002] SendData callback Id is invalid: 0xc8! Probably too late
[2014-10-27 08:29:22.500] Adding job: Get controller info and supported function classes
[2014-10-27 08:29:23.733] Unhandled request for function class 0x04
[2014-10-27 08:29:23.744] Unhandled request for function class 0x04
[2014-10-27 08:29:23.754] Unhandled request for function class 0x04
[2014-10-27 08:29:23.792] Get Serial API Capabilities returned zero.
[2014-10-27 08:29:23.792] Removing job: Get controller info and supported function classes
Of course, I cannot access the expert ui to restart the z-wave chip, since the z-way-server fails to start up. Is there any other way to boot the chip?
This crash has happened without using any automation rules (such as sensor polling). Previously I suspected them for causing the instability.
Re: "Device is not compatible" anymore. Cold reboot helps.
From now on, I will continue to run the tests with a RaZberry dated 08.08.2014 hoping that the hardware has been improved. I'll keep you updated about the crashes.PoltoS wrote:What is the date written on the RaZberry? May be you will need to exchange it.