How does ISY know device state?

[yardman 49]

I am looking for an explanation as to how the ISY handles device states. Specifically:

 

Question 1): When I turn a device "on" through the GUI, and it reports back "on", is that based on a return from the Insteon device, or is it just because I've told it to turn "on", so the GUI the supposed state of the device?

 

My reason is that I'm having some issues that may be PLM related, and I'm still trying to do more troubleshooting.

 

- What I'm seeing is that sometimes when I send an "on" command, it gets through with no errors.

- Other times it gets through (because the light connected to the device comes on, and the GUI reads "on"), but I get an error message saying "Cannot communicate".

- Stil other times, I keep clicking "on" in the GUI, but neither the GUI readback nor the light go "on", and I also get the "Cannot communicate" message.

 

So I'm just trying to better understand what is happening.

 

 

 

Question 2): When I turn a lamp on that is connected to a lamplinc, by physically turning the "on" knob on the lamp, the lamplinc will of course respond to the local sense and power on to allow the lamp to come on. When I then open the GUI to see if it thinks the lamplinc status is on or off, it thinks that the lamplinc is off, which of course it is not.

 

- So I'm assuming that when a lamplinc turns on from local control, it never updates the PLM/ISY. Is this correct?

 

Thanks

[black_fx_35]

Hi Frank,

 

Regarding your second question...

 

Why are you turning the lamp on with the physical switch? It is my understanding that the LampLinc should be controlled via a controller to turn the lamp on (keypadlinc, controllinc).

 

Not sure I understand why you are using the physical switch to turn the light on, so I am interested in finding out your reasoning?

 

Thanks.

[Mark Sanctuary]

Answering the question on device state; In the Insteon protocol each device responds with a confirmation message but it does not give back status of what the device just did. A separate query can be done to get status but it is slow. An example of this is a 30 device network can take 20-30 seconds to query.

 

So the ISY has to keep an estimated guess on levels for each device. It does a very good job of guessing, Michel has said the ISY is greater than 99% accurate.

 

So you ask, what is the reason the Insteon protocol does not return status from each device? Simple Levtion has a patent on returning status and strongly enforces the patent so Smarthome could not have devices return status during the execution phase.

[yardman 49]

Hi Frank,

 

Regarding your second question...

 

Why are you turning the lamp on with the physical switch? It is my understanding that the LampLinc should be controlled via a controller to turn the lamp on (keypadlinc, controllinc).

 

Not sure I understand why you are using the physical switch to turn the light on, so I am interested in finding out your reasoning?

 

Thanks.

 

Hello Black:

 

Lamplincs are similar to the old X10 lamp modules, in that they have something called "local control" enabled. Local control allows you to tell the Lamplinc "turn on" from the lamp itself, without having to walk back to somewhere else in the room to find the nearest linked Insteon controlling device.

 

Of course, to then turn the lamp back off, you would then want to go to the linked Insteon wall switch to turn the lamp off from there on your way out of the room), or have an event trigger turn it off. Otherwise, the next time you tried to turn on the Lamplinc remotely, the lamp really wouldn't turn on, since its "mechanical" switch would really be off.

 

So it would seem that we really do want the Lamplinc to send a state change to the ISY, so that the ISY is informed that someone has exerted "local control", and that the Lamplinc is now energized. In that way, you could have a trigger set for a program that would turn the Lamplinc back off after some defined amount of time has passed.

 

 

Answering the question on device state; In the Insteon protocol each

So you ask, what is the reason the Insteon protocol does not return status from each device? Simple Levtion has a patent on returning status and strongly enforces the patent so Smarthome could not have devices return status during the execution phase.

 

Hello Mark:

 

Great explanation. I'm not certain that it helps me understand other things that I'm seeing, but its good information to know.

 

Best wishes,

[yardman 49]

Hello Mark:

 

Could you take a stab at some additional explanations?

 

I previously wrote this:

- What I'm seeing is that sometimes when I send an "on" command, it gets through with no errors.

- Other times it gets through (because the light connected to the device comes on, and the GUI reads "on"), but I get an error message saying "Cannot communicate".

- Stil other times, I keep clicking "on" in the GUI, but neither the GUI readback nor the light go "on", and I also get the "Cannot communicate" message.

 

So, if according to your previous post, the Insteon protocol does not allow for a device status readback, does it at least receive back a "command acknowledged" from the controlled device? I thought that this was part of the Insteon protocol.

 

If it does at least receive an acknowledgement, why would I sometimes see the controlled light turn on, and yet the ISY GUI comes back and says "Can't communicate with (device name). Please check connections"? Obviously the lamp or light turned on, so some control is actually being exerted. And even if the PLM has a very weak outgoing signal, the signals coming from my Insteon devices shouldn't have changed, so you would think that the acknowledgment from the Insteon device would be received just as well as my PLC would receive them in Houselinc.

 

I guess it's possible that the PLM is lousy at both sending and receiving signals. If so, I could see the first two of my observations occuring. The third one may just be because the PLM stops responding to requests from the ISY.

 

Please let me know if any of my assumptions are correct, and if not, please set me straight.

 

Thanks

[Mark Sanctuary]

Hello Mark:

- What I'm seeing is that sometimes when I send an "on" command, it gets through with no errors.

- Other times it gets through (because the light connected to the device comes on, and the GUI reads "on"), but I get an error message saying "Cannot communicate".

- Stil other times, I keep clicking "on" in the GUI, but neither the GUI readback nor the light go "on", and I also get the "Cannot communicate" message.

 

The randomness of your issues is the communication issue you’re having, fix the communication issue and all these problems will go away.

 

The ISY needs the "readback" to take a good guess at the device level. Say you set from the ISY something at 30% and the PLM does not get the network "readback" I think the PLM reports an error to the ISY. Then the ISY makes its guess and it just shows "On" as the status instead of 30%. And if the device did not really turn on, the ISY would still show "On", but the device is actually "Off".

 

This is my outside looking in answer, Michel might correct me a bit if its not accurate.

[Mark Sanctuary]

When smarthome released the 5.2 version of the PLM we all noticed at least a 75% reduction in signal strength. So the "new" PLM needs hearing-aids.

[Michel Kohanim]

Hello Frank,

 

I think you have gotten some of the answers you were looking for. To clarify, here's how ISY works:

 

1. If you send a direct command (i.e turn on my lamplinc), then the status of the GUI updated if and only if the lamplinc comes back with a confirmation to the message. So, if you sent "On", then if the lamplinc sends an ACK to the "on" command, ISY will display the "on level" for your lamplinc (which has been captured in ISY). The same goes with Fast on but in this case the state is not the on level but it's "ON"

2. If the device does not reply back with an ACK, then ISY will show you "device communication error"

3. If you turn on the local load, ISY will NOT know for two reasons:

a. Lamplincs cannot be controllers and therefore they will not send their status to anything

b. The local load status in in r2 of INSTEON spec and not yet implemented (as far as I know)

 

2. If you send a group command, ISY predicts the status of all the members in the scene simply by having all the associated onlevel/ramprates. This is usually quite accurate (+/- 5%).

 

I personally think that the new PLM will solve most of your issues.

 

With kind regards,

Michel

[yardman 49]

Hello Michel:

 

As usual, you are a wealth of knowledge. Thanks very much for the detailed explanation.

 

You mentioned that Lamplincs cannot be controllers. I'd forgotten about this, so that makes perfectly good sense. But since the Insteon wall switches can be controllers, I'm guessing that for the ISY to know the state of the switches, then the PLM must be in the switches' link table; then the switch will update the PLM when someone comes into the room and changes the state of the switch.

 

So as far as a Switchlinc, Togglelinc, InlineLinc, they all know of the PLM as a "responder" to them. Hey, I think that my brainlinc on this just activated! (Pardon my ignorance on this stuff).

 

If my previous assumptions are correct, then does this logic also apply to Controlincs and Remotelincs? Or do they behave differently?

 

Appreciatively,

 

Frank

[Michel Kohanim]

Frank,

 

You are 100% correct!

 

With kind regards,

Michel

 

Hello Michel:

 

As usual, you are a wealth of knowledge. Thanks very much for the detailed explanation.

 

You mentioned that Lamplincs cannot be controllers. I'd forgotten about this, so that makes perfectly good sense. But since the Insteon wall switches can be controllers, I'm guessing that for the ISY to know the state of the switches, then the PLM must be in the switches' link table; then the switch will update the PLM when someone comes into the room and changes the state of the switch.

 

So as far as a Switchlinc, Togglelinc, InlineLinc, they all know of the PLM as a "responder" to them. Hey, I think that my brainlinc on this just activated! (Pardon my ignorance on this stuff).

 

If my previous assumptions are correct, then does this logic also apply to Controlincs and Remotelincs? Or do they behave differently?

 

Appreciatively,

 

Frank

[Sub-Routine]

Hello Michel:

 

As usual, you are a wealth of knowledge. Thanks very much for the detailed explanation.

 

You mentioned that Lamplincs cannot be controllers. I'd forgotten about this, so that makes perfectly good sense. But since the Insteon wall switches can be controllers, I'm guessing that for the ISY to know the state of the switches, then the PLM must be in the switches' link table; then the switch will update the PLM when someone comes into the room and changes the state of the switch.

 

So as far as a Switchlinc, Togglelinc, InlineLinc, they all know of the PLM as a "responder" to them. Hey, I think that my brainlinc on this just activated! (Pardon my ignorance on this stuff).

 

If my previous assumptions are correct, then does this logic also apply to Controlincs and Remotelincs? Or do they behave differently?

 

Appreciatively,

 

Frank

 

Frank, you are getting very close.

 

Actually, the SL, CL, KPL, etc. do not need to have the PLM in their database, but they must have at least one device in their link tables or they do not send a group command. These 'one-way' links are considered broken, because they half work. A device (i.e. the PLM) can respond to a command but the controller will not confirm any changes to that device.

 

The opposite broken link, when a controller has a device in it's database and the device does not have the controller in it's database (or is non-functional, or doesn't exist, etc.) can cause a lot of Insteon traffic because a controller will send several retries when a command is not acknowledged.

 

Devices do need to have the PLM in their link tables if you wish to control them from the PLM.

 

The PLM must have the controller in it's database or it will ignore any signals from that device.

 

An InlineLinc, like a LampLinc, is also not a controller.

 

You don't need to be concerned about these links as the ISY isolates you from these details. The ISY does make links the proper way, and includes the PLM in the device link tables.

 

Using Restore Device or Restore Devices from the ISY is supposed to eliminate any broken links in one or all devices. Restore Modem is designed to do the same for the PLM.

 

I hope this helps

 

Rand

[timlacey]

I understand that the Lamplincs are never controllers and that they don't send their updated status upon local control.

 

Here is my application.

 

I have a lamp in my kids' bunk bed that we use to read books. The kids know how to turn it on and off.

 

I like to monitor when the lamp is turned on. The kids turn it off and then the lamplinc status changes to OFF, because it must sense the current draw is gone. Then when they turn the light back on, the lamplinc status, when queried, turns back to ON. So the lamplinc becomes a MONITORING device for a local load and can be very handy.

 

You see, I want to know when the kids wake up and turn on their lamp, so I can go in and tell them to go back to bed or at least to be aware that they're not asleep.

 

So I set the ISY to query the Lamplinc every minute to get the current status, so then I always know within a minute whether or not the kids have turned on the light.

 

Could there be some default query option for all devices with local control, where you select the frequency (every minute to every 60 minutes) and on that interval, the ISY will query all the lamplincs and appliancelincs and any other local load control device?

 

Tim

 

Also, I know that local control could be enabled/disabled on the X10 switchlincs, so perhaps that can be done from the ISY for the new Insteon models. Then we could simply disable local control entirely and use a linked switch as a controller instead of using the light locally. (and not worry about the light getting turned on with no way to know it withour a query)

[upstatemike]

One option is to make your own lamplinc by putting an inlinelinc dimmer into a handy box with a blank cover. Cut an extension cord in half and wire it into the input and output of the inlinelinc dimmer to complete the module. Control the module with a Controlinc or some other Insteon switch. Then you have your instant status.

 

If you have Homeseer you can use the ISY plugin to announce when the light goes on during certain hours. (There may be other ways to trigger voice prompts from ISY triggers.)

 

If you don't have a way to trigger a voice prompt then get an X-10 chime module and have the ISY trigger it if the bedroom lamp goes on during the night.

[timlacey]

Your solution would cost more and would still have the problem of local load control permitted by the InLinelinc. I am more concerned with the general lack of status on local control devices rather than my specific example (which I felt compelled to give as a reason why monitoring a lamplinc might be useful). You can't always control whether people use the appropriate switch given local control potential.

 

As it stands, I can query the device periodically, which then updates the status, which gets passed to Homeseer to prompt an announcement.

 

The Homeseer Insteon PLM-based plug-in had a checkbox to query a particular device at a certain frequency, probably to address the rare cases where people want to monitor a local control load. I'm suggesting that UDI consider adding it an option for those types of devices unless they can suggest another easy way to monitor it or provide a means to disable local load control.

 

tim

[Sub-Routine]

To set up automatic polling for a group of devices you would create a scene containing all the devices you wish to query and then query the group instead of individual devices.

 

One person on the Smarthome forum reported that his new Lamplincs are sending updates when local control is used, but I have no personal experience. The new Lamplincs are also supposed to come with local control disabled and a set button method to toggle local control (instead of an X10 procedure).

 

Rand

[upstatemike]

Your solution would cost more and would still have the problem of local load control permitted by the InLinelinc...

tim

 

The point was that switchlincs and inlinelincs do not have a local control feature (that I am aware of) so you would not have the issue.

 

I agree that you can't always control if people will use the local control feature if it is enabled and I am a strong believer that it is a troublesome feature that causes more problems than it solves. I am suggesting that it should not even be there, but if it is you should disable it or use an alternative device that does not have it.

 

I do not think having a lamplinc that reports local control solves anything because the local switch on the lamp can be left in the off position so it is unavailable for scene control.

 

I do not think frequent polling for status is ever a good idea because of the potential traffic issues.

[timlacey]

I agree with your comments. I wish they could make the lamplincs report their status upon a local change.

 

I think out of all my devices, this is the only instance of this issue. Once the kids are older, this problem will go away.

 

My comment about the InLineLinc was based on another posting here that says that they do allow local control, just like a Lamplinc. I think this is true, because I've had them come on while changing light bulbs.

 

I agree that the extra traffic isn't desirable, so UDI is probably smart not to encourage it by adding the feature I suggested earlier. And my current method of using a periodic query is a temporary fix that I'll be on the lookout for easier ways to eliminate (maybe with a new lamp with an inline switch that I can put out of reach.)

 

Tim

[Michel Kohanim]

Hello timlacey,

 

If we can really ascertain that the local load status is sent by LL and AL, then all we have to do is to create a master link in LL/AL and slave link in the PLM.

 

This said, however, we have not been able to confirm that this feature actually works. We are awaiting official response from SH before trying to reverse engineer.

 

With kind regards,

Michel

 

I agree with your comments. I wish they could make the lamplincs report their status upon a local change.

 

I think out of all my devices, this is the only instance of this issue. Once the kids are older, this problem will go away.

 

My comment about the InLineLinc was based on another posting here that says that they do allow local control, just like a Lamplinc. I think this is true, because I've had them come on while changing light bulbs.

 

I agree that the extra traffic isn't desirable, so UDI is probably smart not to encourage it by adding the feature I suggested earlier. And my current method of using a periodic query is a temporary fix that I'll be on the lookout for easier ways to eliminate (maybe with a new lamp with an inline switch that I can put out of reach.)

 

Tim