Everything posted by oskrypuch
-
Ding-Donger replacement
No, you call a sound routine node and supply a value to select the sound. * Orest
-
Adding ZOOZ ZEN17 challenges
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
-
Ding-Donger replacement
For sure, will do. I have ordered the Ecolink, shipping listed as 1 week. There is an Amazon review specifically noting success using it with an ISY. Ships from Ecolink ... https://www.amazon.com/Ecolink-Enabled-Security-Intruder-ISZW7-ECO/dp/B099CS76K3/ref=sr_1_1 * Orest
-
Ding-Donger replacement
Also an Aeotec Siren 6, similar functions, but it is 500 series. * Orest
-
Ding-Donger replacement
Ha, found one, perhaps ... Ecolink ISZW7-ECO Z-Wave Plus v2 https://products.z-wavealliance.org/products/4000 Now to see if I can source it. * Orest
-
Ding-Donger replacement
Searched the Z-Wave database, found lots of sirens, but not what I'm looking for. I still have an ancient X-10 chime (ding-dong, ding-dong, dong-ding) to announce motion outside (once) as well as a garage door opening (twice), and actually for a water leak in the house (ten times). It is still working fine, but will crump some day. Anyone know of a simple Z-Wave box that will issue, perhaps a variety of, identifiable chimes for various states? I suppose you could go with the various talking boxes, but I am loathe to install any device that could also listen and send to the cloud, everything that is said in the house. * Orest
-
Z-Wave alliance site, 500 or 700 series units?
That is really quite an impressive site. I missed the Advanced Search button the first time through. * Orest
-
Z-Wave alliance site, 500 or 700 series units?
OK, so &zwavePlus2Only=on will search for them. * Orest
-
Z-Wave alliance site, 500 or 700 series units?
Hmm, no consistency on that line, the Zen71 series 700 switch uses a different designator, so that may be manufacturer specific. However presence/absence of the line might be significant in this regard. * Orest ON/OFF SWITCH 700 Brand Name: Zooz Product Identifier: ZEN71 Product Line: Line A Product Version: HW: 1 FW: 1.00 Z-Wave Certification Number: ZC12-21020181 Z-Wave Certification Date: 2/17/2021
-
Z-Wave alliance site, 500 or 700 series units?
Just looking through the descriptions of some Z-Wave modules on the registry site, and among other things trying to figure out where it notes what series that devices are. Nothing obvious to me. I suppose if the certification date is 2018 or before, it is unlikely to 700 series. Two examples (below), I know that the Switch 7 is series 700. Is it the Z-Wave Plus v2 line that confirms that? The other listing doesn't have that noted, but then it doesn't have a "Product Line" descriptor line at all. * Orest Smart Switch 7 Brand Name: Aeotec Product Identifier: ZWA023-A Product Line: Z-Wave Plus v2 line Product Version: HW: 1 FW: 1.02 Z-Wave Certification Number: ZC12-20050064 Z-Wave Certification Date: 5/21/2020 Smart Switch 6 Brand Name: Aeotec Product Identifier: ZW096-A02 Product Version: HW: 96 FW: 1.04 Z-Wave Certification Number: ZC10-18106250 Z-Wave Certification Date: 10/4/2018
-
2477S replacement in Z-Wave
Just trying to be cautious, especially since I'm new to the Z-Wave side. Clearly a "clunking" dry contact relay like the old 2477S will handle a variety of loads, but an electronic switch may have some operational restrictions. Most of my fluorescents have been changed out to LED tube replacements, that work with the original ballasts, but still have some T8's in place. * Orest
-
2477S replacement in Z-Wave
There is the Zen30 double switch. It appears to be a triac switched dimmer + separate 15A dry contact relay controlled by a separate lower toggle. But I think it is a 500 series device. * Orest
-
2477S replacement in Z-Wave
They don't mention tube fluorescents in their technical notes, only CFLs. Hmm. Same specs otherwise to the ZEN71. I suspect the guts are identical. * Orest
-
More on Forget using a 2413s PLM with Polisy!
I migrated my 2413s, when I moved from the ISY to the Polisy, works just fine. You do need that serial cable that came with the PLM, if you kept it, you are good. Believe you can replace it. Quite happy with the Polisy, it turned out to be the perfect time for me to make the jump. * Orest
-
2477S replacement in Z-Wave
Right in their documentation. * Orest
-
2477S replacement in Z-Wave
OK, I know about the Zooz switches like the ZEN71, actually just got one of the dimmers (ZEN72), nice unit. But, I'm looking for something that has an 1800w rated relay that can handle mixed loads, including appliances and tube fluorescents. The light box switches (eg. ZEN71) I've found restrict usage for these. It seems you'd have to grab one of the wire-in relay boxes, and also combine it with a regular switch to provide manual control. So, no such all-in-one product, wall switch with heavy duty relay in one box, in Z-Wave? * Orest
-
Added First Z-wave - wow, lots of Z-waves!
Flotsam. If you try to delete the ones you don't need, they will likely regenerate. Seems the tidiest way to handle them, is to move unused nodes to a dedicated "unused nodes" folder. * Orest
-
adding first Z-wave to my new polisy
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.
-
Program execution difference between 994 and IoP
<disregard>
-
Purchasing the Zooz Z-Wave module
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
-
adding first Z-wave to my new polisy
@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
-
Odd program behavior, possible IoP execution bug?
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
-
What are all the extra devices?
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
-
Odd program behavior, possible IoP execution bug?
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
-
Odd program behavior, possible IoP execution bug?
@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