Garage Notification Not Working as Expected

[jpiroli]

Having trouble getting my notification to operate as expected. I have been searching through the past posts and it appears that my program is written as it should be but...

 

What I would like is a notification telling me that the garage door is open, only after the door has been open for 15 minutes. However if the door is closed prior to 15 minutes, I would like no notification.

 

I am getting is a notification, however the ISY994i is simply waiting 15 minutes before it sends it. For example, if I open the garage at 8:00 a.m., and close it at 8:02 a.m., the isy sends me a notification at 8:15 a.m.

 

my program is below:

 

If

Status 'xGarage Door Status' is On

 

Then

Wait 15 minutes

Send Notification to 'Garage Door Status' content 'Garage Door Status'

 

Else

- No Actions - (To add one, press 'Action')

[LeeG]

The basic logic of the Program is correct.

 

First check if a Save is pending for the Program. The Program Icon will have a Green arrow on top of it at 4.0.5 if a Save is pending. Was the Copy to clipboard function used to copy the Program to the forum.

 

Second check the Current State column for the I/O Linc Sensor node. Does it show On when the garage door is open and Off when the garage door is closed.

[jpiroli]

Thanks for the quick response.

 

There is no save pending.

 

I did paste the program from the clipboard but did not use the "Code" button above.

 

The sensor shows on when closed and off when open. Do I change that with Trigger Reverse? Seems I had tried that but received an open notification at 3 a.m. when the query all ran.

 

Also, in the sensor options, I have "LED on tx" checked and "Momentary C: Trigger based on sensor input" selected. Momentary hold time is 2 seconds.

[oberkc]

The sensor shows on when closed and off when open. Do I change that with Trigger Reverse?

 

You could do that, but you could also simply change the program to look for an OFF status, rather than ON. Of course, you may have other uses for the sensor which may make this approach less desirable.

 

The bigger point is that if your program is looking for an ON command to indicate open, yet your garage door sensor says OFF when open. Obviously there is a mismatch and something has to change.

[LeeG]

"The sensor shows on when closed and off when open. Do I change that with Trigger Reverse?"

 

Using Trigger Reverse does result in the 3 AM problem. If the only issue is the posted Program simply change the check to Off rather than On. Most users prefer On to indicate the door is open. To achieve this the best solution is change the magnetic switch from NC to a NO variant.

 

 

"I have "LED on tx" checked and "Momentary C ---" selected. Momentary hold time is 2 seconds."

 

The LED on Tx causes the LED on the side of the I/O Linc to blink when there is Insteon traffic. Makes no difference to the functioning of the I/O Linc. Momentary C relates to what Scene commands will operate the I/O Linc Relay. There has not been a discussion about how the I/O Linc Relay is being used to open/close the door so use momentary C if it produces the desired results.

[jpiroli]

I have changed the check to Off rather than On and have been testing with positive results this evening. All good now, thanks!

[oberkc]

glad it is working. So long as you remember that IOLinc sensor OFF = open, you should be in good shape.

 

The problem with this could be if you ever choose to use a scene with the sensor as controller, wanting to use a responder with ON indicating OPEN. For this, you would have to use a program rather than scene, or the trigger reverse, and live with the other consequences.

[scubaguyjohn]

I have two new IOLincs linked to a keypad controlling 2 garage doors. When I press the keypad A button, it flashes twice, the door opens, and the A button stays on. When I press the A button again, the button flashes twice, the door closes, and the light goes off once the door is fully closed (about 15 seconds). Perfect (thanks to the Wiki)!

 

Problems arise when I use the sensor value to trigger lights via a program. While the keypad button always indicates the correct sensor value, ISY does not. Consequently, I open the door, keypad button A is on but the value in ISY is unchanged until queried. Occasionally, ISY will update the value based on the sensor value changing but it gets out of sync with the correct value.

 

I've tried reading all the threads and some seem to indicate that the issue was an old IOLinc issue with the IOLinc not sending the sensor value. However, given that my keypadlinc buttons do change correctly regardless of how the sensor value is changed (via keypad button, remote control, or manually), I'm stumped as to what the cause/solution is.

 

I have momentary B and trigger reverse selected. When door is closed Sensor is ON.

 

Ideas?

 

thanks, John.

[oberkc]

the keypad button always indicates the correct sensor value

 

Occasionally, ISY will update the value based on the sensor value changing

 

Those two statements lead me to conclude that the sensor IS sending out state change announcements, and that ISY/PLM database is not corrupt (computers general always work, or always don't). The random nature of your failure suggests to me that there is something keeping the insteon messages from reaching your PLM. Were this me, I would be doing some troubleshooting to identify the possibility of comm errors.

 

I can tell you that I use garage sensor status and control as conditions for programs, and it works well. I don't believe there is a programmatic reason for this not to work.

[scubaguyjohn]

the keypad button always indicates the correct sensor value

 

Occasionally, ISY will update the value based on the sensor value changing

 

Those two statements lead me to conclude that the sensor IS sending out state change announcements, and that ISY/PLM database is not corrupt (computers general always work, or always don't). The random nature of your failure suggests to me that there is something keeping the insteon messages from reaching your PLM. Were this me, I would be doing some troubleshooting to identify the possibility of comm errors.

 

I can tell you that I use garage sensor status and control as conditions for programs, and it works well. I don't believe there is a programmatic reason for this not to work.

 

thanks for the reply...given there isn't a programming reason for it not working, I ordered a couple of access points to insure communications are being sent/received properly.

 

John.

[oberkc]

I consider access points near-mandatory. Given the posts I have read, it seems prudent to suggest reading the manaul and following the instructions for confirming you have one on each "phase" of your electrical system. Up until now, how did you provide a communication path across the legs/phases of your electrical system?

 

You may also consider keeping a couple of filters on hand, should you ever discover a device that is giving you some insteon grief.

[scubaguyjohn]

I consider access points near-mandatory. Given the posts I have read, it seems prudent to suggest reading the manaul and following the instructions for confirming you have one on each "phase" of your electrical system. Up until now, how did you provide a communication path across the legs/phases of your electrical system?

 

You may also consider keeping a couple of filters on hand, should you ever discover a device that is giving you some insteon grief.

 

 

I have a very large insteon network (over 75 devices) so bridging the legs shouldn't be an issue. However, the iolincs are in a detached garage so I'm sending the iolinc RF signal about 100' to/from the house. What's strange is that it works 100% reliably with the keypadlinc and the keypadlinc always shows the correct sensor status. However, ISY is not automatically picking up the sensor status change on a consistent basis. A query always shows the correct value.

 

Originally, I thought a communications error could be the issue but it makes little sense that ISY is not picking up the correct value but any other device will.

 

FYI, my control of lights across the 100' gap is flawless which further baffles me as to the issue.

 

For others with Chamberlain garage door openers, you have to wire the iolinc directly to the momentary switches in the powered wall control unit. If you don't, nothing will happen when triggering the opener (actually the wall controller clock will reset and the opener will indicate a short via it's flashing lights). I didn't solder the connections but was able to wrap the wire (I used some old Cat3 wire) around one of the legs on the momentary switch which made it painless. Each wall controller has 2 momentary switches under the door open/close button for door control (one on the left and one on the right of the controller). Wiring to either one will work. Then run the wires back to the IOLinc.

[oberkc]

Originally, I thought a communications error could be the issue but it makes little sense that ISY is not picking up the correct value but any other device will.

 

Which, to me, suggests a problem near the PLM. What other devices are on the circuit with the PLM?

[scubaguyjohn]

Originally, I thought a communications error could be the issue but it makes little sense that ISY is not picking up the correct value but any other device will.

 

Which, to me, suggests a problem near the PLM. What other devices are on the circuit with the PLM?

 

 

There are no other insteon devices on that circuit with the exception of a 2413u and the isy/plm. I unplugged the 2413U with the same results.

 

My audio receiver is plugged in nearby. I assume by circuit you mean an electrical circuit controlled by one electrical breaker.

 

When I say the ISY is not reflecting the correct value, I arrive at this opinion by watching the ISY control java control panel for a sensor value change. Whenever I turn on/off a light, the control panel immediately reflects the status change.

[oberkc]

There are no other insteon devices on that circuit with the exception of a 2413u and the isy/plm.

 

I was less concerned with insteon devices, and more concerned with other electronic gadgets that could interfere with insteon communication.

 

My audio receiver is plugged in nearby. I assume by circuit you mean an electrical circuit controlled by one electrical breaker.

 

Yes, I meant "electrical circuit controlled by one electrical breaker". The audio recieve is the only other thing powered by that circuit? Have you tried unplugging it temporarily?

 

When I say the ISY is not reflecting the correct value, I arrive at this opinion by watching the ISY control java control panel for a sensor value change.

 

Yes, I expect (based on my own experience) that the admin panel should show near-real-time status of that sensor. It does not necessarily show accurate status of the relay. I trigger garage lights from the sensor, and this works very well.

[Xathros]

For what its worth, I believe that the IOLincs are NOT dual band devices and therefore, they are NOT sending RF but rather powerline only communications. I have some Insteon devices at the far end of a 300' run out to my barn that work quite well but there is nothing out there that could generate noise or attenuate signal beyond the extreme wire length to get there. 100' should be just fine if noise makers and signal suckers are filtered.

 

-Xathros

[LeeG]

"A query always shows the correct value."

 

The problem with that is Query returns the opposite state to what the Sensor is sending. When the Sensor is sending an On a Query will indicate Off. When the Sensor is sending an Off a Query will indicate On. The fact that Query "corrects" something in this situation may be indicating a logic problem rather than a communication problem.

[scubaguyjohn]

For what its worth, I believe that the IOLincs are NOT dual band devices and therefore, they are NOT sending RF but rather powerline only communications. I have some Insteon devices at the far end of a 300' run out to my barn that work quite well but there is nothing out there that could generate noise or attenuate signal beyond the extreme wire length to get there. 100' should be just fine if noise makers and signal suckers are filtered.

 

-Xathros

 

 

thanks...I wasn't clear...I'm relying on RF to bridge the 100' as the power to the garage is a separate power source. On the same leg as the IOLinc I have a dua lband lamplinc and a dual band dimmer in the garage which i rely on for the RF back to the house.

[scubaguyjohn]

"A query always shows the correct value."

 

The problem with that is Query returns the opposite state to what the Sensor is sending. When the Sensor is sending an On a Query will indicate Off. When the Sensor is sending an Off a Query will indicate On. The fact that Query "corrects" something in this situation may be indicating a logic problem rather than a communication problem.

 

Lee - thanks...the ISY query doesn't change the sensor value if it is correct. In my case that means ON when the door is closed and OFF when its open.

 

I think you all are likely correct that its a communication issue...I just added a different keypad to control the garage lights and I'm not getting a reliable response from the lights. Strange to me that one keypad would trigger the garage lights but another won't. Does the insteon network send out RF signals from all dual band devices at the same time?

[Xathros]

thanks...I wasn't clear...I'm relying on RF to bridge the 100' as the power to the garage is a separate power source. On the same leg as the IOLinc I have a dua lband lamplinc and a dual band dimmer in the garage which i rely on for the RF back to the house.

 

OK. That makes more sense. From what I have read here since the dual band devices started rolling out, these devices have rather minimal range and are often very directional making them poor choices for bridging a significant distance. I would think a pair of access points arranged as close to line of sight as possible would be a better choice. I have to wonder if you are actually communicating via powerline through a common utility transformer rather than via RF.

 

-Xathros

[oberkc]

I'm relying on RF to bridge the 100' as the power to the garage is a separate power source. On the same leg as the IOLinc I have a dua lband lamplinc and a dual band dimmer in the garage which i rely on for the RF back to the house.

Separate power source? Not on same meter and panel, huh? Is it possible that these separate power sources are on different transformers, or even different phases of the power grid? I am seriously starting to get out of my comfort zone here, but I am not sure that insteon will work if on different phases of the three-phase power system. I assume that the fact that this works SOMETIMES suggests, at least, that you are on the same phase.

 

Strange to me that one keypad would trigger the garage lights but another won't.

Strange...maybe. It could be explainable with a better sense of which keypads are working (the one in the garage, on the same power supply and leg) and which are not (separate power supply, hundreds of feet away?)

 

Did you add these garage devices to the ISY while they were installed in the garage?

[scubaguyjohn]

thanks...I wasn't clear...I'm relying on RF to bridge the 100' as the power to the garage is a separate power source. On the same leg as the IOLinc I have a dua lband lamplinc and a dual band dimmer in the garage which i rely on for the RF back to the house.

 

OK. That makes more sense. From what I have read here since the dual band devices started rolling out, these devices have rather minimal range and are often very directional making them poor choices for bridging a significant distance. I would think a pair of access points arranged as close to line of sight as possible would be a better choice. I have to wonder if you are actually communicating via powerline through a common utility transformer rather than via RF.

 

-Xathros

 

 

that's an astute observation...its entirely possible but I don't think so as I'd lose communication entirely when I'd move the lamplinc too far away from the house...I've ordered the 2 access points...my understanding is that isy doesn't "see" them but i can link them to one another to insure they are communicating.

 

off topic: some of my switches blink when there is network activity. I recall being able to change that feature with Homelinc, is there any way to change it with ISY or?

 

John.

[oberkc]

my understanding is that isy doesn't "see" them but i can link them to one another to insure they are communicating.

 

One does not "link" access points. Rather, one checks to confirm that they are on opposite legs of your electrical system.

[scubaguyjohn]

I'm relying on RF to bridge the 100' as the power to the garage is a separate power source. On the same leg as the IOLinc I have a dua lband lamplinc and a dual band dimmer in the garage which i rely on for the RF back to the house.

Separate power source? Not on same meter and panel, huh? Is it possible that these separate power sources are on different transformers, or even different phases of the power grid? I am seriously starting to get out of my comfort zone here, but I am not sure that insteon will work if on different phases of the three-phase power system. I assume that the fact that this works SOMETIMES suggests, at least, that you are on the same phase.

 

Strange to me that one keypad would trigger the garage lights but another won't.

Strange...maybe. It could be explainable with a better sense of which keypads are working (the one in the garage, on the same power supply and leg) and which are not (separate power supply, hundreds of feet away?)

 

Did you add these garage devices to the ISY while they were installed in the garage?

 

 

garage devices were added to ISY while installed in the garage. Both keypads are in the house which is what makes it strange one will and one won't control the garage lights. I can presently restore any of the devices in the garage without issue. Yes, on different meters and panels but off same power line. I think, however, the RF is doing the communicating.

[oberkc]

It sounds to me as if your analysis is accurate and that a couple of access points is the most likely solution. Hopefully, they have enough range.