My only problem with reusing the old switches is they do not show the actual state of the light. They basically feel like having a three-way stairwell setup on every switch that’s been automated. And in fact one of my target lights is in a stairwell. (just realized that as I was typing)
Honestly, I might end up reusing the old switches, if for no other reason than cost. $40+ for each light is a bit steep.
I am finding a lot of “off-brand” BLE buttons that look like US-standard wall switches. But I have not been able to determine whether BLE sensors and buttons emit a standard payload or pairing model that can be used with any receiver.
My assumption is that they are all proprietary, because heaven forbid a company make something that is interoperable with any other company’s products?
Are these things standard? Or do I have to stick with same brand BLE device and receiver device.?
Yes and no.
Any ble device can print (almost) whatever it wants. There’s no standard for that. It can be advertisement or communication that needs connection.
Hmph. Doesn’t look like PVVX does any kind of button. Just thermo/hygro devices.
I’m considering a hack on the Shelly BLU Door/Window sensor to replace the reed switch with wires to a wall-style switch. This will allow me to put switches where there aren’t already switches. But I need to find a surface mount dumb switch that looks nice. And I’m trying to keep the switch half of the solution below $20. I have a lot of these to do.
I love the idea of a BT relay though for the actual door/window sensors I want to install. I already automated my HVAC (mini-splits) a few years ago, and the next phase of that is detecting open windows and doors, so I can shut off HVAC if someone opens a window, such as my brother, who thinks it’s a good idea to let in some “fresh air” in the middle of a 110F summer day. I have a bunch of Seeed Studio ESP32-C6 boards that would love the chance at this.
OK, I’ve decided to take a budget/DIY approach first. A challenge to see if I can make what I need from things I already have.
I have three of these already: Amazon.com (one of the reviews shows a picture of the buttons installed inside an actual Decora switch plate, which is EXACTLY what I want: Amazon customer review pic)
And it took me all of an hour to identify all the connections I’d need to make with some ESP32-C6 boards I already have. So here’s my plan:
I found the datasheet for the wireless receiver/decoder which feeds whatever data it decodes out a pin that is connected to the unidentified micro controller. (chip markings have been removed) That will be how I inject the on/off command from the ESP32. I also found the line that sets the relay, so I can monitor state from that. Or from the LED, which is on its own pin.
Next steps are to attach some wires and measure voltages when live, without killing myself. And then try to record the command data between the receiver and uC. I’m really hoping it’s not a rolling code. Not sure how I would mimic that with the ESP.
Not sure whether documenting my hack is still on-topic or in the right forum. But I’ll at least offer quick updates in case anyone is interested.
I’m currently using 433MHz buttons to control lights in my garage. But the round trip delay time is much too annoying at around 1-2 seconds between button push and the lights turning on. It’s long enough that I’ve already tripped on something in the middle of the room.
Interesting. OK, I’ll have to look further. I have not found any outlet or smart plug that can receive a 433MHz signal. Everything is either BT, Z-Wave or WiFi. I’ll recheck the specs on the ESP32-C6s I have to see if they have the hardware for it. That would make my day!
At the moment, anything DIY must come from what I already have in my garage. Buying parts adds up more quickly than just buying pre-made things. (this is 50% empirical and 50% my own buying habits)
It took me about an hour to identify the parts. The 433Mhz receiver is a CMT2210LC, which decodes the message and sends the payload as serial data (I2C maybe?) to a pin on the uC. The uC has had its silk screen removed. So I can’t identify it. But I don’t really need to. My approach will be to simply record the data that comes from the receiver chip and just replay that from the ESP32.
Pads of interest:
V - VCC, which I have determined to be 3.3V. I am able to power up the logic directly through this pad without plugging the outlet into the wall. (WOOT!)
DATA - The data coming from the 433MHz receiver to the uC.
C - Control; the pin which controls the relay. I will be monitoring this pin with the ESP32 to track the state of the device. I will not be controlling the relay with the ESP32.
D - LED. I can read the relay state here instead of from C if necessary.
G - Ground, which is at 120VAC when the device is plugged in. Causes loss of blue smoke if connected to something like a laptop over USB serial device when the device is plugged into the wall. This is why I’m so happy I can power the device directly.
I thought it was interesting that the relay has a 24VDC coil, when the logic is 3.3VDC. That means there is a pretty complex power supply for the control circuit. I didn’t try very hard, but I was not able to fully identify how that works. It uses a full-wave rectifier. But I can’t determine how the voltage is stepped down from 120V.
I had to order a logic analyzer so I can figure out what data is being sent by the 433MHz transmitter, which broke my “only what’s in the garage” idea. But I’ve wanted one for a long time and just never bought one, so…
I’m hoping the transmitter is not sending a rolling code. I’m not sure I will be able to complete the hack if that’s the case. I connected my oscilloscope to the data line and discovered it’s frequently sending data, even without the transmitter sending anything, which has me a bit worried. Once I can analyze the data, it should be easy to figure out. (My hope is all that other data is from other 433MHz transmitters in my house, and the uC is just ignoring it.)
I have several of these ESP32-C6 boards laying around that I bought for about $1.50 each before tariffs hit. I’ll be loading up either ESPHome or Tasmota on this, depending on which turns out easier to work with.
Got my logic analyzer and started poking around. Spent a few days so far trying to figure out the data signal between the receiver chip and the uC. The logic analyzer gave me data I am having a hard time deciphering due to the noise of all the other 433MHz devices in my house. But it gave enough info that I was able to determine the timings of the data stream. This allowed me to set up rtl_433 with suitable parameters to sniff the wireless signal and get consistent data from that.
I’m pretty sure it’s not a rolling code. (Phwew!) Looks static in the rtl_433 data.
So, I believe I have figured out the transmitter data. But I haven’t figured out how to send that data over a wire to the uC in the outlet. The reason this is not straightforward is the software I’m using on the logic analyzer (Saleae Logic2) has no protocol extension that will properly decipher the wired data stream. Since it’s able to accurately read the data, I can get good info from it. But programming a uC to send that exact data will be near impossible to replicate without knowing the actual protocol.
This is the rtl_433 command line I’m using to read the transmitters:
All the timing values in the -X “…” section I got from the logic analyzer output. And I had to determine the modulation through trial and error.
Logic2 stream from when I pressed the “On” button. Take note of marker “4” - that’s when the device turned on the outlet. It is consistently switching at the end of the third data block. (EDIT: as I paste a pic that literally debunks the statement. Oh well.) Based on what I have found so far, it appears the device reacts to the transmitter data after two clean data blocks, meaning RF noise and other 433MHz transmitters haven’t polluted or corrupted the data. It shows different data from the SDR data below because it doesn’t recognize the protocol.
And here is what the SDR is capturing, edited for brevity. Each press results in at least 4 packets, and up to something like 100 if you hold the button down. I pressed the on and off button on three transmitters. Note the data value has a consistent pattern in that the On command always ends with “b” and the Off command always ends with “d”. I was hoping that was associated with the button pressed - I.e. b=button 2 and d=button 4, but it’s not. They are buttons 9 and 10, because the transmitter PC board is designed for several models with many different button layouts.
Also found out that this device is made by a company named Jasco (https://byjasco.com/). They seem to be one of the manufacturers that make all the home electrical accessories you find at places like Home Depot or Target.
Next up: Attempt to spoof the wireless data and send it over the wire to the uC and HOPEFULLY get it to switch on and off.
I got into a bit of a distraction hacking the RF signal. HA provides the mechanism for learning and then simply replaying the remote codes. But in the case I’m working on, that doesn’t really help me reach my goal. And in the past, when I was setting up my HVAC, I have been confounded by how that all works. So I have delved into the inner workings of these base64 encoded strings that are stored by HA when learning codes and referenced when sending them.
That being said, here are some things I have had great success with:
Flashed Tasmota onto an ESP-01S and connected it to the RF data line on the outlet.
A. Tasmota instantly recognized the data and it matched what I had measured in other places. (I had flipped bits from my early experimentation, and Tasmota cleared up that issue.)
B. I was able to proxy the transmitter code through the ESP and back to the outlet’s MCU. So, I will be interrupting that connection to insert the ESP.
C. I was able to forward the transmitter data to MQTT, which allowed some experimentation, which resulted in the best part:
The 433MHz signal via Tasmota operates my garage lights WITHOUT A NOTICEABLE DELAY. Holy smokes!
This discovery has caused me to reconsider some things about this project, and see if my goals are reachable with slightly different approach. If I abandon trying to make dumb outlets smart, I will lose the ability to know when a light is on or off in HA, unless I also add a smart outlet. It might be worth the tradeoff in effort (now that I’ve already carved out the case on one of my GE outlets to make room for more circuitry… oh well).
Tasmota impressing me with its ease of use and strong RF capabilities. This image shows on and off actions, and forwarding that same code out to another connected device.
I also found functionality in the rtl_433 tool that converts sampled RF data into “ook” files, which are editable. I have reason to believe the ook files can be used as a source for the encoded data needed in HA for remotes.
And I’ve been reading up on how HA handles learned remote codes and stores them, so that I can dynamically create them instead of recording them and storing a black-box value.
I’ve connected an ESP-01S (ESP8266) board to the outlet, that’s been flashed with the tasmota-sensors image. It’s receiving the data from the outlet’s RF demodulator, and when it’s the correct code, it’s forwarding the data to the outlet’s MCU. I removed a zero-ohm resistor (JR3) to allow intercepting the rf demod data stream. White wire sends rf demod data to ESP. Green wire receives proxied rf data from ESP into outlet’s MCU.
I have successfully confirmed the transmitter data (actually a while ago) and taken that data, wrapped the HA header bits, etc. around it, converted the pulses to long and short values, and base64 encoded all that together. Then placed the b64 string into HA Developer Tools and sent it using the remote.send_command function. Saw the light blink and that’s all I need!