KPL not tracking microlink or switch state

[barrygordon]

I have several keypads installed all working, or non working in the same manner.

 

Lets take one as a typical example. These are 8 button KPL's. One of the buttons is cross linked to a microlink. If I use the KPL button to control the microlink the microlink responds correctly and the light on the KPL button tracks the state. If I address the ISY (REST interface over TCP) to control the microlink, the microlink operates turning on and off correctly, but the KPL button does not track the state of the microlink with its light. The same condition also exists of I control the microlink directly from the ISY using the Admin system.

 

The above is true for all such situations for multiple keypads, some being 8 button and some being 6 button.

 

I am running the version v4.0.4 of the ISY firmware and version v4.0.5 of the UI according to the about dialog box.

 

Your assistance is appreciated.

[oberkc]

One of the buttons is cross linked to a microlink.

 

I normally associate this "croos link" expression to the manual (using button or paddle presses) process of linking devices to each other. To be sure, have you define a scene in the ISY including the button and microlinc as "controller"? If you cross-linked these manually, then you need to clear this and create the ISY scene.

 

If I address the ISY (REST interface over TCP) to control the microlink, the microlink operates turning on and off correctly, but the KPL button does not track the state of the microlink with its light. The same condition also exists of I control the microlink directly from the ISY using the Admin system.

 

I cannot help with the REST interface, but suspect the concepts are the same as that for the admin panel. When you want multiple devices in a scene to track the same status, one must send commands to the scene, rather than to a device in the scene (even if that device is a controller). From the admin panel, choose the scene in which you created (or should have created...see response, above) to cross-link the devices. Turn that scene on/off. Observe KPL status following microlinc.

[Xathros]

If I address the ISY (REST interface over TCP) to control the microlink, the microlink operates turning on and off correctly, but the KPL button does not track the state of the microlink with its light. The same condition also exists of I control the microlink directly from the ISY using the Admin system.

 

In both cases you are issuing direct commands to the microlinc. You need to address the scene that contains both the microlinc and KPL button via /Rest and the Console to get the results you desire.

 

Use /rest/nodes/scenes to retrieve a scene list. Use the scene id in /rest/nodes//cmd/

 

-Xathros

[barrygordon]

Thanks Xathros, That resolved it.

[barrygordon]

Oops, not quite resolved. I have subscribed to feedback. In the scenario described above both the KPL and micro link work correctly but i get no feedback. If I send the rest command directly to the micro link status feedback comes in on the subscription port as expected.

 

Any help advice appreciated.

[Xathros]

There is no "Scene Status" in the Insteon world so for status checking, you need to look directly to the devices.

 

-Xathros

[barrygordon]

I understand that, but since the microlink changed state, shouldn't I get a status report regarding that fact from the Insteon microlink / ISY?

[Brian H]

Did you ever get the firmware and UI versions to match?

Both should be the same.

[barrygordon]

Yes the Firmware and UI versions are now the same at 4.0.5

[Xathros]

Did you ever get the firmware and UI versions to match?

Both should be the same.

 

 

Yes. I would think so. I have not played with subscriptions yet. Time for someone else to step in and pick this up from here.

 

-Xathros

[LeeG]

Run Tools | Diagnostics | Event Viewer at Level 3. The Admin Console uses the same subscription. Devices that respond to Scene On/Off DO NOT report state changes. The ISY looks at what the Scene action should accomplish and marks the device accordingly assuming the device reacted correctly.

 

See the following Event Viewer trace activity. The first Scene On turned the device On and produced a trace entry that reflects what ISY assumes the device did. The second Scene On has no device state message because the device was already On, therefore no state change. Regardless of whether a state change, note that there is no device response to the Scene On in either case.

 

Wed 06/19/2013 12:39:33 PM : [iNST-TX-I1 ] 02 62 00 00 32 CF 11 00

Wed 06/19/2013 12:39:33 PM : [iNST-ACK ] 02 62 00.00.32 CF 11 00 06 LTONRR (00)

Wed 06/19/2013 12:39:33 PM : [ 15 B2 6A 1] ST 255

 

Wed 06/19/2013 12:39:40 PM : [iNST-TX-I1 ] 02 62 00 00 32 CF 11 00

Wed 06/19/2013 12:39:40 PM : [iNST-ACK ] 02 62 00.00.32 CF 11 00 06 LTONRR (00)

[barrygordon]

Thanks for all the assistance. The final problem; subscription feedback; was a bug in my code. Everything is working fine now. The ISY is behaving as I expected it to.

 

Once again, Thanks!

[barrygordon]

Why doesn't the ISY allow me to send a command directly to a key on a keypadlinc to turn on or off?

 

Lets say the keypadlinc is at address 22 46 C0 so button c would have the address of 22 46 C0 3. If I send a rest command to that address to do a DON or DOFF, the command is rejected i.e. the command does not succeed.

 

Is that by design or a bug?

[Michel Kohanim]

Hi Barry,

 

Not a bug.

 

With kind regards,

Michel

[ISYhbsh01]

The ISY cannot send a direct command to buttons on a keypadlinc other than the the main load-controlling buttons. This is an Insteon limitation. You need to create a scene and add the specific button as a responder to the scene. Then you can have the ISY control the scene.

 

Sent from my SPH-D710 using Tapatalk 2

[LeeG]

Barrygordon

 

As Michel and hbsh01 have already noted this is an Insteon limitation. Every button on a KPL has a specific Group number. For example, a 6 button KPL Secondary button A = Group 3, B = Group 4, C = Group 5, D = Group 6. For the KPL to know which Secondary button should react to a command it must be told the Group number of the button. Insteon Direct commands do not have a field (placeholder) for a Group number so the Secondary button cannot be identified.

 

Responder link records do have a field for Group number. That is why Secondary buttons on a KPL must be commanded by a Scene that has a Responder link record associated with it.

 

The Primary load control button (Main A on 8 button KPL, ON/OFF on 6 button KPL) is assumed to be the button being controlled by Direct commands. That is why Direct commands can turn the KPL load On/Off but cannot control Secondary KPL buttons.

 

There is a very old document, insteondetails.pdf, on insteon.net web site. The document details the Insteon Direct message field by field. Although an old document the field format of the Direct message has not changed since Insteon was first released.

[barrygordon]

Thanks again. Great support!

 

The system I developed for the iPad written in JavaScript using the command fusion system is working just the way I want. I need to do some work on the ISY in the scenes I have defined to eliminate some and organize them better. The system tracks the state of all insteon devices using a subscription. The iPads, one mounted i the wall of each major room, are dynamically updated as things change. Sliders move, bulb icons brighten and dim, etc.

 

I am having an issue with ISY programs, but that has nothing to do with the iPads. Sometimes, a program does not see to run. E.g. I have a program thet turns on the outside lights at sunset and one that turns them off at 11 pm. They generally run fine,but sometimes it appears as if they have not run. I.e. the lights do not turn off or do not turn on. Infrequent, but does semmto occur. I need to track this down. Suggestions on how to do that would be helpful. Intermittent problems are a bitch.

[LeeG]

barrygordon

 

The Programs | Summary page is a good place to start. It contains the Last Run Time and Status (True/False evaluation of If) for each Program. If the Program did not Run look at the Folder conditions if the Program(s) are in a Folder. If it Ran but has a Status of False the Else was driven which may have prevented commands from being issued.

 

If the Program Ran and the Status is as expected then look at what the Program issued. Scene commands can be less reliable if the Insteon Mesh Network has marginal areas. Although you mentioned not turning On as well, not turning Off can be the type of load the device is controlling. It is not unusual for a device to turn On but not respond to Off because of the interference generated by the load being controlled.