evilpete

Yeah, now that i understand what is going on more that's what I've thinking about with a few translation table based on protocol number... I was trying to use it as it at first not realizing it was special case mostly for Tasmota integrations

@sjenkins thanks I'll probably have to write a plug-in that interprets the output of rtl-433. it's written in C and the code focuses on SDR protocol decoding thus the input format is not gonna change (I contributed to code base a few years ago) after looking around they have some example code that does something similar for another product. Side Note: once done it will be trivial to incorporate pre-existing devices as input sensors Tire pressure: {"time" : "2025-08-04 18:22:45", "protocol" : 186, "model" : "Hyundai-VDO", "type" : "TPMS", "id" : "5173f60b", "state" : 48, "flags" : 8, "repeat" : 1, "pressure_kPa" : 248.875, "temperature_C" : 25.000, "maybe_battery" : 1, "mic" : "CRC"} Home security sensors (admittedly the neighbors') {"time" : "2025-06-30 22:14:47", "model" : "Interlogix-Security", "subtype" : "unknown", "id" : "51a4c2", "battery_ok" : 0, "switch1" : "CLOSED", "switch2" : "CLOSED", "switch3" : "OPEN", "switch4" : "CLOSED", "switch5" : "CLOSED", "raw_message" : "d24000"} Efergy home energy meter (also the neighbors', but hey, it's good for development input data) {"time" : "2025-07-31 19:01:36", "protocol" : 100, "model" : "Efergy-e2CT", "id" : 16386, "battery_ok" : 0, "current" : 18.781, "interval" : 6} Rolling code Keyfobs {"time" : "@0.843604s", "protocol" : 164, "model" : "Secplus-v2", "id" : 1959100928, "button_id" : 16, "remote_id" : 1959100928, "fixed" : "70678577664", "rolling" : "240124739"} Motion sensors {time" : "2024-09-27 19:28:26", "model" : "Skylink motion sensor", "motion" : "true", "id" : "1e3e8", "raw" : "be3e8"}

Thanks I'll do more studying.. I found a few filters that grok the json and publish the filtered results.

I am trying to feed data from my outdoor temperature sensor (LaCrosse-TX141Bv3). I'm receiving the data using an SDR dongle and passing it via mqtt. The data I'm sending to MQTT: {"time" : "2025-08-07 13:39:10", "protocol" : 73, "model" : "LaCrosse-TX141Bv3", "id" : 237, "channel" : 1, "battery_ok" : 1, "temperature_C" : 20.800, "test" : "No"} This is the json output from rtl_433 My devfile: devices: - id: "TX141Bv1" sensor_id: "temperature_C" type: "Temp" name: "Temperature" status_topic: "rtl_433/LaCrosse-TX141Bv3/temperature_C" cmd_topic: "rtl_433/LaCrosse-TX141Bv3/power" - id: "TX141Bv2" sensor_id: "battery_ok" type: "raw" name: "Battery" status_topic: "rtl_433/LaCrosse-TX141Bv3/battery_ok" cmd_topic: "rtl_433/LaCrosse-TX141Bv3/power" - id: "TX141Bv4" sensor_id: "test" type: "flag" name: "testFlag" status_topic: "rtl_433/LaCrosse-TX141Bv3/test" cmd_topic: "rtl_433/LaCrosse-TX141Bv3/power" MQTT Explorer reports: . But Im seeing . any suggestions? I'm guessing I am misinterpreting fieldnames?

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.