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_MessagesHere are examples of all the commands I could receive if I add dimmable and non-dimmable lights:
#############################################################
# $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
#### 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
