Serial wired remote

I had intentions of tying into the wired remote for an older adjustable bed to add control functions in home assistant. I have an esp32 and a separate switch relay control that I was going to use. It sounded easy enough until I cracked open the wired remote and found a serial communication between it and the control box.

I searched around for schematics on the control or the remote and didn’t find anything. I did however find the control box has a port for a cable to connect 2 beds together. I assume it will use the same serial communication that the wired remote uses.

Inside the remote, I have the RX, TX, ground, 5V, and USB. It has a USB port in the end of it for charging your phone.

If I connect the TX on the remote to the RX of the esp32 along with 5v and ground, what do I need to use in esphome and home assistant to read what the remote is sending to the control box when each button is pushed? If I can read and log this info, I hope I can transmit the same info to the control from the other port to do what I want.

Forget HA for a while, esphome logs is all you need here. You can use uart debug with dummy_receiver for that but you need to find uart parameters first. Guessing and trying… Also you need level shifting if uart is 5V.

Post a good photo of the remote.

ps. another approach would be connect to button contacts

Thanks! The other side of the remote is just buttons and leds.

I have been reading a lot of the esphome documentation. Now I know what to search for and read.

Thanks,
Wayne

I obviously don’t understand all the code behind it. Here is what I came up with. I loaded it to the ESP32 and booted it. I connected to it through the browser and ESPHome Web. It gives me basic bootup logs, so it did load and boot. I probably won’t get a chance to test it on the remote until sometime this weekend. Is this going to log what I want, or am I way off?

esphome:
  name: logger
  friendly_name: logger

esp32:
  board: nodemcu-32s 
  
uart:
  baud_rate: 9600
  tx_pin: GPIO1
  rx_pin: GPIO3
  #optional
  data_bits: 8
  parity: NONE
  stop_bits: 1

  debug:
    direction: BOTH
    dummy_receiver: TRUE
    after:
      delimiter: "\n"
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

I am also looking at the level shift to keep 5V communication from frying the 3.3V ESP32.

Thanks again for the help.

Don’t use default uart pins for this. Use 16/17 for example.

You could also copy the baudrate select example from the page i linked, so you don’t have to compile/upload every time you try new one.

You can use just simple resistor voltage divider for level shift.

I finally got some time to mess with this. I used the esp32 and just wires to ground and the tx of the remote to the rx of the esp32. Pin 16

This is the code I used.

logger:
   level: VERBOSE
   baud_rate: 0 # Disable logging to console

uart:
  rx_pin:
    number: GPIO16
    inverted: false
    mode:
      input: true
      pullup: false
      pulldown: false
  baud_rate: 2400
  debug:
    direction: RX
    dummy_receiver: true
    after:
      timeout: 3ms
    sequence:
      - lambda: UARTDebug::log_hex(direction, bytes, ' ');

I got hex logs back from it with almost all baud rate settings. I didn’t have the resistors I needed on hand to convert the 5v to 3.3v. Using a meter I was getting a solid 5V while idle and it would pull down to about 2.6v while communicating. I think I will be able to get some info worth looking at once my logic level converter comes in.

Thanks for the help. I will post back when I have more info to share.

Correct, meter reads rapid high/low pulses as average.
You don’t need any specific resistor values as long as they make about 1:2 divider and stay in low kΩ range.
1.8k/3.3k or 4k7/10k for example

I have it wired up with the logic level converter. Just RX and ground for now to try to figure out the communication.

I am using this code right now.

# Enable logging
logger:
   level: VERBOSE
   baud_rate: 0 # Disable logging to console


uart:
  rx_pin:
    number: GPIO16
    inverted: false
    mode:
      input: true
      pullup: false
      pulldown: false
  baud_rate: 1200
  #data_bits: 8
  #parity: NONE
  #stop_bits: 1
  debug:
    direction: RX
    dummy_receiver: true
    after:
      timeout: 3ms
    sequence:
      - lambda: UARTDebug::log_string(direction, bytes);

This has given me what makes more sense. I think I need to go a little slower maybe. It seems like I am getting some noise. Basically I am seeing repeated “1’s”, “2’s”, “3’s”, “4’s”, and “5’s” for head up, head down, foot up, foot down, and flat respectively.

I think my next step is to search what all the common slow uart speeds are so I can try them. Anything above 1200 gave me all hex and nothing really repeatable. The faster I got, it would just log constant “FF’s” without pushing any buttons.

[17:34:29.213][D][uart_debug:157]: <<< "11"
[17:34:29.242][D][uart_debug:157]: <<< "111"
[17:34:29.272][D][uart_debug:157]: <<< "1111"
[17:34:29.302][D][uart_debug:157]: <<< "111"
[17:34:29.336][D][uart_debug:157]: <<< "1111"
[17:34:29.362][D][uart_debug:157]: <<< "1111"
[17:34:29.392][D][uart_debug:157]: <<< "111"
[17:34:29.422][D][uart_debug:157]: <<< "1111"
[17:34:29.452][D][uart_debug:157]: <<< "111"
[17:34:29.482][D][uart_debug:157]: <<< "1111"
[17:34:29.514][D][uart_debug:157]: <<< "1111"

[17:36:00.266][D][uart_debug:157]: <<< "22"
[17:36:00.294][D][uart_debug:157]: <<< "2222"
[17:36:00.323][D][uart_debug:157]: <<< "222"
[17:36:00.354][D][uart_debug:157]: <<< "2222"
[17:36:00.385][D][uart_debug:157]: <<< "2222"
[17:36:00.414][D][uart_debug:157]: <<< "222"
[17:36:00.573][D][uart_debug:157]: <<< "\xFE"
[17:36:00.601][D][uart_debug:157]: <<< "\xFC\xF8"
[17:36:00.631][D][uart_debug:157]: <<< "\xF8\xF0"
[17:36:00.662][D][uart_debug:157]: <<< "\xF0\xF0"
[17:36:00.693][D][uart_debug:157]: <<< "\xE0\xE0"
[17:36:00.722][D][uart_debug:157]: <<< "\xE0"
[17:36:00.756][D][uart_debug:157]: <<< "\xE0\xC0"
[17:36:00.784][D][uart_debug:157]: <<< "\xC0\xC0"
[17:36:00.814][D][uart_debug:157]: <<< "\xC0\xC0"
[17:36:00.845][D][uart_debug:157]: <<< "\x80\x80"
[17:36:00.881][D][uart_debug:157]: <<< "\x80\x80"
[17:36:00.906][D][uart_debug:157]: <<< "\x00"
[17:36:00.936][D][uart_debug:157]: <<< "\x00\x00"
[17:36:00.966][D][uart_debug:157]: <<< "\x00\x00"
[17:36:00.998][D][uart_debug:157]: <<< "\x00\x00"
[17:36:01.028][D][uart_debug:157]: <<< "\x00\x00"
[17:36:01.059][D][uart_debug:157]: <<< "\x00\x00"
[17:36:01.089][D][uart_debug:157]: <<< "\x00"
[17:36:01.119][D][uart_debug:157]: <<< "\x00\x00"
[17:36:01.149][D][uart_debug:157]: <<< "\x00\x00"
[17:36:01.180][D][uart_debug:157]: <<< "\x00"

[17:37:47.751][D][uart_debug:157]: <<< "33"
[17:37:47.807][D][uart_debug:157]: <<< "333"
[17:37:47.812][D][uart_debug:157]: <<< "3333"
[17:37:47.841][D][uart_debug:157]: <<< "3333"
[17:37:47.871][D][uart_debug:157]: <<< "333"
[17:37:47.900][D][uart_debug:157]: <<< "3333"
[17:37:47.931][D][uart_debug:157]: <<< "3333"
[17:37:47.961][D][uart_debug:157]: <<< "33"
[17:37:48.028][D][uart_debug:157]: <<< "\xFE\xFC"
[17:37:48.058][D][uart_debug:157]: <<< "\xFC"
[17:37:48.094][D][uart_debug:157]: <<< "\xF8\xF8"
[17:37:48.119][D][uart_debug:157]: <<< "\xF8\xF0"
[17:37:48.150][D][uart_debug:157]: <<< "\xF0\xF0"
[17:37:48.180][D][uart_debug:157]: <<< "\xE0\xE0"
[17:37:48.211][D][uart_debug:157]: <<< "\xE0\xE0"
[17:37:48.242][D][uart_debug:157]: <<< "\xC0\xC0"
[17:37:48.272][D][uart_debug:157]: <<< "\xC0"
[17:37:48.303][D][uart_debug:157]: <<< "\xC0\xC0"
[17:37:48.334][D][uart_debug:157]: <<< "\x80\x80"
[17:37:48.364][D][uart_debug:157]: <<< "\x80\x80"
[17:37:48.395][D][uart_debug:157]: <<< "\x00\x00"
[17:37:48.426][D][uart_debug:157]: <<< "\x00\x00"
[17:37:48.457][D][uart_debug:157]: <<< "\x00"

[17:38:50.616][D][uart_debug:157]: <<< "4"
[17:38:50.632][D][uart_debug:157]: <<< "444"
[17:38:50.660][D][uart_debug:157]: <<< "44"
[17:38:50.660][D][uart_debug:157]: <<< "4"
[17:38:50.675][D][uart_debug:157]: <<< "44"
[17:38:50.705][D][uart_debug:157]: <<< "44"
[17:38:50.705][D][uart_debug:157]: <<< "44"
[17:38:50.720][D][uart_debug:157]: <<< "44"
[17:38:50.750][D][uart_debug:157]: <<< "4"
[17:38:50.750][D][uart_debug:157]: <<< "44"
[17:38:50.767][D][uart_debug:157]: <<< "44"
[17:38:50.944][D][uart_debug:157]: <<< "\xFF"
[17:38:50.973][D][uart_debug:157]: <<< "\xFE"
[17:38:51.003][D][uart_debug:157]: <<< "\xFC\xF8"
[17:38:51.034][D][uart_debug:157]: <<< "\xF8\xF8"
[17:38:51.070][D][uart_debug:157]: <<< "\xF0\xF0"
[17:38:51.096][D][uart_debug:157]: <<< "\xE0\xE0"
[17:38:51.125][D][uart_debug:157]: <<< "\xE0"
[17:38:51.155][D][uart_debug:157]: <<< "\xE0\xC0"
[17:38:51.186][D][uart_debug:157]: <<< "\xC0\xC0"
[17:38:51.216][D][uart_debug:157]: <<< "\xC0\xC0"
[17:38:51.246][D][uart_debug:157]: <<< "\x80\x80"
[17:38:51.278][D][uart_debug:157]: <<< "\x80\x80"
[17:38:51.307][D][uart_debug:157]: <<< "\x00"
[17:38:51.339][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.370][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.401][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.432][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.462][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.494][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.524][D][uart_debug:157]: <<< "\x00"
[17:38:51.555][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.586][D][uart_debug:157]: <<< "\x00\x00"
[17:38:51.616][D][uart_debug:157]: <<< "\x00"

[17:40:03.545][D][uart_debug:157]: <<< "5"
[17:40:03.574][D][uart_debug:157]: <<< "5555"
[17:40:03.604][D][uart_debug:157]: <<< "555"
[17:40:03.635][D][uart_debug:157]: <<< "5555"
[17:40:03.665][D][uart_debug:157]: <<< "5555"
[17:40:03.695][D][uart_debug:157]: <<< "555"
[17:40:03.726][D][uart_debug:157]: <<< "5555"
[17:40:03.755][D][uart_debug:157]: <<< "5"
[17:40:03.803][D][uart_debug:157]: <<< "\xFE"
[17:40:03.833][D][uart_debug:157]: <<< "\xFC\xFC"
[17:40:03.863][D][uart_debug:157]: <<< "\xF8\xF0"
[17:40:03.894][D][uart_debug:157]: <<< "\xF0\xF0"
[17:40:03.925][D][uart_debug:157]: <<< "\xE0"
[17:40:03.955][D][uart_debug:157]: <<< "\xE0\xE0"
[17:40:03.987][D][uart_debug:157]: <<< "\xE0\xC0"
[17:40:04.017][D][uart_debug:157]: <<< "\xC0\xC0"
[17:40:04.047][D][uart_debug:157]: <<< "\xC0\xC0"
[17:40:04.081][D][uart_debug:157]: <<< "\xC0\x80"
[17:40:04.109][D][uart_debug:157]: <<< "\x80\x80"
[17:40:04.141][D][uart_debug:157]: <<< "\x80"
[17:40:04.170][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.202][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.232][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.263][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.344][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.344][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.354][D][uart_debug:157]: <<< "\x00"
[17:40:04.388][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.416][D][uart_debug:157]: <<< "\x00\x00"
[17:40:04.446][D][uart_debug:157]: <<< "\x00"

If only that picture of the main chip was a little clearer so we could see the part number…
Where and what does USB pin go to? Data or just power?
Make and model of devices would assist in sleuthing. Bed, remote, any FCC ID on optional wireless controllers, etc.
Is JP1 useful?
The data may be in ASK or OOK format as well, common on old beds, combined with wireless 433mHz or Infrared.

The chip has PIC16F1828-1/SS and 1442RB4.

The remote has “MottoSleep” on it, but no other identification. USB seems to only go to the end of the remote where it is a power port for charging your phone.

Motomotion XSF series XSF200W matches it.

Is it a PIC1823-1? Often the stamps are not clear. I note in the specs for that chip it supports autobaud, so will probably happily chat with your interface at any common speeds.

Can you please post a pic of the front of the remote too? Trying to track down a non-wireless one is hard without a bit more information.

Actually it is a PIC16F1828-I/SS.

That “Sync Cord” connector on the control box the remote plugs into looks very interesting too.
Wonder what’s in that control box? Game to open and post pictures?

Hook up both the TX and Rx (don’t forget Tx to Rx and Rx to Tx) so the PIC chip can decide what baud rate to settle on. Send it a and see what happens. Send a <1> and see what happens.

Maybe a USB TTL to serial (5v) adapter, connected to your computer in a terminal program could have been an easier setup to play with for early decoding purposes, if you had one lying around for programming purposes.

You’ve only got 5 buttons to decode, so looking for the bits that are the same and the bits that are different, and then consistently replicating them is your end goal. Interfacing the ESP32 to external control, whether by WiFi or bluetooth is going to be the bonus.

On closer examination of the photo, looks like the Tx and Rx pins are linked via two resistors [R2 and R3, both 10K ohmd] for pullup/pulldown.

The sync cord was to be my way in once I could figure out exactly what the remote was sending. I don’t have a sync cord, but I was going to order one or open the control box and solder to the wires I needed.

If it is in auto baud mode, I guess I could try to send a command and see what happens. I assume a series of 1’s would raise the head. I would just need to swap my wire to the tx pin of the ESP32. However, the device I would be sending this to may not be the same chip. I was trying to mimic this chip which is in the remote.

Getting to the control box is going to be a weekend job. It is under the center of two beds bolted together.

Ask me why I’m commiserating with you…
Heavy is an understatement.

On the control box there may be press button switches for up and down which you may be able to tap into from your ESP32 also via the level converter. The sync cable may be I2C or TTL level serial protocol.

1 Like

This would explain the meter behavior when I pressed buttons. Both tx and rx were being pulled down.

Curious if the top of R2 and R3 [both 10k] are going directly to +5v or GND? Pullup or pull down? Disconnect controller and check with ohms setting. You may be able to cheat with the voltage converter and replace it with a resistor.
Are the USB pins for the data connected on the end as well, or just the power ones? Maybe they could they form part of an external wireless controller adapter where you plug in the ESP32 as a dongle for a neat finish? This would be where closely examining the main controller board to see what voltage regulator is there and whether it has enough oomph for powering the ESP32 as well
The bed controller 24volt power supplies are usually generously rated for different actuators. The stepdown regulator may have enough grunt to support the extra 500mA or so the ESP32 needs. The PIC sips very little power, however the LEDs can add up, and just swapping the remote for the ESP32 may be possible.
What is the connector for the cable between the remote and the control box? Something common? The sync cable? Same type?

If you get consistent 1,2,3,4,5 for your button presses, I think you are all good. Baudrate is more likely correct than incorrect, some small mismatch at most. The tail is not part of any protocol, just some “collapse” when you release button. If you convert those hex in binary it looks like this:
11111110
11111100
11111000
11110000
11100000
11000000
10000000
00000000

If you go back to HEX-logging (not string), power the remote, wait few seconds and press the button briefly, what you get on logs?

The question is, does bed normally send something to remote which remote replies or not…

1 Like

The sync cable end and the remote cable end are going to be the same. It is a round 6 pin connector. I dont have an image of the back side of the board at the moment, but there is a trace from each pin of the remote connector straight to the sync connector with no electronic components interrupting the traces.

I did log with hex, but all I have of it is snapshots at the moment.

Basically the head up button outputs a series of 1’s on the string log. In HEX mode “8A” over and over. Never more than 4 to a line. After those, it logs FE F0 C0 80 00 00 00.

Head Down logs a series of “26” followed by E6 E0 80 00 00 00

I tried to do this attached to a button:

- uart.write: [0x8A, 0x8A, 0x8A, 0x8A, 0x8A, 0x8A, 0x8A]

No activity from the control.

ESPhome Logs showed it sent it.

I unhooked everything and then connected a second ESP32 to the first one. TX to RX and RX to TX. Both set to the same baud rate. I monitored incoming data on the second one. Before I could hit the button to tansmit on the first one, HEX data was flooding the second one. It is mainly F0 and FF. At this point I just stopped to research more.

Looking at this image, I see a lot easier of an option. I can use the ESP32 to trigger the relays on the control board. I need to study the board and the relays to see what type of voltage it uses as a trigger, but this is doable.