Hey Matthias,
Indeed. That is a bug. I was about to develop some new feature (fetch data from last 24h but unfortunately I don’t understand the return values) and this is the trace (which I put to WARN to easily get it in my dev environment)
There is a Tag called TAG_EMS_REQ_GET_MANUAL_CHARGE. But what is your use case? From the limitations (once per day) I would not use that in daily operations but happy to learn differently.
Great to see that the binding works with RSCP! Last year I implemented the E3DC Modbus Binding and it’s already part in the official deliveries. Modbus allows the control just for a few functions for Wallbox and I’m missing more control functionality.
Thanks for this starting point - I’ll cloning this one and start digging deeper!
hi Björn, the idea is that if the price for energy (aWATTAR) is negative that I have the option to feed the storage with energy from the grid. Nothing that happens daily but once in a while it happens.
Oh, missed that completely. Until I worked on this addon I have used some custom modbus solution.
Of course feel free to clone and go ahead. As I have no Wallbox I’ll be missing a lot of debug information on that.
Not sure whether you would be able to stop that process once triggered. Given that you could just trigger it once a day I guess that’s a statistical challange how much you want to load.
Technically that should be posstible with the flag I mentioned.
I think it is quite easy as it work as a switch. You start it with “Durchführen” and stop it with “Abbruch”.
There is a binding for aWATTAR (aWATTar binding: Anybody already working on it?) that get all the prices for the next day and also calculates the best time range and provides a switch that turns on when that time range start and turns off when its over. Everything else is doable as a rule.
Hi Björn
any chance you can fix the logging and add the TAG_EMS_REQ_GET_MANUAL_CHARGE ?
Thanks
Mathias
Hey Matthias,
the change in logging shouldn’t be too difficult. On the manual charge it’s a bit more difficult as I don’t want to test that in my environement. But with the changes from @Marco they should be quite straight forward to implement in a comparable way.
I recently integrated this binding in my environment and it mostly works fine. Thanks for all the effort.
But I also see, that it sometimes freezes, so data isn’t updated anymore. If I change the polling intervall from 60s to 1s and back to 60s, it works again. Do you experience something similar or is it maybe connected to my setup (OH3, Rapi 4)?
You’re referring to the current modbus binding, right?
I don’t know about any general performance problems right now. Basically I’ve the same setup with OH3 and Raspi 4 and it runs quite stable with 2 sec update and a constant CPU & Memory usage below 10%. Please check your system with top command if you’ve some disturbing side tasks on your Raspi.
The addon link in the first post is dead… How can I get the file ?
@bjoernbrings my skills are too bad to help I think, but do you know E3DC Control Projekt ?
Maybe you can get something out of it…
Regards
Jörg
Hey Jörg,
updated the link. Thanks for the hint.
Yeah, I know that code. It has some features around wallbox, etc. that I didn’t implement given that I don’t own that (so no testing possible).
Best,
Björn
Dear all.
Somehow I cannot make it work yet. I want to move from the modbus to this binding to control battery charge/discharge. I placed the files in the addon folder, in the addons.cfg file I added “e3dc” to the bindings. The logger tells me that e3dc cannot be found and is ignored.
I’m running oh3 (3.1.0-release) on a PI 4.
Hi @bjoernbrings,
I have a heatpump with an extra e3dc power meter (Leistungsmesser), how can I ad a channel ?
Or can you add the channels for this ?
Strange. Usually placing in the addon folder should be enough. Did you try to configure via UI?
Unfortunately those channels need to be added first in the binding & recompiled and as I didn’t have any usecase for that I didn’t add them.
Did not work for me either, Error is:
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.e3dc [294]
Unresolved requirement: Import-Package: javax.measure; version="[1.0.0,2.0.0)"
someone posted a solution for a different version:
scottrScott Radner
Exact same issue here. I was able to solve this temporarily by adding an explicit dependency in pom.xml
<dependencies>
<dependency>
<groupId>javax.measure</groupId>
<artifactId>unit-api</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
Just built the jar against the latest nightly (see first post; @Michael_Walter not sure what problem you had, didn’t have any issues to compile)
@vbbaby3
New channels are not too difficult, but given I couldn’t spot them easily in the RSCPTags file that will be likely the hardest part.
You could try to play with the function buildRequestFrame in E3DCRequest. You could play around with the buildFrame functions and see from the result in the debug logs which data you might be looking for.
Ah, sorry, I did not specify which version I used. I used @mal version of the binding, since I wanted to test out the power setting writing capabilities.