evilpete

I look forward to playing with this, the limitations of WeMo emulation was getting annoying..

Thank you for your honesty Yes I agree I could have done better, for some reason I couldn't find my groove and bring out my my inter Mussolini on onstage ( and having hardware problems right before the top certainly didn't help). [it's been over a decade since I presented on stage] The important part is I got the information out there, I plan to clean up the reference source when I have time these days I'm a bit distracted working on another projects

Feel free to send me push requests, most of the python code was written where is was beating with a hammer till it worked. The demodulation code in C has been rewritten and needs to be linted and checked in.

I have one at my main panel, seems to work ( if nothing goes wrong, its working ). Although, electrically you get better protection with a distributed systems (eg : protected power strips everywhere )

Background : I2cs requires a device to be linked as a responder before it will accept commands. To link a device physical access and/or knowledge of the INSTEON address of a device is required As a security precaution, Insteon PLM firmware masks address of unknown/unpaired devices to prevent discovery and PLM’s firmware always inserts the true PLM ID number in the From Address field of messages that it sends Since the Insteon protocol is unencrypted and unauthenticated anyone with layer 2 ( the Data link layer) access can circumvent *any* of these restrictions. That is they have the ability to read the full contents of any message/packet ( and see the full address of even non paired devices ) as well as send with any ID in the Address fields of the message/packet Thus to circumvent I2cs restrictions all you have to do is intercept a message/packet then programmatically link to that device ( no physical access needed ) Alternatively after you intercept a message/packet you can impersonate a paired device and do anything you want.

I2CS offers no protection from layer 2 protocol spoofing and injection. In other words the ability to send & receive arbitrary packets includes the ability to intercept & impersonate any other device.

Personally I don't think the talk when that great, I was not as animated as I normally am on stage. I'll have the slides up tomorrow on github with some of the demo code. I'm interested in seeing what people do with these resources. Network Insteon bridges/relays, server signaling, etc...

To be clear the the cc1111emk (with software) can be equivalent of an Insteon 2448A7 Portable USB Adapter but with the ability receive and send arbitrary packets over RF, you will need an AP or dual-band device to relay the packets onto the powerline. In fact for "fun" I just ordered a EZ430-Chronos-915 ( http://www.amazon.com/gp/product/B00DK2D8WW ) since it's based on the same chipset as the dongle and thus would be somewhat trivial to run a script ( in the watch ) that can send Insteon commands. That pretty much already done, for receive only you can use a $15 rtl_sdr dongle and software demodulator The current output is something to the effect of : Flag To From cmd crc padding C3 : 11 0D 27 : 01 00 00 : 11 80 F8 00 00 AA 41 : 80 25 13 : 11 0D 27 : 11 01 8C 00 00 AA 0B : 69 54 17 : 80 25 13 : 13 00 C3 00 00 AA

It can be done easily with the cc1111emk USB dongle. I already have Python scripts that allow you to send commands in hex similar to the raw PLM interface. Wrapping this as a network service making and presenting a PLM like interface over TCP would be straight forward.

the reason the code was not pre-released was because while writing it I effectively beat it with a sledge hammer till it worked for me. Given I have kids and a day job I have not had time to clean it up as much as I would like. I also wrote my own software FSK demodulator in the process as an exercise. I'll be posting the code on my github account some time this week and I have plans to eventually make the tools more genetic for use with other RF protocols. Maybe someone will take what I've started and write a software based PLM...

Defcon will be uploading the video in the next few weeks, it is not one of my better talks. I was not as animated as I would have liked. I took on this project after trying to implement the RF protocol as documented in their ”white paper” with a toolkit called rfcat and having it not work. In the process of debugging I discovered the gross inaccurately of the published documentation.

I'll have the code up in a day or so now that I'm back from defcon. Effectively Insteon's documentation for their RF protocol is bullshit and not even close to what is really used. I've reverse engineered the actual protocol, documented it, and wrote proof of concept set of tools. These tools consist of a few programs & scripts to allow anyone to intercept and/or transmit commands effectively circumventing Insteon's security model of needing to know the node address or being paired. With a good antenna Insteon devices can be communicated with at a fair distance. The security risk for the end user obviously depend on what you use Insteon for. if you have just lights, your threat profile is minimal. I would not advise connecting locks or alarm systems as Insteon is showing to be the weakest link in the chain

my suggestion is to start documenting all details till patterns emerge. some ideas : what type of failures? do they stop operating remotely, locally or both ? Are multiple devices failing at the sametime ? are they the same devices is it random are they all on the same circuit? sub pannel ? power phase ? is it a network access problem? ( eg: a intermediate device failing to relay commands do you have a method to monitor the power quality ? Many UPS have the ability to do this as a feature of their software. I have also found UPSs are the worst offenders, inducing a lot of low voltage noise ( I have all 4 of my home UPSs on filters )

Rainforest Eagle - polling it approx every 5 sec to get the latest demand numbers. Could be written into ISY variables, but had no need for that yet. Also not forwarding the kWh data just yet. I've started on Rainforest Eagle library https://github.com/evilpete/RainEagle it is not as advanced as the ISY library but it exposes the undocumented web API as well as the documented socket based API

take a look ISYlib's internal _read_event() function, the code is ugly and needs to be rewritten but it I might give you some hints https://github.com/evilpete/ISYlib-python/blob/dev/ISY/IsyClass.py#L409

what are you using to monitor your current home energy usage / amps ? As for Insteon reliability, I have 25 to 30 Insteon device is installed and I think the last year and a half of only seeing one device crash ( lockup ). while it is not supported directly by the protocol it is possible to ping and count the retransmission / hops between the PLM and th Insteon node. Sadly this feature is not offered by the ISY (yet) if you have any patches or enhancements for ISYlib please send them along BTW : it would not be that hard to modify my python library to monitor / control multiple ISY devices

if you have a program or app that is to take actions based to current events, you don't want it reacting events that happened hours previous or days previous. A simple example might be an action that happens WHEN a door is opened , as opposed to IF a door opened

... and unfortunately there's no marker, separating the "current state" blast from the following stream of live events

have you looked http://www.universal-devices.com/isy-developers/ download & look at the Rest API docs

the MAC addr. must be both formatted with a dash "-" and must be all upper case. 00-01-55-12-2E-AC : Good 00-01-55-12-2e-ac : Bad 00:01:55:12:2E:AC : Bad 00:01:55:12:2e:ac : Bad 00 015512 2E AC : Bad

I guess I was wondering if I should be concerned about "spikes" from the transformer ( etc )

for Irrigation most people seems to use an IO-Linc or EZFlora For a single zone system, Is there any reason a On/Off module such as a switch Linc (or 2443-222 Micro On/Off Module or InLineLinc Relay ) be wired to toggle power to the 24V Irrigation power supply. The reason I am asking this is cause all I need control is a single zone sprinkler system and the above configuration is cheaper and will fit into a double gang box

If I were you I would wait for integrated support from universal-devices ( unless you also plan to use Z-wave ). What model do you have, RainForest & Bidgely sell the same unit, the only difference I can detect is that the web GUI from Bidgely does not have the option for connecting to custom "uploaders" ( servers ), although you can still do this from the API. Unfortunately the Eagle does not support "uploading" to multiple servers. Thus if you want to continue to use the Bidgely web service a man-in-the-middle style proxy operating as a simple data aggregator may be the best sort term solution. this is easily set up by Using the GUI to configure Bidgely as the upload destination then using the API call get_uploaders() changing the uploader_hostname value to a local IP and then setting the change with set_uploader() Their API is documented here http://rainforestautomation.com/sites/default/files/docs/eagle_uploader_api_03.pdf But as I said before, I would wait for integrated support from universal-devices ( unless you also plan to use Z-wave ).

I was upgraded to 2.0.21 a week or so go after I reported dropped socket connections when I tried to acquiring history use data. My code is still a work in progress, I just added a bunch more api calls from the under documented ajax call api. I guess I'll should add Check & warning for firmware version

thanks for the feed back you need to upgrade your firmware, go to http://support.rainforestautomation.com/ and issue a ticket to get upgraded, include the "cloud id" for your device, it is printed on the bottom of the device.