Läuft: Heizung mit eBus-Schnittstelle

[Sven77]

Habe mal eine Frage zu den CSV-Definitionen; wahrscheinlich am ehesten an john30

Ich verstehe die Erklärung zu Update-Nachrichten nicht ganz:

any other character: update
All of the remaining characters can be used to define a passive message that ebusd will listen to in order to recognize updates of field values. If the type is suffixed with a "w", the message is treated as write message as mentioned above. Otherwise it is treated as read message.

Was ich in den Beispielen bzw. Konfigs anderer Geräte sehe, sind Update-Nachrichten komplett andere als Read- oder Write-Nachrichten.

Was ich gern erreichen würde: meine multiMATIC VRC700 erzeugt schon viel Last auf dem Bus, um mit allen möglichen Teilnehmern zu kommunizieren.
Dabei gibt es sowohl Reads, als auch Writes. Damit ich im Log nicht ständig "unknown MS cmd" lese, habe ich einige davon entschlüsselt und z.Bsp. zu meinem Mischermodul VR71 folgende CSV erstellt:

Code Auswählen Erweitern

# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,VR_71,VR 71,104 104,,,,,,,,,,
*r,,,,,,"B523",,,,,,,,,,
*w,,,,,,"B523",,,,,,,,,,


w,,SetActorState,,,,,05,R1,,UCH,0=off;20=on,,,R2,,UCH,0=off;20=on,,,R3,,UCH,0=off;20=on,,,R4,,UCH,0=off;20=on,,,R5,,UCH,0=off;20=on,,,R6,,UCH,0=off;20=on,,,R7,,UCH,0=off;20=on,,,R8,,UCH,0=off;20=on,,,R9,,UCH,0=off;20=on,,,R10,,UCH,0=off;20=on,,,R11,,UCH,0=off;20=on,,,R12,,UCH,0=off;20=on,,,Rx,,HEX:2,,,

w,,Mc1FlowTempDesired,,,,,0200,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,
w,,Mc2FlowTempDesired,,,,,0201,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,
w,,Mc3FlowTempDesired,,,,,0202,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,

r,,SensorData1,,,,,06,S1,,temp,,,,S2,,temp,,,,S3,,temp,,,,S4,,temp,,,,S5,,temp,,,,S6,,temp,,,,S7,,temp,,,,ignore,,HEX:2,,,
r,,SensorData2,,,,,07,S8,,temp,,,,S9,,temp,,,,S10,,temp,,,,S11,,temp,,,,S12,,temp,,,,Sx,,temp,,,,ignore,,HEX:3,,,

!include,errors.inc,,,,,,,,,,,,


Mit dieser steht nun schön im Log:

Code Auswählen Erweitern

2019-11-27 11:11:34.487 [update notice] received write vr_71 SetActorState QQ=10: -;-;off;off;off;off;-;-;-;-;off;off;00 00
2019-11-27 11:11:34.860 [update notice] received write vr_71 Mc1FlowTempDesired QQ=10: on;38.5;on;35
2019-11-27 11:11:35.124 [update notice] received write vr_71 Mc2FlowTempDesired QQ=10: on;29.5;on;0
2019-11-27 11:11:43.315 [update notice] received read vr_71 SensorData1 QQ=10: 37.50;33.88;29.12;-;40.56;30.69;52.31;40 00
2019-11-27 11:11:43.728 [update notice] received read vr_71 SensorData2 QQ=10: 49.50;-;-;-;0.00;8.00;80 fc 05


Aber im Cache landen leider nur die Reads:

Code Auswählen Erweitern

# ebusctl find -c vr_71
vr_71 currenterror = -;-;-;-;-
vr_71 errorhistory = no data stored
vr_71 SensorData1 = 37.19;33.25;29.06;-;40.19;30.75;52.31;40 00
vr_71 SensorData2 = 49.50;-;-;-;0.00;8.00;80 fc 05


Nun zur Frage: kann ich Ebusd irgendwie beibringen, auch mitgelesene Writes von anderen Busteilnehmern im Cache abzulegen, dass ich diese anschließend (aus dem Cache) auslesen kann?
Konkret geht es in diesem Beispiel u.a. um die geforderte Vorlauftemperatur - die kann ich zwar auch von der VRC700 (aktiv!) auslesen, erzeuge damit aber eine Nachricht auf dem Bus, obwohl die Info ohnehin alle paar Sekunden mitgelesen wird.

[john30]

Aber im Cache landen leider nur die Reads:

Code Auswählen Erweitern

# ebusctl find -c vr_71
vr_71 currenterror = -;-;-;-;-
vr_71 errorhistory = no data stored
vr_71 SensorData1 = 37.19;33.25;29.06;-;40.19;30.75;52.31;40 00
vr_71 SensorData2 = 49.50;-;-;-;0.00;8.00;80 fc 05


naja, du hast halt auch nur nach den reads gefragt. "find -a" ist dein Freund

[Sven77]

Ah, vielen Dank!
Den Schalter hatte ich wohl glatt übersehen - somit kann ich wenigstens über einige Umwege die passiven Reads auslesen, z.Bsp. mittels

Code Auswählen Erweitern

# ebusctl find -a -e -c vr_71 SensorData1
vr_71 SensorData1 = 47.12;49.06;37.38;-;51.50;35.38;54.19;40 00

Die gesuchten Temperaturen kann ich dann mit cut herauspicken - es wäre zwar einfacher, wenn man diese auch noch auswählen und das einleitende "vr_71 SensorData1" weglassen könnte - aber das bringt mich schon einen großen Schritt weiter!

[john30]

Ah, vielen Dank!
Den Schalter hatte ich wohl glatt übersehen - somit kann ich wenigstens über einige Umwege die passiven Reads auslesen, z.Bsp. mittels

Code Auswählen Erweitern

# ebusctl find -a -e -c vr_71 SensorData1
vr_71 SensorData1 = 47.12;49.06;37.38;-;51.50;35.38;54.19;40 00

Die gesuchten Temperaturen kann ich dann mit cut herauspicken - es wäre zwar einfacher, wenn man diese auch noch auswählen und das einleitende "vr_71 SensorData1" weglassen könnte - aber das bringt mich schon einen großen Schritt weiter!

wenn du die niemals aktiv via ebusd schreiben willst, wäre "uw" dein Freund beim Typ in der Definition, dann könntest du die mit read auch regulär lesen

[mebwaster]

Hallo! Hat jemand einen Tipp für mich? Wie kann ich die Therme über den ebusd ein/ausschalten (sprich heizen/nicht heizen)?

Therme: Vaillant ecoTEC exclusiv VC 206/4. KEIN ebus Regler vorhanden. Am ebus hängen nur die Therme und der ebus Adapter.
Derzeitige Ansteuerung ist über ein Relais am Raumthermostat.

Werte auslesen und setzen über den ebus Adapter funktioniert einwandfrei. Z.b. über FlowsetHcMax kann ich die max. Vorlauftemperatur einstellen (aber leider nicht soweit runter drehen, daß die Heizung aus bleibt).

Mein erster Ansatz war, über HeatingSwitch zwischen Sommer- und Winterbetrieb umzuschalten. Funktioniert aber nicht, da die Variable readonly ist (auch wenn ich im csv auf write stelle, nimmt die Therme Änderungen nicht an).

Wie geht man hier richtig vor? Was würde ein ebus Regler schicken um die Therme zu schalten?

Code Auswählen Erweitern

info
version: ebusd 3.3.v3.3
update check: version 3.4 available, vaillant/08.bai.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 118
min arbitration micros: 24
max arbitration micros: 323
min symbol latency: 0
max symbol latency: 48
reconnects: 0
masters: 2
messages: 231
conditional: 0
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0706;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2, ebusd (answering)
address 15: slave #2, ebusd (answering)

f -w
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai AntiCondensValue = no data stored
bai BlockTimeHcMax = no data stored
bai clearerrorhistory = no data stored
bai DSNOffset = no data stored
bai ExhaustCurve = no data stored
bai FlowsetHcMax = no data stored
bai FlowsetHwcMax = no data stored
bai GVStepOffsetMax = no data stored
bai GVStepOffsetMin = no data stored
bai HcPumpMode = no data stored
bai HoursTillService = no data stored
bai HwcPostrunTime = no data stored
bai HwcTempMax = no data stored
bai PartloadHcKW = no data stored
bai PartloadHwcKW = no data stored
bai ReduceModulationBlocktime = no data stored
bai ReturnRegulation = no data stored
bai SecondPumpMode = no data stored
bai SetFactoryValues = no data stored
bai SpecialAdj = no data stored
bai StorageLoadTimeMax = no data stored
bai ValveMode = no data stored
bai WPPostrunTime = no data stored
bai WPPWMPowerDia = no data stored
broadcast id = no data stored
broadcast queryexistence = no data stored
memory eeprom = no data stored
memory ram = no data stored

[Sven77]

Ohjee - da ist ja lt. CSV fast alles read-only!

Also ich habe bei meiner icoVIT156 folgende Nachricht in der CSV hinzugefügt, weil über diese die multiMATIC ihre gewünschte Vorlauftemperatur sendet:

Code Auswählen Erweitern

w,,ExtFlowTempDesired,,,,B510,00,HwcSwitch,,HEX:1,,,,HcFlowTempDesired,,temp1,,,,HwcTappingDesired,,temp1,,,,HwcFlowTempDesired,,temp1,,,,Unknown1,,HEX:1,,,,Unknown2,,HEX:1,,,,Unknown3,,HEX:1,,,,Unknown4,,HEX:1,,,

Da zumindest einige Nachrichten, u.a. ExtFlowTempDesiredMin, mit deiner CSV übereinstimmen wäre es ein Versuch wert.
Wenn du darüber meldest, dass keine Wärme benötigt wird, sollte die Therme das eigentlich auch so anzeigen und akzeptieren.
Leider sind ein paar "Unknowns" dabei, hier habe ich noch nicht durchschaut, was die machen - aber folgende Zustände kenne ich:

Kein Wärmebedarf (also für deine Frage, wie man sie ausschalten kann):

Code Auswählen Erweitern

[update notice] received write bai ExtFlowTempDesired QQ=10: 00;0.0;-;-;ff;01;00;00
Also HwcSwitch=0, HcFlowTempDesired=0, HwcTappingDesired=ff, HwcFlowTempDesired=ff, Unknown1=ff, Unknown2=01 und die letzten beiden 0.

Normale Anforderung für Heizkreis:

Code Auswählen Erweitern

[update notice] received write bai ExtFlowTempDesired QQ=10: 00;50.0;44.0;-;ff;00;00;00
Also HwcSwitch=0, HcFlowTempDesired=50 (nach Bedarf ändern), HwcTappingDesired=44 (Sollwert Warmwasser), HwcFlowTempDesired=ff, Unknown1=ff und die letzten 3 alle 0.

Für (reine) Warmwasser Anforderung habe ich folgende beobachtet, müsstest du mal probieren wie sich diese auswirken:

Code Auswählen Erweitern

received write bai ExtFlowTempDesired QQ=10: 01;-;44.0;-;ff;01;00;01
received write bai ExtFlowTempDesired QQ=10: 01;-;44.0;-;ff;01;c8;00
received write bai ExtFlowTempDesired QQ=10: 03;-;44.0;58.0;ff;01;00;01
received write bai ExtFlowTempDesired QQ=10: 03;-;44.0;58.0;ff;01;c8;00

Also wie ich das sehe: Unknown1 (bei mir) immer ff, Unknown2 scheint bei mir dieses VUV-Ventil umzuschalten (d.35).
Und HwcSwitch scheint auf 1 zu stehen, wenn nur Warmwasser gewünscht, aber aktuell kein Heizbedarf des Brenners erforderlich ist und auf 3, wenn er heizen soll.

[mebwaster]

Danke Sven! Das funktioniert!

Habe das ins bai.0010006101.inc eingetragen und mit den ExtFlowTempDesired Nachrichten läßt sich das nun wunderbar steuern.
Hatte anfangs bedenken, ob die alte Steuermethode (mittels Relais) weiterhin funktioniert wenn man einmal so ein Kommando absetzt. Ist aber kein Problem, die Therme stellt automatisch zurück, wenn eine Zeit lang kein weiteres Kommando kommt:

Code Auswählen Erweitern

read -f EBusHeatControl
yes

nach etwa 15 Minuten:

Code Auswählen Erweitern

read -f EBusHeatControl
no

Danke!

[Sven77]

Hallo,

ich habe für meine Heizung mit VRC 700 die Brennstoffverbrauchsdaten vermisst und habe meine 15.700.csv von ebusd etwas erweitert, jetzt werden die auch angezeigt.

Zeile 27-33 durch diese Zeilen ersetzen.

Code Auswählen Erweitern

r;w,,PrFuelSumHcThisMonth,ThisMonthsFConsumptionHc,,,,4E00,,,energy4,,,Aktueller Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcThisMonth,ThisMonthsEConsumptionHc,,,,4F00,,,energy4,,,Aktueller Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcThisMonth,ThisMonthsEConsumptionHwc,,,,5000,,,energy4,,,Aktueller Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcThisMonth,ThisMonthsFConsumptionHwc,,,,5100,,,energy4,,,Aktueller Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHcLastMonth,LastMonthsFConsumptionHc,,,,5200,,,energy4,,,Letzter Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcLastMonth,LastMonthsEConsumptionHc,,,,5300,,,energy4,,,Letzter Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcLastMonth,LastMonthsEConsumptionHwc,,,,5400,,,energy4,,,Letzter Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcLastMonth,LastMonthsFConsumptionHwc,,,,5500,,,energy4,,,Letzter Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHc,TotalFConsumptionHc,,,,5600,,,energy4,,,Brennstoffverbrauch Heizung gesamt
r;w,,PrEnergySumHc,TotalEConsumptionHc,,,,5700,,,energy4,,,Stromverbrauch Heizung gesamt
r;w,,PrEnergySumHwc,TotalEConsumptionHwc,,,,5800,,,energy4,,,Stromverbrauch Warmwasser gesamt
r;w,,PrFuelSumHwc,TotalFConsumptionHwc,,,,5900,,,energy4,,,Brennstoffverbrauch Warmwasser gesamt
r;w,,PrEnergySum,TotalEConsumption,,,,5C00,,,energy4,,,Dieses Jahr Stromverbrauch gesamt
r;w,,PrFuelSum,TotalFConsumption,,,,5D00,,,energy4,,,Dieses Jahr Brennstoffverbrauch gesamt

Gruß Paul

Ich wurde gerade per PN gefragt, ob es schon die Brennstoffverbräuche gibt.
@John30: könntest du diese im GitHub mit aufnehmen?

[cs-online]

Hi John,

ich musste nun wegen Wechsel auf RPI4 Buster neu installieren. Nun habe ich das dort so eingerichtet, wie vorher im Jessie, ich habe unter /ect/Default/ebusd

Code Auswählen Erweitern

EBUSD_OPTS="--configpath=/etc/ebusd --scanconfig  --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log"
EBUSD_OPTS1="--configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log"


dann die entsprechenden CSVs in die Ordner wie in der Konfig, dann zwei Dienste angelegt

1) ebusd.service : /lib/systemd/system/ebusd.service

Code Auswählen Erweitern

[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log

[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS

[Install]
WantedBy=multi-user.target




2) ebusd2.service : /lib/systemd/system/ebusd2.service

Code Auswählen Erweitern

[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log

[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS1

[Install]
WantedBy=multi-user.target



Beide enabled. Beim Booten läd er einen von beiden (mal den einen, mal den anderen), der andere schlägt fehl. Es kommt ein Hinweis auf die pid-Datei. Ich habe schon versucht, im 2.Service ebus2.pid anzugeben, das klappt aber auch nicht. Wenn ich den Service beende, der nicht funktioniert und dann wieder starte, laufen beide und liefern auch beide Daten.

Nun bin ich leider nicht so fit in Sachen Service und co... Was mache ich denn falsch ?

Grüße

Christian

[istler]

Hi Christan,

der PIDFile-Parameter muss natürlich unterschiedlich sein. Sonst gibt es Probleme beim beenden der Prozesse.
Nach den Änderungen den service-Dateien für systemd hast du da

Code Auswählen Erweitern

systemctl daemon-reload
aufgerufen? Damit werden die Änderungen an den Konfigdateien erst geladen. Danach dann versuchen die ebusd zu stoppen und neu zu starten.
Der Befehl

Code Auswählen Erweitern

systemctl status ebusd liefert dann den Status der Dienste ggf. die Fehlermeldung dazu.

Gruß
Maik

[cs-online]

Hallo Maik,

ja, das hatte ich gemacht. Hab nun nochmal im ebusd2 das ebusd.pid in ebusd2.pid geändert, dann systemctl daemon-reload, dann sudo reboot, dann:

Code Auswählen Erweitern

pi@raspberrypi:~ $ systemctl status ebusd
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: activating (start) since Sun 2019-12-29 22:01:07 CET; 1min 15s ago
  Process: 454 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 1.2M
   CGroup: /system.slice/ebusd.service

Dez 29 22:01:07 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:01:08 raspberrypi systemd[1]: ebusd.service: Failed to parse PID from file /run/ebusd.pid: Invalid argument
pi@raspberrypi:~ $ systemctl status ebusd2
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
   Active: activating (start) since Sun 2019-12-29 22:01:07 CET; 1min 42s ago
  Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
    Tasks: 6 (limit: 4915)
   Memory: 1.9M
   CGroup: /system.slice/ebusd2.service
           └─486 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI0

Dez 29 22:01:07 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:01:08 raspberrypi systemd[1]: ebusd2.service: Can't open PID file /run/ebusd2.pid (yet?) after start: No such file or directory


Dann wieder zurück beim ebusd2.service auf ebusd.pid, dann systemctl daemon-reload, dann sudo reboot, dann:

Code Auswählen Erweitern

pi@raspberrypi:~ $ systemctl status ebusd.service
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-12-29 22:11:21 CET; 1min 50s ago
  Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 489 (ebusd)
    Tasks: 6 (limit: 4915)
   Memory: 2.5M
   CGroup: /system.slice/ebusd.service
           └─489 /usr/bin/ebusd --configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-p

Dez 29 22:11:19 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:11:21 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: timeout) since Sun 2019-12-29 22:13:02 CET; 21s ago
  Process: 458 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
pi@raspberrypi:~ $ ebusctl
localhost: q
pi@raspberrypi:~ $ ebusctl -p 8889
localhost: q


mit anderen Worten: da lief es, nach erneutem reboot :

Code Auswählen Erweitern

pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
   Active: activating (start) since Sun 2019-12-29 22:21:35 CET; 25s ago
  Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
    Tasks: 6 (limit: 4915)
   Memory: 2.3M
   CGroup: /system.slice/ebusd2.service
           └─480 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if

Dez 29 22:21:35 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:21:36 raspberrypi systemd[1]: ebusd2.service: Failed to parse PID from file /run/ebusd.pid: Invalid argument


dann etwas gewartet :

Code Auswählen Erweitern

pi@raspberrypi:~ $ systemctl stop ebusd2.service
pi@raspberrypi:~ $ systemctl start ebusd2.service
pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2019-12-29 22:25:05 CET; 5s ago
  Process: 1180 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
Main PID: 1181 (ebusd)
    Tasks: 4 (limit: 4915)
   Memory: 588.0K
   CGroup: /system.slice/ebusd2.service
           └─1181 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-i

Dez 29 22:25:05 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:25:05 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..

Mit anderen Worten: mal geht es und alles wird geladen, mal klappt nur die erste Instanz, mal nur die zweite, wenn man die fehlgeschlagene Instanz beendet und neu startet, gehen wieder beide... Klingt irgendwie nach einem Timing-Problem oder ?

Brauche ich denn eigentlich zwei Services, nur um zwei Instanzen (also zwei verschiedene EBUS-Adapter) gleichzeitig laufen lassen zu können ?

[istler]

Moin Christian,

Per Default nutzt der ebusd-Daemon:

Code Auswählen Erweitern

--pidfile=FILE
PID file name (only for daemon) [/var/run/ebusd.pid]
Du musst deine Default-Konfiguration für den ebusd-Daemon um den Parameter pidfile erweitern und dort auch noch angeben wo der Dämon seine PID Datei schreiben soll. Am besten auf die gleichen Werte wie in der Systemd-Konfiguration.

Dann findet systemd auch die PID Datei vom zweiten Prozess und jeder Prozess kann gestoppt werden.


Schöne Grüße
Maik


Gesendet von meinem Aquaris_A4.5 mit Tapatalk

[cs-online]

Super, das war's (hoffe ich) Danke dir, wieder etwas schlauer geworden

Grüße Christian

[john30]

Per Default nutzt der ebusd-Daemon:

Code Auswählen Erweitern

--pidfile=FILE
PID file name (only for daemon) [/var/run/ebusd.pid]
Du musst deine Default-Konfiguration für den ebusd-Daemon um den Parameter pidfile erweitern und dort auch noch angeben wo der Dämon seine PID Datei schreiben soll. Am besten auf die gleichen Werte wie in der Systemd-Konfiguration.

Dann findet systemd auch die PID Datei vom zweiten Prozess und jeder Prozess kann gestoppt werden.

genau, Danke fürs Beantworten!

[john30]

Ich wurde gerade per PN gefragt, ob es schon die Brennstoffverbräuche gibt.
@John30: könntest du diese im GitHub mit aufnehmen?

bitte via PR