Current Status of Insteon PLM Integration

[ddamron]

Thanks Pete, That'll help..

Isn't there a way to 'build' a hex string in bash?

If so, we can build 2 strings... One to send, and the other for search..
then we don't 'need' testserialport to handle hex values... it'll just be handling strings,

make sense??

Also,

I'm REALLY having troubles with this DAMN PnP...

I can get it to fire the wizard, but ONLY on the core..., and some values are NOT being updated in the new child device...

I'm going to take another stab at it...

Regards,

Dan

[PeteK]

Dan--

OK, looking back at the code I realize I made a mistake.  your script looks correct.  It works here with my PLM.

-Peter

[PeteK]

Dan--

One thing you may want to check in your template is adding data #162 (Only One Per PC) and #163 (Auto-assign to parents room).

I pulled these from the Zwave template and they seemed to make device discovery more stable.

Look at the Z-wave template or the Insteon template I had posted for their configuration.

-Pete

[ddamron]

Pete,

SWEET!

Not bad for slapping it together...

I didn't even get a change to test it yet!

Glad you did!  Thanks!

[ddamron]

Dan--

One thing you may want to check in your template is adding data #162 (Only One Per PC) and #163 (Auto-assign to parents room).

I pulled these from the Zwave template and they seemed to make device discovery more stable.

Look at the Z-wave template or the Insteon template I had posted for their configuration.

-Pete

Ok, I'll try that...
Really appreciate your support...
I'll add those to my template now..(if I haven't already broke my LMCE again)

Dan

[hari]

Looking at the TestSerialPort code, i noticed that there is no detection mechanism in there for sending hex values.  My guess is they planned to implement it, but did not finish.  I'm working on extending it to support the PLM, which will require hex send and probably a way to receive values and correctly work the compare, ignoring address bytes.

don't know which revision you are looking at but there is code for sending hex values in TestSerialPort (e.g. "string ParseHex(string sInput)")
It's used by some pnp detection scripts ("\xx").

best regards,
Hari

[ddamron]

Thanks Hari, That's the one I was using..
I double checked it with TestSerialPort --help first (to make sure of the cmd line options)

I'm pretty sure I have MY device PnP now, it's just getting the child devices to be PnP.


Dan

[ddamron]

Well, Development started off good, then quickly petered out.
I really need to talk to a developer or someone else who has experience with PnP.

I've got 2 more things to finish, but then, the driver is done.  What needs to be done:
1.  X10 integration - up till now I've been ignoring it.
2.  I still have to fix that keypadlinc bug...
(This is for 2-way communication)  The device sending the command is NOT guaranteed to be the device being controlled.
(or devices for that matter, since a SINGLE button COULD control multiple devices)

Luckily, I have ALL the device's databases in memory, so it should be a quick 30 minute subroutine.
(I don't want to rely on cleanup events as I'm not guaranteed to receive them.)

X10 shouldn't take too long either.. it follows the same flow as Insteon.. the translation tables are done, I just have to add the logic to handle it.

After that, I'm kinda stuck.

Just so we're clear, here's the details on what I'm 'Stuck' with:

1.  PROPERLY reporting Devices Detected via PnP
2.  Sending STATE information to DCE?  (I can send ON/OFF, but I want to send ON/50 --- how do the orbiters do it?!?)
3.  I've got a problem with sending OFF commands... I send them OK, They go through DCE fine, but when GSD gets them, it reports 'not executing command because it is useless'.  Now here's the kicker:  If I use an orbiter, go to the floorplan, DIM a light, then turn it FULLY ON, then OFF, it works.

PeteK, Can you confirm the Detection script I wrote worked just one more time, and document BOTH the script (I lost it) AND the PnP settings for the template here?  Thanks a ton!
Please, also unplug your PLM to verify the script FAILS too...

Hari and TotallyMaxed:  I don't know if either of you could possibly help with the 3 problems above, but If you find a spare minute, maybe see if you can help there, or possibly pm me with someone who can (pluto?)

Anyone Else:  Problem 2 above:  If you know C++, could someone look into that code and see how the orbiters do it?  Maybe they communicate to a different device or something like that... EVEN if I EMULATE an orbiter..  My problem is I don't know C++)

That will complete the PLM driver (which, I believe everyone is waiting for)
BTW, the TYPE of PLM is important.. AFAIK, GSD sends full bore to the serial device.
If you PLM is older, there was a note in the development package to 'wait until the character is echoed back to you before you send another character'

I would consider that not to be a 'bug'..  I can check the firmware of the PLM to determine which one you have.. and possibly put a (minor) delay after sending each character.  I cannot sense the character coming back through GSD...

Well, That's a wrap for tonight.

Regards,

Dan

[ddamron]

Ahh, Today was more of a problem solving day...
I did do a bit of coding, put in some remarks where I need to add X10.. also that other bug... but didn't really do any coding..
(honestly, didn't feel like it today..)
Instead, I did some research... trial and error you might say, and was pretty successful!
Totallymaxed gave me the PUSH I needed with regards to PnP.. and PeteK also helped there.. I have to try it, but let's hope I have it all straight...
I was trying to get the Lighting plugin to start on a MD... Thanks to TM, he informed me it only starts on the MD where the interface is...
NO WONDER I could only get it working on the core... AHA!  Now that I understand that... I can move forward..

As you probably know by now, I figured out the state information, or atleast a work around..

so, by my calculations, I have only 1 problem left to tackle.. and a bunch of coding... hehe
PeteK has dug into the ZWave code quite a bit.. and he understands it more than I.. so if I run into a problem with PnP, I'll pick his brain..

Problem 3 in the last post:  GSD reporting that command is useless..I wonder why that happens... Maybe it has something to do with the State..
I do have a work around for that.. but I REALLY don't want to use it.. sending a DIM command, then a FULL ON command, then a FULL OFF command...

So, not much in the way of coding today, but lots in the way of brainstorming...

Regards,

Dan

[ddamron]

Ok, I just had a hunch, tried it, and VERIFIED my hunch!

The STATE information has TWO PARTS to it...
ON/OFF is part 1, and the level is part2.

You can change part2 using setlevel (which sends a setlevel command...)
HOWEVER, INTERNALLY, the DCE sets the LEVEL, but NOT PART 1!
in the device status, it shows ON/30.. but sending an OFF command does not get processed!

this is because even though a setlevel was processed, internally it's still OFF
I can verify this by sending an ON command, setting the level to say 30, then sending an OFF command..
Looking at the State, it shows OFF/30!  proving that the TWO PARTS are NOT joined

What does this mean? Well, I need to send TWO DCE commands each time, ONE to set the level, and the other to turn the device on.

Interesting!

I haven't tested if I can set the level FIRST, then turn on the device.. or if the ON command will override the setlevel...

Conversly, when I turn OFF a device, I must SETLEVEL to 0 and turn OFF...

YAY ME!!! I ROCK!!!  I'm such a geek!!!
lol

That seems to solve all my issues!! the rest is coding...

Thanks to all who have helped out!

Dan

[ddamron]

X10 Support is almost complete.  I'm just verifying my interpretation of the commands..
Fixed a few more bugs in the spider... found a nasty one that was corrupting my database tables.
Fixed a bug during rerun of the spider which wiped out a couple remote databases...
Fixed a bug in Report Child Devices (hardcoded DeviceID)

Never did figure out how to attach the PLM to my Fiire Station.. hooked back up to the core to continue.
Added a few modifications to the template in preparation for another attempt at PnP.

Spider testing, while not perfect, is getting better..  I'm testing it by adding ONE lighting device, and letting the system find the rest.
All in all, the spider is working (every once in a while it times out, but gets right back in sync..)
Happy New Year!

Dan

[ddamron]

Heh, Sorry guys, I want to document some stuff so I don't forget..

Insteon todo list

finish X10 (a couple hours at most)
-- Sending X10 ON/OFF done,
Setlevel NOT done,
Receiving and decoding X10 Done,
Sending decoded X10 to lmce - NOT done
fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command -- DONE
add code to send cmd184 to self (to set state) beware of infinate loop. -- DONE
add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[ddamron]

Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[ddamron]

Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
DONE add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[/quote]

[ddamron]

Interestingly enough, even when you send an EVENT 48(device ON/OFF) it doesn't change the ON/OFF state of the device...
I'm wondering why event48 was even used in the zwave template...(probably for future use)
I'm going to put that event48 in the same category as event <new> (Report Lighting STATE::int) and not use it.

In the mean time, I'm sending COMMANDS to myself to change the STATE.  It's all working quite well...  The system now accurately tracks when you externally dim or brighten a switch, as well as on/off, and 'updates' the STATE accordingly.  I'll post new code after I'm done today..




Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
DONE add routine for GROUP BROADCAST command processing (keypadlinc bug)
  add generic support for devices OTHER than lighting (Irrigation, generic I/O)
  check code for PnP test, retry code(now that I know it only fires on the core)
  Once PnP procedure is nailed down, implementing it should be a piece of cake.
DONE Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[/quote]
[/quote]