
apostolakisl
Members-
Posts
6943 -
Joined
-
Last visited
Everything posted by apostolakisl
-
First, not to state the obvious, but your program doesn't have any commands after the "wait". Perhaps this is a cut/paste oversight. Generally, the reason "wait" commands don't work is becuase something in the "if" section got triggered. You have 3 "status" items in the "if" section. I assume the variables are state variable judging by the "s" you used in naming. If the status of any of those 3 things changes, your program will terminate and the "if" clause will re-eval. If it evaluates to "false" then your "else" clause will run. For example, you trip your motion detector. The state turns turns to "on". The motion detector has a built in time-out function I assume. After so many seconds it reverts to "off". If the "wait" wasn't done, then the stuff after the wait will never happen. The program would have terminated (cancelling the wait) when the motion detector reverted to "off" and the else would run (which is blank). The command to turn off the scene never is sent becuase the program terminated prior to the 45 sec wait period. The best way to fix this is with two programs. If Status 'Motion Sensors / Closet / Closet Motion Sensor-Sensor' is On And $s_Is.SleepTime is 0 And $s_ClosetOveride is 0 Then Run 'program 2' then Else - No Actions - (To add one, press 'Action') Program 2 If - - (leave it blank) Then Set Scene 'Scenes / Closet Motion' On Wait 45 seconds Set Scene 'Scenes / Closet Motion' Off Else - No Actions - (To add one, press 'Action') With this setup, the timer will get reset in the event that the first program triggers to true before the 45 seconds is up, but if it turns false, the second program will still finish the timer. I also should note, that you could use "control" instead of status to avoid this problem. I do not own any insteon motion detectors, so I don't know if "control" is allowable. Control is only a trigger when it actually happens. Like "control on" only terminates a program for re-eval if the thing is actually turned on. All other actions are ignored. (Also, you don't need those parenthesis)
-
Haaa, great stuff, so many programs you can't even remember what you did. I have this problem with my Elk programs since it has no folder architecture to organize nor can you even give the programs names. I might suggest you try creating a folder architecture in ISY to help you keep things a little more memorable.
-
I don't really want to change the time settings on my ISY to find out, but did you try just closing your Java admin console and reopening it to see if that fixed the time. I do believe that the Java window loads the time from the ISY when you log in and then keeps time itself after that on the local computer. I believe that to be true becuase the time on the Java admin panel slowly gets out of sync with the ISY. Like a second every few hours.
-
What Lee said. The program as you wrote it will never be true. You are asking for it to be two different times at the same time. The "before" and "after" sunrise/sunset are to define a point in time before or after sunrise, not all times before/after. For example "sunrise - 15 minutes" means that if sunrise is 7:15 that day, the program will trigger at 7:00 You can also use a variable. If From Sunrise To Sunset (same day) Then $iSunshine = 1 Else $iSunshine = 0 Then in programs, use "if $iSunshine = 1" for something you want to happen while the sun is up. There is a subtle but important difference here. If you use an integer variable (not state), then the program will not trigger at sunrise and sunset, it will only trigger when some other "if" clause triggers it. This makes it possible to use the "else" clause in a program and not have that else clause potentially happen at sunrise and sunset. For example If $iSunshine is 0 And Status 'Overhead L' is On Then Set 'Closet L' On Else Set 'Closet L' Off The above program will only run the when someone changes the status of 'Overhead L'. If From Sunrise To Sunset (same day) And Status 'Overhead L' is On Then Set 'Closet L' On Else Set 'Closet L' Off The above program will not only run when someone changes the status of 'Overhead L' but also at sunrise and sunset, running the "then" or "else" clause at that time, even though no one did anything to 'Overhead L' switch.
-
As LeeG says, you probably have antivirus issues blocking the Java console from freely communicating. If you can shut your antivirus software off then I would do so, at least as a test. You should find that most of your problems go away. Personally, I just use microsofts antivirus software and it hasn't caused any troubles, plus it is free. I do occasionally get a warning that it thinks something is fishy, but I just click "allow" and all is fine.
-
OK, I am glad that we violently agree. Not sure which we the OP actually wanted it, he says that "advanced's" program does what he wants, but that is both of us. I guess I can see having it so that if you turn all the floor lights off in a room, that the overhead comes on, but it wouldn't be my choice. I could see the other way around perhaps. The overheads are typically for the "full blast" lighting of a room and the other lights are for background "don't trip" lights.
-
I also don't believe the simple condition: time is sunset + 15 minutes, will accomplish the goal. This condition will be true only for an infintessimal time (at sunset +15) and false the rest of the 24 hours. I believe it to be necessary to make this true over a measurable period of time, whether that be from sunset to 10:21, sunset to sunrise, or some other period of time. The two programs have this in common: At Sunset plus 15, if the other two devices are off, the ceiling light will turn on. Difference: In your program, between Sunset +15 and 10:21, changing the status of either the table lamp or keypad to "off", provided the other is already "off", will cause the ceiling light to turn "on". Personally, it seems like an odd thing to turn a light off and have another turn on, but maybe that is what he wants. The fact that my program is only true at sunset plus 15 for an "infentessimal" period of time is of no consequence. ISY will trigger the program at that moment in time and either go to "true" if the other 2 conditions are met and run the "then" or false if the other two conditions aren't met, and run "else". A trigger statement , which is what a time statement like this is, need not have a range to cause the program to run true. It is only if you want other statements in that program to run a "then" statement that you need a range (like manually turning the table lamp off)
-
I don't own one of these, so i am only speculating here, but I am pretty sure it will work. http://www.smarthome.com/2450/IOLinc-IN ... ut-/p.aspx It has a dry contact sensor on it. Power a relay off of your generator (such that it only gets power from the generator). Connect the NO contacts of the relay to the dry contacts on the insteon device. The insteon device would be plugged in where it gets power all the time. I can only assume then that there is a node in ISY for that dry contact that will show up as "on" when the contacts are closed, letting you know the generator is powered up.
-
oberck, Why Time is from sunset + 15 minutes to 10:21pm Instead of Time is sunset + 15 minutes Doing the time interval will make the program true any time someone tries to shut off all the lights during that time and cause it to flip back on again. I would assume you only want the light to automatically come on at sunset plus 15, not block you from shutting it off between the two time slots.
-
I assume what you want here is for at sunset plus 15, you want the status of the lights checked and the scene turned on. You can not use a folder like you have done. At sunset plus 15 the folder condition triggers and the folder evaluates to true. The folder stays true, as there is no other trigger to make the folder evaluate to false. So all of the programs in your folder will be active all the time. You could manually make the folder false, but the next day at 15 minutes past sunset it will become true again and stay that way. Your programs themselves are thus active all the time. You have three lines in the first program all of which evaluates the status of those three lights. When the status of any of those lights changes, the program triggers. I will assume the "family room key - ceiling" is part of your family room ceiling scene. Here is the scenario. Assume 1) "kitchen ceiling keypad - a" and "family room table" are both off. 2) "fam rm key - ceiling" is on You push to turn "fam rm key - ceiling" off, either by directly hitting its button or by a scene. The status of the light changes to off The program triggers becuase "status" is a program trigger wheneve the status changes The program sees that all three lights are "off" The program runs the then and turns the ceiling scene "on" In short what you want is this instead. (without the folder conditions) If Time is sunset + 15 minutes And Status 'Fam Rm Key - Ceiling' is Off And Status 'Kitchen Ceiling Keypad - A' is Off And Status 'Fam Rm Table' is Off Then Set Scene 'Fam Rm Ceiling' On This program is only true at sunset +15 mintes when the status of the other three lights is off. The program will also trigger at sunset +15 minutes because a time statment is a trigger at the specified time. It will also trigger every time the status of one of those lights changes, but that will have no affect since the time is wrong (making it false) and thus the "else" will run (which is empty). What you used to have is a folder that is always true, so the folder was useless. Every time someone changed the status of one of those lights, the program ran. So if the other two lights were off, and you shut off the over head light, it would turn right back on.
-
That is what the "init" value for the variables does. Whatever program sets your variables in the first place just needs to simultaneously init the value. No need to run a program at reboot, the variable will automatically go to the init value. The program below is an example. The program sets the variable and then it immediately changes the init value so it will persist through a power failure. You should do this with all variables you want to persist through a power failure. The only time you shouldn't do it is if you want a power failure to cause the variable to be different. Then right a program that runs only at startup. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then $iOdd.Even.Day = $iDay.of.Month $iOdd.Even.Day %= 2 $iOdd.Even.Day Init To $iOdd.Even.Day Else - No Actions - (To add one, press 'Action')
-
Release 3.1.9 (Beta) Is Now Available
apostolakisl replied to Michel Kohanim's topic in Previous Releases
I have that problem as well after an xep reboot. The ISY doesn't lock up entirely, programs still run, but the java console stops communicating and Elk/ISY communications stop. Rebooting the ISY fixed it. Rebooting the xep is a very rare event for me, but it just so happens that I recently had all kinds of issues with the email function on it. -
Just to be clear, the old switches need to be fully integrated into ISY. I am not quite sure from your post if you just got the ISY, or if the system was already fully ISY integrated. But, any switch that is properly enrolled in the ISY is a breeze to swap out. Personally I don't even bother to name the new switch. If you leave it blank, ISY will just name it the same as the address. As mentioned, as soon as the ISY completes the replacement, it assigns to it the name the old switch had. Also, unless I have missed some trick, the swtich has to be in the root folder. In other words, if you have it in a subfolder, you need to pull it out of that folder and put it in the root "my lighting" directory. As soon as you swap it out, just move it right back to the other folder. Also, you can only swap out the same type of switch. In other words, icon dimmer for icon dimmer, not switchlinc dimmer.
-
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
Hello apostolakisl, I have tried reading your post from beginning to end a few times with hopes that I could offer some help. The post above seems somewhat inconsistent with the rest of the thread? I have to question when someone says their system works at least 99% of the time. From the help others have offered and your responses I believe your system has some (possibly several) very real issues that you need to address if you want to attain reliable operation. I understand it can be very difficult without test equipment to make progress. I do want to throw out a couple of thoughts in hopes it might help some. If I read correctly It appears that Ack messages from the PLM to several devices are not making it though on 1 hop. Your desire is to increase the system performance such that 1 hop is all that is required. 1) You stated that you have a 2412S PLM. My 2412S had a rather weak transmitter. That may have been only my one device but I beleive the hardware design of the 2413 has a stronger transmitter. In addition the newest 2413 I purchased also has new firmware that appears to have changed the hop assist protocol. Normally the PLM would not participate in simulcasting its own 1st hop. My newest device does. I hate to suggest that you invest in a new PLM and find that it did not improve your situation but you might consider it. Without ability to monitor you signal levels it would only be a guess. 2) You talk about removing old signallincs and others have questioned how you might be coupling your phases. I think you need to be serious about getting a good intentional coupling whether that be via a hardware coupler or newer Access points. 3) Are you using any filters? Have you read others posts about devices they have had to add filterlincs to? In my experience there are lots of home appliances that can degrade your communications and it is likely that at least some of these may need to be filtered. As a side note: I also read where you used a 100ft extension cord when testing different positions for your PLM (as a diagnostic tool). I recently did a test to compare 175 ft of 14/2 romex against a 75Ft 14/2 extension cord. This test showed that a long extension cord (dependent upon its design) can be way worst than romex for Insteon signals. In romex the conductors are spaced farther apart and that results in a lower capacitance (there are other factors as that affect this as well but this is the obvious one). While the romex added very little measureable attenuation the extension cord added a fair amount. Using the comparative system system I have been previously the romex was null whereas the extension cord was greater than 1 Standard Insteon load. The point here is when doing a diagnostic test, where you move the PLM, use as short of a cord as required. Hope this did not sound too harsh. I did hope to help. Thanks for the info. And by 99% I mean not including the issue with that program that requires one hop. That is really an "on the fringe" use of Insteon in my opinion. I would say that when given the chance for 3 hops, damn near everything works every time. My 2412s PLM is 2 years old and I replaced it at that time to try to get to 100%. My previous one would be about 5 years old now (forgot the number). Frankly, I am not sure anything changed 2 years ago with that trade out. The newest ones may be more of a change. I suppose it would be worth a try. The 100ft cord I was using was 12 gauge industrial grade (makes your arm muscles burn as you coil it). And it didn't matter where I plugged it in or if I didn't use the cord at all. I couldn't find any change in my scene test results. I do have 2 Insteon noise filters. The one is filtering a known problem with a low-voltage light transformer. This was obvious. The other filters all of my HA stuff (except the PLM of course). This includes all of my audio/computers/Elk panel/video cameras/sattelite receiver/other sundries. It isn't clear that installing this changed anything, but it is there. There is no association with anything in my home being on/off and the extra hop count. If I sit there and hit the same switch over and over and over, it will just every once in a while take 2 hops instead of 1. Not like something is turning on and screwing it up unless it just flips on for a second, which I just don't think is happening. I think it is just a situation where it is slightly on the fringe of enough signal strength and every now and then it just isn't quite enough. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
So, here is what I think would be a first place to start to try to cut down on hops. 1) Buy a 2406h http://www.smarthome.com/2406H/SignaLin ... red/p.aspx 2) Drill through the back of my dryer j-box and pop out the wall near my HA stuff. 3) Put a double gang j-box and pull the 4 wire 240 line in. 4) Connect the 2406h to the 2 legs of the 220 and the neutral 5) Connect a 120 receptacle to one leg and the neutral plus ground 6) Plug the PLM into that outlet. Would anybody suggest that this is not the most direct way to get both phases connected to the PLM. It is effectively a dedicated circuit with a straight shot back to the breaker box. It would only have other activity when that dryer is on, and dryer's should be quiet as far as noise is concerned. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
Any comments on the xpcr. I pretty much figured that a hop trace would be impossible, but it was worth asking. My command central room is behind a utility room which has a 220 drier outlet. I was thinking of drilling through and pulling a 220 wire into my communication room (actually part of the attic, but my attic is conditioned space), and putting the plm on one leg of the 220 and putting xpcr linking the two legs together. Having a dedicated line for the plm might be nice, but except for when the drier is actually on, I think this should be pretty much the same thing. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
What exactly makes you think my system shouldn't work. The only piece I am missing is a phase coupler. I had assumed my rf signalincs were doing that, but it would seem that they were superfluous based on my normally function system without them. My system works at least 99% of the time. I have one icon dimmer that consistently fails, and by that I mean about twice per month it doesn't turn on or off as it should on its program. I get occasional "failed to communicate" messages on the ISY, but the thing is that it did communicate and everything worked. Perhaps that is failed ACK message. My only real problem is the thing that started this entire thread. Which for mysterious reasons is much better now only happening about 1/20 tries. I dug out my x10 coupler. It is a xpcr -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
So far, Still have the rf signalincs sitting in a box. The system works pretty much the same, maybe even better. I am not having any failed commands, but I still get the occasional false trigger of that program related to too many hops. Questions: is there any way to trace the hop path taken. Knowing that might help find a shorter path. maybe Do you think a hardwired signal linc at or near one or all of my subpanels might do the trick? It wouldn't surprise if the need for multiple hops has to do with getting from phase to phase. Although you would think the rf signalincs would have solved that, especiallly with 5. What are the odds that all would be on the same phase, pretty low I think, but I never checked. Do the hardwired x10 phase couplers work the same as the Insteon ones? I actually have one of those sitting in a drawer right now. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
IM I ran links tables on several devices. What did you want to know? And I would say that my system is currently working without error with no RF devices. I have not been able to create the false program trigger that this whole thread goes back to. Lou -
If you can get x10 to work, you will find ISY/insteon to be a breeze. All the "bugs" are on the fringe, far from routine application issues. Certainly there is a learning curve using the ISY, but it is a highly reliable device. Far more reliable than any pc I have ever owned.
-
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
SignaLinc RF #2442 are the units. Manufact dates are 12th week 06 and 24th week 05. And I don't have any of the stuff that uses the extended messages. All of those sorts of things in my house are part of the Elk. As far as Insteon is concerned, I only have SWL's, ApplianceLincs, Lamplincs, and a few icon dimmers. I have about 60 devices total. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
Yeah, the hinged black antenna and they plug in. Most if not all of them have the pass through plug, which I see the "access points" on SH website don't have. I'll look at all of them when I get home and see. But I am pretty sure none have the words "access point" written on them. I didn't really study this issue, however, as I didn't know it was worthy of such attention. But I did for sure look closely at one of them before I started posting about them because I wanted to make sure I referred to them by their proper name! Who knew I was sabotaging myself. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
Did they change the name at some point? I see on SH website that signal lincs are the hardwired phase couplers, but I know for a fact that the word "signalinc" is on at least a couple of mine followed by the item number. I will confirm tonight. I think it might actually say "rf signalinc". These guys are fairly old. Heck, I don't even know if they are doing anything at all. The led lights up on them but other than that I have no way to check them. I suppose I could isolate my plm using a filterlinc and see if it still can communicate by putting one of these "rf signalincs" on each side of the filterlinc. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
I had tried running extension cords from my plm to various other outlets around the house (100 ft cord was more handy than long cat5) and I couldn't really find any improvement in performance. I actually used a washing machine plug that was on its own breaker. Of course, at the time I was looking at it differently. Possible. I do have over 100 feet from my panel to the transformer, but I guess that isn't that long. I can do that tonight. PS, anyone want to buy some signalincs? Seems that mine are just wasting electricity. -
Improper Programm Behavior Since Firmware Update.
apostolakisl replied to apostolakisl's topic in ISY994
That was my point. The SWL didn't hear the ack in 1 hop (it took two) which resulted in the SWL message being sent to the PLM twice. On the second ACK from the PLM, it allowed for more hops, so it got through to the SWL. So I was trying to get the ACK to go through in one hop (not 2). Not knowing the path taken, I consisdered that the rf signal lincs may have been involved. If using a dual band plm takes one hop out versus two signal lincs, then that was my idea. Anyway, a full evening and full morning of activity have completed in my home without any signal lincs or rf insteon devices of any kind. Everything is working at least as well as before, possibly better. None of the lights this morning misbehaved as per the original problem. My home has standard two phase power with three subpanels. As far as things connected to both phases, that would include the oven, heat pumps, well pump, air handlers?, two clothes dryers. The oven has not been on, the heat pumps/air handers are probably off (it is actually 68 right now), the dryers are off, and the well is off. So at least one of those devices must have some standby draw that is using both phases, I guess.