Läuft: Heizung mit eBus-Schnittstelle

[zentis666]

Geht relativ schnell, hatte das Ding in weniger als ner halben Stunde zusammengebraten (man siehts an den Fotos  )
Die Schaltung läuft auch prinzipiell an meiner Heizung.
Hab bloß noch Probleme bei der Einstellung des Potis, der Bereich in dem sinnvolle Daten kommen ist sehr klein.
Ich bekomme zwar Daten aber nach ein paar Sekunden ist immer das Bus-Signal weg. Hab schon über eine Stunde am Poti rumgestellt,
ich bekomme es nicht besser hin. Ich poste nachher noch ein logfile.

[Reinhart]

@zentis666

wenn ich mir die Fotos anschaue, dann habe ich den Eindruck du hast die Bauteile an der Rückseite der Platine nicht verlötet.
Wäre dies der Fall, dann wird je nach Art der Durchkontaktierung die Schaltung nicht besonders stabil arbeiten, CMos Bauteile haben sehr hochohmige Eingänge und neigen leicht zum schwingen wenn die Verlötung nicht zu 100% passt.

Schau dir das bitte noch einmal an, kann aber sein, dass das Foto mich etwas täuscht.

LG

[cs-online]

@Texel: Ich weiß nicht, ob das hilft, aber ich habe festgestellt, daß manchmal nach dem Setzen eines Parameters beim Auslesen noch der alte Wert drin steht. Hier hilft ein "reload", dann zieht EBUSD die aktualisierten Werte... Also erst Wert schreiben, dann reload, dann Wert auslesen

[zentis666]

@zentis666

wenn ich mir die Fotos anschaue, dann habe ich den Eindruck du hast die Bauteile an der Rückseite der Platine nicht verlötet.

Danke für den Tip, ich hatte tatsächlich nur von einer Seite gelötet. Habe nochmal auf der oberen Seite nachgelötet,
ist aber noch das gleiche Verhalten.

Gruß
Sven


Gesendet von iPhone mit Tapatalk

[zentis666]

Problem gelöst: bei meinem Raspi war ein 2A Samsung USB Netzteil, hab es ausgetauscht und nun ist der Bus stabil.


Gesendet von iPhone mit Tapatalk

[Reinhart]

Das ist super, wenn es bei dir nun funktioniert!

Das mit den Netzteilen ist ein allgemeines Problem, auch wenn 2A drauf steht hat man keine Garantie das der Strom auch geliefert wird. Hier kann man eigentlich nur probieren.

LG

[Jojo11]

Beim Raspi scheint das Problem nicht die maximale Stromstärke zu sein, sondern die Stabilität der Versorgungsspannung. Dazu gibt es hier zahlreiche Beiträge.

schöne Grüße
Jo

[john30]

@Texel: Ich weiß nicht, ob das hilft, aber ich habe festgestellt, daß manchmal nach dem Setzen eines Parameters beim Auslesen noch der alte Wert drin steht. Hier hilft ein "reload", dann zieht EBUSD die aktualisierten Werte... Also erst Wert schreiben, dann reload, dann Wert auslesen

Reload ist etwas heftig, ein einfaches "read -f ..." tuts auch, damit wird der cache umgangen.

[amunra]

Hallo Sven,

die Teile sind heute angekommen, Danke.
Jetzt nur noch Zeit finden...

Viele Grüße
Arthur

[cs-online]

@John: Danke für den Hinweis !!! Das kannte ich noch nicht, werd ich mal ausprobieren.

[zentis666]

Hallo Sammelbesteller,
Noch ein Hinweis, hatte  ich zwar schon weiter oben geschrieben aber lieber nochmal: der U4 (78L05) muss 180 Grad gedreht zum Druck eingelötet werden, sonst sind in und out vertauscht.

Gruß
Sven

Gesendet von iPhone mit Tapatalk

[primi]

Hallo, ich habe auch den Ebusd mit FHEM auf einem Raspberry Pi2 ModelB bereits am laufen. Derzeit kann ich noch keine Probleme erkennen, obwohl EbusD und FHEM auf ein und dem selben Raspberry läuft. Allerdings fange ich mit FHEM erst an. Ist also sonst fast leer. Ich kann aber bereits mehere Daten meiner Vaillant Wärmepumpe VWS63-3 auslesen und im Diagramm darstellen. Also erstmal ganz herzlichen Dank an all die Softwareentwickler.

Zuerst möchte ich eine Übersicht über alle möglichen Ebusd-Befehle (sowie den Antworten dazu) bekommen. Anschließend kann ich dann die Befehle die ich nicht über FHEM ausführen möchte herausnehmen (wegen Sicherheitsbedenken die hier schon aufkamen).

Dazu habe ich mir vom Ebusd mit Option dumpconfig eine Liste generiert. Diese Liste wird nun in einem Perl-Programm nach Namen Sortiert und die entsprechende config-Datei ebus.cfg generiert. Außerdem wird ein Timer mit allen Befehlen geladen. So der Plan der schon fast fertig ist und teilweise bereits läuft.

Im Moment habe ich noch eine Frage zu den Befehlen aus der CSV-Datei ehp_brinetowater.csv.
Hier gibt es z.B. zu dem Befehl "SourceTempInput" eine "u" und eine "r" Variante. Dazu folgende Fragen:

-Das "r" steht wohl für "read". Wofür steht das "u"?

-Beide Befehle kann ich über telnet und den Ebusd an die Wärmepumpe absetzen. Allerdings nur wenn ich dem Ebusd mit read -h .... (send hex message) anspreche. Jedoch bekomme ich dann auch die Antwort in schwer lesbarem Hex-Format. Da beide Befehle ja den gleichen Befehlsnamen und die gleide Zieladresse haben, kann ich den Befehl nicht in Form von "read SourceTempInput" absetzen. Zumindest würde der Befehl immer nur einen von den Beiden definierten Varianten ausführen können.  Als Lösung fällt mir nur ein die CSV-Datei entsprechend umzubauen, dass die beiden Befehle einen unterschiedlichen Namen bekommen...!? Gibt es hier nicht einen Besseren Weg? Sollte das so sein?
-->nachtrag... habe jetzt in der csv die Einträge für r,ehp... in r,ehp1 und u,ehp in u,ehp2 geändert... sollte also damit recht einfach behoben sein...

-Wäre es nicht sinnvoll die expect und postproc-Ausdrücke mit in die csv-Datei zu packen?

Gruß primi

[john30]

-Das "r" steht wohl für "read". Wofür steht das "u"?

"u" steht für "upate" und macht die Nachricht zu einem passiven read, womit ebusd die Nachricht nur mitlauscht, aber nicht mehr selbst aktiv abfragen kann. Zudem wird über dieses Typzeichen auf eine andere defaults-Zeile umgeschwenkt (Zeile 4 der ehp_brinetowater.csv statt Zeile 3), so dass aus ff08b509030d0f00... dann ff08b50903290f00|XXXX... wird (zwei bytes in der Slave-Antwort ignorieren).

-Beide Befehle kann ich über telnet und den Ebusd an die Wärmepumpe absetzen. Allerdings nur wenn ich dem Ebusd mit read -h .... (send hex message) anspreche. Jedoch bekomme ich dann auch die Antwort in schwer lesbarem Hex-Format. Da beide Befehle ja den gleichen Befehlsnamen und die gleide Zieladresse haben, kann ich den Befehl nicht in Form von "read SourceTempInput" absetzen. Zumindest würde der Befehl immer nur einen von den Beiden definierten Varianten ausführen können.  Als Lösung fällt mir nur ein die CSV-Datei entsprechend umzubauen, dass die beiden Befehle einen unterschiedlichen Namen bekommen...!? Gibt es hier nicht einen Besseren Weg? Sollte das so sein?

Ja das soll genau so sein, da die "29" Nachricht nur aktiv vom Controller an die WP gesendet wird und es wenig Sinn macht, das vom ebusd in der Form auch zu tun.

-->nachtrag... habe jetzt in der csv die Einträge für r,ehp... in r,ehp1 und u,ehp in u,ehp2 geändert... sollte also damit recht einfach behoben sein...

Das ist Quatsch, lies einfach ehp SourceTempInput. Wenn dir Daten aus dem Cache vom Alter her genügen, wird das neuere von beiden genommen. Andernfalls (mit "read -f") wird sowieso die "r" Nachricht verschickt und ausgewertet.

-Wäre es nicht sinnvoll die expect und postproc-Ausdrücke mit in die csv-Datei zu packen?

Das wär ziemlich sinnlos. Vernünftiger wäre es, ein eigenes FHEM Plugin für ebusd zu schreiben. Dafür fehlts mir aber an Zeit, Energie und Perl-Knowhow.

[distel]

Ich mach die Sendungen am WE fertig und schick sie am Montag raus

Heute angekommen - und dabei sind die noch gar nicht durch mit dem Streik - für ne Warensendung schon fast reguläre Laufzeit...

Danke Sven!

Jetzt nur noch das Löteisen aufheizen... aber es ist eh so warm :-/

[zentis666]

Gern geschehen, viel Spass beim Basteln.
Gruss
Sven