-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[e3dc] E3DC Home Power Plant Binding contribution #8172
Conversation
Please stick with this PR. If you messed up rebasing, it can be fixed in this PR without creating a new one. |
|
Travis tests have failedHey @weymann, |
It's a general issue. Nothing has to be done from your side. |
Travis tests have failedHey @weymann, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution, again! Here is my feedback.
Did you take a look into the modbus binding? Maybe you could've saved some code by utilizing it like #8163.
bundles/org.openhab.binding.e3dc/src/main/resources/ESH-INF/thing/thing-e3dc-strings.xml
Outdated
Show resolved
Hide resolved
bundles/org.openhab.binding.e3dc/src/main/resources/ESH-INF/thing/thing-e3dc-strings.xml
Outdated
Show resolved
Hide resolved
bundles/org.openhab.binding.e3dc/src/main/resources/ESH-INF/thing/thing-e3dc-wallbox.xml
Outdated
Show resolved
Hide resolved
bundles/org.openhab.binding.e3dc/src/main/resources/ESH-INF/thing/thing-e3dc-wallbox.xml
Outdated
Show resolved
Hide resolved
...penhab.binding.e3dc/src/main/java/org/openhab/binding/e3dc/internal/handler/BaseHandler.java
Outdated
Show resolved
Hide resolved
Hi, maintainer of the modbus binding/transport here. Happy to see new binding popping again! I hope you would reconsider that you would "extend" on top of the I can see how you want to avoid complex rules etc., this is exactly the use case for device specific bindings! Instead of directly interfacing with the transport, you would reuse Many (all?) other modbus-based bindings follow the same approach,
This allows user to configure the connection details (e.g. retry interval, how long to keep the connection open, connection retry interval etc.). A comment on thing hierarchy: Some bindings have opted for single thing (representing the physical device?) with multiple channel groups, making the configuration even more simple. See e.g. sunspec docs . If you always poll the same registers and there's no variation (e.g. different model variations represented by "Blocks"), this could make sense here as well -- reducing the number "things" user needs to configure and define? All data would be readily available, one just needs to link it to items. |
...ing.e3dc/src/main/java/org/openhab/binding/e3dc/internal/handler/E3DCDeviceThingHandler.java
Outdated
Show resolved
Hide resolved
...ing.e3dc/src/main/java/org/openhab/binding/e3dc/internal/handler/E3DCDeviceThingHandler.java
Outdated
Show resolved
Hide resolved
...nhab.binding.e3dc/src/main/java/org/openhab/binding/e3dc/internal/modbus/ModbusCallback.java
Outdated
Show resolved
Hide resolved
...nhab.binding.e3dc/src/main/java/org/openhab/binding/e3dc/internal/modbus/ModbusCallback.java
Outdated
Show resolved
Hide resolved
...nhab.binding.e3dc/src/main/java/org/openhab/binding/e3dc/internal/modbus/ModbusCallback.java
Outdated
Show resolved
Hide resolved
...nhab.binding.e3dc/src/main/java/org/openhab/binding/e3dc/internal/modbus/ModbusCallback.java
Outdated
Show resolved
Hide resolved
thanks for giving feedback to my Binding contribution. Let me explain my design approach and the reason why I started this way: I got my E3DC system in April 2020 and I prepared my openHAB setup based on this Community post: https://community.openhab.org/t/e3dc-with-the-new-modbus-binding/51345 In June a new Modbus Spec (only available in German) was released by E3DC which I placed temporarily here https://github.com/weymann/openhab-addons/blob/e3dc-test/bundles/org.openhab.binding.e3dc/test/spec/ModBus_E3DC_Speichersysteme_V1.70_2020-06-18.pdf. With this some of my problems began: First aspect Second aspect Third aspect My conclusion |
Hi @weymann thanks for the reply. Yeah I noticed I as well replied to the original thread at the time (https://community.openhab.org/t/e3dc-with-the-new-modbus-binding/51345/2) :) I think you are misinterpreting my suggestion, let me try to re-explain. I'm not advicing to come up with complex rules to process the data and force yourself to work with generic modbus binding. The whole setup is designed to accomodate device specific bindings, that's completely OK. Instead, I'm advicing you to follow the advice set in In essence: you would still interact with the transport bundle, that's OK. You would just reuse the Thing hierarchy could look like (keeping blocks as separate thing types)
User would need no additional rules or processing in place -- that's the job of the binding as now. You would still interact with You might ask why do it this way?
(*) Not sure how relevant this argument is with this particular device. If it is only available as TCP, I have hard time seeing anyone converting modbus TCP to Modbus RTU serial. Obvious downside is that you end up having one more thing representing the connection type to the device. My other comments was related to channel / thing setup. This is a separate discussion. A completely separate discussion is whether you should combine all the different e3dc thing types into one thing type. Instead of having e3dc-info, e3dc-power, etc., you would only have one thing type In general I have understood this is the intention with the thing system (docs), trying to keep openHAB things represent physical things if possible, and channels exposing thing's functionality. |
To make my point more clear, see this quick & dirty conversion of having single thing, using Hopefully this made my message more clear. Let me know what you think |
Thanks @ssalonen for the code example, I think I got the idea. I'll put the "work in progress" label onto this Pull Request and evaluate your example in my enrionment. Give me some time to figure it out and I'll come back with an updated version. |
@weymann glad to hear it! Let me know if I can help out in any way |
Hey @ssalonen ! Time for a short pre-review? Perhaps you can give me a helping hand on modbus error handling. I don't know the appropriate actions if an error occurs. Do I have to stop the Poller? Is it automatically stopped and if yes shall I introduce a timer for recovery? Test bundle is updated here https://github.com/weymann/openhab-addons/tree/e3dc-test/bundles/org.openhab.binding.e3dc/test |
I had a quick look and looks like good stuff to me! With errors you probably want to update thing statuses to offline with COMMUNICATION_ERROR as reason. You can also provide textual description of what failed (was it eg the write or reading of data). I would keep the polling going, essentially retrying again after a while. Thing status should be updated back to ONLINE once read / write is successful. |
Btw, a small thing If you want to remove some code you could listen for children things with childHandlerInitialized and childHandlerDisposed, and tracking them in a collection. I don't think you really need DataListener, you could just deal with the concrete wall box class in e3dc thing. In fact, are the wall box data listeners deregistered in the current implementation? Check out poller implementation for inspiration https://github.com/openhab/openhab-addons/blob/2.5.x/bundles/org.openhab.binding.modbus/src/main/java/org/openhab/binding/modbus/handler/ModbusPollerThingHandler.java |
Now with #8218 in, please also handle the EndpointaNotInitialized exception |
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Travis tests were successfulHey @weymann, |
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Travis tests were successfulHey @weymann, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your changes look good! I found a few minor things I overlooked during the first review. Sorry for that.
...ng.modbus.e3dc/src/main/java/org/openhab/binding/modbus/e3dc/internal/dto/DataConverter.java
Outdated
Show resolved
Hide resolved
.../src/main/java/org/openhab/binding/modbus/e3dc/internal/handler/E3DCWallboxThingHandler.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Travis tests were successfulHey @weymann, |
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Travis tests were successfulHey @weymann, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for you contribution. I've not really something to comment, just a question (and a informative suggestion).
...g.modbus.e3dc/src/main/java/org/openhab/binding/modbus/e3dc/internal/dto/EmergencyBlock.java
Outdated
Show resolved
Hide resolved
xmlns:thing="https://openhab.org/schemas/thing-description/v1.0.0" | ||
xsi:schemaLocation="https://openhab.org/schemas/thing-description/v1.0.0 https://openhab.org/schemas/thing-description-1.0.0.xsd"> | ||
<channel-group-type id="info-values"> | ||
<label>Information</label> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These channels look more like properties of a thing/bridge? Maybe this was discussed before, but is there a reason to create channels instead of properties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was one remark regarding properties and as result the implementation contains a "low speed" update of these registers while Data is updated frequently.
Several enrties will change due to remote updates like Modbus Firmware Version, Supported Registers and Firmware. After the Device Installation the Serial Number wasn't set and was updated remotely. Also the Modbus-ID can change because you can operate the device either in Sunspec Mode or in the Manufacturers own Mode.
In addition I would like to have these values in my UI. It's quite handy to check currently installed Software Versions for Support. With Properties I have to change to PaperUI, search the device and check the properties. On Smartphone I didn't find a possibility to check properties yet.
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Travis tests were successfulHey @weymann, |
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com> Signed-off-by: Daan Meijer <daan@studioseptember.nl>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Signed-off-by: Bernd <bernd.weymann@gmail.com>
Binding for the E3DC Home Power Plant (https://www.e3dc.com/). It provides all information regarding Photovoltaic Production, Household Electric Power Consumption, detailed Photovoltaic String values, Emergency Power Settings and attached Wallboxes. Some Wallbox Settings can be changed and give you even more Control. It’s based on org.openhab.io.transport.modbus
I didn’t choose a pure Modbus Binding for the following reasons:
The overall design looks like this: org.openhab.io.transport.modus bundle polls Modbus registers and provides byte arrays. The Data Transfer Objects are translating bytes into Strings, Numbers and Bits. Handlers takes care to distribute the data to the correct Channels.
Test bundle plus configuration is available here https://github.com/weymann/openhab-addons/tree/e3dc-test/bundles/org.openhab.binding.e3dc/test