iLink Scene Manager

[ginigma]

Decided to start a new thread....
Is anyone having any success using this software with a KeypadLinc? I pretty much can't do anything due to communication errors such as "kpl: read failure" and "Failed to get keypad linc info". When I try programming a scene (a simple one just controlling a LampLinc), the KPL button LEDs blink, so I know some communication is going on.

I've been able to setup scenes on a ControLinc without any problems. I haven't used any other devices as controllers.

Any thoughts???

 

[bpwwer]

Ok, new version - 0.2.4a on my site now.

I've been working on the communications some more and added some code to do a couple re-tries if it doesn't successfully read/write a byte on the remote device. I also added a progress bar to the keypadlinc config screen. I've been able to read & write to one of my KPL's without seeing any errors so I think it is working better.

 

[ginigma]

Ok, new version - 0.2.4a on my site now.

Great, I should have some time tonight to check it out.

I also added a progress bar to the keypadlinc config screen.

Another "Great!" Progress bars provide great visual feedback when it appears nothing is happening.

Another question/issue: With the link CLI in Monitoring mode, I don't see any traffic. I would expect to see messages when I put a device into programming mode. I would also expect to see messages when I press a button on a controller, but I don't. Think it's something that may be fixed in the new version? Other link commands return information (status, etc.).

 

[bpwwer]

I'm glad you like the progress bar. Now I need to add them to all the functions that take a while. I'm not real happy with the code design to make this work. It will probably be better when I get around to making the code multi-threaded.

Another question/issue: With the link CLI in Monitoring mode, I don't see any traffic. I would expect to see messages when I put a device into programming mode. I would also expect to see messages when I press a button on a controller, but I don't. Think it's something that may be fixed in the new version? Other link commands return information (status, etc.).

I just took a look at the code and I don't see anything that looks broken. Nothing I've done recently (well, since I first released it) changes the behavior of the monitor function so

The PLC does filter messages so that you'll only get messages from devices that are in the PLC's link table. The only exception is when the PLC is in linking mode, then it can see the "I want to join" messages from unknown devices (This is how auto discovery works). There is a menu item to update the PLC links in the GUI that will add all the known devices into the PLC's link table. Once this is done, the monitor mode should see all the commands sent.

I'll have to think about how to add a monitor mode into the GUI.

 

[ginigma]

The PLC does filter messages so that you'll only get messages from devices that are in the PLC's link table.

I'll bet that's it then. My devices probably aren't in the PLC's link table. I'll have to check on that. Thanks for pointing me in the right direction.

 

[bpwwer]

I just uploaded another new version. This one has a progress bar that pops up when programming devices. Also added a menu item to initialize the PLC link table with all devices that the program knows about. I just realized that while the code was in there to do that, there wasn't any way to access it.

 

[ginigma]

Notes from testing v0.2.6a
Did you work on the communications? It seems more stable to me. Actually a lot more stable. The KPL Configuration was read with a few errors, but it loaded. The ControLinc Configuration (nice feature! Except for the X-10 stuff, see below) read fine. All I changed was to check the “Light Dimmed†checkbox and I got the following errors (9 times) in the console window:

(ilink:13813): Gtk-CRITICAL **: file gtkprogress.c: line 584 (gtk_progress_set_percentage): assertion `percentage >= 0 && percentage <= 1.0' failed

and then the following dialog box popped up: Warning: Unplug and re-plug ControLinc for changes to take effect! which I believe is fine.
Programming scenes was also better. No write errors and only a couple of “Bogus messagesâ€.
If you didn’t make any communication changes, my better results may be due to using the ilink_scene.inf file as my scene file, instead of a different name before.

On a personal note, unless you have X-10 devices that you want to control, I would keep this an “Insteon only†app. I wouldn’t add any X-10 control features. But that’s just me.

A few questions:
Please define the columns in the link (CLI) examples below and what is returned from a query (ping) command?

./link -m
PLC ID: 00.d7.ab   Firmware version 2c
2006-03-25 23:27:55:  ** 00.00.01 -> 06.04.d2  0xcf OFF 0 group broadcast
2006-03-25 23:27:55:  rr 00.00.01 -> 06.04.d2  0xc7 OFF 0 group broadcast
2006-03-25 23:27:55:  ** 03.04.18 -> 06.04.d2  0x45 OFF 1 group
2006-03-25 23:27:55:  rr 06.04.d2 -> 03.04.18  0xe1 OFF 255 ack group broadcast
2006-03-25 23:27:56:  ** 03.04.19 -> 06.04.d2  0x45 OFF 1 group
2006-03-25 23:27:56:  rr 06.04.d2 -> 03.04.19  0xe5 OFF 255 ack group broadcast

./link -f 00.d7.ab
PLC ID: 00.d7.ab   Firmware version 2c
00.d7.ab: SLV group(1)  0x00 0x00 0x00

./link -q 03.04.19
PLC ID: 00.d7.ab   Firmware version 2c
FAMILY-Ceiling Lights     (03.04.19) returned 0xffffffff

 

[bpwwer]

Did you work on the communications? It seems more stable to me. Actually a lot more stable.

I did add a re-try to the send message function so that if it fails, it will re-try up to 2 more times. That's probably what made the difference.

The KPL Configuration was read with a few errors, but it loaded.

Is it getting the "Bogus message" or "Extended message" errors or something else? The first two seem to be caused by corrupted data coming from the PLC, If it is something else, It might just need more re-tries.

The ControLinc Configuration (nice feature! Except for the X-10 stuff, see below) read fine. All I changed was to check the “Light Dimmed†checkbox and I got the foIllowing errors (9 times) in the console window

I don't know how I missed that. I must of changed something and forgot to re-test it. It's an easy fix and a harmless error.

and then the following dialog box popped up: Warning: Unplug and re-plug ControLinc for changes to take effect! which I believe is fine.

Yeah, you have to pull the power on the controlinc for the changes to take effect. There's a INSTEON command that tells the device to re-read it's configuration but only the KeypadLincs implemented (go figure).

On a personal note, unless you have X-10 devices that you want to control, I would keep this an “Insteon only†app. I wouldn’t add any X-10 control features. But that’s just me.

I do have a couple of X10 devices still but I don't really need to control them. I put that in because the dialog box seemed a little empty with only the beep and light controls

See below in red for descriptions of the fields.

./link -m
PLC ID: 00.d7.ab   Firmware version 2c
2006-03-25 23:27:55:  ** 00.00.01 -> 06.04.d2  0xcf OFF 0 group broadcast
2006-03-25 23:27:55:  rr 00.00.01 -> 06.04.d2  0xc7 OFF 0 group broadcast
2006-03-25 23:27:55:  ** 03.04.18 -> 06.04.d2  0x45 OFF 1 group
2006-03-25 23:27:55:  rr 06.04.d2 -> 03.04.18  0xe1 OFF 255 ack group broadcast
2006-03-25 23:27:56:  ** 03.04.19 -> 06.04.d2  0x45 OFF 1 group
2006-03-25 23:27:56:  rr 06.04.d2 -> 03.04.19  0xe5 OFF 255 ack group broadcast

Timestamp
** = first time message
rr = repeated message
?? = unknown by me
From device
To device
Message flag byte
command byte
command data byte
parsed message type flags

./link -f 00.d7.ab
PLC ID: 00.d7.ab   Firmware version 2c
00.d7.ab: SLV group(1)  0x00 0x00 0x00

This option will list the PLC's link database. When given a device id, it will search for entries with that device id, you might want to try it with the 'all' argument. The return values are:
device id
SLV = responder record
MST = controller record
group(n) = group number (0-255)
3 link data bytes.

./link -q 03.04.19
PLC ID: 00.d7.ab   Firmware version 2c
FAMILY-Ceiling Lights     (03.04.19) returned 0xffffffff

device name
(device id)
device type
device firmware revision

However, the 'return 0xffffffff' indicates that it didn't work. I haven't updated the ping command to use the new and improved message code so that's probably why. I"ll look into it and see if I can make it work again.

This version also allows the PLC to be a group controller and a group responder. But I havent' tested that functionallity yet.

 

[ginigma]

Bob,
Any software updates? I think I'm going to be adding more switches this weekend.

 

[bpwwer]

I've made some changes to the device control dialog so that it now does manual dim start/stop commands. I added the local ramp rate and on-level to both the dialog and to the scene file but the program device function doesn't yet try to program those values.

I added a new dialog for scene verification that queries all the devices and compares the link tables with what is in the scene file. Currently it only displays the errors, it doesn't try to fix them (code is there but commented out).

I also upgraded my development system to Fedora Core 5, but I don't think I've used anything yet that would prevent it from still working with FC3 & FC4.

New version with those additions on my web site now.

I've been mostly consumed with some home improvement projects so not much time to work on this.