LinuxMCE Forums
General => Developers => Topic started by: ddamron on December 14, 2007, 01:04:33 pm
-
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?
-
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? ;D
-Thom
-
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?
-
220 Volt devices available in europe would be nice. ;)
-
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!)
-
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
-
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...
-
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?
-
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
-
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..
-
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.
-
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!
-
Great!
So what's next?
-
Ring!
-
okay ddamon, here's the question:
Which controller should I pick?
-Thom
-
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
I would prefer fixing up the X10 support properly, but I'm still a long way from getting around to even looking at it. And I'd probably need to get an X10 remote and motion sensors to test properly as well.
-
okay ddamon, here's the question:
Which controller should I pick?
-Thom
Well, pretty soon, you'll have a choice of 3. I'm working on the PLM right now..
If you just want linuxmce dedicated control, I'd go for a PLM.
If you want a controller that can do all kinds of other things via the internet, I'd go with a PLM/EZBridge (The EZBridge uses a PLM)
Also, if you want to connect via IP (ethernet), the EZBridge is the way to go..
if you can connect with a COM port, PLM.
if you need to connect with a USB port, PLC.
-
Oh, did I forget to mention, I'm also working on X10 support, also bidirectional...
I have a plethra of X10 devices / sensors, so I can test that functionality..
The EZBridge interface sees the X10 commands now, just doesn't do anything with them.
-
ZWave bidirectional communications is limited by a pesky patent of Lutron's so most ZWave guys have been reluctant to do it. The hardware does have the ability. Leviton does have a solution and they were sued within weeks of shipping.
The issue with Insteon is reports of flakey hardware. Some forums have indicated a 1 year life expectancy for the hardware. The better ZWave stuff (Leviton, Cooper, Intermatic) should last a long time. Perhaps redoing the ZWave stuff is next since it is supported in Europe and soon Asia.
I'll see if I can gather some Insteon hardware and try it. LMCE should be able to support both simultaneously.
-
I can confirm that LMCE has no problem with Zwave and Insteon working side-by-side. Currently I have an ACT ZCU000 and an Insteon PLC running without problems.
The hardware build quality of the Insteon switches doesn't feel as solid as with my Leviton Zwave switches, but hopefully that can be improved over time.
-
If you want a controller that can do all kinds of other things via the internet, I'd go with a PLM/EZBridge (The EZBridge uses a PLM)
Also, if you want to connect via IP (ethernet), the EZBridge is the way to go..
if you can connect with a COM port, PLM.
if you need to connect with a USB port, PLC.
What kinds of things can a PLM do via the Internet? Are you talking about managing the PLM over the Internet, or the PLM managing devices over the Internet? If the latter, how do you connect the remote device to the local PLM, an EZBridge?
I think it's weird that a PLM works (on some layer) over TCP/IP, but uses the (ancient, deprecated) COM port, while the PLC doesn't do TCP/IP, but uses the modern USB. Most modern mobos come with ethernet and USB, and COM often doesn't come with ethernet.
-
Matthew,
I think you miss understood me..
a PLM connects Insteon signals to either an RS232 port, or a TTL Level Device.
the EZBridge connects to a PLM (as a TTL Level Device) and then connects to IP.
With the PLM Alone, everything is local..
However, if one is using an EZBridge, it can be located anywhere in the world, as long as it has an accessible IP, linuxmce can send commands to it, and receive information from it.
An EZBridge is ideal if you have a 'remote' location, and want to monitor/control insteon devices.
-
as an example, I have my EZBridge located OUTSIDE my linuxmce subnet..
(it's connected to the same switch as the PUBLIC port of my core , and hence, get's an IP in THAT range)
pluto's internal IP subnet is 192.168.80.x/255.255.255.0
pluto's public ip AND EZBridge are on 192.168.x.x/255.255.0.0
FYI, all my IP cameras are on that subnet too.(255.255.0.0)
-
Just a Status Update:
PLM interface is now functioning.
EZBridge interface is now functioning.
Internally, both devices send and receive using the same methods. This allows me to add functionality to BOTH at the same time.
Device Detection (determining the type of device) is implemented and working.
Database Delta values are being read, currently, nothing is being done with them.
I want to get a bit more accomplished today, but I should be able to post updated code later today.
Dan
Questions I still need answered:
1. How do I read Scenario configurations in Ruby
2. How do I store 1 Byte of data into the child device
3. How do I return STATE information to the child device (currently, I can only send on or off, not ON/50)
-
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?
>> on another note, does ANYONE know how I may be able to SAVE certain state information?
First, if the data you want to store for a child device is the unique address or id that the parent uses to identify that child, you should use the device data: DEVICEDATA_PortChannel_Number_CONST 12 This is the standard. So, for a light switch that is controlled by an X10 controller, that device data is something like C8. If the light switch is part of an EIB system, it may be: 10.37.1. And so on.
Now assume you need some special device data for your light switch that is totally unique to Insteon, and is separate from or in addition to the standard id that the switch has (which is device data 12). Let's call this "Insteon Status". The usual way is to go into the device template (say generic on/off switch) and add a device data ("Insteon Status"), and set the 'set by device' to true. I don't recommend this, though, because the device templates for the child devices (like lights) are shared by all the interfaces (ZWave, EIB, etc.). You don't want to add this to the template because then it will be there for all non-Insteon light switches too. The best solution is to set the device data for devices in code without defining it in device template. For example, add a new record to Device Data "Insteon Status". The next time pluto2cpp generates the header pluto_main/Define_DeviceData.h there will be a #define for it. Then in your Insteon interface, call the Command_Impl::SetDeviceDataInDB, passing in the device id and the new #define for your device data. This will set it in the database, but this won't force it into the template, so it won't effect EIB and others. Each time the router reloads and you get your pointer to the Insteon Device (DeviceData_Impl) you can call: m_mapParameters_Find with your device data to get the value. That will get the value that was in the database when the router was last reloaded. This is best, since you probably are keeping a copy of the current value in memory. if you don't and need to do a database hit to retrieve the current value you already set, call m_pEvent->GetDeviceDataFromDatabase() (from Event_Impl.h)
-
Aaron,
Thank you!
I'm writing this all in Ruby... Can I define DeviceData in Ruby? currently, I read the Insteon ID using devicedata_[12], just as you suggest..
now If I create a NEW device_data (without defining it in the template of course), will that device data replicate itself into the database?
(just so I'm clear...)
device_.childdevices_.each{|c| $children[device_.childdevices_[c.to_s.to_i].devdata_[12].chomp.lstrip.rstrip] contains my Insteon ID
so if I do:
device_.childdevices[c].devdata_[uniqueDeviceDataID] = valuetosave #The value I really want to save is the Database Delta byte.. this tells me if an insteon device's database has changed
Thanks again!
Dan
-
Also, this would imply that each device could potentially have hidden devicedata_...
Would the STATE of a device be accessible this way? Currently, I can only send State ON or OFF..(via an event)
I'd like to send ON/45..
-
Aaron,
Thank you!
I'm writing this all in Ruby... Can I define DeviceData in Ruby? currently, I read the Insteon ID using devicedata_[12], just as you suggest..
now If I create a NEW device_data (without defining it in the template of course), will that device data replicate itself into the database?
(just so I'm clear...)
device_.childdevices_.each{|c| $children[device_.childdevices_[c.to_s.to_i].devdata_[12].chomp.lstrip.rstrip] contains my Insteon ID
so if I do:
device_.childdevices[c].devdata_[uniqueDeviceDataID] = valuetosave #The value I really want to save is the Database Delta byte.. this tells me if an insteon device's database has changed
Thanks again!
Dan
I'm doing similar thing in Perl. I keep states as internal variable in my driver and then do comparisons. My experiences show that you need to distinguish between changes that do happen in LMCE and changes that do happen in your automation system, cause you need different actions on them....
At the start, I read all initial values from home automation system and then proceed...
HTH,
regards,
Bulek.
-
Bulek,
That's currently what I'm doing right now too.. however, here's the problem:
If I sense a database change in an INSTEON device, I need to read it...
when I read an INSTEON device's database, it could require HUNDREDS of different commands/responses
hence why I want to just read the DELTA (a database status byte that increases each time the database changes) and compare it to a stored value..
I have 30 or so Insteon devices.. all of them have tons of links... each link (database entry) requires possibly 16 seperate commands to read it.
I don't want to do that upon initialization, plug up the Insteon network for 10 minutes... hmmm
Thanks for your reply though!
Dan
-
I'm doing similar thing in Perl.
I heard you were working on Perl integration with LMCE. I sent you a PM today about my investigating embedding Perl along with Ruby to GSD support.
-
That must be directed at Bulek, I'm not doing anything with perl... ;o
-
I think I may have stumbled onto something... looking closer at the zwave template.. I see a command group 841 - Set Config Param..
This has a bunch of stuff that looks like it's zwave specific..
including parameters
239 NodeID (int)
248 Parameter ID (int)
48 Value (int)
Then I went into the zwave Device Template.. and found Command Group ZWave
in that command group are commands:
820 Assign return route
842 Set Association
841 Set Config Param
840 Set Wakeup
I added the zwave commandgroup to my PLM device template.
Now, when I try to manually send a command (from advanced tab) I get this in my log...
GSDMessageTranslator isCmdImplemented = false <0xb60a8b90>
05 12/17/07 18:01:49.238 #### Pre-Process Queue = 1 <0xb60a8b90>
05 12/17/07 18:01:49.238 _QueueProc Pre - 841 : 0 <0xb78abb90>
05 12/17/07 18:01:49.238 GSD-Sleep Pre 841 : 0 <0xb78abb90>
05 12/17/07 18:01:49.238 Process Queue = 1 <0xb78abb90>
01 12/17/07 18:01:49.258 For obscure reasons could not handle the message <0xb58a7b90>
05 12/17/07 18:01:49.258 GSD-Sleep Post 841 : 0 <0xb78abb90>
05 12/17/07 18:01:49.258 _QueueProc Post - 841 : 0 <0xb78abb90>
anyone have any hints for me?
I'm looking at the possibility of storing all the database deltas in my PLM device instead of in the child devices... this way I don't have to modify them...
Thanks for all your comments!
Dan