But he is using the Solaredge binding.
Sorry for causing some confusion. I should have written “ModBus hardware” rather than ModBus.
The minimum allowed value for live date is 1, which I am already using.
I wonder why this can not be changed in the programming of the binding to allow 0.1 (=6 seconds), for example
What makes you think that the API the binding talks to is not rate limited?
Hi, thank you for the question.
I know that the PUBLIC API is limited to avoid users hammering the SolarEdge servers 24/7.
That is why I ordered the ModBus Hardware, as that will allow me to use the PRIVATE API using the setup seen in the screenshot.
What I see in reality, however, is that the private API updates less frequently (compared to the cellphone app). The cellphone app gets its data from the PUBLIC API (and still updates faster) which is kind of unexpected.
What exactly is the private api??
The private API intercepts the traffic to the SolarEdge Cloud and makes it available locally.
So using the private API, you can eleminate the need to first send the data away, just to be forced to download it again (using the Public API), directly afterwards as step 2.
(At least this is my understanding).
It sounds pretty ackward to me… Well, ackward is probably not the right word. But its first time I have heard of an inverter with its own API. Normally an inverter would support industrial standard communications, (like modbus, E-Bus, etc).
My SMA inverters I´ve got two options. And I´m actually using both at the same time, cause both options are through the ethernet of the devices.
- Is the devices which sends data to SMA cloud server (called Sunny Portal). This I have used from the start. My Inverter and my Storage Inverter communicated with the Energy Meter, which collect some of the data and send it to Sunny Portal.
- Direct access to each device (Inverters) through modbus protocol (ethernet). This is where I use openhab and the modbus binding, to connect to the devices and collect data to openhab.
I assume yours would be the exact same. And if I understand correctly, what you call Private API, is the same as my devices communicating with the SMA cloud server. And for this, you´re using the specific binding (SolarEdge Cloud binding).
What I suggest is to still continue to use that, and then try if you can access your inverters directly as well through an interfcae like ethernet using modbus or anything else.
I´m not quantee this will work, but I suspect it will. It all depends on your devices (inverters).
Hi, from the screenshot Bert was posting earlier he is using SolarEdge binding which can be installed directly from Paper UI. This binding is using API of SolarEdge cloud and it seems that appart from Public API SolarEdge is offering and which is limited in number of request per daty they offer additionally some less stable Private API. From the configuration of the binding it looks to me that it is not using Modbus as it only requires SolarEdge ID. There is however another SolarEdge binding based on Modbus which you can configure to poll as often as you want, I do reading every second for example. This binding is working together with Modbus binding. However you do not need any extra hardware on the invertor, it has an Ethernet port and you can enable on the invertor Modbus over TCP.
I do not know if there is other way, but I have installed this by putting into addon folder /usr/share/openhab2/addons/ following jar files
org.openhab.binding.modbus-2.4.0-SNAPSHOT.jar
org.openhab.binding.modbus.sunspec-2.4.0-SNAPSHOT.jar
org.openhab.io.transport.modbus-2.4.0-SNAPSHOT.jar
Then need to configure your Modbus thing, I do it in Paper UI
and then add things using SolarEdge binding - one for Invertor and one for the Meter where you select Modbus TCP slave as the bridge and configure polling frequency
I believe that binding you are using is for the cloud only. This SolarEdge binding is based on Sunspec which shared also with other invertors https://www.solaredge.com/sites/default/files/sunspec-implementation-technical-note.pdf and gives you way more details on usage then cloud based binding.
3 Likes
Hello Petr,
this looks definately interesting. I will for sure give it a try once I find a little spare time. Thumbs up and thanks again for the hint.
Bert
Hmm… Why does a binding works together with another binding like this? If it´s modbus he should be able to access it directly using only the modbus binding. He just have to know the modbus registers. But maybe that is the purpose with the SolarEdge binding? (Ie using modbus, but SolarEdge is telling him which registers?):
Yes, that is how I understand it, Modbus binding takes care of connectivity (here you set IP/port) and SolarEdge binding (here you basically select type of device such as 1phase or 3phase invertor or meter) does the mapping of registers based on Sunspec.
Okay makes sense now…
You can if you like.
Exactly, because it works together and does a lot of configuration for you.
So far as I know the Modbus “add-on” is actually Sunpec specification which is a standard used by more than one manufacturer.
It’s like asking why we bother having weather bindings, when really you could do all that with HTTP binding (and a lot of work).
But for devices like these, you put all your trust into the binding developer to choose which registers to support then, or??
Ofocuse things like these are “alot of work”. But I would hate to use a binding, which is somekind of “general” setup, where I cant tweak or optimize where I want to. And as far as I understand the OP, this is exactly the problem he has. The binding dont seem to let him do what he wants to.
Yes. Just like you do with Astro or Weather bindings.
His problem is with the Solaredge binding that uses the manufacturer’s web API. He has to supply an API key, etc.
He is not (yet) using the Modbus based Sunspec binding, which is not yet fully merged into OH.
The SolaEdge Binding that I currently use, let’s me choose.
Option 1 - using (a shorter) API Key:
Here I can re-download the content from the Public API. Officially supported.
Option 2 using a (significantly longer) security token (that intercepts ModBus traffic):
Download from a local source, but only 1x per minute. Private API, not officially supported.
To me the currently used binding makes it easy to get startet, however it seems to come with that awkward limitation, that the other binding (mentioned by Petr) seems to not have.
Is there an ETA on when the Sunspec Binding will be merged?
You can follow progress here. It may make release 2.5.4
1 Like
Hello,
I am trying to connect my SE5000H Single phase SetApp inverter through Modbus. I have enabled Modbus TCP with standard port 1502 in the Inverter through SetApp.
Is there any time limits in which the ports are available, or it does not matter?
How can I test, if the port is reachable?
My settings:
modbus TCP seems to be online, whatever is setted in:
UID: modbus:tcp:d76ff7b8b0
label: SE Modbus TCP Slave
thingTypeUID: modbus:tcp
configuration:
rtuEncoded: false
timeBetweenTransactionsMillis: 60
connectMaxTries: 1
reconnectAfterMillis: 0
port: 1502
timeBetweenReconnectMillis: 0
host: 192.168.1.105
connectTimeoutMillis: 10000
id: 1
enableDiscovery: false
location: Vchod
1ph inverter is Error with read: org.openhab.core.io.transport.modbus.exception.ModbusConnectionException: Error connecting to endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502]
UID: modbus:inverter-single-phase:d76ff7b8b0:c88c825712
label: SE5000H Single Phase Inverter
thingTypeUID: modbus:inverter-single-phase
configuration:
length: 61
refresh: 5
maxTries: 3
address: 40000
bridgeUID: modbus:tcp:d76ff7b8b0
location: Vchod
and the same for meter:
UID: modbus:meter-wye-phase:7fdcd65a9c
label: SE Three Phase Meter, Wye-Connected
thingTypeUID: modbus:meter-wye-phase
configuration:
length: 61
refresh: 5
maxTries: 3
address: 40000
bridgeUID: modbus:tcp:d76ff7b8b0
location: Vchod
2021-12-28 21:10:35.665 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/1 error: Spojenie odmietnuté (Connection refused). Connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=/192.168.1.105, m_Port=1502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false]. Endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502]
2021-12-28 21:10:35.666 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - re-connect reached max tries 1, throwing last error: Spojenie odmietnuté (Connection refused). Connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=/192.168.1.105, m_Port=1502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false]. Endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502]
2021-12-28 21:10:35.668 [ERROR] [ing.ModbusSlaveConnectionFactoryImpl] - Error connecting connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=/192.168.1.105, m_Port=1502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false] for endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502]: Spojenie odmietnuté (Connection refused)
2021-12-28 21:10:35.669 [WARN ] [rt.modbus.internal.ModbusManagerImpl] - Could not connect to endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502] -- aborting request ModbusReadRequestBlueprint [slaveId=1, functionCode=READ_MULTIPLE_REGISTERS, start=40000, length=61, maxTries=3] [operation ID 1f3fac1a-4ef8-4d0b-ab9e-3f905fdb6472]
2021-12-28 21:10:35.682 [WARN ] [ing.ModbusSlaveConnectionFactoryImpl] - connect try 1/1 error: Spojenie odmietnuté (Connection refused). Connection TCPMasterConnection [m_Socket=Socket[unconnected], m_Timeout=3000, m_Connected=false, m_Address=/192.168.1.105, m_Port=1502, m_ModbusTransport=null, m_ConnectTimeoutMillis=10000, rtuEncoded=false]. Endpoint ModbusIPSlaveEndpoint [address=192.168.1.105, port=1502]
What I am doing wrong? according to documentation, starting with address 4000 seems to be legit…
Michal
The advice here applies
but -
this does look like a basic error with IP, port, or ethernet pathway