apostolakisl

Lee, aLF, or others, Any comments on how well dual band works while on a non-perfect sine wave? How about the "inverter" style generators. Are they clean enough for Insteon?

In your second program, move the wait 1 second in front of the +=1 line. The reason it is running up too fast is because every time 1 gets added to that variable, the program triggers again and it re-evals the if. You actually don't need the repeat clause at all in either program. They are both getting reset every time the variable changes and the program starts all over from scratch.

That would work. You would want to power the inline lincs with a UPS. You wouldn't necessarily need to have these programs run at startup. If status inline linc generator is on then send email generator power on If status inline linc city power is on Then send email city power on Else send email city power off These programs will run every time the status of the in line lincs change. When you first install the programs or boot the ISY, these will both be "on". No email will be sent at that time if you don't have a "run at startup" checked. If power goes out, both will change to off, and both programs will run, but the first program won't do anything (else is empty). The second program will send the else email (city power off). When the generator turns on a few seconds later, the first program will run again, and this time it will send the then email (generator on). When power is restored, I assume your generator will switch off and back to city power seamlessly so first program does nothing. The second program will run sending the "city power on" email. The cai solution could also work the same and be cheaper, it would only cost about $40 plus some random wall warts you probably already have sitting around. Except, you need a computer running all the time for io-guy's program. However, there might be a chance that ISY adds some direct linking to the CAI board, we shall see.

Nice work. Here is another way. Io_guys program has a "heart beat" it sends to ISY. If the cai is plugged into a regular plug (not a ups), when the power fails the heartbeat will stop. You could use this to trigger an email. Of course your router/modem/ISY would all need to be on UPS.

I went through my box of old wall warts, found one with the right plug, cut it off, and wired it up to my terminal strip 5v lead. The terminal strip is fed by an ATX power supply and powers all of my 5v (and 12v stuff on a second terminal strip). It works beautifully. Very clean, reliable, stable voltage through all amps power supply. And I was able to retire about a dozen bulky, ugly, old, in-effecient second rate wall warts and open all kinds of new plugs.

I do have the elk module and it would appear based on your screen shot that it has added some pages that you don't have. The Elk module appears to add the ability to control what is in your export file. You don't need the Elk module to have the same basic Elk integration that you had before. I assumed you tried hitting the refresh topology button before exporting as well. I assume that hitting that button generates a new export file adding any new devices/scenes and subtracting any removed ones. I am sure Michel can confirm if true. In short, I don't know why you can't connect with your updated firmware. I did not have any trouble communicating with my Elk with the earlier 3.1.<15 versions prior to adding the module. EDIT: WAIT, yes I did. It had something to do with the password. I was not the only one. To fix it, I purposefully entered the wrong one password, saved it, then re-entered the correct password, saved it, and it worked.

Check under Configuration/Elk/Export and add the new lights to the export file. Check under Configuration/Elk/Configuration and make sure the ip/ports are all correct.

but this does not send multiple OFF commands, as reqested earlier. I read this to mean "multiple" as in 3 different lights, not multiple "offs" to each light. Perhaps I am speaking incorrectly to that point, but I think the OP doesn't understand exactly how scenes work. A scene instruction (on/off) sends a SINGLE Intseon power line command. All Insteon devices in your home will hear that command (barring bad communication issues). When a particular device "hears" that command it will check its link records to see if it is supposed to do something (it asks itself "am I in this scene"). If the answer is "yes" then it does whatever you programmed it to do as part of that scene. If it is not in the scene, it just ignores it (actually will repeat it depending on the hop count).

If you really want to monitor your kegerator send me a PM. I have just patented a system for monitoring kegs using a special coupler I designed and a wifi enabled control board. It posts to our webserver and the user can log on and see how much beer is in the keg as well as the temp, all in graphical form over user specified time periods. It does not monitor consumption directly, it monitors liquid still in the keg and consumption is then calculated from that. It also will send email alerts according to user preference. It also has an optional feature for untapping the keg the instant it goes empty keeping gas out of the beer lines (this is primarily for long glycol systems). I am testing the first prototype right now and it is working quite well. Version 2 should be ready to test next month which I will place in our test bar/restaurants (and my own kegerator of course). If that goes well we will go retail in the early summer. It creates usage reports and notifies the distributer for re-stocking as well. The system is geered mainly for inventory control at bars and restaurants, but we plan on having a scaled down version for the private kegerator.

You can do that with a scene but you need to think backwards. Create a scene and put all of those lights in it. Set the level of all the devices that you want "off" when you go to bad as "0". Set the bedroom light you want on to "x%" where x is however bright you want it. Include whatever ramp rates you want on each device. When you go to bed you need a keypad linc or some other insteon device or a program to turn that scene "on", which counter intuitively will actually turn most of the lights off. If you want a delay, you can use slow ramp rates, or you can use a program with a "wait" command. When you get into bed, turn the scene "off", then that one light in your bedroom will turn off, the other lights will stay off.

I would actually tell you to skip the program alltogether and just link the triggerlinc to the light switch. This would do the same thing as the program but do it directly, no middle man. Since you have no delays or other complex issues programmed in, just on when open, off when closed, a direct link would 100% cover you. EDIT: Never mind, I forgot about the sunrise/sunset thing. OK, so try checking your log and see when ISY is receiving the status "on" and when it is sending the "on" to the switch. That would rule out ISY as the delay source. Also, you could try direct linking it to the switch temporarily and see if the delay still exists. I own no triggerlincs so I don't know for sure, but it is also possible that they have a purposeful delay there to prevent false openings from vibrations and the like.

It has been a couple weeks now with not a single malfunction. I believe you have fixed it!

The best way to solve the problem is to have a thermometer that clicks on at one temp and off at another. For example, on at 70, off at 73. Then a simple link would do the trick (no programs). No matter what program you use, you need to set the primary program to run at boot and you will want to run it manually any time you make an edit. Otherwise, if it is already "on" when you start things off and the heater is "off", you will never get a trigger to turn on the heater (a status change, or control on) I think oberkc program will do the trick more simply than mine.

You should use "Status" not "control". If it cycles too often set up 3 programs If Status workshop heater thermometer is below temp (on?) Then set workshop heater on run program 2 then clause Else - - If - - then wait 10 minutes run program 3 if clause else - - ***this program must be disabled**** If status workshop heater thermometer is below temp (on?) Then run program 2 then clause Else set heater off These three programs will run the heater in 10 minute intervals. If the room is still not up to temp after 10 minutes, it will run another 10 minutes, and so forth until it is up to temp. Then it will shut off and wait for the room to drop below temp again. You would want to set the first program to run on boot and also you would need to manually run the "if" the first time to get it started if the workshop is already below temp.

To point 2. It was already covered but I'll add a little. Keep in mind that devices are set as controllers and/or responders. When you have a virtual multiway, all those devices are controllers for all the other devices (meaning that all devices controll each other and respond to each other). So PHYSICALLY acting on any of those devices (by that I mean actually touching it) propogates through to all of them. HOWEVER, if one of those devices is acted upon by the ISY or some other switch not in the scene, it will behave ONLY as a responder, none of the other switches in that virtual multiway will change. Only a switch that is PHYSICALLY acted upon will control another switch. This is how one switch can respond to multiple scenes where perhaps the other switches are not intended to be changed. So, to have all the switches in a multi-way act in sync, you must program the SCENE to change, not just one device. I hope you now have your items in order. I think you did some extra work there manually rebuilding all your scnes. It would have been easier to simply set the system to restore all devices/plm and then go out to dinner and a movie, but oh well. In the future try not to factory reset your plm by accident But if you do, be sure to restore the plm, not restore an old backup of ISY.

Michelle will get you out of this. But realize that when you restored a backup of your isy that the any links you created since then would not be known to the isy but would still exist on the devices and plm. And you had a plm which sound like it got erased and then had some links added in. You've now got a hodge podge of devices in various states of linkage and none of it on the same page. I suspect that you may find it easiest to factory reset every single device and then have ISY re-write all links to all devices and the plm. This will for sure put everything back on the same page. Realize that the ISY does know every single link for all devices and the plm and can re-write all of that. But let Michelle guide you through.

A suggestion, Put all of the switches that control outdoor lights in one scene as responders. Call it "outdoor lights". Instead of listing each light in your "then" clause above, you just list the scene. This will decrease traffic and increase probability of proper execution. Also, it might be nice to then have a kpl button in your house that you set as a controller for that scene, so if you wanted to have all the outdoor lights turned on (hear something suspicious), you can just hit one button. I have a button next to my bed that does that. Also, you can use that same button to turn them all off. And you need to figure out why your ISY isn't getting updated. Probably it is an issue with links as mentioned. If the links are wrong, just right click and hit "restore device" and that rewrites them.

Indeed I should have included this change. Yes, that to, I edited my above post.

Solve this by splitting the program in 2. And of course keep the change that runs the "if path" not the "else path" as indicated. If From Sunset To Sunrise !!!!! NEXT DAY !!!!!! And Control "Main hallway Keypad C" is switched on Then Run program 2 'then path' Else -No actions- If no action Then Set Scene "Garbage Night" On Wait 8 mins Run program "Landscape Lights" (If Path) << Else no action In program 2, if you wanted to purposefully interupt it (allow the lights to stay on), you can always add something to the "if" clause that would evaluate false. Alternatively, you could put the stuff in the "else" section and put something in the "if" section that evaluates to true.

Thanks, I kind of thought that was the case. So, you would have to write the programs as I listed, otherwise, for example, if the 5 minute button were already running, and you pushed the 10 minute button, the 5 would keep going and shut off the fan prematurely.

I use a regular switch to control the fan rather than a kpl. It is a lot cheaper and doesn't confuse anyone. Tap on once it stays on for 5 min. This is what happens if someone uses it who has no idea about anything. Tap on twice (fast on), it stays on for 10 min. You could expand on that if you wanted more options. Fan off, click off, turn on for x minutes fan off, double click off, turn on for y min. Fan on, click on, stay on for z minutes. And so forth. As far as using kpl buttons. If kpl button b status is on Then turn on kpl load turn off kpl button a turn off kpl button c turn off kpl button d wait 5 minutes turn off kpl load turn off kpl button b If kpl load is turned off Then turn off button a turn off button b turn off button c turn off button d You could write 4 programs for each of the 4 buttons just like this. What will happen, if you push the load button only, it will just work like normal. It will stay on until you turn it off. If you pressed any of the 4 other buttons, it would turn the fan on (or leave it on if it were already on), turn off the other kpl buttons and abort their programs if already running. And after the specified wait, it turns the fan off. Potentially you could use the "radio buttons" mode which automatically turns off the other kpl buttons when you push one of the others, but I am not sure if that would also send an Insteon "off" mesage to the ISY so as to abort the other program if already running.

That is accurate. But it would only apply sparingly to me since I pretty much do every single update as it comes out and most of those updates don't make changes to the admin console. This is why I can be running 3.1.15 console and 3.1.16 firmware and not have any issues. But if I were someone who upgraded once per year, yes, things would be significantly off. In my experience however, the ISY is the only device I have ever used where the admin console is capable of being out of whack with the hardware. I think the most conclusive way to deal with this would be to have the admin console code on the ISY itself and when you log onto the ISY it downloads it to your computer. In this way you could never be running the wrong Java ware.

By "terminal" do you mean that console fails to function completely or is so riddled with errors that it is nearly unusuable? Personally, I have not found that to be the case. Of course, I am usually only accidentally running a console that is only a small revision different than the current. But I have discovered on a number of occasions that I forgot to upgrade my Java control panel on a secondary computer and had successfully used it extensively (only by chance discovering the wrong version).

While this may not be the best solution, perhaps it is a simple one that can be implemented with little or no issues. Can the "insteon finder" that pops up first before the admin console put the version in its title? Similarly, can the ISY show the version number accross its title? Or maybe at the login box? From my perspective, I have a number of computers I use to access the AC. After a firmware upgrade I always load the new admin console on that machine, but it would not be unusual for me to forget to do it when I run it at a different computer.

Every once in a while when I load the admin console it doesn't connect properly to ISY. Logging off then back on fixes it. I have never had to reboot the ISY to fix anything, except one time after a firmware update.