What features do YOU want in an Insteon Interface?

[ddamron]

I'm at the point to start building in features... Give me some ideas, I'll see what I can do.

I've got (currently on the go):
1.  Device Detection - Confirmation of Insteon devices vs pluto device templates (so you don't control your sprinklers when you want to turn on a light )
2.  Automatic Device creation - automatic creation of devices based on Insteon device detected

I'd like to implement:
3.  Enhanced Grouping - extend the Group functionality of Linuxmce down to the Insteon level for SIMULTANEOUS multiple device activation.
4.  ability to 'spider' the insteon network for undetected devices. (includes automatic All-Linking)

What else?

[tschak909]

dude, even with what you've got so far, you've already overshadowed every other lighting/climate DCE device in the system.

you've singlehandedly convinced me to completely ditch my Z-Wave setup for Insteon.

Can I send you a crate of beer? 

-Thom

[PeteK]

I don't know if extending the current grouping idea is the best way to go.  I think creating a new grouping mechanism may be easier, especially to go to a scenario-based grouping system.

Other than that, you've already surpassed the level of integration that I've gotten so far, so I need to take a longer look at your code and port those features.

So how do you plan on doing the automatic device detection?  Do you require the device to be paired with the controller first?  Otherwise, how do you get around Insteon's security scheme?

[Zaerc]

220 Volt devices available in europe would be nice.

[colinjones]

Here, here, Zaerc!! For Aus/NZ too - can't find a damn thing

Edit - maybe I should have said, can't find a damn thing at 220-240v either (except X10, which I'm not interested in at all!)

[PeteK]

It sounds like Zigbee may be the answer.  They do have a frequency they can use in europe.  I guess we should start looking at zigbee to pc adapters

[ddamron]

Heh, Sorry guys, can't help with the hardware...yet...

I ordered a HDK, but they cancelled it on me... (they probably want to see some form of progress)


I'm not sure how Insteon would work in 50Hz countries...  It's not in the spec...  It depends on how they sense the zero crossing...
Also, on the RF side, I don't know if the frequencies are legal in europe...

Here in Canada, it's not a problem.. 60Hz, 120/240 Single phase..

Tschak909,
Thanks a ton!  It's nice to hear praise once in a while... I don't think webPaul1 gets enough, he's really the brains of this whole project... I'm just taking a small tidbit of his masterpiece, and enhancing a bit.
Heh, If your going to throw your Zwave away, send it my way... I'll see what I can do with that..
Insteon does have it's quirks.. but it's a far cry from the ole CM11A I used for years..
I've been also keeping an eye on your MAME project with amaze... can't wait to see that happen...
Can you send the beer to Canada? lol

PeteK,
I think you're right about coming up with a grouping mechanism... You got me started, for that I am grateful!
The spidering of the network - in order for monitor mode to work, either the sender or the receiver MUST be in the PLM's link database.
I can track the Database Delta and compare that to detect if a database has changed.. this way I don't have to read the whole database, just the delta.

Spidering will simply be going out to all known devices, reading their database, and making sure all devices in their database linked to the PLM.
Ideally, when ANY new device gets linked to ANY current device, the 'spidering' should be able to detect it, and add it to the PLM.

this spidering scheme SHOULD be relatively fast too.. detecting if a database has changed or not is a simple 1 command/response.  Depending on if the device supports DATA commands, reading the whole database could be as simple as 1 command, and receiving Extended packets back. (I'm working on that also)  If the device does not support Data, then peeking into the database is the only option, however, I think I should be able to optimize what I need to actually read... thus not requiring to read the whole thing...
I haven't dug deep enough (for me anyway) into the security... but if I'm not mistaken, 2 of the 3 bytes ARE transmitted.  It might take some time, but that only requires 256 different combinations to try to PING the device..
of course, with the timeouts, it may take a while, but eventually, it should 'catch' the right insteon ID.

More important, what if the device REALLY IS at your neighbour's place???
Let me think on that.. I don't know if I really want to HACK Insteon's security scheme...  Is it really worth it, and is is really needed, if all you have to do is link the device with ANY other device..the spider process works so much better..

On a sadder note, I woke up today with my development PC dead.. Processor fan choked.. Processor is still good, replaced the fan, but now windoze won't boot...
So I had to add a serial port dongle to my Fiire Engine (It's about time eh?) and I'll be continueing development on my laptop.

so now, I have to make sure the dongle I added to the fiire has the right pinouts... (can't find the pinouts for it)  I hope its standardized...

[ddamron]

on another note, does ANYONE know how I may be able to SAVE certain state information?
Eg:  I'd like to be able to read a device's database, then it's delta.  SAVE it's delta for future comparison..possibly in the Child itself??
I really don't want to have to create a file and save it there..

Suggestions?

[tschak909]

i could donate donate some zwave devices because the zwave implementation, while somewhat complete, lacks in some really annoying ways:

* no bi-directional communication
* ripple effect as devices come on and off
* sometimes devices don't get the message, even though they are in close proximity
* no ability to set individual device parameters, without using the Zwave master controller, and even then, on a very non-intuitive parameter=value basis, and none of the parameters seem to be documented in the little pieces of paper that come with the modules :-P

-Thom

[ddamron]

Heh, Geeze, I didn't realize it wasn't bidirectional...
I'm having some minor troubles reporting back to linuxmce.. HOWEVER, I can CONFIRM my insteon routines are FULLY Bidirectional, and IF a response is NOT received, the command is send AGAIN.

Every message is both acknowledge when it is SENT, and acknowledged when the receiving device executes the command.

The ripple effect... currently, that is what happens in my driver too.. until I can come up with a grouping routine..  I can do it, it's just a matter of logistics.

Keep in mind, my implementation is in RUBY..  the zwave is in C++.. they can do multiple threads, I cannot.. (I've been able to work around most of that with my queueing scheme)

It's actually kind of neat, following the log upon reload...  I have about 15 devices configured, and watching the command queue is pretty impressive.

Donations??  heh, lemme get the insteon wrapped up first!

I just spent the whole day trying to figure out the stupid pinout of the COM port connector on the Fiire Engine...
Took me all day, but I finally made an adapter so I can connect the PLM directly to the Engine.. and go figure, it's straight through, pin 1 to pin 1, pin 5 to pin 5..

[PeteK]

It looks like my Insteon interface is going to make it into the 0710 release.  I had to freeze development some while back in order to concentrate on getting it into the build, so right now, it does suffer from the lack of bi-directional communication, and the ripple effect of serially changing light status.

However, it looks like the initial release at this point is fixed and I'm going back into the code to add fixes for those features. Dan's interface (using the EZbridge device under GSD) does currently support bi-directional communications. The group mechanism is going to need to be implemented to finish off the ripple problem once and for all.  This is a fairly small task to accomplish in Insteon.  I've written and tested the functions for doing it with the PLC, and the PLM contoller supports it natively, supposedly.  The task Dan and I are trying to figure out how to accomplish is to add support for these lighting groups into the higher-level LMCE lighting module.  This is a high-priority item and I hope we can have a patch soon.

[ddamron]

Way to GO PeteK!

Congrats!

BTW, I've designed the EZBridge code to be generic as possible... a few subroutine changes, and I should be able to implement the PLM too.

I just got the PLM responding... so that's hot on my todo list..
Then, Insteon will be supported by PLC, PLM, and EZBridge!

Heh, You want Insteon??? Pick your controller!

[PeteK]

Great!

So what's next?

[ddamron]

Ring!

[tschak909]

okay ddamon, here's the question:

Which controller should I pick?

-Thom