johnnyt

What search are you doing because I'm not finding much info. Searches for "zwave NWE/NWI" and variations of that brings up this thread and the UDI wiki, which doesn't explain it - or at least not the page I found. What does it do? Should I just leave it on (it defaults to off) or could it cause grief to do that?

I see people mentioning they're on zwave firmware 6.82 and 6.88 (ISY 500-series dongle) I'm only at 6.81. Could that be explanation for some problems and annoyances I've not been able to solve? Is there a way to update the firmware? Not finding must by searching forum.

I'm planning my move from 994iZW to IoP. Is the above saying that I won't need to exclude zwave devices from 994i and that IoP will just see them as they were on 994i when I restore the ISY backup (with the embedded zwave backup)? I didn't get that from reading other posts about migrating to IoP. Rather I was under the impression I needed to re-include my zwave devices one by one and manually realign all my 994i device name/numbers to use their inevitably new 'out of the box' device names and the new ZWxxx numbers starting at 001 when doing inclusion. This would change a lot.

There's a new firmware that "Fixed reporting behavior after power outage: if parameters 2 or 3 are set to any value, and parameters 10 or11 are set to disabled" this is the setting that unlinks the sensor from the relay https://www.support.getzooz.com/kb/article/727-zen17-universal-relay-change-log/

So I'm currently working on my 2nd ZEN17 that's not reliably reporting the sensor changes when they happen. Querying it is fine but I need it to trigger properly every time and it sometimes doesn't. The first one Zooz support agreed with me it was defective. It's on-going discussion right now for second one. I just sent ZooZ the attached list of some of the multiple errors from ISY logs - the worst kind: intermittent ones. Did I just get 2 bad units? (bought at same time from amazon - thankfully I don't have to fight to return them) What are other people's experiences with ZEN17 sensors? ZEN17-Errors-summary.xlsx

Just query the sensor node, no? I have to say I'm currently working on my 2nd ZEN17 that's not reliably reporting the sensor changes when they happen. Querying it is fine but I need it to trigger properly every time and it sometimes doesn't. One of my less frequent use cases (I have 3) is when utility power goes out and my UPS kicks in and closes a dry contact. The ZEN17 needs to tell my ISY (which is on the UPS) that power is out. I have my furnace and zwave Tstat on UPS so (in winter) ISY turns it down right away then again a bit more 30 minutes later in case it's going to be a long outage. I'm looking for others' experiences with ZEN17 sensors because I'm getting worried they're unreliable. It could be just 2 bad units from the same batch given I ordered them at same time. I don't know yet. I'm getting two other ones from different supplier so will see how those do. In the meantime would love to hear from others.

After a few exchanges with Zooz support, the answer regarding setting params 2/3/ to 4, 7, and 10 is: " yes, the setting should behave the same way but will have different wording depending on the setting programmed" So they're suggesting I check with ISY support regarding settings 4 and 10 not working like 7. I may do that at some point, although as long as one of the settings works and the only difference is the words used in the nodes and status, it's not critical.

First thing I did with both devices (after getting the latest firmware from Zooz) was include them on my spare zwave stick to do the firmware update. Then i excluded it from 2nd hub and included it on ISY where I changed param 2/3 then did the exclude/include again on ISY then changed the other params (10/11, 19/20). I think when I did the latter param changes at the same time as param 2/3, the values didn't stick for them. I'm not sure - only did that once then just decided to do them after the changes to param 2/3 and the required exclude/include from then on. Something I didn't do between playing with params 2/3 was a factory reset. Didn't seem to need it but then again settings 4 and 10 didn't work as advertised so maybe a factory reset was needed. At this point I'll just wait to see what Zooz support tells me.

I received a 2nd ZEN17 and used it to test a couple different settings to see if there's a setting that works better for my UPS dry contact feature. I left the relays linked to the sensor so I could hear the changes (relays for the 1st unit are being used so I don't want to start messing with them, not to mention exclude/include process.) I found the performance/behavior finicky. Some behavior didn't work the first time and some nodes didn't show up until I went through a couple of cycles closing/opening the sensors. I tried param2/3 at 4, 7 and 10. Only 7 worked properly, and it did work 100% fine when I used the 2nd unit with the UPS. So I did a test again with the unit in "production" and it worked fine today. So I'm thinking these things need to stabilize or something by going though a few cycles. Hopefully this is just an initial stabilization thing but will need to keep and eye and maybe do periodic drills to make sure things do settle and act reliably. I also found that setting 4 doesn't work properly - sensor never changes as one would have expected. (If not the expectation, then why put sensor nodes?) Same with setting 10, as discovered already on in this post. I reached out Zooz support to ask about this and for an explanation of the behavior for all the settings (stressing that I have the advanced settings "manual" so looking for more than that). If they provide something useful, I'll post it here.

that would defeat the purpose for which i got the ZEN17 - at least the way I'm using one of the sensors. (I'm using the relays for something else.) I should point out that when I did the test there was not an actual power failure. So it's not like anything wasn't working the way it would under normal conditions, i.e. any/all zwave neighbors were up, for what that's worth.

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.

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

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, 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/

Can two zwave networks co-exist? If it matters, in my case one is my "production" 500-series ISY994iZW, and the other will be (not done yet) my "development/testing" Zooz 700-series USB dongle on my Polisy with an unconfigured IoP. As I test away, and in particular test things like the ZooZ ZEN17, which needs an exclusion/inclusion performed after some parameter changes, I wonder: 1) How is one supposed to manage changing a parameter that needs an exclusion/inclusion, like with a ZEN17? No big deal when I first get it, I can start over, but what if I have to change something after a bunch of stuff is configured? 2) how to replace a defective device? Is there a way to assign the same device number that was excluded to a new one on inclusion? If no, which is what I think, is that going to change some day? is/will there ever be a way to add a new zwave device and click "replace device with..." (like there is with Insteon) before excluding the device or after the device failed?

Thanks, @MrBillLooks very promising. Just ordered one and may get a couple more later.

I have a UPS that closes a dry contact when utility power goes out that I would like to use to notify ISY that power is out. Is there an equivalent to the IOLinc sense function in a zwave device? I searched "dry contact" but the results have all returned magnets used to detect door/window closure. Any suggestions would be appreciated.

does Ecobee need cloud service to work with ISY or can it connect locally? I think I know the answer but just checking I don't mind a cloud service for "value add" stuff, like reporting, etc. and might even pay if it's good stuff but I really don't want to count on a cloud service to use it with ISY.

I don't have short cycling with this stat - I've only had those with Venstar. I do have AC situations where temp = SP and there's still a call for AC for a long time. Doesn't happen with heat calls. I was assuming the temp display rounds up or something compared to the internal temp setting for the purposes of a cooling call. For the record I checked and adjusted, as needed, all the settings to optimized values (researching if I wasn't sure). I left Cycles per Hour (CPH) to 3, the default and generally recommended setting for high efficiency furnace as well as for my furnace. My zwave firmware version is "01-03-00-00" - what's yours @jec6613? I haven't tried to update it since I got the thing and don't know if I even can. (I don't think so. I don't recall it advertising that it supports OTA firmware updates) I may well have a defective unit. For one thing I have to use the remote temp sensor because the one in the stat is about 8 degrees too hot (max temp offset is -3). Hopefully it's using the remote sensor for everything, not just the display. It also doesn't report stage 2 heat call, even though it supports it. I'm thinking it's just a missing zwave feature?

2 deg gets too hot in summer and too cold in winter. Always used 1 deg and never had problem until I got the Venstar. If they had implemented a min run time and min off time, it would have been fine. I worked around it by having ISY programs implement MRT and MOT. It wasn't foolproof and the stat had other issues, like spontaneous reboots, so I gave up on it.

forgot to mention that I don't want a stat that needs a cloud service to work/control, e.g. Nest, Ecobee (I think), etc. I'm okay if the cloud provides reporting or other optional value add, but don't want to be tied to the whims of a cloud service that might end one day (see Insteon hub, etc.) or demand a monthly ransom.

Looking for up to date Zwave thermostat recommendations. I've had a Venstar and liked a lot of things about it but didn't like the hair trigger cycling that happened when I set the deadband to 1 degree. It would short cycle my heat/AC because it had no minimum run time and when I discussed it with support their suggestion was to set a 2 degree deadband. I've had 1 degree deadbands for 30 years - what's up with that? I'm not loving the Honeywell T6 Pro I have now for 2 reasons, 1. it doesn't respond to ISY program queries. That might be an ISY problem supporting that t-stat - I don't know. (yes, I've reported the issue to UDI - ticket still open a year later - one of the few rare ones I have with no answer.) 2. it's strangely ON (heat/cool call) even when the setpoint has been reached. Clearly it's not reporting on the screen the temp it senses internally but, more interestingly, it can sit at SP=Temp for what seems like a longer time than needed while it's calling for heat/cool (especially cool). I would really like suggestion for a good 700 series stat, if there is one but I'd be fine with a 500 series as long as it worked well with ISY.

I had a look after work at what's needed and understood about 20%, so it's a stretch but I'll see if I can conquer it when I have more time. They show you how to do it with Postman / Insomnia so that's where I'll look first. In another related post JimboAutomates said he would look into a Node server. If that happens before I figure things out (assuming I can) I'll for sure look into it.

Starting new thread on this as the old one is closed for some reason and I don't know how to re-open or get it reopened. Looks like Airthings now offers API's for consumer products https://help.airthings.com/en/articles/4510990-integrations-airthings-api Now I have to see if/how I get this to work with ISY.

Wow we're off topic but.. oh well... You want one of these with all your networking gear plug into it in addition to ISY, Polisy, etc. https://dlidirect.com/products/new-pro-switch You can set/up call scripts using ISY network resources to reboot ISY and/or Polisy, as well as you networking gear in proper sequence with delay in between. Can also set up autoping to reboot hung things. Also you can bookmark these in your browser to make stuff happen: http://192.168.0.60/outlet?8=ON, http://192.168.0.60/script?run021=run