Läuft: Heizung mit eBus-Schnittstelle

[sven.anacker.5]

...im Ruhezustand habe ich 2,4 bar auf der Anzeige und "hex 06b509030dd10" bringt 021800, also 32? Oder sind die 18 hex und damit 24?

Mit meiner "hex 06b509030d6f00" Umrechnung war ich wohl voll auf dem Holzweg...

[Sven77]

Das erste Byte einer Hex-Antwort ist immer die Länge der Antwort, gehört also nicht zu den Nutzdaten.

Füge mal in /etc/ebusd/vaillant/_templates.csv diese zwei Zeilen ein:

Code Auswählen Erweitern

press2,UCH,10,bar,Druck
presssensor2,press2;sensor,,,

Und in der /etc/ebusd/vaillant/06.pms.csv diese Zeile:

Code Auswählen Erweitern

r,,SolarPressure,Druck Solarkreis,,,,"D100",,,presssensor2,,,Druck im Solarkreis,,,

[sven.anacker.5]

Es läuft!

Und stimmt auch mit dem aktuellen Druck (2.0 bar) überein. Ich melde mich wenn es Auffälligkeiten gibt, betrachte das "Problem" aber aktuell als gelöst.

Vielen Dank Herr Namensvetter!

P.S. geht unsere Erkenntnis nun eigentlich automatisch in die Quellen auf Github ein?

[Prof. Dr. Peter Henning]

Nur mal so als Kommentar von mir - habe sozusagen über Monate nicht mehr hineingeschaut: Ich bin beeindruckt, was Ihr bisher in Hardware und Software aus dem Projekt gemacht habt.

Nachdem ich zwischendurch mal die gestorbene Zenerdiode ausgetauscht habe, werkelt bei mir übrigens immer noch die allererste Lochrasterversion der Schaltung vor sich hin.

LG

pah

[cs-online]

@ John: Ich hatte mal irgendwo gelesen, dass es die Möglichkeit gibt, EBUSD regelmäßig bestimmte / alle Werte abfragen zu lassen ohne das aus FHEM heraus aktiv abzufragen, nur finde ich das nicht mehr wieder. Daher meine Frage: Wo kann ich das wohl finden und welche Mindestanforderung (ich habe aktuell die EBUSD 3.0 installiert) brauche ich dafür ?

Hintergrund ist, daß ich regelmäßig dann einen ca. 6s langen Freeze habe, wenn ich die Werte neu abfragen lasse und ich das gerne reduzieren würde...

Grüße

Christian

[istler]

Hallo Christian,

suchst du das hier:
https://github.com/john30/ebusd/wiki/4.1.-Message-definition

Du kannst dies in den CSV Dateien der Konfiguration einstellen.

Gruß
Maik


Gesendet von meinem Aquaris_A4.5 mit Tapatalk

[cs-online]

Hallo Maik,

wenn ich das richtig verstehe, dann muss ich also bei dem Wert, der mit regelmäßig abgefragt werden soll, eine z.B. 1 hinter das r in die CSV eintragen oder ? Dann würden alle, bei denen eine 1 dahinter ist, bei jedem Zyklus (wie lang ist das denn zwischen den Abfragen ?) automatisch aktualisiert, richtig ?

[istler]

Hallo Christian,

ja richtig. Und das Poll-Intervall kannst du beim starten des Dämons angeben:
https://github.com/john30/ebusd/wiki/2.-Run

Gruß
Maik

[john30]

wenn ich das richtig verstehe, dann muss ich also bei dem Wert, der mit regelmäßig abgefragt werden soll, eine z.B. 1 hinter das r in die CSV eintragen oder ? Dann würden alle, bei denen eine 1 dahinter ist, bei jedem Zyklus (wie lang ist das denn zwischen den Abfragen ?) automatisch aktualisiert, richtig ?

genau, istler hats ja schon beantwortet.
Anstelle die CSVs zu ändern, kannst Du auch einfach bei einem read Kommando direkt die poll prio verändern. Das ist aber nach einem ebusd Neustart wieder weg.

[cs-online]

Also einmal alle Werte, die ich haben möchte statt mit "r -f" dann "r1 -f" abfragen und dann mittels "find" immer alle aktuellen Werte über einen Timer in FHEM abfragen ? In welchem Intervall werden die denn akrualisiert ?

[istler]

Hallo Christian,

Das wird bei den Start-Parametern des Daemon (ebusd) festgelegt:
https://github.com/john30/ebusd/wiki/2.-Run

Code Auswählen Erweitern

--pollinterval=SEC
Poll for data every SEC seconds (0=disable) [5]

Gruß
Maik

[borg]

Hallo zusammen, ich hänge mich auch noch an den Riesen-Thread.

nach über 10 Jahren Bedenkzeit habe ich einen eBus-Adapter und ebusd auf einem Raspberry Pi mit meiner TEM-Controller-Wärmepumpenheizung verbunden. Mich interessieren Temperaturverläufe, abgegebene Wärmemenge etc. und vielleicht ein etwas tieferes Verständnis der Anlage. Aus Zerstörungsangst habe ich nur die lesende Hälfte des Interface bestückt und kann also nicht scannen oder aktiv Werte auslesen. Ich hatte gedacht, mir reichen die abgehörten Daten, die zwischen Controller und Bedienteil ausgetauscht werden.

In der Tat sehe ich sofort einige Standard-ebus-Nachrichten und einige unbekannte Nachrichten. Für die Standard-Nachrichten habe ich eigene Signaldefinitionen gemacht, in die ich die beobachteten Geräteadressen eingetragen habe (habe keine Standard-Messagenamen gefunden und mir selbst welche ausgedacht, vgl. angehängtes Log). Leider verstehe ich schon gar nicht, welches ebus-Device welches reale Gerät ist. Nach dem Neustart der Anlage melden sich folgende Adressen:

address 03: master #11
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=TEM;ID=17385;SW=0106;HW=0100"
address 90: slave
address 91: slave

Dabei sendet 10 die "Regler"-Signale ("Room Controller" in der englischen Version), 03 und 13 sind Feuerungsautomaten ("Burner Control Unit"), 90 und 91 sind auch Feuerungsautomaten. Letztere Adressen werden für Betriebstunden- und Anlaufzähler-Abfragen benutzt. Adresse 15 sagt nach der Initialisierungsmeldung nichts mehr.

Meine Heizungsanlage enthält zwei Wärmepumpen (Abluft und Erdwärme) sowie zwei unabhängige Bedienteile (angeblich mit je einem "Heizkreis" verbunden). Wenn ich an einem Bedienteil die Uhrzeit verstelle, überträgt der regelmäßige Broadcast von Adresse 10 nach einigen Sekunden die neue Uhrzeit, welche erst dann vom anderen Bedienteil angezeigt wird. Ich finde aber keinen Hinweis, wie  Adresse 10 an die geänderte Uhrzeit kommt. Genauso verhält es sich bei der Soll-Brauchwassertemperatur.

Meine Fragen an die Experten

• Können sich hinter 2 der gefundenen Adressen die Bedienteile verstecken?
• Kann es sein, dass ich ordentliche Standard-Ebus-Nachrichten sehe, aber einzelne Busteilnehmer (Bedienteile?) systematisch nicht bemerke? Der TEM-Controller hat nur einen ebus-Anschluss, an welchen beide Bedienteile und der Ebus-Adapter angeschlossen sind.
• Erkennt jemand ein Muster in den unbekannten Nicht-Standard-Nachrichten 100a (vgl. Anhang)? Ich habe z.B. nirgendwo eine Temperatur erraten können. Die john30-Howtos zum Thema kenne ich.
• Ist es vielleicht doch eine schlechte Idee, ein read-only Interface zu benutzen? Da geht offenbar nicht alles, wie Scan oder Conditions.

Danke für die Geduld und viele Grüße
Christoph "borg"

[cs-online]

Hallo Christian,

Das wird bei den Start-Parametern des Daemon (ebusd) festgelegt:
https://github.com/john30/ebusd/wiki/2.-Run

Code Auswählen Erweitern

--pollinterval=SEC
Poll for data every SEC seconds (0=disable) [5]

Gruß
Maik

Hallo Maik,

das ist ja super, genau nach sowas habe ich gesucht !!!

Danke

Grüße

Christian

[rellla]

Hallo borg,

ich habe auch eine TEM Steuerung (mit Bartl WP).
Mit den Master-Master und Broadcast-Telegrammen habe ich mich leider noch nicht beschäftigt, kann dir also mit deinen Logs nur bedingt weiterhelfen.

Falls du aber verschiedene Werte lesen willst, kannst du die Master-Fernbedienung dafür "mißbrauchen". Dafür darf Ebusd aber nicht im read-only Modus gestartet werden, wenn ich mich recht erinnere.

Ich bin folgendermaßen vorgegangen:
- Ebusd in Grab Modus setzen
- Menüs auf der Master-FB auswählen und durchscrollen, damit die Werte angezeigt werden.
- In den Grabs solltest du nun Master-Slave Telegramme erhalten, die von der Master-FB getriggert werden
- Diese sind relativ einfach zu identifizieren, da der TEM-Code mit gesendet wird (Antwortbytes 1 + 2) und du die HEX-Werte mit den angezeigten Werten im Display vergleichen kannst.

Somit sollte es möglich sein, alle Werte per Ebusd abzufragen, die du auch mit der Fernbedienung abfragen kannst.

Eine relativ komplette csv (für meine Bartl) findest du hier: https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/TEM/bartl.csv

Hier: http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_7_v1_6_1_anhang_ausgabe_1.pdf gibts eine Übersicht über die Master/Slave Adressen. 15 ist die Slave Adresse des Reglers, 01 dürfte dann die Masteradresse einer deiner Fernbedienungen sein, wenn du die Abfragen triggerst. 90/91 sind Slave Adressen der Raumgeräte/Fernsteller - was auch immer das ist

Hinter deinen 1090 Nachrichten mit den vielen "Doppelbits" 03,0C und FF und der Durchnummerierung 30-37 vermute ich Zeitprogramme, die der Regler an das "Raumgerät" sendet. Hier gibt es mehrere verschiedene, z.b. 04, 05, 06 also z.B. 3004 und 3005, 3104 usw.
Wie der bytetream so eines Zeitprogramms aussieht, kannst du hier sehen: https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/TEM/bartl.csv#L103 Diese Nachrichten werden aneinandergehängt.

Vielleicht hilft dir das ja erstmal weiter.

Gruß
Andreas

PS: Ich fand diesen Online-Konverter hier http://manderc.com/concepts/umrechner/index.php sehr hilfreich. Ich habe mir das selbst auch etwas angepasst. Damit kannst du relativ schnell deine HEX Codes (1- und 2-Byte-weise) in Dezimal und einzelne Bits umwandeln, was die Entschlüsselung einfacher macht. Gerade bei den Zeitprogrammen brauchst du die einzelnen Bits... Darauf achten, dass die Datenbytes immer als einzelnes oder doppeltes Byte zu betrachten sind. Bei 2-Byte Werten ist allerdings die Endianess zu beachten, d.h. das kleinstwertigere Byte sitzt am Anfang. Aus 3004 muss dann 0430 werden, damit das Ergebnis richtig ist. Nur für den Fall, dass ich dir was neues erzählen konnte

[Sven77]

Aus Zerstörungsangst habe ich nur die lesende Hälfte des Interface bestückt und kann also nicht scannen oder aktiv Werte auslesen. Ich hatte gedacht, mir reichen die abgehörten Daten, die zwischen Controller und Bedienteil ausgetauscht werden.

Ergänzend eine Erkenntnis, die mir kürzlich aufgefallen ist:

Der --readonly Switch verträgt sich nicht mit --scanconfig, da zumindest in meinem Fall kein externer Busteilnehmer die erforderdlichen Scans gestartet hat, die notwendig wären um die korrekten CSVs zu ermitteln.
Wenn also schon der Hardware-Sendeteil fehlt, sollte Ebusd mit --readonly gestartet werden um zu wissen, dass es nicht senden kann und eben ohne --scanconfig, wobei dann nur noch die passenden (bzw. keine gegenseitig kollidierenden CSVs) im Konfigurationsverzeichnis liegen dürfen.