Repository navigation
Replies: 14 comments 13 replies
|
Hi all, Thank you for your effort. I am in a similar situation because I have at home a Wolf heatpump (CHC/CHA) with Solar module SM-1 and control module BM-2. As you can see in #776 I am encountering difficulties getting the data (also getting devices to properly show up). I checked out your files in the 22.4.x/de folder and I am currently using them, just restarted ebusd. Please count me in if you need any further information, as I can debug and give data from the system. Mainly because I want this to work :D |
|
My System Layout as Example and a small update on whats going on I have a CGB-35 with BM integrated and directly controlling the hot water tank I scanned my bus and sorted the devices by id and function. I see this communication on regular basis:
Most communication uses the speced protocol messages. |
|
Hello! Currently i cannot get the .csv stuff to work Is this as it looks at your setup: 1 directory, 5 files Greetings |
|
I just pushed my latest working config into my github repro for you to checkout |
Ohh my setup was rubbish, its however working now using other .csv's |
|
@ulda you are correct, that there is no publicly available documentation from Wolf regarding their messages on the ebus, but they published a desktop application in the past and are still publishing an android app which contains metadata files with all information needed to map ebus addresses to readable names and even find out which are supported by a concrete setup. I've "looked closely" at the Wolf Smartset application (and written an ISM to MQTT Adapter). I've already linked the information in #460 (comment) and hoped it would spread further within this community. This tool is not directly talking to the bus, but to an ISM module from Wolf, which basically translates XML to ebus. In the meantime i also extracted, packaged and used the official binaries in a tool to automatically extract all parameters from a given setup without the requirement to run the Wolf app just by connecting to the ISM. So from a user perspective (with the required hardware) it's just:
and you have read and write access to all parameters I haven't thought this through, but I'm pretty confident that it should be possible to write some kind of adaptation layer which translates the protocol from the official app to ebusd or some kind of adapter and thus be able to use the app to extract the exact configuration needed for ebusd. So it should be possible to get the same experience of "run this binary to generate a complete config" for users with an ebus adapter/without an ISM. |
|
Hi, is this topic still relevant? I actually only want to read out 3 values, pump on or off, temperature in the solar buffer and the modules on the roof. Thanks this is how it looks at the moment: root@vclin:~# cat /var/log/ebusd.log |
|
#950 helped a lot. At least I have some basic fields working now, working on getting more to work. |
|
Hi there, i'll probably tackle what @zivillian talked about in the near future about generating the config files from the xml files. So it would probably go like: Few things:
I havent used ebusd a lot but from what i can see around forums and in ebusd wolf has two "special" messages:
I now provide a more reasonable way to inspect the xml files, a json file compiled from the xml files in case anyone wants to take a look at them if they are missing definitions. LIST OF WOLF DEVICES THE APP RECOGNIZES: My device is a COB this means that i can search for that in the json: {
"DTID": "90000",
"name": "COB",
"parameters": [Then inside the parameters array you can find the parameter you want to read/write by their name, for example "Boiler water temperature": {
"type": "NumericParameterDescriptor",
"PTID": "90001",
"name": {
"DEU": "Kesseltemperatur",
"ESP": "Temperatura caldera",
"GBR": "Boiler water temperature"
},
"RemoveConditionId": "False",
"ReadOnlyConditionId": "True",
"InactiveConditionId": "False",
"IsSnapshotTransmitEnabled": "false",
"Decimals": "1",
"ControlType": "NumericInput",
"converter": {
"type": "NumericConverter16Template",
"TelegramNr": "13",
"Type": "SS10"
},
"read_command": "CC0D00"
}Again i have no clue what half of the things mean and its even missing many others that i didnt believe to be relevant, but they seem pretty self explanatory. ReadOnlyConditionId probably means that the parameter is read only. Then "converter" is the important part, it tells you how to read/write the value, in this case our dear neighbor zivillian already did the hard part in https://github.com/zivillian/ism7mqtt So we know that TelegramNr is what you need to send transformed the following way (Python for convenience): def telegram_to_read_command(telegram_num):
# Convert to hex, little endian, prefix with CC
hex_str = f"{int(telegram_num):04x}"
little_endian = hex_str[2:] + hex_str[:2]
return "CC" + little_endian.upper()So 17 -> Gives us 0x0D00 -> CC0D00 According to #167 the CC part is irrelevant since its a CRC that wolf devices ignore so the TypeSpec template defaults it to 00 Then when you get the ebus response you need to convert it based on the "Type", again zivillian did the hard part, the options are: case "US":
result = JsonValue.Create(_value.Value);
break;
case "SS":
result = JsonValue.Create((short)_value.Value);
break;
case "SS10":
result = JsonValue.Create(((short)_value.Value) / 10.0);
break;
case "US10":
result = JsonValue.Create(_value.Value / 10.0);
break;
case "SS100":
result = JsonValue.Create(((short)_value.Value) / 100.0);
break;
case "SSPR":
result = JsonValue.Create(((short) _value.Value) * (1.0 / 255));
break;
case "US4":
result = JsonValue.Create(_value.Value / 4.0);
break;
case "IntDiv60":
result = JsonValue.Create(_value.Value / 60.0);
break;I havent looked what the equivalent is in ebusd for all of them but SS10 is temp10 in the TypeSpec. Full TypeSpec example that worked for my boiler: import "@ebusd/ebus-typespec";
import "./_templates.tsp";
import "../opdata_inc.tsp";
using Ebus;
using Ebus.Num;
using Ebus.Dtm;
using Ebus.Str;
namespace Wolf;
// 0x35 is my boiler, pure guess tho, i know its this one because of the few messages i can see in the bus
@zz(0x35) //
namespace hc {
/** Boiler temperature */
@id(0x0D, 0x00) // Message 0D00
@poll(2)
model BoilerTemp is ReadonlyRegister<temp10>;
/** Accumulator temperature */
@id(0x0E, 0x00) // Same reasoning as above but with TelegramNr 14 thus 0E00
@poll(2)
model AcumulatorTemp is ReadonlyRegister<temp10>;
}This "compiled" to this csv: type,circuit,level,name,comment,qq,zz,pbsb,id,*name,part,type,divisor/values,unit,comment
*r,
r2,Hc,,BoilerTemp,Boiler temperature,,,5022,000d00,value,,UIN,10,°C,temperature
r2,Hc,,AcumulatorTemp,Acumulator temperature,,,5022,000e00,value,,UIN,10,°C,temperatureI havent tried writing yet, but the json contains all possible values for write parameters: {
"type": "ListParameterDescriptor",
"PTID": "410010",
"name": {
"DEU": "Programmwahl",
"ESP": "Selección de programa",
"GBR": "Prog. select."
},
"RemoveConditionId": "False",
"ReadOnlyConditionId": "False",
"InactiveConditionId": "False",
"IsSnapshotTransmitEnabled": "true",
"MinValueCondition": "0",
"MaxValueCondition": "3",
"ControlType": "ProgramSelectionListView",
"KeyValueList": [
{
"key": "0",
"value": {
"DEU": "Standby",
"ESP": "Standby",
"GBR": "Standby"
}
},
{
"key": "1",
"value": {
"DEU": "Auto",
"ESP": "Auto",
"GBR": "Auto"
}
},
{
"key": "2",
"value": {
"DEU": "Sommer",
"ESP": "Verano",
"GBR": "Summer"
}
}
],
"converter": {
"type": "NumericConverter16Template",
"TelegramNr": "10100",
"Type": "US"
},
"read_command": "CC7427"
}If anyone knows how ISM7 identifies the devices it would be of great help. If its not possible i will just probably create the TypeSpec without |
|
Thank you @valonsodev for your detailed steps and for sharing this great discovery by @zivillian! Your description helped me a lot. The 5800 entries in the json file comprise 633 different commands, most of which have a unique meaning, even across different devices. Unfortunately, about 193 are duplicates whose meaning depends on the receiving device. Thus, it still remains to identify the devices at some point. I want to share this information as it could be helpful to build a common config for the WOLF devices. But I am not yet sure how to proceed from here. |
|
Hi everyone, great thread! I have a working Wolf CGW2 config, able to read quite a lot of data using the following csv: I only see 1 broadcast message on the bus, but can read values using polling and also via the force read in the command line. I have a wiring question though. I have my AM module integrated into the boiler (snapped in place into the unit) and have my ebus adapter wired to the ebus connection on the PCB. Is this the right way to do it? Or should my ebus adapter be wired "between" the boiler and the AM module? I was not able to write anything to the boiler (wanted to set DHW target), I get an error: Anyone got writing of settings working? |
|
I had success when I wrote to the BM2 instead of the boiler directly. So, instead of 03, try to write to 35 (BM2 address). I 'quick and dirty' added this line to my 35..bm2.csv and it works: |
|
I don't have a BM2. My AM is snapped into the boiler itself and my ebusd is connected to the ebus terminals in the boiler. I am not seeing the AM on the bus unfortunately. I was not able to figure out how to send a warmwater settemp command to the boiler. Heck, I was not able to send any write commands at all. |
|
Did you check whether your writing command actually works, despite the read timeout error? I had the same issue writing on a Wolf system (an FHA, actually, not a CGW2) and discovered that there was actually no answer to the master-slave command, despite the writing command was actually correctly executed. See the issue I raised here. Best |
|
For CGG-2 with BM: writing HG parameters to ZZ=03 (Feuerungsautomat) Ces1254 is right though: the read timeout on write doesn't necessarily For andrasg without BM2: the AM module snapped into the boiler is likely More details on what works/doesn't work for CGG-2 in our config: |
|
Hi all, |
|
Hi there! |
|
Hi guys, I answer here, as I plugged yesterday my Solar Module SM2 (with BM2 screen) via eBus (device EBUS to WiFi Adapter Module V6.3) to my home assistant server running MQTT and ebusd. At first, I struggle to get it recognized, and finally I have the values I am looking for: (collector temp, solar tank exchanger temp, solar return line temp, pump state, and even pump hour meter). My install SM2/BM2 old genAlthough this is a new installation, I installed an old SM2 gen1 device I recovered. Firmware is old (228-02 on old SM2 motherboard). First of all, when configuring ebusd, I had to ignore enhanced mode (can't connect to bus), and switch to regular mode. In ebusd configuration, line "Network adapter address', I get rid of enh (enh:IP:port) and use IP:port instead (ie: 192.168.1.34:3333) with specific 3333 port (regular mode, read/write). At this stage, device was talking to ebusd and gives me warning about Kromschroeder device ID 76 not recognized. I found quickly that it is the same brand as Wolf, and a direct symbolic link exist in CSV conf. Working CSV FileAfter some struggling, I wrote this CSV file. Upload that file to your home assistant server in Values does not appears in MQTT device (solved)I was annoyed with values not showing in MQTT device, but available in MQTT data (using MQTT explorer). Other valuesI tried map other values, like yield day, yield total, but it does not work (returning 0). Hope this helps! |
|
I've been running a Wolf CGG-2-18 with BM control module on ebusd for a while now and finally got around to publishing the configuration. Full stack including MQTT auto-discovery for Home Assistant: A lean version (CSV only) was also merged into puni2k's collection: Happy to answer questions. |
|
One more finding: the Wolf BM has no battery-backed RTC and loses its time and date Documented with shell command and HA automation notes here: |
|
The BM has no battery but is has a goldcap. Mine was broken, afer replacing it, it keeps its time. |
|
Good to know — thanks for the hardware tip! The goldcap explains a lot. The software workaround via ebusd is still useful as a fallback for extended outages where even a healthy goldcap runs out, or simply for those who prefer not to open up the boilers "brain" physically. ;) |
|
Some findings from a Wolf CGU-2-10 + old BM (ebusd 26.1 HA add-on, adapter v5), in case they help others: 1. Output A1 (circulation pump) is readable at the boiler 2. BM DHW setpoint and operating mode – read AND write at slave Mode values verified at the BM: 1 = off, 2 = timer, 3 = sun+DHW, 4 = moon+DHW, 5 = DHW only. Changes show up on the BM display immediately. 3. Heating vs. DHW demand from broadcast Thanks to @dktzde for the CRC8 finding and to @realResi – both saved a lot of guessing. _homa |
Wolf boilers on ebusd: the checksum is solved — read and write every registerTL;DR — The mystery byte in a Wolf read telegram is a CRC8 with polynomial Tested on a Wolf FGB-K-28 (ebusd 25.1, eBUS shield, ioBroker). 22 of 22 generated IDs are 1. Why this has been hardWolf publishes no eBUS documentation. Every Wolf config in the wild is hand-made, partial, and Reads are The last two bytes are obviously the TelegramNr little-endian. The first byte is the problem. 2. The checksumIt is linear over GF(2), which is what makes it recoverable. Take known-good (byte, TelegramNr) function wolfCrc(telegramNr) {
let c = telegramNr & 0xff;
for (let i = 0; i < 8; i++)
c = (c & 0x80) ? (((c << 1) & 0xff) ^ 0x5c) : ((c << 1) & 0xff);
return (c ^ (telegramNr >> 8)) & 0xff;
}
const hx = n => n.toString(16).padStart(2, '0');
const readId = tn => hx(wolfCrc(tn)) + hx(tn & 0xff) + hx((tn >> 8) & 0xff);A CRC8 chain with polynomial Checks that matter:
Bonus: running this over an existing config is a good way to find typos. It flagged one in 3. Writes — and why yours probably do nothingWrites use a different address and a different ID format:
Two things people get wrong:
Proof, on a deliberately harmless register ( And the one that matters — the DHW setpoint, TelegramNr 19, write ID Test writes on something harmless first. 4. Getting the register list for your Wolf deviceYou do not have to guess which TelegramNrs exist. Wolf's own SmartSet/ISM7 metadata is public
Which one are you? Look at your ebusd scan string. Mine says Type mapping: 5. Things that cost me hours
Validate a config offline, as a normal user, before installing it: Copy your config tree somewhere writable, edit, check. It prints Do not force-read many registers back to back. I ran 32 sequential Adding a write row whose name matches an existing read row does NOT increase Polling more costs nothing. I went from 28 to 60 polled messages and the bus symbol rate Values reading 6. ioBroker integrationMQTT. ebusd's own MQTT integration publishes reads fine: Note it ships exec('ebusctl write -c heating dhw_target_set 50', () => {
exec('ebusctl read -m 0 -c heating dhw_target_set', (e, out) => log('now ' + out));
});Always read back and verify. A write that silently does nothing is the failure mode here. Poll priority gotcha. If you use the Home Assistant MQTT profile, Two scripts are attached:
Useful enum decodings (from Wolf's own 7. SafetyThis is a gas appliance. A few things I would not do:
8. What it got meA Wolf FGB-K-28 that exposed 28 registers, six of them permanently dead, now exposes 60 — at Anlagendruck (system pressure, bar) · Abgastemperatur (flue gas) · Modulationsgrad · Plus working writes, which turned into an automated weekly DHW disinfection cycle and a Three errors found in a config that had been running for years: a wrong checksum on Files
CreditThe parameter database is zivillian/ism7mqtt's extraction Corrections welcome, especially from anyone who can confirm or refute the checksum on a non-FGB |
|
thank you so much for your extensive work. It helped me so much and worked pretty well on a CHA with BM-2 and MM-2 . As i wanted to query multiple devices i ran into the issue with duplicate identifiers so i extended your wolf-registers.js to query all at once and add deduplication. Some special identifiers like 1x_warmwasser (hotwater) is not allowed. My change tries to handle it by moving the numerical part to the end. |
|
Absolutely — go ahead, and thank you for asking. The header said "do what you like with it" and I meant it, so you never needed my permission; forking, extending and republishing is all fine by me. I'm glad someone picked it up, and I appreciate that you kept the write-up intact as HISTORY.md and linked the original comment rather than just the thread. Now the useful part. I ran your version against mine and found a few things you'll probably want. The multi-device feature doesn't quite do what the README says, and it's a small fix. Names are made unique per class ( The dedup also drops rows inside a single device, and one of those bit me. Two smaller ones. Your numeric-prefix fix is a real bug find — the original does emit Two things I'd gently ask you to reconsider, as feature requests rather than complaints. First, the class column: hardcoded None of that changes the answer to your question, which is yes, with pleasure. If you'd rather I open issues or PRs on your repo for the per-class dedup and the |
|
thanks for the long reply and deep inspection, you brought up many issue i wasn't aware of in my first quick tests. i will look into those issues. |
Uh oh!
There was an error while loading. Please reload this page.
Hi everybody
I started this discussion to collect everything we have about WOLF Heiztechnik hardware.
and this nearly nothing at the moment (2022-12-29). At least I did not find much googling.
The WOLF systems sometimes also announce manufacturer KROMSCHROEDER. Hold these as synonome.
I did not find any documentation of manufacutrers side of the bus - they keep every docu closed behind ther support portal.
But in the ebus spec there are some defaults documented, and over on ebus-wiki.org they collected the spec documents.
Some of the 05xx and 07xx and 08xx messages can be decoded using this documentation.
But until now nobody used this to create some default CSVs to use for unknown systems.
They also startet to collect about the vendor specific command set 50xx but they did not come far and what I found in the 2.x.x part of this repository look better.
It looks to me like someone poked on the user terminal for each setting and then looked at the messages it generates on the bus.
This would be another way to come forward with reverse-engineering the 50xx command set at least to get some data out of it.
The configs of the 2.x.x directory of this repo did not work for me, either.
Some messages had errors on my CGB-35/KK/BM system. And it was a hazzle to get mqtt autoconfiguration running.
becaus the old names do not fit with the default mqtt-hassio.cfg filtering sheme.
So I startet a fork of the ebusd-configuration repo here at github to put in what I have now: some small set of entities generated from the ebus of my CGB-35 gas heating system.
Now I want you to join to create some working default configuration from this devices.
You can help out
We all would be happy if you post your findings here.
All reactions