evilpete

that was exactly what I was thinking, there is plenty of room. as I said above, I have had zero failures of insteon devices ( not counting the PLM) ever since I installed a main surge protector in my main panel 8 years ago.

@bpwwer in rtl_433/examples there are some example python scripts that take the json messages and publish MQTT messages, is that what you are doing? The only issue i've had with receiving that you need to increase the sample rate to around 1500k or better, or sometimes (depending on the signal) use the other FSK pulse detector ( -Y classic or -Y minmax ). i have found it useful for occasional debugging by looking at the hops count field and / or packet duplication, If I do not see at least one duplicate I can assume there are connectivity issues as insteon has no routing thus you should see multiple packets via different paths I'm cleaning up my insteonrf stuff to use rtl_443 instead of my sucky home brew FSK demodulator as well as cleaning up the python. There is already code to transmit and receive Insteon packets with the CC1111 platform using the rfcat library with a Yardstick One or cc1111emk868 usb dongle. (I can also do it with a hackrf but that is more complicated)

I agree I'm better off with a new one (Amazon promises delivery by next week. by the 17th) II may install a MOV for surge protection in the new unit, I figure i can attach it via the screws on the inside in the plug (no soldering)

the Insteon 2448A7 Portable USB Adapter may be a good work around.. As for discontinued PLMs maybe their plan is to force people to use SmartHome branded Hubs? how fast is the Insteon market shrinking ?

@Michel Kohanim They stopped making PLMs?? interesting... with the rtl_433 program, I only contributed the protocol decoding part, the maintainers did all the heaving lifting implementing the demodulators. As for legality, I never signed a non-disclosure and thus was free to reverse engineer it. (https://github.com/merbanan/rtl_433/blob/master/src/devices/insteon.c) regarding making a product, if someone was to do this, i'd suggest building on the CC1111 chip instead of the RTL2832U chipset. With SDR dongles you'll have to do the demodulating of the raw I/Q data (aka the raw RF wave info) in software along with the accompanying CPU overhead (receive only) Where as if you use TI's CC1111 chipset family, the demodulation is done by in the chip, and you and can most likely get it done with cheap aarduino cpu at the a controller ( + you can transmit just as easily ) The or cc1111emk868 or Yardstick One are both based on CC1111 platform and allows simple transmit and receiving on the sub-1 GHz ISM radio bands. ( https://greatscottgadgets.com/yardstickone/ http://www.ti.com/tool/cc1111emk868-915 )

the. rtl_sdr app will do that with the -M level option rtl_433 -f 915M -s 1500k -M level _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2020-11-12 10:04:58 model : Insteon From_Addr : 34F837 To_Addr : 132580 Message_Type: 2 Message_Str: Group Cleanup Direct Message Extended : 0 Hops_Max : 3 Hops_Left : 3 Packet : 4F : 132580 : 34F837 : 13 04 65 Integrity : CRC Payload : 4F80251337F834130465 CMD_Data : 19, 4 Modulation: FSK Freq1 : 914.9 MHz Freq2 : 915.1 MHz RSSI : -0.2 dB SNR : 33.4 dB Noise : -33.7 dB _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ time : 2020-11-12 10:05:00 brand : LaCrosse model : LaCrosse-TX35DTHIT id : 8 Battery : 1 NewBattery: 0 Temperature: 11.2 C Integrity : CRC Modulation: FSK Freq1 : 914.9 MHz Freq2 : 915.1 MHz RSSI : -12.1 dB SNR : 17.7 dB Noise : -29.8 dB (I also picked up my 915MHz LaCrosse outdoor temperature sensor )

the c7 is a 10uF 35v cap with another 10uF 35v cap soldered to it's leg and a 1mH soldered to the other leg. honestly I am tempted to just order a new one given the corrosion (with fingerprint) on the back and the shit-show of hanging parts on the front. I'll try to replace what I can without touching the hanging parts crap. but the corrosion is another story ------------------ Update: the repair worked (I hope), although corrosion was bad enough that soldering was difficult enough that I didn't expect it to work I'll do a burn in overnight, if it fails, I'll just buy a new one.. BTW: I have had practically zero failures of insteon devices ever since I installed a home surge protector in my main panel 8 years ago (Intermatic IG3240RC3 Surge Protective Device https://www.amazon.com/gp/product/B003A3MUJI/ )

If anyone is interested, a few months ago I added the Insteon wireless protocol to the SDR application rtl_433 ( https://github.com/merbanan/rtl_433 ) . For those not familiar, rtl_433 is a Software Defined Radio (SDR) program that supports decoding of hundreds of protocols including wireless weather station sensors, and power meters. X10 (just to name a few) The program compiles on Linux, Mac and windows, and requires a rtl_sdr dongle ( ~$30 on amazon: https://www.amazon.com/s?k=RTL-SDR ). Terminal output using the command : rtl_433 -f 915M -s 1500k time : 2020-11-11 14:33:17 model : Insteon From_Addr : 110103 To_Addr : 34F837 Message_Type: 6 Message_Str: Group Broadcast Message Extended : 0 Hops_Max : 3 Hops_Left : 3 Packet: CF : 34F837 : 110103 : 06 01 E0 Integrity : CRC Payload : CF37F8340301110601E0 CMD_Data : 6, 1 Json Output from the command rtl_433 -f 915M -s 1500k -R 159 -F json {"time" : "2020-11-11 14:36:11", "model" : "Insteon", "from_id" : "34F837", "to_id" : "132580", "msg_type" : 2, "msg_str" : "Group Cleanup Direct Message", "extended" : 0, "hopsmax" : 3, "hopsleft" : 3, "formatted" : "4F : 132580 : 34F837 : 11 02 C1", "mic" : "CRC", "payload" : "4F80251337F8341102C1", "cmd_dat" : [17, 2]} {"time" : "2020-11-11 14:36:12", "model" : "Insteon", "from_id" : "110102", "to_id" : "34F837", "msg_type" : 6, "msg_str" : "Group Broadcast Message", "extended" : 0, "hopsmax" : 3, "hopsleft" : 3, "formatted" : "CF : 34F837 : 110102 : 06 01 D1", "mic" : "CRC", "payload" : "CF37F8340201110601D1", "cmd_dat" : [6, 1]}

So my 2nd PowerLinc just died, the first one lasted 3 year the 2nd one lasted a little over 7.. I've already ordered the parts (to be delivered today) when I took it apart I was a little surprised at the "creative" wiring (see attached photo). There was also a serious smudge ( with a fingerprint ) of something slightly corrosive on the back of the board (again see photo) I'll report back later replacing the caps brings it back to life

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.