Jump to content

IOLinc going on unexpectedly


johnnyt

Recommended Posts

Am stumped (again) by an IO Linc that's going on unexpectedly and that ISY doesn't even see going on.

 

I push button 6 on KPL 20.43.49 to turn off a scene that is supposed to turn off IOLinc 15.B9.70 and IO Linc 1F.50.CA as well as button 6, 7 and 8 on itself (the KPL)

 

Here's the event viewer when I turn the scene off using either the admin console or the KPL button (same exact thing happens every time - have done it about 10 times now trying to figure this out myself):

 

Sat 01/19/2013 01:08:44 PM : [iNST-TX-I1  ] 02 62 00 00 1B CF 13 00
Sat 01/19/2013 01:08:45 PM : [iNST-ACK    ] 02 62 00.00.1B CF 13 00 06          LTOFFRR(00)
Sat 01/19/2013 01:08:45 PM : [  15 B9 70 2]       ST   0
Sat 01/19/2013 01:08:45 PM : [  20 43 49 6]       ST   0

At this point IOLinc 1F.50.CA has turned on although neither the event viewer nor the console shows that happened

 

So I query 1F.50.CA:

 

Sat 01/19/2013 01:08:52 PM : [iNST-TX-I1  ] 02 62 1F 50 CA 0F 19 01
Sat 01/19/2013 01:08:52 PM : [iNST-ACK    ] 02 62 1F.50.CA 0F 19 01 06          LTSREQ (01)
Sat 01/19/2013 01:08:52 PM : [iNST-SRX    ] 02 50 1F.50.CA 1E.48.AD 2B 0F 00    PING   (00)
Sat 01/19/2013 01:08:52 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Sat 01/19/2013 01:08:52 PM : [iNST-TX-I1  ] 02 62 1F 50 CA 0F 19 00
Sat 01/19/2013 01:08:52 PM : [iNST-ACK    ] 02 62 1F.50.CA 0F 19 00 06          LTSREQ (LIGHT)
Sat 01/19/2013 01:08:53 PM : [iNST-SRX    ] 02 50 1F.50.CA 1E.48.AD 2B 0F FF    PING   (FF)
Sat 01/19/2013 01:08:53 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Sat 01/19/2013 01:08:53 PM : [  1F 50 CA 2]       ST 255

I assure you it was off before.

 

Here's me sending a device OFF command using the console:

 

Sat 01/19/2013 01:09:00 PM : [iNST-TX-I1  ] 02 62 1F 50 CA 0F 13 02
Sat 01/19/2013 01:09:00 PM : [iNST-ACK    ] 02 62 1F.50.CA 0F 13 02 06          LTOFFRR(02)
Sat 01/19/2013 01:09:00 PM : [iNST-SRX    ] 02 50 1F.50.CA 1E.48.AD 2B 13 02    LTOFFRR(02)
Sat 01/19/2013 01:09:00 PM : [std-Direct Ack] 1F.50.CA-->ISY/PLM Group=0, Max Hops=3, Hops Left=2
Sat 01/19/2013 01:09:00 PM : [  1F 50 CA 2]       ST   0

Here's the log during the above timespan: (HRV Low: 15.B9.70; HRV High 1F.50.CA)

 

1-MISC (Non Lighting) / HRV / HRV Low Speed	Status	0%	Sat 2013/01/19 01:08:46 PM	System	Log		
1-MISC (Non Lighting) / HRV / HRV High Speed	Status	Query	Sat 2013/01/19 01:08:53 PM	Web	Log		
1-MISC (Non Lighting) / HRV / HRV High Speed	Status	100%	Sat 2013/01/19 01:08:54 PM	System	Log		
1-MISC (Non Lighting) / HRV / HRV High Speed	Off	 	Sat 2013/01/19 01:09:01 PM	Web	Log		

I compared the IO Linc's and KPL's device links tables against what ISY has and they were identical in both cases.

 

I would like to show you a screen capture of the scene but the system won't let me upload the file. (board attachment quota reached)

 

Here's the device links table for IOLinc 1F.50.CA:

 

Device Links Table : HRV High Speed-S / 1F 50 CA 1
0
4088
162
0
1984685
16719617


1
4080
162
5
1711369
16711680


2
4072
162
6
2114377
0


3
4064
162
7
1471711
16711681


4
4056
162
7
2114377
16711680


5
4048
162
8
2114377
16711680


6
4040
162
22
1984685
0


7
4032
162
23
1984685
16711680


8
4024
162
27
1984685
0


9
4016
162
32
1984685
16711680


10
4008
162
37
1984685
16711680


11
4000
162
55
1984685
16711681


12
3992
226
1
1984685
16719617


13
3984
0
0
0
0

Link to comment

ISY Scene 1B has a link record in I/O Linc 1F.50.CA for that Scene number. The link record has an On Level of 00 which reverses the Relay action. Off command turns Relay On, On command turns Relay Off. That is why I/O Linc Relay is On in response to Scene 1B Off command.

 

Sat 01/19/2013 01:08:44 PM : [iNST-TX-I1 ] 02 62 00 00 1B CF 13 00

Sat 01/19/2013 01:08:45 PM : [iNST-ACK ] 02 62 00.00.1B CF 13 00 06 LTOFFRR(00)

Sat 01/19/2013 01:08:45 PM : [ 15 B9 70 2] ST 0

Sat 01/19/2013 01:08:45 PM : [ 20 43 49 6] ST 0

 

HRV High Speed-S / 1F 50 CA 1

0FF8 : A2 00 1E.48.AD FF 1F 01

0FF0 : A2 05 1A.1D.09 FF 00 00

0FE8 : A2 06 20.43.49 00 00 00

0FE0 : A2 07 16.74.DF FF 00 01

0FD8 : A2 07 20.43.49 FF 00 00

0FD0 : A2 08 20.43.49 FF 00 00

0FC8 : A2 16 1E.48.AD 00 00 00

0FC0 : A2 17 1E.48.AD FF 00 00

0FB8 : A2 1B 1E.48.AD 00 00 00

0FB0 : A2 20 1E.48.AD FF 00 00

0FA8 : A2 25 1E.48.AD FF 00 00

0FA0 : A2 37 1E.48.AD FF 00 01

0F98 : E2 01 1E.48.AD FF 1F 01

0F90 : 00 00 00.00.00 00 00 00

Device Record Count : 14

Link to comment
The link record has an On Level of 00 which reverses the Relay action. Off command turns Relay On, On command turns Relay Off. That is why I/O Linc Relay is On in response to Scene 1B Off command.

Thanks for pointing out the needle in that haystack, but I'm confused. It's counter to all other scenes I have that turn a device off when the scene is turned on or off when the device is set to 0 on level in the scene.

 

Is this unique to IO Lincs? If so, I guess it means I'll have to take the IO linc I want off out of the scene and write a program to do the work instead. And I guess it would explain past weirdness that I didn't understand (and didn't always notice), but what's up with that approach? Is it useful for garage door applications or something?

 

Where is this in the Smarthome documentation? Did I just miss it? Could it be added to ISY doc (assuming I didn't just miss it there either)? It seems like kind of an important exception for people to know, whatever the application.

Link to comment

The I/O Linc has three Momentary modes that are generally used in garage applications. Being able to reverse the Relay actions in combination with the various Momentary modes allow a KeypadLinc button press On or Off to control the Relay.

 

Smarthome makes no effort to describe the internals of link records and how various values affect device operation. Their user guides and quick start guides are written from the perspective of how to set up devices with Set button links and various On/Off/On Level conditions. Would be of little use for users to think about what values in a link record produce what results.

 

I don't think reversing a device response is limited to the I/O Linc relay. Seems like the MorningLinc has something similar, and probably other non-lighting devices. The Simplehomenet/Smartenit devices use On Level, Ramp Rate and Unit number for things other than what they mean for the main stream Insteon devices for lighting and appliance control. The 0% On Level resulting in a device being turned Off with an On command is pretty much universal across lighting and appliance control devices like the ApplianceLinc.

 

It would take a Developer Subscription to gain access to the confidential device spec's if you want/need the specifics on the internals. I don't have one as it requires an NDA which is just too limiting. Also some folks that have one express frustration over the level of detail and timeliness of the information even when one has a Developer Subscription.

Link to comment

LeeG, Thanks for the detailed response. The insight is always appreciated.

Smarthome makes no effort to describe the internals of link records and how various values affect device operation.

I see this as about basic device behavior and would not personally position it as describing the internals of link records. The concept that sending 0% on level turns a light off is well known and a key benefit of insteon automation. (By the way I use the latching mode of the io linc, not the momentary modes and not for a garage door application.) Maybe there's good reason to have a different story for lighting vs non-lighting but I think it should be better publicized, especially since it's different than the well known behavior. I say that but maybe I'm the only one who didn't know the difference in behavior. I also think the latching mode of an IO Linc should behave like a light.

 

I realize this comment should be made in the Smarthome forum more than this one. Just mentioning it in case UDI can fill another gap, as it so often does, and save others some grief. (Personally, now that I know I'll just work it)

 

Thanks again.

Link to comment

Any time.

 

"The I/O Linc has three Momentary modes that are generally used in garage applications. Being able to reverse the Relay actions in combination with the various Momentary modes allow a KeypadLinc button press On or Off to control the Relay."

 

I am aware the I/O Lincs are not being used in a garage application in this case. The above information was meant to describe how/why the command/relay action reversal is necessary/useful in some cases. The MorningLinc has the same capability, to reverse the On/Off command versus Lock/Unlock action. Some folks want a KPL On button press to open the garage door or unlock the MorningLinc. Others want just the opposite. Command reversal provides that. Memory says there is another Smarthome device with the same feature but I cannot bring it to mind.

 

For the benefit of others who might gain some general device knowledge from these topics. I suspect there are folks who do not know 0% On Level turns a light Off. I suspect there are folks who do not know that until recently KPL Secondary buttons did not support being turned Off with a 0% On Level. I suspect there are folks who do not know the I/O Linc and MorningLinc commands can produce the opposite effect. I suspect some folks are familiar with all of the above.

Link to comment

By the way, if this is the way IO Lincs (and other devices) work, can I ask that ISY show the proper state for them?

 

Having programs triggered when the device turns ON (even though it's supposed to be being turned off) would not only be appropriate but it certainly would have helped me (maybe others?) both notice the behavior and be able to more easily identify the root cause of what I thought was a problem... well, actually, still think is a problem, at least for latching mode.

 

Fortunately - or maybe unfortunately since it made it harder to find/track down - I only have one of my 9 IO Lincs (all similar "latching mode" HVAC applications) that I've put in OFF-when-another-one-is-ON scene. But interestingly I had been thinking of putting more of them in those kinds of scenes as a way to cut down on the number of programs I have (now at over 535). That's not going to happen now, of course.

 

Would I need to post this idea in Product Requests or is this good enough?

Link to comment

Michel

 

To clarify a little, johnnyt is not using Trigger Reverse to reverse the Sensor commands.

 

A Scene is being used with the I/O Linc Relay as a Responder. When the Responder On Level is 100% in the Responder link record a Scene On turns the Relay On (he operates in Latching Mode) and a Scene Off turns the Relay Off.

 

If the Responder On Level slider is changed to 0% On Level in the Responder link record, the Relay action is reversed. The I/O Linc turns the Relay On with a Scene Off and turns the Relay Off with a Scene On. Currently the ISY marks the Relay Current State based on the last command issued which is fine unless the Responder On Level is set to 0%. The Relay is actually Off when the last command sent is Scene On and the Relay is actually On when the last command sent is Scene Off. The ISY would have to note the Responder On Level as well as the Scene command being sent to know whether to mark the Relay On or Off. Similar to noting a 0% On Level of a lighting device to know that a Scene On is actually turning the lighting device Off. The difference with the I/O Linc Relay is that a 0% On Level affects both the Scene On and Scene Off.

Link to comment

Using a scene and regardless of trigger reverse setting:

 

1. setting the scene OFF turns IO Linc OFF whether the IOLinc was on or off before. So OFF works as expected.

 

2. Setting the scene ON turns or leaves an IO Linc ON that is set to 0%; something that would have turned a light off.

 

There's no toggling (reversing) going on. The only aberration is that 0% turns the device ON instead of OFF.

 

I think "trigger reverse" setting comes into play when one uses the sense and sets "relay follows input" - I don't use it in this case and can't confirm that right now.

 

If this is something UDI can fix with ISY code, I personally can't think of a situation for "latching mode" where it shouldn't work like a light (0 means off), however you or others may have examples where that is the case.

 

I might add too that there's precedent for fixing this otherwise presumably factory default behavior. I would point to the fact that ISY changes the factory default latching mode to momentary mode when linking in or restoring an IO Linc, which caused me grief a number of times before I posted about it earlier this month and the issue came to light.

 

Thanks again to LeeG for working through these things in detail with me.

Link to comment

Michel

 

What you wrote is exactly right. A 0% On Level in the link record reverses the Scene command actions. Scene On turns relay Off, Scene Off turns relay On. That is what this topic documented in the initial post.

 

johnnty was seeing one of his I/O Linc Relays turn On with a Scene Off and did not understand why. It was because the link record has a 0% On Level. This is well documented in the initial post which Queried the I/O Linc relay and found it On when it was expected to be Off. That is what this topic is all about. What is described in 1. in the post just before this one is just the opposite to what is described in the initial post of this topic..

 

The confusion now is that 3.3.10 no longer changes the actual Responder link record when the Responder On Level slider is moved. I had the event viewer running while moving the On Level slider. A command is issued to change the state of the Relay when the On Level slider is moved between 0% On Level and 100% On Level but no commands are issued to change the link record in the I/O Linc. Do not know when not changing the link record started. The initial post by johnnyt shows the Responder link record in the I/O Linc with the On Level of 00

 

0FB8 : A2 1B 1E.48.AD 00 00 00

 

With 3.3.10 (do not know when this started) not changing the link record when the Responder On Level slider is moved the link record cannot be set back to 100% On Level to stop the relay/command reversal.

 

Here is the event trace of moving the I/O Linc Relay Responder On Level slider. The first set of commands are when the slider was moved to 0% On Level, the second set of commands when the slider was moved back to 100% On Level. Note that no commands were issued to physically change the link record.

 

Mon 01/21/2013 08:47:09 AM : [iNST-TX-I1 ] 02 62 15 BB 5A 0F 13 02

 

Mon 01/21/2013 08:47:09 AM : [iNST-ACK ] 02 62 15.BB.5A 0F 13 02 06 LTOFFRR(02)

 

Mon 01/21/2013 08:47:09 AM : [iNST-SRX ] 02 50 15.BB.5A 19.70.06 2B 13 02 LTOFFRR(02)

 

Mon 01/21/2013 08:47:09 AM : [std-Direct Ack] 15.BB.5A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

 

 

Mon 01/21/2013 08:47:25 AM : [iNST-TX-I1 ] 02 62 15 BB 5A 0F 11 02

 

Mon 01/21/2013 08:47:25 AM : [iNST-ACK ] 02 62 15.BB.5A 0F 11 02 06 LTONRR (02)

 

Mon 01/21/2013 08:47:25 AM : [iNST-SRX ] 02 50 15.BB.5A 19.70.06 2B 11 02 LTONRR (02)

 

Mon 01/21/2013 08:47:25 AM : [std-Direct Ack] 15.BB.5A-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

 

Mon 01/21/2013 08:47:25 AM : [ 15 BB 5A 2] ST 255

 

 

 

 

johnnyt

 

After changing the Responder On Level slider do another Show Device Links Table for the I/O Linc. The link record On Level is no longer being changed when the On Level slider is changed.

Link to comment

LeeG is right that the initial problem was different than what my test this morning showed. Since I deleted the IO Linc from the scene that was causing the problem I had to move the slider from 100 to 0 in another one and that's what I reported on. But if the slider move does not get written then I can't replicate the situation because I don't have another IO Linc that's already set at 0% in a scene.

Link to comment

Archived

This topic is now archived and is closed to further replies.


  • Recently Browsing

    • No registered users viewing this page.
  • Forum Statistics

    • Total Topics
      36.6k
    • Total Posts
      367.9k
×
×
  • Create New...