Toddimus

I bought my first ISY994 almost 14 years ago. Had a few Insteon modems die along the way (not UDI's fault), assumed it was just the cost of playing the geeky game. Somewhere along the line, I think I must have had an ISY994 die along the way because I have an extra. Can't really remember what happened there. Now I have a Polisy Pro that initially just ran Polyglot integrations which have since been deprecated (more on that later). About a year ago, I finally migrated my totally functional ISY994 system/programs/Z-wave network over to the Polisy. It was supposed to be the bee's knees. By the time I ended up migrating, there was a new and improved, bee's knees called the EISY. I get it, they had to change suppliers for their uber-cheap imported box that can run the Java backend to maintain compatibility. What initially pissed me off was that the recommended Zooz Z-stick was no longer supported on the "latest" version of ISY firmware on the now deprecated Polisy. You can still use it but you can't upgrade to the latest versions of firmware because it's not supported. Instead, you have to buy the MatterZ stick because that's the new thing and you just have to have it, or it won't work unless you stay on old firmware. Fast forward to now... My Polisy updated itself to v5.8.4 (I think) firmware apparently within the last few days/weeks. I didn't do it. Now, it needs rebooting every day. My old Polyglot 2 integrations are dead. I had a LOT of archaic ISY Java admin interface code programmed around those Polyglot integrations. And now, you need a subscription to maintain connectivity to the system from the smart phone. I get it. The company needs to make money and needs to monetize this thing. I totally get it. I'm just not willing to buy an EISY (~$300) and a Zmatter (~$125) to replace the stuff that worked just fine until the ecosystem I had been using is suddenly deprecated. I just did the subscription for the next year for the portal. I'm fine with a subscription. I'd probably pay $50/year if it just worked and I didn't have to deal with it all the time. But, alas it doesn't. I had hoped I didn't need to babysit it. But I do. Why does the Insteon light take so long to react to a motion sensor when the Z-wave reacts immediately? Why do I still occasionally get an all-on event? Why does the Polisy reboot when the living room motion sensors have a bunch of triggers (can't I have a party in my living room)?? I think I'm done with UDI unless there's a clear path to a stable system that I can rely upon for at least a few years. I wish it wasn't this way but I'm at my wit's end. I'll likely be migrating control to either Home Assistant or OpenHAB (both of which I have run in parallel for many years). I just find that I can't rely upon the Polisy and the ISY/Polyglot infrastructure anymore. To be honest, I'm bummed. I'm not one to be a complainer or squeaky wheel. I've tried to make the ISY work. And I have ~50 Insteon devices in my house. I have a ridiculous amount of time building ISY programs. And I made some really cool automation stuff over the years. But I realize this is the state of affairs. I think I have to begin the process of migrating away. It's just not stable anymore. As I said, I'm bummed, or you could even say, disappointed. Please tell me I'm wrong and pull me off the edge because I'd love to just have an update and fix everything. I just don't see it happening. Especially on "old" Polisy hardware with Zooz Zstick.

FWIW, this worked for me as well. Thank you for this!!!!! I get the zwave menu instead of the Zmatter not responding. Now I just need to get the zwave devices added. That's proving to be a chore. I updated to v7.18 firmware on the Zooz, so maybe that's the problem. I'll try reverting to v7.17, which seems to have worked for others.

I use an Autelis Bridge for Pentair Intellitouch connection, but apparently Autelis seems to be AWOL for the last year or so that's not an option. And that's a lot more involved than what you're asking to do. You could possibly use the GPIO pins of a RaspberryPi and to be on the safe side, have those outputs drive 4 small relays. The RPi's GPIO pins are only 3.3V so you get something like this to buffer between it and the Pentair relays: Raspberry Pi relay hat Then, use this Polyglot Node Server, which can probably run on the same Raspberry Pi. https://github.com/exking/udi-gpio-poly I haven't tried the GPIO node server, nor have I tried one of those relay hats but it seems like you could put something together for ~$50.

Yeah, it did work with precision set to 0 or 1. When the precision is set to 0, I think it just drops whatever "mantissa" there is, rather than rounding. So 99.9 would equal 99. EDIT: I stand corrected. See the second set of variables below: Precision set to 0 does seem to do rounding:

Because of the post by @kclenden I had to test it out myself too. One weird thing is that when you manually change a variable on the variables tab, you need to hit enter or it doesn't "stick". Here's programs that works both ways:

@mmb On the variables page where you have your Temp_Current defined, right click on the row and select "Change Precision". I'm pretty sure that's how you change it from "Integer" to a "Floating Point" (even if it's defined on the "Integer" tab! ) You can select from 0 up to 8 digits of precision. I think that should fix your problem.

FWIW... I saw issues with Alexa earlier today too. Seems to work now.

I have the same question/issue with my Velux skylights, which are driven by a pair of Insteon I/O modules. To open them, I have a program that makes one I/O turn "ON" and the other "OFF" (and the opposite polarities for closing). It just so happens that this is the way the Velux "home automation bridge" works. It actually has been a good thing to combat the dreaded Insteon "ALL ON" bug. When that happens, both I/O modules go high (i.e. ON), and that would actually stop any movement that's currently in progress, though I've never had an ALL ON event while the skylights were in transit. I've just gotten used to saying "Alexa, turn the skylights on (or off)". It's weird and non-intuitive for anyone other than me. It would be very cool if it were to be fixed so I could use the words "open" and "close", but in the mean time, I'll keep using "ON" and "OFF".

I've been keeping an eye on this thread. I plan to check it out soon, maybe this week. Been too busy to get deep into loading/testing it out. Thanks for your work on it!!

That valve might be a good tool to use for an automatic pool filling system, if I ever get around to automating my pool.

Both, I think. I honestly didn't look that hard at it. I was getting our toddler to bed and got distracted. Nothing stood out to me though. Definitely weren't a bunch of individual device or scenes turned full on in the log. Sorry I'm not more help. Il try to document it better next time. Sent from my iPhone using Tapatalk

I didn't have any All On events for about 14 months ... from the time I did my initial install in our new house until about a month ago. I just had another one last night. Both times, I was opening a door that has a hidden door sensor in it. There also happens to be a wireless motion sensor on the far side of the door that I was opening. Not sure if the motion sensor would have had enough time to "see" me before the All On actually happened. I think the first time, the hidden door sensor had a low battery. Maybe it tried to send out its low battery signal on top of the regular door open signal it was trying to send? The first time, I wasn't able to get to the log to check. Last night, I looked in the ISY log and didn't see anything that looked suspicious.

This is extremely cool! I recently put some extra blank switch locations around the house in preparation for something like this. I had been thinking of using old iPhones or maybe some sort of small tablet, but a RPi with touch screen would be awesome! In fact, I just received two more RPi 2 boards today that I ordered from Makershed. They are having a big sale. They were already half off ($20) and then there was a 20% off coupon code which made them $16 each! Yes, that's for the latest RPi2. Looks like they are out of stock now though.

Well, that answers that question. You even did the math for me Stu, thanks. So I won't worry about it then. Any thoughts on the new feature for automatically populating the permutations of the adjust scene function I suggested for the interface? I did go through and do it manually with all the permutations and it wasn't that bad but it would be nice to be able to automate some of that process if possible.

Follow up question... I assume these adjust scene actions actually write updates to the internal non-volatile (is it EEPROM?) of the devices. Is there any issue with degradation if I write to these say... 5 times per day? I commented about this in one of the Ideascale items where the originator (Jim Searle) wanted to be able to programmatically enable/disable devices from being responders to scenes. By the way, this is a great idea, if it can be done... http://udi.ideascale.com/a/dtd/Allow-disabling-a-device-in-a-program/83037-32911 This would also theoretically require writes to the devices' non-volatile memory. Any thoughts on the longevity of the non-volatile memory's write endurance? 10 years x 365 days x 5 writes per day is almost 20,000 write actions. Thanks, Todd

Makes sense. And I thought that might be the case. It's just a lot of programming. I have 24 (8 scenes x 3 lighting scenarios for each scene) programs so far to address the level changes. And I haven't finished installing all of my devices, or creating scenes. Each of those programs would then need at least 4 adjust scene lines (for single device scenes) and 12 lines (for my dual controller scenes). I know... just buck up and deal with it. That's part of the fun in this home automation stuff. Version 5.X will hopefully make this easier, in that I can use variables instead of hard coded values in the adjust scene drop down lists. Seems like there's an opportunity for a new feature (even without variables driving the levels)... The new GUI feature would allow the user to apply the changes to all of the devices in a scene (and the scene itself) in the adjust scene part of the programming tab. Kind of like the "Copy Scene Attributes from <Scene Name>" button on the scene configuration page. I realize it wouldn't necessarily address my desire to have different ON or RAMP levels for the scene vs. locally applied button presses. But I can envision how that could be implemented too. Thanks for the reply oberkc!

Programming question here. I have searched and read about adjust scene programming, but found nothing regarding a 3 (or more) way switch setup to do what I want. Here's a simplified set of my components involved in the scenario... Devices: Dimmer switch "Hallway - A" (controls actual load with red wire, is also set as a controller for the 3-way scene) Dimmer switch "Hallway - B" (red load line is not connected, it is used only for the 3-way scene as a controller for the scene) Scene: "Hallway - 3 Way" Both "Hallway - A" and "Hallway - B" are controllers for this scene. I would like to set the locally applied (i.e. button pressed on the wall switch) value to a different (higher) value than is assigned to the scene itself. I would also like to be able to programmatically change these levels (and ramp rates) independently, depending upon the time of day. In order to do this, I will set up programs that will trigger an "adjust scene" action. My question relates to the options available in the adjust scene drop-down boxes. In the THEN clause of my program, I have the following options to adjust the scene: In Scene: Hallway - 3 Way (Scene icon), Set: Hallway - A (Device icon) : XXX% (On Level) In Scene: Hallway - 3 Way (Scene icon), Set: Hallway - A (Device icon) : X.X Sec (Ramp Rate) In Scene: Hallway - 3 Way (Scene icon), Set: Hallway - B (Device icon) : XXX% (On Level) In Scene: Hallway - 3 Way (Scene icon), Set: Hallway - B (Device icon) : X.X Sec (Ramp Rate) But I also have the options of: In Scene: Hallway - A (Device icon), Set: Hallway - A (Device icon): XXX% (On Level) In Scene: Hallway - A (Device icon), Set: Hallway - A (Device icon): X.X Sec (Ramp Rate) In Scene: Hallway - B (Device icon), Set: Hallway - B (Device icon): XXX% (On Level) In Scene: Hallway - B (Device icon), Set: Hallway - B (Device icon): X.X Sec (Ramp Rate) In Scene: Hallway - A (Device icon), Set: Hallway - B (Device icon): XXX% (On Level) In Scene: Hallway - A (Device icon), Set: Hallway - B (Device icon): X.X Sec (Ramp Rate) In Scene: Hallway - B (Device icon), Set: Hallway - A (Device icon): XXX% (On Level) In Scene: Hallway - B (Device icon), Set: Hallway - A (Device icon): X.X Sec (Ramp Rate) So I think I understand that if I want to change the scene "Hallway - 3 Way" parameters when the actual scene is triggered, I need to adjust the first set of four values (with "Hallway - 3 Way" selected in the first drop down box after "In Scene". This will not have an effect on the values applied locally (i.e. when I press the actual light switches on the wall). If I want to adjust the locally applied levels (and ramp rates), do I need to set all eight of the second set of values? So for instance at night, I want the scene to trigger on levels of 30% and a ramp rate of 2.0 sec. When the actual wall buttons are pressed, I want the level to go to 60% with a ramp rate of 0.5 sec. I also want the other wall switch to adjust its locally displayed LED level to match. Furthermore, if a locally applied "Fast On" is double clicked on one of the switches, I want the load to come on to 100%. Effectively, this gives me three levels of "ON" at any given time. The scene would be programmatically triggered by motion detectors for the 30% level. If I press a wall switch, the lights come on to 60%. And if I double click the wall switch, the lights come on to 100%. All of this with theoretically different ramp rates for each scenario. I presume I would need to do at least this: In Scene: Hallway - 3 Way, Set: Hallway - A : 30% (On Level) In Scene: Hallway - 3 Way, Set: Hallway - A : 2.0 Sec (Ramp Rate) In Scene: Hallway - 3 Way, Set: Hallway - B : 30% (On Level) In Scene: Hallway - 3 Way, Set: Hallway - B : 2.0 Sec (Ramp Rate) In Scene: Hallway - A, Set: Hallway - A : 60% (On Level) In Scene: Hallway - A, Set: Hallway - A : 0.5 Sec (Ramp Rate) In Scene: Hallway - B, Set: Hallway - B : 60% (On Level) In Scene: Hallway - B, Set: Hallway - B : 0.5 Sec (Ramp Rate) Do I need to do these too? In Scene: Hallway - A, Set: Hallway - B : 60% (On Level) In Scene: Hallway - A, Set: Hallway - B : 0.5 Sec (Ramp Rate) In Scene: Hallway - B, Set: Hallway - A : 60% (On Level) In Scene: Hallway - B, Set: Hallway - A : 0.5 Sec (Ramp Rate) This same question would apply to any "N-Way" switches and presumably gets more convoluted with more controller switches in the scene. I hope this makes sense. Thanks in advance for any help with this question. Cheers, Todd p.s. As an aside... the fact that they call it a 3-Way switch is somewhat misleading to me. There are only two switches and two possible paths for the hot lead (in a conventional switch setup). There are 4 possible permutations of the switch positions: UP-UP, UP-DOWN, DOWN-UP and DOWN-DOWN. Is it because there are usually 3 wires involved? White, red and black? That's the only plausible explanation to me. I do realize that Insteon switches aren't wired this way.

Mike, Awesome! Thanks for the info. I had always thought it was Linux based. I guess my Raspberry Pi would be vulnerable though. I'm not currently using it, but had planned to integrate it into the system. Cheers, Todd

Not to be alarmist... but I just read this article on CNN and it sounds like the Linux based OS of the ISY could be vulnerable to the newest hit amongst the hackers out there: The "Bash Bug"... http://money.cnn.com/2014/09/24/technology/security/bash-bug/index.html?hpt=hp_t2 Just wanted to raise the flag to the powers that be. -Todd

I had this same thing happen to me this weekend. All of the events from my motion sensors stopped being received by the ISY 994 (and 2413S PLM). I noticed that my timers that are triggered by the motion sensors weren't running (so the lights stayed on). I power cycled the ISY and PLM but this didn't fix it. I eventually did a PLM restore which fixed everything, but I will agree that this is weird. Made me wonder if my PLM is going bad. It's an older version (V1.4 I think). Strange stuff started happening when I added a new dimmer switch. Most of my Insteon stuff is the older i1 protocol, and the new dimmer is presumably the newest i2cs protocol. I'm having issues with that too, but haven't had time to track down exactly what's going on. I'll start a new thread on my dimmer scene issue.

Good call Lee. I recently pulled a chunk of paint/texture off of the wall when I removed the double sided tape that comes with the motion sensors. At least I think it came with the sensor. I have some of that stuff lying around so I may have used what I had if it didn't come with the sensor. It's some of the really sticky stuff!

Thanks Michel, I had the extra adjust scene part in there as a "belt and suspenders" kind of entry. I had wondered whether I really needed it or not. It wasn't clear which one I needed so I used both. I'll take it out and I'm sure it will help a bit. Hopefully all of this will help somebody else. I think we have gone over all of the pitfalls in my method and their consequences. It is noticeably faster to use a scene to react to motion and that's just what some folks may want. Thanks to all who have contributed!

For what it's worth, I've also experimented with rotating the sensor by 90 degrees when I'm trying to sense motion down a hallway. Since the sensor is normally meant to detect motion that passes side to side in front of the sensor, if you rotate it 90 degrees and tilt it down a bit, it can help sense motion towards/away from it. The idea is that your body parts appear to move across the sensor during your ingress/egress because the apparent angle to the sensor changes. Don't know if my explanation makes sense but it's worth a try. Have a look at the 2420M manual to see the sensing area in front of the sensor to see if rotating might work for you. I've also found that some white electrical tape works well to block out parts of the sensing area to prevent our small dogs from triggering an ON event. This is similar to flipping the sensor upside down, but may be useful in other orientations. Ultimately, I ended up removing the tape, but it did work to mask areas of the sensor if that's what you want to do. Sounds like you want as much sensitivity as possible so its not for your application, but I thought I'd mention it since others might want to try. Cheers, Todd

Michel, 3. Both, but I understand that they both take time. My previous estimates of 1-2 seconds may be longer than it actually takes but the point is that they're slower than I'd like them to be. It's the scene adjust delay that causes most of my "bugs". The bug occurs when I have manually pressed the hallway dimmer switch. Since it is a locally applied command, the hallway dimmer immediately goes to the preset FAST OFF, OFF, ON, or FAST ON level, which is what I want it to do. The appropriate program for state -1, 0, 4, or 5 is then activated which sends the scene adjust value to the scene and dimmer. If the hall motion sensor sends an "ON" command before the adjust scene commands are finished doing their business, I get into an unknown condition. The light sometimes turns off or to the previously set on level which is not what I want it to do. I know it's too slow (from previous experiments) when I use programs (not links to the motion sensor) to activate the hallway switch. That's where I started in this whole journey in the first place. It's become esoteric now, but since I've gone this far, why not go the full monty. My whole hallway motion scheme is described below in the most explicit way I can think of. I'll sign off here and let the code do the talking from here... Cheers, Todd I created a scene that I call "Hall After Motion". "Dimmer - Hallway" is the responder "Motion - Hall - Sensor" is the controller. When I highlight the "Hall After Motion" scene entry in the MAIN device/scene tree, I see "Dimmer - Hallway" show up in the main panel on the right. -- This is the scene that I'm adjusting in my programs below. When I highlight the "Motion - Hall - Sensor" device under the "Hall After Motion" scene in the tree, I also see "Dimmer - Hallway" show up in the panel in the right. -- This is the second adjust scene value I'm adjusting in the programs below. I then created a state variable called "s_Hall" to keep track of the current state the hallway lighting system. The rest of the post contains all of the programs that run this whole scheme. They aren't perfected, but they do work pretty well, most of the time. I'm trying to minimize the bugs... THESE ARE THE SCHEDULE BASED PROGRAMS WHICH ARE MY "AUTO MODE" VARIABLE VALUES OF 0, 1, 2: Hall_Auto_Sched_1 If From Sunset + 2 hours and 30 minutes To Sunrise + 2 hours (next day) Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 30% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 30% (On Level) Set 'Dimmer - Hallway' Off $s_HALL = 1 Else - No Actions - (To add one, press 'Action') Hall_Auto_Sched_2_0 If From Sunset - 45 minutes To Sunrise + 2 hours (next day) Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 50% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 50% (On Level) Set 'Dimmer - Hallway' Off $s_HALL = 2 Else In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 0% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 0% (On Level) Set 'Dimmer - Hallway' Off $s_HALL = 0 THIS IS THE TRIGGER THAT STARTS TIMERS WHEN IN "AUTO MODE": Hall_Motion_TRIGGER If Control 'Motion - Hall - Sensor' is switched On And ( $s_HALL is 1 Or $s_HALL is 2 Or $s_HALL is 3 ) And $s_HALL is not 0 And $s_HALL is not 4 And $s_HALL is not 5 And $s_HALL is not -1 Then Wait 2 seconds Run Program 'Timer for Hallway_Short' (Then Path) Else - No Actions - (To add one, press 'Action') THESE TRIGGER THE STATES THAT SUPPRESS OR DISABLE THE SCENE LINK BEHAVIOR BY MATCHING SCENE ON LEVEL TO THE DESIRED LEVEL: Hall_SW_FAST_OFF_neg1 If Control 'Dimmer - Hallway' is switched Fast Off Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 0% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 0% (On Level) $s_HALL = -1 Run Program 'Timer for Hallway_Long' (Else Path) Run Program 'Timer for Hallway_Short' (Else Path) Else - No Actions - (To add one, press 'Action') Hall_SW_FAST_ON_5 If Control 'Dimmer - Hallway' is switched Fast On Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 100% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 100% (On Level) $s_HALL = 5 Run Program 'Timer for Hallway_Long' (Else Path) Run Program 'Timer for Hallway_Short' (Else Path) Else - No Actions - (To add one, press 'Action') Hall_SW_OFF_0 If Control 'Dimmer - Hallway' is switched Off Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 0% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 0% (On Level) $s_HALL = 0 Run Program 'Timer for Hallway_Long' (Else Path) Run Program 'Timer for Hallway_Short' (Else Path) Wait 30 seconds Run Program 'Hall_Auto_Sched_2_0' (If) Run Program 'Hall_Auto_Sched_1' (If) Else - No Actions - (To add one, press 'Action') Hall_SW_ON_4 If Control 'Dimmer - Hallway' is switched On Then In Scene 'Motion Responses / Hall After Motion' Set 'Dimmer - Hallway' 50% (On Level) In Scene 'Motion - Hall - Sensor' Set 'Dimmer - Hallway' 50% (On Level) $s_HALL = 4 Run Program 'Timer for Hallway_Long' (Then Path) Run Program 'Timer for Hallway_Short' (Else Path) Else - No Actions - (To add one, press 'Action') AND FINALLY, THE TIMERS THAT TURN OFF THE LIGHTS AFTER A TIME: Timer for Hallway_Long If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Run Program 'Timer for Hallway_Short' (Else Path) Wait 2 minutes Set Scene 'Motion Responses / Hall Fade' Off Run Program 'Timer for Hallway_Long' (Else Path) Run Program 'Hall_Auto_Sched_2_0' (If) Run Program 'Hall_Auto_Sched_1' (If) Else - No Actions - (To add one, press 'Action') Timer for Hallway_Short If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Run Program 'Timer for Hallway_Long' (Else Path) Wait 20 seconds Set Scene 'Motion Responses / Hall Fade' Off Run Program 'Timer for Hallway_Short' (Else Path) Else - No Actions - (To add one, press 'Action') If you were really paying attention, you might wonder where the state for 3 comes from. I'm holding that for another TBD auto mode that might be used for security or a later time at night, etc. There shouldn't be a way for the s_Hall variable to get to 3 yet, but even if it did, it would be reset at the next scheduled auto mode update. If you made it this far, thanks for hearing me out!

Lee, As I mentioned in the above posts, I have tried using programs triggered by the Motion ON to turn on the responder. It works fast enough for all of my other applications, but not for the hallway. I can see why it works for your bathroom, like it does in my other rooms, because when you are going into the bathroom, you typically come in and stop. For my short hallway, you are already through it before the lights turn on when I use a program to turn on the dimmer.