forum

After multiple tests, analyzes ... I still have the same problems with the fibaro motion sensor.

I would restart with a blank configuration of z-way-server/razberry. But after deleting the directory "/opt/z-way-server" device numbers continue the sequence, it does not restart the numbering to 2 (Razberry has number 1).
How do I reset the configuration of the Razberry?

fredaim wrote:But after deleting the directory "/opt/z-way-server" device numbers continue the sequence, it does not restart the numbering to 2 (Razberry has number 1).
How do I reset the configuration of the Razberry?

Device numbering is maintained by Z-Wave controller itself, not by the software. You should reset the controller to restart numbering sequence (there's a Reset Controller button in expert UI).

One quick question, If I exclude a device (example 23) and then include it again (without resetting the controller or the device), will it get back ID 23 or a new ID 24. I ask this question because if you add Fibaro Door/Window Sensors and then later want to add the Temperature Sensor, you have to exclude the device, install the temperature sensors and include the device once again.

sdh wrote:One quick question, If I exclude a device (example 23) and then include it again (without resetting the controller or the device), will it get back ID 23 or a new ID 24. I ask this question because if you add Fibaro Door/Window Sensors and then later want to add the Temperature Sensor, you have to exclude the device, install the temperature sensors and include the device once again.

It increases every time, so it will be 24.

About Fibaro Motion Sensor
I see different problems

1) in blue UI the sensors maybe missing complete (device is there, but sensors are missing)
In same time the sensor is available in mobile UI

2) the "Seismograph" - sensor must be enabled at first in Fibaro device. It must be configured via "TAMPER OPERATING MODES" - value 4 must be set (little bit funny place for my understanding).
Fibaro told me that it is disabled by default is a "product feature".

About 1) - have no idea, why this happen - no JS error is visible

About 2) - we have checked in Log - it seems there is any error in command / protocol
as sample:
[2014-05-13 13:11:34.507] RECEIVED: ( 01 0D 00 04 00 09 07 60 0D 02 02 FF 00 00 6A )
[2014-05-13 13:11:34.508] SENT ACK
[2014-05-13 13:11:34.513] SETDATA devices.9.data.lastReceived = 0 (0x00000000)
[2014-05-13 13:11:34.515] Node 9:0 CC MultiChannel: Received CC 0xff command from instance 2, but it isn't registered, creating it
[2014-05-13 13:11:34.517] Trying to create command for unknown CC 0xff
[2014-05-13 13:11:34.519] Command Class 0xff is not supported (requested for node 9:2)
[2014-05-13 13:11:34.521] Error returned from _zway_cc_call_handler(zway, cmd, node_id, data[3], length - 4, &data[4]): Bad arguments (-1)

Somebody else have same or other effect when using the seismograph?

michap wrote:we have checked in Log - it seems there is any error in command / protocol
as sample:
[2014-05-13 13:11:34.507] RECEIVED: ( 01 0D 00 04 00 09 07 60 0D 02 02 FF 00 00 6A )
[2014-05-13 13:11:34.508] SENT ACK
[2014-05-13 13:11:34.513] SETDATA devices.9.data.lastReceived = 0 (0x00000000)
[2014-05-13 13:11:34.515] Node 9:0 CC MultiChannel: Received CC 0xff command from instance 2, but it isn't registered, creating it
[2014-05-13 13:11:34.517] Trying to create command for unknown CC 0xff
[2014-05-13 13:11:34.519] Command Class 0xff is not supported (requested for node 9:2)
[2014-05-13 13:11:34.521] Error returned from _zway_cc_call_handler(zway, cmd, node_id, data[3], length - 4, &data[4]): Bad arguments (-1)

Somebody else have same or other effect when using the seismograph?

0xFF is really an invalid command class id, there's no such CC defined at all. Probably there's an error in sensor firmware, and it is sending some kind of bullshit data.

I have z-way-server v.1.7.0-rc3 running and it seems like it has a serious memory leak.
At first, I simply thought it would require more RAM as my raspberry pi began to swap.
Therefore, I replaced my old raspberry with 256MB RAM with a new one with 512MB.
The server worked ok but after having it running for a full day, things went erratic again - until the server is unreachable.
After a full day of operation, the process z-way-server has (taken from "top") 589M VIRT and 124M RES which is a HUGE HUGE amount of memory.
Probably there is a bug with the new http-request feature of the server.
I am using this custom code for all of my nodes:

function NodeNotifier(nodeID, value)
{
var pushstring = 'NID=' + nodeID + '&VAL=' + value;
debugPrint("NodeNotifier: " + pushstring);
http.request({ method:'GET', url:'127.0.0.1:8888/push&' + pushstring });
}

// example for one of my motion detectors
try { zway.devices[3].instances[0].commandClasses[48].data[1].level.bind( function() { NodeNotifier('3:0', this.value); } ); } catch (e) { debugPrint('\nERROR: Failed to bind to zway.devices[3].instances[0].commandClasses[48].data[1].level!\n'); }

Probably, the http requests do have some unknown side effects.
I would be very happy if you could reproduce my problem and if you could provide a fix.
Currently, I have to reboot the server every night - otherwise the system crashes after around 1.5 days...

Many thanks in advance!!

Could you please try to turn off http.request and see if leaks stops?

@Tiptop: https://github.com/Z-Wave-Me/z-way-issues/issues/3

We will include the fix in next version

Wow, very cool!
When can I expect to get my hands on the bugifx?
It would REALLY help me to get my system stable, again.
Many many thanks again for your quick help!