ergodic

I won't be doing the oil shutoff kill switch after all. It aborts the cool-down cycle and everything related to a 'normal' shutdown. Not a really good plan I think. So the only way I can see from the prints I have would be to splice directly into that rocker switch on the generator and simply make it think it's been turned off (center position). I haven't looked at the physical wiring under that panel to see how nasty that would be to do cleanly. I also have to talk to service to make sure they'd be OK with it and not affect the warranty.

I've already tested the oil sense idea this morning and I think it should do the job, though I forgot to check how easily it comes back once it's faulted that way. I've installed a low profile outlet inside the transfer switch to plug in the iolinc there, but I need to now build a little modular spade lug insert pigtail I can put inline at the oil switch to insert this run easily and without cutting into the Generac's wires or connectors. Service is fine with it as long as it's easy to pull out.

Thanks. That's a good idea. I wasn't even thinking outside the transfer switch. There's actually an extra (green) wire in that control cable, if the circuit is on a common ground I can use it, though it wouldn't be much to run another little cable. Or I could just stuff the iolinc inside the generator itself - signal gets there just fine. I'll let you know once I try it. I want to talk to the service contract people to be sure they're OK with that mod.

I just completed the install of a 20KW Generac generator at the house. This post is just to share the experience as it relates to the ISY and Insteon. I'd also like to thank the several forum users who corresponded with me in advance of my getting the unit as it helped me know what to expect. The Generac unit and whole-house transfer switch are straightforward installs and it only took about a day including the propane piping and so forth. There was debris lodged in the 1/4" propane feed line that took another couple of hours to figure out - it was causing the unit to shut down after starting. But other than that no real install problems. (But I've decided to start a "tray cable is too damn high" party. Residential tray cable is now running about $1 per INCH.) There is one odd part of the design of this unit I will warn you about: that little 6-wire 18ga Generac control line is carrying full 240V line power to the generator unit for it to sense utility power. There is no isolation or step-down, just fuses on each of those 3 lines. No kidding. I discovered this the Bad Way when tying it up and I accidentally nicked through the thin insulation on the bell wire, touched one to the metal flex and spent most a day looking for a very-hard-to-find 5A fast-blow mini fuse. (thank you Fuseco in Laguna Hills, CA.) My main concern was being notified when the generator goes on or off if we're not here via SMS. To do that I wired up an Smarthome Inlinelinc with sense. The Inlinelinc is powered from house power (utility or generator) and its sense lead is tied to one leg of the Generac output, all just simply stuck inside the roomy transfer switch box itself. The Inlinelinc load is of course not connected to anything, we just want the sense. The picture below shows it wired-in at the bottom right-side cabinet, just below the neutral bonding plate in the transfer switch. It is secured with a little velcro on the back and a tie wrap, there are no useable mounting holes. The power for the Inlinelinc is run through the conduit to the main breaker box on the left and tapped from the same breaker that connects up my access points below the breaker panel. I did observe that the Inlinelinc is more fussy than most devices about signal so getting it close to an AP is probably worthwhile. This setup also means the Inlinelinc loses power for a few seconds during the switchover. This is harmless and causes no issues. I also did scope the Generac output on advice from several people. The 20KW Guardian is the largest of Generac's true-sine units and I saw absolutely nothing to concern me. No spikes during the transitions and no h/f noise. There is a little visible distortion in the A/C waveform which matches exactly with what I see when I'm on utility power -- just the way the house loads. Frequency bobbles around a bit from 59.4Hz to 60.5Hz. No big deal there either. I have no worries about the Generac causing any problems with Insteon. Everything communicates fine. What does cause an issue is the Generac sense, which bounces around during its cut-in and cool-down phases while the voltage is stabilizing. This causes the Inlinelinc to "jitter" from off to on to off quickly and randomly in those intervals. If you're looking for an SMS text message from this, you'll definitely get a few! I initially tried to solve this with hardware: I breadboarded a little RC-diode circuit to try an smooth all this out, but never could come up with anything reliable. I still don't know if it is because the Inlinelinc sense expects A/C, or there's just too much variability, or I was just tired. I do know for sure my wife was very tired of my testing. Anyway, this is the digital age, so we ought to solve it with software anyway. To fix this we just need a few ISY programs to sense the transitions over a long period, ignoring short on/off sense line changes of a few seconds. I eventually settled on 7 second or less fluctuations and a wait of 90 seconds to determine that the unit is really on or off. There are arguments for other numbers, but these worked fine the first time. These first 5 programs are a little 3-state machine that does the on-off smoothing. They use two state variables: $Generac.On.State to track the state of the state machine itself, and $GeneracCurrentStatus as an "output." //GENERAC.B0 (waiting to come online) If $Generac.On.State is 0 Then $GeneracCurrentStatus = 0 //GENERAC.B1 (Generac sense is on. Ignore short off transitions) If $Generac.On.State is 1 Then $GeneracCurrentStatus = 1 //GENERAC.B1 If //Off transition on Generac. If not too long then ignore it, o/w reset to B0 after wait $Generac.On.State is 2 Then Wait 7 seconds $Generac.On.State = 0 //GENERAC.C1: Jump to state B1 when sense goes high If Status 'Generac Sense' is On And ( $Generac.On.State is 0 Or $Generac.On.State is 2 ) Then $Generac.On.State = 1 //GENERAC.C2: Jump to state B2 when sense goes off If Status 'Generac Sense' is Off And $Generac.On.State is 1 Then $Generac.On.State = 2 These next two programs implement the on and off waiting period. They use $GeneracCurrentStatus as an input and, after 90 seconds of an unchanged $GeneracCurrentStatus, they set the final state variable we're actually interested in: $GeneracIsOn. //GENERAC.C2: Jump to state B2 when sense goes off If Status 'Generac Sense' is Off And $Generac.On.State is 1 Then $Generac.On.State = 2 //GeneracGoingLive If $GeneracCurrentStatus is 1 Then Wait 90 seconds $GeneracIsOn = 1 //GeneracGoingOff If $GeneracCurrentStatus is 0 Then Wait 90 seconds $GeneracIsOn = 0 The last program uses $GeneracIsOn and is the one that actually drives the notifications out. //Generac.SendMessage If $GeneracIsOn is 1 Then Send Notification to 'steve.sms' content 'Generac.On' Else Send Notification to 'steve.sms' content 'Generac.Off' One more thing I'd like to implement is some way to remotely turn off the generator via the ISY regardless of whether utility power is on or off. It is easy to fire it up by simply opening one of the utility sense leads with a relay, simulating a power failure. But as yet I've found no control point inside the transfer switch where a generator-off can be done easily and it may not be possible. But at $4/gallon for propane and a 250 gal tank, I'd sure like to.

Thanks Lee. Made a huge difference. Haven't done anything much with it yet, but it all seems now to be working the way I would expect under 3.2.6

So I'm trying to test out an inlinelinc w/ sense connected to my ISY (f/w 3.1.17). The device is labeled as a 2475S2. I'm able to add it to the ISY as a manual link device using the "B2475S - In-linelinc relay W/ sense". But once in there it just shows in the "on" state. I don't have a load connected yet, does it require one? Even when I push the on/off buttons manually, it still always shows "on" in the ISY and I see no comm traffic. Tying the yellow sense line to hot or ground makes no difference either. I'm starting to think I don't understand how this device is supposed to work.

skripo: I may not be getting all of it, but as I understand it you want the staircase light level in the scene to be 100% during the day, and 30% level at night when turned on. And in either case it should shut off 30 seconds after being turned on. I'm unclear on the purpose of the ramp rate business since it seems to always be at 2 seconds. And I don't think you want to use a fade-down, just a normal control off command should do. While it might work, fade-down is intended for IR commands where you do a subsequent fade-stop. You're trying to stuff too much into one program. ISY programs generally should be quite small and dedicated to just one bit of logic. Let the trigger conditions do the work to tie those bits of logic together. In this case, the program is readjusting the control scene settings every time the light is used, which you don't want: that's a lot of Insteon traffic and it takes time, especially if reliability isn't great. And I think you are altering the status of the light that the conditions are triggering on which will cause the program to self-cancel and run its else part. At any rate it all gets too confusing with so much going on in there. So just bust it up: Create one program to run at 10PM that simply sets the scene level for the control to 30% and exits. Then a second program to run at sunrise that sets the scene level for the control to 100%. Then create a third program that triggers on the control coming on, and turns it off after 30 seconds. If there are still problems, they'll be much easier to sort out. I'd agree 100% with LeeG: if your system is not yet reasonably reliable, programmatically modifying control link records isn't the ideal thing to be attempting. At this point you might want to do a link table compare on the control, and restore it if it shows mismatches. Corrupt link tables in devices can cause all kinds of odd problems.

I have had this subscription problem since the early 3.x releases. I often have to close and re-open the console a second (or 3rd or even 4th) time before current state shows up. If you just try logging in again you will usually get connected - a restart shouldn't be necessary.

There are LAN addresses (your inside network) and then public, Internet addresses. Your provider gave you a fixed public IP. Your LAN addressing is still the same. In almost all situations your router will translating the one Internet address you have to your various inside addresses. So changing your public-side Internet address should not, in most cases, require any change to the ISY or anything else on your inside network. The public IP setup inside the router itself is enough. It will only change how you access your ISY from outside - you now use the new IP to get to your router and the router should direct traffic based on the port you assign to the ISY and mapping rules. This all gets beyond what you need to deal with at the moment. Putting the ISY at a public IP address will make it inaccessible to your inside network simply because your router sees that address as an outside (Internet) address and tries to send all the ISY traffic to the Internet. As I read your post, that's what you did, yes? I don't want to get too technical here - there are more esoteric situations that go far past this and since you requested a fixed IP there well could be other things I'm not taking into account, but my initial suggestion is to put the ISY back the way it was and it should work fine. Unfortunately that won't be entirely simple now since you can't talk to it. You either need to: (1) use a serial connection to change the addressing in the ISY, (2) hard-reset the ISY, let it pick up a DHCP address from your inside network and then restore it from a backup, (3) temporarily setup a workstation with the public IP subnet you've used so you can talk directly to the ISY the way it is currently configured. The workstation will then talk directly to the ISY and not send that traffic to the router. #3 is the easiest but it is hard to explain the configuration if you aren't familiar with doing it. #2 works quickly but only if you have something that talks serial to the ISY. Which otherwise leaves the reset / restore. Do not attempt that if you don't have a valid backup. The ISY itself is fine, just not talking to you, and #1 or #3 are available.

"- State variables now use value in the event for comparisons/conditions" Could you put a little more flesh around this fix comment?

TJP_426: My suggestion for this kind of thing usually is to break the triggers and the actions into two separate programs so a false trigger condition re-evaluation cannot interrupt itself. If there are any problems with your logic they also will be easier to spot. If Control 'Garage Door Sensor' is On And Status 'Kitchen - Under Cabinet' is Off And From Sunset + 15 minutes To Sunrise - 3 hours (next day) Then Run Program DoLights (Then Part) Else - No Actions - (To add one, press 'Action') //DoLights Program If - No conditions Then Set 'Kitchen - Under Cabinet' On Set 'Laundry Room - L [East]' On Wait 5 minutes Set 'Laundry Room - L [East]' Off Else - No actions DoLights has no conditions, so it only runs when it is explicitly called. And it also cannot be interrupted once started unless you create another program that calls its Else. For example, you might want to create another program to cancel (run the Else part of DoLights) if somebody manually changes the status of the lights while the program is in the 5 minute wait. With this, it shouldn't matter to the execution whether you use Control or Status, though Control is probably the better choice.

If you ever had X10 (or even if you didn't) possibly those codes could be in there. You might try a factory reset on both devices and then do a restore-device on both from the ISY.

Thanks Michael. I'll watch that thread for a resolution. I'm hoping I won't have to get yet another PLM (not to mention the spare one I keep.) For now I've moved the PLM on to the power strips controlled by the big red power button that I've told my wife to press when things don't work.

I had a situation today where none of the motion sensors were signaling status to the ISY. I couldn't see any problem with the ISY itself so I just went down and unplugged the 2413S and plugged it back in. And things all started working again. I've had a couple of PLM failures in the past that required replacement. But I've never seen one lock up like this, or at least that's the only explanation I can see. Does that happen? Is there any experience to say it's getting ready to fail? I did note when I unplugged it that the (normally white) LED flashed red very briefly, which I've never seen a PLM do before.

Let me suggest a step-by-step approach that might help get you past the initial difficulties, and also will help us separate your setup problems from possible communication issues: 1) Start over. Delete all devices and scenes from the ISY. As already recommended: now add your devices only by linking them in the ISY. Do not manually link anything (ever). Select "Clear all links" on the linking menu when you add the device so it won't matter what state the device was in previously. Now if you cannot link a device via the ISY link dialog you know have a basic communication problem to be solved before proceeding on. Don't waste any effort trying to add other devices or create scenes yet until it's figured out. Communication problem usually affect the entire system or a good chunk of it, and you'll just get deeper in the hole if you try to slide past it. Lots of good comm. troubleshooting posts are on this forum. If you can't figure out what it is, post back those details. 2) Now create a scene for that device's paddle or primary load button. Make it a "controller" (which also makes it a "responder") in that scene. Call it something like "Multiway: devicename". So for now the scene will just have that device in it. Again, if the ISY cannot create the scene successfully you are dealing with a communication problem we need to figure out before moving on. Do a right-click... Diagnostics... "Show Device Link Table". When all the device's links are displayed (this can take a minute or two), click "Compare" to make sure the link table in the device matches with the ISY/PLM. This is actually a pretty tough test of ISY-to-device communication. 3) Now run the "Scene Test" from the ISY Tools menu a few times - preferably at a few different times of the day. Make sure it reliably shows "successful". Once again, if it doesn't, we have to look at communication. 4) If you're here, you have working 1-device scenes. After you've added all the devices and their scenes you should be able to add the buttons on the other devices you may want as other controllers for a scene. When you do that, you will have full control of the load from any of the buttons/paddles. And activating the scene in the ISY should set the state of all the scene's devices. Now run the ISY scene test again to check communication with all the different controllers in the scene. Also check the operation at the individual buttons to make sure the devices are communicating successfully directly with each other. If you don't want to keep one of these scene after you're done successfully checking the device's setup, you can of course delete it. I don't. I create a scene for each device when I add it to the ISY, even if it is just itself. As a little encouragement, I can tell you I did a whole-house ground-up remodel about 3 years ago with the ISY. Every single switch in our house is now Insteon, run through the ISY. You will get it working nicely if you're able to get past this initial 'frustration' stage. And regrettably, I will say it is also possible if you find communication issues it may turn out you have to spend a few more $ on filterlincs or access points to resolve it. The nature of the beast I'm afraid. If you want to feel a little better about that, price a Crestron or Control4 system.

I run HS2 and the ISY, but I use the ISY plug-in for HS exclusively, no PLC/PLM is connected to HS. This setup actually works quite well IMO. The plug-in even exposes variables and program state, and has an API. As Michel said, the problem you'll have with your proposed configuration is that the two controllers won't necessarily know about each other's links or changes. With the ISY plug-in for HS, everything drives through the ISY so that isn't a problem. I'm not aware of any Insteon-specific functions in one vs. the other. The HS scripting model is easier to deal with for more complex logic, and HS of course supports a fairly broad array of other plug-ins for various technologies. And it is web-based, not Java. But it isn't a stand-alone device as is the ISY.

I've had a number of ISY lockups like that since V3.x. No response from the ISY and a hard power-cycle required to get it going again. Most occurred either during or right after removing or replacing a device, though a couple were just random with nothing special happening. Doing device/link stuff with an EZX10RF device seems to be especially susceptible to this. I haven't seen any ISY lockups since 3.1.13, but it's recent and I haven't done much device adding/replacing in this version.

Short answer: Regrettably, no. The console requires full Java. (Android imbeds a sort-of Java clone.) Would be nice though. I use an RDP remote desktop app to connect to a PC when I need to see/use the admin console directly. A VNC app would work as well. It is a little clumsy, but workable when you need it. If you just want to control devices, there are lots of browser-based solutions available, including the ISY itself of course. If you don't mind spending a little money, HomeSeer 2 is http based, and the ISY plug-in for it works well and exposes most things including programs. If you need the diagnostic/logging/linking stuff though, then no option I know of other than a remote control app.

In the category of "it's usually something stupid..." (with me anyway) I'm wondering if this could be something as simple as a mechanical or alignment issue with the switch or 6-button keys or bale. The 6 and 8-button devices are of course are designed to be convertible to each other with change kits, and these are very short throw switches. Possibly pressing the B button is really, physically causing the "Off" switch to make intermittent contact on rare, random occasions? I know not likely, but maybe. You could pull the KPL plate and keys and have a look. That won't necessarily help if the problem is a switch contact itself, so you could also try putting in a brief (2-second) disable on the program when the B button is pressed to see if it prevents the problem from triggering execution. Might be a workaround. Also be interesting to know if it also happens if you assign one of the other three aux. buttons instead of B. (If it is just B it kind of blows this out.) gviliunas replaced his switch and apparently still had the issue, but it still might be worth checking into since there's no better theory on the table at the moment.

Shawn: I find the easiest way to deal with the self-canceling problem is to simply break it in two: put the triggers and tests in one program and your actual execution logic into a separate program: //Program IfMotion: If Status 'LightSwitches / Front Entrance Switch' is not On And Control 'Sensors / Motion Entrance-Sensor' is switched On And From Sunset To Sunrise (next day) Then Run Program DoMotion (Then part) Else //Program DoMotion: If Then Set 'LightSwitches / Front Entrance Switch' On Wait 30 seconds Set 'LightSwitches / Front Entrance Switch' Fast Off Else DoMotion only runs when IfMotion calls it (because DoMotion has no conditions or triggers). Any false tests and resulting unwanted 'Else' execution just gets 'absorbed' by the IfMotion program's Else part, and so cannot cancel or affect DoMotion if it is already running. If you have some reason to actually want to cancel DoMotion, you can always run DoMotion's Else part from another program. Doing it this way makes it easier to understand what's happening, you shouldn't need any variable artifice, and whatever logic problems there may be are a lot easier to diagnose. It would be really nice if the ISY just allowed you to delete the Else clause since you rarely want it anyway but this works OK.

You might look at the just-announced Autelis serial network adapter. Not inexpensive, but it is designed to work with the ISY directly (via variables) which is worth something. Also the Global Cache iTach models - there is a wiki entry and forum post on using them (the iR models anyway) with the ISY network module. With other serial servers you should be able to manage them directly through the ISY network module if they can be operated via network management commands and don't require their own drivers, but there might be a steep learning curve to get it talking with the ISY. Otherwise you have to keep a PC in the mix. If you plan to keep the X10 stuff, you might look at just replacing the W800 with an EZX10RF and ditch that serial. I personally would not look to be expanding the use of serial ports. I run the ISY and HS2 also (using just the ISY plug-in, no PLM). I have a little netbook dedicated to HS2. I got a nice dual-channel oscilloscope on eBay once for around $50.

I suppose that's my question: what commands could you possibly send to an AP? I did disassemble it this evening, and noticed it is clearly designed to accept a daughterboard. So possibly it can be morphed into something more advanced? And then that something else might need a hardware address.

This finally turns out to have been a failing access point. I have two AC receptacles dropped down from both sides of the electrical panel in my garage. An access point is plugged into each. It turns out to have been most unfortunate to hide these behind the washing machine. I'd given up on ever figuring this problem out. But I happened to look back there the other day and noticed one of the access point's lights was flickering madly, dimly and continuously and the other phase wasn't doing anything. Replaced that AP and now everything is back talking at 100% again. It has also mostly ended the mysterious "unable to communicate" motion sensor pop-ups in the ISY. So add 'failing access point' to 'RFI', 'V.35,' 'bad PLM,' and the other "X" communication factors to check when the problem is impossible to explain by signal quality issues alone. BTW does anyone know why access points have Insteon hardware address labels?

Modest bug (I think). If you remove a device from the ISY and then re-add the same device back in, programs that reference the device in conditions will again show it (under the newly re-added name). I'm guessing this is because the ISY is indexing the device by it's hardware address, so when it reappears, programs are once again able to access it. However, the device doesn't actually trigger the programs any longer. IOW the programs show the device in the conditions and to all appearances are proper, but they don't actually work. If you then go in and manually change the device in the programs to anything else, and then change it back to that device, the ISY seems to 'hook' it back and the program then triggers as it should. I haven't done much testing on this, but that seems to be what happens.

You're correct: all that's been done (several times) and I'm on 3.1.9 I think I have a log extract where the MS Nack happens. Does this contain anything useful? 11.A4.43 is the MS, it currently is a V1 device. Tue 10/11/2011 10:36:09 AM : [standard-Cleanup][11.A4.43-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Tue 10/11/2011 10:36:19 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:36:19 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:19 AM : [ 11 A4 43 1] DON 1 Tue 10/11/2011 10:36:19 AM : [ 11 A4 43 1] ST 255 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:36:20 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:20 AM : Duplicate: ignored Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 00.00.01 CB 11 01 LTONRR (01): Process Message: failed Tue 10/11/2011 10:36:20 AM : [standard-Group][11.A4.43-->Group=1] Max Hops=3, Hops Left=2 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 18.D0.38 41 11 01 LTONRR (01) Tue 10/11/2011 10:36:20 AM : [standard-Cleanup][11.A4.43-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Tue 10/11/2011 10:36:20 AM : [iNST-SRX ] 02 50 11.A4.43 18.D0.38 A3 BB 81 (81) Tue 10/11/2011 10:36:20 AM : [standard-Direct Nack][11.A4.43-->ISY/PLM Group=0] Max Hops=3, Hops Left=0 Tue 10/11/2011 10:37:02 AM : [iNST-SRX ] 02 50 13.ED.64 00.00.01 CB 11 01 LTONRR (01) Tue 10/11/2011 10:37:02 AM : [standard-Group][13.ED.64-->Group=1] Max Hops=3, Hops Left=2