The box that you know works with generic Modbus does not work with Sunspec. Leave that for a minute, you know you can go back to generic.
The other box does not work with Sunpec, but is unknown about generic Modbus.
Try that out.- get some confidence in your id numbers and topology.
It looks to me like Sunspec feature needs enabling on these boxes, though it is not clear to me if that needs doing only on "Leader"or also on “Follower” boxes.
Sorry to say, but I have the same issues using the “genric” modbus configuration. The Bridge with ID=2 always has SocketTimeoutException. Thus no difference (even though checking all parameters twice).
I think I will add a separate netwok cable to the second inverter with own IP address and Modbus over IP activation. All other scenarios are not working for me.
Excellent work here - thx. What I’m still missing is - what has already been requested above: Support of solarstore. I have a Solaredge inverter with a BYD Battery and I can easily read the battery state with python:
So it looks like I would just have to read the register 62836 with the openhab Modbus
plugin, too. But all my tries faulted right now. I don’t get any readings. This is what I’ve tried:
You are reading two registers in python and combining them. However, in openHAB you seem to read only one register as integer…as is, you would not get the same results. You probably want to use float32_swap or float32 readValueType
What I can tell pymodbus has same numbering convention than the binding, l.e. Addresses start as zero. So 62836 should be OK.
What do you mean when you say "all my tries faulted right now "? Give us the error message and it is easier to help
I have a little different configiuration. My battery is connected via 4K SolarEdger inverter an I get the information using this (last lines are commented out due to lack on information):
Bridge modbus:tcp:SE4K "PV Bridge ID1" [ host="x.y.z", port=502, id=1, timeBetweenTransactionsMillis=60, timeBetweenReconnectMillis=0, connectMaxTries=3, reconnectAfterMillis=0, connectTimeoutMillis=5000, enableDiscovery=true ]
{
Bridge poller RegistersBattery [ start=62784, length=120, refresh=5000, type="holding" ] {
Thing data B_Battery_ID [ readStart="62785", readValueType="uint16" ] //
Thing data B_RatedEnergy [ readStart="62787", readValueType="float32" ] //
Thing data B_MaxChargeContinuesPower [ readStart="62789", readValueType="float32" ] //
Thing data B_MaxDischargeContinuesPower [ readStart="62791", readValueType="float32" ] //
Thing data B_MaxChargePeakPower [ readStart="62793", readValueType="float32" ] //
Thing data B_MaxDischargePeakPower [ readStart="62795", readValueType="float32" ] //
// next 32 registers are reserved
Thing data B_AverageTemperature [ readStart="62829", readValueType="float32" ] //
Thing data B_MaxTemperature [ readStart="62831", readValueType="float32" ] //
Thing data B_InstantaneousVoltage [ readStart="62833", readValueType="float32" ] //
Thing data B_InstantaneousCurrent [ readStart="62835", readValueType="float32" ] //
Thing data B_InstantaneousPower [ readStart="62837", readValueType="float32" ] //
Thing data B_LifetimeExportEnergyCounter [ readStart="62839", readValueType="uint64" ] //
Thing data B_LifetimeImportEnergyCounter [ readStart="62843", readValueType="uint64" ] //
Thing data B_MaxEnergy [ readStart="62847", readValueType="float32" ] //
Thing data B_AvailableEnergy [ readStart="62849", readValueType="float32" ] //
Thing data B_StateOfHealth [ readStart="62851", readValueType="float32" ] //
Thing data B_StateOfEnergy [ readStart="62853", readValueType="float32" ] //
Thing data B_Status [ readStart="62855", readValueType="float32" ] //
Thing data B_StatusInternal [ readStart="62857", readValueType="float32" ] //
// Thing data B_EventsLog0 [ readStart="62859.0", readValueType="uint16" ] //
// Thing data B_EventsLog1 [ readStart="62859.1", readValueType="uint16" ] //
// Thing data B_EventsLog2 [ readStart="62859.2", readValueType="uint16" ] //
// Thing data B_EventsLog3 [ readStart="62859.3", readValueType="uint16" ] //
// Thing data B_EventsLog4 [ readStart="62859.4", readValueType="uint16" ] //
// Thing data B_EventsLog5 [ readStart="62859.5", readValueType="uint16" ] //
// Thing data B_EventsLog6 [ readStart="62859.6", readValueType="uint16" ] //
// Thing data B_EventsLog7 [ readStart="62859.7", readValueType="uint16" ] //
}
}
Hi all
Sorry for rising up this thread. But I have one question regarding this implementation.
I set up a SolarEdge and Energy Meter using Modbus Sunspec. (Coming from a Kostal, which was much better and much more modern regarding the interfaces etc. and the OH Binding is great.)
It works ok so far, with one exeption.
How do you prevent the “timeouts” respectively the poller things go offline because of the two different modbus poller (Inverter and energy meter block)? If they read nearly at the same time, one of them is blocked and goes offline.
It seems that the two pollers do not need the same amount of time to read and thus at some point they try to read at nearly the same time.
Is there a possibility to arrange the two pollers which have to connect to the same modbus tcp slave (Inverter)?
There is timeBetweenTransactionsMillis parameter in the tcp thing to control silent period between different requests to the same host. Modbus - Bindings | openHAB thing
Default is 60ms but perhaps it is too short time for the device to recover.
Thank you for this.
I will try to set a higher value and report back.
Update
I used 200ms instead of 60 and 2 connection tries instead of 1 and it seems to be better.
However the log still states many errors but there are MUCH less.
It seems the Solaredge is really slow, so maybe I have to go higher than 200ms to prevent the errors in the logfile…
Update2
Still no more things going offline, thats the good message.
But still some connection errors in the logfile, even if I only use one Thing(Poller).It happens especially a lot more frequently during night but sometimes also during day:
2021-12-28 05:57:51.252 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Try 1 out of 10 failed when executing request (ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=40069, length=50, maxTries=10]). Will try again soon. Error was I/O error, so reseting the connection. Error details: net.wimpi.modbus.ModbusIOException I/O exception: SocketException Connection reset [operation ID 135e1e47-19f2-4674-9c38-a0ebe6be752a]
Anyone else seeing this Warnings using Modbus with SolarEdge?
I’m also using Modbus for my Stiebel Eltron Heating and there I do not have any warnings. However, I perform a less frequent reading. 90s vs. 5s on SolarEdge.
my solaredge single phase inverter (SE5000H) works fine, but my logfile is full of events. I tried to change the log-level of modbus binding with “log:set WARN org.openhab.binding.modbus”.
2022-03-25 19:32:40.862 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACFrequencyValue' changed from 50.011 Hz to 50.013 Hz
2022-03-25 19:32:40.869 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACVoltage' changed from 230.9 V to 231.1 V
2022-03-25 19:33:00.957 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_HeatSinkTemperature' changed from 22.88 °C to 22.86 °C
2022-03-25 19:33:00.985 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACFrequencyValue' changed from 50.013 Hz to 50.011 Hz
2022-03-25 19:33:00.986 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACVoltage' changed from 231.1 V to 230.8 V
2022-03-25 19:33:21.045 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_HeatSinkTemperature' changed from 22.86 °C to 22.84 °C
2022-03-25 19:33:21.074 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACFrequencyValue' changed from 50.011 Hz to 50.003 Hz
2022-03-25 19:33:21.077 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'SinglePhaseInverter_ACVoltage' changed from 230.8 V to 231.2 V
the INFO messages are the standard openhab.event.ItemStateChangedEvent log entries.
I have set up an additional filter in the log4j.xml for preventing the logs to be spammed by high frequency readouts of the power values (solaredge inverter and meter, grid meter):
Add this to your log4j.xml in the section <Appenders> and replace the property regex by your needs (Item names or parts of the Items names)
I also have the connection problems sometimes. But it is very sporadically and I was not able to find any type of time scheme or if there are some events driving the connection errors. I think, the occurences are not more than 4-5 times a week.
You are hammering the Modbus as fast as it will go, That means to re-read the data very 5 milliseconds.
Luckily, the binding is smart enough to discard duplicate queued read-polls, or else your system would collapse with a huge queue of polls awaiting bus access.
It’s probably managing to read every 50mS or so.
I’d say from your useful log snippet that the target device is only changing its data every 20 seconds or so, so there’s no point reading it more often than that.
I reckon you do about ten million read polls in that time, so that’s a pretty good error rate.
This is simply not true as the Sunspec addon of the Modbus binding defines the refresh parameter of the Things in seconds (see documentation here: SunSpec - Bindings | openHAB)
I am reading the data every 5 seconds and the values are changing a bit more often I think. But 5 seconds is a good value to observe and track energy data.
This is interesting because your config looks almost default.
With default values my Inverter/Meter things went offline again and again.
Different to you I have a three phase inverter.
And I start reading at 40069 for 50 entries, but that should not make the difference.
But maybe more important, I used the delta connected Meter and I have to read another Modbus Block for live usage (40188, length 105). Why are you reading the same values for the meter as for your inverter?