Boo!

* ddamron sneaks a peek!

Still get the same error. As a test I tried this:

Code:

   4:#### 192 ####################################################################
   5:def cmd_192(pk_pipe, pk_device_pipes, cmd=nil)
   6:@returnParamArray.clear
   7:log('Turning off device: ' + device_.devdata_[278].to_s)
   8:#switch('192')
   9:
  10:from = "128"
  11:to = "128"
  12:priority = "1"
  13:type = "1"
  14:command = "192"
  15:
  16:mycmd = Command.new(from, to, priority, type, command)
  17:mycmd.devdata_[120] = "1"
  18:
  19:SendCommand(mycmd)
  20:return @returnParamArray
  21:end
)

i.e. the exact code copy/pasted from above

and I get the same error:

Code:

01 06/28/09 19:25:23.801 Error while calling method: Cannot call class method: cmd_192
error: No matching function for overloaded 'new_RubyCommandWrapper', line: 16
backtrace:
in: (eval): 16
from (eval):16:in `initialize'
from (eval):16:in `new'
from (eval):16:in `cmd_192'
 <0xb584bb90>

I created the template by adding a new GSD device template then ticking the Ruby Internal Commands and the Standard Receiver Commands.

Thanks,

Chris

Chris:
The values your passing are strings.  They need to be int's.
  10:from = 128
  11:to = 128
  12:priority = 1
  13:type = 1
  14:command = 192
  15:
  16:mycmd = Command.new(from, to, priority, type, command)
  17:mycmd.devdata_[120] = "1"
  18:
  19:SendCommand(mycmd)
  20:return @returnParamArray
  21:end

Try that, that sould work.  The devdata_[120] is a string.

HTH,

Dan

Sorry, I don't have a GC100, I cannot test it.
I would, however, suggest that you use the Process Incoming Data routine rather than transmitting, waiting, then receiving in the same module.

basically, Ruby isn't threaded, so the faster you can return control, the better.
I'd use a global variable to track the command sent, and then when you receive data from process incoming data, you can compare the response to the command.

HTH,

Dan

Thom,

I'll be there for that one.  Let me know if I can help you in any way.

Regards,

Dan

I remember now,

the device's state is the same as you are setting it to.

try this:

device_.devdata_[120]="1"

devdata 120 is retransmit.  Long story, but because Ruby code is stored in the IR table, DCERouter tries to be 'smart', and if the device is already on, it won't send the command to turn it on again.

This is by design, for devices that have toggles.  ie, a remote control that has a POWER button. (press once to turn on, press again to turn off)

Looks to me that you also have some minor programming issues.

cmd = Command.new(target, target,  priority, type, command)

doesn't work.  Try this instead:
mycmd = Command.new(from, to, priority, type, command)
mycmd.devdata_[120] = "1"

SendCommand(mycmd)



"cmd" is reserved in Ruby.  that's the command received, iirc

Good luck,

Dan

Looks to me like the receiving device's template (power amp) doesn't handle that command.

You get that message when you send a command to a device and the command isn't implemented.

Can you post the GSD code of the amp? (if it's GSD)

Best Regards,

Dan

Glad to see people are using this code!

I'm just getting ready to set up my 810 alpha box. 

At the moment, I don't have access to any Insteon devices, so I can't help too much, other than writing the original code..

I would make one recommendation to anyone wanting Insteon PLM Support:

Watch the LOGS!  There's a lot of messages and information in the logs, and most of the time, the logs will help you determine what the problem is.


HTH,

Dan Damron

Oliver

just as I wrote to you: this is most of Dan's PLCBUS template. (I left some ruby code out but the big 373 routine is there)

by the way when I am trying to take existing one I am getting:

Code:

<?php
error_reporting(E_ALL);
$link = mysql_connect("localhost","root");
mysql_select_db("pluto_main",$link);
$deviceTemplateID = $newPK;
print "New DeviceTemplate: " . $newPK;
?>

this is for template 1779

Eran.

What?!?  Is MY code causing Possy havoc?!?!? LOL
Sorry Possy

Glad to see someone is using that code... the framework is there for some really cool stuff...
and YES, it's a LOT of code.

That, along with the InsteonPLM code, are (as far as I know) the largest Ruby Templates in the system.

Only because I was trying to do way too many things

ahh well, it works, that's what counts

All the best,

Dan

Sounds like your onboard nic is bad..  It should only have ONE MAC address, unless you change it in linux.
I would suggest you try changing the cat5 cable, and see if that helps.  possible bad cable, if not, definately bad nic.

Those mac addresses don't look very healthy at all.. FF FF FF at the end is not good.

One other suggestion would be to check your motherboards firmware for an update.

HTH

Regards,

Dan

Hi,

Another item.

The system I have hooked up to a CRT via S-Video has the following...

EP-8KDA3+ NVIDIA nForce3-250 Socket 754 with audio, SATA, 1GbE LAN
NVIDIA Boot Agent 201.0440
Nvidia 6200 PCI video card.

At this time the system has spawned twice.

Once with MAC address 00:04:61:FF:DF:FF:FF
Second with MAC address 00:04:61:FF:FF:FF:FF

There is a single on board NIC.

This is obviously related to forcedeth drivers.

Just to get this system to even PXE boot without failing has been interesting.

At the moment I'm just trying to work out a routine that provides consistent MAC assignment.

Prior to using this system Windows 2000 told me the address was FF's.

The BIOS reports the address as DF.

Sometimes it boots one way, sometimes the other. 

At one time it wouldn't boot if the AC97 audio out to the TV was connected.

Strange.

Oh well.

I've seen similar.  It seems to be related to nvidia based nics.  The solution is simple though.
Disable one of the nics in the BIOS.  That fixed it for me, on 2 systems.

BTW, you can thank Zaerc for that one, he taught me that at linuxTAG last year

Regards,

Dan

I agree with this too.

BR,

Dan

it looks to me like the above log is correct.
Device 501 sends a SET HOUSE MODE to 13.  all fine. (regardless of the params)
then, below, it seems as if a command is being sent to a child of 501
ie device 701 (routed to 501) has not registered.
501 may well work, but 701 may not.

I'm not able to look up the parameters of cmd19 atm, but I'm guessing param 5 (House Mode) 0 is invalid.

Also, the "removing Socket" line, look at the object ID... 0xb6becb90
that is different from the above "cmd 19" line... 0x0x6e4efb90
hence I believe all is right.



HTH

Dan

Check the log, it may be that the socket connection is still open.. or cannot connect, because the other end (not gsd) isn't designed for multiple connections.. (ie, 1 socket connection at a time, and it must be closed prior to reopening)

Try adding a conn_.close() in the apropriate GSD routine.

I've used IP via GSD for a lot of things, including my first stab at Insteon...

Good Luck, HTH

Dan

OK, Dan.  I'll give it a shot.  I've started revisiting my Insteon code in hopes of getting it cleaned up and improve the functionality.  Did you see that there's a USB PLM now?

Yeah, there's quite a bit of new Insteon hardware.. Motion/Occupancy sensors, low voltage I/O, door/window sensors, etc.

Also, there's another new controller with IP.  I've not looked at the specifics yet..

I haven't found the USB PLM as of yet, but then again, I haven't really looked too hard.

It should be pretty straight forward, any idea if it's a USB/serial device or HID?

Regards,

Dan

Not sure..  I currently don't have the resources to test it, but from what I can see, it should work.

Check the log, it may be that the socket connection is still open.. or cannot connect, because the other end (not gsd) isn't designed for multiple connections.. (ie, 1 socket connection at a time, and it must be closed prior to reopening)

Try adding a conn_.close() in the apropriate GSD routine.

I've used IP via GSD for a lot of things, including my first stab at Insteon...

Good Luck, HTH

Dan