Hello Pavel,
i am still not sure if i figured out the right starting point for you? You write that it doesn’t work in openHAB.
-
You need to configure the bridge. Does this work?
You have 2 possibilities to configure the bridge. One is to use “ebusd” as network driver. Then the ebus daemon (ebusd) needs to run somewhere. Second way is to use network driver “raw” in order to connect the adapter directly without ebusd.
-
In OH you don’t need .csv config files as automatically loaded by the ebus 5 adapter after it identified your equpment. Instead of this, you need custom .json config files as in my configuration description or the integrated equipment of the binding (e.g. VRC700).
-
What is the heatpump type you have?
Hex telegram example for “high pressure in coolant circle”:
- Extract of code lines as within my hmu08 .json file (assume that you saw this?):
{
"label": "Hochdruck Kältekreis",
"id": "HighPressure",
"command": "B5 14",
"get": {
"master": [
{"type": "static", "default": "05 3F 03 FF FF"}
],
"slave": [
{"type": "byte"},
{"type": "byte"},
{"name": "HighPressure", "type": "word", "label": "Hochdruck Kältekreis", "min": 0, "max": 500, "factor": 0.1, "format":"%.1f bar"}
]
}
},
-
If you use “ebus send” in OH Karaf console, the complete ebus telegram is “FF 08 B5 14 05 05 3F 03 FF FF”, see screenshot below.
-
The answer telegram is “FF 08 B5 14 05 05 3F 03 FF FF 55 00 04 3F 00 40 00 50 00”. This telegram leads resolved to 6.4 bar pressure.
-
You can use “ebus resolve” in Karaf console to analyze this telegram.
The slave data which you are looking for, has 4 byte length and is “3F 00 40 00”
-
Having this information, you can use “ebusctl grab result decode” to figure out the appropriate data type searching for the received telegram and for the value “6.4” or “64”. Here it is 64 and means that the value has to be divided by 10 (see “factor: 0.1” in my .json file).
If you know nothing except the value of a parameter, you can can search for this numbers (here 6.4 or 64 within the decode results. Then you get an idea of the hey code and can test it. I looked for the numbers on my Vaillant controller (outside unit parameters within expert mode) and searched for them in the “ebusctl grab result decode” screen.
The answer telegram after the / is “043f004100”. The first byte of this telegram defines the data length and is 04 or 4 bytes. Data is 3F004100. The required pressure value within the line “UIN” is the “double-byte” 4100=65. Multiplied by 0.1 its 6.5 bar (changed slightly against my above example with 6.4 bar due to different time where i took it). This provides you the data type information, here “UIN”. A problem is that the data type of ebus5 adapter (John30) is not the same as Christian Sowada used in his OH ebus binding. The pressure data uses 2 byte length. In ebus 5 adapter the data type is “UIN” (unsigned integer) and in OH the data type is “word”. You can download a conversion table from Christian here: https://github.com/csowada/ebus/blob/master/doc/ebusd-mapping.md
Due to the fact, that the length for the pressure value here is 2 bytes, the .json slave config has only 3 lines. The 3rd line defines the data length of 2 bytes using data type “word” (UIN). Therefore the 4th line is ommitted. This is a bit tricky. The first line stands for the “3F”, the second line stands for the “00” and the 3rd line stands for the “4100”. This and the apropriate data type represent the “trick” in order to setup of the .json slave part.
"slave": [
{"type": "byte"},
{"type": "byte"},
{"name": "HighPressure", "type": "word", "label": "Hochdruck Kältekreis", "min": 0, "max": 500, "factor": 0.1, "format":"%.1f bar"}
]
Another example. If the length of a response telegram would be 9 bytes and the same information would be contained within the sixth byte and length of 2 bytes, the slave part of the .json would have 8 lines and look like this:
"slave": [
{"type": "byte"},
{"type": "byte"},
{"type": "byte"},
{"type": "byte"},
{"type": "byte"},
{"name": "HighPressure", "type": "word", "label": "Hochdruck Kältekreis", "min": 0, "max": 500, "factor": 0.1, "format":"%.1f bar"},
{"type": "byte"},
{"type": "byte"}
]
Does this bring you forward in some way? If not, feel free to ask more questions. An issue might be that your equipment may use different telegrams than mine. For that reason, i asked for the type. Vaillant doesn’t apply any standard like for example that the pressure telegram is always the same.
Regards,
Willi