Proper way to handle removing devices

Discussions about Z-Way software and Z-Wave technology in general
Post Reply
enco.josh
Posts: 35
Joined: 10 Mar 2014 22:10

Proper way to handle removing devices

Post by enco.josh »

I am able to detect a zway structure change and more specifically when a device is removed. Each device has a generic VirtualDevice class that is similar to the one you have provided. I bind to certain properties and save those in a _propertyBindings variable. Is it sufficient enough to just unbind those properties when I delete it?

What is the proper procedure for removing a device? I want to eliminate any memory leaks that results from a removed device.

I create the device using

Code: Select all

var newVirtualDevice = new VirtualDevice(virtualDevice.id, virtualDevice.type);
and I detect the structure changes using

Code: Select all

zwayBinding = zway.bind(function (type, nodeId, instanceId, commandClassId) {
	if (type === ZWAY_DEVICE_CHANGE_TYPES["DeviceAdded"]) {
		console.log("Device Added " + nodeId);
	} 
	else if (type === ZWAY_DEVICE_CHANGE_TYPES["DeviceRemoved"]) {
			console.log("Device Removed " + nodeId);
	}
}, ZWAY_DEVICE_CHANGE_TYPES["DeviceAdded"] | ZWAY_DEVICE_CHANGE_TYPES["DeviceRemoved"]);
What code should properly destroy the device? I understand that javascript classes do not inherently have a destructor class. Assuming I can obtain a reference to the newVirtualDevice object that was created above. Is the proper way just to

Code: Select all

newVirtualDevice.unbindDataPoints(); //this routine unbinds all datapoint bindings
newVirtualDevice = null;
TIA. I am just trying to properly destroy the object without memory leaks.
User avatar
PoltoS
Posts: 7571
Joined: 26 Jan 2011 19:36

Re: Proper way to handle removing devices

Post by PoltoS »

The ZWaveGate module you are citing does this. Isn't it enough for you?

Or you want to create and destroy your own vDev?

Before destroying the object unbind from zway objects
pofs
Posts: 688
Joined: 25 Mar 2011 19:03

Re: Proper way to handle removing devices

Post by pofs »

If the actual ZWave device is removed (i.e. you get ZWAY_DEVICE_CHANGE_TYPES["DeviceRemoved"]), all the data holders are destroyed. And when a data holder is destroyed, all the existing bindings for it are also destroyed automatically. So you don't actually need to unbind if the device is removed.

But if you're destroying a JS device object at some point without the actual device being deleted, you'd need to unbind data bindings.

But, as PoltoS said, why bother creating your own device if they're maintained automatically by ZWaveGate module.
enco.josh
Posts: 35
Joined: 10 Mar 2014 22:10

Re: Proper way to handle removing devices

Post by enco.josh »

I am currently developing with a very limited number of ZWave devices for private (not end-user) use. I have no need for most of the modules that have already been created. I am just tweeking the ZWaveGate module for my needs. If I understand correctly, there is no need to unbind the datapoints from devices that have been physically removed? In fact, by the time that the device is removed, the dataholder is already deleted and I would get an error if I did try to reference those.

On the other hand, I want to dynamically create virtual devices as devices are added to the network. How could I detect that the device is done interviewing? I see that each command class has an interviewDone parameter, but I can't use that unless I know that there are no more new command classes for the device. What is the proper way to detect when a device's interview process has completed?
pofs
Posts: 688
Joined: 25 Mar 2011 19:03

Re: Proper way to handle removing devices

Post by pofs »

enco.josh wrote: I see that each command class has an interviewDone parameter, but I can't use that unless I know that there are no more new command classes for the device. What is the proper way to detect when a device's interview process has completed?
All supported command classes are created before interview starts, so for supported command classes it is not possible new ones to appear.
As for controlled command classes, they may be rendered at any point of time. But they're never interviewed, so you don't need to wait for interviewDone.

Also not sure that device should complete interview to be created. Some defective devices never pass interview completely, but they're still able to function.
Post Reply