Do you perhaps own an oscilloscope?
All I can think of is noise in the output of the voltage regulator.
But you can’t be sure without checking with a scope.
Something like this:
I use a TSR-1 2433 instead of an MP1584EN.
The output seems really stable, but there still can be peak voltages. (I haven’t checked, because I still don’t have a scope…)
In my PCB design I included two ceramic smoothing capacitors just to be safe.
I placed them as close as possible to the ESP.
If you don’t own an oscilloscope either, I would just add some capacitors. They are cheap, so that should be an easy test without buying a scope.
You would probably be better off adjusting it to ~5v and running it in through the 5v pin of the wemos d1 mini. The D1 has a linear power supply to drop the 5v down to 3.3v which should help to protect it from voltage spikes.
I cam back into this thread to ask if anyone else is having trouble getting reliable communication with their roomba on recent versions of esphome.
It seems like communication is failing most of the time, I usually can’t start the roomba and the sensors are slow to update. I guess I’ll have to dig into the library and see if I can add some debugging info to it.
I was trying to get this to work using both david and your libs for esphome and wasn’t having any luck. Thought I’d got the wiring wrong or something, but I don’t get any error messages, just a warning
[14:23:40][D][api.connection:1050]: Home Assistant 2023.11.2 (192.168.10.10): Connected successfully
[14:23:48][W][component:214]: Component <unknown> took a long time for an operation (0.20 s).
[14:23:48][W][component:215]: Components should block for at most 20-30ms.
Sensors aren’t updating and the buttons aren’t doing anything.
Fwiw I wired it up with a buck converter and a logic level shifter, so all the communications to the roomba should be at 5v while everything coming to the d1mini should be at 3.3, but I don’t own an oscilloscope to actually check if rx/tx are actually passing data or not…
I first tried this around the start of december and had no luck then, was giving it another shot today
Sorry for the late reply.
No I don’t have the same issue. Are you still starting the SoftwareSerial from the component, or are you using the ESPHome UART component?
(If your github repo is in sync, then you’re probably still starting the SoftwareSerial manually from what I checked )
Maybe switching to a ESPHome UART will make a difference?
Mm weird that you can’t get anything working.
When I fried my board and tried to get it working again, I used this FTDI thingy: click (I have the red one.)
You can hook your roomba up to your pc and try to get a serial connection there.
When the roomba starts, it will shout some boot info over the serial connection.
If that gives you output, then you know your serial port works at least.
It’s a lot cheaper than a scope
It does not give you as much info as a scope, but it’s a starting point.
@wburgers You my friend are a life saver. I was fiddeling around with the Roomba for days. And just like yours it suddenly didn’t answer me anymore.
I had a scope and everything looked fine. So I did what you suggested and added the start command 128 before each query and BAM it works.
Finally can go to bed after 3 days of tinkering. And my roomba can finally go clean the house again.
To all others: Thanks for tinkering and posting this is an amazing project
I fried 2 ESPs before I checked the voltage AND amps flowing into my ESP from the buck converter. In my programmer the ESP usually consumes about 70mA (more or less) and the buck converter “magically” forced 150mA into it. My guess was that it has to do with some overtone waves that the bloody thing is generating. So I exchanged it for a LF33C with 10uF on the output to keep the peaks at bay. Less parts. Easier to integrate and foremost: No fried chips.
Just hook up the TX of the FTDI to RX of the Roomba and vice versa.
And only hook up the GND, not the VCC.
Roomba has it’s own battery to power the serial connection and the FTDI is powered over USB.
Make sure to set the FTDI board to 5V with the jumper.
I will look into this. My ongoing theory is that the massive dump of serial data when the roomba restarts is confusing the esp32. Somewhere i think there is an option to dump all serial comms into the logs I should look into that.
I am using a level shifter too and I was checking with a scope. I discovered that the rise time on the tx line is too long with both level shifters I tried. I ended up removing some pull-up resistors on the roomba’s board, but you could try removing the level shifter from the esp’s tx line and wire it up directly.
I switched to the hardware UART and serial comms seem rock solid.
For the life of me however, I can’t figure out how y’all are starting your roombas. I just edited the library to make on_command public and I’m using template buttons to start/stop, dock and locate.
Also the library doesn’t seem to be pulling the drc pin to wake up the roomba before sending commands.
You mean your roomba goes into sleep mode while docked?
Mine doesn’t go into sleep mode, so I have no issue to send it commands.
It is always awake on the dock.
This has to do with the version of the main board/firmware version I believe.
I have such an old Roomba that it wasn’t implemented yet I think .
From the docs it does not seem configurable.
There’s even this note in the docs:
NOTE: Create 2 and Roomba 500/600 firmware versions prior to release-3.8.2/release-stm32-3.7.7 do
not wake up via BRC pulses when on the dock. To determine the firmware version on your robot, send a
reset opcode (7) via the serial port. Upon reset, the robot will print a long welcome message which will
include the firmware version, for example: r3_robot/tags/release-stm32-3.7.7 .
There were some BRC hacks in the Roomba library, but I have no clue if they work.
I’ve been editing the library again. I made most of the delays asynchronous. I’ve got it working reliably on several roomba 500s. Most of mine are 2008 or so.
Something I noticed is that the brc_wakeup doesn’t work reliably due to the lengths of the delays. I’ve got it working more or less reliably now and I’ll be updating my fork accordingly.
Once i get that up and running, I’ll try to get it working such that a sleeping roomba is woken up before commands are sent. Lots to do.
I think most of us used an ESP8266 variant, but it should be quite easy to modify the configuration to use an ESP32.
I think the thing that would have to change are the platform and board in de esphome section of the configuration and maybe which pins the uart connects to.
You should definitly try it out!
Let us know what you achieve.
Hi Willem.
I tried for two days
Nothing I do, except for board - platform - UART and BRC pin assignment, works
That why I’m asking here
I’v tried the different configs from this page and the github pages linked…
I got i to work
First I had mixed different *.h and *.yaml, and when using uart in logger, it would’t connect to wifi, lastly I started with resistors instead of the transistor.
Sooo Got it to compile yesterday and today I found an MPS3906.
I mixed some from DavidCavestro and Real-Time-Kodi. Works great!
)
.
,
