• You've been granted Beta access to this site, allowing you to explore some of the new features while they're still under construction. More information can be found in the Beta forum.

Linux INSTEON scene management software

johnnynine

Active Member
electron said:
This is really starting to look good Bob, nice job, keep up the great work!
Yes I have had so much trouble getting PowerHome to work right that I hope to use this instead. I'm looking forward to full Keypadlinc support. ;)
 

johnnynine

Active Member
dhoward said:
If you don't mind, what are the problems that you're having with PowerHome?
I only have 5 devices including a keypadlink and a controllinc.

I WAS able to succesfully use the device discovery, but that's about it.

I could not get it to retrieve my existing scene information.

I could not get it to get past (I forget the status, but it wasn't not found or verified) on the Groups by Controller window even after waiting 20 minutes and hitting F5.

It did not set the scene information in the devices that I entered.

I could not tell when it was actually communicating with my devices.

It only sometimes could set the on/dim level of my devices.

It never showed the current on/dim levels of my devices (I think it always said 0).

When I clicked the ADim,On,Off buttons they would remain depressed until I closed and reopend the device status window.

After installing the latest version it sometimes would not find the powerlinc and when I followed the directions for setting the port, SDM would lock up after typing port=? and then PowerHome appeared to start multiple instances of SDM every 5 to 10 seconds.

Perhaps some of this is from not completely understanding PowerHome, but I thought I followed the directions fairly well.

I have tried several other programs including this linux program and had success with at least setting and reading the on/dim levels. Device discovery also worked for me in this linux app.

I hope that helps,
Johnny
 

dhoward

Member
Johnny,

Definately...all feedback helps ;).

If you are still testing PowerHome, would it be possible for you to send me the SDM log? It may help me track down problems that I might be able to fix for other users as well.

Based upon what you wrote, it almost appears to be communication problems but I don't want to jump to conclusions without first looking at the log. The way the Device Status screen works, when you depress a button, the corresponding command is sent out the SDM. The button stays depressed until a confirmation is received. If a confirmation is not coming back, the button will stay depressed.

With only 5 devices, I would expect the total link discovery process to take less than 5 minutes. The value that was probably showing in the Group by Controller screen would have been "CHECKING". This would also lead me to believe there is a communication error.

This error though, may not be on your Insteon network but may be a communication error between PowerHome and the SDM. The log would help me troubleshoot this.

Appreciate the feedback,

Dave.
 

bpwwer

Member
I just uploaded a new version to my web site (0.2.1a). The copy scene screen is now fully functional. I also changed the the scene editor on the main screen to allow new devices to be added or existing devices to be edited. "Save" now remembers the last file opened so you don't have to remember what it was. It still pops up the dialog and allows you to change it (I guess that should only happen if a file was never opened). A couple of bug fixes too.

johnnynine said:
Delete Scene gives me a Segmentation fault.
Save gave me a segmentation fault and I my old saved file was replaces with a new one with comments in it only.
The Delete Scene seg fault is fixed. I didn't find any problem in the save function but added some addition error checking just in case.

I'm thinking about a new feature to allow all devices in a scene to be re-programmed this would suppliment the the program device and prgram all options.
 

ginigma

Active Member
Comments on 0.2.1a:
I'm not sure if scene editing is working properly or I just don't know how to use it yet. If I select an existing scene that I setup previously (with iLink), I would expect the Scene Controller to indicate which controller it's set for and the Scene Group to indicate the button (should default to button 1) and then list all of the responders for that scene and their settings. It doesn't do that. When I select a scene, it leaves all the previous information displayed. It's like it doesn't refresh. As I cycle through the Scene Group #'s, I would expect to see the Responder list changing to reflect the devices that are part of each scene (button).

I haven't had a chance to fool around with the KPL. I want to read the SmartHome docs so I gt a good understanding of the device, but I don't have any load connected to it; I'm just using it as a controller for other scenes.

More to come....
 

bpwwer

Member
ginigma said:
Comments on 0.2.1a:
I'm not sure if scene editing is working properly or I just don't know how to use it yet. If I select an existing scene that I setup previously (with iLink), I would expect the Scene Controller to indicate which controller it's set for and the Scene Group to indicate the button (should default to button 1) and then list all of the responders for that scene and their settings. It doesn't do that. When I select a scene, it leaves all the previous information displayed. It's like it doesn't refresh.
Your assumption about how it should be working is how it should be working. A scene name should reference a controller, a group, and a list of repsonders. Selecting a new scene should update all of that.

I'm going to describe how the program should be working. The scene data is currently read from a saved file (by default ilink_scene.inf). What is actually programmed into the devices may be different. Also, if you saved the information in a different file, it won't automaticlly re-load that data next time you run the program, but might load up old/wrong data. It probably shouldn't be auto-loading data from ilink_scene.inf since that may not have your most recent data, and thus confusing. Can you make sure the file you have opened has what you expect for the scene definition?

The idea is that you create/edit all the scenes, and then program the devices to match. I've added a "program scene" button to program all the devices included (controller/responders) in a scene. I'm also working on a feature to compare the current in-memory scenes with the actual device link tables to find errors/descrepencies.

ginigma said:
As I cycle through the Scene Group #'s, I would expect to see the Responder list changing to reflect the devices that are part of each scene (button).

Interesting idea, but not the way it works :lol: A scene is directly linked with a "button", not a device (although for single button devices, it is one and the same). The scene group is an attribute of the scene, so when you edit a scene, you can change the group, the controller, the resonders associated with that scene. So as you cycle through scenes, all those values should change. I plan to add the ability to set the PLC as a scene controller, it will support up to 254 groups.

So when editing a scene you are not editing all aspects of a device. With multi-button devices, you create a unique scene for each button. Sounds like you are looking for a way to view all the scenes assigned to a device. I hadn't thought of that, maybe that is something that would work under the device control option, not only control the device, but list the scenes configured too.

ginigma said:
I haven't had a chance to fool around with the KPL. I want to read the SmartHome docs so I gt a good understanding of the device, but I don't have any load connected to it; I'm just using it as a controller for other scenes.

More to come....
The KPL config screen is pretty rough. It should be reading/writing the KPL configuration but I'm not exactly sure what actual effect changing the various values will have on its operation. I too, need to spend some time just trying things. It's kind of slow transferring data and the KPL config has a lot of data to transfer (well it seems like a lot at 1.5 seconds per byte).

Last night I worked on fixing some problems with the low level PLC communications and I think this will help with the reliability with data transfers to/from remote devices.

Thanks for the feedback! It's definitly helping.
 

ginigma

Active Member
Ok, just clarify something for me: In the Scene Editor area, the Scene Group # is the Controller button number, e.g.
  • ControLinc has 1-5
  • KeypadLinc has 1-8
  • SwitchLinc has 1
The devices in the Responder list are the devices that are linked to that Scene Controller/Scene Group # selected?
The Button Group control for the Responder is only applicable for KPLs?

Buglist
Create New Scene, click on a device in the responder list, click Delete from Scene, click in an empty area in the now blank Responder list. This causes a Seg fault.
You can create scenes with the same name (just click the New Scene button a few times.
I seem to be getting a lot of “set_device_link: Failed to send message to xx.xx.xx
I saw the error message: “Bogus message (Extended NAK of group cleanup direct message?†when programming a device (KPL). What does that mean?
Saving as a new file didn’t update the filename in the title bar. Opening that same file updated the title bar properly.
I tried creating a scene with a KPL but was getting kpl: read failures and write failures. This could be something I was doing wrong. I’ll give you time to work on the KPL stuff.


Wishlist
Main window is too wide. Think about using a “tabbed†interface: Put the Scene Editor on one tab, Add New Device on another tab and Device Programming on yet another tab.
Sort devices in Responder and Device Programming drop-down controls
Make the list boxes sortable by clicking on the column header


As always, keep up the good work!
 

bpwwer

Member
ginigma said:
Ok, just clarify something for me: In the Scene Editor area, the Scene Group # is the Controller button number, e.g.
  • ControLinc has 1-5
  • KeypadLinc has 1-8
  • SwitchLinc has 1
The devices in the Responder list are the devices that are linked to that Scene Controller/Scene Group # selected?
The Button Group control for the Responder is only applicable for KPLs?

Yes. That's correcct.

ginigma said:
Create New Scene, click on a device in the responder list, click Delete from Scene, click in an empty area in the now blank Responder list. This causes a Seg fault.
Found and fixed.

ginigma said:
You can create scenes with the same name (just click the New Scene button a few times.
Rename scenes allows this too. So I fixed it in both places.

ginigma said:
I seem to be getting a lot of “set_device_link: Failed to send message to xx.xx.xx
I saw the error message: “Bogus message (Extended NAK of group cleanup direct message?†when programming a device (KPL). What does that mean?
Yesterday, I found a bug in my low level PLC communications functions. I've been working on that and think I have it solved. I think it will clear up all these problems. I haven't done much testing yet but so far it seems pretty solid.

ginigma said:
Saving as a new file didn’t update the filename in the title bar. Opening that same file updated the title bar properly.
Found and fixed.

ginigma said:
I tried creating a scene with a KPL but was getting kpl: read failures and write failures. This could be something I was doing wrong. I’ll give you time to work on the KPL stuff.
Same as above, There's a fair amount of data to read/write on the KPL. The messages are indicators that the messages were corrupt or missing.

I'll add your wish list items to the TODO list. They all seem like pretty reasonable suggestions, although do you have any idea how many tries it took to come up with that main window :)

I'm uploading a new version now....
 

ginigma

Active Member
Ok, so based on what you said, as I scrol through my list of scenes, I should expect the Scene Controller and Scene Group # to change, based on their settings. I'm having a problem then. When I switch scenes, there are two on the ControLinc, two different buttons. The Scene Group # doesn't reflect the two different bubttons (never changed from "1". And then when I select the ControLinc in the Device Programming area, all my devices are in Group 1, when some should be in 1 and some should be in 2.
[edit] I went into the scene file and changed the second group to "2" and reopened it in ilink, opened the ControlLinc in Device Programming and it loooked correct.

bpwwer said:
I'll add your wish list items to the TODO list.  They all seem like pretty reasonable suggestions, although do you have any idea how many tries it took to come up with that main window  :)
I understand your pain! In my real job, I manage people who write software. I am constantly pushing them to push the envelop. However, they dred giving me their apps to test as I can usually break them within 2 minutes.
 

ginigma

Active Member
Testing v0.2.2a
Still getting a lot of kpl write/read errors. I'm just trying to set Toggle Mode for a button using the KeypadLink Configuration screen.
The Scene Controller and Group # are now in sync when selecting different scenes.
However, there's still a problem somewhere, as highlighted in the attached file. In the scene editor, I am trying to control a switchlinc with button 5. However, in the Device Programming window, it shows as group (button) 3, which is wrong. If I go into the scene inf file and manually change it, it will display the group properly in the Device Programming screen, but the Level and Ramp information is all screwed up. Looks like the Level = Group # and Ramp is all set to 0 and Extra = Group # also. They are correct in the inf file. The Level and Ramp Rate info is correct in the Scene Editor Responder list. However, when I clicked the Program Scene button, it wrote the wrong info to the devices; it wrote what was in the Device Programming list (wrong levels and ramp rates). This seems to be a major bug.

In addition, I noticed the following problems in the inf file:
PowerLinc V2 Controller has device_type=1; shouldn’t it be 0?
Some of the SwitchLinc V2 Dimmers have device_type=0; they should be 257. Some are correct.

Did you include the new version of the iplc code in v0.2.2a? The source still has a Jan 28 date. That could be the cause of my communications problems.

You have a typo in one of your error messages: search for “tring†I think you mean “tryingâ€
 

Attachments

  • Screenshot_ilink5.jpg
    Screenshot_ilink5.jpg
    79.5 KB · Views: 42

bpwwer

Member
ginigma said:
Testing v0.2.2a
Still getting a lot of kpl write/read errors. I'm just trying to set Toggle Mode for a button using the KeypadLink Configuration screen.
I've been working on the communication functions and I think it's getting better. It's kind of a balance deciding how long to wait for a message to be received before giving up. I still have a couple more ideas to try out. For one, it would be good if the writing was more intelligent so that it only writes the config options that have been changed.

ginigma said:
The Scene Controller and Group # are now in sync when selecting different scenes.
However, there's still a problem somewhere, as highlighted in the attached file. In the scene editor, I am trying to control a switchlinc with button 5. However, in the Device Programming window, it shows as group (button) 3, which is wrong.
I'll experiment some to see if I can reproduce it. I have a two controllinc's and I'm using all 5 buttons on both.

ginigma said:
If I go into the scene inf file and manually change it, it will display the group properly in the Device Programming screen, but the Level and Ramp information is all screwed up. Looks like the Level = Group # and Ramp is all set to 0 and Extra = Group # also. They are correct in the inf file. The Level and Ramp Rate info is correct in the Scene Editor Responder list. However, when I clicked the Program Scene button, it wrote the wrong info to the devices; it wrote what was in the Device Programming list (wrong levels and ramp rates). This seems to be a major bug.
I'm a little confused by the first part of this. The screen shot shows the scene group as #5, is that not what is written to the file? It almost sounds like you changed the scene, but it didn't rebuild the link entries. I'll have to check, but changing the group, might not be triggering a re-build of the link entries like it should.

After chaning it in the file, and re-running, the device programming screen for the device shows the correct group number, right? The controller and the responder both bet link entries and they are slightly different. The controller's link entry will have the reponder's address, the group number, (and for controllincs and kpls the button number). The controller does not have the on-level or ramp rate. The responder will have the controller's address, the group number, the on-level, and ramp rate. So what I see in the device section of your screen shot looks correct except for the group number being 3 instead of 5.

The information stored in the scene file is only the responder links, the controller links are created internally in the program.

ginigma said:
In addition, I noticed the following problems in the inf file:
PowerLinc V2 Controller has device_type=1; shouldn’t it be 0?
Some of the SwitchLinc V2 Dimmers have device_type=0; they should be 257. Some are correct.
I think early PowerLinc's had a device type of 0 and the later ones were 1. I don't know why some of the switchlincs have a type of zero. Can you correlate them to how they were added? Were they added using device disovery or by adding them manually via the form on the main screen? Currently, the only the powerlinc, controllincs and kpls device types really matter. All other devices are treated the same (notice that you can set a lamplinc as a controller in a scene even though that isn't valid).

ginigma said:
Did you include the new version of the iplc code in v0.2.2a? The source still has a Jan 28 date. That could be the cause of my communications problems.
The code I've been improving is in idrv.c and that was included in 0.2.2a. That's what has all the logic for the PLC communications. The iplc driver works fine. I'm not modifying that.

ginigma said:
You have a typo in one of your error messages: search for “tring†I think you mean “tryingâ€
Thanks, I'll fix that. Sometimes the old fingers just can't keep up.

Thanks also for all the testing and bug reports. You're really helping to make this a better program.
 

ginigma

Active Member
bpwwer said:
The controller's link entry will have the reponder's address, the group number, (and for controllincs and kpls the button number). The controller does not have the on-level or ramp rate. The responder will have the controller's address, the group number, the on-level, and ramp rate.
Ok, thanks for clearing that up. This makes sense.

bpwwer said:
The information stored in the scene file is only the responder links, the controller links are created internally in the program.
More good information!

ginigma said:
In addition, I noticed the following problems in the inf file:
PowerLinc V2 Controller has device_type=1; shouldn’t it be 0?
Some of the SwitchLinc V2 Dimmers have device_type=0; they should be 257.  Some are correct.
bpwwer said:
I think early PowerLinc's had a device type of 0 and the later ones were 1. I don't know why some of the switchlincs have a type of zero. Can you correlate them to how they were added? Were they added using device disovery or by adding them manually via the form on the main screen? Currently, the only the powerlinc, controllincs and kpls device types really matter. All other devices are treated the same (notice that you can set a lamplinc as a controller in a scene even though that isn't valid).
Some I added manually and others by discovery. Not sure which were which. I'll delete one and try both methods and check the results.

bpwwer said:
Thanks also for all the testing and bug reports. You're really helping to make this a better program.
Well thank you for doing all the dirty work. I spent many hours over the weekend reading the SDK docs and they're not that great. There are a few people writing some really good applications. I'm sure I'm not the only one who appreciates the effort taht goes into it.
 

johnnynine

Active Member
ginigma said:
Well thank you for doing all the dirty work. I spent many hours over the weekend reading the SDK docs and they're not that great. There are a few people writing some really good applications. I'm sure I'm not the only one who appreciates the effort taht goes into it.
I also appreciate all the work you have done. I wish I had more time to test.

Thanks!!!

Johnny
 
Top