Läuft: Heizung mit eBus-Schnittstelle

[MilanK]

@Reinhart: interessant, ich habe niemals davon gehört. Doch, funktioniert es gut bei mir (Arch Linux).

Kannst du probierien, ob ebusd den ebusd.log ganze Zeit geöffnet hält:

Code Auswählen Erweitern

$ fuser -a /var/log/ebusd.log

(Es soll PIDs drücken. In meinem Fall gibts es kein. Möglich ist, daß es nichts mit 'fd' zu tun hat...)

[john30]

Code Auswählen Erweitern

Not using O_APPEND in the first case and using it properly in
the working case.

okay, habs auf append umgestellt. wär cool, wenn Du das probieren könntest.

ich hatte so einen ähnlichen Fall mal in einem anderen Projekt. logrotate ist da manchmal bisschen zickig
LG John

[john30]

Das Pidfile läuft aber leider wieder  in /usr/local/var/.

Kann fast nicht sein. Hast Du den letzten Stand vom git genommen ("git pull")?
Was sagt denn bei Dir die Ausgabe von:

Code Auswählen Erweitern

strings /usr/bin/ebusd |grep /run

Mit der aktuellen git Version kommt bei mir

Code Auswählen Erweitern

/var/run/ebusd.pid raus.

[john30]

Code Auswählen Erweitern

$ fuser -a /var/log/ebusd.log
(Es soll PIDs drücken. In meinem Fall gibts es kein. Möglich ist, daß es nichts mit 'fd' zu tun hat...)

Wenn ich fuser als root aufrufe, dann zeigt es mir brav die PID vom ebusd.

[amunra]

Hallo zusammen,

ein paar Zwischenfragen zum Thema ebusd defs/commands vrc430/470:

- sind die hier im Forum beschriebenen Änderungen/Anpassungen (Datentyp-Definitionen etc.) in ein(das ursprüngliche) Dokument eingeflossen?
- hat jemand die vrc430 commands (bai00 sind dankenswerterweise von pah schon überarbeitet) nach den, wie ich finde sehr sinnvollem semantisch motivierten Ansatz von pah, angepasst und kann das hier bereitstellen?

Falls nicht, dann setze ich mich mal dran ... (dauert aber ein paar Tage).

Danke.
VG Arthur

P.S: @pah - Idee war die Config-Files in Wiki und/oder sourceforge/Github(EBUSD/contib) bereitzustellen - oder?

[Prof. Dr. Peter Henning]

Ja, war die Idee.

Ich bin derzeit beruflich zu 150% ausgelastet, darum derzeit etwas weniger Posts von mir.

LG

pah

[Reinhart]

so, habe jetzt alles aus dem Git neu geladen und kompiliert. Vorher alle alten Verzeichnisse "ebusd*" auf dem Raspi verschoben.

Installiert habe ich mit der Standard Prozedur:

Code Auswählen Erweitern

svn co https://github.com/john30/ebusd
cd /home/pi/ebusd/trunk
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd/trunk/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd 
sudo chmod 755 /etc/init.d/ebusd       
sudo update-rc.d ebusd defaults     



Folgende Ergebnisse:

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd/trunk $ ps -aux|grep ebusd
root     13521  0.4  0.5  28068  2348 ?        Ssl  12:54   0:09 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888


Dämon OK, Pfade OK.

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd/trunk $ sudo strings /usr/bin/ebusd |grep /run
can't open pidfile: /var/run/ebusd.pid


Pidifle kann mit "strings" nicht geöffnet werden, aber Pfad stimmt.

Code Auswählen Erweitern


pi@raspberry2 ~/ebusd/trunk $ sudo cat /var/run/ebusd.pid
13521


Pidfile ist korrekter Pfad und auch die Pid ist korrekt eingetragen.

Code Auswählen Erweitern


pi@raspberry2 ~/ebusd/trunk $ sudo fuser -a /var/log/ebusd.log
/var/log/ebusd.log:  13521


- Dämon ok
- Pidfile ok
- Logfile ok
- Logrotate ? (erst morgen)


Es sieht nun alles gut aus, ob Logrotate jetzt korrekt funktioniert sehe ich morgen Früh um 06:25 und werde dann noch berichten. Während der ganzen Installationsphase ist mir aufgefallen, das FHEM überhaupt nicht mehr aus der Ruhe zu bringen ist, er zeigt zwar im EBUS Status "Disconnect" an, aber das war es. Nachdem der ebusd am anderen Raspi wieder gelaufen ist habe ich "set EBUS reopen" abgesetzt und alles läuft wieder.

Übrigens, habe gestern auf Raspi 2 B gewechselt (SD Karte umgesteckt) und bin fasziniert von der Geschwindigkeit der Plots. Als YAF Anhänger habe ich nun auch deutlich mehr Speed bei der Anzeige der Grafiken (Bilder). Ebusd läuft auf Raspi B+ und werde hier nicht tauschen, der reicht bei weitem locker aus.

Schöne Grüße
Reinhart

[john30]

Prima, Danke Dir fürs Testen!

Code Auswählen Erweitern

pi@raspberry2 ~/ebusd/trunk $ sudo strings /usr/bin/ebusd |grep /run
can't open pidfile: /var/run/ebusd.pid


Pidifle kann mit "strings" nicht geöffnet werden, aber Pfad stimmt.

Da bist Du jetzt auf die zugegebenermaßen etwas verwirrende Ausgabe reingefallen: Das "strings" Kommando extrahiert alle Strings aus dem Binary und spuckt diese aus. Einer der Strings in Deinem ebusd lautet also "can't open pidfile: /var/run/ebusd.pid", was zu erwarten war. Etwas verwunderlich ist nur, dass ein zweiter String "/var/run/ebusd.pid" nicht bei Dir erscheint. Der ist nämlich auch in dem ebusd Binary enthalten.

[Reinhart]

@john30

ja mit den "strings", da bin ich reingefallen, habe in der Manpage nachgelesen was der tut.

Betreffend Logrotate, das ist bei deiner neuen Version nun auch ok! Das Log wird ordentlich um 06:25 gepackt (ebusd.log.1.gz), das alte sauber gelöscht und ein neues begonnen.

Es dürfte sich aber bei der neuen Version ein kleiner Fehler eingeschlichen haben. Da ich jetzt die Logs genau untersuchen kann ist mir aufgefallen das es öfters zu Busfehlern kommt.

[bus error] ERR: arbitration lost, retry

Hier ein Beispiel:

Code Auswählen Erweitern

2015-02-12 06:42:23.869 [update notice] update bai00 Status: 46.0;45.0;-0.438;56.0;51.0;0
2015-02-12 06:42:27.010 [main notice] >>> r anlagendruck
2015-02-12 06:42:27.115 [bus notice] read res: 03ca080092
2015-02-12 06:42:27.116 [main notice] <<< 2.250
2015-02-12 06:42:27.138 [main notice] >>> r vorlauftemperatur
2015-02-12 06:42:27.257 [bus notice] read res: 03f5020062
2015-02-12 06:42:27.258 [main notice] <<< 47.31
2015-02-12 06:42:27.280 [main notice] >>> r returntemp
2015-02-12 06:42:27.411 [bus notice] read res: 05cc0233fd0084
2015-02-12 06:42:27.412 [main notice] <<< 44.75
2015-02-12 06:42:27.434 [main notice] >>> r Fanspeed
2015-02-12 06:42:27.565 [bus notice] read res: 04b00c4ff373
2015-02-12 06:42:27.565 [main notice] <<< 324.8
2015-02-12 06:42:27.587 [main notice] >>> r PumpPower
2015-02-12 06:42:27.698 [bus notice] read res: 0143d8
2015-02-12 06:42:27.698 [main notice] <<< 67
2015-02-12 06:42:27.720 [main notice] >>> r wwsolltemp
2015-02-12 06:42:27.753 [bus error] ERR: arbitration lost, retry
2015-02-12 06:42:27.852 [update notice] unknown MS cmd: 1008b51009000073ffffff04ff0035 / 01019a
2015-02-12 06:42:28.128 [bus notice] read res: 03820300d7
2015-02-12 06:42:28.129 [main notice] <<< 56.12
2015-02-12 06:42:28.150 [main notice] >>> r mcHeatingCurve
2015-02-12 06:42:28.252 [bus notice] read res: 026e00f5
2015-02-12 06:42:28.252 [main notice] <<< 1.10
2015-02-12 06:42:31.874 [update notice] update bai00 Status: 53.0;44.0;-0.438;56.0;51.0;1


Meine Abfrage sieht dabei so aus.

Code Auswählen Erweitern

define EBUS.Timer at +*00:06:00 get Aussentemp Aussentemp;;get Druck Druck;;get Vorlauf Vorlauf;;get Status status;;get Ruecklauf Ruecklauf;;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get WarmW.Temp. WarmW.Temp.;;get HKurve HKurve


d.h., ich hole alle 6 Minuten 9 Datenpunkte vom Bus. Irgendwie kommt der eBus jetzt manchmal durcheinander. Ich habe gezielt die älteren Logs jetzt durchforstet, aber da ist kein einziger Fehler enthalten. Ich habe jetzt temporär einmal die 9 Datenpunkte in 3-er Gruppen aufgeteilt und bis jetzt keinen weiteren Fehler mehr entdeckt. Läuft aber erst 1 Stunde so.

Ich kenne ja das eBus Protokoll nicht und weiß daher auch nicht ob das so ähnlich wie eine Colission-Domäne (TCP) funktioniert. Hier wird ja einfach 9,81 Mikro Sec. gelauscht und wenn nichts am Netz ist dann gesendet. Wenn nun gleichzeitig eine andere Station zu senden beginnt (bei gleicher Kabellänge) dann kommt es zu einer Kollision und das Paket wird wiederholt. Laut Log sieht das zumindest jetzt so aus, als würde Fhem den Befehlsstapel abarbeiten obwohl gleichzeitig noch eine Antwort unterwegs ist.

Ich hänge hier das Log von gestern an, da habe ich bis ungefähr zur Mittagszeit die alte "ebusd" und dann auf die letzte Version gewechselt. Ab dann beginnen die "arbitration" Fehler. Scheint mir auf jeden Fall ein Zusammenhang zu sein.

Ebenso wurde unter Fhem nun der erste Disconnect in der Nacht gemeldet (Mail) welchen aber der Watchdog eine Minute später selber beheben konnte.

edit 14:45: auch durch Ändern der Abfrage weniger Werte ist der Fehler NICHT behoben.

LG
Reinhart

[heikoh81]

Hallo zusammen,

melde mich auch mal wieder, habe aber die letzte Zeit immer mit gelesen.
Meine ebusd von ca. 28.12.2014 läuft ja auch weitestgehend stabil, per Cronjob starte ich den Heizungs-Raspi alle 3 Tage neu, weil ab ca. 5-7 Tagen irgendwas eingefroren ist (ebusd war noch aktiv, ebusd restart hat ebenfalls nichts gebracht, nur der reboot).

@Jojo11
John30 hat ja die ebusd Version hier bei dieser Diskussion weiter verbessert. http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167 und liegt in seinem Git.
Bei mir läuft diese Version etwa eine Woche stabil und ohne Probleme.

Never change a running system
Aber falls ich nun nochmal probieren möchte - ist die Binary noch aktuell oder lieber jetzt neu kompilieren aus dem john30-GIT?

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

"Arbitration lost" ist kein Fehler - sondern eigentlich zu erwarten, wenn auf einem Bus mehrere Master aktiv sein müssen.

LG

pah

[Reinhart]

@pah
Danke für die Aufklärung, dann verstehe ich das so wie eine ganz normale Kollision!
Das lustige an der Sache, ich habe heute Früh exakt um die selbe Uhrzeit wieder per Mail den Ausfall des eBus gemeldet bekommen. Dein Watchdog hat auch hier wieder perfekt funktioniert. Was ich aber nicht ganz verstehe, dass dieser Fehler plötzlich da war. Ich werde daher noch etwas experimentieren um herauszufinden woran das liegen kann. Im Prinzip sollte es mich ja nicht weiter stören, weil der Betrieb dadurch ja nicht eingeschränkt ist, ich bin halt  vorsichtig wenn ich in den Logs Errors finde. Da bin ich vermutlich durch meine über 20-jährige Tätigkeit als System Manager zu sehr geprägt worden. Alles andere was eBus betrifft funktioniert ja mit der letzten Version perfekt. Yuhu und John haben da wirklich sehr gute Arbeit geleistet.

@heikoh81
ich kann dir gerne die letzte Binary posten, ich würde aber einfach alles neu aus dem SVN laden und kompilieren da John30 ja auch in diversen Scripten was geändert hat. Ein paar Posts weiter oben habe ich ja meine Vorgangsweise gepostet, die funktioniert bei mir (Raspi unter Debian) perfekt. Vor allem was Logging (logrotate, Pfad) und Dämon betrifft gabs doch einige Änderungen.
eBus via Cron neu starten war bei mir nie notwendig, da der Bus selbst ja läuft und läuft ......

Vielleicht noch ein Tipp, ich habe festgestellt, das die Raspis sehr empfindlich sind was DN betrifft. Das merkt man wenn man eine SSH Sitzung öffnet und zwischen Benutzername und Passwort es einige Sekunden dauert bis man das Passwort eingeben kann. Dass muss sofort gehen. Dann stimmt irgendwas im DNS nicht und du solltest in dieser Ecke weiter suchen. Ich habe sicherheitshalber auch noch in der Hosts meine Clients eingetragen, das ist zwar unsauber aber es gibt dann absolut keine Probleme mehr.

[john30]

Danke für die Aufklärung, dann verstehe ich das so wie eine ganz normale Kollision!

Genau, "arbitration lost" im Log ist zunächst einmal nichts schlimmes bzw. ungewöhnliches, weil dann einfach zu diesem Zeitpunkt zwei Teilnehmer eine nachricht auf den Bus absetzen wollten. Das ist im eBUS Protokoll vorgesehen und wegen der Arbitrierung kann es auch nur 25 Master am Bus geben.
Unschön wird es, wenn ebusd es dauerhaft nicht schafft, Zugang zum Bus zu bekommen. Dann werden abgesetzte Anfragen im Client mit "ERR: arbitration lost" beantwortet. Das sollte eher nicht passieren.

Das lustige an der Sache, ich habe heute Früh exakt um die selbe Uhrzeit wieder per Mail den Ausfall des eBus gemeldet bekommen.

Wie sieht das denn genau aus? Kommen dann keine Nachrichten mehr durch oder "stirbt" der Dienst?? Das darf natürlich nicht sein, darum wäre ich um Hinweise dankbar.

LG John

[lawern]

Hallo

Betreffend die Heizkurve: Die hat immer Steigung und Offset - beeinflussbar durch die eingestellte (nicht tatsächliche) Raumtemperatur. Diese "Heizkurve" sollten wir also sehen als eine lokale lineare Annäherung an die tatsächlich gewünschte Heizkurze.

Ziel solte hier also sein, einen schönen variablen PID-Regler zu programmieren (gibt es schon), der in regelmäßigen Abständen Offset und Steigung der Heizkurve anpasst (gibt es noch nicht). Damit ist sichergestellt, dass nicht FHEM die Heizung direkt steuert - sondern nur als "Überintelligenz" über der Heizung sitzt, so dass diese auch autonom laufen kann.

Genau diese Gedanken habe ich mir auch gemacht. Ich möchte über das setzen der Heizkurve in meiner VCR 430 auch gern indirekt die Vorlauftemperatur einstellen.
Die Heizkurve der VCR 430 ist aber leider nicht linear. Hat hier jemand eine Idee, welche Funktion dahinter stecken könnte?

Lars

[Reinhart]

@john30

habe nun endlich den Fehler des täglichen "reconnect" des eBus gefunden. Der eBus ist unschuldig und hat mit der Sache nichts zu tun, im der syslog bin ich fündig geworden. Es wird gezielt die Wlan Verbindung restartet "Deleting Interface Wlan0", so ein Schmarn!

Code Auswählen Erweitern

Feb 14 03:59:57 raspberry2 wpa_supplicant[1746]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1d:7e:e3:80:80 reason=0
Feb 14 03:59:57 raspberry2 dhclient: Internet Systems Consortium DHCP Client 4.2.2
Feb 14 03:59:57 raspberry2 dhclient: Copyright 2004-2011 Internet Systems Consortium.
Feb 14 03:59:57 raspberry2 dhclient: All rights reserved.
Feb 14 03:59:57 raspberry2 dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb 14 03:59:57 raspberry2 dhclient:
Feb 14 03:59:57 raspberry2 dhclient: Listening on LPF/wlan0/00:13:ef:20:32:95
Feb 14 03:59:57 raspberry2 dhclient: Sending on   LPF/wlan0/00:13:ef:20:32:95
Feb 14 03:59:57 raspberry2 dhclient: Sending on   Socket/fallback
Feb 14 03:59:57 raspberry2 dhclient: DHCPRELEASE on wlan0 to 10.0.0.254 port 67
Feb 14 03:59:58 raspberry2 ifplugd(wlan0)[1674]: Link beat lost.
Feb 14 04:00:00 raspberry2 ntpd[2135]: Deleting interface #3 wlan0, 10.0.0.84#123, interface stats: received=351, sent=356, dropped=0, active_time=86330 secs
Feb 14 04:00:00 raspberry2 ntpd[2135]: 86.59.13.46 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 93.185.134.36 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 78.46.40.125 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 86.59.80.170 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: peers refreshed
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: Executing '/etc/ifplugd/ifplugd.action wlan0 down'.
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: client: /sbin/ifdown: interface wlan0 not configured
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: Program executed successfully.
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Trying to associate with 00:1d:7e:e3:80:80 (SSID='Mobile' freq=2412 MHz)
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Association request to the driver failed
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Associated with 00:1d:7e:e3:80:80
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: WPA: Key negotiation completed with 00:1d:7e:e3:80:80 [PTK=CCMP GTK=CCMP]
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:1d:7e:e3:80:80 completed (reauth) [id=0 id_str=]
Feb 14 04:00:46 raspberry2 dhclient: Internet Systems Consortium DHCP Client 4.2.2
Feb 14 04:00:46 raspberry2 dhclient: Copyright 2004-2011 Internet Systems Consortium.
Feb 14 04:00:46 raspberry2 dhclient: All rights reserved.
Feb 14 04:00:46 raspberry2 dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb 14 04:00:46 raspberry2 dhclient:
Feb 14 04:00:46 raspberry2 dhclient: Listening on LPF/wlan0/00:13:ef:20:32:95
Feb 14 04:00:46 raspberry2 dhclient: Sending on   LPF/wlan0/00:13:ef:20:32:95
Feb 14 04:00:46 raspberry2 dhclient: Sending on   Socket/fallback
Feb 14 04:00:46 raspberry2 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
Feb 14 04:00:46 raspberry2 dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Feb 14 04:00:46 raspberry2 dhclient: DHCPOFFER from 10.0.0.254
Feb 14 04:00:46 raspberry2 dhclient: DHCPACK from 10.0.0.254
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Link beat detected.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Executing '/etc/ifplugd/ifplugd.action wlan0 up'.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: client: /sbin/ifup: interface wlan0 already configured
Feb 14 04:00:46 raspberry2 dhclient: bound to 10.0.0.84 -- renewal in 298635 seconds.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Program executed successfully.
Feb 14 04:00:47 raspberry2 ntpd[2135]: Listen normally on 4 wlan0 10.0.0.84 UDP 123
Feb 14 04:00:47 raspberry2 ntpd[2135]: peers refreshed
Feb 14 05:00:41 raspberry2 wpa_supplicant[1746]: wlan0: WPA: Group rekeying completed with 00:1d:7e:e3:80:80 [GTK=CCMP]


Das Ganze täglich zur selben Uhrzeit. Ich habe auch schon nachgelesen, angeblich könnte das ein Bug des Realtek Treibers ein, kann ich mir aber nicht vorstellen. Im Cronjob kann ich nichts finden, aber von irgendwo wo muss es ja getriggert werden. Ich suche aber nicht länger herum, sondern gebe dem Raspi auch ein Lan das unmittelbar in der Nähe (Gaszähler) ist. Wenn man es weiß, stört es auch nicht weiter, weil es ja automatisch wieder da ist.

LG
Reinhart