sensor tripping and untripping constantly from static Z-way device

Your second post arrived just as I was composing a reply… so not such good news indeed.

I find this surprising. The changes are minimal. Are you saying that NO device works, or just the lock?

I had to go to work before I could test beyond minimally, but it was a light that didn’t work. I didn’t get a chance to test the lock. I can do some more testing later today or tonight.

The condition seems to have arisen from a particular combination of ‘command codes’ presented by the door lock device. How long this has been happening, I don’t know. Did you, perhaps, upgrade the ZWay firmware recently?

What hardware device is that lock?

I really can’t see why the new version doesn’t run.

Any browser should give you the option of viewing the raw page data.

I’ll get some more information later today. It’s a Schlage BE469N lock. I’ve had it for a while - maybe a year. I haven’t updated Z-Way. I was considering it, but didn’t move to 2.3.6. I believe I’m on 2.3.5. I’ll check. I suppose it is possible that when I added the second lock, it updated something in Z-Way for both locks?

The very first line of the file has ‘module’ commented. I removed the ‘–’ and it is working much better. Z-Way is back alive and the overflow of logging has stopped. I’ll let it run overnight and see what it does. Thanks.

Aargh. Yes, I did that during testing. Will fix ASAP! Thanks.

This change incorporated in the latest ZWay GitHub commit 2018.03.16.

…reminds me of a programmer who once worked for me and said:

 [i]"I don't understand why it doesn't work... I only changed one line!"[/i]
1 Like

I’m curious as to the underlying issue. And any idea why it just started up for me? And why I am the only lucky winner of it? Anything I should monitor in the future? Thanks.

As I mentioned, the condition seems to have arisen from a particular combination of ‘command codes’ presented by the door lock device.

I’m re-thinking the way that the ZWay plugin represents devices. Part of the issue is that one ‘device’ can have many types of ‘alarm’, viz. Tamper, Motion, Security, … and trying to represent these without having a per-manufacturer database (which is a nightmare.) So I’m considering a v2 version of the plugin which will try less hard to make devices look like their Vera counterparts and more like the virtual devices in the ZWave.me Smarthome interface. This means having more, but less sophisticated virtual devices, but you would be able to group or hide them manually to keep things tidy.

But this is only just on the drawing-board. I’m actually having too much fun at the moment adding a mail server, camera triggers, and some image handling into openLuup.

You mentioned adding a second lock?? This was the first I had heard of it. Not sure if that changed your system somehow. Anyway, I assume that things are still going OK.

Yes, I had added another door lock of the same type in roughly the time frame that the issues started, but it didn’t immediately start after that. And it didn’t go away after I removed that lock from the Z-wave network. But maybe the installation had a side effect.

The new v2 plugin seems better to me. There are features available in Z-way that I can’t use currently such as the double/triple tab on some switches to run scenes. Z-way is cluttered, but I prefer to have access to all features if that is the trade off.

I’m going to try the camera code. That could be useful for me. Thanks.

Tested this and wanted to let you know that in my case it was a problem with z-way’s API. I had a sensor behaving the same way with a variable which was in an odd state. I ended up manually tripping the device and let it untrip. The behavior stopped.

1 Like