Author |
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 10:53 | IP Logged
|
|
|
I've got a few 2457D2's, the new more-polished LampLinc modules that don't look quite as much like a brick hanging on the wall.
These have the ability to use their local load sense to trigger commands to other Insteon devices, so for example toggling a light on or off can trigger another Insteon device as well.
This seems to work great but Power-Home doesn't seem to pick up on it as expected.
The devices are configured as the generic "XXXX" device within PH since there's no predefined template.
Links are created from the LampLinc to the PLM, just as you'd do to sense any other switch. The messages are clearly sent to PH. I see
RECEIVEINSTEONRAW=14 20 26 0E D9 90 41 11 01
RECEIVEINSTEONRAW=14 20 26 0E D9 90 41 13 01
in the log, so I'm guessing that something there is a bit off and PH doesn't like it. Has anyone gotten that sort of thing to work?
Thanks.
|
Back to Top |
|
|
BeachBum Super User
Joined: April 11 2007 Location: United States
Online Status: Offline Posts: 1880
|
Posted: August 06 2010 at 11:45 | IP Logged
|
|
|
Have you tried setting them up as 2456D2 in devices?
__________________ Pete - X10 Oldie
|
Back to Top |
|
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 11:52 | IP Logged
|
|
|
Yes, then you can't install responder links. Bludgeoning them down to the feature level of the previous product "works" if your definition of "works" is ignoring the new feature. I was hoping to actually get the new feature to work, though...
What I really wish is that SmartHome would make their products fully featured to begin with. It stinks to have already invested money in products and then they go and add features like the RF and the enhanced load sense.
|
Back to Top |
|
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 12:02 | IP Logged
|
|
|
Oh, and just to complete the thought, it also doesn't work if you set it up as XXXX with the links, then change it to a 2456D2, or even a 2476D, which was originally what made me think it might have been some sort of data format issue (I would have thought that might work). I also meant to mention that it does eventually pick up on the device change via status scan, but that's not very real time and kind of duh when it's getting an Insteon message from the device as it happens.
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 12:10 | IP Logged
|
|
|
Unless you posted only snippets of the PH log the link in the PH PLM is not there or not correct. The PLM is posting the Group Cleanup Direct command to PH because that command is specifically addressed to the PLM. That message indicates the LampLinc has a link pointing to the PLM. The Group Broadcast message that preceded the Group Cleanup Direct (assuming it is not in the trace) requires a link in the PLM pointing back to the LampLinc for the PLM to post that message to PH.
What Trigger Type are you using in the Trigger?. Some will not work because of the missing Group Broadcast message.
Likely you can define your own Device Type entry that reflects the basic characteristics of a SwitchLinc or even use the SwitchLinc Device Type.
__________________ Lee G
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 12:33 | IP Logged
|
|
|
Your last post was not there when I started my post. The Device Type does not control what messages the PLM will post back to PH or what PH will do with them. It does affect what PH will initiate regarding defining links as you have already seen,
I am pretty sure PH is setting the device status when it sees a Group Broadcast command. Once that message is being processed I think you will see the device entry status follow.
__________________ Lee G
|
Back to Top |
|
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 12:38 | IP Logged
|
|
|
There's no trigger, I'm just watching for status changes in the Device Status screen. The LampLinc does have a link pointing to the PLM. It's not clear to me why there would be a group broadcast.
What has worked here up 'til now is that Insteon switches (and remotes and etc) are configured to have links to the PLM. This allows PowerHome to instantly update its concept of a device's status when the device is locally controlled.
Speaking from a "newbie" point of view, I have to say that actually figuring out how this stuff is all supposed to work is quite frustrating; Insteon's "group" features seem rather sketchy and hard-to-use and not actually necessary for many purposes. We have groups for scene control, for example, "kitchen on" or "all lights off", and that makes sense.
But let's consider something simple, like just a 2476D linked to a 2456D2. What's the setup supposed to be? Here we just set up a link from the 2476D to the 2456D2 and to the PLM, and if we want PH to be able to control it, then a link from the PLM back to each device. You could set up a group for that bit instead, but then you lose the ability to independently control each device. You seem to be saying, though, that you should be setting up a group on the 2476D to talk to the 2456 and the PLM rather than individual links. I was never able to get such a configuration to work properly and have PH recognize what was going on if I tried that. Is that the preferred way to do it, and if so, how's it actually set up?
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 13:06 | IP Logged
|
|
|
It is worth the time to learn how Groups (Scenes) work as all Insteon hardware device to hardware device control is done using Group protocol. When you press a KPL button, SwitchLinc paddle, etc that device is the Controller and it sends a Group Broadcast message on the powerline that is not addressed to any specific Insteon address. All Insteon devices that have a "Responder to" link record that matches the Insteon address of the Controller will respond to the command in the Group Broadcast message. This is how Insteon accomplishes near simultaneous response of all the devices that have been linked as responders to the Controllers Group.
The problem is that the Controller cannot know if all (or any for that matter) responder devices actually received the Group Broadcast message. It is sent in the blind, that is no specific To device address so no responder can ACK that message. Usually works very well but if the powerline is less than ideal or has some noise when the Group Broadcast is sent some of the responders will not see the Group Broadcast message.
The Controller then sends a follow-up Group Cleanup Direct message to each responder that has been linked to the Controller button/paddle. This message is addressed specifically to an individual device (this is the message that you posted) and the responder device will send an ACK message back to the Controller to confirm the message was received. If the Controller does not receive an ACK message it will retry the Group Cleanup Direct message up to a total of three times. This sequence is done for each responder device.
Normally a responder device has already seen and reacted to the Group Broadcast message. In this case the Group Cleanup Direct is simply Acked. If the Group Broadcast had not been seen the responder device reacts to the command in the Group Cleanup Direct. This redundancy is a major reason Insteon has such good quality. Each Insteon device being a repeater is also key to Insteon reliability.
Powerhome triggers (some) are dependent on seeing the Group Broadcast message. As mentioned before I think PH also updates the device status based on the Group Broadcast message. This message is always sent by the LampLinc. If the PLM is not passing the Group Broadcast message to PH it is because the PLM does not have a “Responder to” link record with the Insteon address of the LampLinc.
EDIT: to clarify something in your last post, it is not necessary for the PLM to have a "Controller of" link record for the responder to be able to control the responder. There is class of Insteon messages called Direct messages. These can be sent from PH to the responder and do not require any link records on either end. Only if you want to use Group commands are link records in both devices required. Groups allow multiple responder devices to be controlled nearly simultaneously with a single Group command issued from PH. Also some Insteon device stuff can only be controlled with Group commands such as turning On/Off KPL Secondary buttons.
Edited by grif091 - August 06 2010 at 13:23
__________________ Lee G
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 13:37 | IP Logged
|
|
|
Quote:
You could set up a group for that bit instead, but then you lose the ability to independently control each device. |
|
|
Having links in a device DO NOT prevent direct device control.
Quote:
and if we want PH to be able to control it, then a link from the PLM back to each device. |
|
|
You can use Insteon Direct commands to control the device without creating a link from the PLM to the device. The ph_insteon, ph_insteonwithret functions send Insteon Direct commands which do not use link records on either end. These commands work regardless of whether links exist or not. The ph_insteongroup commad sends an Insteon Group command sequence which requires link records on both ends.
Edited by grif091 - August 06 2010 at 13:40
__________________ Lee G
|
Back to Top |
|
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 14:00 | IP Logged
|
|
|
grif091 wrote:
Quote:
You could set up a group for that bit instead, but then you lose the ability to independently control each device. |
|
|
Having links in a device DO NOT prevent direct device control.
Quote:
and if we want PH to be able to control it, then a link from the PLM back to each device. |
|
|
You can use Insteon Direct commands to control the device without creating a link from the PLM to the device. The ph_insteon, ph_insteonwithret functions send Insteon Direct commands which do not use link records on either end. These commands work regardless of whether links exist or not. The ph_insteongroup commad sends an Insteon Group command sequence which requires link records on both ends. |
|
|
When I toyed with that, it seemed that while you could control the DEVICE that way, PowerHome didn't recognize the status of the device had changed. I really want the home automation system to be aware of the state of the real world, so generally speaking, techniques where that happens with minimal fuss seem to be more correct to me than techniques that involve manually sending Insteon commands and then updating databases manually, because coding several steps manually is just another place for errors to be introduced.
|
Back to Top |
|
|
jgreco Newbie
Joined: December 22 2009
Online Status: Offline Posts: 18
|
Posted: August 06 2010 at 14:22 | IP Logged
|
|
|
grif091 wrote:
Powerhome triggers (some) are dependent on seeing the Group Broadcast message. As mentioned before I think PH also updates the device status based on the Group Broadcast message. This message is always sent by the LampLinc. If the PLM is not passing the Group Broadcast message to PH it is because the PLM does not have a “Responder to” link record with the Insteon address of the LampLinc. |
|
|
You mean "responder (of current device)"? It does, but it's for a specific group, since it's part of the "all lights" scene. But you still only get the traffic I mentioned previously. And that's where the Insteon and PH terminology seem to devolve into sucking, since "responder to" sounds like what PH is calling "Controllers (of current device)".
As it stands, the PLM is listed as a responder to the LampLinc, which is what it sounds like you mean, but then you guys are complaining about the results of that link. So I'm still unclear on what it is that you think should exist or what it's supposed to look like.
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 14:57 | IP Logged
|
|
|
Group numbers must match as well as the Insteon address of the Controller and type of link record. The terms "Controller of" and "Responder to" link record types are what Smartlabs uses to describe the two link record types. "Controller of" link records are what the device looks at when it is functioning as a Controller. An 8 button KeypadLinc uses Group numbers 1-8 to represent the 8 buttons. When you press button C (Group 3) the hardware searches through the link database in the KPL looking for "Controller of" link records with Group number 3. It uses these records to know what the responder Insteon device address is for the Group Cleanup Direct commands. "Reponder to" link records are used by the device when it is functioning as a responder. When an inbound Group command is received by the device it searches its link database looking for "Responder to" link records that both match the Group number in the inbound message as well as the Insteon device address of the "from" device. If a match is found the device responds using the bright level, ramp rate, etc information in the matching “Responder to” link record.
If the LampLinc is the PH "Current Device", "Controllers (of current device)" link definitions listed in this section are "Responder to" link records in the Current Device link database as these link records represent devices (controllers) that are Controlling the Current Device. A single line in this section also represents the link record in the Controller device link database which would be a "Controller of" link record.
Link definitions in the "Responders (to current device)" section represent "Controller of" link records in the "Current Device" link database as they represent devices being Controlled by the current device. A single line in this section also represents the link record in the Responder device link database which would be a "Responder to" link record.
I found this a bit confusing in the beginning as I had years of Insteon experience looking at link records from the device hardware perspective. Powerhome is presenting the information from a User perspective which is just the opposite to the way an individual Insteon hardware device looks at the world.
The question of Powerhome awareness of device status is separate from being able to control it directly. Generally PH is pretty good at keeping track of device status. I wrote a Macro that used ph_insteon functions to turn On then Off a LampLinc using Insteon Direct commands (no link records involved) . The PowerHome Device Status display correctly showed the LampLinc status turning On then turning Off. What was the specific case where Insteon Direct commands issued from Powerhome were not reflected in the Device Status display.
__________________ Lee G
|
Back to Top |
|
|
grif091 Super User
Joined: March 26 2008 Location: United States
Online Status: Offline Posts: 1357
|
Posted: August 06 2010 at 15:11 | IP Logged
|
|
|
As I mentioned before a single line in the “Responders (to current device)” section represent both the link record in the Current Device and the link record in the Responder device. Scroll to the right and look a the Ctlr Link Status column and the Resp Link Status column. The heading column colors are very useful. Information listed under the Current Device section have dark blue column headings. Columns which are dark blue in both the “Controllers (of current device)” and “Responders (of current device)” sections represent information associated with the “Current Device”. Column heading other than dark blue represent information in the other device (either the controller or responder depending on the section).
Make sure both the Ctlr Link Status and Resp Link Status columns show VERIFIED. It is possible for these columns to have different information.
__________________ Lee G
|
Back to Top |
|
|