OutletLinc Behavior and ISY, Scenes, & REST

[blaine]

I'm curious as to why an OutletLinc (Insteon 2473) cannot be added as a controller to a scene. It's got a local button on the outlet that allows one to turn the switched outlet on and off. Because of this "feature", I'm unable to have it drive behavior elsewhere in the system. Because of the local switch on the device itself, I really don't see any difference between this and, say, a SwitchLinc.

 

In my particular case, this is a coffee pot. If someone enables the coffee pot manually at the outlet, I want to be able to see that reflected via scenes and REST.

 

--Blaine

[LeeG]

OutletLinc does not have Controller capability so it cannot be added to a Scene as a Controller. Same with the ApplianceLinc.

 

EDIT: refer to the OutletLinc User Guide. It describes how to link it as a Responder but no instructions on how to link it as a Controller. Some Insteon devices are Controller Only, some are Responder Only, and some can be Controller and Responder. The OutletLinc is a Responder Only device.

[blaine]

OutletLinc does not have Controller capability so it cannot be added to a Scene as a Controller. Same with the ApplianceLinc.

OK... good to know, but I'm not sure I understand the logic here. I'd actually like it better if the switch wasn't physically on the device.

 

Knowing this, I would think that I should at least be able to query the status of the device accurately via REST to figure out what state it's in. I've tried switching the device locally and the query via REST doesn't reflect the state change. This does work with ApplianceLincs based on my experience.

[LeeG]

Run the event viewer at LEVEL 3. Then issue the REST command. Is a command being sent to the OutletLinc? It sounds like the REST command is pulling the current State the ISY knows about which would not reflect that it is On. What actual REST command is being issued?

 

Unfortunately nothing you post here about how the device works versus how you would like it to work has any influence over the manufacturer (SmartLabs). There is a topic on the Smarthome forum for posting product requests.

[blaine]

Run the event viewer at LEVEL 3. Then issue the REST command. Is a command being sent to the OutletLinc? It sounds like the REST command is pulling the current State the ISY knows about which would not reflect that it is On. What actual REST command is being issued?

 

Unfortunately nothing you post here about how the device works versus how you would like it to work has any influence over the manufacturer (SmartLabs). There is a topic on the Smarthome forum for posting product requests.

I realize your last statement... I'm just venting. If it was mission critical, I'd go over there and post.

 

As for the command I'm issuing, it's "http://192.168.1.50/rest/nodes/18%2039%2081%201". This is the address of the OutletLinc.

 

I think this exercise caused me to stumble onto something. I'm using a 2-way driver (that I didn't develop) for an RTI remote control system. The driver sets up REST subscriptions for every device I've set up. I rebooted the ISY and I was seeing everything ticking away just fine in the event view, including the REST query. As soon as I fired off a command from the RTI system, everything stalled on the event viewer. The funny thing is, the subscriptions are clearly working for every device other than the OutletLinc. Nonetheless, something strange is going on because I'm not seeing anything reflected in the event viewer for any REST query/command that I issue, regardless of the device, once the RTI system is invoked.

 

I'm not well versed in the event viewer, but this doesn't seem right.

[blaine]

In the interest of not confusing things, I'm isolating out just the ISY system behavior and removing the RTI system from the equation. I think things were getting a bit confusing, for me anyway.

 

I did a fresh reboot of the ISY and brought up the event viewer in level 3. Once everything settles down, I can see the clock clicking off every second and nothing else. I issue the REST query mentioned previously and see nothing come up in the event viewer. Should I? Curiously, the second counter eventually stops... don't know if that's normal behavior or not. This is the behavior that lead me to an erroneous conclusion in my previous post.

 

Thanks,

Blaine

[LeeG]

This REST command returns the information the ISY currently has. It does not physically Query the device

 

"http://192.168.1.50/rest/nodes/18%2039%2081%201"

 

This REST command actually sends a Query command to the device.

 

http://192.168.2.2/rest/query/1A%2084%20BB%201/

 

After this REST command is issued the first REST command can be issued to return the current state of the device.

[Michel Kohanim]

Hi blaine,

 

LeeG is 100% correct. Also, I am not sure I understand why you would have subscriptions for every device. ISY is not that granular to let you subscribe to certain devices only.

 

There's already a RTI driver for ISY. Have you tried it?

 

With kind regards,

Michel

[blaine]

Hi blaine,

 

LeeG is 100% correct. Also, I am not sure I understand why you would have subscriptions for every device. ISY is not that granular to let you subscribe to certain devices only.

 

There's already a RTI driver for ISY. Have you tried it?

 

With kind regards,

Michel

Lee/Michel,

 

I'm not sure I could botch what I'm trying to convey any worse than I already have.

 

1) I'm using the RTI driver for ISY that you mention

2) I'm making ASSumptions about REST, including how it's used in said RTI driver

3) I haven't read the SDK documentation about subscribing and hence don't know how that actually works. The driver is clearly doing what it should be, however that's done, which is not how I imagined it's done.

3) I'm using a couple of REST commands to simulate what I imagine is going on in the driver I'm using and get different results for the OutletLinc vs. every other device when controlled locally at the device.

4) The OutletLinc, independent of whatever is actually going on in the driver, behaves differently than all other devices in regards to status and the driver. I don't believe this is an issue with the driver, but I could be wrong there too! This is why I'm asking here. The RTI driver is completely agnostic to the device I'm attempting to control.

5) I know only enough to be dangerous in regards to the usage of REST... my intent was never to become an expert in REST, but rather to get a fully functioning RTI system, including OutletLincs.

6) The OutletLinc still doesn't update its status in RTI when turned on locally (this is the only thing I'm trying to address!!!) where every other device does so instantaneously.

 

With that out of the way, shall we start from scratch?

 

Thanks,

Blaine

[LeeG]

You are absolutely correct that most Insteon devices send an updated Status when controlled locally. Would need to know the other device types you mentioned but it is normal for most devices to function as both a Controller (send updated Status change message when changed locally) and Responder. This has nothing to do with REST.

 

The OutletLinc Relay DOES NOT function as a Controller. It is a Responder Only device. The state change that occurs by pressing the local button on the OutletLinc Relay DOES NOT send a state change message to the ISY. Again, having nothing to do with REST.

 

The REST command that retrieves the current information in the ISY about the OutletLinc Relay WILL NOT reflect any local state change that has happened from pressing the local button. Again, the OutletLinc Relay is a Responder Only device. There is a REST command (mentioned in my previous post) that will send a Query command to the OutletLinc which will determine the current OutletLinc state. This REST Query command must be issued against the OutletLinc Relay before issuing the REST command that returns the current information in the ISY.

[blaine]

OK... starting to feel like Groundhog Day!

 

Short of requesting something special from the RTI driver developer for OutletLincs (and apparently ApplianceLincs too), I've resigned myself to live with the shortcoming.

 

Thanks,

Blaine

[LeeG]

There are more Insteon devices that function as Responder Only devices. You can know this in advance by checking the device User Guide for instructions on linking. If the User Guide does not include instructions for linking as a Controller it is a Responder Only device regardless of whether it has a local switch. Even this approach can be misleading. The I/O Linc User Guide has instructions for linking as a Controller but that applies to the Sensor part of the I/O Linc which happens to be Controller Only. The I/O Linc Relay part of the I/O Linc is a Responder Only. The I/O Linc automatically turns the Relay Off in Momentary mode which State change is NOT sent to the ISY.

 

Bottom line is do not assume anything about a specific Insteon device. Just because a KeypadLinc and SwitchLinc as examples function as both Controller and Responder, not all Insteon devices do even when they can be controlled with a local switch. Some devices are Controller Only, some are Responder only, and some (probably most) are Controller/Responder devices.