forum

Posted: **06 Jun 2014 18:46**

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.

Posted: **07 Jun 2014 13:28**

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

Posted: **08 Jun 2014 01:30**

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.

Posted: **09 Jun 2014 16:42**

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?

Posted: **09 Jun 2014 23:17**

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.

forum

Proper way to handle removing devices

Proper way to handle removing devices

Re: Proper way to handle removing devices

Re: Proper way to handle removing devices

Re: Proper way to handle removing devices

Re: Proper way to handle removing devices