Current Status of Insteon PLM Integration

[ddamron]

Well, a good coding day...

Solved quite a few problems that snuck up..  implemented X10 (all but X10 Dim/Bright commands)
Added support for Insteon remote dim/brighten (I cheated, just requested a status after the command was complete)

made a lot of progress with the state information... it's almost there..

I know of one bug with setting the state information.. I just have to fix it.

I implemented the Group processing... that works quite well (aka the keypadlinc bug is squashed)

Not a bad day coding wise, I STILL have a kink in my neck... <ARGH>

I said I would post more code today, but I wanted to fix the state problem first..

I'm mentally drained, so it's time to call it a day..

I'm surprised at how big this project actually got.. well, bit by bit it's almost done.

Regards,

Dan

[totallymaxed]

Well, a good coding day...

Solved quite a few problems that snuck up..  implemented X10 (all but X10 Dim/Bright commands)
Added support for Insteon remote dim/brighten (I cheated, just requested a status after the command was complete)

made a lot of progress with the state information... it's almost there..

I know of one bug with setting the state information.. I just have to fix it.

I implemented the Group processing... that works quite well (aka the keypadlinc bug is squashed)

Not a bad day coding wise, I STILL have a kink in my neck... <ARGH>

I said I would post more code today, but I wanted to fix the state problem first..

I'm mentally drained, so it's time to call it a day..

I'm surprised at how big this project actually got.. well, bit by bit it's almost done.

Regards,

Dan

Hmmm... software development tends to be like that. If you'd know how much work it would be or how many 'hills' there were to climb at the beginning you probably would not have started! ;-)

[ddamron]

Heh, Actually, I would have...
I've wanted Insteon implementation for a while now..
I just had to 'bite the bullet' and learn another language..
I suspected when I started the spider routines that it would get hairy..
and figuring out HOW to do things in lmce, that was really the hard part..

I was also suspicious of an 'embedded interpreted' language, but for all intents, Ruby has proven more than adequate.

I've done lots of software development in my years.. lots of hardware development too...
Both are about the same, estimate 4 hours to do a routine, and it takes 16.  I'm aware of that, and expect it.

ahh, the joys of being a techno geek...

Dan

[ddamron]

Well, I'm stuck.

I can't figure out how to get the Lighting Wizard working.

I'm going to release this code as is...

Once it finds all your lighting devices, you'll have to go into Lights and figure out which is which, (ON/OFF/50% works)

Then, give it a proper name, and room... Don't forget to set the ObjectType! (table lamp, sconce, etc)

The First and second times it runs, it takes a little bit..

The First time, it spiders the insteon network, looking for devices, and reports them to the system.

The Second time, it redownloads the configurations OF those newly discovered devices, and saves it into the newly created devices.

After that, it's pretty quick..

I'm still fighting with the state info bug.. ahh well..

Also:  If for some reason, it misses some configuration.. simply DELETE the string in the CONFIGURATION field of the light in question, and reload router.
It will redownload that device's configuration.

Gimme a bit to disable the state bug, and I'll upload it asap..


Dan

[ddamron]

Code is uploaded.

Also, no need to fire a 'Report Child Devices' command from the advanced menu..
The code will do it automatically once it finishes the spider routine.

The first time it runs, it may take a minute or two, eventually, you'll get a message on your MD saying 'New devices have been installed.  Please reload the router'

When you reload router, it starts it's second run... (here, it downloads all the configuration to the child devices)
Give it about the same time as the first.

From that point, it simply checks the configuration of each device, and if it's different, it will download the database again.

X10 is functional.
State information is buggy, but other than that, it works quite well.

I've noticed once in a while, the PLM will lock up.. I can't seem to unlock it via software.. it just NACKS every command. (0x15)

If this happens, unplug your PLM from power, plug it back in, and reload router.

I'm going to consider this project as complete as it's going to get, unless someone can explain the lighting wizard to me..

I was going to write my own 'Lighting wizard' in ruby, but why reinvent the wheel...

If anyone finds any bugs, please let me know.

NOW is the time to test it.  If you have equipment, NOW is the time to try it out.

watch the PLM Logs as you send commands.. there's still a bit of debug information..

Well, I'm 3 days late, and 2 features shy (wizard and state)..

On to the next project...

Regards,

Dan

[ddamron]

Oh, yeah,

I could only get it working if the PLM was installed off the CORE...

This could be a brain fart on my part.. (possible template problem)

If anyone has any success using the PLM off an MD, let me know!

(It could also be because I'm trying to use it off a Fiire Station)

Technically, the code should work.

Dan

[aaron.b]

Regarding: GSD is ignoring command because it's useless...

Unfortunately this code inside GSD is kind of hard to get to and follow.  But basically what it's for is if you send the same on or off command repeatedly it only does it once.  This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it).  There's a parameter you can add to the on or off command to force it to send it again.  I think it's "retransmit" or something.  I'd need to look in the code again.  You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes.  You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.

GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.

As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin).  You'll see it intercepts some commands and events.  I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.

[ddamron]

Regarding: GSD is ignoring command because it's useless...

Unfortunately this code inside GSD is kind of hard to get to and follow.  But basically what it's for is if you send the same on or off command repeatedly it only does it once.  This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it).  There's a parameter you can add to the on or off command to force it to send it again.  I think it's "retransmit" or something.  I'd need to look in the code again.  You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes.  You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.

GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.

As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin).  You'll see it intercepts some commands and events.  I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.

Aaron,

Thanks for you post!
Since then, I did manage to trace the code, and found where it sends that message (consequently ignoring the command)

Once I found it, looking at the code a bit closer, it only makes sense, and I am working around it by keeping state information in my code.

Thanks again for the hint about the retransmit though..  I'll look into that.

I'll also take a closer look at Lighting_Plugin.cpp for the event info.

Regards,

Dan

P.S.  It was nice seeing you at the conference..  (I was on webcam)

[Matthew]

Since then, I did manage to trace the code, and found where it sends that message (consequently ignoring the command)

Once I found it, looking at the code a bit closer, it only makes sense, and I am working around it by keeping state information in my code.

Thanks again for the hint about the retransmit though..  I'll look into that.

I'll also take a closer look at Lighting_Plugin.cpp for the event info.

I haven't been able to find how these various devices send their messages to the DCERouter. Where in the code did you find that?

P.S.  It was nice seeing you at the conference..  (I was on webcam)

Next time, more dogs on the set. If only for the hairstyle variety .

[ddamron]

matthew,
in Generic_serial_driver.

[Matthew]

matthew,
in Generic_serial_driver.

Which method sends the event?

[tom_say]

not sure if this will help you all i am sure you all have seen it

http://misterhouse.svn.sourceforge.net/svnroot/misterhouse/trunk/lib/Insteon_PLM.pm