eBus Schaltung in Betrieb nehmen

[Orpheus]

Hallo,

Das macht der eingebaute Watchdog des Raspberry Pi viel besser.
Dazu muss nur ein entsprechendes Skript nach /etc/watchdog.d geschrieben werden:.

mir ist aufgefallen, bzw. in der /var/log/watchdog/repair-bin.stdout ist zu lesen, dass alle 8 Sekunden der ebusd neu gestartet wird.

Code Auswählen Erweitern


/etc/watchdog.d $ tail /var/log/watchdog/repair-bin.stdout
ebusd restarting at Do 27. Apr 19:26:48 CEST 2017
Starting ebusd (via systemctl): ebusd.service.
ebusd restarting at Do 27. Apr 19:26:56 CEST 2017
Starting ebusd (via systemctl): ebusd.service.
ebusd restarting at Do 27. Apr 19:27:03 CEST 2017

Also habe ich mir das Script mal genauer angesehen, bzw. die Befehle ausgeführt:

Code Auswählen Erweitern


/etc/watchdog.d $ ps -ef | grep ebusd.*USB0 | grep -v grep
/etc/watchdog.d $
etc/watchdog.d $ ps -ef | grep ebusd.*USB0
pi        3606   670  0 19:30 pts/0    00:00:00 grep --color=auto ebusd.*USB0
/etc/watchdog.d $
/etc/watchdog.d $ ps -ef | grep ebusd
root      1955     1  0 19:18 ?        00:00:00 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig
pi        3679   670  0 19:30 pts/0    00:00:00 grep --color=auto ebusd
/etc/watchdog.d $
/etc/watchdog.d $ ps -ef | grep "ebusd --pidfile.*--scanconfig" | grep -v grep
root      1955     1  0 19:18 ?        00:00:00 /usr/bin/ebusd --pidfile /var/run/ebusd.pid --scanconfig


Daraufhin habe ich den Eintrag im Script entsprechend abgeändert:

Code Auswählen Erweitern


...
       if [ -s /var/run/ebusd.pid ] ; then
           RUN=`ps -ef | grep ebusd.*--pidfile.*--scanconfig | grep -v grep`
           if [ "$RUN" != "" ] ; then
              #echo "ebusd is already running
...


Jetzt funktioniert es bei mir. (Achtung, nano legt im gleichen Verzeichnis eine ebusd.save an, da sucht man dann erst mal, weil es nicht funktioniert. )

Viele Grüße
Jürgen

[theotherhalf]

Hat jemand noch ein Set aus Ebus Platine und USB Wandler, welches er nicht mehr braucht? Bin bereit eines abzukaufen. Nachricht gerne per PM.

[hanswerner1]

Hallo,
Ich habe noch ein Rechte Problem auf den PI.
service ebusd start
Failed to start ebusd.service: Access denied

mit sudo geht's. Angemeldet bin ich als pi user. Welche Rechte muss ich ändern ?
VG
Thomas

[Reinhart]

das ist doch normal, dass ein Daemon wenn er händisch gestartet wird mit "sudo" gestartet werden muss.

Wenn der Service mit "sudo update-rc.d ebusd Defaults" zum Start/Stop Script hinzugefügt wurde, startet der Service beim booten ja mit den entsprechenden Rechten automatisch.

LG

[hanswerner1]

Wenn der Service mit "sudo update-rc.d ebusd Defaults" zum Start/Stop Script hinzugefügt wurde, startet der Service beim booten ja mit den entsprechenden Rechten automatisch.

Danke Reinhart, das wars. Bin in der Linux Welt leider nicht so zuhause.

[theotherhalf]

Wenn der Service mit "sudo update-rc.d ebusd Defaults" zum Start/Stop Script hinzugefügt wurde, startet der Service beim booten ja mit den entsprechenden Rechten automatisch.

LG

Ist es relevant an welche Stelle im Skript das Kommando eingefügt wird? Ich würde es an den Anfang setzen.

[Reinhart]

das brauchst du nur einmal in der Konsole aufrufen, trägt sich dann selber ein.

LG

[texel]

Wodurch könnte das blockiert werden?

Hi, habe seit heute ähnliches Problem. Ich hab einen alten Raspi1 im Einsatz - heute Linux upgedated, von ebusd2.1 auf ebusd3 upgegraded.
Ebusd3 erkennt z.T. meine Geräte nicht mehr (nur noch den 50.mc) - nicht aber BAI.

ok - wieder downgrade auf ebusd2.1:
Jetzt scheint es auch so, dass ich nicht mehr auf den Bus schreiben kann.
Es kommt immer ein read timeout ...

bai WarmstartDemand = no data stored
bai WarmstartOffset = no data stored
bai WaterHcFlowMax = no data stored
bai WaterPressure = no data stored
bai WaterpressureBranchControlOff = no data stored
bai WaterpressureMeasureCounter = no data stored
bai WaterpressureVariantSum = no data stored
bai WP = no data stored
bai WPPostrunTime = no data stored
bai WPSecondStage = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.08 id = no data stored
scan.08 ident = MF=Vaillant;ID=BAI00;SW=0518;HW=7401
scan.15 ident = no data stored
scan.50 ident = MF=Vaillant;ID=V6100;SW=0418;HW=1902
scan.75 ident = MF=Vaillant;ID=V8100;SW=0202;HW=2502
v81 CMResetCnt = no data stored
v81 COMErrorCnt = no data stored
v81 DesiredHcRoomTempDesired = no data stored
v81 DisplayedRoomTemp = no data stored
v81 eBUSCRC = no data stored
v81 eBUSFifoDiffCntMax = no data stored
v81 EEpromMaxInkonsCnt = no data stored
v81 FiFoResetCnt = no data stored
v81 Hc2RoomTemp = no data stored
v81 HcActiveSpecialFunction = no data stored
v81 HcRoomTempDesiredAdjustable = no data stored
v81 LVResetCnt = no data stored
v81 OperatingMode430 = no data stored
v81 POCResetCnt = no data stored
v81 RoomTempOffset = no data stored
v81 RoomTempOffsetSelfWarming = no data stored
v81 SelectedHc = no data stored
v81 StackeBUSTaskMax = no data stored
v81 StackLifeCheckTaskMax = no data stored
v81 StackMainTaskMax = no data stored
v81 Variant = no data stored
v81 VariantDKRefreshCnt = no data stored
v81 WDResetCnt = no data stored

localhost: r -f WarmstartDemand
ERR: read timeout

localhost: r -c bai WarmstartDemand
ERR: read timeout

localhost: r WarmstartDemand
ERR: read timeout

[texel]

Hi, ich habe soeben nochmals alle ebusd Versionen durchprobiert. Alle haben wohl ein Problem auf den Bus zu schreiben:

root@ebusd:/usr/bin/ebusd_2.1.0# ./ebusd -s -f --configpath=/etc/ebusd_2.1.0/ --receivetimeout=99999
2017-05-22 13:50:49.106 [main notice] ebusd 2.1.0c0ea8e started
2017-05-22 13:50:49.126 [main notice] found messages: 12 (0 conditional on 0 conditions, 0 poll, 6 update)
2017-05-22 13:50:49.393 [bus notice] signal acquired
2017-05-22 13:50:50.761 [bus notice] new master 70, master count 2
2017-05-22 13:50:50.777 [update notice] unknown MS cmd: 7050b505053c37013701 / 00
2017-05-22 13:50:50.842 [bus notice] new master 10, master count 3
2017-05-22 13:50:50.887 [bus notice] new master 03, master count 4
2017-05-22 13:50:50.889 [update notice] unknown MS cmd: 1008b510090000006effff010000 / 0101
2017-05-22 13:50:51.128 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-05-22 13:50:52.775 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-05-22 13:50:53.768 [update notice] unknown MS cmd: 7050b5040126 / 0705000009003701
2017-05-22 13:50:54.852 [update notice] unknown MS cmd: 1008b5110101 / 096a6600133822000024
2017-05-22 13:50:56.916 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2017-05-22 13:50:58.610 [update notice] unknown MS cmd: 7008b5110101 / 096a6600133822000024
2017-05-22 13:50:58.912 [update notice] unknown MS cmd: 1050b5040137 / 0200ff
2017-05-22 13:50:59.134 [main notice] starting initial scan for fe
2017-05-22 13:50:59.148 [bus error] send to fe: ERR: read timeout, retry
2017-05-22 13:50:59.194 [bus error] send to fe: ERR: read timeout, retry
2017-05-22 13:50:59.242 [bus error] send to fe: ERR: read timeout, retry
2017-05-22 13:50:59.290 [bus error] send to fe: ERR: read timeout
2017-05-22 13:50:59.291 [main error] initial scan failed: ERR: read timeout
2017-05-22 13:50:59.323 [bus error] send to 08: ERR: read timeout, retry
2017-05-22 13:50:59.371 [bus error] send to 08: ERR: read timeout, retry
2017-05-22 13:50:59.418 [bus error] send to 08: ERR: read timeout, retry
2017-05-22 13:50:59.466 [bus error] send to 08: ERR: read timeout
2017-05-22 13:50:59.468 [main error] scan config 08 message: ERR: read timeout
2017-05-22 13:51:00.913 [update notice] unknown MS cmd: 1008b510090000006effff010000 / 0101
2017-05-22 13:51:01.166 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-05-22 13:51:01.497 [bus error] send to 15: ERR: read timeout, retry
2017-05-22 13:51:01.545 [bus error] send to 15: ERR: read timeout, retry
2017-05-22 13:51:01.577 [bus error] send to 15: ERR: read timeout, retry
2017-05-22 13:51:01.624 [bus error] send to 15: ERR: read timeout
2017-05-22 13:51:01.626 [main error] scan config 15 message: ERR: read timeout
2017-05-22 13:51:02.990 [update notice] unknown MS cmd: 1050b505023001 / 0101

Den timeout hochzusetzen hat auch nichts gebracht.

Ich vermute das das update/upgrade auf die neuste Linuxversion das Problem verursacht hat.

Da ja ansonsten die lesenden Datenpakete, die vom Bus kommen, vernünftig aussehen liegt es vermutlich nicht an der Hardware und auch nicht an ebusd??

[theotherhalf]

das brauchst du nur einmal in der Konsole aufrufen, trägt sich dann selber ein.

Danke Reinhart! Punkt is abgehakt.

[Reinhart]

@Texel

wenn du noch eine Sicherung deiner SD hast, dann wäre das einfach die auf eine neue SD zurück spielen und damit austesten.
Dann könntest du durch einfaches umstecken der SD den Fehler schön einkreisen.

Die Platine verhält sich ja so als wäre der Sendeweg defekt, du bist ja nicht der erste dem dieser komische Fehler nach dem Update passiert.
Ich hatte das ja auch einmal, habe aber dem ganzen wenig Beachtung geschenkt und einfach eine Sicherung zurück gespielt, die Schaltung sicherheitshalber getauscht und dann Schritt für Schritt wieder upgedatet. Hatte aber dann alles geklappt und konnte den Fehler nicht mehr nachvollziehen.

LG

[a200]

Hi, ich habe soeben nochmals alle ebusd Versionen durchprobiert. Alle haben wohl ein Problem auf den Bus zu schreiben:

Den timeout hochzusetzen hat auch nichts gebracht.

Ich vermute das das update/upgrade auf die neuste Linuxversion das Problem verursacht hat.

Da ja ansonsten die lesenden Datenpakete, die vom Bus kommen, vernünftig aussehen liegt es vermutlich nicht an der Hardware und auch nicht an ebusd??

Gleiches Problem hier. Habe meinen aBus-Adapter prüfen lassen. Soll i.O. sein. Ich kann trotzdem nur lesen.
ebusd > 3.0
Vaillant auroMATIC vrs 620/3

[texel]

@Reinhard: dummerweise hab ich keine Sicherung auf SD Karte und leider auch keinen Zugriff auf die Hardware (kann mich nur Remote aufschalten)..

[a200]

Hi, ich habe soeben nochmals alle ebusd Versionen durchprobiert. Alle haben wohl ein Problem auf den Bus zu schreiben:

Den timeout hochzusetzen hat auch nichts gebracht.

Ich vermute das das update/upgrade auf die neuste Linuxversion das Problem verursacht hat.

Da ja ansonsten die lesenden Datenpakete, die vom Bus kommen, vernünftig aussehen liegt es vermutlich nicht an der Hardware und auch nicht an ebusd??

Moin,
kannst du noch sagen, wann dein eBusd noch korrekt gelaufen ist? Ich konnte noch nie schreibend auf den Bus zugreifen und wie du kann ich mit einer alten Version besser meine Geräte erkennen als mit den aktuellen. Ich würde ein altes Raspi-Image suchen und testen ob ich dann auf den eBus zugreifen kann.  Allerdings wäre eine grobe Orientierung wann  es bei dir noch ging, ganz gut.

Danke, a200.

[john30]

kannst du noch sagen, wann dein eBusd noch korrekt gelaufen ist? Ich konnte noch nie schreibend auf den Bus zugreifen und wie du kann ich mit einer alten Version besser meine Geräte erkennen als mit den aktuellen. Ich würde ein altes Raspi-Image suchen und testen ob ich dann auf den eBus zugreifen kann.  Allerdings wäre eine grobe Orientierung wann  es bei dir noch ging, ganz gut.

Für das "Erkennungsproblem" gibt es ein issue, das natürlich behoben werden muss: https://github.com/john30/ebusd/issues/87
Die Timeout Geschichte scheint mit Änderungen am ftdi Modul im Kernel zu tun zu haben.
Inzwischen sehe ich auf einem RPi 2 mit aktuellem archlinux 4.9.30-1, dass immer noch eine Latenz von bis zu 20ms zwischen Senden eines bytes und Rückempfang besteht. Deshalb kann das nur dann funktionieren, wenn ebusd als Startparameter noch --latency=20000 o.ä bekommt.