Linux INSTEON scene management software

[bpwwer]

I'm uploading version 0.2.3a now.

This fixes the problem that occured when updating the scene group number. It wasn't updating any of the link entries but is now. It should work as expected such that you can change the group number in a scene and all the devices that are members of that scene will get updated. The one area that won't is the device links list box, that doesn't get rebuilt unless you switch to a different device and then switch back.

Fixed the typo in the error message.

I did determine that you can manually enter a device without selecting a device type. In that case the device type is saved as '0'. I've added a bunch of error checking to the input to make sure it is valid before adding the device.

 

[johnnynine]

I'm getting a little further...

Basically I get lots of "Timeout in usb_cts (0)" and "Timeout trying to get echo back from PLC. Once I get one I have to unplug the powerlinc from the wall and start over.

I sometimes event get a "Timeout trying to get echo back from PLC" when I start up ilink.

I even get this in Device Control. I seem to be able to turn something on, but when I click the Turn Off button I get:

[root@localhost ilink5]# ./ilink
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC

Here's what I get when I do a Discover Existing Scenes:

[root@localhost ilink5]# ./ilink
Querying KeypadLinc
Querying Family Room Dimmer
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout in usb_cts (0)
Timeout in usb_cts (0)
Timeout in usb_cts (0)

Here's what I get when I open the Keypadlinc window.

[root@localhost ilink5]# ./ilink
Timeout trying to get echo back from PLC
last_on_level = 0x2b00
resume_dim_enable = 0x2b88
kpl: read failure
Failed to get keypad linc info
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout trying to get echo back from PLC
Timeout in usb_cts (0)
Timeout in usb_cts (0)
Timeout in usb_cts (0)
Timeout in usb_cts (0)

 

[bpwwer]

Johnny,

You're still using vmware right?

I've been experimenting with my PLC communication functions, trying to make them both more reliable and faster. So might be that I'm too far on the faster side and need to back that off some, at least to have it work in vmware.

I'm a little surprised that you have to unplug the PLC to get it working again. I do see timeouts, usally when I've changed the timeout to a small value, but everything continues to work. What I might do is create some test functions and put them in the command line version. Then if you get a chance, maybe we can figure out what the timing needs to be.

Another thing, you might want to try the command line version just to try some commands that don't do so much remote communciations. Both the descover scenes and keypad config screens try to read a lot data over the powerline so you're much more likely to encounter problems with those.

You can build the command line version by typing 'make link' and it will create an executable called 'link' If you run 'link -h' you'll get a list of the options it supports. One that might be good to test with is the -l (lower case L) option. If you do a ./link -l <device id> it will list the link table on the device. If you pick a device that doesn't have very many links, then this pretty fast. I'd also be curious to know if this is able to work after you start getting the timeout in usb_cts messages.

 

[ginigma]

I had a chance to test last night, until the GF complained I was paying more attention to my toys than her! :unsure:
I haven't seen the timeouts that Johnny is having, but I'm still getting "set_device_link: Failed to send message to xx.xx.xx" errors, but not as much. The comm seems more stable. In general things seem more stable.
I still have problems with the display being proper when cycling between the scenes: Basically I have 5 scenes setup on a ControLinc, one on each button. If I select the scene on button 1, the controller and button are displayed correctly. Switch to the next scene and things display properly. Switch to the next scene and the button (group #) goes back to "1", when it should be "3". It's correct in the file. Switching to the next scene leaves the button at #1.

Programming the devices was real good. Except for a couple set_device_link messages, everything was downloaded to the proper devices and the ControLinc buttons operated the devices as I would have expected.

Keep going Bob, lookin' good.

 

[tye]

Hi Bob:

I had use icmd from ilink to start test my PLC. I had tried to light up LAMPLINC but failed.
message as the following..

# ./icmd -v 04.bb.b5 FAST_ON
Timeout in ikd_cts (0)
PLC ID: 07.f9.eb Firmware version 2d
Sending command 0x12 0x00 to 04.bb.b5
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Too many NAK's, aborting
255

before I try your ilink. I had tried SALad IDE and it failed too. and it complaint about the device map not found.
I found the device map PLC3-2D.ump from insteon website, use SALad IDE to load the map file and then try again an it worked.

I found ilink tested with Firmware Version 2C.
So I try to find different point from PLC3-2C and PLC3-2D map file.
I found there is 3 difference from the compare as the following
PLC3-2C |PLC3-2D
{FILEMATCHVER=2.12} |;{FILEMATCHVER=2.13}
REV=002C ;firmware version |REV=002D ;firmware version
_RS_AppLock=0103 ;1=unlock SALad area to download | empty not definded

Don't know is there anything different on sending signal to USB on 2C or 2D
Please advise.

Tye

 

[bpwwer]

Hi Tye,

I had use icmd from ilink to start test my PLC. I had tried to light up LAMPLINC but failed.
message as the following..

# ./icmd -v 04.bb.b5 FAST_ON
Timeout in ikd_cts (0)
PLC ID: 07.f9.eb Firmware version 2d
Sending command 0x12 0x00 to 04.bb.b5
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Write failed (got NAK), retry
Too many NAK's, aborting
255

As far as I know, my software doesn't really care which firmware version the PLC is. I've had a couple of different versions and it worked with all of them. The "map" files are specifically for the salad IDE and aren't used at all with my software. However, you might want to make sure you have the latest timercore app loaded on the PLC. The SDM should be able to load that. I don't have the exact instructions for that here at work, but they're probably posted somewhere.

It looks like you're using the kernel driver. Because it read the firmware version, reading from the PLC is working. It's just the writing that is failing. This may be a problem with the iplc driver and you're specific kernel version or might be something with the PLC.

I've stopped using the iplc driver in favor of the HIDDEV driver. You might want to try the HIDDEV driver. Assuming you have HID support in your kernel. To switch, you'll have to change the source slightly and recompile. To change icmd.c look for a line that looks like this:

if ((iplc = ilib_open(USE_IPLC, "/dev/usb/iplc0")) != NULL) {

and change it to look like this:

if ((iplc = ilib_open(USE_HIDDEV, "/dev/hiddev0")) != NULL) {

You'll have to unplug the PLC, rmmod the iplc driver, then plug the PLC back in. The HID driver should take control of the PLC. To run the programs with a user account (not root), the /dev/hiddev0 device will need to have both read and write access set for that user.

 

[linuxha]

Also be careful to use the driver that Bob is suppling as my driver uses a different path for the device name.

Bob you might want to change the buffer size to 4K. I found that the driver does over run the buffer from time to time.

Thanks

 

[tye]

Hi Bob:

Thanks for your kindly reply.

you might want to make sure you have the latest timercore app loaded on the PLC. The SDM should be able to load that. I don't have the exact instructions for that here at work, but they're probably posted somewhere.

Can you tell me more detail? what is SDM ? what exactly the timercoreapp affects the transmission between PC to PLC?
I used SmartLabs Device Manager (may be the SDM you mentioned) and typed the following "dl=insteon.net:timercoreapp12" to download the timercoreapp12. and It get back to me the successful message. So I think there is newest timercoreapp in my PLC. But I still not getting to goal from ilink. Please advise.

It looks like you're using the kernel driver. Because it read the firmware version, reading from the PLC is working. It's just the writing that is failing. This may be a problem with the iplc driver and you're specific kernel version or might be something with the PLC.

I've stopped using the iplc driver in favor of the HIDDEV driver. You might want to try the HIDDEV driver. Assuming you have HID support in your kernel. To switch, you'll have to change the source slightly and recompile. To change icmd.c look for a line that looks like this:

if ((iplc = ilib_open(USE_IPLC, "/dev/usb/iplc0")) != NULL) {

and change it to look like this:

if ((iplc = ilib_open(USE_HIDDEV, "/dev/hiddev0")) != NULL) {

You'll have to unplug the PLC, rmmod the iplc driver, then plug the PLC back in. The HID driver should take control of the PLC. To run the programs with a user account (not root), the /dev/hiddev0 device will need to have both read and write access set for that user.

I had tried to use HIDDEV to drive the PLC. but I seems a little bit worse than that I using IPLC. following is the message from icmd.

# ./icmd -v 04.bb.b5 FAST_OFF
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Command failed
Sending command 0x14 0x00 to 04.bb.b5
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
Timeout in ihid_cts (0)
Timeout waiting for PLC to echo data.
255

I think that could be something err in my kernel USB HID.
I am using CentOS 4.5 with kernel 2.6.9-55.EL come with CentOS 4.5.
Could you please tell me your kernel version and what OS you are using. Thank you.

By the way. the following raw message is dump from SALad IDE that successful send the message to PLC and make the LAMPLINC light up.
Could you please help to find some clue about what different between SALad IDE and ilink. Thanks in advance.

T:02 40 01 A1 00 09 FB E4 07 F9 EB 04 BB B5 00 12 00
S:02 02 40 00 00 00 00 00
S:03 01 A1 00 00 00 00 00
R:
R:02 40
S:03 09 FB E4 00 00 00 00
S:03 07 F9 EB 00 00 00 00
R:
R:01
R:A1 00
R:
S:03 04 BB B5 00 00 00 00
S:03 00 12 00 00 00 00 00
R:09
R:
R:
R:
R:06
T:02 46 01 42 10 9F
S:03 01 42 10 00 00 00 00
R:
R:02
R:46
S:01 9F 00 00 00 00 00 00
R:
R:01 42
R:10
R:
R:9F 06
R:02
R:45 04
R:02
R:4F 04 04
R:BB B5 07 F9
R:EB 20 12 00

With My Best Regards

Tye

 

[bpwwer]

Hi Bob:

Thanks for your kindly reply.

you might want to make sure you have the latest timercore app loaded on the PLC. The SDM should be able to load that. I don't have the exact instructions for that here at work, but they're probably posted somewhere.

Can you tell me more detail? what is SDM ? what exactly the timercoreapp affects the transmission between PC to PLC?
I used SmartLabs Device Manager (may be the SDM you mentioned) and typed the following "dl=insteon.net:timercoreapp12" to download the timercoreapp12. and It get back to me the successful message. So I think there is newest timercoreapp in my PLC. But I still not getting to goal from ilink. Please advise.

Yes, the SDM is the Smarthome Device Manager. timercore12 is the latest so you do have that loaded.

I had tried to use HIDDEV to drive the PLC. but I seems a little bit worse than that I using IPLC. following is the message from icmd.

# ./icmd -v 04.bb.b5 FAST_OFF
Timeout in ihid_cts (0)

That does seem like a problem with the driver. You can verify that the HID driver has control of the PLC by looking at /var/log/messages. You should see something like this when you plug the PLC into the usb port:

Dec  7 06:45:50 kernel: usb 5-2: new low speed USB device using uhci_hcd and address 9
Dec  7 06:45:50 kernel: usb 5-2: configuration #1 chosen from 1 choice
Dec  7 06:45:50 kernel: hiddev96: USB HID v1.00 Device [SmartHome SmartHome PowerLinc USB E] on usb-0000:00:1d.2-2

If you don't, then you probably don't have the HID driver loaded in your kernel.

I am using CentOS 4.5 with kernel 2.6.9-55.EL come with CentOS 4.5.
Could you please tell me your kernel version and what OS you are using. Thank you.

I have only used various Fedora kernels. But probably only the kernels available for FC6 with the HID driver. I'm currently using kernel 2.6.22.9-61.fc6. This is the kernel straight from Fedora, I don't re-compile it.

By the way. the following raw message is dump from SALad IDE that successful send the message to PLC and make the LAMPLINC light up.
Could you please help to find some clue about what different between SALad IDE and ilink. Thanks in advance.

I don't know anything about the SALAD IDE and how it is communicating with the PLC. I'd guess it uses the SDM but that's just a guess.

You could also try Neil's latest iplc driver. The version I include with ilink is pretty old, I was just modifying it to compile for newer kernels.

 

[tye]

Dear Bob:
Thank you for all the help.

I have only used various Fedora kernels. But probably only the kernels available for FC6 with the HID driver. I'm currently using kernel 2.6.22.9-61.fc6. This is the kernel straight from Fedora, I don't re-compile it.

Finally. I get pass the very frustrated time. and use the HID driver come from kernel.
I downloaded and compiled the kernel 2.5.22.9 from www.kernel.org. And try again with the new kernel. My PLC finally aware that I am its boss. hahaha... oh my god...

Thanks again Bob and could you please give the advise or kernel version which in your ilink readme. That will be more help for someone like me.

Regards
Tye