Lighting commands incorrectly routed from floorplan

[chrisbirkinshaw]

I have a added a generic device to act as a parent to my lights and allow an external program to connect and read these commands by a TCP socket.

When choosing "Lights" from the admin website and pressing on or off the commands are correctly routed to the parent device:

Code: [Select]

08      12/14/07 14:00:11.386           Received Message from 0 (unknown / ) to 179 (Misterhouse Remote / Entrance), type 1 id 760 Command:Send Command To Child, retry none, parameters: <0x5e65fb90>
08      12/14/07 14:00:11.386             Parameter 10(ID): B3 <0x5e65fb90>
08      12/14/07 14:00:11.386             Parameter 154(PK_Command): 193 <0x5e65fb90>


However when called from the floorplan this does not happen:

Code: [Select]

08      12/14/07 14:02:16.292           Received Message from 69 (Generic Proxy Orbiter / ) to Red Cabinet Lamp (dimmable)(189), type 1 id  193 Command:Off, retry none, parameters: <0x63e6ab90>
08      12/14/07 14:02:16.292             Parameter 97(PK_Pipe):  <0x63e6ab90>


Does anyone know why?

Thanks in advance,

Chris

[ddamron]

Sorry Chris, not familiar with misterhouse...

[chrisbirkinshaw]

I don't see how this can be related to MH. I created a generic device and some children and am not seeing messages routed to the parent. At the moment I am testing with just 2 telnet sessions to the core to register for plain_text messages as detailed here:

http://wiki.linuxmce.org/index.php/Plain_Text_DCE_Messages


Chris

[chrisbirkinshaw]

After some more digging I see totally different commands coming through from the core to a telnet session.

When using the floorplan I get the following when turning device 206 on and off:

MESSAGET 25
69 206 1 192 97 "" 98 ""
MESSAGET 19
69 206 1 193 97 ""


But from the web admin interface I see the following:

MESSAGET 30
0 204 1 760 10 "C2" 154 "192"
MESSAGET 30
0 204 1 760 10 "C2" 154 "193"


I also notice that the X10 channel number "C2" is missing when not routed by the parent device.

[ddamron]

hmm... did you make sure the Implements DCE box was UNCHECKED in your lighting devices?
if that box is checked, DCE sends the command directly to the device, not to it's parent.
97 and 98 are the PARAMETERS for command 192 ON

looks like what you are getting is correct... from 69, to 206, type is 1, Command, CmdID of 192 with 2 parameters 97 (string) "" and 98(string) ""

I don't know what your device 69 is..

HTH,

Dan

[chrisbirkinshaw]

After some more digging I see totally different commands coming through from the core to a telnet session.

When using the floorplan I get the following when turning device 206 on and off:

MESSAGET 25
69 206 1 192 97 "" 98 ""
MESSAGET 19
69 206 1 193 97 ""


But from the web admin interface I see the following:

MESSAGET 30
0 204 1 760 10 "C2" 154 "192"
MESSAGET 30
0 204 1 760 10 "C2" 154 "193"


I also notice that the X10 channel number "C2" is missing when not routed by the parent device.

Did a bit more digging in order to get my Misterhouse parent device to work. The parent device is a template I made by copying the Logic Handlers/Generic #1 template and adding Specialized Interfaces as a controlled by type to allow me to set it as the parent for lights and motion sensors. Misterhouse connects and registers for plain text messages as per this wiki page:

http://wiki.linuxmce.org/index.php/Plain_Text_DCE_Messages

Here are examples of all the commands I could receive if I add dimmable and non-dimmable lights:

Code: [Select]

                #############################################################
                # $1    $2      $3      $4      $5      $6      $7      $8
                # from  to      msgtype msgid   p1id    p1val   p2id    p2val
                # Example command from orbiter
                # 69    206     1       192     97      ""      98      ""
                # 69    206     1       193     97      ""
                # 69    205     1       184     76      "100"
                # 69    218     1       193
                # Example command from admin site
                # 0     204     1       760     10      "C2"    154     "192"
                # 0     204     1       760     10      "C2"    154     "193"
                #############################################################

So it looks like the admin site sends commands from id 0 but the orbiter sends them from the parent device (69). But the really confusing thing is that the command structure is completely different. I therefore had to program my external program to recognise different command forms for admin site originated and orbiter originated commands. Did you have to do the same thing?

Also, how can I update the status of a device from an external script/program connected using the plain text DCE method - eg. tell LMCE a light is on - without causing an infinite loop (as the light is controlled by the external script from LMCE)?

Thanks,

Chris

[bulek]

Hi,

I'm using lights in both ways and AFAIK I didn't encounter this problem....

Are you sure that you're using same device on Floorplan and web-admin ?

Did you register as normal device or did you register as message interceptor ?

Command with id of 760 is send command to child....

Command *     
Command Category *    
Device Templates who use command *    #1754 ZWave, #1857 ControlBoard, #1913 Automation Interface
Parameters
#10   ID (string)   The internal ID used for this device--not the Pluto device ID.   Is out
  Yes   No    Delete Edit
#202   Parameters (string)   Parameters for the command in the format: PK_CommandParameter|Value|...   Is out
  Yes   No    Delete Edit
#154   PK_Command (int)   The command to send   Is out
  Yes   No    Delete Edit
Add new parameter
Create new parameter

HTH,

regards,

Bulek.

[bulek]

Hi,

I was debuggint this cause of other problem, but checked my lights on floorplan in between and in my case, it seems that messages are correctly send...

I get this on my device driver when I set Light in Lighting floorplan :

LMCE_DCE_REC : 41 133 1 192 97 "" 98 ""

41 is ID of Orbiter, 133 is ID of light device...

I haven't encountered that command 760 yet, although I do pretty similar setup (only that I have device driver in a standalone Perl fashion)... If you give more info on your setup (parent,childern), maybe we can sort things out...


HTH,

regards,

Bulek.

[chrisbirkinshaw]

I just tried again (LMCE 0710 B4) and found the following (for a simple on/off light switch with id 80). Note that id 78 is the parent device in this case (generic device registered for plain_text dce messages, not set to intercept anything, just get what it's directly sent).

On from Orbiter:

88 80 1 192 97 "" 98 ""

On from Web Admin GUI:

0 78 1 760 10 "B1" 154 "192"


So this 760 command from the web admin sends the X10 device address (B1) rather than the id (80). The orbiter sends the device id and not the X10 address, which seems more sensible.

Weird, huh?

[ddamron]

After some more digging I see totally different commands coming through from the core to a telnet session.

When using the floorplan I get the following when turning device 206 on and off:

MESSAGET 25
69 206 1 192 97 "" 98 ""
MESSAGET 19
69 206 1 193 97 ""


But from the web admin interface I see the following:

MESSAGET 30
0 204 1 760 10 "C2" 154 "192"
MESSAGET 30
0 204 1 760 10 "C2" 154 "193"


I also notice that the X10 channel number "C2" is missing when not routed by the parent device.

Did a bit more digging in order to get my Misterhouse parent device to work. The parent device is a template I made by copying the Logic Handlers/Generic #1 template and adding Specialized Interfaces as a controlled by type to allow me to set it as the parent for lights and motion sensors. Misterhouse connects and registers for plain text messages as per this wiki page:

http://wiki.linuxmce.org/index.php/Plain_Text_DCE_Messages

Here are examples of all the commands I could receive if I add dimmable and non-dimmable lights:

Code: [Select]

                #############################################################
                # $1    $2      $3      $4      $5      $6      $7      $8
                # from  to      msgtype msgid   p1id    p1val   p2id    p2val
                # Example command from orbiter
                # 69    206     1       192     97      ""      98      ""
                # 69    206     1       193     97      ""
                # 69    205     1       184     76      "100"
                # 69    218     1       193
                # Example command from admin site
                # 0     204     1       760     10      "C2"    154     "192"
                # 0     204     1       760     10      "C2"    154     "193"
                #############################################################

So it looks like the admin site sends commands from id 0 but the orbiter sends them from the parent device (69). But the really confusing thing is that the command structure is completely different. I therefore had to program my external program to recognise different command forms for admin site originated and orbiter originated commands. Did you have to do the same thing?

Also, how can I update the status of a device from an external script/program connected using the plain text DCE method - eg. tell LMCE a light is on - without causing an infinite loop (as the light is controlled by the external script from LMCE)?

Thanks,

Chris

Chris,

There is a reason why the webadmin sends cmd760 and not the standard cmd192/193/184 commands...

When a home automation device detects a new child (light switch) and reports it via Report Child Devices cmd.. the child is created immediately.  HOWEVER, the router needs a reload in order to activate that child.

Cmd 760 is designed so you can send messages to a child who hasn't actually loaded yet. (perfect example, Lighting wizard setup)

Also note the 50% button on webadmin, I've found some interesting stuff with that.
Here's my code from my Insteon Driver, it demonstrates how to properly use cmd760

Code: [Select]

#### Written by Dan Damron
#### #760 Send Command to Child ####


@insteonID = id.chomp.split('.')
@parameters = parameters
@command = pk_command
@cmd = cmd

log('#760:id=' + id.inspect)
log('#760:parameters=' + parameters.inspect)
log('#760:pk_command=' + pk_command.inspect)
log('#760:cmd=' + cmd.inspect)
### ok, I get the insteonID in @insteonID
# pk_command has one of THREE values, 192, 193, or NOTHING
# when I click 50%, I get in parameters: 76
# but NOTHING in pk_command.

case pk_command
when '192' #ON
  param = {'Command' => 'SndIns',
    'Parameter1' => @insteonID[0],
    'Parameter2' => @insteonID[1],
    'Parameter3' => @insteonID[2],
    'Parameter4' => 'OF', # Flags
    'Parameter5' => '11', # Insteon SetLevel
    'Parameter6' => 'FF'} # FULL ON
  $cmdqueue << param
  SndIns()

when '193' #OFF
  param = {'Command' => 'SndIns',
    'Parameter1' => @insteonID[0],
    'Parameter2' => @insteonID[1],
    'Parameter3' => @insteonID[2],
    'Parameter4' => '0F',
    'Parameter5' => '13', #OFF
    'Parameter6' => '00'}
  $cmdqueue << param
  SndIns()


when ''
  if parameters=='76'
    #SetLevel 50%
    param = {'Command' => 'SndIns',
      'Parameter1' => @insteonID[0],
      'Parameter2' => @insteonID[1],
      'Parameter3' => @insteonID[2],
      'Parameter4' => 'OF', # Flags
      'Parameter5' => '11', # Insteon SetLevel
      'Parameter6' => '76'} # 50%
    $cmdqueue << param
    SndIns()
  end
end

HTH,

Dan