Oops! Found a bug in my insteon! YIKES

[ddamron]

hehe, well, I think I found my first Major bug...
While I was searching for the reason, I also found a solution.. so It's just going to take a bit more coding to fix...

anywho, here's the situation:

I scan all child devices for their insteon ID, and make sure they're all in the PLM.  If they're not, I add them to the PLM.
I do this so that when I put the PLM into MONITOR MODE, it will catch all messages..
All is fine, so far...


When someone presses a Switchlink, it sends out an insteon message saying it's turning on/off...

Here's the catch:

a Keypadlinc does the same thing.. BUT it's NOT CONTROLLING ITSELF!!
a closer look at the keypadlinc, it sends BROADCAST messages (determined by the flags) with the button ID as the GROUP.

hah!  I was tracking the FROM Address and assuming this was the device turning on...  which is NOT the case!

The fix: (and it's pretty easy)

I already interrogate all child devices and download their databases.  I store this information in the child object itself (in devdata_[59] configuration, which is added to each device by CODE, not template)
I also have the database in memory.. so I have to search the memory for RESPONDER records of said insteonID and GROUP.. then send events based on those devices...

I also found another situation to address:
I have 2 devices that are NOT connected to anything -- they are keypadlincs used as REMOTE CONTROLS.. (by the bed)
I have to find a way to add those devices as child devices, but don't control anything directly, they simply send out commands to control other devices...

As always, I would REALLY like some comments / suggestions.. I know almost everyone is busy with the 710 beta..  I'd be right there with you guys too if I wasn't sooooo close to having this done.

I don't want to 'break' my system until I'm finished... hehe

more or less FYI...

Dan

[Matthew]

hehe, well, I think I found my first Major bug...
While I was searching for the reason, I also found a solution.. so It's just going to take a bit more coding to fix...

(...)
As always, I would REALLY like some comments / suggestions.. I know almost everyone is busy with the 710 beta..  I'd be right there with you guys too if I wasn't sooooo close to having this done.

(...)

more or less FYI...

I can't help, with my nonexistent Insteon expertise. But I hope offering a good listener helps you think through your work better. And your developer notes here will help others following your pioneering footsteps later (so less work for you to do alone later . Thanks for plugging away!

[PeteK]

hehe, well, I think I found my first Major bug...
While I was searching for the reason, I also found a solution.. so It's just going to take a bit more coding to fix...

anywho, here's the situation:

I scan all child devices for their insteon ID, and make sure they're all in the PLM.  If they're not, I add them to the PLM.
I do this so that when I put the PLM into MONITOR MODE, it will catch all messages..
All is fine, so far...


When someone presses a Switchlink, it sends out an insteon message saying it's turning on/off...

Here's the catch:

a Keypadlinc does the same thing.. BUT it's NOT CONTROLLING ITSELF!!
a closer look at the keypadlinc, it sends BROADCAST messages (determined by the flags) with the button ID as the GROUP.

hah!  I was tracking the FROM Address and assuming this was the device turning on...  which is NOT the case!

The fix: (and it's pretty easy)

I already interrogate all child devices and download their databases.  I store this information in the child object itself (in devdata_[59] configuration, which is added to each device by CODE, not template)
I also have the database in memory.. so I have to search the memory for RESPONDER records of said insteonID and GROUP.. then send events based on those devices...

I also found another situation to address:
I have 2 devices that are NOT connected to anything -- they are keypadlincs used as REMOTE CONTROLS.. (by the bed)
I have to find a way to add those devices as child devices, but don't control anything directly, they simply send out commands to control other devices...

As always, I would REALLY like some comments / suggestions.. I know almost everyone is busy with the 710 beta..  I'd be right there with you guys too if I wasn't sooooo close to having this done.

I don't want to 'break' my system until I'm finished... hehe

more or less FYI...

Dan

Dan-

I'm a little confused.  If the keypadlincs are not controlling anything, and you're lookinf at responder links for state information, why do you want to add these keypadlincs into the sytem as child devices?  BTW, how are you creating these child devices?

Thanks,
-Pete

[ddamron]

PeteK,
I haven't got that far yet, I haven't created *any* child devices yet.
My concern is: when I spider out to sniff all insteonIDs, I'm going to find those two switches..

I'm trying to figure out how to deal with them when I DO find them.
When I do find them, I can confirm they are keypadlincs... so that helps.
I'm thinking I'm simply going to add them as child devices, in a room UNKNOWN?

[PeteK]

Dan--

I've been going back and looking at how the current Zwave code handles child device creation.  DCE sends command 756 (CMD_Report_Child_Devices) to the interface once it discovers the interface.  The Zwave interface builds a list of devices, with Node and Type information and then creates a "Reporting Child Devices" Event, which triggers whatever handles that event (I believe at this point, the lighting plugin) to create child devices and begin the wizard for assigning those devices to rooms.

From the source, it looks like the format for each node is:

Code: [Select]

// [internal id] \t [description] \t [room name] \t [device template] \t [floorplan id] \n
The code to add a dimmable light is:

Code: [Select]

snprintf( buffer, sizeof(buffer), "%d\t\t\t%d\t",  node->nodeID(),  DEVICETEMPLATE_Light_Switch_dimmable_CONST );

Which looks like not all information needs to be populated, so the event parser (the lighting plugin) is smart enough to ignore empty fields.  Since the DCE router is not reloaded at this point, the standard "Send_Command_to_Child" won't work yet.  The lighting plugin uses the 760 Command to turn the lights on or off to allow the user to select the room. The lighting plugin then sets the "Room" attribute for the child device. After lighting configuration is complete, the router is reloaded and the standard "Send_Command_to_Child" is used to control the lights.

[Zaerc]

PeteK,
I haven't got that far yet, I haven't created *any* child devices yet.
My concern is: when I spider out to sniff all insteonIDs, I'm going to find those two switches..

I'm trying to figure out how to deal with them when I DO find them.
When I do find them, I can confirm they are keypadlincs... so that helps.
I'm thinking I'm simply going to add them as child devices, in a room UNKNOWN?

When adding X10 devices manually in my experience the Setup Wizard pops up to tell me she's detected a ligthing system and then tries to switch them on and off (unsuccessfully in this case) in order to determine what and where they are.  Maybe you could trigger that mechanism as well?  Just a thought.

[PeteK]

Zaerc--

Yup.  That's the wizard I'm talking about.  The device template has to support the 'discoverable interfaces' command group in order for this process to work successfully. Those are the commands I mentioned in my previous post.

[ddamron]

PeteK and Zaerc,

I really, really, REALLY apreciate you guys helping with this!  That is EXACTLY what I need to do..
I've found a few bugs (I'm painfully going through as we speak) so that's why I haven't been on as much today.

Currently, I'm debugging the spider... as in getting the device's internal link database.. and saving it to the child device.

It's really hairy, as my code is all reentrant (due to the single thread issue)

I've been thinking about rewriting the whole shebang again with a more 'OO' flavour.. (I keep kicking myself, and saying LATER!)

I haven't implemented adding child devices yet.. but when I do, I'll be re-reading this thread... LOL

So far, my spider routine is doing:
1.  getting insteonID's from child devices (currently configured)
2.  checking to make sure they are in the PLM (if not, adding them)
3.  checking the current database delta of each device (if different, downloading the device's complete database and updating the config)
4.  going through EACH device's datbase, looking for Insteon ID's that are not in the PLM (and adding them as needed)
5.  (NOT DONE YET) go through the PLM's new database, checking for devices not installed in the system (THIS is where I'll fire those events/commands)

the hard part about this is that it's reentrant code... I can't simply 'send' a command and wait for a 'response'
commands are added to the commandqueue as required.. (some commands have to be added to the front of the queue, while others are added to the end)
examples of commands that need to be inserted at the front of the queue:
GetNext PLM record MUST be right after the getLnk (which gets the first link)
peek commands also need to be inserted at the front of the queue..

Phew...

Thanks guys! and keep it coming!

Dan

[PeteK]

Yeah.  Those are some of the issues that drove me to a c++ implementation initially.  Then again, you've surpassed my current level of functionality pretty handily with Ruby so far...

[PeteK]

In any case, I think you can make the requirement initially that all devices that are to be controlled are linked to the PLM before the PLM is added to the system.  Any further additions can be done manually for now.  I know this is not your end goal, but for an initial step, it could prove easier.

[ddamron]

I'm past that stage now...
As far as I care, the PLM's database can be BLANK.. NO LINKS

As long as their's a valid insteonID in one of the childs.. the spider routine will start...
1.  Adding the childs insteonID to the PLM
2.  searching the childs database for other insteonID's
3.  Adding them to the PLM
4.  searching each link's database, one by one for more insteonID's
etc, etc, etc.
Once all the insteon ID's are in the PLM, then I can reload the PLM's database, and check if the devices  are 'configured' in linuxmce.

I think I have the spider working now..

We'll see.. now, I probably have a thousand records in my PLM, so I have to reset it... lol

[ddamron]

Ok!  MAJOR Progress today...
The spider routine works.  I'm ready to add devices to linuxmce..
I have a question though, and would like other's comments:

Should I just 'GO AHEAD' and add new devices, or

should I WAIT for a command to 'look for child devices'?
and if so, what would that command be?



Thanks!

Dan

[PeteK]

The DCE command is 756 (CMD_Report_Child_Devices).  This is sent when the interface is detected.

[ddamron]

Pete, check your email...
gimme a call when you get it all loaded...



Dan

[ddamron]

Ok!

I got cmd[760] implemented..

it's weird though

on some of my lighting devices (that are already in the system) don't send the proper pk_command... (yes, it's lowercase, it's passed that way to ruby as uppercase signifies CONSTANTS)

That had me baffled.. until I said 'let's see what happens when I click other devices on/off... for sh*ts ^ g*ggles'

low and behold, the commands came through..  I even figured out the 50%.. it doesn't come through pk_command... it comes through as a parameter..

So, cmd 760 is implemented.

I think I'm calling it a night, I've been at this since 12 noon..

VERY productive day today

Hopefully, tomorrow, I should be able to implement the Report Child Devices event, and get the lighting script working!!!

VERY CLOSE!!!

Dan