eBUS Binding 3.x [3.4.0;3.9.9)

Have not been able to make progress with my Vaillant circulation pump. Would be happy about any hint from experts within the community.

This string is from John30 and his hcmode.inc which is included within 08hmu.csv:

*uw,,,,,,"B512",,,,,,,
uw,,StatusCirPump,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,

This is my attempt creating a .json file for openhab but i don’t get the data:

{
    "id":           "HMU00",
    "vendor":       "Vaillant",
    "label":        "Circulation Pump",
    "description":  "Status der Zirkulationspumpe",
    
    "authors":      ["Willi Konrath, willibald.konrath@t-online.de"],
    "identification": ["48 4D 55 30 30"],
    
    "commands":
    [
        {
            "label":    "Status HWC Circulation Pump",
            "id":       "StatusCirPump",
            "command":  "B5 12",

            "get": {
                "master": [
                    {"type": "static", "default": "00"}
                    ],
                "slave": [
                    {"name": "StatusCirPump", "type": "uchar", "label": "Status HWC Circulation Pump", "min": 0, "max": 100, "format":"%d",
                        "mapping": {"0":"Off", "100":"On"}}
                ]
			}
		}
	]
}

The file is loaded into openhab successfully but i get “NULL” instead of “On” or “Off”.

Can anybody help me onto the horse?

Does your thing or channel have a polling interval set?

Are you able to find the ebus message in your log? Should start with something like
FF 08 B5 12 01 00 XX
And let us know the full message.

Every response byte should be accounted for. If the response has more bytes than your json specifies, message deciding fails.

PS: try with “byte” in stead of “uchar”?
PS2: I don’t have a lot of time, so replies could take longer than one hopes for when troubleshooting such case :wink: especially with the Xmas weekend in front of us.

1 Like

Thanks for your quick response. Will go through the points step by step and report (after Xmas). Have nice Xmas days.

Command:

Poll command "ebus:HMU00:e2026358ab:c517a846e7:HMU00_StatusCirPump#StatusCirPump" with "FF 15 B5 12 01 01 58" ...

Answer could be (am not sure):

Unknown telegram FF 15 B5 12 01 01 58 00 00 00

“Byte” instead of “uchar” didn’t change something.

The openhab command line console can give you hints. I used it on your telegram, it is a great tool to learn more:

openhab> ebus resolve "FF 15 B5 12 01 01 58 00 00 00"


*****************************************************************************************************************************
** Error on checking telegram: Master CRC invalid! IS:59 SHOULD:58 [ERROR: MASTER_CRC_INVALID, DATA: FF 15 B5 12 01 01 58] **
**     !!! Warning: All following results are wrong and only displayed for information purpose !!!                         **
*****************************************************************************************************************************


openhab> ebus resolve "FF 15 B5 12 01 01 59 00 00 00"


Check and unescape telegram
***************************

Original data : FF 15 B5 12 01 01 59 00 00 00
Unescaped data: FF 15 B5 12 01 01 59 00 00 00

Analyse the telegram
********************

FF 15 B5 12 01 01 59 00 00 00
^^--------------------------- Source address       | Type: Master         | FF
   ^^------------------------ Destination address  | Type: Slave          | 15
      ^^ ^^------------------ Command              |                      | B5 12
            ^^--------------- Master Data Length   | Length: 1            | 01
               ^^------------ Master Data          |                      | 01
                  ^^--------- Master CRC           |                      | 59
                     ^^------ Slave ACK            |                      | 00
                        ^^--- Slave Data Length    | Length: 0            | 00
                           -- Slave Data           |                      |
                           ^^ Slave CRC            |                      | 00

What I don’t get is that a command “01” is sent and not “00”, however your CRC matches 00 and not 01…. Question marks all over the place in my head. But second of all, although the slave acknowledges with 00, it responds with a 00 bytes message (so actually no response).

In the openhab consol you also have the “ebus send” command. You could try to send the command directly from there:

ebus send "FF 15 B5 12 01 00 58"

And check out the response you get.

1 Like

I might have made a failure using copy & paste. This is what i get using “ebus send”:

openhab> ebus send "FF 15 B5 12 01 00 58"
Send telegram with id 867017405, waiting for response ...
Status    : FAILED 867017405~                                                                                                           
Telegram  : FF 15 B5 12 01 00 58 00 00 00
Error     : No command method matches the telegram!

Earlier you wrote that you wanted the information from a device at slave address 08. You are somehow polling now from a device at slave address 15 (see command starting with FF 15).

What if you try

ebus send "FF 08 B5 12 01 00 16"
1 Like

Hello, can somebody tell me what I have to do to get these both files?
ebus-resolved.csv
ebus-unresolved.csv
Since I have updatet Openhab to version 3.4 no files are created anymore.
I set log level to:
log:set DEBUG org.openhab.binding.ebus

Tested this:

openhab> ebus send "FF 08 B5 12 01 00 16"
Send telegram with id 1112849013, waiting for response ...
openhab> Status    : FAILED 1112849013
Error     : Received SYN byte while receiving telegram! [ERROR: INVALID_SYN, DATA: FF 08 B5 12 01 00 16 00 AA]

My understanding is actually:
My openhab thing “circulation pump” has ebus address 15 as a node. The target ebus adress 08 (HMU unit, main board of the heatpump) for polling data should be set by the identification of the ebus device. This maybe nonsense? Please explain.

1 Like

I have really no clue. Problem is I have only a Brink Renovent, so there is very little I can check with my own system.

I also don’t know how ebusd works. You could try to get the information with ebusd as that program has the config. Can you control or read the VRC700 with ebusd? And with openhab ebus binding just see what messages are flying by from ebusd.

My understanding is that you should send the command to slave 08 as the command is included in 08hmu.csv. It could be that one device only accepts the call from a certain master or slave address?

In that case one could try

ebus send "03 15 B5 12 01 00 XX"

or

ebus send "10 08 B5 12 01 00 XX"

But I think the best way is to learn how ebusd does it, find the code that ebusd sends and convert it to an openhab json.

1 Like

Many thanks for your efforts to help me. Have a second ebus adapter 3.0 and ebusd running within a “Docker Desktop” for Windows10.

Here the ebusd config files are applied. For my problem 08hmu.csv and hcmode.inc (see last lines within 08hmu.csv) apply. I can see the hex telegrams and the resolved parameter values.

hmu StatusCirPump = On = 10 08 b5 12 02 00 64 / 00
hmu StatusCirPump = Off = 10 08 b5 12 02 00 00 / 00

These are the received telegrams which represent the status of the pump. For me its still unclear what the difference of these telegrams compared with a poll command telegram from openhab is?

Also unclear is how this is translated into a .json for the ebus binding in openhab.

A special thing is also that the config file hcmode.inc contains uw (update-write) instead of r (read)?

*uw,,,,,,"B512",,,,,,,
uw,,StatusCirPump,Status Zirkulationspumpe,,,,00,,,UCH,0=off;100=on,,

The whole thing goes above my actual openhab expertise.

That is very useful information!

I had already noticed *uw but could not figure out the “u” in there, but I think it is a value that you cannot poll, but is updated by the master: “I communicate that I have turned off/on the pump”. So you need to listen for the message from master 10 to slave 08.

At this moment no time to give an example json, but will give later this week.

Hold on…

{
    "id":           "HMU00",
    "vendor":       "Vaillant",
    "label":        "Circulation Pump",
    "description":  "Status der Zirkulationspumpe",
    
    "authors":      ["Willi Konrath, willibald.konrath@t-online.de"],
    "identification": ["48 4D 55 30 30"],
    
    "commands":
    [
        {
            "label":    "Status HWC Circulation Pump",
            "id":       "StatusCirPump",
            "command":  "B5 12",

            "get": {
                "master": [
                    {"type": "static", "default": "00"},
                    {"name": "StatusCirPump", "type": "uchar", "label": "Status HWC Circulation Pump", "min": 0, "max": 100, "format":"%d",
                        "mapping": {"0":"Off", "100":"On"}}
                    ]
			}
		}
	]
}

On your slave 08 Thing you listen to this channel. You do not poll this channel, so in the Thing definition you do not define polling, but you define polling on a per channel basis, where this channel should have no polling defined.

1 Like

Many thanks for your continued support. Have looked for telegrams in the ebus binding TRACE log while i switched the pump “on” and “off” using the myVaillant app on the iPhone. They appear as “unknown” telegrams:

Pump state "On": 10 08 B5 12 02 00 64 AE 00 00 00
Pump state "Off": 10 08 B5 12 02 00 00 CA 00 00 00

Thus, “on” master data is “00 64” and “off” master data is “00 00”. Hope that this helps you in order to setup a .json file.

I just updated my post…

1 Like

Great, it is working out now :smiley: :+1:. Many thanks for your support. Learned a lot on ebus binding configuration.

Have another task where i am still struggling. Could you give me one more .json example, e.g. for the CurrentCompressorUtil. These parameters are all “r” (read).

Ebusd telegram received:

hmu CurrentCompressorUtil = 3108b51a0405ff3225 / 0aff083862020000000000

The result is: 98%

The following data is from ebusd config file 15.700csv:

I assumed that ebusd data type “D1B” is for ebus “data1b”. Am not sure if this is right?

Thanks for your support in advance.

D1B is indeed data1b, but you can use type “char” as well, both are signed integers.

Analyse the telegram
********************

31 08 B5 1A 04 05 FF 32 25 49 00 0A FF 08 38 62 02 00 00 00 00 00 8B 00
^^--------------------------------------------------------------------- Source address       | Type: Master         | 31
   ^^------------------------------------------------------------------ Destination address  | Type: Slave          | 08
      ^^ ^^------------------------------------------------------------ Command              |                      | B5 1A
            ^^--------------------------------------------------------- Master Data Length   | Length: 4            | 04
               ^^ ^^ ^^ ^^--------------------------------------------- Master Data          |                      | 05 FF 32 25
                           ^^------------------------------------------ Master CRC           |                      | 49
                              ^^--------------------------------------- Slave ACK            |                      | 00
                                 ^^------------------------------------ Slave Data Length    | Length: 10           | 0A
                                    ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^------ Slave Data           |                      | FF 08 38 62 02 00 00 00 00 00
                                                                  ^^--- Slave CRC            |                      | 8B
                                                                     ^^ Master ACK           |                      | 00

You are looking for the fourth byte in the response (62 hex).


{
            "label":    "Current compressor utilization",
            "id":       "CurrentCompressorUtil",
            "command":  "B5 1A",

            "get": {
                "master": [
                    {"type": "static", "default": "05 FF 32 25"}
                    ],
                "slave": [
                    {"type": "byte"}
                    {"type": "byte"}
                    {"type": "byte"}
                    {"name": "CurrentCompressorUtil", "type": "char", "label": "Current compressor utilization", "min": 0, "max": 100, "format":"%d"}
                    {"type": "byte"}
                    {"type": "byte"}
                    {"type": "byte"}
                    {"type": "byte"}
                    {"type": "byte"}
                    {"type": "byte"}
                ]
			}
		}

Edit: I filled up “bytes” for response length 8, however response length was 10 (0A), hence added two additional bytes at the end of the slave

1 Like

I only had to add the missing commas. Everything else was perfect :smiley: :+1:. Many thanks for this and a happy new year.

Ah yes, the ever missing commas. Copying and pasting on the iPad never works as well, where nano or notepad++ would’ve shown me my mistakes. Glad you found that out easily. Little while ago took me some hours finding out why a text-based rule failed, only noticing late that I declared a “string” with lower case i.s.o. upper case :frowning:

Happy New Year Willibald. Have fun “programming”.