Modbus issues with ABB Terra charger

Hi, I got ABB Terra AC charger which has electricity meter and RFID. This model ( W22-T-RD-M-0) has Modbus tcp/ip whereas my previous ABB charger without the electricity meter (model W22-T-0) didn’t seem to have it. I have discussed with ABB’s technical support in Finland and they don’t seem to know anything about these AC chargers.

I managed to setup the Modbus tcp/ip in Terraconfig Android app (see sceenshot below).

I have now tested the Modbus communication with Modbus Master software and I can read the MB registers with it. The problem is that I seem to get an error message (Modbus Communication Lost) in ABB’s other Android app ChargerSync after 1min or so:

When I get this error message charging of my car stops. When I disconnect the Modbus Master and reconnect it to Terra I can read again the MB registers. It seems that Terra’s Modbus is not a slave so it wants actively make the connection to Modbus Master. I have thought that MB slave units are always passive but this doesn’t seem to be the case with ABB Terra charger.

I wonder whether anybody else has experienced similar problems with ABB Terra AC charger. I guess I will contact ABB again and try to describe my problem.

There is no Modbus prohibition to prevent multiple TCP Masters accessing the same TCP Slave at the same time - BUT it is very common that devices simply do not support it, either rejecting or ignoring attempts to connect or making a mess of responses.

What makes you think this?
Even a well-behaved Modbus TCP Slave can be originating messages in other protocols (HTTP etc.) over the same TCP link - usually using different ports. (That does potentially include acting as a Modbus Master to something else, like an external meter. That’s the kind of thing Solar units do.)

Many thanks for your reply.

Yeah, perhaps I was wrong. My charger (as a slave) communicates with an energy meter via Modbus RTU.

I’m still wondering why MB TCP communication ends up in an error message when the MB Master software is not polling. I haven’t tried yet to use OH with the charger. Perhaps there is a bug in the charger’s firmware. I have now contacted ABB Finland but let’s see whether they have any solution to this problem.

openHAB is a really poor environment for ‘experimenting’ with Modbus. The presumption is that you know what to configure before you begin.
Which is to say, until/unless you get it working by using MBpoll or whatever utility tool, don’t even bother trying.
That does look like learning some tool you may never use again, but really it forces you to understand the Modbus set-up.

Impossible to say without some help from the complainant - error messages, error logs, etc.

One thing I noticed missing from the Terra setup screen you showed to begin with - Modbus ID (an integer in 1-250 range).
It is usual to allow users to configure that, though some devices just force that to a pre-set (often 1). Solar systems sometimes respond on several IDs with different results.
You will need to know the ID that you/it ends up with.

The other thing to talk about is that “disable LAN” warning. Did you do that? (careful - how would you undo it?)
Maybe you’ve a choice of Modbus-TCP or app, but not both.

EDIT - another scenario to consider.
I understand this charger supports an external meter connection using Modbus-RTU over wired serial?
If it supported alternative meter connections over Modbus-TCP, that might look rather like your setup screen i.e. no ID for the charger, which would be a Modbus Master.

Thanks, this is a good advise. I’ll try to get MB working first with Modbus Master (or MBpoll). I think I can’t do anything right now until I get more info from ABB.

I also noticed that the MB ID is missing but I assumed in MB Master that ID=1 and it seems to be working. I told the engineer at ABB that the MB ID is missing in the setup page.

Yes, I disabled LAN.

This is a good point. I’ll make a test this afternoon using either the app or MB Master.

Where did you get the detail for which of many thousand registers to look at? Does that source give any more hints?
Does the MM tool ever throw transient errors, like a timeout and a retry, when the other app is active?

The MB documentation can be downloaded from ABB.

It gives the MB register map but it doesn’t give any more hints regarding other tools (e.g. MM or MBpoll).

Yes, I got some errors on the MM tool but I didn’t pay enough attention to these so I guess I need to be more systematic next time.

May or may not be very helpful.
A non-response/timeout is most likely, where silence doesn’t tell us much about what the other end thinks.
On the other hand, garbled/unexpected responses is an indicator of dual master conflict. There may even be straightforward “I’m busy, go away” responses which would be completely legitimate if dual Masters (or just any Master) hit it too quickly.

I’m now testing the charger and it seems that dual masters wasn’t the reason for charging to stop. I had only MB Master connected to the charger. I have observed that if MB Master is not polling the charger within ~60s then I will get the “Modbus Communication Lost” message. I’m now using MBPoll to poll the charger every 15s and everything seems to be working so I guess the problem (MB Communication Lost) is related to the charger’s features somehow.

I think I have now realized the timeout problem. MB register 4106 is the communication timeout and according to the ABB MB documentation the default timeout is 60s. According to this document the timeout can be increased to 65535s but it seems that I can’t change the value for the timeout. Tried with MB Poll and MB Master.

That’s a weird behaviour from ABB, but there is a feel here that the Modbus-TCP interface is provided for some dedicated charger manager, and we’re “hijacking” it for general monitoring. I suppose that acts as a failsafe.
You’ll need to remember that shutting down openHAB may stop the charger!

You’re ready to go for openHAB, then :slight_smile:

The ABB docs suggest you read this as two words but write it as one. More weirdness.
There’s two ways to write a single holding register, “write single” or “write multiple”, commands FC6 or FC16. Make sure you try both. I’d wonder about which half of the two-words you were supposed to write to as well, i.e try addressing +/- one. Or of course that might be an error, and you really ned to write two registers for a 32-bit value.

I think it’s bug in the firmware. The charger has also OCPP protocol and the ABB cloud servers communicate with the chargers using this protocol, not the MB tcp. I will need to check what happens when I shutdown OH.

Yeah, somewhat weird that reading/writing requires different amount of words. I will do some more tests this week.

I have managed to start/stop charging by writing 0/1 to MB reg 4105 (without any offset) so this works.

I found this information on ABB website regarding firmware update, latest version seems to be 1.6.3 but you can’t download this yet. I’m on 1.5.2. I think the update below explains few issues I have had.

Modbus
Lock/Unlock cable on charger side
Improved 4100H – Set Charging Current Limit use case
Set Charging Current Limit register could be set anytime instead of during transac-
tion
EV1 meter support
EV1 meter also supported by reading correct Active power total register.
Different ABB meters are identified internally by charger and information trans-
ferred according to specific profile
New Modbus register to define communication timeout while in second-
ary mode
Provides a configurable approach to support interoperability