apostolakisl

Below is a log of the status of a light that behaved wrong this morning. I don't know what the third line means where it says "on 63". Other than that, you can see that at 6:30 the light was turned on by the wakeup program. The next action on the light was to turn it off by me manually at 6:52:35. Then there is a program log with the 63 which I don't know what means, then the light turns on to 25% which it should not have done. Then I turned it off again and it stayed off. Alexis Room / Alexis BR/Overhead L Status 100% Thu 2011/09/29 06:30:00 AM System Log Alexis Room / Alexis BR/Overhead L Status 0% Thu 2011/09/29 06:52:35 AM System Log Alexis Room / Alexis BR/Overhead L On 63 Thu 2011/09/29 06:52:36 AM Program Log Alexis Room / Alexis BR/Overhead L Status 25% Thu 2011/09/29 06:52:37 AM System Log Alexis Room / Alexis BR/Overhead L Status 0% Thu 2011/09/29 06:52:42 AM System Log

Hmmm. That's something to think about. I do have maybe 4 rf doohickies plugged in around the house. I have had those all along however. It would be no big deal to unplug them and see what happens. I do have 3 breaker boxes in the house and don't wan't to lose signal through the different panels and their phases.

You would be very limited with those. They typically are capable of multiple tones but the user needs to select one of them at the base station. You could use an Insteon relay device and "hot wire" it to the doorbell button allowing ISY to "ring the bell", but that would be just one tone. If you bought 8 of them and selected different tones for each one, it might work, but you would probably find that they all shared the same frequency and thus all would go off every time one of them was triggered. Maybe you can find a hardwired version and thus be able to keep them separate. My doughter has one like that she put on her bedroom door, but it just does a little chime, no voices or anything.

I have a 2412s modem that I bought 7/09. I have both icon dimmers and switchlinc dimmers running the program and all of them are the newer models with the beeper in them (less than 2 years old). The problem is happening with both the icons and the switchlincs. I really didn't have this issue prior to firmware 3.1.7. The programs all say "off" and "switched off", not "less than 5%" and "switched off"

Now that I have been using the lights "real world" for about a week, I am sad to say that it is behaving improperly a lot more than when I just stood there hitting on/off/on/off etc. It is probably running the program when I turn the light off from a "not off" status 25% of the time. This is probably too much to keep the programs running. I think I am going to have to disable them.

That is what I was thinking with the "is you computer always on" question. But it still also needs an intercom unless you have a small house and can crank up the volume on your computer speaker.

Talk to io_guy. He has written a couple applications that run in the background on a pc and set ISY variables. I have his app syncing my cai webcontrol unit with isy variables. If you can use http commands to poll your Davis weather station then I am sure it would work pretty much the same.

Do you have an intercom system in your house with a line-in? Do you have an Elk m1G? Do you have a computer that runs all the time?

You might try updating to the latest firmware. "bounce" would be a good adjective for how it behaves when it isn't doing what it should. But with the current firmware, this is a pretty rare event. It is a little odd to me that it happens like this. It would seem more likely to me that it would happen every time or none of the time. 5% is kind of odd. Especially considering that at the time I was testing it, the ISY had no other active programs. I can only assume that it has something to do with Insteon communciation fluctuations since I would thin ISY was in a steady state at the time.

I played with it some more last night. I think saying it functions properly 95% of the time is pretty accurate. I was able to get 2 more misfires of the program out of roughly 40 tries. I am sure you guys will get it 100% soon enough. It is not that big of a deal at a 5% error rate in this context. However, there might be a time when someone wants to use that program technique in a less forgiving application where 5% failure would be bad.

I know this isn't exactly the answer you were looking for, but there are fairly inexpensive ways to reboot the ISY if it is locked up (remotely). 1) If you have an Elk, put a relay board on it and run the power to the ISY through one of the relays. 2) Buy a cai webcontrol and a relay board. You need relays that activate from ttl outputs which can be found on ebay by searching "pic relay". For about $60 total you can have 8 IP controlled relays which you can use to cycle power to up to 8 devices. If you don't need 8 relays, you can save about $15 and just get a single relay. ISY can also directly control the CAI unit using the network module which might be useful. Also, you can sync all of the cai's functions with ISY using io_guy's little application. This is actually the cheapest way to get multiple temperatures into ISY. Still doesn't help you, however, if your modem or router lockup. Although you probably can control the Elk from the phone. I've never looked into it.

With the new firmware update (3.1. the problem is nearly elliminated. I turned several of the switches with this program on/off dozens of times. The problem did occurr a few times. I did have my laptop with me to confirm that isy registered all actions on the switches and that it wasn't a com failure. There were zero com failures in the 30 or 40 on/off cycles. I didn't take exact counts, but the program now is mis-behaving maybe 5% of the time versus maybe 75% of the time with 3.1.7.

The two programs below will do it. But you can't have the kitchen table linked to the in line device. Let ISY turn it on and off. Blink If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Set 'Kitchen table' On Wait 5 seconds Run Program 'blink' (Else Path) Else Set 'Kitchen table' Off Wait 5 seconds Run Program 'blink' (Then Path) Run Blink If Status 'in line linc' is not Off Then Run Program 'blink' (Then Path) Else Stop program 'blink'

It happened so rarely before that I couldn't repeat the event while investigating. There is a very good chance that it was a failure to comunicate when the light was turned on, resulting in a proper execution of the program (from the perspective of ISY which thought the light was off). The programs were presented to be used exactly as I am using them. This is a "night light" program and was presented as such. I quickly perused the wiki and didn't see this program. But I found this set of programs which is the exact same thing except for if status is on, and it is switched on (instead of off). But it is functionally the same thing. http://www.universal-devices.com/mwiki/ ... tion_Order

I have taken tjf1960's idea and slightly altered it. For now, I am using the "fast off" to turn the light off when I actually want it off. The sinlge off will still get me the 25%. It is almost comical. Turn the light off, 1 second later it comes on to 25%. Click off again, it goes off, then boom, 25% again. It isn't the same for every switch. Some do it darn near every time, some not so often. I don't know what the creators of ISY intended when writing the first code for it, but they definitely pointed out this feature. As I mentioned, I did not brain storm it up myself, it was from an official UD publication that I got the idea. Before this firmware, this happened every once in a while, but now, it happens most of the time. EDIT: I do believe that ISY is responding very quickly to status changes of devices and communicating better than ever with this firmware. I do like it. So, a simple workaround to get this particular program functioning again would be great.

What you say is true. The point is that it used to work and now it doesn't. The ISY has changed either how fast it processes or the order of processing. I liked the way it used to work and would like it to still work that way. And tjf1960 makes a fine suggestion, it is just that at 3am you are swatting blindly at a light switch, trying to get a double click may be out of the quesiton.

I think Chris said this, but if xxxx is the actual program (it is using its own state as a condition), it will not work properly. For example: 1) all lights off 2) program is "false" 3) turn one light on 4) program triggers, turns true 5) then runs All is good 6) second light is turned on 7) program is true evaluates to false 9) else clause runs All is still good 10) third light turns on 11) program is false 12) program evaluates to true 13) then clause runs (OOOPs, not good) You need to use a separate flag program or more easily now that we have variables, use a variable. If Status 'light a' is not Off Or Status 'light b' is not Off Or Status 'light c' is not Off Then $sledtracker = 1 Else $sledtracker = 0 If $sledtracker is 1 Then Set 'switchlinc' 100% (Backlight Level) Else Set 'switchlinc' 25% (Backlight Level) The first program will run every time the status of any of the lights change. The second program will only run when the status of the state variable ledtracker changes. ledtracker only changes when the first program goes from true to false or vice-versa. You may be able to skip the variable and use the true/false status of the first program as the if clause for the second program. I forget if a program status in the if cluase triggers a program on status change or if you need a separat trigger. Only if it is a trigger would that work. If you wanted 3 or more state to your backlights, you would definitely need to use a variable.

The program is designed such that pushing the "off" side of the paddle when the light is already off turns it on to 25%. I implemented a bunch of these programs a long time ago and actually copied it from the wiki I believe. It is (had been) a nice way to turn the lights on dimmly during the night. It has worked great until the new firmware installation. Now, about 75% of the time, the program runs when I shut the light off even when it was not initially off. In other words, the light is "on", I click "off", the light turns off, but then the program turns it back on to 25% a half second later. The program was only intended to run when "off" is pushed when the light is already "off". It would seem that the new firmware has changed the order of evaluation. It used to be that clicking the off paddle caused the program to run, then the light turned off (if it was already on). Now, it looks like the light is turning off before the program is running (most of the time). So, in effect, the program is seeing the light as off every time you push the off button, regardless of what state it was in when you hit the off button. Flow chart: (old way) starting from light NOT off 1) light status not off 2) push "off" button 3) program triggers, evaluates to false and doesn't run then clause 4) light turns off (this is good, what I want) Flow chart: (new way) starting from light NOT off 1) light status is not off 2) push "off" button 3) light turns off 4) program triggers and evaluates to true 5) light comes back to 25% (this is bad) Flow chart: (not affected by new firmware) starting from light off 1) light status off 2) push "off" button 3) program triggers and evaluates to true 4) light turns on to 25% (as intended)

I have a bunch of programs written like this. If Status 'Master Bedroom / Master/Bath Cans L' is Off And Control 'Master Bedroom / Master/Bath Cans L' is switched Off Then Set 'Master Bedroom / Master/Bath Cans L' 25% Else - No Actions - (To add one, press 'Action') After the most recent firmware update, then program is running the "then" section nearly every time I do anything to the switch. It is not a communication issue. For example, I turn the light "on". The ISY admin console changes from "off" to "on" on the main page. So, ISY knows it is "on". I click "off" on the switch, it turns off, then a second later it goes to 25%. Why is the program executing the "then" section? It doesn't happen 100% of the time, but it is happening maybe 2 out of 3. Is there a timing issue? For example, I click "off" the ISY changes it's status to "off", then the program tests the status?

Michel, Would it be possible to get an LED backlight level tutorial? When it first showed up as an option on ISY I attemtped to use it and wound up with a switch that needed factory resetting. Some threads at the time basically said "don't use it for now". Where do we stand with it at present? And to the OP. After re-reading your post and question I think I have an idea. It would seem that you want the led backlight to be brighter or dimmer based on the current light in the room. But every time a light changes you don't want the program re-sending the led level if it hasn't changed. Here is a solution. Write one program for each led backlight level you want that includes the conditions (if stuff) for those levels. Perhaps you want 3 different levels: low, medium, and bright. So you have three programs (if you only want 2 levels you can do it with one program using the "else" clause) But don't have the program's "then" section set the led's. Instead, have it set a state variable to 1,2,or3. Then have a second program (three of them for 3 states, 1 for two states, again by using the "else" clause) that looks for the variable to change value and if it does, then send the led brightness change. A program with a single "if" clause testing the status of a state variable will only trigger when that state variable changes value.

oberkc is right to say that programs won't change link tables, so I don't get that part. I can only assume you are using the "if" section here as an example for a group of programs since the above program doesn't do anything except set a true/false status of itself (as mentioned by oberck, no traffic). In short, if you don't want a program to trigger every time the status of a switch in the program changes, don't use "status" in your programs. That is the nature of "status", that it triggers programs with any status change. Use "control" if you only want a program to trigger under more specific circumstances. If you want the status of something checked after some trigger event occurs, then use two programs. The first program has the trigger event and then you put a "run if" in the "then" section which runs a second program containing the "status" situation. The second program needs to be disabled so it doesn't run except when the first program calls it.

Please put your exact program in here. Right click on it and click "copy to clipboard" then paste it to the forum.

I have 99irpro. The installation went very smoothly. The unit is running perfectly, seems to be communicating with devices faster than before (updated from 3.1.2). Maybe my imagination.

From a technical standpoint, yes it will work. However, because of the state nature of the ISY and some limitations currently in how variables can be used you will run in to a couple of ease-of-use issues. 1) if you have more than a few devices that you want to include you will end up with either quite a number of individual programs, 1 per device or an extremely complicated and hard to read set of IF/THEN clauses. 2) you will have quite a number of additional state variables, again 1 per device 3) If you have to account for devices that are not simply on/off, your set of IF/THEN statements has to account for every possible status. An AC or other temperature control would be a royal pain. 4) You cannot easily see what state the devices are all supposed to be in. Think of looking at a single scene vs having to look in each individual program. 5) Any time you decide you want to include a new device you have to set up a new variable and a new program. If you use a scene, you simply add the device to the scene and you're done. Hope that helps. The OP stated he has a couple of relays that either turn his ac on/off (I assume these are window units with the temp setting on the unit itself). This would be quite simple to implement in that situation. I truly doubt anyone would do this across a 100 device Insteon installation, it simply isn't necessary. This is a great way to make sure that the mission critical stuff gets into the proper state after a power failure. I just don't consider using the programs and variables that we paid for when we bought the isy to be a problem. That's why I bought them!

What if you had the program that turns your appliance link on/off simultaneously set an integer variable on isy to 1 for on and 0 for off and inits that value so it maintains across power failure. Set a program that runs only on start up which queries the variable and turns the appliance link on if the value is 1. I have not used the "run at start up" feature, but per Michel's comments on another thread it always runs the "then" clause upon power up. So perhaps the "then" clause is a "run if" command that runs a second program reading along these lines. Tracker for appliancelink If Whatever conditions normally turn the appliance link on Then $i.appliance.link.tracker init to 1 Else $i.appliance.link.tracker init to 0 Turn on 'run at startup' for this program If No Conditions Then Run Program 'power failure status check' Else No action Power Failure Status Check If $i.appliance.link.tracker is 1 Then set 'ac appliancelink' to on Else set 'ac appliancelink' to off