Yes, you already set it passing true as last costructor arg
if (lazy650Enabled) {ESP_LOGI("roomba", "lazy650Enabled is true");} or unconditionally simply passing the value as variable arg.
Please do share! I am interested in such tutorial.
Specs talk about mA for current and mAh for charge/capacity, so raw values are translated to A/Ah. Also voltage is converted from mV to V.
Experimenting with filters is a good idea… removing translations from component code and leaving raw values flow, eventually manipulated at the filters stage, so that we can easily remove noise.
Hi,
as soon I add this sensor
- name: "${friendly_name} drive speed"
unit_of_measurement: "mm/s"
icon: mdi:speedometer
accuracy_decimals: 0
I lose the connection with the ESP, any idea?
I see this in the code
SensorSongNumber = 36, //24
SensorSongPlaying = 37, //25
Would it be possible to use it to play a song when I send the locate command?
void locate() {
write(141);
write(0);
}
I think that @Real-Time-Kodi did something similar…
else if (command == "locate"){
uint8_t song[] = {62, 12, 66, 12, 69, 12, 74, 36};
this->roomba.safeMode();
delay(500);
this->roomba.song(0, song, sizeof(song));
this->roomba.playSong(0);
//this->roomba.playSong(1);
Please check you added the related sensor within the lambda return value of the custom sensor.
Pay also attention to the position, i.e. last elem of the return value, last elemn of the sensor array defs
I tried the same and it works, just pushed to the uart branch both changes for keeping raw sensor data with filtering and for locate.
oh boy 
I have left this sensor in the config
- name: "${friendly_name} distance"
unit_of_measurement: "mm"
icon: mdi:map-marker-distance
accuracy_decimals: 0
let me test it 
I saw that you removed the / 1000.0 from the amper and volt measure
What is supposed to e the unit after this change? mA or A?
This way sensors expose raw data, mA, mAh, mV, in order to be enriched/filtered with something like
Please note the '“multiply: 0.001” in the example above, which translates from mX to X
Lovely, I’m sharing back the UI, if someone would like to re-use it
type: vertical-stack
cards:
- type: vertical-stack
title: roomba-control
cards:
- type: horizontal-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: start
target: {}
icon: mdi:arrow-right-drop-circle
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: stop
target: {}
icon: mdi:stop-circle
- type: horizontal-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: spot
target: {}
icon: mdi:sync
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: dock
target: {}
icon: mdi:home-circle
- type: horizontal-stack
cards:
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: locate
target: {}
icon: mdi:bell-circle
- show_name: true
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: sleep
target: {}
icon: mdi:pause-circle
- type: grid
title: roomba-drive
cards:
- show_name: false
show_icon: false
type: button
tap_action:
action: none
icon: ''
hold_action:
action: none
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: go_faster
target: {}
icon: mdi:chevron-triple-up
hold_action:
action: none
- show_name: false
show_icon: false
type: button
tap_action:
action: none
icon: ''
hold_action:
action: none
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: go_left
target: {}
icon: mdi:chevron-triple-left
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: halt
target: {}
icon: mdi:car-brake-hold
hold_action:
action: call-service
service: esphome.roomba_control_command
data:
command: drive
target: {}
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: go_right
target: {}
icon: mdi:chevron-triple-right
- show_name: false
show_icon: false
type: button
tap_action:
action: none
hold_action:
action: none
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: go_slower
target: {}
icon: mdi:chevron-triple-down
hold_action:
action: call-service
service: esphome.roomba_control_command
data:
command: halt
target: {}
- show_name: false
show_icon: true
type: button
tap_action:
action: call-service
service: esphome.roomba_control_command
data:
command: drive
target: {}
hold_action:
action: none
icon: mdi:steering
type: entities
entities:
- entity: sensor.roomba_control_activity
icon: mdi:robot-vacuum-variant
- entity: sensor.roomba_control_battery
icon: mdi:battery-outline
- entity: sensor.roomba_control_charging_state
icon: mdi:battery-charging-high
- entity: sensor.roomba_control_capacity
icon: mdi:battery
- entity: sensor.roomba_control_charge
icon: mdi:battery-charging
- entity: sensor.roomba_control_current
icon: mdi:lightning-bolt
- entity: sensor.roomba_control_voltage
icon: mdi:sine-wave
- entity: sensor.roomba_control_temperature
icon: mdi:thermometer
- entity: sensor.roomba_control_oi_mode
icon: mdi:steering
- entity: sensor.roomba_control_drive_speed
title: Roomba-telemetry
Hi,
I did some additional tests
Telemetry is working well
All the commands are working as expected, including the play song
@davidecavestro THANK YOU for this amazing work!!!
I have an additional question regarding the behavior: after the cleaning phase, the “DOCK” button starts to flash; but the activity remains “CLEANING”. Is there any way to intercept the “going to dock” status
regards
regards
I have an additional question regarding the behavior: after the cleaning phase, the “DOCK” button starts to flash; but the activity remains “CLEANING”. Is there any way to intercept the “going to dock” status.
From what I saw in the OI documentation that is not possible 
.
I don’t know if the automatic dock action is timer based. Maybe we can figure that out.
If it is timer based, we could just change the state based on the timer, but I believe there is some more magic involved in the Roomba.
Yep, I have the feeling that time isn’t the only parameter, because if I move Roomba in another room or area, the research of the dock doesn’t start at the same time. I will do more tests here
I noted this behavior:
Cleaning → Cleaning (Dock button flashing) → Lost (Red Alert triangle on roomba) → Lost
From another point of view, I’m wondering if we can do something with automation or in code when we send command “DOCK” to arbitrary set the activity or another sensor to “Going to DOCK”
In this way we can understand what the roomba is doing after it receives a command, same for “SPOT”, we can manage another status that only “CLEANING” status
what do you think?
So far I had no time to check, so I write my thoughts anyway.
As @wburgers said specs rulez.
I’d check specs then try and see how data flows from device, eventually preparing a truth table
I haven’t had much time either to dive into the idea by @bremby.
I’ve mostly tried to figure out what is wrong with my Roomba and pretty much dove into a rabit hole.
So, last time, I figured that the OI port was damaged, probably due to a short circuit.
So naturally I ordered a new motherboard for my Roomba from AliExpress for about €23.
Because what else could be wrong? The OI port is probably a protected part of the motherboard and so that part is probably damaged.
Took a while to get the new motherboard to the Netherlands.
Last weekend I removed the old motherboard from the device and installed the new one only to find out that it had exactly the same behavior for the OI port.
So apparently it was not the motherboard that was broken 
.
It has to be one of the sensors or something else.
A few years back, I ordered myself a new battery as the one that came with the Roomba was getting depleted very fast. I kept the old battery laying around just in case.
I inserted the old battery back into the Roomba after the new motherboard install and guess what…
The ESP could read from the OI port again. Inserting the newer battery again, made it spit out bogus.
So I damaged the battery?
Then I started digging more into the battery. There are no smarts in these older NiMH batteries.
It’s just battery cells and a thermistor. No pcb or anything.
With my multimeter I tested both the battery voltage and the thermistor resistance.
The voltage was around 16V after charging, which should be fine.
The thermistor should be between 8.5 and 15.5kΩ at room temperature according to the Roomba service manual.
The old battery gave a value of around 13.6kΩ, the newer battery around 9kΩ, just removed from the Roomba, which could impact the measurement a little.
It should be fine.
So I’m now considering buying another brand new battery.
Before I do so, I’ll hopefully try out a battery from a friend of mine, to see if that indeed solves my issues.
I am completely baffeled that the battery can cause the OI port to go haywire.
Especially since the measurements are okay.
So I’m still a bit lost on what to do next.
Buy a new battery or give up and buy a new robo vacuum.