Adding ZOOZ ZEN17 challenges

[oskrypuch]

I am adding a ZOOZ ZEN17. Purpose is to capture the status of two garage doors, each has a magnetic contact. This will be replacing an IOLinc.

I have it set to what I think I need (dry cell contact detection for door open/close sensors p2 & p3 = 7), and disabled the relay drive for the switch for good measure, so no more clicking on shorting the contacts. I can see activity on the event viewer when I short one contact, and then the other, which may be what I'm looking for, at least shows that I'm close ...

But not sure how to pick this toggle up in a program. Despite the activity, I don't see any changes on the screen for any of the nodes.

Here are the nodes that popped up:

It says:

... you'll need to exclude and re-include the device so that a child device is created for the input of your choice.

OK, that kind of makes sense, the missing link, the missing nodes -- but I am looking all over for an exclude/include toggle, can't find it. Does that just mean to remove the switch from the network, and re-add it? I know this is basic Z-Wave, but thanks to anyone for help.

Unlike in the docs, there is no Remove/Exclude option in this menu.

And nothing on the device context menu.

Is it perhaps the Add/Refresh button nodes? I did try it without luck.

* Orest

 

 

 

[oskrypuch]

Well, that is what I did, I removed the device altogether, and then added it, and up came two more nodes. Named them SW1 & SW2.

Is Z-Wave "exclude" not implemented yet on the Polisy? (so remove/install is the next best thing)

* Orest

[oskrypuch]

For anyone familiar with the ZEN17, I was unable to turn off the relay driving (p10 & p11), if I did that then there would be no sensing provided on the SW1 & SW2 labelled nodes, at least on the p2=10 & p3=10 settings.

I don't need the relays triggered, but I guess the click will make no difference in the garage.

* Orest

[oskrypuch]

OTOH, that would mean that the relays would remain (uselessly) energized virtually 100% of the time. Wonder if they are rated constant duty?

It would be better to make them work as they are supposed to!

* Orest

[peterathans]

I am actually using the Zen17 to do the same thing, and set it up the same way (including disassociating the relay from the input).  I also configured it to operate as a door/barrier monitor, and it gave a new node of "ZW 004.1 Barrier 1", which reports a status of Open or Closed.  That's the status I'm using in my program logic.

[brians]

The instructions that come with with zen17 tell you the parameter how to isolate the inputs and that that you have to exclude include again and extra nodes appear. I have two running like this with no issues. 

[brians]

I looked up my notes:

1. parameter 2 and parameter 3 to 10 (on/off dry contact sensor)

2. exclude/include via ISY controller and it added a couple extra nodes... binary sensor - use these for triggers in programs etc.

3. parameter 10 (and Parameter 11 if wanted) to 0 which does not require a remove/add (this isolates the relay triggered from the input)

 

From manual:

IMPORTANT: If you set this parameter to value
4-10, you’ll need to exclude and re-include the
device (without changing any settings) so that
a child device is created for the input of your
choice!

[oskrypuch]

Thanks!

I've been able to get it to trigger a change, but haven't been able to dissociate it from the relay triggering, without then suppressing that desired response.

But, now that I know it is possible, I'll give it another shot from scratch.

And, when you say exclude/include, do you mean just uninstall them? The Polisy/700 dongle doesn't have an exclude function it seems.

* Orest

[brians]

31 minutes ago, oskrypuch said:

Thanks!

I've been able to get it to trigger a change, but haven't been able to dissociate it from the relay triggering, without then suppressing that desired response.

But, now that I know it is possible, I'll give it another shot from scratch.

And, when you say exclude/include, do you mean just uninstall them? The Polisy/700 dongle doesn't have an exclude function it seems.

* Orest

Add remove or whatever isy calls it is same they just used different nomenclature. 

[DennisC]

12 hours ago, oskrypuch said:

Thanks!

I've been able to get it to trigger a change, but haven't been able to dissociate it from the relay triggering, without then suppressing that desired response.

But, now that I know it is possible, I'll give it another shot from scratch.

And, when you say exclude/include, do you mean just uninstall them? The Polisy/700 dongle doesn't have an exclude function it seems.

* Orest

In the screen shot a few post above: Remove a Z-Wave Device

[oskrypuch]

OK, one more try.

I removed the device, factory reset it for good measure, then re-added it.

P2 was 2, I changed it 10

P3 was 2, I changed it 10

Once again, I removed the device (excluded it), then re-added it.

I get these nodes. I shortened the "Switch" in the text label to Sw, so I had room to add my own descriptors.

The designated nodes will sense SW1 shorted or SW2, the first one actually ORs SW1 & SW2, it will be ON if either is shorted.

Relays click in concert, and can be controlled from the labelled pages on the ISY admin panel. The first two nodes will actually both show switch(es) shorted and allow you to control relay 1.

And, an odd collection of pages, on some the ON/OFF buttons do nothing, some just have a QUERY at the bottom. Kind of looks like an unfinished project!

 

THEN, the moment of truth ...

P10 is 2, changed it to 1

P11 is 2, changed it to 1

The relays can still be controlled as before ...

BUT now, there is no state change reflected on the SW-any, SW1 or SW2 pages. So, no longer any way to sense whether SW1 & SW2 are shorted.

@briansWhat am I doing wrong?

* Orest

[oskrypuch]

On 4/28/2022 at 3:09 PM, peterathans said:

I am actually using the Zen17 to do the same thing, and set it up the same way (including disassociating the relay from the input).  I also configured it to operate as a door/barrier monitor, and it gave a new node of "ZW 004.1 Barrier 1", which reports a status of Open or Closed.  That's the status I'm using in my program logic.

Which P2/P3 setting is "door/barrier", P2/P3= 7 ?

* Orest

[oskrypuch]

OK, that was a GREAT clue. Thanks @brians.

I set

P2 to 7

P3 to 7

exclude/include, then ...

That popped up a whole bunch of extra nodes, and the: Window Alarm 1 (11.1 & 11.2) reflect whether the contacts are shorted AND I can still disable the control of the relays.

Problem solved.

But, this Z-Wave node stuff is kind of a breadboard experiment.

And, kind of looks like you need a folder for all those nodes, to keep it a little tidier. Deleting the ones I'm not using doesn't seem to work, they pop right back.

* Orest

 

[brians]

You should have binary sensors for each input after setting the configuration parameters and exclude/include.

Weird that setting to 10 didn't show and 7 did which is a open/close alert. I am not sure what the functional difference is in all those settings 4-10 anyways.

It could also have been a second exclude/include fixed - I have seen this with some z-wave devices.

 

 

[oskrypuch]

The p2/3=4-10 setting differences, for the ones that are two state, it could even be as simple as just the label attached to the nodes. Perhaps that is significant for controllers where you don't have as low an access level as you do with ISY.

But, I'm not going to try to figure it out further, I think I added/removed them a dozen times! Got something that will work now.

My first Z-Wave module, in operation. Hope it is not intimidated by the sea of Insteon. ?

* Orest

[oskrypuch]

I can report GOOD success with the ZEN17 unit.

AND, there is a bit of irony.

In this location previously, I had a pair of IOLincs in the garage, one for each door. They would have no more than a 70% rate of transmission reliability, way worse than any other Insteon module (including other IOLincs) in the house. If they failed to report a door open bad enough, but if they failed to report the door closed the ding-donger would continue irritatingly.

I tried everything, of course double checked the contact switches (alarm company commercial grade), swapped out with two new IOLinc units, put filterLincs on the garage door motors, tried using a different power outlet in the garage, put a booster module in the garage, I even jiggled the cords. I considered running the low-voltage cabling from the contact switches further indoors and centrally, but I finally gave up and set the program to both listen for messages, and also to QUERY the pair of IOLincs between each set of ding dongs, when the door was reported as open. That seemed to work as a fail safe. Still missed some door opens, but never kept ding donging and falsely indicating a garage open state.

So, the irony ....

Z-Wave is often site limited by distances in a sparse new setup as it is a wireless mesh network. I was a bit concerned as the garage is a bit distant. Well, the garage door open/close state report (sensed by the Zen17) now works flawlessly! I actually removed all the extra queries and double checks in the ISY code.

Now, I do have the 700 dongle on the top floor, oriented vertically, and there is a Series 7 repeater within 15 feet, but still -- weird!

* Orest

 

[johnnyt]

@oskrypuch, thanks for the post. It was very helpful.

FYI, there is an updated firmware 1.10 (unit comes with 1.04), which includes a bug fix for an issue when setting param 2/3 to 7 and params 10/11 to disabled, which is exactly what's needed for the desired behavior.

See changelog here: https://www.support.getzooz.com/kb/article/727-zen17-universal-relay-change-log/

I did the upgrade - all is good and am actually also using the new parameters 19/20

updated manual explaining new parameters: https://www.support.getzooz.com/kb/article/698-zen17-universal-relay-advanced-settings/

[oskrypuch]

@johnnytInteresting.

How did you perform the firmware update?

* Orest

[johnnyt]

See: https://www.support.getzooz.com/kb/article/253-how-to-perform-an-ota-firmware-update-on-zooz-devices/

it's a bit of a process. You need to get a separate zwave hub and you need to download a really bloated multi component software suite, register with the company so you can login when the tool starts, then add a couple of components to it in order to use the "PC Controller" that actually does the work.

I check for updates when I first get the device and do it right away because I believe if you've already added it to ISY, you need to exclude it so you can link it to the other hub, which hoses all the programs/config work you've done.  I'm hoping there's a better way coming - or if someone knows of one here now they'll chime in.

 

 

[oskrypuch]

If you have to manually remove all your devices from the stick/ISY, and then add them in with the stick plugged into a laptop, [do the update], and then remove them and then add them back to the ISY -- that is completely impractical. Besides being rather time consuming, it would scramble all of your ISY programming.

I would have to need that update, really badly!

* Orest

[brians]

The devices will be on the stick. Just inbox and try the update -  not sure If the update will work or not like that however. 

backup stick reset do firmware update then restore   

Or get a second stick. 
 

see my topic elsewhere here about firmware fun. 
 

 

[johnnyt]

I have my new ZEN17 configured with param 2/3 -> 7 (open/close alert door sensor) and param 10/11 -> 0 to disable the link from sensor to relay. 

I use one of the sensors to detect a dry contact feature of my UPS that closes the contact when UPS goes on battery. The contact closing works fine, the ZEN17 detects/reports it and ISY changes the state within a second or two.

However when the UPS goes off battery (back to utility power), the sensor doesn't report it. If I query the device manually, it shows that the dry contact from UPS did re-open.

I don't know if it's a "feature" of open/close alert door sensor (setting 7 for param 2/3) to not report the "OFF" event, or if there's something else going on (or should I say, not going on). Has anyone else noticed this?

One thing I tried as a workaround (not really ideal though) is to try periodic queries of the device in a program when its ON but I can't find the device when I'm trying to pick it to do the query. It's like ISY doesn't see it as an option to do anything to it. Has anyone else seen this? Is it a bug or feature?

Using the device list below, I'm using and trying to query "Windows Alarm 1" in a program

[oskrypuch]

Are you by any chance powering the Zen17 on the circuit supplied by the UPS? It is of course an RF device, but the surge might be doing something.

Did you try to run a program, to see if it would notice the change, even though it isn't shown in the admin console?

* Orest

[johnnyt]

yes, ZEN17, which is a foot away from ISY with its zwave dongle inside, is on UPS just like ISY and all my  networking gear, plus a PC doing some server duties. That's not an issue at all.

The problem is not that ISY doesn't recognize the change of the ZEN17 sensor to ON when power fails - that works fine. The problem is that ISY doesn't see when the sensor goes OFF (i.e. back to main power)  unless I manually query it. And I'm not finding an option to query the sensor in a program. I must of looked up and down the pick list for 20 mins for the device. I can't find it.

Can you/someone verify that you/they are able (or not) to query the "windows Alarm 1" node of a Zen17 with param 2/3 set to 7 in a *program*?

Thanks.

[oskrypuch]

Take the Zen17 OFF the UPS power. Yes, it is an RF device, but a power spike could possibly affect it.

As you have it set up, mine works 100%.

* Orest