apostolakisl Posted June 9, 2015 Posted June 9, 2015 What problem are you having with a KPL? If you're asking me, none. Just questioning why multiple nodes on a fanlinc or io linc might cause this odd issue and if I should consider the same problem on my kpls if and when I have any odd behavior. I don't have any fanlincs or iolincs, though I think I will be buying some fanlincs in the future. I have no need for IO lincs as I have all that stuff hardwired to my elk, which is rock solid reliable. And if I were to go with a non Elk I/O device, it would be my webcontrol boards, which I suppose may even be integrated as nodes at some point in the near future, but even if not, they work great using the REST interface. I have a number of wifi to ethernet adapters which work quite nicely with my webcontrol boards and to date has never had a failed com. I can pretty much put them anywhere and get ~100% response.
dba62 Posted February 24, 2017 Author Posted February 24, 2017 The I/O Linc has two nodes, Sensor and Relay, each node must be queried individually. In this case the Sensor will report On with the door closed and of course the Relay will report Off. There are cases traced and posted where a Query response will be late arriving at the PLM such that the Relay Off Query response is applied to the Sensor Query. The Query response does not indicate which node it applies to. This can result in a Program being run because the door Status looks Open when the door is actually closed. Although it best to try and resolve the late message some users have found it easier to change magnetic switch such that the door Status is Off when door is closed. What do you mean by change the magnetic switch? Move the location of the magnet or sensor? Are there any other options to work around an intermittent communications issue?
Teken Posted February 24, 2017 Posted February 24, 2017 What do you mean by change the magnetic switch? Move the location of the magnet or sensor? Are there any other options to work around an intermittent communications issue? Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit) vs closed (unlit). Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior. Better yet purchase the correct kit which offers both N.O. & N.C. contacts.
stusviews Posted February 25, 2017 Posted February 25, 2017 Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit) vs closed (unlit). Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior. Better yet purchase the correct kit which offers both N.O. & N.C. contacts. Not possible, there's only one garage door kit.
dba62 Posted March 7, 2017 Author Posted March 7, 2017 Older GDO kits came with a sensor that could be wired to be N.O. vs N.C. Meaning the LED on the unit would reflect the door open (lit) vs closed (unlit). Newer GDO kits have only one contact and this always results in the I/O Linc's LED to show the reverse state. So your choices are to purchase the magnetic contact that offers the reverse behavior. Better yet purchase the correct kit which offers both N.O. & N.C. contacts. So the newer kits have NO and NC, but this is for control of the garage door opener? I only see one input for the sensor.
stusviews Posted March 7, 2017 Posted March 7, 2017 All Insteon garages kits include NO and NC. That's just the feature of the I/O Linc which has many purposes.There has always been only one sensor input. The concern is if the sensor terminals are connected a Normally Open or Normally Closed magnet contact switch. The former will send an Off signal when the garage door is open (when the sensor is away the magnet the contacts are open) and the latter will send an On signal when the door is open.
Brian H Posted March 7, 2017 Posted March 7, 2017 (edited) Stu, Are you referencing the NC and NO relay contacts or the magnetic sensor in the kit? I just looked. The present kit has the single contact arrangement magnetic sensor. Not the older more expensive one with NO and NC outputs. Edited March 7, 2017 by Brian H
dba62 Posted March 7, 2017 Author Posted March 7, 2017 There has always been only one sensor input. The concern is if the sensor terminals are connected a Normally Open or Normally Closed magnet contact switch. The former will send an Off signal when the garage door is open (when the sensor is away the magnet the contacts are open) and the latter will send an On signal when the door is open. OK - I finally understand. Are the older magnetic sensors still available? Regardless, I probably don't want to spend the money and/or do the requisite rewiring. Would it be possible to code around this in my program that monitors the garage door? Specifically I am asking is there a way to programmatically force a query? If so, I can code around this.
Teken Posted March 7, 2017 Posted March 7, 2017 Yes, here is the older dual type sensor: http://www.smarthome.com/seco-larm-sm-226l-3-magnetic-garage-door-contact-switch.html
stusviews Posted March 8, 2017 Posted March 8, 2017 And yes, you can code around the problem by selecting Trigger Reverse. A difficulty is the the nightly query will at some time randomly reverse the reverse with no warning.
dba62 Posted March 9, 2017 Author Posted March 9, 2017 Right now I have: If Open Wait 30 minutes Send alert Is threre anyway to do something like: If Open Wait 10 minutes <query> If Open Wait 10 minutes Send Alert I assuming merely adding If Open won't accomplish anything because there won't be a second query after the 3 am query.
stusviews Posted March 9, 2017 Posted March 9, 2017 The ISY does not have nested IFs as a construct. In any case, that won't solve the reverse the Trigger Reverse problem.
Sub-Routine Posted March 9, 2017 Posted March 9, 2017 How I solved the Query All at 3AM issue with IOLincs, unpowered LampLincs, etc. I created a few scenes containing all the devices I want to Query and none of the ones I don't. I modified the 3AM Query program to query only those scenes. Query My Lights - [ID 0027][Parent 002B] If Time is 3:00:00AM Then Set Scene 'Indoor Lights / Indoor Lights' Query Wait 3 seconds Set Scene 'Outside Lights / Outside Lights' Query Wait 3 seconds Set Scene 'Basement / Basement Lights' Query Else - No Actions - (To add one, press 'Action') Schedule migrated from previous version. Modified for specific devices. Now the only time the unwanted devices are queried is after a power outage.
oberkc Posted March 9, 2017 Posted March 9, 2017 Right now I have: If Open Wait 30 minutes Send alert Is threre anyway to do something like: If Open Wait 10 minutes <query> If Open Wait 10 minutes Send Alert I assuming merely adding If Open won't accomplish anything because there won't be a second query after the 3 am query. dba62, While I agree with stusviews response (in regards to nested conditions as well whethernthis is a solution to your trigger reverse problem), the ISY does (in my estimation) provide sufficient flexibility and power to program the logic you propose. If you wish to discuss further, let us know. I definitely believe the best solution to a trigger reverse problem is to replace the sensor with one that works as needed for the application.
dba62 Posted March 10, 2017 Author Posted March 10, 2017 dba62, While I agree with stusviews response (in regards to nested conditions as well whethernthis is a solution to your trigger reverse problem), the ISY does (in my estimation) provide sufficient flexibility and power to program the logic you propose. If you wish to discuss further, let us know. I definitely believe the best solution to a trigger reverse problem is to replace the sensor with one that works as needed for the application. I'm going to go ahead and purchase the sensors, but I would like to understand how the programming could be acconmplished. It would seem that the following might work: If Open Wait 15 minutes Query Garage Doors Sleep 10 seconds If Open Wait 15 minutes Notify
stusviews Posted March 11, 2017 Posted March 11, 2017 I'm going to go ahead and purchase the sensors, but I would like to understand how the programming could be acconmplished. It would seem that the following might work: If Open Wait 15 minutes Query Garage Doors Sleep 10 seconds If Open Wait 15 minutes Notify No, that won't work I already indicated that the ISY does not support nested IFs. Also, I'm not sure what you are trying to accomplish, the I/O Linc sensor status can be used a a program trigger, There's no need to query it.
oberkc Posted March 11, 2017 Posted March 11, 2017 It would seem that the following might work: If Open Wait 15 minutes Query Garage Doors Sleep 10 seconds If Open Wait 15 minutes Notify it might, if you have nested IF statements. We don't. However, understanding triggers and effect on wait statements, you could accomplish similar logic by: if open then run second program (then path) else nothing second program: if nothing then wait 15 minutes run third program (if path) else nothing third program (disabled) if open then wait 15 minutes notify else nothing
dba62 Posted March 13, 2017 Author Posted March 13, 2017 No, that won't work I already indicated that the ISY does not support nested IFs. Also, I'm not sure what you are trying to accomplish, the I/O Linc sensor status can be used a a program trigger, There's no need to query it. The status can be bad. I am trying to verify the status at least once before generating a message.
dba62 Posted December 9, 2017 Author Posted December 9, 2017 So what I ended up doing which seems to work was to write a query garage door program: If Status ' Garage Closed' is Off Then Wait 3 minutes Set "Garage Closed" Query Wait 3 minutes Set "Garage Closed" Query" Else - No Actions But I am wondering if this works the way I would like it to. My question is: what happens if the first query shows that the door is actually closed. Will the THEN be exited or will it continue to execute the following Wait/Query? If the first query shows that the door is open, I don't want to execute the second query. What I am trying to do is query the door status twice. If it returns open both times, then I am willing to believe that it is actually opened.
oberkc Posted December 9, 2017 Posted December 9, 2017 (edited) But I am wondering if this works the way I would like it to. My question is: what happens if the first query shows that the door is actually closed. I suppose it depends on what you would like it to do, and whether "closed" = "off". It may also be affected if you are using the sensor reverse mode on the IOLinc. In general, if the query causes a change in status of 'garage closed', the program will re-evaluate. A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false). Edited December 9, 2017 by oberkc
dba62 Posted December 9, 2017 Author Posted December 9, 2017 I suppose it depends on what you would like it to do, and whether "closed" = "off". It may also be affected if you are using the sensor reverse mode on the IOLinc. In general, if the query causes a change in status of 'garage closed', the program will re-evaluate. A program in a wait state that is re-evaluated will be halted and run from the beginning, based upon the newly-evaluated status (true or false). Thank you. That is exactly what I wanted to know, although I end up with another question. Here is the sequence of events, I am wondering what happens next: Garage Opens Wait 3 minutes Query Garage (still open) Wait 3 minutes Query Garage (still open) Does the program go back to the if statement at this point? If so, then the second wait/query combination is superfluous.
oberkc Posted December 9, 2017 Posted December 9, 2017 Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause.
dba62 Posted December 10, 2017 Author Posted December 10, 2017 Programs are triggered by events, based upon the conditions. Programs do not automatically re-evaluate based solely upon completion of an action clause. Thanks, so this program does want I want. Occasionally (< 1% of the time) my garage door sensor will return a bad status (I believe that part of the message is lost which results in improper interpretation). So now if that happens, the sensor is queried two additional times to validate the current state. 1
oberkc Posted December 10, 2017 Posted December 10, 2017 Yes. You can also check status (true/false) of the program. If true, that is a pretty good indicator tat it ladt run THEN path to completion.
Recommended Posts