I/O linc not updating status in the ISY?

[cartman413]

Hi,

 

Thanks for all the help, as you can see i'm working on a new install and have plenty of questions.

 

I have an I/O linc garage sensor that does not update it's status in the ISY when the garage is opened and closed.

 

If i run an manual query, it updates with 100% accuracy. Also all the keypad lincs that are responders to the I/O linc show the correct status every time. (lit for open, dim for closed)

 

It's an I/O linc 4.1 2450 with garage sensor kit.

 

I'm very confused as to why the status is not being reported to the ISY as the garage opens and closes.

 

Also after reading other posts. The greenlight on the I/O linc does come on and off as well when the garage moves. The way my garage is set up is ON means closed and OFF means open.

 

my settings are currently TX on LED, Trigger Reverse, and Momentary A. (hold of .2 seconds)

 

Also, the garage responds 100% of the time when sending a open/close command from the ISY interface. But the status never updates without a query.

 

Seems like something is not linked properly, but I thought the ISY was automatically linked with all the devices to receive status?

 

TIA.

[LeeG]

The links necessary for the I/O Linc Sensor are created when the I/O Linc is initially added to the ISY. However, it does sound like a link record problem. Right click on the Sensor node, select Diagnostics | Show Device Links Table. When the display completes click the Compare button which causes the ISY to compare the links read against what the ISY thinks should be there.

 

It is possible for the PLM link database to become full of duplicate and out dated link records. If the Show Device Links Table/Compare does not indicate a problem issue a Restore Modem (PLM) which will compress out duplicate and out dated links in the PLM. It sounds like the PLM has become full and did not accept the Responder link record necessary to receive Sensor state change messages.

 

It could be a communication problem between the I/O Linc and the PLM but since the Query works and the I/O Linc Relay responds it is more likely the PLM is full.

[cartman413]

Thanks for the tips, but nothing seems to work.

 

any other troubleshooting thoughts?

 

the compare showed everything identical and one (ignore/identical)

 

I did the PLM restore and even did factory restore on the I/O linc. nothing seems to work.

[LeeG]

Run Tools | Diagnostics | Event Viewer at LEVEL 3. Turn the I/O Linc Relay On 3-4 times allowing time for the door to cycle open and closed. Post the event trace. That will provide a general sense of the communication between the PLM and the I/O Linc by looking at the Hops Left=x count.

 

Run Tools | Diagnostics | Show PLM Links Table. When the display completes click Count to produce a count of the link records in the PLM. This sequence, Show PLM Links Table followed by Count should be done 3-4 times. If any Insteon traffic reaches the PLM during the Show PLM Links Table processing the link record display will not accurate and the subsequent Count will not be correct. Only when the same number of link records is obtained from a series of Show/Count sequences can the Count be considered accurate. If the PLM is still full the Count will be 992.

 

The I/O Linc can be moved to the PLM plug point and two pieces of wire connected to GND and Sensor. Touch the wires together to turn the Sensor On (Green LED at wire connections will be On when the Sensor is On). There is no danger of electrical shock as these wires carry very low voltage (less than 5 volt DC). Connect and disconnect the wires which should turn the Sensor On and Off. (Green LED will turn On and Off). Does this change in Sensor state register at the Admin Console.

 

Once the I/O Linc was factory reset a Restore Device must be done to rebuild the link database.

[oberkc]

Cartman413

 

Your post, and the details you included, suggest you have a good sense of what is happening. The fact that the led is going on and off, and that you keypads are also responding, suggest that the sensor is working, and properly linked via scene. If this were me, I would be focusing on factors that would make communication with the PLM problemmatic. What other devices and gadgets do you have plugged into the same outlet and circuit as the PLM?

[cartman413]

Of course as soon as i'm asked to post a log, the behavior has corrected itself this AM.

 

However I got a garage was open for more than 5 minutes messages right after my ISY was scheduled to do it's Query All at 3am.

 

Also the state of the Garage has flipped. Now Off is Closed and On is Open. (I use Mobilinc and I label them so I know when it's changed). (not sure if this is indicative of a communication error?)

 

I've attached my log file. First four triggers were from the ISY interface (open, close, open, close) than a couple more from the mobilinc interface. Mobilinc has an issue where i have to flip the switch back to off again to make the I/O linc activate. So that will probably show an extra line in the log for that.

 

I did the PLM count it's 41, 41, 41

 

I have not moved the I/O linc to the ISY plug (have to pull a ladder out and it's working currently).

 

My setup is relatively simple currently. Two Keypadlincs (non-dualband) and two Switchlinc dimmers (dual-band), the ISY and the I/O linc in the garage. They are grouped 1 keypadlinc and 1 switchlinc (DB) share a breaker controlling lights in two rooms.

 

My PLM is located in my network box plugged in there. The 2nd plug of that receptacle has a power strip with a small unmanaged switch and my router. Both very low power consumption boxes. The breaker it's attached eludes me as I've gone through about half of my breakers and never found the right one. (we have two panels) But I do know it's not on any of the AFCI circuits. I was trying to isolate what phase it was on earlier, but when I plugged in and everything seemed to communicate fine I stopped my search.

 

It's odd that I never have issues with sending commands from the ISY to the garage, and status for all the other devices seem to have status in sync so I discounted the communication issue. But now that I see everyone's comments, is it possible to see if the return router for updating status from the I/O linc is different than the transmission of the initial command?

 

Thoughts would be appreciated, and will definitely post a log when the behavior starts again.

 

Thanks,

ISY-Events-Log.v4.0.5__Sun 2013.07.14 09.29.11 AM.txt

[LeeG]

If the I/O Linc Insteon address is 22.D3.80 the posted trace shows good communication between the I/O Linc and the PLM. Messages with Max Hops=3 have Hops Left=2 which is as good as it gets. Messages with Max Hops=1 have Hops Left=0 which is also as good as it gets. Of course things are working now. This also means the link records in the I/O Linc and PLM are not in question.

 

The change in status at 3AM is the result of using Trigger Reverse. The Trigger Reverse option reverses the commands sent when the Sensor changes state. Sensor On sends an Off command, Sensor Off sends an On command. The Query issued at 3AM returns the true state of the Sensor not the command reversed state. The solution is to change the magnetic switch from NC to NO and turn Off Trigger Reverse. This has become an issue only since Smarthome stopped selling the garage kit with the combination NC/NO magnetic switch which allowed the user to select which switch produced the desired results.

 

The trace shows inbound messages from the I/O Linc to the PLM are fine now.

[LeeG]

What are you using to couple the two 120v phases?

 

If the SwitchLincs are expected to couple the two phases have the 4 tap set button test been run to confirm they are on opposite 120v phase. Appliances such as electric hot water heater, electric stove, electric dryer will couple intermittently. If the SwitchLincs are not on opposite phases you will not have reliable coupling which could explain why communication with the I/O Linc is intermittent.

[cartman413]

Thanks again for the reply.

 

So I do not have any 240 devices save the A/C. I have 240 breakers for an Oven but it's not in use. We are all gas here.

 

The A/C has not been on at all either. I know by looking at my panel layout that the Master Bed (where i have a keypad and dualband switchlinc installed) is on the same phase as the garage door opener. I ran the 4 push test just now. The Master Bed room dual band stays solid white. The other set Dual band in my Living room blinks red.

 

So that tells me that the garage door is communicating with the switchlinc in the master bed which communicates over RF with the PLM. Does that make sense given the Log saying 1 hop? Or should that be 2 hops?

 

When I was having the issue, the master bed did not have any issues that i know of communicating with the ISY, but i guess it's possible since most of those are scenes that are written to the insteon devices themselves. It stil seems odd to me that a on trigger sent from the ISY would go through no problem but the return status message send a second or two later would not make it back to the ISY.

 

Guess we can't tell much more until it happens again?

[LeeG]

The device that is blinking Red is receiving the RF test signal and is on the same phase as the Dual Band device where the 4 tap test was initiated.

 

The SwitchLinc not reacting (is that the correct interpretation?) is not receiving the RF test signal. It has to do something other than its normal state to indicate it is receiving the RF test signal. The status LED may blink On and Off, it may blink dim to bright, but it has to do something when receiving the test RF signal. Otherwise how would one know the RF signal is being received. In wall devices can behave oddly. I have a Dual Band SwitchLinc that does not receive the RF test signal from my ISY PLM unless I am standing near the SwitchLinc. My existence at the SwitchLinc is having an effect on the RF signal. Likely reflecting off my body back to the SwitchLinc since the ISY PLM is located physically behind the SwitchLinc. That is why I much prefer and do use Access Points for coupling.

[cartman413]

The change in status at 3AM is the result of using Trigger Reverse. The Trigger Reverse option reverses the commands sent when the Sensor changes state. Sensor On sends an Off command, Sensor Off sends an On command. The Query issued at 3AM returns the true state of the Sensor not the command reversed state. The solution is to change the magnetic switch from NC to NO and turn Off Trigger Reverse. This has become an issue only since Smarthome stopped selling the garage kit with the combination NC/NO magnetic switch which allowed the user to select which switch produced the desired results.

 

 

HI LeeG,

 

Not sure I understand this fix. Isn't the NO/NC the terminals for the replay in the I/O linc? i.e. isn't that how i close the circuit to activate the garage? If I set it to N/C won't it just stay closed all the time (like keeping the garage button pressed all the time?)

 

I like the trigger reverse setup cause in mobilinc and open garage is red and a closed garage is Green (i think colors are tied to on/off status.)

 

I was thinking of using this after the ISY runs a query at 3am. Any thoughts on this?

 

If

Time is 3:03:30AM

And Status 'Garage Sensor' is On

 

Then

Set 'Garage Sensor' Off

 

Else

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

 

Thanks!

[cartman413]

The device that is blinking Red is receiving the RF test signal and is on the same phase as the Dual Band device where the 4 tap test was initiated.

 

The SwitchLinc not reacting (is that the correct interpretation?) is not receiving the RF test signal. It has to do something other than its normal state to indicate it is receiving the RF test signal. The status LED may blink On and Off, it may blink dim to bright, but it has to do something when receiving the test RF signal. Otherwise how would one know the RF signal is being received. In wall devices can behave oddly. I have a Dual Band SwitchLinc that does not receive the RF test signal from my ISY PLM unless I am standing near the SwitchLinc. My existence at the SwitchLinc is having an effect on the RF signal. Likely reflecting off my body back to the SwitchLinc since the ISY PLM is located physically behind the SwitchLinc. That is why I much prefer and do use Access Points for coupling.

 

The LED was actually doing something It had like a slight flicker or something. It was as if it was blinking, but the blink was so fast you could barely tell. I'm fairly sure that it was receiving signal as I can regularly update and control that bank of lights with the ISY and my phone. And the status has always been up to date from what i can tell. Sorry I should have mentioned the flicker when i said I think it was passing the test. Not sure why it doesn't flash green though. I took it as "Solid White" meaning it was passing. But it definitely looked different than when in normal operation due regular flicker.

[LeeG]

When I discuss the I/O Linc Sensor and using NO rather than NC I am referring to the characteristics of the magnetic switch that is connected to the I/O Linc Sensor. The NO and NC I/O Linc Relay contacts have nothing to do with the Sensor being On or Off. Of course the Relay moves the door which changes the state of the magnetic switch but I am referring to whether the magnetic switch is closed (NC) when the magnet is next to the switch or the magnetic switch is open (NO) when the magnet is next to the switch.

[cartman413]

Hi LeeG,

 

Okay, I thought it was a reference to the terminals, but now i get what you are saying. I didn't know that you could even change that function outside of the "Trigger Reverse" check mark. The kit i have just has two magnetic bars and they attach to the I/O link via GND and Sensor.

 

Can you help me understand the work around? hoping my program will fix the "flip" when the ISY Query happens. But less complicated always seems better so If I can not have it switch on me by just reversing some connections, that would be ideal.

 

Also, I wonder if the change of state overnight is what was causing the issue as i noticed if i unselect the "Reverse Trigger" the status doesn't update properly until I open and close the garage.

 

Appreciate the Help!

[LeeG]

The Query can be tested by right clicking the I/O Linc Sensor node and select Query. That is the same Query issued at 3AM except it is only doing a Query of the I/O Linc.

 

The magnetic switch the garage kit came with in the past is item # 7455B SECO-LARM SM-226L-3. It is a wide gap switch which means it works even on doors that have play between the door and the magnetic switch. This switch has three wires. Use the Black/Red wires for the I/O Linc Sensor to be On when the door is open, Off when the door is closed. Using the Black/Red wires has the same effect as using Trigger Reverse except Trigger Reverse is not used so Query and I/O Linc Sensor are in sync.

 

Changing the Trigger Reverse option does not immediately change the Sensor state. The garage door has to be cycled open/close to see the result of changing Trigger Reverse.

[cartman413]

Okay, i think that is what has been causing my issue. It wasn't a communication issue, the ISY status was updating fine, but when i hit query it would change (flip) as it would return the standard status instead of the "trigger reverse" status and then i would close the door and nothing would happen as the state would match now. The query i would run was always pulling the opposite state. So when i moved the door to the next position it would match the trigger reverse state again, i hit query again, and it reports the opposite state again. Like a dog chasing it's tail.

 

So it sounds like this is a bug in the I/O linc software? or is this a bug with the ISY ?

 

Any thoughts on how to maintain the state of the I/O linc? I'm assuming the query is so the ISY can resync every night. But it's actually throwing it out of sync with the garage.

 

The trigger reverse is necessary because It lights the keypadlinc buttons as well. So off (closed) is a dim light and On (Open) is a lit LED key.

 

Is it possible to change the query to not include the garage I/O linc? or is the only solution to buy a new sensor?

 

I was hoping i could change the sensor state using a program in the ISY, but that doesn't seem to do anything. (any help on that as a work around would be appreciated as well.)

[LeeG]

The Sensor aspects of the I/O Linc is a Controller Only node. Its state cannot be changed with a Program.

 

I do not consider it a bug in the I/O Linc as it has worked this way for all the years the I/O Linc has been marketed. You can post a Product Request on the Smarthome forum. I don't think SmartLabs will change it after working this way for years. The time horizon for a design change of a SmartLabs product would be measured in years. It is not an ISY bug as the ISY has no control of the design of the I/O Linc.

 

See my last post. It has the Smarthome Item number and manufacturer number of an alternative magnetic switch which supports using a Normally Open (NO) magnetic switch rather than the Normally Closed (NC) magnetic switch now being used.

 

You can Disable the 3AM Query Program but it serves a good purpose to bring devices and ISY in sync in case there have been Insteon Mesh network issues in the previous 24 hours. You can write your own Scene with all devices except the I/O Linc and have the 3AM Program use that Scene.

 

You can stop using the Sensor as a Controller. Write an ISY Program that is triggered by the commands flowing from the Sensor (If Control 'iolinc sensor' is switched On, If Control 'iolinc sensor’ is switched Off) and have the Program turn the KeypadLinc button On and Off as desired. The Query will not affect 'If Control' as the Query does not result in commands flowing from the Sensor.

 

The simplest and best solution is to change the magnetic switch from NC to NO which has the same effect as using Trigger Reverse so the Trigger Reverse option is not necessary.

[cartman413]

Thanks agin LeeG,

 

I was thinking about all sorts o ways to reproduce what i'm doing with programs instead of scenes. But just seems like a big headache.

 

My little exercise here was a perfect example of knowing enough to be dangerous. LOL thanks again for the help. After realizing the trigger reverse was my issue I was able to research the issue and have seen you have given this advice many times. appreciate the patience!

 

btw are you an UDI programmer? seems like you have been an ISY guru forever based on the posts I've been seeing.

 

I have a quick question about creating my on query program. Do I need to query every single button? or just each device?

[LeeG]

No association with UDI. Have been using Insteon for along time. A KeypadLinc device (primary node) is queried, not each individual button.

[MWareman]

change the magnetic switch from NC to NO which has the same effect as using Trigger Reverse

 

Arguably not - at least entirely. If this were completely true, the result of the query would also be reversed. Changing the magnetic switch from NC to NO does both.

 

I do agree with you though - it's not a bug. I think it was a design flaw that nobody noticed until there was critical mass of deployed devices, and which point the 'if we fix this we break everybody's implementation' became a valid argument.

 

At the end of the day though, does it *really* matter if 'ON' = 'OPEN' or 'ON' = 'CLOSED' as long as it's always the same? Trigger reverse breakers this. Just disable it, and reverse the program logic. To me, that's the easiest solution.

[oberkc]

At the end of the day though, does it *really* matter if 'ON' = 'OPEN' or 'ON' = 'CLOSED' as long as it's always the same?

 

It matters to me, where I use scenes to control status displays, and prefer "ON" to indicate open.

[MWareman]

At the end of the day though, does it *really* matter if 'ON' = 'OPEN' or 'ON' = 'CLOSED' as long as it's always the same?

 

It matters to me, where I use scenes to control status displays, and prefer "ON" to indicate open.

I almost exclusively use MobiLinc - and I can override 'On' to actually say 'Open' or 'Closed' as necessary. My irrigation does not actually say 'On' - rather 'Running' or 'Off' on each zone.

 

I guess if you cannot arbitrarily rename the status on your chosen client it does matter thou.

[oberkc]

I guess if you cannot arbitrarily rename the status on your chosen client it does matter thou.

 

Such as with a keypad button (which, I submit, is the most common of "clients").

 

Perhaps, someday, we can have a means to easily duplicate a configurable keypad function on a tablet, and use them in place of a keypadlinc. In my mind, we are not quite there yet.

[MWareman]

I guess if you cannot arbitrarily rename the status on your chosen client it does matter thou.

 

Such as with a keypad button (which, I submit, is the most common of "clients").

 

Perhaps, someday, we can have a means to easily duplicate a configurable keypad function on a tablet, and use them in place of a keypadlinc. In my mind, we are not quite there yet.

 

Ahh - I don't do that.