Modbus issues with ABB Terra charger

Add-ons Bindings
1

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).

Screenshot_20220913-220430_TerraConfig
Screenshot_20220913-220430_TerraConfig1080×2280 123 KB

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:

Screenshot_20220919-183559_ChargerSync
Screenshot_20220919-183559_ChargerSync1080×2280 124 KB

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.

2

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.)

4

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.

5

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.

6

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.

7

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?

8

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.

9

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.

10

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.

11

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.

12

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.

13

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.

14

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
15

ABB released finally FW 1.6.5 for the Terra AC charger yesterday. I have made some tests with MB softwares and it seems that most of the problems (bugs) have been resolved. E.g. the communication timeout can be changed now.

I had some difficulties in changing the “Set Charging Current Limit” parameter in MB reg 4100h because it has two words. Finally I discovered that I need to write 0 to 4100h and e.g. 16000 to 4101h at once using FC16. 16000 corresponds to 16A. Now I need to figure out how to use FC16 in openHAB.

16

how do you get one? on my 11kw the latest is 1.5.2 that I’m seeing. Also would you mind sharing some code that you used to debug it? I use mine via serial, and it suddenly stopped working

17

Hi, you need to have ChargerSync app on your phone to download the latest firmware (1.6.5). I haven’t implemented Terra in OH yet. I just have been testing Modbus communication using Modbus Master and MB Poll softwares.

You also need to have a MID version of Terra. Basic version (without the energy meter and display) doesn’t have Modbus TCP. It has Modbus RTU but this is only for communication between Terra and energy meter (for load balance).

18

yes, I’m using the Basic version without display through modbus RTU. Basic version can be as a slave in multi site connection and you can control it via modbus (abeit not via tcp/ip). And I’ve been debugging it with evcc.io, but it just stopped working after first charge :slight_smile:
Maybe that’s why firmware is not yet available, it shows just 1.5.2 in both the chargerSync and TerraConfig app.

19

OK, I thought that the RTU is only for communication between Terra and an energy meter.

Perhaps you could try to uninstall ChargerSync and reinstall it to see if you can upgrade to 1.6.5.

1 Like
20

Its in the bindings docs. You’d set up your data Thing as a 32-bit read and write type, and get FC16 by default (32-bit being implicitly multiple register write)

21

Somehow I managed to get the setting for charging current working but I don’t quite think that this is a correct way.

So I setup a Modbus data thing:

UID: modbus:data:dc8dd55fc1:11009dee3a
label: TerraAC_latausvirta
thingTypeUID: modbus:data
configuration:
  readTransform: default
  writeTransform: default
  writeType: holding
  updateUnchangedValuesEveryMillis: 1000
  writeValueType: int32
  writeMultipleEvenWithSingleRegisterOrCoil: false
  writeMaxTries: 3
  writeStart: "16640"
bridgeUID: modbus:tcp:dc8dd55fc1
location: Autotalli

I then created two MB items for regs 16640 (TerraAC_Reg16640) and 16641 (TerraAC_Reg16640) and linked them with the MB Data thing above. I have a number item for the current and made a rule to change the current:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: TerraAC_virta_asetus
    type: core.ItemCommandTrigger
conditions: []
actions:
  - inputs: {}
    id: "2"
    configuration:
      type: application/vnd.openhab.dsl.rule
      script: >-
        var int TerraAC_virta_asetus_2 = (TerraAC_virta_asetus.state as
        Number).intValue * 1000
        TerraAC_Reg16640.sendCommand(0)
        TerraAC_Reg16641.sendCommand(TerraAC_virta_asetus_2)
        logInfo("test" , "TerraAC_Reg16645 sendCommand(1)" + TerraAC_virta_asetus)
    type: script.ScriptAction

Basically this seems to be working but when I am sending the TerraAC_Reg16640 and TerraAC_Reg16641 commands are they both sent at once? So is this the way how I should use FC16? The MB binding documentation doesn’t seem to have an example for FC16.