OpenZWave / python-openzwave

Python wrapper for openzwave
Other
200 stars 141 forks source link

Distinguish add_node / remove_node mode #6

Open m0rphi opened 9 years ago

m0rphi commented 9 years ago

Hi,

I tried to distinguish if the controller is in add_node mode (also called include mode) or in remove_node mode (exclude mode). In the debug logs from python-openzwave, it seems to be there is the same callback information for both function, First picture shows the add_node, second the remove_node function pyozw_add_device pyozw_remove_device

Here the relevant part: _addnode DEBUG Z-Wave ControllerCommand : {'controllerState': 'Starting', 'controllerError': 'None', 'controllerErrorInt': 0, 'notificationType': 'ControllerCommand', 'nodeId': 0, 'controllerStateInt': 1, 'controllerErrorDoc': 'None.', 'homeId': 23197916L, 'controllerStateDoc': 'The command is starting.'} DEBUG Z-Wave ControllerCommand : {'controllerState': 'Waiting', 'controllerError': 'None', 'controllerErrorInt': 0, 'notificationType': 'ControllerCommand', 'nodeId': 0, 'controllerStateInt': 4, 'controllerErrorDoc': 'None.', 'homeId': 23197916L, 'controllerStateDoc': 'Controller is waiting for a user action.'}

_removenode DEBUG Z-Wave ControllerCommand : {'controllerState': 'Starting', 'controllerError': 'None', 'controllerErrorInt': 0, 'notificationType': 'ControllerCommand', 'nodeId': 0, 'controllerStateInt': 1, 'controllerErrorDoc': 'None.', 'homeId': 23197916L, 'controllerStateDoc': 'The command is starting.'} DEBUG Z-Wave ControllerCommand : {'controllerState': 'Waiting', 'controllerError': 'None', 'controllerErrorInt': 0, 'notificationType': 'ControllerCommand', 'nodeId': 0, 'controllerStateInt': 4, 'controllerErrorDoc': 'None.', 'homeId': 23197916L, 'controllerStateDoc': 'Controller is waiting for a user action.'}

When you compare both picture, the callback is the same, so I don´t know in which mode the z-wave chip is.

In openzwave logs, there is some difference between add_node and remove_node function ozw_add_device ozw_remove_device

Maybe there is another way to find out in python-openzwave in which mode the chip is, but I didn´t find it yet ;)

my system: OS: Linux Mint 17 32 Bit 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:31:42 UTC 2014 i686 i686 i686 GNU/Linux python-openzwave commit: b4476e27c9 Python: Python 2.7.6 (default, Mar 22 2014, 22:59:38) [GCC 4.8.2] cython -V: Cython version 0.20.1post0 HW: Z-Wave Aeotec Z-Stick S2

bibi21000 commented 9 years ago

You're right. There is actually no way to retrieve the command from notification. Openzwave library seems not returning it in notification (or I've not found a way to get it) : https://github.com/OpenZWave/open-zwave/blob/a11616144bbac2c890a230e18f24cb12894ce49c/cpp/src/Driver.cpp#L5432 I can only get a controller_state and a controller_error : https://github.com/OpenZWave/open-zwave/blob/a6703f1b50558bc9ce0d1b96bd7fc36dd42a7cec/cpp/src/Driver.h#L483 But not the command which generate it.

So actually you need to "save" the last sent command in a "flag". For me, it's not a good way to do it, that's why I don't implement it. Keep in mind in that user (in dynamic mode with .so modules) can launch an instance of a python program AND an instance of ozwcp for example. Maybe there must have some work in c++ library to retrieve the way begin_controller_controller was working. I don't have the time to look at it further more in the next weeks (will be on holidays at the end of next week). So if you're interest in you speak about that on openzave c++ group on google ... or simply use a flag. Hope this helps

m0rphi commented 9 years ago

Thanks bibi, the knowledge if the command was an include or exclude is somehow important, I think. Right now I am saving a flag for the include/exclude mode. I found out that openzwave has an interesting behaviour when execute include (add_node) /exclude command (remove_node) multiple times. It queues e.g. all include commands and when cancel the commands, it cancel only the last include..

For me it´s more comfortable to execute one include command and throw away all other include commands in that time the chip is in include mode.(same for exclude command) . So I have to cancel only once the same command, otherweise the chip could be stuck in include mode all the time. And this state nobody wants to have ;)