Im suspecting that my converters would be bad.
I ordered other one but according to its datasheet it needs sort of flow control. DE and RE high to send and low to receive(MAX485).
Problem is I dont find flow control pin.
Im using @jrv yaml default pins and dont really understand how those relate to ESP Wroom 32 pins.
Yaml has 16 as RX, 17 as TX and 5 as flow control.
RX and TX is found on pins 40 and 41 on ESP Wroom 32 package.
I tried to measure all pins from package with scope to find flow control pin with out luck.
What is logic between pin numbering in Yaml and for ESP?
Default uart2 pins are GPIO16 and GPIO17.
Don’t get confused with whatever pinmapping you might see, always define GPIOx.
If your rs485 module has automatic direction control, you can just remove that line from your yaml (or leave it unconnected).
Did you manage to “open your chargers heart” with proprietary pc software?
I have to double check.
But while I was looking for flow control pin I also measured where TX pin on PCBA is connected on ESP and it didnt seem to match what ESP documentation says.
And this is only pin that pushes out any traffic. Could of course connect to USB adapter to check how that traffic looks.
Means what?
Look, if you want to move on, answer the question above about PC connection and publish a photo of your setup.
On PC connection to charger.
Yes it connected, theres screenshot of what that program returned.
It doesnt really much to configure.
For my project.
I will document my HW and post here tomorrow or day after that with all measurements that I can do.
Software is taken from @jrv git repo.
Did you get responses or not? I don’t think that software was created to show just serial number…
Serial number is response. Its even correct value as same is printed on labels on charger.
And yes if I would have multiple chargers, meter options or some load balancing stuff it would configure a lot stuff. But for lonely changer there’s not much to configure. There is option to change maximum current but its already correct and changing it back and forth would not prove anything else than reading serial number does.
Fact that connection worked with USB adapter from PC proved that my chargers RS485 works. It gave me working signal levels for sending to charger and levels that charger sends out.
This is what lead me to believe my original TTL - RS485 adapters are not good as when comparing its signals to those of USB adapter and charger the voltage difference between A and B was lower. Maybe low enough that charger would not register.
This is why I ordered different adapter but was too focused to just check its specified signal levels on RS485 pins that I missed fact that it requires flow control on TTL in order to recieve data. And for few hours I had time to look for that flow control pin I would not find that specified pin5/GPIO5 pin or pin that would have signal that behaves like I would expect flow control pin to behave.
Lets see if while documenting my HW or from my HW documentation someone else can spot that pin or some other pin that i can configure to carry that function.
Flow control pin can be whatever digital pin on your board. Leave it 5 like in your yaml. Make Y jumper wire from your esp pin to rs485 board DE and RE.
By the way, if you think you had correct hardware connection with USB, try with free windows software:
It can scan all addresses you have available…
Wiring it from where ever I would find it is acceptable. But currently issue is that so far only pins that are not static is TX and CLK.
Not sure scanning with different program would provide much additional value at this point? Or are you looking for something specific?
I don’t follow you perfectly. But I have played with many Rs485 devices, and the whole concept is generally (not always) quite simple. If you have common rs485 to usb module, just give that CAS software a change.
If you use one of those two most common Rs485 to TTL modules available online, you shouldn’t have issues either to connect to ESP32.
Show your hardware.
So. I have Espduino-32 board that uses ESP Wroom 32.
My Yaml is as a whole has been posted earlier but I guess important part is pins at this point.
tx_pin: "17"
rx_pin: "16"
flow_control_pin: "5"
With these TX actually comes out from GPIO01/ TXD 0. Atleast if pinout of Wroom in this image is correct.
All other IO pins are just static high or low.
For TTL - RS485 conversion I have this module(different shop but this in English so probably more usefull to most) MAX485 RS485 transceiver module
Based on information on that page and datasheet on MAX485 chip this needs flow control pin that for my Espduino is missing at this moment as GPIO5 is just static low. Tested RS485 from new module but as expected it doesnt send what is provided to it as it needs flowcontrol high in order to send.
Earlier modules where from china with no other documentation or model info than what was on silk print. These didnt require flow control but voltage difference between A and B lines where much lower than on USB adapter I used to scan for and found charger using ABL configuration software 2.0. USB adapter has ~2.3V difference between A and B when chinese adapters had barely 1V. This is why at this moment I consider these china modules out of spec.
Did also read RS232 directly from ESP with USB adapter and Putty with 38400 baud databits 8 stop bits 1 and no parity or flow control. Result is like this:
b:▒ξ▒▒▒q▒n▒▒▒▒;▒▒
Is this as expected? Or do I have Putty settings wrong or some issue on ESP side?
What does it mean? Not free to use?? If so. just pick another pin like GPIO4.
Gpio16(rx2)/17(tx2) is UART2, that’s what you want to use.
Your max485 module linked should be ok, I have never had problems with them.
Also. don’t be shy with your yaml, your three lines is not enough to see if everything matches.
Also, define your pins as GPIOxx,
Wiring is like this:
What does it mean? Not free to use?? If so. just pick another pin like GPIO4.
Flow control pin for MAX485 should go high when there is data to be sent. I dont know what you mean free to use? Generally GPIOs should be free to use as thats what those are there for. I will do tests tomorrow with other pins.
Gpio16(rx2)/17(tx2) is UART2, that’s what you want to use.
But there is no traffic on TX. This is why I earlier started to ask whats going on with pin numbering as these doesn’t seem to match.
Also. don’t be shy with your yaml, your three lines is not enough to see if everything matches.
Was just trying to be conservative about reposting same config repeatedly but here it is:
substitutions:
name: esphome-web-8c5fa4
friendly_name: ESPHome EV Charger 8c5fa4
device_description: "Monitor and configure ABL eMH1 Charger via RS485/Modbus-ASCII"
external_components_source: https://github.com/jrv/esphome-abl-emh1
tx_pin: "17"
rx_pin: "16"
flow_control_pin: "5"
esphome:
name: ${name}
comment: ${device_description}
friendly_name: ABL eMH1
project:
name: "jrv.esphome-abl-emh1"
version: 0.0.1
esp32:
board: esp32dev
external_components:
source:
type: git
url: ${external_components_source}
ref: main
refresh: 0s
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
ota:
- platform: esphome
id: ota_esphome
logger:
level: DEBUG
api:
encryption:
key: JtQ6TY+YVOGdC3AuCm+XuEPdi8oa8b29fiZjcVEtV8I=
uart:
id: uart_2
baud_rate: 38400
tx_pin: ${tx_pin}
rx_pin: ${rx_pin}
parity: NONE
emh1_modbus:
uart_id: uart_2
flow_control_pin: ${flow_control_pin}
id: modbus0
abl_emh1:
emh1_modbus_id: modbus0
update_interval: 5s
preferences:
flash_write_interval: 5min
text_sensor:
- platform: abl_emh1
mode:
name: "Status"
serial_number:
name: "Serial number"
disabled_by_default: true
- platform: template
name: Chargemode
id: chargemode
icon: "mdi:car"
update_interval: 5s
disabled_by_default: true
lambda: |-
int phaseCnt = 0;
if (id(outlet_state).state == 0xC2) {
if (id(l1_current).state > 1.0)
phaseCnt++;
if (id(l2_current).state > 1.0)
phaseCnt++;
if (id(l3_current).state > 1.0)
phaseCnt++;
}
std::__cxx11::string result;
switch (phaseCnt){
case 0:
result = "None";
break;
case 1:
result = "1 Phase";
break;
default:
result = "3 Phase";
}
return result;
sensor:
- platform: abl_emh1
l1_current:
name: "L1 current"
state_class: "measurement"
accuracy_decimals: 0
id: l1_current
l2_current:
name: "L2 current"
state_class: "measurement"
accuracy_decimals: 0
id: l2_current
l3_current:
name: "L3 current"
state_class: "measurement"
accuracy_decimals: 0
id: l3_current
max_current:
name: "Max current"
state_class: "measurement"
id: max_current
disabled_by_default: true
accuracy_decimals: 0
en1_status:
name: "EN1 status"
disabled_by_default: true
en2_status:
name: "EN2 status"
disabled_by_default: true
duty_cycle_reduced:
name: "Reduced Duty Cycle (max_current)"
disabled_by_default: true
ucp_status:
name: "Ucp Status <= 10V"
disabled_by_default: true
outlet_state:
name: "Outlet state"
disabled_by_default: true
id: outlet_state
- platform: uptime
name: Uptime Sensor
id: abl_uptime
update_interval: 15s
number:
- platform: template
name: "Max Amps"
id: set_current
icon: mdi:arrow-oscillating
min_value: 3
max_value: 32
step: 1
optimistic: false
lambda: 'return std::lround(id(max_current).state);'
update_interval: 1s
set_action:
lambda: |-
ESP_LOGD("main", "Sending modbus value = %d", std::lround(x));
id(modbus0)->send_current(std::lround(x));
switch:
- platform: template
name: "Enable"
id: enable_switch
icon: "mdi:power"
lambda: 'return (id(outlet_state).state != 0xE0);'
turn_off_action:
- lambda: |-
if ((id(abl_uptime).state > 10.0) && (id(outlet_state).state != NAN))
id(modbus0)->send_enable(0);
turn_on_action:
- lambda: |-
if ((id(abl_uptime).state > 10.0) && (id(outlet_state).state != NAN))
id(modbus0)->send_enable(1);
Also, define your pins as GPIOxx
I took config provided in Gitrepo that based on earlier discussion on this thread has worked for others. Tried to use it as it was so that there would not be mistakes introduced by me now knowing what Im doing. Will test tomorrow if this formatting changes anything.
You wrote that gpio5 is not available and is static low. What should I understand?
Esp32 gpio pin can be defined input or output, if input it can be pulled down to 0 or pulled up to 3.3V or left floating. If output, it can be written low 0V or high 3.3V.
Doesn’t sound static to me. It will we static low if you connect it to GND with jumper wire.
Control that 38400 is correct baudrate for your charger.
Connect your wirings like that hand drawing I posted.
Remove all substitutions for pins.
Define all pins as GPIOxx, like this:
id: uart_2
baud_rate: 38400
tx_pin: GPIO17
rx_pin: GPIO16
and
uart_id: uart_2
flow_control_pin: GPIO4
Rest is in hands of your external component.
You wrote that gpio5 is not available and is static low. What should I understand?
Esp32 gpio pin can be defined input or output, if input it can be pulled down to 0 or pulled up to 3.3V or left floating. If output, it can be written low 0V or high 3.3V.
Doesn’t sound static to me. It will we static low if you connect it to GND with jumper wire.
Didn’t say not available. Pin is there I have wire in it.
Its just not doing anything. Its constant low state like most other unused IOs.
Active pin would change its state, as TX does. This is easy to see with scope.
But is shows static low state ~30mV
On most processors configuring pins is done in code, dont think Yaml is much use in this case. If you are familiar with ESP32 and coding it you can read code written by @jrv from hes Gitrepo.
For baud its also what is in project. I just assume its correct as people in this thread have used this same project.
Trust me there’s no issues of wiring MAX485. Its written on pages of shops that sell it and yes I did read datasheet for this chip to verify before even opened ESD bag.
As I said in previous post. I will tomorrow try changing pins im yaml to GPIOxx format and see if that changes anything. Will also test other GPIO pins for flow control just in case GPIO5 in my chip is faulty.
May be language issue, pins are not static.
I had a look at that external component code, it’s doing some playing with float control pin and it’s hardcoded, so you have to leave substitution for that.
So leave all the substitutions and ignore the yaml changes I proposed.
That flow control changes it state for few millisecond’s may be you didn’t catch it.
Or that external component just doesn’t do it’s job correctly.
If I was you, I would try to scan that charger with pc software, like proposed before.
If I come to point where I choose to develop my own solution for this I likely will scan my charger with software you proposed if no program that Im familiar from work works.
But as of now Im looking to use this project and help related to setting up it.
Up to you.
Quick scan from pc software gives you confirm that your hardware is correct and shows you successful addresses. That’s a lot to start with.
With your esphome external component everything has to match perfectly to setup that creator had. But what if your charger has different slave id address?? Different firmware??
I also own an ABL EMH1 wallbox and have heard about the possibility of integrating it with ESPHome. Since I’m very interested in this solution, I wanted to ask if there’s a way to get a complete package without having to do much tinkering myself. I’m particularly interested in a solution that includes all the necessary components and configurations so that I can integrate the wallbox as easily as possible. Do you have any recommendations or could you help me out?
