ebusd as bus master about ebusd HOT 6 OPEN

The issue with the unpowered bus, I resolved in the meantime. It's well documented in the physical layer specification, how to do it, but I took the easy way and just bought a Vaillant VR 38 power supply.

I now see all my units and can communicate with them. It's only the OMU (Vaillant AroCollect):

address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0131;HW=5202", loaded "vaillant/e0.omu.csv"

And I see that it's not ready:

omu ODUReady = no

I guess, it's missing his heatpump or system controller, which according to forums, is likely one of these:

address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"

Now what I need is to put ebusd in place of one of these devices. I can change the ebusd address, however I need something to reverse load the csv file. Reverse means, wherever the file has a read entry, I need to have a write entry, and vice versa.

from ebusd.

I found several threads that contained log entries with communication from HMU (03) to OMU (E0). This was usually done, using service B521, which is not yet in the e0.omu.csv. There is only B509 service. Here are some snippets:

#QQ ZZ PBSB NN              NN
#03 e0 b521 05 00020800e7         / 09 0000c400d100070000
#03 e1 b521 05 00020800e7         / 09 0000c800d200070000
#03 e0 b521 05 00050700e7         / 09 0106f3ff2900073f46
#03 e0 b521 05 00050700e7         / 09 0106f2ff4000073f47
#03 e0 b521 05 00050700e7         / 0b 00029bffe1ff0700000800
#03 e0 b521 09 00012200e6ffff4600 / 0b 0106d5ff2a00074759ef00
#03 e0 b521 09 00012200e6ffff4600 / 0b 0106d0ff1a00074759f600
#03 e0 b521 09 00002200e6ffff4600 / 0b 0106d0ff1a00074759f400
#03 e0 b521 09 00002200e6ffff4600 / 0b 0006d0ff1d0028404daf00
#03 e0 b521 09 00002200e6ffff4600 / 0b 0006d0ff1d002837417200
#03 e0 b521 09 00002200e6ffff4600 / 0b 0006d0ff1e00282d344400
#03 e0 b521 09 00002200e6ffff4600 / 0b 0006d0ff1e002822282700

I collected this from several threads and log entries therein. In fact my OMU just reacts to the longer messages.

This thread was helpful to understand what B521 does:
https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/27472-ebusd-frage-zu-command-csv?p=552909#post552909

Looking at the reactions of my ODU, I was able to solve most of the remaining fields. B521 seems to tell the ODU the state of the HMU 00<state>2200e6ffff4600 and returns the following parameters

• IDU Appliance Code (which is basically the state of the HMU)
• Last IDU Appliance Code (the state the HMU is coming from)
• Temperature Brine Output
• Temperature Air Inlet
• unknown
• Fan RPM
• Fan PWM

The IDU Appliance Code is what is available in several Vaillant owner manuals as "Status Code":

• 0: Heizung kein Wärmebedarf
• 1: Heizung Gebläseanlauf
• 6: Heizung Gebläsenachlauf
• 34: Heizbetrieb Frostschutz

So by sending these states, I can switch fan on (1 or 6), off (0) or start defrost/deicing on (34). The OMU also has its state machine and returns state back via IDUApplianceCode.

A normal HMU seems to send this command every 20 seconds. But it seems the OMU just needs this once. So no difficult service, just a write command and everything works well.

So I hope that makes sense. I'll prepare a pull request to bring B521 command into e0.omu.csv.

from ebusd.

I created a pull request for the ebusd-configuration here: john30/ebusd-configuration#368.

from ebusd.

A possible command to start the AROcollect OMU is shown here:

w -c omu OMUControl 5;34;0;230;-1;-1;50;0

Just the "5" is important, as it sends the HMU status code to the ODU, e.g. if it's in heating mode.
The rest I use as constants. I haven't found in the log files always these numbers, and don't know yet, what they mean...

from ebusd.

Ah, another thing I've found:
If I set datatype to UCH and try to send 0xff=255 to it, it complains that the value is out of range. I circumvented this with using SCH and sending -1, which effectively gives the intended 0xff.
Same with UIN and 0xffff=65535. Sending -1 to SIN, effectively gives 0xffff.
Maybe I open another issue for this.

from ebusd.

0xff is the replacement value for that datatype (like null), so you could set that value by using "-" as input. same for SIN with 0xffff

from ebusd.