The view of the problem from this end is that the target device refuses to talk to openHAB at that moment.
There’s nothing else to find out from this end.
It might be helpful for you to look at other SMA threads, and see if they used any particular TCP settings. If yours looks like an unusual case, maybe your network is the problem. You’ve told us nothing about that.
My config are from two different sites which both have a SMA and similar setup.
What do you want to know about network? It is all local and server and inverter are directly connected to a switch by wire Internet comes from a fritzbox and outgoing DNS is done by AdGuard home.
That’s good, not likely to be any problem there. Remember we only know what you tell us.
If you did not understand the other post, I’m not sure there’s much point in repeating it to you, but here goes.
When openHAB wants to talk to the SMA, it has to create a TCP connection.
That is a hand-shaking agreement, a negotiation of a contract. After that, the two devices can exchange data.
Your problem is that your SMA is not responding to that initial contact from openHAB to begin negotiation.
There’s nothing else to find out from a silence.
By default, the binding will not try again until the next poll becomes due. But you can change the setting to have it re-try the connection straight away, set connectMaxTries=2
I don’t really expect that to help.
But we know it works sometimes, and can try to guess what is happening.
Maybe the message doesn’t get to SMA, or the response doesn’t get back, or the messages get corrupted. That is unlikely, or you would probably see other errors reported from different stages in communication.
Having said that, there have been improvements to how the binding handles or reports some obscure TCP traffic conditions, like fragmentation.
If you are stuck on OH2.5, at least make sure you have OH 2.5.12
My gut feel though, is this is all about timing…
The OH server waits a time after sending the first TCP connection request, before deciding it hasn’t worked. If the SMA is just too slow to answer, OH will report a ‘timeout’ error.
Why would SMA be slow?
Maybe it just is. Maybe some SMA software versions do better than others - what’s yours?
Maybe sometimes it is just busy doing something else. I keep asking if you have any other service or app talking to it, for example.
What can you do about it?
Not much, from the openHAB end.
The most important connectTimeoutMillis is the one saying how long to wait. It should be 10 seconds by default, which is an absolute age on a local network, so I don’t think making it any longer will help at all.
You could make sure it really is 10000 millis, though.
The binding periodically drops an existing TCP connection and makes a new one.
That connection (the “negotiated contract”) will not last forever, so this is a good idea. Also for devices that will only do one connection at once, it allows other people to have a turn.
So by default, reconnectAfterMillis is 0 meaning to break the TCP connection and negotiate a new one at every poll.
However, you can set this to quite a long time, so that once you have a TCP connection you keep re-using the same one.
By setting this to a long time, you will reduce the number of times you get into this disconnect/reconnect problem area.
It can be set for days, but if I were you I wouldn’t go much more than an hour, at least while you are trouble shooting.
This will not fix anything but reduces nuisance logs.
The last setting you can play with is timeBetweenReconnectMillis
This is how long for openHAB to wait between closing an old TCP connection, and trying to start a new one. By default, it tries immediately, but often it helps to allow some time for the other end to clear up after the old connection before asking for new one. It shouldn’t be very long, just 500mS or so is all that is needed.
Apart from all that - the SMA Modbus implementation is quite badly behaved about reading the ends of register blocks, as @Nanna_Agesen hinted. If you want 2 registers, get your poller to ask for 4. If you need 100, ask for 102. SMA will always mess up the last one.
Very technical explanation here -
I really appreciate you help and patience.
About the Binding:
281 │ Active │ 80 │ 2.5.12 │ openHAB Add-ons :: Bundles :: Modbus Binding
SMA software versions
Software Package This will not fix anything but reduces nuisance logs.
I keep asking if you have any other service or app talking to it, for example.
I am not sure. There is the smart meter and SMA sunny portal receives values also, but they normally do not use modbus because it had been turned off till I wanted to know more from the inverter.
This will not fix anything but reduces nuisance logs.
For that I couls maybe also reduce log level of this binding (even if I do not know exactly how to do but I will find)
I will test it tomorrow again.
Don’t do that, or you will never be able to fix future problems. We have an idiom in the UK “that’s just sweeping the dirt under the carpet”
This SMA Thing file works for me, you can try that if you want
Bridge modbus:tcp:inverter [ host="192.168.100.141", port=502, id=3, connectMaxTries=3] {
// SMA Inverter Power Section West & Total
Bridge poller power_a [ start=30769, length=20, refresh=5000, type="input" ] {
Thing data currentA_input [ readStart="30769", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data voltageA_input [ readStart="30771", readValueType="int32", readTransform="JS(smalimits100.js)" ]
Thing data power_a [ readStart="30773", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data Active_Power [ readStart="30775", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data power_L1 [ readStart="30777", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data power_L2 [ readStart="30779", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data power_L3 [ readStart="30781", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data volt_G1 [ readStart="30783", readValueType="uint32", readTransform="JS(smalimits100.js)" ]
Thing data volt_G2 [ readStart="30785", readValueType="uint32", readTransform="JS(smalimits100.js)" ]
Thing data volt_G3 [ readStart="30787", readValueType="uint32", readTransform="JS(smalimits100.js)" ]
}
// SMA Inverter Power Section East
Bridge poller power_b [ start=30957, length=8, refresh=5000, type="input" ] {
Thing data currentB_input [ readStart="30957", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
Thing data voltageB_input [ readStart="30959", readValueType="int32", readTransform="JS(smalimits100.js)" ]
Thing data power_b [ readStart="30961", readValueType="int32", readTransform="JS(smalimits1000.js)" ]
}
// SMA Inverter Day Yield
Bridge poller Day_Yield [ start=30517, length=4, refresh=5000, type="input" ]
{
Thing data Day_Yield [ readStart="30517", readValueType="uint64", readTransform="JS(divide1000.js)" ]
}
// nilan_input_device.connection
Bridge poller Total_Yield [ start=30529, length=4, refresh=5000, type="input" ]
{
Thing data Total_Yield [ readStart="30529", readValueType="uint32", readTransform="JS(divide1000.js)" ]
}
// SMA Inverter Status
Bridge poller SMA_Status [ start=30201, length=36, refresh=6000, type="input" ] {
Thing data SMA_Status [ readStart="30201", readValueType="int32" ]
Thing data Grid_Contactor [ readStart="30217", readValueType="int32" ]
Thing data Max_Power [ readStart="30231", readValueType="int32" ]
Thing data Set_Max_Power [ readStart="30233", readValueType="int32" ]
}
// SMA Inverter Operation
Bridge poller SMA_Status_Operate [ start=40029, length=4, refresh=5000, type="holding" ]
{
Thing data SMA_Status_Operate [ readStart="40029", readValueType="uint32" ]
}
// SMA Inverter Country Standard
Bridge poller SMA_Country [ start=40109, length=4, refresh=5000, type="holding" ]
{
Thing data SMA_Country [ readStart="40109", readValueType="uint32" ]
}
// SMA Inverter GFDI
// Bridge poller SMA_GFDI [ start=30769, length=4, refresh=5000, type="input" ]
// {
// Thing data SMA_GFDI [ readStart="30769", readValueType="uint32" ]
// }
}It could be that the TCP Server on SMA side is not enabled.
You can use SUNNY EXPLORER (available for WINDOWS only) to verify this.
SUNNY EXPLORER can be download from here :
https://www.sma.de/en/products/monitoring-control/sunny-explorer.html
Let me know if you need further directions after installing SUNNY EXPLORER.
Many Thanks. It is aktivated. I did it also with UDP ON, it changed noting
I will give that a try this evening.
Thanks a lot
I had a look at the stripped things and items setup in the first post.
There is no closing bracket, may be you did not copy everything.
Bridge modbus:tcp:tripower "SMA Sunny Tripower 9000TL-20"
[ host="192.168.100.48", port=502, id=3, reconnectAfterMillis=6000 ]
{
Bridge poller devicedaten_30053 "Geraete Spezifikation"
[ start=30053, length=4, refresh=60000, type="input" ]
{
Thing data sma_type_30053 "SMA Wechselrichter Type"
[ readStart="30053", readValueType="uint32" ]
}
Bridge poller input_30769_114 "TP_Input_30769_114"
[ start=30773, length=114, refresh=2000, type="input" ]
{
Thing data 30773_2 "TP_30773_2"
[ readStart="30773", readValueType="int32"]
Thing data 30775_2 "TP_30775_2"
[ readStart="30775", readValueType="int32"]
Thing data 30839_2 "TP_30839_2"
[ readStart="30839", readValueType="uint32"]
}
} <-this bracket is missing !!
Apart from that I strongly recommend to follow the advice given by rossko57
For a start do not try to read multiple registers but just a single register.
Bridge modbus:tcp:tripower "SMA Sunny Tripower 9000TL-20"
[ host="192.168.100.48", port=502, id=3, reconnectAfterMillis=6000 ]
{
Bridge poller input_30775_4 "TP_Input_30775_4"
[ start=30775, length=4, refresh=60000, type="input" ]
{
Thing data 30775_4 "TP_30775_4"
[ readStart="30775", readValueType="int64"]
}
}
Note that the poller length= 4 and the readValueType=“int64”
This is due to the fact that some SMA converters “fragmentate” tcp messages.
This is an SMA error, but has been addressed in OPENHAB 3.
Give it a try and report back what error messages are left using this very basic setup.
Good luck !
OK,
I changed things file to this:
Bridge modbus:tcp:tripower [ host="192.168.100.48", port=502, id=3, connectMaxTries=3] {
Bridge poller input_30775_4 "SMA_Power_input_gesamt" [ start=30775, length=4, refresh=5000, type="input" ] {
Thing data 30775_4 [ readStart="30775", readValueType="int32"]
}
}
this is the error message:
2022-03-11 22:34:24.730 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'sma.things'
2022-03-11 22:34:38.710 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/3 error: connect timed out. Connection TCPMasterConnection@5cbf5ab9[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:35:33.456 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/3 error: connect timed out. Connection TCPMasterConnection@3678a657[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:36:03.916 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/3 error: connect timed out. Connection TCPMasterConnection@480b2713[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:36:13.984 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 2/3 error: connect timed out. Connection TCPMasterConnection@480b2713[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:36:24.054 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 3/3 error: connect timed out. Connection TCPMasterConnection@480b2713[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:36:24.055 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - re-connect reached max tries 3, throwing last error: connect timed out. Connection TCPMasterConnection@480b2713[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
2022-03-11 22:36:24.055 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection TCPMasterConnection@480b2713[socket=Socket[unconnected]] for endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]: connect timed out
2022-03-11 22:36:24.055 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502] -- aborting request ModbusReadRequestBlueprint@1653460b[slaveId=3,functionCode=READ_INPUT_REGISTERS,start=30775,length=4,maxTries=3] [operation ID 31df311a-65ba-4f9b-aa8a-6d4ab2cc24a1]
2022-03-11 22:36:39.066 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/3 error: connect timed out. Connection TCPMasterConnection@4903bc33[socket=Socket[unconnected]]. Endpoint ModbusTCPSlaveEndpoint@6da9c64e[address=192.168.100.48,port=502]
Item is showing a value. Even this is quite strange but I saw this earlier:
This is something I am catching with a rule.
ah, btw:
I had to shutdown my inverter first. I tried to connect with asimplymodbus to connect which was working normally but after lots of testing this did not work. So I shutdown inverter and after reboot I could connect again
While SMA can be picky about configuring addresses etc., you are getting a bunch of errors that other people do not see. What is more, it all seems a bit intermittent.
Smells strongly of flaky network somewhere.
I had (and still have) a similar issue with solar edge inverter. (see last post of Solaredge inverter via Modbus TCP 2 - Tutorials & Examples - openHAB Community)
At the beginning, my things even went offline and I had hundred of errors in the log. The cause seems to be because I have to read two different register seperatly (Production and use). Setting the “Time Between Transactions” in the Modbus TCP Slave to 250ms reduced my errors a lot, but I still get some which I just ignore for now.
I miss my Kostal Inverter which had a great OH-Binding without using Modbus. (And a much better local Webinterface)
The negative value indicates that the investor is not producing power at the moment.
If length= 4 you will receive 8 bytes → 0x80000000 which is -2147483648
If length= 4 you will receive 4 bytes → 0x8000. which is -32768
I use following Read Transform function to transform negative values to zero
JS(TransferCurrentPower.js)
(function(i) {
return Math.max(0,i);
})(input)
Do you have a static IP address for your inverter ?
If not, switching off and on the inverter may result in a IP-address which different from the one you specified in your things file.
This could explain that you sometimes nothing is received.
You can use SUNNY EXPLORER to check
its MAC address: SUNNY EXPLORER > Settings > Type Label > MAC address
its current IP-Address: SUNNY EXPLORER > Settings > System communications > IP address
With this information you can create a static IP address in your Router.
2022-03-11 22:34:38.710 [ERROR] connect try 1/3 error: connect timed out.
second attempt was succesful
2022-03-11 22:35:33.456 [ERROR] connect try 1/3 error: connect timed out.
second attempt was succesful
2022-03-11 22:36:03.916 [ERROR] connect try 1/3 error: connect timed out.
2022-03-11 22:36:13.984 [ERROR] connect try 2/3 error: connect timed out.
2022-03-11 22:36:24.054 [ERROR] connect try 3/3 error: connect timed out.
no successful attempts, connection time out
I see no other way forward than capturing the TCP-IP traffic on your network.
Are you familiar with Wireshark ?
IP is correct in settings of the inverter (checked with sunny Explorer) and My Router is giving this device always the same IP (defined in settings)
But thanks anyway
One thing I saw several time: if i am using sunny explorer and do not use a save configuration it shows two different IP Addresses .41 and .48
Connection with Sunny Explorer is only possible with xxx.xxx.xxx.48
This is also the one I use for Modbus when I receive values. 41 is not working, already tested.
UPDATE:
I guess xxx.xxx.xxx.41 is the Smart Meter …
Thanks for this, I wrote an rule for that … you way is for sure the better one
Another option to proceed is the use of a Modbus Master Simulator.
I have been using the Radzio! Modbus Master Simulator.
[Modbus Master Simulator]
Note:
I am NOT suggesting that your problems are caused by OPENHAB.
I have been using the Radzio! Modbus Master Simulator to investigate the “lost byte problem”.
It helped me to find out that the “lost byte problem” was caused by SMA.
Feel free to contact me for further investigation !
If I recall, the SMA didn’t quite follow the rules on TCP fragmentation. This might cause something in the middle of the network to mess up.
@Homer-Sim situation is unusual - once you set the minimum poll length 4, no-one else seems to suffer timeouts? I wonder if the router/switch might be fumbling the fragmented transfers, where most just pass it along as-is.
