It was a long wish of mine to replace the nice modbus solution (to connect my E3DC) with a proper binding.
This binding is not based on modbus as this has several restrictions (few values, readonly, …) but the AES encrypted RSCP. I could just come to this point as @bvotteler has already solved nearly all the struggl around RSCP and AES in his library and example.
There is an early stage prove of concept which I would love to share (by now it’s read-only). Please expect to find bugs and please expect that the code is far away from being ready to start the merge process (expect some log-noise).
To get it working you need:
Two files
– the addon V3.1V3.2 and
– the bouncycastle encryption lib that both should be placed in the Addon directory of a version 3+ openHAB installation.
You need to have the E3DC portal registered (username, password) and in the E3DC an RSCP password set. Furthermore you need the IP adresse of the E3DC device
With that you should be able to setup the thing.
How would I like the work to continue:
There is a ton of data that one could get from the RSCP protokoll. I pulled with a test programm everything I could get but for a lot of data I don’t have any clue what it is about and what we could use it for, so I’d be happy for any suggestion what data is useful/any usecase. Data that could be pulled are (very likely) strings from the tags that include the string ‘REQ’
In the same file there are some ‘SET’ activities that correspond to writing. I didn’t look into that deeper.
From another example (function ControlLoadData line 116) I’d conclude that TAG_EMS_REQ_SET_POWER_MODE is quite interesting to steer when and with what power the battery is (un)loaded (so switch from auto to manual mode)
Get the code merge-ready …
If you want to have a look at the current state of the code you can find it here.
Björn thanks for your work. Out of the box it works. As posted before, I would like to replace the calculation of energy consumption, with pulling it directly form the E3Dc. This is an appreciated feature .
Sadly my circuit brakers form the batteries come today, so I assume I have some failure in the controlling board or the batteries. In best case they are only deeply unloaded. So I have to wait for the service before I can test the binding further.
Thanks for the feedback. Touch I have an example I’m struggeling a bit with the precision as I tried to rebuild the daily figures that I could see on the E3DC page. Unfortunately it’s not possible to get just some counter but only the values for a range. Not sure which range would be best for a openHAB addin: daily, hourly, 5 min, time between pulls, …
Will add that to the list of features that I try to implement first.
I know the pulling is done via range. As I remember E3Dc is publishing every 15 min into their cloud service. But every 5 min is nice, if you want to do persistence within Openhab.
In KNX you can create new channels to every thing you created. I don’t know if it is possible, to make it flexible to everybody, the binding can provide such channels, where you can create defined ranges for day, weeks, month, as you like. But this is for sure a deluxe solution.
Because my system has had a failure, I had a call yesterday. E3Dc is checking some parameters, such Battery Temp, voltage between battery cells. This is only for surveillance or predicative maintenance but no real use case. But Errors would be helpful.
Additional Use Case, in the E3Dc App there is a forecast available providing the amount of energy possible available during the day. I have to admit I didn’t find it within the RCSP documentation.
Additional Use Case not for me today, but maybe for others, Charging from E-Vehicles. Releasing Charing, or Stopping.
But in the end pretty amazing how fast the first version was available. Thanks a lot for your work.
For better understanding (though with german texts) I put the channel names on a screenshot of the E3DC S10 Portal.
Setting PowerLimitsUsed to off, resets the enclosed charging values. I’m not sure yet what happens if the values get changed afterwards. They should be ignored…
I have not yet tested the binding as currently use the Modbus binding.
Is it possible with this binding to get the predicted kWh from E3DC. In the portal I see todays and tomorrows prediction and I find usefull to have that information in openhab as well.
Thanks.
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.
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.
.
