2.3.0 and Schlage Lock

Discussions about existing Z-Wave device and their usage with Z-Way/Z-Cloud/Z-Box
jadedeane
Posts: 29
Joined: 31 Jul 2016 23:14

Re: 2.3.0 and Schlage Lock

Post by jadedeane » 24 Feb 2017 22:04

Having similar issues with the Niffler module that worked with 2.2.5, albeit on GE switches. Should I follow-up here, or open a new forum thread and or Git issue?

Will Z-Way eventually provide the same NIF workaround that the Niffler module did prior to 2.3.0?

Original issue that led me to discover Niffler documented here: https://forum.z-wave.me/viewtopic.php?f ... r&start=10. The other issue in that thread, namely the bug with get/set was resolved.

jadedeane
Posts: 29
Joined: 31 Jul 2016 23:14

Re: 2.3.0 and Schlage Lock

Post by jadedeane » 28 Mar 2017 06:42

Bump. Is there any resolution for Niffler, or roadmap for NIffler-like support...?

silverhack
Posts: 32
Joined: 23 May 2016 21:41

Re: 2.3.0 and Schlage Lock

Post by silverhack » 13 Apr 2017 05:51

I -think- I'm experiencing the same type of problem with my Kiwkset 916 lock and wanted to add some additional information that I discovered through testing.

If I manually turn the lever on the deadbolt, the device reports the status change and I get the notification and the state is correctly updated in SmartHome UI (both in Events and as the element status). This seems to work very well and regularly.

If I use Z-way to lock or unlock the device (using SmartHome UI or the iPhone app) then the device does change state, but the Notification does not happen and the state change is not reported in UI. However, if I do the same operation in Z-way again, then the Notification happens. Example: Door is locked, press unlock in UI, wait 4-5 seconds and press unlock again and then the Notification happens and I see the event in UI and the element changes in UI as well.

Here is what I monitored using
sudo tail -f /var/log/z-way-server.log | grep -i core

Lock started in Closed state, and I had to press open twice (4-5 seconds in between presses) for the notification to occur.

Code: Select all

[2017-04-12 19:38:58.525] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:00.444] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:02.980] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:11.573] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"open","1":{}}
[2017-04-12 19:39:19.513] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"open","1":{}}
[2017-04-12 19:39:21.606] [I] [core] Notification: device-info (device-OnOff): {"dev":"Front Door","l":"open"}
[2017-04-12 19:39:21.707] [I] [core] [BaseModule-22] Set lastLevel to open for ZWayVDev_zway_57-0-98 (was close)
[2017-04-12 19:39:28.969] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:33.962] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:38.947] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:41.014] [I] [core] Notification: device-info (device-OnOff): {"dev":"Front Door","l":"close"}
[2017-04-12 19:39:41.053] [I] [core] [BaseModule-22] Set lastLevel to close for ZWayVDev_zway_57-0-98 (was open)
[2017-04-12 19:39:51.164] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:52.641] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:54.021] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:55.844] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}
[2017-04-12 19:39:57.170] [I] [core] ---  ZWayVDev_zway_57-0-98 performCommand processing: {"0":"close","1":{}}

silverhack
Posts: 32
Joined: 23 May 2016 21:41

Re: 2.3.0 and Schlage Lock

Post by silverhack » 14 Apr 2017 02:22

Did some more testing and put a hack in place that resolved the problem for me. I noticed that when the lock state is changed, a Set() and Get() is added to the queue but the Get() seems be coming too early for my scenario, so I hacked in another Get() 8 seconds after the state change and now the Notification is received and processed correctly.

in Zwave/index.js I added to the handler:
setTimeout(function(){ console.log("##### Hack to get door lock status 8 seconds after change ####"); cc.Get(); }, 8000);

Code: Select all

else if (this.CC["DoorLock"] === commandClassId && !self.controller.devices.get(vDevId)) {

	defaults = {
			deviceType: 'doorlock',
			metrics: {
					level: '',
					icon: 'door',
					title: compileTitle('Door Lock', vDevIdNI)
			}
	};

	// apply postfix if available
	if (changeVDev[changeDevId]) {
			defaults = applyPostfix(defaults, changeVDev[changeDevId], vDevId, vDevIdNI);
	}

	var vDev = self.controller.devices.create({
			deviceId: vDevId,
			defaults: defaults,
			overlay: {},
			handler: function(command) {
					if ("open" === command) {
							cc.Set(0);
					} else if ("close" === command) {
							cc.Set(255);
					}
					setTimeout(function(){ console.log("##### Hack to get door lock status 8 seconds after change ####");  cc.Get(); }, 8000);
			},
			moduleId: self.id
	});


Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest