Unable to read modbus on V3

[k-janssens]

I've installed the latest V3 yesterday and the hardware is working great.
Only problem I currently have is to read the modbus registers.

Regardless if what register I try to read, I always get the exact same response:
21:04:19:482 > 00 49 00 00 00 06 01 03 00 02 00 01 21:04:20:509 < 00 49 00 00 00 06 0A 04 00 00 00 14 21:10:18:578 > 00 4A 00 00 00 06 01 03 00 04 00 01 21:10:20:513 < 00 4A 00 00 00 06 0A 04 00 00 00 14 21:10:47:492 > 00 4B 00 00 00 06 01 03 00 0A 00 01 21:10:48:516 < 00 4B 00 00 00 06 0A 04 00 00 00 14 21:10:52:844 > 00 4C 00 00 00 06 00 03 00 02 00 01 21:10:54:510 < 00 4C 00 00 00 06 0A 04 00 00 00 14

Besides the response always being exactly the same, the value '0A 04 00 00 00 14' can be found on the Sensorbox documentation (see the example below the page):
https://github.com/SmartEVSE/Sensorbox-2

So am I doing something wrong? Or is the modbus implementation changed in V3?

Additional info:

• tried both modbus and modbus rtu
• sensorbox is connected with the P1 of my digital meter
• no kWh meter
• I use a waveshare device to read modbus over tcp

[mstegen]

Modbus implementation has changed. For v3 i'm using the eModbus library (https://github.com/eModbus/eModbus) which works different from the implementation from v2.
But it works fine as master or as node controlled by a master, also mixed with older v2 controllers, but i have not tried to control it from a external modbus controller.

I'm trying to understand what response you are receiving, but i can not make any sense of it yet.. All i know is that a modbus message should not start with '00'
The SmartEVSE uses modbus RTU @9600 bps 8N1
Maybe you should try to listen to the modbus data first, you should be able to receive measurement data from the sensorbox every two seconds.

[k-janssens]

I'm using the same hardware as a friend of mine uses with the V2.
Got all his settings and such, but if he makes a request he is getting the proper response but I always get the same response: 00 00 00 00 00 06 0A 04 00 00 00 14

No matter which register I try to call or any other setting.
A few screenshots from the client I'm using:

In the Waveshare interface this is the data he is receiving every second (which make sense as the sensorbox is working as it should):

And the settings I used:

[kennyschuoler]

I just replaced my v2 controllers with the new v3 controllers, and i have the same issue, i'm unable to connect to modbus anymore.
I also tried if we could directly connect to modbus via the wifi interface, but it seems this is not (yet) available ? ( It's also possible that it is not the default 502 port, but here i'm waiting for the source code to figure this out )

[9600]

@mstegen You called?

[kennyschuoler]

@mstegen You called?

It was on accident ... He mentioned the bitrate to connect to modbus, you can ignore this ;p

[mstegen]

Two modbus masters do not (currently) work on v3, this is mainly because the eModbus library does only support two modes, master or node/slave. When configured for master, there is no modbus address set
There is also an option for a TCP bridge, but i have not used that yet.
My main focus was to get communication from the master controller to nodes/ kwh meters and sensorbox to work.

[koen-serneels]

@mstegen I was also trying to get modbus to work to no avail, glad I found this issue in time. I'm in need to control the evse to work together with other devices consuming power, so the sensorbox alone wont cut it for me: the evse without this feature to control it via any form of external api is a step backward for me.

This feature was in v2: would it perhaps be possible to flash v2 on a v3 device in the meantime?

Also, any other option of more high level communication than raw modbus (like a TCP or MQTT bridge) would be a huge step forward. If that is easier to implement than fix the modbus support than that would also be OK !

Would it be possible to give an ETA on this please as I'm really blocked atm wit this. Thanks!

[mstegen]

I have ported v2 software to v3 hardware, but the ESP32 is completely different from the PIC which was used on v2.
The modbus code on v2 was written from scratch, on v3 i'm using a library, mainly because low level access to the uarts on the ESP32 (while running RTOS) is difficult.
Until a few weeks ago it was for example not (?) possible to get a callback when new data was received by the uart.
You had to check for new data continuously in a loop. This is how the eModbus library determines there is new data.
10 days ago they added support for a callback (espressif/arduino-esp32#6364)
Hopefully it will get added to a stable arduino core release soon.

But in the mean time, i'll see if i can run the modbus master and node/slave processes at the same time.
That would most likely fix this issue.

[koen-serneels]

Ok that would be great!

Another idea maybe, if running both processes would not be possible, is to have some kind of minimalistic firmware just driving the cp pwm and offer a modbus master for comms (or if possible a higher level tcp/mqtt bridge). This firmware could then be used by people controlling loadbalancing and/or power management themselves instead of relying on the evse/sensorbox.

[mstegen]

I tested to run both the master and node processes, but that did not work.

So for now the only way to get it to work with a external master controller, is to configure the controller(s) as a Node, and send the required commands.

In order to keep each node happy, and not timeout with a comm-error you will have to send the chargecurrent for each node in a broadcast message to all nodes (address 09):

09 10 00 20 00 08 10 00 A0 00 00 00 3C 00 00 00 00 00 00 00 00 00 00 99 24
Node 0 00 A0 = 160 = 16.0A
Node 1 00 00 = 0 = 0.0A
Node 2 00 3C = 60 = 6.0A 
etc.

Each time this message is received on each node, the timeout timer is reset to 10 seconds.
The master will usually send this message every two seconds.

This is all what is required to prevent the communication error.

To have full control over the nodes, you will have to read each node's status registers, and see if it requests to charge.

for example for node 2:

Received packet (21 bytes) 03 04 10 00 01 00 00 00 3c 00 01 00 00 00 01 00 01 00 20 4d 8c
00 01 = state B
00 00 = no errors
00 3c = charge current 6.0 A
00 01 = Smart mode
etc.

Here the state changes to STATE_COMM_C (00 06)
Received packet (21 bytes) 03 04 10 00 06 00 00 00 3c 00 01 00 00 00 01 00 01 00 20 0a 8e
So the ESVE request to charge.

You can respond to this request by changing the state of the node to State_C
03 10 00 00 00 02 04 00 07 00 00 49 D6
Here it will write 00 07 (STATE_COMM_C_OK) to register 0x0000, and reset the error register 0x0001

The node will respond to this by switching to STATE_C (Charging).

[k-janssens]

As I am now able to add an API endpoint to read and control the data I need, this feel like the better way to move forward.
So for me need anymore to access the EVSE through the modbus interface, not sure what the others their opinion is on this.