I 100%+ plus agree. I myself will not take this path.
If your current controller is a Modbus (is this ESP32 DIY or something else?) it will be reletively easy to add a Mode Button press simulation and use a feedback from Mode State LEDs.
You may need just only 2 status signals from whichever Modes are used.
For modbus, I'm using waveshare esp32-s3-relay-1ch with esphome.
I've actually just gotten the mode register read working, so now I know what the mode is after a button press. But there is some polling delay.
Which modbus commands can do mode button press simulation and mode state LED feedback? I only know the commands from AutoSlide-ATM2-Modbus-Protocols.pdf.
Thounds good!
So, feedback for current Mode Status is there. There is no need to messup with checking LED States. Polling delay should not be a problem.My ggod gess, Mode Change will be used only few timea s day.
Unfortunately there is no shuch thing. You will need to add wires across Mode Select Button and use an Optocoupler (my primary choice) or Relay for simulating Button Press. How to control this Optocouple or Relay is a different story. I have no idea what is "waveshare esp32-s3-relay-1ch" and what its capability. If you want to, I can share my Hubduino Modbus Controller sketch for the ESP32 (any ESP32 development board should be OK and you will need a RS485 Tranceiver module). You will need to add a "Mode Status" read function and a control for Optocoupler/Relay (basically the same thing, simple On/Off Switch). This has a direct integration with HE.
Thank you for the advice. esp32-s3-relay-1ch has an rs485 interface, and a relay. I've just soldered the relay to the mode switch button, and configured esphome to read the mode register value and press the button the needed number of times for certain modes.
I am happy to hear you got a solid reliable solution.
Did anyone find a solution for the 3.9B board? I am currently using a dedicated iPad to run pushcut app as the bridge between home assistant and the iOS autoslide shortcuts to change modes. However it is super unreliable and I would prefer a way for home assistant to communicate directly to the autoslide board to change modes. If anyone has suggestions I would appreciate it!
MODBUS Mode for the Autoslide Controller 3.9B is broken. However you can use "Button Simulation" local control. Controller Board (all versions) has a connectors for connecting external buttons/sensors. All what you need - is a Relay Board (one relay per each button/sensor) which could be controlled by HE. Before switching to MODBUS Control I used 2 relays. One for open/close and second for partially open. You will also need a separate Door Status Sensor. This was working lust fine. The reason I awitched to MODBUS is - single controller does all the job (control and status).
Home Assistant + ESPHome project — testing ATM3.4B Modbus first, relay/button simulation as fallback
Hi everyone — I’ve been reading through this entire thread and it has been incredibly helpful. I’m finally ready to experiment with my own AutoSlide, and I thought my particular board revision and some of the ridiculous workarounds I’ve already tried might make the results useful to others here as well.
My AutoSlide hardware
I opened my AutoSlide and confirmed:
Main PCB: AUTOSLIDE AS8 Rev P — April 2021
Module: ATM3.4B
It’s the blue PCB with the RS485 connector in the upper-right and the external sensor/button connections along the right side.
I had previously been under the impression that I needed AutoSlide’s older red PCB to get proper Modbus control. I contacted AutoSlide about purchasing one, but their support AI told me something interesting:
“The newer PCB uses the #6 DIP switch to choose between MODBUS control and Bluetooth app control. When that switch is left off, it is set to MODBUS control.”
I’m waiting for a human at AutoSlide to confirm whether my exact AS8 Rev P / ATM3.4B combination uses the same Modbus protocol/register map as the older documentation.
Given what’s already been discovered in this thread about differences between ATM2, ATM3.2 and ATM3.9B, I’m very curious to find out exactly what ATM3.4B does before replacing anything.
My Home Assistant setup
I have a fairly extensive Home Assistant installation running on a dedicated Intel N100 mini-PC with HA OS, and I’m already heavily using ESPHome.
I also have OpenCode running with direct access to my Home Assistant environment, so it can help create/modify ESPHome configuration, inspect HA entities/configuration and analyze logs. I use ChatGPT alongside it for research, interpreting documentation and troubleshooting.
That should make this a little more systematic than manually firing Modbus frames and watching LEDs.
My intention is to use ESPHome + Home Assistant + OpenCode + ChatGPT as a controlled test environment around the AutoSlide.
I specifically do NOT plan to brute-force arbitrary Modbus registers. I’ll start with the documented registers/values and methodically record:
- command sent
- Modbus response/exception
- register value before/after
- physical AutoSlide mode
- door position/lock status
- whether the requested operation actually occurred
Hopefully this will let me characterize exactly what works and doesn’t work on ATM3.4B.
Hardware I’ve ordered
Rather than buying a plain ESP32 + RS485 adapter, I ordered a:
Waveshare Industrial ESP32-S3 6-Channel Relay Module
It gives me:
- ESP32-S3
- Wi-Fi/Bluetooth
- onboard isolated RS485
- six relay outputs
- ESPHome compatibility
I also ordered an assortment of 2.54 mm XH connectors/sockets with pre-crimped leads, hoping to make the AutoSlide connections completely plug-in/reversible rather than modifying the factory harness.
I deliberately chose the 6-relay Waveshare because the same hardware gives me both of the approaches below.
PLAN A — Native RS485/Modbus control
This is obviously my preferred outcome.
I’ll connect the Waveshare RS485 interface to AutoSlide and initially test only the documented Modbus functions.
According to the protocol document I have, Mode is holding register 40003 / 0x0002:
- 0 = Auto
- 1 = Stacker
- 2 = Lock
- 3 = Pet
The documentation also provides a separate Locked & Position Status register reporting:
- closed/unlocked
- closed/locked
- open
If ATM3.4B implements those properly, ESPHome should theoretically expose something very clean in HA:
Patio Door Mode: Auto / Stacker / Lock / Pet
Patio Door Status: Open / Closed-Unlocked / Closed-Locked
Home Assistant could then explicitly issue “Lock Patio Door” rather than trying to cycle through modes.
My existing Good Night routine, presence automations, dashboards, voice assistant, etc. could all use the same HA entities/scripts.
I’ll have OpenCode help generate and modify the ESPHome YAML and inspect the resulting entities/logs while I physically watch the AutoSlide. I’ll use ChatGPT to compare the results with the protocol documentation and determine the next useful/safe test.
The initial testing will be deliberately conservative: read known registers first, then write only documented values such as Auto and Lock and immediately read the register/status back.
If ATM3.4B has a partial implementation like some of the other ATM3 revisions reported here, hopefully I’ll be able to document exactly where it breaks.
PLAN B — Relay/button simulation
This is why I bought the 6-relay Waveshare instead of the simpler RS485-only version.
If Modbus mode control doesn’t work properly, my fallback is to use the same ESPHome device to simulate AutoSlide’s external sensors/buttons using dry-contact relay closures.
I’m considering dedicating four relays:
Relay 1 → Inside
Relay 2 → Outside
Relay 3 → Pet
Relay 4 → Stacker
That would still leave two relays available for experimentation.
Obviously those four inputs are not equivalent to four discrete mode selections. They’re sensor/button inputs, and their behavior depends upon AutoSlide’s current operating mode.
One particular behavior I’m very interested in testing:
Put AutoSlide into Secure/Locked mode → pulse the Inside input.
The mode chart indicates that Inside remains active in Secure mode while Outside is disabled.
Does an Inside activation while securely locked cause AutoSlide to:
unlock → open → close → relock?
If it does, that could make relay/button simulation surprisingly useful. HA could keep the patio door secure while retaining an authorized local means of opening it.
If necessary, there’s also the hybrid approach discussed in this thread: use whatever Modbus reading still works for status while using relays to simulate physical button/sensor inputs. With six relays available, I should have plenty of room to experiment.
The increasingly ridiculous history of how I got here 
My goal sounds simple: Home Assistant should be able to tell AutoSlide exactly what to do.
Getting there without direct hardware access has been surprisingly complicated.
Attempt #1 — Alexa / Echo
Since AutoSlide supports Alexa voice commands, I first tried to leverage Alexa Media Player from Home Assistant.
The problem is that AutoSlide’s Alexa functionality isn’t exposed to HA as a nice normal lock/door entity that I can simply call.
I even experimented with a fairly absurd workaround: pre-recording my own spoken AutoSlide commands as audio files and having Home Assistant play those recordings through a speaker positioned so an Amazon Echo could hear them.
In other words:
Home Assistant → play prerecorded “Alexa, lock patio door” audio → Echo hears recording → Alexa recognizes command → AutoSlide skill → door
It was basically Home Assistant talking to Alexa by pretending to be a human.
Besides being inelegant, Alexa voice recognition introduces another failure point. Sometimes Alexa may not recognize the recording/voice, which led me down the path of wondering whether HA should replay the recording, listen for Alexa’s failure response, etc. At that point it became obvious I was building a Rube Goldberg machine.
Attempt #2 — Siri Shortcuts
AutoSlide also works through Apple’s ecosystem, so I experimented with Siri/iOS Shortcuts.
The Shortcut itself can issue the AutoSlide command, but getting Home Assistant to reliably initiate an iOS Shortcut remotely is another matter.
Attempt #3 — Pushcut
This one actually works.
I took a spare older iPhone, synchronized its Shortcuts, installed Pushcut, and configured it as a dedicated Pushcut Automation Server.
The chain is now:
Home Assistant → REST command → Pushcut cloud → spare iPhone running Pushcut Automation Server → iOS “Lock Patio Door” Shortcut → AutoSlide
I successfully tested it from Home Assistant and can now call the Pushcut REST command from HA scripts. That means, for example, my Good Night script can request that AutoSlide enter Locked mode.
So I technically have HA → AutoSlide control today.
But the solution requires a spare iPhone sitting permanently at home, powered and running the Pushcut server. It also adds Pushcut, Apple’s Shortcut execution and AutoSlide’s software integration as dependencies between HA and a door controller sitting on my own LAN.
After getting all of that working, discovering that my existing AutoSlide PCB may already have a usable RS485/Modbus interface made me wonder why I’m doing any of this.
The end goal
I want to replace:
HA → cloud/service/phone/Shortcut/AutoSlide
with:
HA → ESPHome → RS485 → AutoSlide
or, if Modbus on ATM3.4B is broken:
HA → ESPHome → local dry-contact relays → AutoSlide
Ultimately I’d like completely local Home Assistant control of:
- Open
- Close
- Auto
- Secure/Lock
- Pet/partial opening
- actual open/closed/locked feedback
Ideally Plan A gives me all of that elegantly through Modbus.
If ATM3.4B’s Modbus implementation is broken or incomplete, Plan B uses the exact same ESP32 and its onboard relays for local button simulation.
Only if neither is satisfactory would I replace this controller with an older ATM2/red PCB known to have better Modbus support.
Questions for those who have already gone down this rabbit hole
1. Has anyone specifically tested an ATM3.4B / AS8 Rev P (April 2021) combination?
2. Does the older ATM2 Modbus register map apply to ATM3.4B, or should I expect differences?
3. Is DIP #6 OFF definitely the correct configuration for RS485/Modbus on this revision?
4. Any reason the onboard isolated RS485 on the Waveshare ESP32-S3 shouldn’t work directly with the AutoSlide RS485 interface?
5. For relay/button simulation, are Inside / Outside / Pet / Stacker the four most useful inputs to expose to HA?
6. Has anyone tested Inside activation while in Secure mode? Does it unlock/open and subsequently relock?
7. Are there any other known-safe registers/commands you’d particularly like me to test on ATM3.4B?
Once the Waveshare arrives, I’m happy to post the ESPHome YAML, Modbus logs, exact test results and ATM3.4B behavior here. If this revision behaves differently from the ATM3.2/ATM3.9B boards already discussed, hopefully we can add another useful data point to this thread.
Button simulation with relays definitely will work but this requires a lot of wiring. I started with relays but when I realized it has a MODBUS/RS485 I decided to switch to MODBUS. My Autoslide came with ATM3.2. MODBUS worked but not quite right. I called a support and ordered a latest board. This was ATM3.9B. Instead of expected MODBUS fix this version did not have MODBUS at all. Support eventually admitted that ATM3.9B MODBUS is completely broken and sent me very old ATM2 board. On the ATM2 board MODBUS was working as it should but door opening was extremely slow and my wife rejected it. I stayed with my original ATM3.2 board and applied workaround to fix MODBUS problems. This is my current setup and it works just fine. I have no idea how ATM3.4 will work with MODBUS.
Thanks for the summary of how you got to where you are. I agree — I’d rather not go back to the ATM2 red board, especially if that means giving up the better door performance of the ATM3.4B.
I’m hoping OpenCode AI, with ChatGPT, can help me determine whether the ATM3.4B can be made workable via MODBUS despite the apparent issues with its implementation. I’m running Home Assistant and ultimately want to integrate everything there.
If OpenCode can’t figure it out from the existing documentation and testing on its own, is there a specific approach you’d recommend I have it investigate? For example, particular registers/commands, timing differences, protocol quirks, or tests that might help determine exactly what is broken on the 3.4B and whether there’s a software workaround?
I’m not a programmer, but I’ve gotten pretty good at steering AI through projects like this. If you can point me in the right technical direction — or tell me what you would test next — I can feed that information into OpenCode and have it do the coding and experimentation.
I’ve also bought an ESP32/RS485 relay board, so once it arrives I should have the hardware available to start testing against the ATM3.4B.
To begin with try to control Autoslide manually, read the Status Register and check if responce is correct. If this does not work as it should than MODBUS is broken. But if status reporting is correct try to send a command. If this also works you can finalize your MODBUS project. Otherwise you option is button simulation with relays.