MarkJames

Actually that just made me realize why something I was doing wasn't working. I was using a photobeam connected to an iolinc to turn on a bunch of lights approaching my house. The code basically said If photobeam status ON set scene pathlights ON wait 10 minutes set scene pathlights OFF This would turn them ON but never turn them off. I see now why - when the sensor beam broke it turned the sensor ON which turned the scene on - but when the beam restored the conditions changed and were reevaluated. That terminated the program so the wait 10 minutes was never completing. I guess the right way would be to put the WAIT and the scene off in the ELSE portion Interesting... I'm gonna hafta be careful of this, I see. Thanks for the time you spent explaining it - this will save much hairpulling.

THAT is the part I was missing. I assumed each instance was allowed to run to its conclusion. OK... that opens up quite a bit of flexibility. Thanks, mark

Yes - but repeating every second without nested if-then would be an endless loop. It would never reevaluate the IF condition

Thanks, guys, I understand what you're saying. I was worried to continuously re-run the program from within itself as I was afraid I might run into some stack overflow issues if the program continuously recursed. Sounds like that's not a problem. Much thanks! Mark

Ahhh.. OK... that makes sense then... I was trying to understand it in light of a program I saw where the IF was executing and when the condition was no longer true the ELSE executed. I didn't understand why that would happen as in general a program would evaluate the condition and then execute the THEN or the ELSE - not both but in ISY it seems that the THEN can be executed and if the condition changes the ELSE will execute as well. A bit confoozalating. So... if I were to want an IF to continuously evaluate and continuously execute until the condition is FALSE then I could simply change part of the condition from within the THEN portion forcing the iSY to reevaluate the condition? Or is there a more direct approach? And thanks for both the link and clearing up the folder issue.

Thanks - that actually made perfect sense. I did two things to make it work. First I downloaded the 2.7.9 firmware as the iolinc options are better there and I could set it up as brad77 indicated (mine was wrong, it turns out - it was set for latch). Second I wrote the following code snippet so that the light for the door flashes to get your attention if the door is open It flashes the lights a few times, waits 10 seconds and then runs itself again. I wanted to use the repeat command for the flashing but I couldn't figure out how to stop a repeat - it seems once you hit repeat then the rest of your then statement is all repeat. Anyways - thanks all for your help. This works nicely now. Mark [/img]

Hi, all, Before I get too far into my ISY programming I wanted to clarify something that was confusing with my last home automation controller (a JDS Stargate). In the Stargate there was an IF statement and and IF (always) statement. The difference was with the IF statement IF (condition is true) ...these statements would execute ...but only once ...and not again until the condition has changed to false first this was useful for, say, a switch turning on. If you turned the switch ON, say a remote chime would ring. But now that it was on the chime would not continue to ring - however if you turned the swtich OFF and then ON again then the chime would ring again. The second form - IF (always) meant that so long as the IF condition was true the statements would continue to execute. In this format IF (always) condition is true ...ring bell ...the bell would continue to ring until the condition was false My first question is what is the ISY equivalent of these two functionalities. Second - In reading the programming manual the ELSE statement is a bit confusing. If time is 10pm AND button1 is on ... THEN ...... do this ... ELSE ...... do that When and how many times will the else execute? Or will it only execute if it has managed to satisfy the IF at some point? Clearly the ELSE would just continue to run all the time that it's not 10 OR the button isn't on. That can't be what's intended? So... my second question is basically when/how/how many times is the ELSE evaluated? Third - what if there are NO conditions? The language allows these - when/how many times do the THEN statements execute? Lastly.... Programs in a folder..... Can one put a condition on a folder like say Bed Folder (going to bed) ...if (bed mode button is pressed) ...THEN alllow programs in this folder to run ... prog1 in bed folder ... no ifs in this program ... then ... turn off all light ... ... progr2 in bed folder ... if temperature is below 65 ... then turn on electric blanket ... ... prog3 in bed folder ... no conditions ... turn on security system ... You get my gist - can there be a folder condition to cause a series of programs within the folder to run? Or is the folder condition merely to enable/disable the programs within the folder? (or is that reallly just the same thing?) Thanks for the help... understanding this before getting too far will go a long ways towards getting it right the first time Mark

Thanks for the link - that looks like just what I need. I'll try my hand at that tomorrow. I installed a photo-beam today so that as guests enter the yard the path lighting and front door lighting turn on. Insteon is so quick and reliable it works like magic. The photobeam turned out to be quite a bit of work to install. The wiring and all was easy but I had to make a custom bracket to hold it because of the relationship of my garage to my gate. The angle was really acute and the stock bracket that came with it wouldn't work. I'm trying to figure out a way to use a combination of the garage door opening and the beam being broken to decide if I'm coming or going. The whole coming or going thing is hard if you don't want to be burdened with pressing a button to actually TELL the system what you're doing. Thanks again - I'll post back how it goes.

How are your door contacts configured? NO or NC? I don't know that this matters but every little detail might be it. Oh.. and more significantly... are you calling momentary both momentary b or are you calling momentary: look at sensor - b? I have mine on momentary: both (which I believe is the smarthome equivalent of momentary c) Thanks, Mark

Hi, Michael, Sorry for the late reply. It's been deluging here for the last few days and I've not been inclined to do things that involve standing in the rain. Over 320mm of rain has fallen in the last 3 days - that's over 12 1/2"! Fortunately today the rain has stopped and the sky is clear. Things here aren't looking so great for the winter Olympics that start in less than 4 weeks. Much of the local snow has washed away and the mild, rainy weather is here for a bit. Anyways - I've downloaded 2.7.7 and upgraded my ISY. That all went smoothly. There has been no change to the method with which it interacts with the door, though. The iolinc is configured as momentary both - that's the only option ticked other than the LED. The contacts I'm using are NO. When the door is closed the sensor node reads OFF When the door is open the sensor node reads ON When I send an ON command it will set the door in motion - whether that motion is up or down it makes no difference. Sending an OFF has no effect at all. While the door is stationary - whether it's open or closed - if the relay is ON then sending an additional ON has no effect - the door will not move. In order to make the door move an OFF must be sent followed by an ON. I'm seeing many other ISY users garage programs that all reset the relay to OFF a few seconds after it is turned on. I'm assuming this is why they do it? I don't mind programming it this way - it's not really a big deal - I'm just trying to understand why it doesn't behave the way I expect it to. Thanks! mark

Thanks, Michael.... Only problem is that I can't find 2.7.7 anymore. It seems to be something one needs to sign up for. Could you please point me at it? Thanks! mark Oh.. and by the way - while I remember - I was sitting at my computer today for quite some time plodding away with the ISY software and after an hour or two I realized that I had been backing up and saving my changes every few minutes. I do that automatically as I'm so accustomed to things crashing on me. The thing is - the ISY software never crashed - not even a hiccup..... That's quite remarkable! Thanks for that!

I thought the same - that sending an ON should be an ON whether an off was sent first or not. But I do, indeed, have to send an off first. I've tried this both from direct control of the iolinc or with it in as a responder in a scene. As for my firmware - in an effort to make this work properly I upgraded from 2.7 which was the version I got it with to 2.7.6 which is what it's currently at. The smarthome manual states that the iolinc can be set up so that an on will cause it to open the door while an off will cause it to close. http://www.smarthome.com/manuals/74551qs.pdf near the bottom says this. Very confoozalating

Ahh.... Thanks for that. I read a lot of the code snippets people were using but didn't get why so much elaboration for what should be a simple task. My 2450's are brand new.... one would think they would work as advertised. Thanks again, Mark

I've searched and searched and I'm sure I'm doing something just silly but I can't figure out where I'm going wrong. I hooked up an iolinc as per the smarthome instructions and it works as it should - tap set and it opens - tap it again and it closes. I can't make it work properly from ISY though. I have it set for LED on TX and momentary:both. The time out is set for 2 seconds and this seems to be OK with my garage door opener I've confirmed that: When the door is closed the sensor reads off When the door is open the sensor reads on If the door is open and I send an ON it will close Once it's closed an off will NOT open it. In order to open it I have to send the off and then a subsequent on. In other words it only works in response to an ON command and not to the off regardless of the sensor input. Am I missing something obvious?

I thought 13 seconds seemed a bit much... I have a LOT of insteon in my house - 13 KPLs and 65 other devices. The problem that I think I'm experiencing is that I have a weird electrical system. I have something called E-plus. The power comes in to my main panel and then feeds off to a sub panel that provides heating/cooling to the house. The feed to that sub panel goes through a separate meter as I get charged less for the electricity I use for heating than I do for regular power. Unfortunately some other devices are on the heating side as well and the insteon signal has a hard time getting past the meter. I'd hoped that the RF portion of insteon would prevent that problem and it's certainly much more reliable than X-10 ever was (I've had a large x-10 install for 15 or so years) but it's still a bit quirky. I've got 2 of the older insteon access points (the ones with antennas) installed on both legs of the panel as well as a couple of other newer 2443 access points in other areas of the house. I've ordered two more 2443's in the hopes that this might improve matters. Oddly... when I install the access points I can't get the newer style to communicate properly across both phases - only the older ones. I'm not sure what that means - perhaps you have some insight into this? At the moment I'm linking an 'every light in the house off' scene which turns off 92 lights and KPL LED's. It's been running for nearly half an hour and is not quite done yet. This seems ungodly long! Mark

As the only Insteon installation I'm familiar with is my own I have no way to gauge how well my system is communicating. I was wondering how long, typically, it takes for some of you to have a link successfully write to an insteon device. Obviously the more responders and controllers within a scene the longer it will take for that scene to be created. But if you were to create a blank scene and add one device to it as a responder how long does it take the ISY to successfully write that link. In my case it takes about 13 seconds. I understand that some of the newer switches accept extended messages and write faster. Just curious. Mark