Manually hack devices config - is this possible?

Discussions about RaZberry - Z-Wave board for Raspberry computer
Post Reply
Posts: 39
Joined: 02 Nov 2012 14:53

Manually hack devices config - is this possible?

Post by klirichek »

I have two similar wall switches
(bought at the same time, have same ver/sdk)
The problem is that one of them is reported as battery powered, but another not.
So, for one switch z-way postpone all the commands, and sent them on awaking, but for another it tries to sent them immediatelly, which results in 'broken' icon and trying to delete the device from the meshwork on reload (however device itself doesn't know that it is 'broken' and still work according to it's direct assotiations, only command sent to controller is failed this case). Exclusion/reinclusion/reinrerview (tried several times) don't work.

I've found the sections of both devices in /opt/z-way-server/config/zddx/xxxxxxxx-DevicesData.xml and compared them. Two differences (apart from timestamps) are
1). one (good) device has 'isListening=false'. Second has 'isListening=true'. As I can guess, this is the very reason why z-way tries to send any command immediatelly.
2) one (good) has 'optional=true'. Second has 'optional=false'. Dont know what does it mean, it seems to be not important for this very issue.

The thing which I tried to perform is
1) /etc/init.d/Z-Way stop
2) open the config file with vim and try to manually edit this 'true' to 'false'
3) /etc/init.d/Z-Way start

However it was not successfull. It seems that on shutdown Z-Way tries to ask devices and mark the wrong one as 'broken'. And after restart it doesn't try to ask this broken device anymore (just asked to remove it from the map).

So, I don't see any way right now how to perform such hacking.
Does it possible to do it on live daemon? (if I edit the config and force it to reload - will it work? How to do that?)

User avatar
Posts: 5677
Joined: 26 Jan 2011 19:36

isListening is the reason.

Post by PoltoS »

isListening is the reason.

Your hacking was correct in general, but this particular value is requested from the stick each time.
The problem is certainly caused by some problem during inclusion. Try to exclude-include the device.

Post Reply