Replies: 8 comments 4 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Currently i cannot get the .csv stuff to work Is this as it looks at your setup: 1 directory, 5 files Greetings |
Beta Was this translation helpful? Give feedback.
-
|
I just pushed my latest working config into my github repro for you to checkout |
Beta Was this translation helpful? Give feedback.
-
Ohh my setup was rubbish, its however working now using other .csv's |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
#950 helped a lot. At least I have some basic fields working now, working on getting more to work. |
Beta Was this translation helpful? Give feedback.
-
|
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: I 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
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.
Beta Was this translation helpful? Give feedback.
All reactions