During Development I placed my bundle into the addons folder. With this I got the following options when adding a Modbus Thing manually
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
I must say that if these extensions are bundled in with generic Modbus binding, that surprises me too. Sounds like bloatware 
Addressing that as it stands now is just a case of adding explanatory words to the doc pages.
Yeah I think the maintainers have opted to follow the same approach even though it might not make sense here.
Original discussion was with sunspec https://github.com/openhab/openhab-addons/pull/6331#discussion_r410307406
I actually do agree, I argue that most people have at most one type of modbus device, not more. It would be therefore reasonable to install them one by one. The ui would not be bloated of different type of modbus devices that you would not work with.
You could raise this up in the github issue I referred to, perhaps it can be adjusted for oh3
This does seem like the opportune time to properly consider this, and implement if needed. I’ll have a think about raising a more generic Github issue.
2 Likes
Yes, I think a more generic issue is the better way. The Issue @ssalonen raised is already solved in a Pull Request
@rossko57 Will you raise one? If not I’ll raise the github issue.
2 Likes
Pull request from @bern77 was closed actually (due to target wrong branch) so the immediate problem remains still.
I am not quite sure now the situation with openhab 2.x vs 3.0… Will there be new 2.x addon releases?
I think we might be on the last 2.5.x version already
1 Like
As you can see the installation is broken. Honestly I don’t know if there will be a fix release for 2.5.9. I can only offer to place the latest Release Candiadte into the openhab2-addons folder.
This was a first stab at a fix but my understanding out of this was also that 2.5.9 should be the last release in the 2.x version.
I understand that https://github.com/openhab/openhab-addons/pull/8575 does the same for the main branch now, so there the problem should be fixed.
I’m really not sure if there’s a way to offer the extensions other then providing download links to the JARs…
Did that, without any visible change. Afterwards i’ve added modbus-e3dc to /etc/openhab2/services/addons.cfg, but this didn’t worked well:
2020-09-28 09:34:03.813 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-modbus-e3dc'
Any suggestions?
I don’t think addons.cfg needs to be adapted. I just dropped my bundle in the addons folder - that’s it! So after copying the bundle into addons folder you’re still not able to see E3DC devices in PaperUI via Modbus Binding?
Correct, i’ve just dropped the jar bundle and even restarted openHAB without success.
[19:30:54] openhabian@openHABianPi:~$ ls -lah /usr/share/openhab2/addons/
total 92K
drwxrwxr-x+ 2 openhab openhab 4.0K Sep 28 09:21 .
drwxrwxr-x+ 4 openhab openhab 4.0K Sep 21 09:51 ..
-rw-rw-r-- 1 openhab openhab 77K Sep 28 09:21 org.openhab.binding.modbus.e3dc-2.5.8-SNAPSHOT.jar
-rw-r--r-- 1 openhab openhab 70 Sep 20 19:12 README
