Läuft: Heizung mit eBus-Schnittstelle

[Jojo11]

Hallo Jojo11,

das würde jetzt den Rahmen sprengen (sorry), soviel kann ich (kurz/grob) erklären:
-   Ich nutze nicht das ECMD Modul und auch kein(e) Dummy-Button(s) -> Es ist ein eigenes Modul
-   Die CSV Datenstruktur ist ja vorgegeben – die Idee ist, die schon vorhandenen Informationen zu verwenden.
-   Die CSV Datei wird eingelesen, entsprechend in ein Hash (Datenstruktur) gespeichert, verarbeitet (den zugehörigen Klassen zugewiesen) und an die Set/Get Funktionen des Moduls übergeben.
Dies nur als Kurzfassung.
VG Arthur

Ok, danke!

schöne Grüße
Jo

[amunra]

Hallo,

leicht OT, aber evtl. hier auch von Interesse. Mit ECMD habe ich folgendes beobachtet:
FHEM läuft auf einem cubietruck, EBUSD auf einem Pi. Wenn ich den ebusd stoppe, fährt die Auslastung des cubietruck in die Höhe, so dass fhem nicht mehr reagiert. Es hilft nur ein Neustart des CT (und natürlich des ebusd). Kann ich das Einfrieren bei fehlender Verbindung zum ebusd unterdrücken?

schöne Grüße
Jo

Verwendest du auch die aktuelle ECMD Version? In der neuen Version soll das Thema "einfrieren bei disconnect" behoben sein?
VG Arthur

[amunra]

Ich denke, dass es unmöglich ist die Drinnentemperatur aus dem drahtlosen Raumregler abzulesen, nicht war? Es ist wahrsheinlich so, das der Raumregler nur die Gastherme informiert (einmall in zehn minuten oder wenn manipuliert), das die Therme brennen soll oder nicht

Kann mich Jojo11 nur anschließen - probier doch die VRC430.csv (Datei gibt es hier im Forum) aus.

VG Arthur

[Jojo11]

Verwendest du auch die aktuelle ECMD Version? In der neuen Version soll das Thema "einfrieren bei disconnect" behoben sein?
VG Arthur

Eigentlich schon. Fhem ist gestern aktualisiert worden.

schöne Grüße
Jo

[MilanK]

Warum soll das unmöglich sein? Habe auch einen Funkregler 470f, der auch über den ebus kommuniziert.

schöne Grüße
Jo

Korrekt! Ich habe schon was abgelesen, jetz muss ich noch viel lernen. Ich komme wieder zurück wenn ich etwas ereiche.

Noch eine Sache würde mir helfen:

Code Auswählen Erweitern

Die BC-Nachricht ist:       update BC cmd: 10feb5160301500127
Die menschlesbare Wert ist: update BC OutsideTempBC: 1.312

Die Nachrichtstruktur soll sein:

Code Auswählen Erweitern

10 FE B516 01 temperature D2B
Nach der ebusd Wiki is der Datentyp

Code Auswählen Erweitern

"D2B": signed number, -127.99 - +127.99 (fraction 1/256, divisor 256, 2 bytes)

Wie soll man die Wert "5001" handeln um die 1.312 zu bekommen? 0x5001 ist dec 20481, dividiert bei 256 ist 80. Dass wäre -48 °C...  Ich bin kein Programmer, sicher muss es einfach sein.

[Prof. Dr. Peter Henning]

@MilanK. Nein. LSB (Least Significant Byte) zuerst ! Also 5001 => 0x0150 = 1*256 + 5*16 => dividieren durch 256 => 1 + 5/16. Das stimmt also

@amunra: Ich habe darüber nachgedacht, dafür ein weiteres ein eigenes FHEM-Modul zu schreiben und FHEM direkt mit _allen_Kommandos an den EBUS zu koppeln.. Aber erstens möchte ich weiterhin den ebusd auf einem separaten Raspberry laufen lassen, zweitens halte ich das Ganze für sehr gefährlich: Wenn es möglich ist, wichtige Betriebsparameter der Heizung per Mausklick aus der Entfernung zu setzen, ist dies eine erhebliche Sicherheitslücke. Damit meine ich nicht einmal einen Hack (Vaillant hat das ja aufgegeben wegen der Unsicherheit). Sondern z.B. eine Fehlbedienung. So könnte man (dummerweise) die Gasart ändern, oder die Vorlauftemperatur auf 150 Grad setzen und die Heizung zerstören.

Das ist viel zu riskant. Nicht umsonst schützt Vaillant wichtige Einstellungen bei der manuellen Eingabe (nicht auf dem EBUS) durch (na ja) Passwörter. Und von Fragen der Versicherung ganz zu schweigen.

Nun könnte man ja noch argumentieren, dass auf dem Raspberry ein separates FHEM laufen kann, das mit der Hauptinstanz über FHEM2FHEM kommuniziert. Das ist aber auch nur telnet.

Zusammengefasst also: ebusd auf einem separaten System, und Zugriff darauf mit ein paar kryptischen telnet Kommandos ist (etwas) sicherer, als das direkt in FHEM einzubauen.

Was also machen ? Mir schwebt vor, ein zentrales Modul zur Heizungssteuerung zu schreiben, das dann verschiedene backends hat, die mit unterschiedlichen Heizungssystemen kommunizieren. So etwas habe ich ja schon mit der OWX-Modulfamilie produziert.

LG

pah

[MilanK]

@MilanK. Nein. LSB (Least Significant Byte) zuerst ! Also 5001 => 0x0150 = 1*256 + 5*16 => dividieren durch 256 => 1 + 5/16. Das stimmt also

Danke.

[amunra]

Hallo pah,

soviel vorab – ich bin immer noch im ,,read-only" Modus unterwegs. ;o)

Mir ist in erster Linie wichtig alle notwendigen Daten zu erfassen, verstehen und daraus evtl. Optimierungen/Maßnahmen abzuleiten, ob diese Maßnahmen automatisiert (Stichwort: Pumpensteuerung via Aktor ja/nein? etc.) per FHEM oder manuell (mit Hilfe des vorhandenen Reglers) initiiert werden, ist mir persönlich (noch) nicht wichtig.

Das FHEM EBUS-Modul war/ist eher eine Machbarkeitsstudie/Evaluierung (hier fehlt mir die Möglichkeit, für den ausgewählten get/set Parameter, Werte vorzugeben(Dropdownlist) - aber das nur am Rande.) und keines Falls ein ganzheitlicher Ansatz, wie es dir vor schwebt – es ist max. ein Schritt/Teil von vielen. Ja, ich bin ganz bei dir, das Ändern der Parameter ist damit sehr einfach. Deine Bedenken sind somit nachvollziehbar und berechtigt. Ich sehe FHEM (insbesondere Steuerung der Thermen Betriebsparameter via Ebus) eher als Admin-Werkzeug und gehört, in der aktuellen Fassung, keinesfalls auf ein Tablet im Wohnzimmer.

Mein Schwerpunkt / meine Zielsetzung kurz-/mittelfristig liegt in der Visualisierung (Vorlauf- Rücklauftemp, Heizbetrieb, Betriebsstunden, Pumpe  etc.) und Monitoring (Wasserdruck, Verfügbarkeit, Störungen etc.)

-Monitoring Möglichkeiten gibt es bereits out of the box.
-Visualisierung/Info-Panel (sogar Steuerung wäre denkbar/möglich), spiele ich mit dem Gedanken es via RSS-Modul zu realisieren. Aus diversen Gründen (Anpassungen relativ umständlich/aufwändig etc.) halte ich noch Abstand davon.

Fazit: Es bleibt also spannend...

VG Arthur

[heikoh81]

Hallo zusammen,

nun sind ja schon einige Beiträge seit meinem letzten Post vergangen, aber es ist wieder einiges Interessantes zusammengekommen.

So könnte man (dummerweise) die Gasart ändern, oder die Vorlauftemperatur auf 150 Grad setzen und die Heizung zerstören. Das ist viel zu riskant. Nicht umsonst schützt Vaillant wichtige Einstellungen bei der manuellen Eingabe (nicht auf dem EBUS) durch (na ja) Passwörter. Und von Fragen der Versicherung ganz zu schweigen.

Ist das wirklich so, d.h. könnte ich über ebusd tatsächlich einen Vorlauf von 150°C einstellen?
Das würde mir ganz und gar nicht gefallen. Ich dachte bisher immer, ich bewege mich hier innerhalb hardwareseitiger Grenzwerte, auf die ich keinen Zugriff habe und auch gar nicht haben will!
Selbst bei Fehlbedienung erwarte ich, dass meine Therme nur so heiß wird wie technisch sicher möglich?
D.h. gebe ich 150°C vor, dann macht die Therme halt maximal 75°C?

Nun könnte man ja noch argumentieren, dass auf dem Raspberry ein separates FHEM laufen kann, das mit der Hauptinstanz über FHEM2FHEM kommuniziert. Das ist aber auch nur telnet.
Zusammengefasst also: ebusd auf einem separaten System, und Zugriff darauf mit ein paar kryptischen telnet Kommandos ist (etwas) sicherer, als das direkt in FHEM einzubauen.

Das ist sicher eine zusätzliche Barriere.
Da man in den csv nur wenige Parameter schreibend freigibt, kann auch nichts über die Grenzen hinaus manipuliert werden.
Andererseits: Hat jemand erst Zugriff auf den Heizungs-Raspi, dann kann er auch die csv-Dateien verändern.

Die LED sollte nicht "gerade nicht leuchten" - sondern bei angeschlossenem EBUS ständig flackern, weil die Synchronisationssignale einlaufen.

Was ist nun die optimale Einstellung?
Ich habe meinen so eingestellt, dass die organgene LED ununterbrochen schwach flackert, bisher läuft es reibungslos, aber ca. alle 5-7 Tage muss ich den Raspi rebooten, ebusd läuft noch.
Oder soll ich den Adapter so einstellen, dass die organgene LED nur ab und zu flackert?

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

Nein. Du sollst den Watchdog auf dem Raspberry installieren, der automatisch den ebusd neu startet - und wenn das nicht hilft, den ganzen Raspberry.

Mit Hilfe der "zweiten Diagnosebene" kann man sehr wohl die Betriebsparameter der Therme so verstellen, dass dies gefährlich ist. Und zwar nicht nur für die Hardware, sondern für Menschen.

LG

pah

[heikoh81]

Was ist die zweite Diagnoseebene? Kommt man mit ebusd da überhaupt ran?



Hat es jemand der mitlesenden auf der Calormatic 470/3 geschafft, die DesiredTemp für Warmwasser zu schreiben?

Code Auswählen Erweitern


*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,vrc430,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r;w,,hwDesiredTemp,Manuell Solltemperatur,,,,4400,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
liefert bei mir zwar die richtige Anzeige, aber writes mit einer anderen Temp. werden auf der Calormatic nicht angezeigt.

Code Auswählen Erweitern


#LIEFERT NUR 0.0
#r,,mcDesiredTemp2,Manuell Solltemperatur,,,,8600,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

liefert bei mir nur 0.0, also keinen an meiner Anlage sinnvollen Wert.

Viele Grüße,
Heiko

[Jojo11]

Habe ich noch nicht getestet. Bisher setze ich nur Tages- und Nachttemperatur.
Würde gerne erst einmal die Sache mit dem Einfrieren bei fehlendem ebusd ändern. Sowas kann einem beim Produktivsystem den Spaß verderben 

schöne Grüße
Jo

[heikoh81]

@Jojo:
Das kann ich voll nachvollziehen. Ich war damals auch schockiert, weil mein Master-FHEM mittlerweile extrem viel produktive Aufgaben in meinem Haus macht, auch Alarmfunktionen durch 6 Bewegungsmelder inkl. Email-Versand von Bildern von IPCams - ein Absturz darf da wg. der Heizung nicht passieren.

Boris war damals sehr hilfsbereit und konnte mittels Logging auf höchster Detailstufe das Problem eingrenzen.
Vielleicht kannst du ihn kontaktieren, dass ihr auch so vorgeht wie bei mir damals.

Viele Grüße,
Heiko

[Prof. Dr. Peter Henning]

Ich kann das Problem nicht nachvollziehen.

Bei mir ist das alles abgesichert - gestern habe ich z.B. zufällig einen meiner vier Raspberrys mit derselben IP-Adresse versehen, wie den Heizungs-Raspberry. Resultat ist natürlich, dass der ebusd nicht mehr erreichbar war.

Das merkt sofort ein notify:

Code Auswählen Erweitern

define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:Outside.T.*err) { EBUSrecover("notify EBUS.N",0)}

Damit wird der Recover-Prozess gestartet. Der fragt bis zu 30x in Abständen von 5 Sekunden nach, ob ein Reconnect erfolgreich ist:

Code Auswählen Erweitern


###############################################################################
#
#  EBUSrecover
#
###############################################################################


sub EBUSrecover($$)
{   
   my ($evt,$num) = @_;

   Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
   
   if(Value("EBUS") ne "opened"){
     if( $num < 30){
       $num++;
       fhem("set EBUS reopen");
       fhem("delete EBUSrecoverdly")
          if($defs{"EBUSrecoverdly"});
       fhem("define EBUSrecoverdly at +00:00:05 {EBUSrecover('EBUSrecover',$num)}");
     }else{
       fhem("set Device.warn EBUS")
     }
   }
}


Wenn das nicht geklappt hat, wird also der Dummy Device.warn auf "EBUS" gesetzt.

Dieser Dummy ist als alarmSensor für das Modul Alarm gesetzt und löst Folgendes aus:

• Auf meinem 1-Wire FHEM-Display erscheint die Meldung "EBUS ausgefallen"
• Auf meinem digitalen Bilderrahmen erscheint im Meldungskasten der Text "EBUS ausgefallen"
• Mein HomeMatic MP3-Funkgong sagt laut und vernehmlich mit angenehmer Frauenstimme "Achtung, Systemstörung" und beginnt rot zu blinken.

Sonst passiert gar nichts, schon gar kein Absturz oder Einfrieren von FHEM.

Es könnte also sein, dass Euer Problem gar nicht auf Seiten von FHEM existiert, sondern auf Seiten des ebusd.

Bei mir läuft auf dem Raspberry der Watchdog, mit der folgenden Konfiguration /etc/watchdog.conf

Code Auswählen Erweitern


max-load-1              = 24
test-timeout            = 10
watchdog-device = /dev/watchdog
interval                =5
realtime                = yes
priority                = 1


Im Verzeichnis /etc/watchdog.d steht die Datei ebusd mit dem folgenden Inhalt:

Code Auswählen Erweitern


#!/bin/sh
# description: watchdog helper file for ebusd 

#echo "Called as ebud $1"
case "$1" in
'test')
        #--- Test for ebusd
        if [ -s /var/run/ebusd.pid ] ; then
            RUN=`ps -ef | grep ebusd.*USB0 | grep -v grep`
            if [ "$RUN" != "" ] ; then           
               #echo "ebusd is already running"
               exit 0
            else
               echo "ebusd defunct at "`date`
               exit 1   
            fi
        else
            echo "ebusd not running, return 1 at "`date`
            exit 1   
        fi
        ;;
"repair")
        #-- Restarting ebusd
        echo "ebusd restarting at "`date`
        /etc/init.d/ebusd start
        RETVAL=$?
        #echo "retval from setting permissions is $RETVAL"
        exit 0
        ;;
*)
        exit 0
        ;;
esac


Et voila: alle 5 Sekunden testet der Watchdog, ob ebusd noch läuft und startet ihn ggf. neu. Probleme damit ? Unbekannt. System kann nur durch trotteliges Vorgehen des Hausherrn gestört werden, siehe oben.

LG

pah

[joachimS]

Hi,
danke für das tolle Projekt, speziell an pah!
Ich werde pahs Schaltung löten und auch mit einem raspberry pi arbeiten.
Gibt es noch Änderungen an der Schaltung?

Habe eine Wolf COB Heizung mit BSP Schichtenspeicher, Mischermodul und Solar.
Die 3 Steuerungs Module hatten nicht einmal einen ebus dazwischen, habe ich nachverdrahtet und tut auch.
Weiss jmd. wie lange ein ebus Kabel sein darf? Ich kann das ebus Kabel zum raspberry ja an eine belegte ebus Klemme parallel anschliessen, oder?
Welches Linux empfehlt ihr für den raspberry pi? Solle man die vorinstallierte SD Karte nehmen oder besser runterladen?
Werde den raspberry pi B+ bestellen

Gruss Joachim