oskrypuch

Check the pamphlet that came with your extender. Pretty straightforward, you plug it in, you'll see the LED ring breathing (glowing bright/dim), single tap that button and it is in learning mode. * Orest Classic Inclusion. 1. Decide on where you want your Range Extender to be placed and then plug it into a wall outlet. Make sure that the LED is breathing its white LED. 2. Set your Z-Wave Controller into pairing mode. 3. Press the Z-Wave Button on your Range Extender and quickly release the button (should only be a quick tap action on the button). Range Extender 7 will quickly flash its white LED up to 30 seconds or until it is paired successfully. If successfully paired, the LEDs light will become brighter. If your repeater failed to pair, the LED will return to slow breathing LED. If it is this case, please return to step 2.

<disregard>

I bought my 700 dongle here ... https://shophometechsolution.org/collections/zooz/products/zooz-zst10-700-series Apparently they are the Canadian partner to Smartest Home in the US. They have a ton of Z-Wave stuff, I've already purchased a number. I did want to add the Aeotech extender as a first step, but they don't carry it curiously. Aartech does, even though they don't have that many Z-Wave products, yet, anyway. https://www.aartech.ca/zw189/aeotec-zwave-plus-plug-in-range-extender-7.html On sale until May 2nd. * Orest

@jkrausOK, this is fairly obvious (sorry) but worth saying, you did put the extender into learning mode? I am only two Z-Wave devices ahead of you, and I have that extender in operation. * Orest

A little warmer today, so will likely hit Summer season state by the time we hit 11pm, if so, it won't test out tonight. All the observed temp variables are one digit precision. The limit constants on the temps were zero decimal precision, changed them to one digit decimal precision, just on spec. Just in case IoP is doing the comparisons differently, but that is a reach. * Orest

Noticed the same thing with the Zen17, my first Z-Wave item. There seems to be duplication in the nodes, and some nodes are actually non-functional. I tried deleting the unused nodes, but they came back. I put them all in their own folder to keep it tidier. Don't know if you can group them as well. It may be that there is some sort of Z-Wave device definition that requires a certain general framework for compatibility. Love to hear, from someone that is informed on this. * Orest

That is a good point, if we are looking for something odd. The next time this happens, likely tonight, I will check the date stamps on the variables, to prove that the ELSE clause actually ran. The program itself does date stamp correctly. But, because it would have been Spring/Fall on the prior running of the program, and subsequent to it running errantly Spring/Fall is false (all season states are false then), it does suggest the ELSE clause ran. The true/false constants are initialized on startup: $xc_true = -1 $xc_false = 0 and are used widely throughout many lines of code. They are never assigned any other value. FWIW, I have five season states, Summer Hot, Summer, Spring/Fall, Winter, Winter Cold. These are set based on the outside temperature and the time of day, and checked once an hour. I then use those season variables in a variety of ways, in particular to run my thermostats. Because of their wide use, I monitor/alert the season states for validity, there can only be one set, and there must be one set, so I caught the issue immediately. * Orest

@Michel Kohanim The program in question is below, it is one of a family of programs that decide what season it is out there. This is very old code, and has been executing uneventfully on the ISY for years. It has recently been moved to the Polisy. The program itself is set as disabled and all the variables are non-state. The program is triggered to run 15 minutes after the hour, every hour, by another supervisor program. The situation is late night (in the 11pm to 5am timeframe), and our Spring time. Variable values, these are all "integer" (not state) variables ... $uu_Temperature = 1.8 $uu_Feels_Like = 1.8 These are from a weather station. $sx_S_AM = 5 (top limit of "Spring" in this timeframe) $sx_SF_AM = -3 (bottom limit of "Spring" in this timeframe) These are constants, I have them in variables so they are easy to change, as they occur in other statements as well. Time is in the 11pm to 5am timeframe. Clearly the final OR statement is true, and the program should execute THEN. It doesn't. It has happened twice. I tried to run it manually, it went false and executed the ELSE. When all of the possible seasons execute ELSE, I get an alert, it means the system doesn't know what season it is, and that should never happen normally. The first night I went in, made a trivial change to the program, saved it, and then went in and changed it back to the same and resaved it. So two saves, but the program code remained the same. On forcing that program to run again, it then ran normally and executed the THEN as expected! There was no temperature change in that time frame, or anything else. I did something similar tonight. Once again when the statement was restored to exactly what it was (after two saves), it ran as expected. That is hard to explain, unless there is some underlying system issue. Or, perhaps it was just the passage of time, combined with an issue with the over midnight time block logic? I bring it to your attention, and for comment. * Orest spring/fall.check - [ID 00AD][Parent 0038][Not Enabled] If ( From 5:00:00AM To 11:00:00AM (same day) And $uu_Temperature <= $sx_S_AM And $uu_Temperature > $sx_SF_AM And $uu_Feels_Like > $sx_SF_AM ) Or ( From 11:00:00AM To 5:00:00PM (same day) And $uu_Temperature <= $sx_S_Day And $uu_Temperature > $sx_SF_Day And $uu_Feels_Like > $sx_SF_Day ) Or ( From 5:00:00PM To 11:00:00PM (same day) And $uu_Temperature <= $sx_S_Eve And $uu_Temperature > $sx_SF_Eve And $uu_Feels_Like > $sx_SF_Eve ) Or ( From 11:00:00PM To 5:00:00AM (next day) And $uu_Temperature <= $sx_S_Night And $uu_Temperature > $sx_SF_Night And $uu_Feels_Like > $sx_SF_Night ) Then Wait 10 seconds $_season_spring_fall = $xc_true $_season_spring_fall Init To $xc_true Run Program 'spring/fall.notify' (If) Else $_season_spring_fall = $xc_false $_season_spring_fall Init To $xc_false

How old is the 2450? (week/year of manufacturing is stamped on each unit, eg. 2313) There IS a ZWave alternative, the ZOOZ ZEN17. I just set one up. Check the recent threads here. It is actually more capable than a 2450, but a little more involved to set it up. If you go Z-Wave (which you probably will eventually), I'll pass on the suggestion to keep it to the 700 series devices, with the supported ZOOZ ZST10 700 dongle on the Polisy. Also, the Aeotec Series 7 repeater/amplifier for a sparse setup has been recommended. I have a complex Insteon network, but am a complete newbie to Z-Wave. I guess in time we will all get more familiar with it. * Orest

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

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

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

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

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

One thought, when you manually added the ISY address in the finder, did you include the full url, example... http://192.168.1.99 The prefix is required. * Orest

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

So there is a hard limit of 254 devices on a network? * Orest

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

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

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

I am trying to add ZOOZ ZEN17. ... <moved to its own thread>

Oh gosh, didn't realize that a device identity in Z-Wave is so fragile, in contrast to the "nic" type hard ID on the Insteon side. That would be a real nuisance if you scrambled the IDs. I assume that a power loss won't cause this?? And the ISY relies only on that labile ID to address the devices. Hmm. is there a way to recover the original logical device ID, by manually reassigning it, if it gets scrambled? If not, that means editing all your programs in ISY?? That could be a royal headache. * Orest

The other thing, folks talk about including/excluding. Is that a way to force a rejigging of the path to the controller? Presume that is a context option, when you have a device installed? So, that might be if you were rebuilding a full already (physically) installed network. Otherwise, you can just use the Update Neighbors option, assuming that only one device needs fixing. Does the "topology" map list the Z-Wave routing, so you can check the logic yourself? Fun to be a newbie again. * Orest

That would allow you to move the plisy to the installed location, but at the penalty of having to reboot the Polisy twice, each time, unless you have a very long extension cord! I have a lot of program initializations and such, so that would be a pain. * Orest

Yes, that is the first thing I added, the Aeotec 700 repeater. That is all I have so far, so not too concerned about Z-Wave backups thus far! For plug in units trivial to do, but for in box devices I guess you would just keep a 110v plug with a loose wire hookup to get it going? So, let's say I add a unit next to the Polisy (and repeater, it is only 10ft away), I then pull the power on the just added unit, and walk it out to its final location, plug it in/wire it up, and then just let it sit and it will "heal" itself in a a bit? And if putting in a bunch, you want to sequence from closest (first) to furthest away. * Orest