Recovair in ebusd 3.4 manuell einbinden ?

[cbeham]

Guten Abend!
Ich habe folgendes Ergebnis bei ebusctl -i:

Hinter v32, Adresse 38 slave 08 verbirgt sich eine Recovai mit einem v32 Buskoppler.
Leider kann ebusd nichts dazu auslesen.

Hat jemand eine Lösung oder Hilfe für mich?

Im Internet habe ich eine csv Datei mit Befehlen gefunden.
Kann ich die auf dem Pi hochladen und dann funktioniert es?

Danke und lg

# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recoV,RecoVair,RecoVair,,,,,,,,,,
*r,,,,,,B509,0D,,,,,,
*w,,,,,,B509,0E,,,,,,
*wi,#install,,,,,B509,0E,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
r;w,,FanLevelDay,Lüfterstufe Tag,,,,8a03,,,UCH,1=1;2=2;3=3;4=4;5=5;6=6,,
r;w,,FanLevelNight,Lüfterstufe Nacht,,,,8b03,,,UCH,1=1;2=2;3=3;4=4;5=5;6=6,,
r;w,,Heatrecovery,Wärmerückgewinnung,,,,8c03,,,UCH ,0=auto;1=on;2=off,,Aktuelle Uhrzeit
r;w,,FilterChange,Tage bisFilterwechsel,,,,350e,,,UIN,,Tage,
r;w,,maintenance,Tage bis Wartung,,,,360e,,,UIN,,Tage,
r,,DayKwh,Ertrag Heute kwh /10,,,,560e,,,ULG,10,Kwh,
r,,YesterdayKwh,Ertrag Vortag kwh /10,,,,570e,,,ULG,10,Kwh,
r,,MonthKwh,Ertrag Monat kwh /10,,,,580e,,,ULG,10,Kwh,
r,,YearKwh,Ertrag Jahr kwh,,,,590e,,,ULG,,Kwh,
r,,TotalKwh,Ertrag Gesamt kwh,,,,5a0e,,,ULG,,Kwh,
r;w,,InstallationHight,Installationshöhe in m,,,,1a0e,,,UIN,,m,
r;w,,Disbalance,Dissbalance Abluft %,,,,1b0e,,,SCH,,%,
r;w,,VolumeFlow,Nennvolumenstrom NL,,,,1c0e,,,UIN,,m³/h,
r;w,,RedVolumeFlow,Red.lüftung % zu NL,,,,1d0e,,,UCH,,%,
r;w,,IntensVolumeFlow,Intensivlüftung % zu NL,,,,1e0e,,,UCH,,%,
r;w,,WTTyp,WTTyp,,,,250e,,,UCH,0=Standart;1=Etalph ie,,
r;w,,FreezProtect,FrostschutzTyp,,,,260e,,,UCH,0=k ein;1=elektrisch;2=hydraulisch,,
r;w,,GroundCollector,Erdkollektor,,,,280e,,,UCH,0= nein;1=ja,,
r;w,,BypassDiffTemp,BypassDiffTemp,,,,2a0e,,,temp, ,°C,
r;w,,PressureSwitch,Druckwächter,,,,2b0e,,,UCH,0=n ein;1=ja,,
r;w,,StepSwitch,Stufenschalter,,,,2c0e,,,UCH,0=nei n;1=ja,,
r;w,,AirQualitySens,Luftqualitätssensor,,,,2d0e,,, UCH,0=keiner;1=1Sensor;2=2Sensoren,,
r;w,,MinCO2,min CO2 Wert,,,,2e0e,,,UIN,,ppm,
r;w,,MaxCO2,max CO2 Wert,,,,2f0e,,,UIN,,ppm,
r;w,,MinHum,min Luftfeuchte %,,,,300e,,,UCH,,,
r;w,,MaxHum,max Luftfeuchte %,,,,310e,,,UCH,,,
r,,VolumeFlowAct,aktueller Volumenstrom,,,,040e,,,UIN,,,
r,,ByPass,ByPass Klappe,,,,0a0e,,,UCH,0=on;01=mid;02=off,,
r;w,,FanStage,Luefterstufe,,,,150e,,,UCH,0=low;1=a uto;2=mid;3=high,,
r;w,,Desiredtemp,Wunschtemp,,,,140e,,,temp,,°C,
r,,OutsideAirTemp,AussenTemp,,,,0c0e,,,temp,,°C,
r,,ExhaustAirTemp,FortLuft,,,,0d0e,,,temp,,°C,
r,,OutletAirTemp,AbLuft,,,,b40d,,,temp,,°C,
r,,InletAirTemp,ZuLuft,,,,b30d,,,temp,,°C,
r,,HeatElement,Frostschutzelement,,,,f10c,,,UCH,0= nein;1=ja,,
r,,BypassPos,Bypass Position,,,,0b0e,,,UCH,,,

[cbeham]

Ich kann leider die Datei nicht hochladen, aber sie heißt 38.v32.csv

[john30]

wie schon geschrieben ist die Kommunikation durch einen VR32 durch völlig anders. Am einfachsten wäre, ein zweites Interface an den Lüftungs-eBUS zu hängen und einen zweiten ebusd laufen zu lassen.

[papaschlumpf2000]

Hallo zusammen,
ich habe ebenfalls eine RecoVair und leider wurde kein Gerät erkannt. Nun habe ich ein VR32 eingebaut und erhalte diese Meldung:
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"

Da ich hier sehe, dass keine csv geladen wurde und sehe was John 30 geschrieben hat: Gibt es trotzdem eine Chance, dass die Werte ausgelesen werden können? Ich habe laut Anleitung in dem Gerät die Adresse 3 eingestellt.

Viele Grüße

[nori0077]

Hallo. Ich habe den Ebus Adapter direkt auf der Recovair angeklemmt und bekomme auch eine Verbindung. Ich habe die CSV Datei lokal abgelegt, da sonst keine gefunden wurde. Leider werden einige Werte aus der CSV Datei nicht übertragen, welchen Grund kann es hierfür geben? Die Daten in der CSV Datei sind identisch mit denen von cbeham.

[john30]

@nori0077 was ist denn die Meldung bei der Abfrage? Und poste halt mal die hex bytes, sonst kann ich hierzu wirklich nichts sagen.
@papaschlumpf2000 siehe hier

[motylu]

Hello,
for some time I am using this great eBUS daemon on Raspberry Pi 1B (and now on new 4B). I have Vaillant heat pump VWL 58/4 and multiMATIC VR700 on one eBUS interface and on separate eBUS recoVAIR VAR 360/4 (without any other device like multiMATIC, VR32, etc.).
Until now I used only one instance of ebusd with VWL 58/4 and multiMATIC VR700 together with Home assistant without any problems.
Now I am trying to start communication with recoVAIR on separated bus with second converter (I am using own desings based on well known eBUS adapter v 2.2) and second instance of ebusd. I have local configuration and added 08.recov.csv file also. My problem is that ebusd is not capable to scan any device or communication on separate bus between recoVAIR and converter, see result of ebusctl info for both instances (port 8888 is for eBUS with VWL and multiMATIC, port 8889 for recoVAIR):

pi@raspberrypi:~ $ ebusctl -p 8888 info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 43
max symbol rate: 130
min arbitration micros: 1056
max arbitration micros: 9964
min symbol latency: 0
max symbol latency: 23
reconnects: 0
masters: 4
messages: 483
conditional: 0
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0303;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0303;HW=0403"

pi@raspberrypi:~ $ ebusctl -p 8889 info
version: ebusd 3.4.v3.3-51-g57eae05
update check: version 21.2 available, broadcast.csv: different version available, memory.csv: different version available
signal: acquired
symbol rate: 23
max symbol rate: 24
reconnects: 1
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

See also result for grab and listen, where is exactly nothing...:

pi@raspberrypi:~ $ ebusctl -p 8889 grab
pi@raspberrypi:~ $ ebusctl -p 8889 grab result all
done
/var/log/ebusd2.log:
2021-03-29 05:03:23.234 [main debug] performing regular tasks
2021-03-29 05:03:23.234 [main debug] >>> grab
2021-03-29 05:03:23.235 [main debug] <<< grab continued
2021-03-29 05:03:23.236 [network debug] [00011] wait for result
2021-03-29 05:03:23.247 [network info] [00011] connection closed
2021-03-29 05:03:24.234 [network debug] dead connection removed - 0
2021-03-29 05:03:33.238 [main debug] performing regular tasks
2021-03-29 05:03:43.240 [main debug] performing regular tasks
2021-03-29 05:03:53.241 [main debug] performing regular tasks
2021-03-29 05:04:03.246 [main debug] performing regular tasks
2021-03-29 05:04:13.247 [main debug] performing regular tasks
2021-03-29 05:04:22.256 [network info] [00012] client connection opened 127.0.0.1
2021-03-29 05:04:22.259 [main debug] performing regular tasks
2021-03-29 05:04:22.261 [main debug] >>> grab result all
2021-03-29 05:04:22.262 [main debug] <<< done
2021-03-29 05:04:22.262 [network debug] [00012] wait for result
2021-03-29 05:04:22.276 [network info] [00012] connection closed
2021-03-29 05:04:23.259 [network debug] dead connection removed - 0
2021-03-29 05:04:32.262 [main debug] performing regular tasks
2021-03-29 05:04:42.263 [main debug] performing regular tasks
2021-03-29 05:04:52.264 [main debug] performing regular tasks
2021-03-29 05:04:58.526 [network info] [00013] client connection opened 127.0.0.1

pi@raspberrypi:~ $ ebusctl -p 8889 listen -u
pi@raspberrypi:~ $ ebusctl -p 8889 listen stop
done
/var/log/ebusd2.log:
2021-03-29 05:08:44.474 [main debug] >>> listen -u
2021-03-29 05:08:44.475 [main debug] <<< listen started
2021-03-29 05:08:44.475 [network debug] [00021] wait for result
2021-03-29 05:08:44.484 [network info] [00021] connection closed
2021-03-29 05:08:45.473 [network debug] dead connection removed - 0
2021-03-29 05:08:54.475 [main debug] performing regular tasks
2021-03-29 05:09:04.477 [main debug] performing regular tasks
2021-03-29 05:09:14.479 [main debug] performing regular tasks
2021-03-29 05:09:24.480 [main debug] performing regular tasks
2021-03-29 05:09:34.481 [main debug] performing regular tasks
2021-03-29 05:09:44.486 [main debug] performing regular tasks
2021-03-29 05:09:54.487 [main debug] performing regular tasks
2021-03-29 05:10:04.488 [main debug] performing regular tasks
2021-03-29 05:10:14.489 [main debug] performing regular tasks
2021-03-29 05:10:18.903 [network info] [00022] client connection opened 127.0.0.1
2021-03-29 05:10:18.908 [main debug] >>> listen stop
2021-03-29 05:10:18.908 [main debug] <<< listen stopped
2021-03-29 05:10:18.908 [network debug] [00022] wait for result
2021-03-29 05:10:18.924 [network info] [00022] connection closed
2021-03-29 05:10:19.905 [network debug] dead connection removed - 0
2021-03-29 05:10:23.909 [main debug] performing regular tasks
2021-03-29 05:10:33.910 [main debug] performing regular tasks
2021-03-29 05:10:34.106 [network info] [00023] client connection opened 127.0.0.1

I also tried changing converters and instances, adding options for daemon (like answering, generate SYN, changing default address, etc.), but with the same result. Are there any specific configurations, initial or periodic messages for "waking" the recoVAIR for start the communication?

I am using older version of ebusd, because I am not able to run newest version on Raspberry Pi 1B and also 4B due to error during starting service...

[john30]

is there any controller on the recovair bus?
try a full scan

[motylu]

Of course I tried full scan multiple times, but basically everytime with no result:

pi@raspberrypi:~ $ ebusctl -p 8889 scan full
done
pi@raspberrypi:~ $ ebusctl -p 8889 scan result
1 scan(s) still running
pi@raspberrypi:~ $ ebusctl -p 8889 scan result
done

On eBUS there is only recoVAIR (without VR32) and eBUS/USB adapter, nothing else.
If I will have some time, I want to try connect recoVAIR to eBUS with multiMATIC (when heat pump will be switched off), but I must do some reconnections, which take some time...
But it is very strange behaviour, because obviously signal levels on eBUS are OK and something (maybe SYN?) is continuously received by adapter.

[john30]

try looking at some raw logs to see if recovair answers at all

[john30]

closed due to inactivity

[piotrtobolski]

@motylu did you solve it? I seem having the same issue. Adapter v5, looks like it is connected to eBUS but it doesn't see the recoVAIR

[motylu]

@motylu did you solve it? I seem having the same issue. Adapter v5, looks like it is connected to eBUS but it doesn't see the recoVAIR

Sorry, but no. I have another priorities, so I didn't spend much time on this...