SMA Tripower / Modbus TCP

Setup, Configuration and Use Beginners
,
1

Hello everyone,

the last two days I have been trying to get Openhab to read my SMA TriPower inverter data via Modbus TCP.

In general, I think it works, f.e.

 Bridge modbus:tcp:inverter [ host="192.168.178.XXX", port=502, id=3, connectMaxTries=3] {
 
 	// Current power generation
 	Bridge poller power_current [ start=30775, length=4, refresh=5000, type="input" ] {
 	    	 Thing data power_current [ readStart="30775", readValueType="int32"]
 	   	 }
 
 	// Total yield - all together
 	Bridge poller power_alltogether [ start=30529, length=2, refresh=15000, type="input" ] {
 	    	 Thing data power_alltogether [ readStart="30529", readValueType="uint32", readTransform="JS(divide1000.js)"]
 	   	 }
 }

This example returns values as I would expect.

But when I try different Modbus channels I also get data formated like a timestamp:

Bridge poller info_30513 [ start=30513, length=4, refresh=5000, type="input" ] { Thing data info_30513 [ readStart="30513", readValueType="uint64"] }

This should return the total yield in “Wh” (watt hours). But I always get this error message:

2020-07-02 15:30:32.559 [WARN ] [ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '1970-01-03T13:12:42.000+0100' of item Solar_info_30513 with format '%.0f Wh': f != java.time.ZonedDateTime

This is the item:
String Solar_info_30513 "30513 [%.0f Wh]" { channel="modbus:data:inverter:info_30513:info_30513:number" }

Can someone see my mistake? I happens with a couple of different addresses (each one returns a timestamp value). I see these timestamp values even in the PaperUI!

Could someone post your (working) modbus thing + items? That would be very nice!!!

Thanks a lot and bye

2

I’m pretty sure you do not want duplicate Thing names. Your poller Bridge and data Thing are both named info_30513, I would change one e.g. reg_30513 or something.
Having said that, I do not think duplicate Bridge and Thing names are a real issue, but it’s an accident waiting to happen.

It certainly looks like something is trying to force a numeric into an epoch timestamp shaped hole. Don’t know of bugs, but uint64 is unusual config.
Try reading it as two 32 bit data Things, just to see if you get reasonable values.

Bear in mind binding may need a restart to pick up things file edits.

3

Hi Rossko57,

okay, I changed the names. Didn’t help.

What do you mean by reading as “two 32 bit data things”? In the documentation of the SMA it says the required data type is U64 (“A quad word (64 bit/2 x DWORD) in the local processor
format 0xFFFF FFFF FFFF FFFF”), that’s why I’ve used this.

Today I tried it with a bug fix (tried to convert the timestamp to seconds by javascript):

(function(i) {
    return new Date(i).getTime() / 1000;
})(input)

But then I get this message in the log file

2020-07-03 07:19:00.248 [WARN ] [ernal.handler.ModbusDataThingHandler] - Channel number will not be updated since transformation was unsuccessful. Channel is expecting the following data types [DecimalType, QuantityType, UnDefType]. Input data: number value 411564 (value type 'uint64' taken into account) and bool value true. Transformation: Transformation@8e740a[tranformation=JS(date_to_seconds.js),transformationServiceName=JS,transformationServiceParam=date_to_seconds.js]

Looks like the modbus binding gets the correct value of 411564 and then Openhab somehow transforms it into a timestamp value?!

I’m confused…

4

I mean you can read any Modbus register as a Modbus register. The distinctions we make between 16 bit, 32 bit, 64 bit is entirely arbitrary. To the binding, it’s just a bunch of 16-bit registers. How we want to group them is up to us (normally we’d use the same convention as the slave’s designers, of course!)

Same applies to interpretation - we choose whether some bunch of registers is supposed to represent a count or a timestamp or a set of binary relays.

So, my suggestion was just about finding out what real raw data comes across Modbus, see if that is what you expect, just in case there was some obscure bug with the uncommonly used 64-bit binding functions.

diagnostic setup, which could be linked to separate Items

Bridge poller info_30513 [ start=30513, length=4, refresh=5000, type="input" ] {
   Thing data in_30513_w64 [ readStart="30513", readValueType="uint64"]
   Thing data in_30513_32A [ readStart="30513", readValueType="uint32"]
   Thing data in_30513_32B [ readStart="30515", readValueType="uint32"]
 }

But as you’ve now seen a value 411564 for 64-bit usage, that will do, no need to go through all that.

Happy that is really the sort of value you are expecting? Remember, like the binding, I have no idea what it represents or what range of values you expect.

I would expect a javascript transform to blow up here, because basic javascript does not support 64-bit values.

That’s good - we haven’t accidentally selected a datetime binding channel type, this is a number channel like we expect.

After all that … I now see the issue

You’re trying to fit a number modbus channel into a String type Item.
I’m surprised it invokes timestamp parsing! But it’s not a sensible option.
Try -

Number Solar_info_30513 "30513 [%.0f Wh]" { channel="modbus:data:inverter:info_30513:whatever_it_is_now:number" }
5

I have a SMA tripower as well. This is my total yield reading:

// Total Yield
	Bridge poller Total_Yield [ start=30529, length=4, refresh=5000, type="input" ] {
	    
	    	 Thing data Total_Yield [ readStart="30529", readValueType="uint32", readTransform="JS(divide1000.js)" ]
 	 }

And this is the item:

Number inverter1TotalYield     "Inverter Total Yield [%s kWh]"     <line>      {channel="modbus:data:inverter1:Total_Yield:Total_Yield:number"}
1 Like
6

That’s it! changed it, now I get some values in non-timestamp format.
In earlier stages I was fooling around with this and forgot to change it back :frowning:

Still, my returning values are kind of strange, but this might be inverters fault. Will see.
Thanks for your support!

7

Hey guys, I am also interested in connecting my tripower with openhab.
My problem: I am a complete rookie to mod us and such.

Is there any step-by-step guide available, that could help me to get it working?

Thanks in advance for any hint!

8

I dont think there is an actual step by step guide. But its faily simple.
Does your SMA Tripower support ethernet (mine does). Connect it to the local network.

If yes:
You´ll need to get modbus running og OH.
From there you setup from the list of SMA modbus registers for the Tripower device. SMA has a full list of registers for almost all their products.

Thats basicly it.