E3DC Modbus Binding - Test Request

Hi folks,

this year I got my E3DC system and for sure I wanted to integrate this into openHAB. This post does quite a good job and on top the Grafana diagrams are quite nice.

In June a new Modbus spec was released by E3DC with some Wallbox control possibilities. This was quite hard to implement in rules. So i decied to implement an E3DC Modbus binding. Release candiate + config are available here.

If you own such a system I would be appreciate your feedback!

2 Likes

Hi,

i’ve upgraded to 2.5.9 and tried to migrate from my own E3DC modbus interpretation to your Binding. I’ve copied the things and items files and just configured the correct IP address. Unfortunately the items don’t get any values.

2020-09-21 10:52:30.414 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'e3dc.things'
2020-09-21 10:52:30.451 [DEBUG] [modbus.internal.ModbusHandlerFactory] - createHandler Modbus tcp
2020-09-21 10:52:30.462 [TRACE] [very.internal.ModbusDiscoveryService] - Received new handler: org.openhab.binding.modbus.discovery.internal.ModbusEndpointDiscoveryService@652613
==> /var/log/openhab2/events.log <==
2020-09-21 10:52:30.484 [hingStatusInfoChangedEvent] - 'modbus:tcp:device' changed from UNINITIALIZED to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2020-09-21 10:52:30.510 [TRACE] [r.AbstractModbusEndpointThingHandler] - Initializing modbus:tcp:device from status INITIALIZING
2020-09-21 10:52:30.516 [TRACE] [r.AbstractModbusEndpointThingHandler] - initialize() of thing modbus:tcp:device 'E3DC Modbus TCP' finished
==> /var/log/openhab2/events.log <==
2020-09-21 10:52:30.518 [hingStatusInfoChangedEvent] - 'modbus:tcp:device' changed from INITIALIZING to ONLINE

That’s all i get.

The, uhh, unadventurous naming here prompts me to say - make sure your new Things do not clash with your old Things.

Yeah i’m heavily confused with the naming in the shipped .things file

Bridge modbus:tcp:device "E3DC Modbus TCP" [ host="192.168.178.56", port=502, id=1 ] {
	Bridge e3dc powerplant "E3DC Power Plant" [ refresh=2500 ] {
    	 Thing e3dc-wallbox wallbox0		"E3DC Wallbox"				[ wallboxId=0]
    }
}
String    E3DC_ModbusId                 "E3DC Modbus ID"            (e3dc)      { channel="modbus:e3dc:device:powerplant:info#modbus-id" }

I think this is a naming issue, but changing modbus:tcp:device to modbus:tcp:e3dc in things file doesn’t help, too.

You’ll find the official binding docs at https://www.openhab.org/addons/bindings/modbus.e3dc/

Shame on me for the bad naming :slight_smile: . Perhaps replace device with e.g. solar which ends up to

Bridge modbus:tcp:solar "E3DC Modbus TCP" [ host="YOUR_E3DC_IP", port=502, id=1 ] {
	Bridge e3dc powerplant "E3DC Power Plant" [ refresh=2500 ] {
    	 Thing e3dc-wallbox wallbox0		"E3DC Wallbox"				[ wallboxId=0]
    }
}
String    E3DC_ModbusId                 "E3DC Modbus ID"            (e3dc)      { channel="modbus:e3dc:solar:powerplant:info#modbus-id" }

Nevertheless I think the names are correct - I’m running exactly this config in my environment.

To start analysis from scratch please check if your E3DC IP-Address is really 192.168.178.56!
In the example description I missed to replace the concrete IP with YOUR_E3DC_IP. Modbus TCP Bridge gets online with any valid IP-Address,even if you type 99.99.99.99 it go’s online. So please double check valid IP!

I already adopted my real E3DC IP address :slight_smile:

[16:01:46] root@openHABianPi:~# cat /etc/openhab2/things/e3dc.things
Bridge modbus:tcp:solar "E3DC Modbus TCP" [ host="192.168.4.77", port=502, id=1 ] {
        Bridge e3dc powerplant "E3DC Power Plant" [ refresh=2500 ] {
                Thing e3dc-wallbox wallbox0             "E3DC Wallbox"                          [ wallboxId=0]
        }
}

[16:03:10] root@openHABianPi:~# head /etc/openhab2/items/e3dc.items
Group                      e3dc
Group                      gE3DCPersist

String                     E3DC_ModbusId                      "E3DC Modbus ID"                      (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#modbus-id" }
String                     E3DC_ModbusFirmware                "E3DC Modbus Firmware"                (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#modbus-firmware" }
Number                     E3DC_SupportedRegisters            "E3DC Supported Registers"            (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#supported-registers" }
String                     E3DC_Manufacturer                  "E3DC Manufacturer"                   (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#manufacturer-name" }
String                     E3DC_ModelName                     "E3DC Model"                          (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#model-name" }
String                     E3DC_Firmware                      "E3DC Modbus ID"                      (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#firmware-release" }
String                     E3DC_SerialNumber                  "E3DC Modbus ID"                      (e3dc)              { channel="modbus:e3dc:solar:powerplant:info#serial-number" }

Unfortunately i see only E3DC Modbus TCP in the Paper UI “Things” section. E3DC Power Plant and E3DC Wallbox is missing. Furthermore TRACE logging doesn’t create any more hints:

2020-09-21 16:01:05.956 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'e3dc.things'
2020-09-21 16:01:05.982 [DEBUG] [modbus.internal.ModbusHandlerFactory] - createHandler Modbus tcp
2020-09-21 16:01:05.990 [TRACE] [very.internal.ModbusDiscoveryService] - Received new handler: org.openhab.binding.modbus.discovery.internal.ModbusEndpointDiscoveryService@d4784d
==> /var/log/openhab2/events.log <==
2020-09-21 16:01:05.998 [hingStatusInfoChangedEvent] - 'modbus:tcp:solar' changed from UNINITIALIZED to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2020-09-21 16:01:06.012 [TRACE] [r.AbstractModbusEndpointThingHandler] - Initializing modbus:tcp:solar from status INITIALIZING
2020-09-21 16:01:06.016 [TRACE] [r.AbstractModbusEndpointThingHandler] - initialize() of thing modbus:tcp:solar 'E3DC Modbus TCP' finished
==> /var/log/openhab2/events.log <==
2020-09-21 16:01:06.023 [hingStatusInfoChangedEvent] - 'modbus:tcp:solar' changed from INITIALIZING to ONLINE
==> /var/log/openhab2/openhab.log <==
2020-09-21 16:01:07.037 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'e3dc.things'

Which openhab version do you have running? Is it smaller than 2.5.7?

You have installed the add on?

I’ve installed 2.5.9 today, that’s why i found out that the E3DC binding is included now.

As far as i understood, e3dc is part of the modbus binding, right? I don’t find a seperate binding neither in Paper UI nor in Karaf console

openhab> feature:list | grep -i modbus
openhab-binding-modbus1                           │ 1.14.0           │          │ Uninstalled │ openhab-addons-legacy-2.5.9 │ Modbus Binding (1.x)
openhab-transport-modbus                          │ 2.5.9            │          │ Started     │ openhab-addons-2.5.9        │ Modbus Transport
openhab-binding-modbus                            │ 2.5.9            │ x        │ Started     │ openhab-addons-2.5.9        │ Modbus Binding

Nope. E3DC is an add-on to the standard Modbus binding. I don’t know where you"d find it to install it, may not be in the usual place since it is not a standalone binding.

Karaf confirms you have not installed it so that would be why it does not work.

Does it work with the new easy-connect wallbox ? I already use the modbus-binding with my S10E Blackline but cannot get the Sun-Mode Switch to function correctly. I tried with your implementation but i think it just works with the old (white) wallbox.

if i switch it off or on it just stays null:

2020-09-21 19:27:33.327 [ome.event.ItemCommandEvent] - Item ‘E3DC_WB_Sunmode’ received command OFF
2020-09-21 19:27:33.329 [nt.ItemStatePredictedEvent] - E3DC_WB_Sunmode predicted to become NULL

EDIT: It seems like its not possible to add a second bridge in the things-file or add a second modbus-bridge with the same ip-address.

During Development I placed my bundle into the addons folder. With this I got the following options when adding a Modbus Thing manually
paperui-modbus

Can you check if this option is available for you?
If not I think @ssalonen can help with installation!

I’ve a Easy Connect Wallbox attached. Switching Sunmode works pretty well.

I don’t know your configuration but setting things up from scratch Own Modbus TCP Bridge + E3DC Bridge + Wallbox works with the same IP Address.

This is my Configuration:

I already got most of the Things i needed and just wanted to add the Wallbox to the Bridge (at the bottom), but it does not appear in the PaperUI and no entry in the openhab.log either.
I may just start from scratch and remove my Polling Bridge to get this working.

Bridge modbus:tcp:e3dc “E3DC Modbus TCP” [ host=“10.0.6.111”, port=502, id=1 ] {
Bridge poller polling “E3DC Modbus Poller” [ start=0, length=104, refresh=30000, type=“holding” ] {
Thing data PV_Inverter “E3DC Inverter” [ readStart=“67”, readValueType=“int32_swap”]
Thing data Battery “E3DC Battery” [ readStart=“69”, readValueType=“int32_swap”]
Thing data Consumption “E3DC Consumption” [ readStart=“71”, readValueType=“int32_swap”]
Thing data Grid “E3DC Grid” [ readStart=“73”, readValueType=“int32_swap”]
Thing data External “E3DC External” [ readStart=“75”, readValueType=“int32_swap”]
Thing data SelfConsumption “E3DC SelfConsumption” [ readStart=“81.0”, readValueType=“uint8”]
Thing data Autarky “E3DC Autarky” [ readStart=“81.1”, readValueType=“uint8”]
Thing data SoC “E3DC Battery SoC” [ readStart=“82”, readValueType=“uint16”]
Thing data String1_Voltage “E3DC String 1 Voltage” [ readStart=“95”, readValueType=“uint16”]
Thing data String2_Voltage “E3DC String 2 Voltage” [ readStart=“96”, readValueType=“uint16”]
Thing data String3_Voltage “E3DC String 3 Voltage” [ readStart=“97”, readValueType=“uint16”]
Thing data String1_Current “E3DC String 1 Current” [ readStart=“98”, readValueType=“uint16”]
Thing data String2_Current “E3DC String 2 Current” [ readStart=“99”, readValueType=“uint16”]
Thing data String3_Current “E3DC String 3 Current” [ readStart=“100”, readValueType=“uint16”]
Thing data String1_Power “E3DC String 1 Power” [ readStart=“101”, readValueType=“uint16”]
Thing data String2_Power “E3DC String 2 Power” [ readStart=“102”, readValueType=“uint16”]
Thing data String3_Power “E3DC String 3 Power” [ readStart=“103”, readValueType=“uint16”]
Thing data Wallbox_Power “E3DC Wallbox” [ readStart=“77”, readValueType=“int32_swap”]
Thing data Wallbox_PV_Power “E3DC Wallbox PV” [ readStart=“79”, readValueType=“int32_swap”]
}
Bridge e3dc powerplant “E3DC Power Plant” [ refresh=2500 ] {
Thing e3dc-wallbox wallbox0 “E3DC Wallbox” [ wallboxId=0]
}
}

Unfortunately not. All other modbus extensions seem to work.

[21:26:12] root@openHABianPi:/var/lib/openhab2# find . | grep modbus
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/2.5.9
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/2.5.9/org.openhab.binding.modbus.sunspec-2.5.9.jar.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/2.5.9/org.openhab.binding.modbus.sunspec-2.5.9.jar
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/maven-metadata-openhab.xml
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/maven-metadata-openhab.xml.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus.sunspec/resolver-status.properties
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/2.5.9
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/2.5.9/org.openhab.io.transport.modbus-2.5.9.jar
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/2.5.9/org.openhab.io.transport.modbus-2.5.9.jar.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/maven-metadata-openhab.xml
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/maven-metadata-openhab.xml.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.io.transport.modbus/resolver-status.properties
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/2.5.9
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/2.5.9/org.openhab.binding.modbus-2.5.9.jar
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/2.5.9/org.openhab.binding.modbus-2.5.9.jar.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/maven-metadata-openhab.xml
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/maven-metadata-openhab.xml.sha1
./tmp/mvn/org/openhab/addons/bundles/org.openhab.binding.modbus/resolver-status.properties

@ssalonen to the rescue, pls!

This. You haven´t installed the binding?

Can you do bundle:list -s|grep modbus

Created https://github.com/openhab/openhab-addons/issues/8538. It seems that the new modbus based bindings, such as e3dc, might be missing in some of the openHAB “manifests”… This might explain why you have trouble with the installation.

2 Likes

During my development I didn’t pay much attention on the installation procedure. But now I’m also a bit confused.

Does it mean if I install Modbus binding all extensions (Studer, Stiebel Eltron, Helios, E3DC, …) are installed automatically? Isn’t this contrary to the normal Binding installation which is quite selective?

Also from User perspective I see some issues. If you want to integrate a device you’ve this big list with all available bindings. You can search for Stiebel Eltron but you don’t find it - seems it’s not supported. But it’s only hidden behind the Modbus Binding. Shouldn’t it be more present in the binding list?

1 Like

I think this is exactly the same as with bluetooth binding.

I see, but it’s the same problem. E.g. the DaikinMadoka Thermostat is behind the bluetooth Binding. So looking through the Binding list I can find the Daikin Air Conditioning but not the corresponding Thermostat.

Please don’t get me wrong. I’m not addressing a technical issue. From technical point it’s totally right: You’ve a protocol and based on that several extension. I just doubt this is the view of a lesser technical experienced user.

Imagine the following:
I prepare a brilliant Rest API Binding which takes care of connections, timeouts, error handling, OAuth & Token handling. As a result all web based bindings shall be based on this and are just extensions.
Spinning this even further Binding Installtion refers to a bunch of protocols and the real devices are behind them.

For this particular case I would say you want to install E3DC Binding and the Modbus Binding is simply a dependency. With this each user can install devices without knowing the protocol behind it.

Again: Don’t understand me wrong. I don’t press for a solution right now. But in general I think it’s worth a discussion if the Protocol Extensions is the right way to proceed.

What do you think about this?

2 Likes