Läuft: Heizung mit eBus-Schnittstelle

[stinch]

Ah, jetzt weiß ich was Du meinst.
Das liegt wohl daran, dass Du schon eine WW Instanz hast (0a.pmw). Damit überschneiden sich die Definitionen.
Wenn Du die Datei "25.solsy.hwc.csv" umbenennst nach "25.solsy.2.hwc.csv", dann klappt es.
Damit taucht die zweite WW Instanz dann mit circuit "hwc.2" auf.
Ist das denn eine zweite Warmwasser-Station?

hi,

ok, werde ich heute nachmittag probieren. nein, ich habe nur eine warmwasserstation. meine anlage besteht aus einem Brenner, einer warmwasserstation, einer solarstation, einer vrs620 sowie einem Speicher.

Viele Grüße

[thomhug]

das weiß ich auch nicht, aber wenn man der Spez. glauben schenkt, dann ist das die Bedeutung.

Du hast gesagt ich sei der 4. TEM Benutzer. Hast du evtl. Infos zu den Erkenntnissen der ersten drei? Telegramme entschluesseln ist ja das eine aber wenn es darum geht, RAM Speicheradressen oder nicht dokumentierte Abfragekommandos zu benutzen, wirds sehr schwierig.

Das ist, wenn man den Raumregler so einstellt, dass die Differenz zwischen gemessener Raumtemperatur und Soll-Raumtemperatur die Regelung der Vorlauftemperatur beeinflusst.

Wie es genau funktioniert weiss ich nicht. Gemaess Dokumentation kann der FS die Temperatur messen. Ob diese zur Regelung verwendet wird, ist mir nicht bekannt. So wie es aktuell aussieht, wird die nicht verwendet.

Ja, FF bedeutet NACK, also die Antwort vom adressierten Gerät, dass die CRC falsch ist.
Hier wäre die richtige CRC z.B. "93" (statt EC). Folgerichtig kommt ein NACK.

Hmm. Also ich habe diese C-Programm aus dem Mikrokontroller Forum genommen und damit die CRC ueberprueft. Bei 10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff bekomme ich aber ec als CRC, wie auf dem Bus mitgesnifft. Die 10 90 Telegramme sind auch immer genau gleich mit dem selben CRC. Kann es sein, dass der ebusd die ignoriert wegen dem NACK?

Bei den 10 FE 10 Telegrammen (welche auch im Abstand von ca. 5.5h zusammen mit 10 9X kommen) erkennt ebusd diejenigen mit korrekter CRC und die mit falscher werden ignoriert. Da muessten jeweils 24 kommen und im Extremfall sind 16 mit falscher CRC, manchmal auch nur 4. 10 9X sind aber immer korrekt und die bekannten 07 xx und 08 xx habe ich noch nie falsch gesehen.

Somit hast Du also einigermaßen gravierende Probleme mit Deiner Busleitung, die Du schleunigst beheben solltest. Kann natürlich gut sein, dass der Anschluß des ebus Interfaces das negativ beeinflusst. Wie sind denn deine Leitungslängen?

Ich glaube da ist etwas anderes nicht richtig. Bei einem Problem auf dem Bus wuerde ich ein anderes Fehlerpattern erwarten. Ich koennte aber natuerlich mal probieren an einem anderen Ort anzudocken.
Leitungen mit geschaetzten 2mm Draehten vielleicht 5m zum 90 FS und einen Stock hoeher zum 91 FS vielleicht 10m. Mein ebusd sitzt mit einem 1m Kabel direkt am Regler. Allerdings habe ich nur 0.5mm Querschnitt genommen.
Momentan stoert mich das weniger.

Bin immer noch interessiert, die Heizung zu beeinflussen. Bisher habe ich noch folgendes rausgefunden:
Die 10 FE 10 0A Telegramme (TEM spezifisch) kommen in 8 Varianten vor. Das erkennt man an den ersten zwei Bytes nach der Telegrammlaenge: 10 00, 10 01, 10 02, 10 03, 11 00, 11 01, 11 02, 11 03. Wie ich in Dumps von anderen Reglern gesehen habe, haengt die Anzahl Varianten von den Anzahl Heizkreisen ab. Ich habe zwei Heizkreise und bei den 10 XX Telegrammen bezieht sich 10 00 auf den ersten, 10 01 auf den zweiten, 10 02 wieder auf den ersten Heizkreis, usw. Darin kommen vermutlich einige Einstellungen und u.a. Boilertemp, Vorlauf Soll, Vorlauf Ist, Kesseltemp und ein paar andere vor. Ich habe es aber noch nicht 100% verifiziert.

Ich habe schon mal probiert, die Telegramme von 10 an 90, welche immer mit NACK quittiert werden selber an 90 zu senden. Bei den langen bekomme ich 00 als Bestaetigung und bei den kurzen spannenderweise folgendes:

Code Auswählen Erweitern


$ ebusctl write -h 90100a020004
051004a50001

$ ebusctl write -h 91100a020005
051005be0001


Das habe ich nun schon oft probiert und veraendern tut sich nur das dritte Byte (a5 oder a4, resp be oder  etwas zwischen ba und c2). Das koennten Raumtemperaturen/10 sein. Wenn ich das letzte Byte vertausche, kommt das vertauscht an zweiter Stelle zurueck, bringt also nichts - es kommt also das zurueck was ich eingebe. Am vermuteten Temperaturbyte aendert sich nichts.

Als naechstes muss ich vor Ort Werte verstellen und schauen wie sich die Telegramme veraendern. Ebenfalls bin ich daran RAM und EEPROM auszulesen und zu schauen was sich da veraendert. Allerdings mit bisher maessigem Erfolg...

Wenn alles nicht hilft, bleibt wohl nur noch das Servicetool von TEM zu besorgen (oder auszuleihen - anyone?) und dann auf dem Bus zu schauen was passiert wenn man Werte veraendert...

Freue mich auf Inputs von anderen TEMlern...

[john30]

Du hast gesagt ich sei der 4. TEM Benutzer. Hast du evtl. Infos zu den Erkenntnissen der ersten drei? Telegramme entschluesseln ist ja das eine aber wenn es darum geht, RAM Speicheradressen oder nicht dokumentierte Abfragekommandos zu benutzen, wirds sehr schwierig.

Ein Ergebnis daraus liegt hier (noch auf 2.0 hochgezogen): https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner
Da wird vermutlich in nächster Zeit noch einiges passieren.

Hmm. Also ich habe diese C-Programm aus dem Mikrokontroller Forum genommen und damit die CRC ueberprueft. Bei 10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff bekomme ich aber ec als CRC, wie auf dem Bus mitgesnifft. Die 10 90 Telegramme sind auch immer genau gleich mit dem selben CRC. Kann es sein, dass der ebusd die ignoriert wegen dem NACK?

stimmt, hab mich in der Zeile vertan. ec ist richtig. dann weiß ich auch nicht, warum der Adressat mit NACK antwortet.
Diese Nachrichten werden von ebusd in der Tat verworfen.

Bei den 10 FE 10 Telegrammen (welche auch im Abstand von ca. 5.5h zusammen mit 10 9X kommen) erkennt ebusd diejenigen mit korrekter CRC und die mit falscher werden ignoriert. Da muessten jeweils 24 kommen und im Extremfall sind 16 mit falscher CRC, manchmal auch nur 4. 10 9X sind aber immer korrekt und die bekannten 07 xx und 08 xx habe ich noch nie falsch gesehen.

Das ist aber schon eine ganz schön hohe Fehlerquote. Dass als NACK auch öfter mal "fe" da steht ist auch merkwürdig. Ist eigentlich nicht erlaubt...

[Schorsch]

ich habe von Vaillant ein EcoPower 1.0 Mikro BHKW...  Systemregler 1.0. ... eBus ... CAN Bus.

Kann man generell einen Systemregler via eBus abfragen und bekommt man alle Informationen ausgelesen...?

...Daten wie Aussentemperatur, sowie Speichertemperatur auslesen möchte. Aber genau diese Fühler sind direkt auf dem Systemregler aufgelegt. ... Kann es somit sein, dass ich diese Daten nicht über den eBus aus dem Regler abfragen kann?

...aber ich würde den steinigen Weg gehen wenn es Erfolg versprechend ist.

weiß nicht ob das hilft oder überhaupt noch gelesen wird, falls aber: ich habe seit 2012 ebenfalls ein ecoPower 1.0 in Betrieb. Damals gab es die eBus-Anbindung noch nicht. Habe das daher damals etwas anders gelöst (s.u.) und so läuft das heute noch. Ich bezweifle, dass eBus bei der Anlage zum Erfolg führt, denn die Anbindung nach außen macht der Systemregler über diese unsichere Java-Applikation, die munter die Passworte rausposaunt. Damit hat es Vaillant seinerzeit ja in die c't geschafft. Vorteil der Java-Anwendung ist, dass man darüber mit dem richtigen Passwort auch Daten über die Gemischaufbereitung, Motortemperaturen, Nadelventilposition und ähnliche Dinge bekommt, die man zwar nicht täglich braucht aber die manchmal helfen. So hab ich z.B. festgestellt, dass der Installateur mein BHKW auf die falsche Gassorte (E-Gas) eingestellt hat, obwohl wir hier LL-Gas haben.

Diese Werte gehen nicht über eBus - und die von Dir gewünschten Werte Außentemperatur und Speichertemperatur kannst Du anders u.U.  einfacher erfassen, nämlich über dedizierte Temperaturfühler. So mache ich das seit 2012, nur mal als Beispiel:

• Außentemperatur bespreche ich nicht weiter, hat jeder irgendwo her
• Puffertemperaturen unten/mitte/oben: In 3 Fühlerröhren stecken PTC-Sensoren, mein Puffer (800L, 2m hoch) hat weitere leere Röhren, dort habe ich 1-wire Temperaturfühler platziert. Würden notfalls auch noch mit in die Originalröhren passen, falls es keine Extraröhren gibt
• Ich habe damals weitere 1-wire-Sensoren verbaut am BHKW-Vor-/Rücklauf etc., nach persönlichem Belieben
• Eine Sache muss ich auch fernsteuern, weil ich sie nicht parametrisieren konnte: Wenn die Hausbatterie voll ist, soll das BHKW abschalten, weil ich den Strom nicht einspeisen möchte. Bei 85% SOC darf es wieder einschalten, wenn Wärmebedarf vorliegt. Realisiert über einen potentialfreien 1-wire-Schalter und einen Widerstand, der geschaltet der Anlage 76°C Puffertemperatur unten signalisiert. Bei 75°C unten geht das BHKW nämlich von einem geladenen Wärmespeicher aus und schaltet ab. Die Heizung/Warmwasser etc. bleiben unbeeinträchtigt, die achten nur auf die Puffertemperaturen mitte / oben. Wenn die Batterie wieder aufnahmefähig ist, bekommt der Regler die echte Puffertemperatur unten zurück. Noch ein Grund, weshalb mein eigener Temperatursensor am Puffer hilfreich ist
• Mit der Steuerung passe ich den häuslichen Strommix auch an, wenn z.B. die PV absehbar längerfristig viel liefert (bekomme Direktverbrauch für Haus oder zum Laden des Autos noch gut vergütet und treibe ihn an, überschüssige PV geht bei mir aber nicht in die Hausbatterie, sondern wegen der Speicherkosten ins Netz) - SMA und Vaillant sprechen sonst auch völlig verschiedene Sprachen leider.
• Den Spitzenlastkessel (und nur den) lasse ich über einen anderen 1-wire Schalter an S.31 auf Sommerbetrieb, solange nicht Räume über zu weit geöffnete Ventile signalisieren, dass die vom BHKW bereitgestellte Wärme deutlich nicht reicht.

Lieber wäre mir natürlich auch eine elegantere Steuerungsmöglichkeit z.B. über eBus. Bei der Anlage müsste man für ein einigermaßen vollständiges Bild aber über die LAN-Schnittstelle und diese dusselige Java-Applikation gehen. Dafür reichen meine Kenntnisse nicht. Läuft aber auch so seit 2012 zuverlässig für das, was ich täglich brauche. Und die sonstigen Daten lese/steuere ich halt im Bedarfsfall über mein VPN per Browser. Der Systemregler sendet mir auch eine Mail, wenn es ein Zipperlein hat.

[Prof. Dr. Peter Henning]

Die genannten Daten gehen mit hoher Wahrscheinlichkeit als broadcast über den eBus.

LG

pah

[thomhug]

Ein Ergebnis daraus liegt hier (noch auf 2.0 hochgezogen): https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner
Da wird vermutlich in nächster Zeit noch einiges passieren.

Mit diesen Ochsner Daten kann ich nichts anfangen. Ich scheine da einen anderen Regler zu haben. Ich habe einen "TEM IT 5710 MX - 1 CTC". Baujahr 2000 

Das ist aber schon eine ganz schön hohe Fehlerquote. Dass als NACK auch öfter mal "fe" da steht ist auch merkwürdig. Ist eigentlich nicht erlaubt...

Irgendwas scheint nicht so zu funktionieren wie es soll. Gehe dem noch auf den Grund.

[Schorsch]

Die genannten Daten gehen mit hoher Wahrscheinlichkeit als broadcast über den eBus.

Habe daraufhin mal weiter gesucht in der Tat kann ein anderer Betreiber des Systems diese Daten über den eBus Broadcast lesen. Er kann allerdings den Motor nicht steuern, was nahe liegt (CAN-Bus). Wem also die Heizungsseite reicht, der sollte ruhig die Anbindung über eBus auch beim EcoPower versuchen.

[thomhug]

Mit diesen Ochsner Daten kann ich nichts anfangen. Ich scheine da einen anderen Regler zu haben. Ich habe einen "TEM IT 5710 MX - 1 CTC". Baujahr 2000 

Irgendwas scheint nicht so zu funktionieren wie es soll. Gehe dem noch auf den Grund.

So, ich habe jetzt zwischen 0xf000 und 0xffff im EEPROM und im RAM so ziemlich viele Werte gefunden! Sehr spannend. Ich hoffe jetzt mal die RAM Adressen sind statisch und die aendern sich nicht wenn man die Heizung "neu bootet" Wobei RAM waere nicht so schlimm wie EEPROM, da dort die Settings sind.

Nun ist mir nicht klar, warum die Werte immer mehrfach vorkommen. Im EEPROM ist alles doppelt (z.B. 2 Heizkreise, 2 Sollwerte = 4 Eintraege). Im RAM ist es dann noch schlimmer, die Kesseltemperatur kommt da doch sage und schreibe 7x vor!! Ich habe alle Eintraege verfolgt, die werden brav alle aktualisiert.

Wenn jetzt eine Solltemperatur nur 1x vorgekommen waere im EEPROM, dann haette ich die mal ueberschreiben und geschaut was passiert. Bei doppelten Werten bin ich aber unsicher. Ich will da nicht noch eine Racecondition produzieren auf der Heizung Wie sind da eure Erfahrungen?

[thomhug]

Nun ist mir nicht klar, warum die Werte immer mehrfach vorkommen. Im EEPROM ist alles doppelt (z.B. 2 Heizkreise, 2 Sollwerte = 4 Eintraege). Im RAM ist es dann noch schlimmer, die Kesseltemperatur kommt da doch sage und schreibe 7x vor!! Ich habe alle Eintraege verfolgt, die werden brav alle aktualisiert.

Wenn jetzt eine Solltemperatur nur 1x vorgekommen waere im EEPROM, dann haette ich die mal ueberschreiben und geschaut was passiert. Bei doppelten Werten bin ich aber unsicher. Ich will da nicht noch eine Racecondition produzieren auf der Heizung Wie sind da eure Erfahrungen?

Also, das Mysterium ist geloest: Anscheinend gibt es nur 2kB EEPROM, d.h. 0xf000 ist das gleiche wie 0xe000 und sogar gleich 0xf800. So habe ich mal probiert, einen Wert zu setzen und es hat geklappt!!! Raumtemperatur im EEPROM geaendert: Wert im RAM hat sich geaendert und die Solltemperatur vom Heizkreis hat sich auch geaendert! JUHEEE!
Wo sich der Heizungsstatus versteckt, habe ich noch nicht rausbekommen ohne vor Ort zu gehen. Dafuer kann man mit EEPROM write etwas mehr riskieren, da man nicht gleich erfriert wenn die Heizung crasht 

Code Auswählen Erweitern


# Raumsolltemperatur Heizkreis rot: (UIN/10 d2 00 = 21.00 Grad)
$ eeprom-read.sh 70f3
02d200
21.00

# Solltemperatur Heizkreis rot
$ ram-read.sh 2af6
02a601
42.20

# Register 70f3 (also 0xf370) mit (96 00) ueberschreiben (UIN/10 = 15.00)
$ ebusctl write -h 1509030470f39600
00

# Schreibvorgang hat geklappt
$ eeprom-read.sh 70f3
029600
15.00

# Der Regler hats auch gemerkt, Solltemperatur ist sofort tiefer
$ ram-read.sh 2af6
022901
29.70


ram-read.sh und eeprom-read.sh machen nichts anderes als ebusctl write -h 15090003${1}02 und mir den UIN/10 Wert berechnen.

[Gerhard]

Hallo John,

auf dem Cubietruck habe ich den ebusd V1.2 und jetzt möchte ich die version V1.3 instalieren.
Muss ich vorher V1.2 deinstalieren?, wenn ja, wie? oder vird V1.2 von V1.3 ersetzt?

Danke, Gerhard

[john30]

auf dem Cubietruck habe ich den ebusd V1.2 und jetzt möchte ich die version V1.3 instalieren.
Muss ich vorher V1.2 deinstalieren?, wenn ja, wie? oder vird V1.2 von V1.3 ersetzt?

Cubietruck kenn ich jetzt nicht. Wenn Du das Debian Package genommen hast, dann einfach dpkg -i mit neuem Paket ausführen.

[Stütti]

Über 960 Symbole/Sekunde klingt nach einem Zeitproblem. Läuft da ein NTP drauf?
Um die 2.0 Version als Fehlerquelle auszuschließen kannst ja einfach mal eine ältere aus den https://github.com/john30/ebusd/releases probieren.

Kurze Rückmeldung - hat etwas länger gedauert:
Habe den Raspberry Pi aktualisiert und bin jetzt wieder auf ebusd 1.3.0 - keine Veränderung, es gibt weiterhin die "signal lost"-Meldungen, zu viele Symbole/Sekunde und kein brauchbares Log.
Um mal eine Alternative auszuprobieren, habe ich Ubuntu auf einem Laptop installiert - damit läuft alles und ebusd liefert ein ordentliches Log, es werden 3 Master erkannt und Abfragen funktionieren. Somit weiß ich schon mal, dass der Koppler läuft.

Jetzt frage ich mich nur, was ich am Raspberry ändern muss, damit es auch darauf sauber läuft. Bei anderen läuft das ja auch!?
- Betriebssystem ist derzeit Raspian. Wechseln? Arch Linux?
- NTP läuft darauf per default.
- Kann es ggf. an der Spannungsversorgung des ebus-Kopplers (eservice) liegen? Der hängt derzeit direkt am USB des Raspberry Pi 2.

[Reinhart]

@beni.s

also ich betreibe den eBus schon über einem Jahr auf dem Raspi mit Debian, Fhem 5.7 und eBus 1.2 (werde aber demnächst auf 1.3 wechseln) ohne Probleme.

Ich habe aber auch schon in anderen Foren gelesen, dass einige User Probleme mit den Netzgeräten des Raspi haben, speziell bei dir wenn hier noch die Stromversorgung des eBus Kopplers drauf hängt. Wenn es dir möglich ist, dann versuceh doch einfach ein anderes Netzgerät bevor du großartig umstellst. Ich verwende am Raspi nur Netzteile mit mindestens 2 A, doch es ist auch bei diesen Angaben nicht gesagt ob das auch wirklich stimmt.

LG
Reinhart

[Stütti]

@Reinhart

Danke für die Antwort.
Okay, werde es mal mit einem anderen Netzteil ausprobieren. Verwende zwar extra für diese Anwendung eins mit 2,1A, aber vielleicht stimmen wirklich einfach die Angaben nicht.

Gruß
Benjamin

[cs-online]

Hallo zusammen,

hat evtl. schon einer die Adresse für D.29 herausgefunden ? Das ist der Volumenstrom, der tatsächlich grad im Umlauf ist. Ich würde den gerne nutzen um die tatsächlich abgegebene Leistung berechnen zu können.... Alle Versuche (auch mit Johns Hilfe) sind bislang leider nicht erfolgreich gewesen...

Hat's schon jemand raus ?

Grüße

Christian