E3DC Binding (beta)
Version 2022-02-10
I updated the non-modbus binding E3DC binding
To get it working you need:
- OPTION A: Install the binding from the marketplace: openHAB 3 UI → Settings → Bindings → Community Marketplace (show more)
- OPTION B: Install the jar or kar linked at the end of this post
- 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
- Backup your openHAB - just in case
- Please, if it’s ot working for you add helpful information (trace logs, reproduction steps).
What’s new?
Compiled for and tested with version 3.2 (Marketplace ready) (Version 3.1 can be done on demand)
Sorry, no weather forecast details found so far.
Probably some new bugs
Changes
- Renamed thing to S10
- Refactoring (my personal taste, don’t know if it’s good)
- If “else if” then “switch” (for better readabillity)
- Improved connect routine
- Improved exception resistance
- Added Thing propeties (static information)
- Extended Thing config (forcing the number of tracker, pomermeters, wallboxes)
- Added powermeter query (3/8 for now, incomplete)
- Added wallbox query (2/8 for now, very incomplete) (not sure if the interface is happy with requests for non-existing devives/data)
- Added modbus query (incomplete)
- Added new RSCP-Tags based on the fantastic C# E3/DC RSCP Connection Lib - Is there a new RSCP Excel file???
- Prepared for i18n
- Added Channel Groups
- Added dynamic channels according to number of devices connected (~discoverd) or by forcing through thing config - changes after connection is established
- Split Thing, Group and Channel XMLs
- Added Debug switch to query (nearly) all TAGs (if logging is set to TRACE (sudo openhab-cli console // log:set TRACE org.openhab.binding.e3dc )
- Include Bounce Castle V1.68 in jar/kar, no seperate file needed, but increased filesize therefore
ToDo
- Pull request @bjoernbrings as he’s the creator of this binding
- get new version for RSCP documentation
- translations
- fix wording and interpretation of RSCP Namespace abbreviations
- complete channels
- Issue: Incomplete telegrams: Only 1448 Bytes received (TCP window issue?!)
- Handle Error codes ( NotHandled = 0x01, AccessDenied = 0x02, Format = 0x03, Again = 0x04, OutOfBounds = 0x05, NotAvailable = 0x06, UnknownTag = 0x07, AlreadyInUse = 0x08)
- change default update intervall to 5? 10? 20? seconds
- query RSCP namespaces only if channels linked to item. Manage map in channelLinked and channelUnlinked (or even TAGs only…)
- fix code for merge (@NonNullByDefault, …)
- fix “Classes found in the wrong directory: {META-INF/versions/9/org/bouncycastle…”
- reduce logging
- fix channel names/IDs (similar to E3DC Modbus Binding?)
- fix channel categories
- fix state objects show dates (I’m to dumb for this)
- fix/force order of thing properties (how?!)
- complete requests (EMS, PVI, BAT, DCDC, PM, WB)
- split wallbox request to one or two request per wallbox ?
- actions for manual charge, … (EMS)
- actions for system reboot, aplication restart (SYS)
- action for update check (UM)
- remove info channel, as thing properies are implemented now (except for time/time zone)
- analyze and implement Home Automation requests (HA)
- manage Home Automation equipment (ADD_ACTUATOR, REMOVE_ACTUATOR, COMMAND_ACTUATOR, COMMAND, DESCRIPTIONS_CHANGE, CONFIGURATION_CHANGE_COUNTER) (HA)
- get constant values from RSCP resulst (e.g. max values for MaxDischargePower from TAG_EMS_SYS_SPEC_NAME maxDischargePower )
Maybe
- analyze and implement Farming Systems requests (FMS)
- implement thing “Quattroporte” (stupid name btw)
- more dynamic and less hardcoded channel handling (Map RSCP-Tag-name ↔ channel-name)
Contribute
UI / UX
Any hints for typos wrong descriptions or wrong behaviour are welcome. Feature request/hints are welcome.
Whenever to binding stops working please check the logs, for an error message (or even better: stack trace).
Extending and ensuring functionally
Make sure to anonymize the last 6 digits of your SERIAL NUMBER
Make sure you deleted your MAC ADDRESS
Make sure you deleted any other personal data
It would be great if you could support us in completing this binding.
We need information / debug trace (see above - change log level back afterwards!!!) for:
- different S10 models (Mini, S10-E 10-X, PRO, Compact, …)
- 1-n wallboxes
- 1-n powermeters (tested with 2)
- 0-n trackers (could be that only external power generators are connected)
- 0-n external power generators
- 0-n Home Atuomation equipment
Easiest would be to get the logs from the openHAB LogViewer (fronttail): http:\SERVERNAME:9001
Upload a file somewhere (gist.github.com) and link it here
or paste the (stripped down) log here inside(!) code fences - three backticks before and after the logs.
*```
* Text inside a code block
*```
(ignore the asterisk in the sample)
Make sure to anonymize the last 6 digits of your SERIAL NUMBER
Make sure you deleted your MAC ADDRESS
Make sure you deleted any other personal data
Code
Im not good a git. Never handled a pull request, but I’ll do my best to manage yours.
Don’t know how the rules are, but if allowed you could send smaller code changes in the forum. Needs to be clarified.