Peter T. schrieb im Beitrag #4370613:
> Sorry, muss leider ueber das Forum kommunizieren wg. e-mail Problemen
2. Mail auf GMX und übers Forum noch eine.....
Mehr kann ich nicht machen, such Dir 'ne neue Mailadr, wenn es auch
nicht übers Forum hier nicht geht....
...hatte das gleiche Problem mit AOL ! Mit T-online ging es dann...
Die Platinen von Helmut sind TOP !!! Und auch schnell mit der Post
gekommen, Danke dafür nochmal
Grüsse Christian
Moin zusammen,
ich habe jetzt zwei EBUS Adapter aufgebaut. Bevor ich diese an die
Vaillant anschließe, würde ich diese gerne auf Funktionsfähigkeit
testen. Gibt es da eine einfache Möglichkeit?
Ich hatte mir das sonst so vorgestellt, dass ich die EBUS Adapter an
jeweils einen PC anschließe und ebusd starte. Dann müssten sich die
Adapter ja erreichen können. Ich gehe mal davon aus, dass ich eine
Busspannung benötige, oder? Kann ich diese irgendwie selber zur
Verfügung stellen oder ist die in diesem Szenario überflüssig?
Danke und Gruß.
Christian
Also soweit ich das Thema inzwischen verstanden habe:
Ja, der eBus braucht eine Spannungsquelle - bei mir kommt die vom
Brenner und kann dort an/ausgeschaltet werden. Ich weiß gar nicht genau,
ob die anderen (stromversorgten) Geräte sich auch ohne den Brenner
unterhalten könnten, meine Steuerung geht definitiv nur, wenn der
Brenner eingeschaltet ist.
Da der ganze Bus aber (auch) für Heinzungs-Monteure ausgelegt ist, war
ich mutig und hab's einfach direkt draufgeklemmt. Anfangs sogar falsch
herum, weil die Platine entgegen aller Vaillant-Komponenten polrichtig
an +/- geklemmt werden muss. Sieht man aber schnell an der grünen LED.
Und wenn Du mit der eBus-Seite anfängst und USB (noch) nicht anschließt,
sollte ja eigentlich auch nicht viel passieren können?!
Ansonsten müsste man das mit 2 Adaptern mal probieren, geht bekanntlich
über studieren! :)
Lese mal meinen Beitrag (Hasont vom 26.02) da hab ich beschrieben wie
ich die Platine getestet und eingestellt habe. Ich musste danach am Poti
nichts mehr justieren.
Sven G. schrieb:> John B. schrieb:>> oha, das wiederspricht allerdings meiner Theorie von max. 3 Bytes ID.>> Wie unschön. Da muss ich mir was einfallen lassen, denn ebusd>> unterstützt derzeit maximal 4 ID Bytes (zusätzlich zu PBSB).> In der Tat, denn die Ergebnisse haben neben verschiedenen Datentypen> sogar verschiedene Längen:>
1
ff15b52406020000001a00 / 0500001a0000
2
> ff15b52406020000001b00 / 0603001b000500
3
> ff15b52406020000001c00 / 0803001c000000b442
4
> ff15b52406020000001d00 / 0803001d0000007041
> Das stammt zwar jetzt von einem künstlich initiierten Scan, zeigt sich> aber auch bei den Nachrichten zwischen Internetmodul und Steuerung.
Hast Du schon einmal entsprechende Write Nachrichten gesehen?
Ich hab die Längenbegrenzung jetzt aufgehoben und würde gerne noch einen
Test für die Schreibrichtung einbauen.
> Hast Du schon einmal entsprechende Write Nachrichten gesehen?> Ich hab die Längenbegrenzung jetzt aufgehoben und würde gerne noch einen> Test für die Schreibrichtung einbauen.
So sehr viel kann das Internetmodul wohl nicht an die Steuerung
schreiben, aber z.Bsp. den Ferienzeitraum und Temperaturen setzen:
1
0015b5240a0201000082000000a841 / 020000
2
0015b52409020100007200020a0f / 020000
3
0015b52409020100007100160a0f / 020000
Das vorletzte Byte der ersten Zeile (a8) ist die Temperatur von 21°C und
darunter Ende und Beginn der gesetzten Urlaubsphase:
020a0f = 02.10.2015
160a0f = 22.10.2015
Dass ich eigentlich 22.12.2015 bis 02.01.2016 gesetzt habe, werde ich
mal an Vaillant melden - so GANZ fehlerfrei ist die App eben noch
nicht... ;-)
Nachtrag: bei genauem Hinsehen bringt das etwas Licht ins Dunkel!
Bei den "b509" Meldungen hatte Vaillant lesen/schreiben durch 0d/0e
unterschieden. Das ist jetzt bei den "b524" offenbar 0200/0201. Dahinter
kommen 4 Bytes, welche die Nachricht klassifizieren - das 2. davon gibt
dabei den betroffenen Heizkreis (k) bzw. die Zone an, das erste (a),
dritte und vierte (b) wird bei jedem Read als Zuordnung nochmal
zurückgegeben, ich habe es mal durch Leerzeichen lesbarer gemacht:
Helmut H. schrieb:> Peter T. schrieb im Beitrag #4370613:>> Sorry, muss leider ueber das Forum kommunizieren wg. e-mail Problemen>> 2. Mail auf GMX und übers Forum noch eine.....> Mehr kann ich nicht machen, such Dir 'ne neue Mailadr, wenn es auch> nicht übers Forum hier nicht geht....
Hallo Helmut,
scheinbar haben wir noch immer e-mail Probleme, diesmal von mir zu Dir -
hab Dir den Betrag am 30.November überwiesen, bitte schick mir die
Platinen.
Danke
LG Peter
Glaube eher an ein Postproblem, Platinen sind unterwegs. Deine Mail ist
auch angekommen.
Edit: Wann Du überwiesen hast, weiß ich nicht, angekommen ist es am 3.
Du darfst nicht vergessen: es ist eine Überweisung von Österreich nach
Deutschland und bei der Post ist es ähnlich.
John B. schrieb:> Hast Du schon einmal entsprechende Write Nachrichten gesehen?> Ich hab die Längenbegrenzung jetzt aufgehoben und würde gerne noch einen> Test für die Schreibrichtung einbauen.
Gleich noch eine Frage dazu: es gibt offenbar Schreib/Lese-Operationen.
Die Steuerung VRC700 schickt dem Mischermodul VR70 die
Soll-Vorlauftemperatur und bekommt den aktuellen Status des Mischers als
Antwort zurück:
1
1052b5230402010154 / 0201fb
2
^^ Mischerstatus schließt -100..+100 öffnet (SCH)
3
^^ offenbar immer 01
4
^^ Vorlaufsoll 42°C (D1C)
5
^^ 0 oder 1: Heizen notwendig/Vorlaufsoll gültig
Wie müsste ich eine CSV-Zeile anlegen, dass ich sowohl die
Vorlauf-Solltemperatur als auch den Mischerstatus auslesen kann?
Vielleicht muss ich noch weiter suchen, aber beides habe ich bisher
nicht in reinen Leseoperationen gefunden. Somit entfällt auch ein
aktives Auslesen, aber ebusd könnte beim Mitlesen der Nachricht ja
beides irgendwo puffern (diese treffen ohnehin im 10-Sekunden-Takt ein).
Ich habe jetzt analog zum 'makegrabcsv' folgende Zeile erstellt:
Und sehe daraufhin folgenden Eintrag im Log:
> [update notice] update McFlowTempDesired QQ=10: on;42.0;on;-5
Aber bei einem Versuch 'ebusctl r McFlowTempDesired' erhalte ich
natürlich 'ERR: invalid numeric argument'. Komme ich irgendwie an die
Werte, die im Log stehen?
Sven G. schrieb:> Aber bei einem Versuch 'ebusctl r McFlowTempDesired' erhalte ich> natürlich 'ERR: invalid numeric argument'. Komme ich irgendwie an die> Werte, die im Log stehen?
Da war noch ein Fehler im Cache cleanup. Sollte jetzt funktionieren,
vorausgesetzt die Daten sind frisch genug (nicht älter als 5 Minuten).
Hallo zusammen,
nachdem ich vor über einem Jahr zwei Platinen von Benedikt Patt erworben
hatte, kam ich jetzt dazu diese zu löten und in Betrieb zu nehmen.
Meine Vaillant Heizungsanlage (ecoTec VC146 inkl. auromatic 620/3) kann
ich ohne Probleme auslesen, dank der hervorragenden Arbeit aller
Beteiligten insbesondere John. Vielen Dank.
Nun betrete ich allerdings vermutlich Neuland. Meine KWL von Brink
(Renovent Sky 300) spricht auch Ebus, auch hier funktioniert der
EBUS-Adapter. Interessanterweise ist im Orginal-Diagnosekabel von Brink
(Kosten nach Recherche ca. 300 Euro) der gleiche FTDI-Chip verbaut wie
auf der gelöteten Platine. Folglich funktioniert sogar die
Diagnosesoftware vom Hersteller. Die KWL-Anlage gibt es
baugleich/gelabelt auch von Wolf (CWL F-300) falls das jemand
interessiert.
Meine Probleme die ich aktuell habe, liegen bei den Datentypen. Ich
bekomme über den Bus z.B. eine Dezimalwert 260 mit Hex 01 04 gesendet.
Ebusd macht beim Datentyp UIN aber 1025 draus, ergibt rückwärts Hex 04
01 (also gedreht). Das höherwertige Byte wird wohl an zweiter Stelle
erwartet!?
Gibt es einen Kniff die Bytereihenfolge umzustellen, oder bin ich auf
dem Holzweg und muss was anderes ändern?.
Danke schonmal für eure Antworten.
Patrick K. schrieb:> Meine Probleme die ich aktuell habe, liegen bei den Datentypen. Ich> bekomme über den Bus z.B. eine Dezimalwert 260 mit Hex 01 04 gesendet.> Ebusd macht beim Datentyp UIN aber 1025 draus, ergibt rückwärts Hex 04> 01 (also gedreht). Das höherwertige Byte wird wohl an zweiter Stelle> erwartet!?>> Gibt es einen Kniff die Bytereihenfolge umzustellen, oder bin ich auf> dem Holzweg und muss was anderes ändern?.
Die eBUS Datentypen sind meist in little endian notiert. Es gibt
natürlich Ausnahmen seitens der Hersteller, die teilweise auch in die
verfügbaren ebusd Datentypen einfließen mussten (bspw. BTI/VTI/VTM).
Für int Werte war das bis dato nicht notwendig.
Solltest Du wirklich einen umgedrehten Datentyp benötigen, dann kann ich
das schon eibauen. Das würde ich aber erst dann tun, wenn Du Dir
wirklich über die Codierung der Daten sicher bist.
Hallo John,
danke für deine Antwort.
John B. schrieb:> Solltest Du wirklich einen umgedrehten Datentyp benötigen, dann kann ich> das schon eibauen. Das würde ich aber erst dann tun, wenn Du Dir> wirklich über die Codierung der Daten sicher bist.
Ich bin mir da schon sehr sicher. Sämtliche Daten die über 2-Byte Felder
übertragen wurden, wo Werte < 256 sind, konnte ich mit Divisor 256
entsprechend einstellen. Bei Werten über 256 bin ich da aktuell
machtlos.
Beispielsweise kann ich z.B. die konfigurierten Lüftungsvolumen pro
Stunde der 4 Stufen (50,105,180,260) auslesen. Die ersten drei Werte mit
Divisor 256 kein Problem, bei dem Wert 260, wie oben geschrieben, wird
das zweite Byte belegt, dann funktioniert das dann nicht mehr.
Ob ich künftig Datum brauche, weiß ich jetzt noch nicht. Die
Anlagensteuerung scheint mir insgesamt sehr primitiv. Bisher kann ich
auch nur das eigentliche Deckengerät steuern und dessen Sensorwerte
auslesen, indem ich die Kommunikation des Bedienmoduls mitgeschnitten
hatte. Ob man das Bedienmodul selber überhaupt über EBUS konfigurieren
kann (unter anderem definierte Perioden mittels Zeit und Datum
überschreiben) ist für mich noch nicht ersichtlich.
Aktuell funktioniert auch kein scan und scan result, aber das ist nicht
so wichtig.
Gruß
Paddy
Patrick K. schrieb:> Ich bin mir da schon sehr sicher. Sämtliche Daten die über 2-Byte Felder> übertragen wurden, wo Werte < 256 sind, konnte ich mit Divisor 256> entsprechend einstellen. Bei Werten über 256 bin ich da aktuell> machtlos.
für Werte die unter 2 Bytes Länge bleiben solltest Du vermutlich eher
einen anderen Datentyp nehmen, z.B. UCH.
> Beispielsweise kann ich z.B. die konfigurierten Lüftungsvolumen pro> Stunde der 4 Stufen (50,105,180,260) auslesen. Die ersten drei Werte mit> Divisor 256 kein Problem, bei dem Wert 260, wie oben geschrieben, wird> das zweite Byte belegt, dann funktioniert das dann nicht mehr.
Es sind jetzt neue Typen mit "R" am Ende (für "reverse") verfügbar, z.B.
UIR.
Viel Spaß,
John
Hallo,
ich wollte noch einmal daran erinnern, dass bei mir noch 5 eBus-USB
Adapter liegen, die einen neuen Besitzer suchen.
Die Adapter sind vollständig aufgebaut und getestet.
Gruß und guten Rutsch,
Björn
Würde eine Platine abnehmen; bitte Preis und am einfachsten per Paypal
und an "Freund" oder ?
Bin seit 5 Tagen nur am Lesen und Staunen.
Will Pi2 oder Banana M2 bestellen => egal ? Bin noch unsicher ....
Hab erst einen Raspi PI (1) am laufen gehabt, der lief schon recht gut,
nach einem Blitzschlag habe ich dann auf Raspi PI 2 aufgerüstet, der
läuft super mit EBUSD und FHEM und hat noch massig Reserve (Auslastung),
hat 4x USB, u.U. erweiterbar mit Hub (am Hub läuft aber u.U. nicht
alles, also je mehr USB umso besser). Wichtig: Gutes Netzteil und gute
Speicherkarte, habe 16GB genommen als SDHC Class 10, da kann man noch
ein Image (ist dann 16GB groß!) sichern falls mal was schief läuft. Also
nicht am falschen Ende sparen ;-)
Grüße
Christian
Björn C. schrieb:> Hallo,>> ich wollte noch einmal daran erinnern, dass bei mir noch 5 eBus-USB> Adapter liegen, die einen neuen Besitzer suchen.>> Die Adapter sind vollständig aufgebaut und getestet.>> Gruß und guten Rutsch,> Björn
Neues Projekt für 2016 - da bin ich dabei :)
Email wg. Bestellung ist schon draussen!
Andreas A. schrieb:> Björn C. schrieb:>> Hallo,>>>> ich wollte noch einmal daran erinnern, dass bei mir noch 5 eBus-USB>> Adapter liegen, die einen neuen Besitzer suchen.>>>> Die Adapter sind vollständig aufgebaut und getestet.>>>> Gruß und guten Rutsch,>> Björn
Hallo,
alle Adapter sind vorerst ausverkauft!
Vielen Dank an alle Käufer.
Gruß Björn
Hallo eBus Gemeinde ;-)
hat wer noch eine Adapter Platine oder einen fertigen Adapter?
Oder gibt es vll jemanden der noch mal ein Mehrfachnutzen los tritt?
Wäre sehr interessiert.
Datum: 29.12.2015 19:31
Platinen von mir, fertige Adapter von Björn
Papa ist blind, ich zweifel an den Fähigkeiten die Platine dann auch zu
bestücken......
>> Hallo,>> alle Adapter sind vorerst ausverkauft!> Vielen Dank an alle Käufer.>> Gruß Björn
@Helmut
nach dem obigen Feedback von Björn (der ohne Papa) wollte ich erst mal
in die Gruppe fragen bevor ich Leute per PN nerve
Schön aber das es Dir gut geht und du anscheinend ein toller Hecht bist.
Eine einfache Antwort hätte auch gelangt ;-)
So... ich muss nochmal um Nachhilfe bitten!
Ich versuche gerade, endlich mal die von mir identifizierten
Vaillant-Meldungen in eine vernünftige CSV zu packen. Momentan scheitere
ich aber an dieser Eigenart, dass die VRC700 bei einem Lesevorgang am
Anfang immer die 4 Bytes der ausgelesen ID sendet.
Schreiben und Lesen von Hand sieht so aus:
1
# ebusctl w -h 15b5240c020100006f0054656c65666f
2
020000
3
4
# ebusctl w -h 15b52406020000006f00
5
0b03006f0054656c65666f00
In dem String steht der erste Teil (ja, auch das hatten wir ja schon)
der Service-Telefonnummer. Nun hätte ich gern eine CSV-Zeile dazu, die
mir folgendes ermöglicht:
1
# ebusctl w vrc700 PhoneNumber1 "Telefo"
2
# ebusctl r PhoneNumber1
3
Telefo
Mein Ansatz:
1
*r,vrc700,,,,,"B524","0200",,,,,,,,,
2
*w,vrc700,,,,,"B524","0201",,,,,,,,,
3
r;w,,PhoneNumber1,Telefonnummer Teil 1,,,,"00006F00",ignored,s,IGN:4,,,,phone,,STR:6,,,,,,
Lesen klappt damit wunderbar, aber Schreiben nicht.
Durch das ",s," nach dem "ignored" konnte ich wenigstens dafür sorgen,
dass ich diese Felder nicht schreiben muss (sie kommen ja NUR vom
Slave), aber jeder Schreibvorgang meldet jetzt ein "ERR: invalid
position in decode", weil als Bestätigung nur "020000" zurückkommt,
statt der erwarteten 4 Bytes zum Ignorieren...
Es geht zwar so erstmal, aber schön ist der Fehler nicht.
Frage am Rande: die vorgefertigten CSVs scheinen einen Default-Circuit
zu haben. Alle Meldungen aus der "08.bai.csv" erscheinen beispielsweise
im Circuit "bai". Bei meiner CSV habe ich versucht, das über den
Dateinamen "15.vrc700.csv" zu steuern, aber dort war der Circuit immer
leer, bis ich ihn in den *r/*w-Zeilen benannt habe...
PapaBjörn schrieb:> Hallo eBus Gemeinde ;-)>> hat wer noch eine Adapter Platine oder einen fertigen Adapter?> Oder gibt es vll jemanden der noch mal ein Mehrfachnutzen los tritt?> Wäre sehr interessiert.
Hallo,
eine Platine habe ich noch da.
Bei Bedarf bitte per PN melden.
Gruß
Benedikt
>> In dem String steht der erste Teil (ja, auch das hatten wir ja schon)> der Service-Telefonnummer. Nun hätte ich gern eine CSV-Zeile dazu, die> mir folgendes ermöglicht:>
1
# ebusctl w vrc700 PhoneNumber1 "Telefo"
2
> # ebusctl r PhoneNumber1
3
> Telefo
Wie sieht denn dann Teil 2 der Telefonnummer aus?
> Frage am Rande: die vorgefertigten CSVs scheinen einen Default-Circuit> zu haben. Alle Meldungen aus der "08.bai.csv" erscheinen beispielsweise> im Circuit "bai". Bei meiner CSV habe ich versucht, das über den> Dateinamen "15.vrc700.csv" zu steuern, aber dort war der Circuit immer> leer, bis ich ihn in den *r/*w-Zeilen benannt habe...
Richtig, default circuit greift nur in default Definitionen. Das ist so
gedacht.
John B. schrieb:> Wie sieht denn dann Teil 2 der Telefonnummer aus?
Das war nur ein Beispiel - der zweite Teil ist identisch; ebenfalls
einfach 6 Zeichen STR. Die sind genauso getrennt, wie auch die
Bezeichnung der Heizkreise. Aber ich habe gesehen, dass das auch beim
470 oder 430 so war - deshalb will ich darüber erstmal nicht meckern.
Ich muss nur irgendwie ein sauberes WRITE hinbekommen - geht das dann
wirklich nur über separate r/w-Zeilen (und geht das überhaupt mit
identischen Namen)?
> Richtig, default circuit greift nur in default Definitionen. Das ist so> gedacht.
Okay, ich dachte, das irgendwie nachbauen zu können, um dann die
"fertige" vrc700 auf Github zu stellen...
Und nochmal zurück zu meinem Klassiker:
Sven G. schrieb:> h) 0015b52406020003010f00 / 0801030f00cd4ca141[/code]>> h) und die letzte für heute enthält u.a. die Raumtemperatur, nach der> ich schon lange gesucht habe. Allerdings als "neuer Datentyp".> Anfang ist wie gehabt, die eigentlichen Daten beginnen mit:> cd = keine Ahnung, scheint statisch zu sein> 4c = auch keine Ahnung, ist aber manchmal cc - also sicher irgendein> Bit-Status> a1 = Raumtemperatur * 8, ich müsste also UCH durch 8 Teilen (geht das> über 'divisor'?)> 41 = ebenfalls noch unklar und statisch
Das scheint der neue Trend bei Vaillant zu sein: aus den 32 nutzbaren
Bits werden "irgendwo" welche genutzt und die restlichen entweder nicht
initialisiert, oder sie zeigen einen Status an. Inzwischen bin ich etwas
schlauer:
Das MSB vom 2. Byte gehört mit zur Temperatur, daher entweder 0x4C oder
0xCC. Beim 4. Byte wirds kritischer, da wird bei Temperaturen >32°C die
0x41 zur 0x42 wird - eine reine Bit-Trennung ist da nicht mehr machbar;
man braucht einen Offset - also zusätzlich zum Divisor etwas, was
konstant abgezogen/hinzuaddiert wird!
H I L F E .....
Sven G. schrieb:> John B. schrieb:>> Wie sieht denn dann Teil 2 der Telefonnummer aus?> Das war nur ein Beispiel - der zweite Teil ist identisch; ebenfalls> einfach 6 Zeichen STR. Die sind genauso getrennt, wie auch die> Bezeichnung der Heizkreise. Aber ich habe gesehen, dass das auch beim> 470 oder 430 so war - deshalb will ich darüber erstmal nicht meckern.> Ich muss nur irgendwie ein sauberes WRITE hinbekommen - geht das dann> wirklich nur über separate r/w-Zeilen (und geht das überhaupt mit> identischen Namen)?
ich meinte den Master-Teil, aber habs jetzt rausgefunden.
Wenn ich das richtig verstanden habe, sieht das read/write hier so aus:
1
020000006f00 / 0b03006f0054656c65666f00
2
RRRRIIKKIIII ??iiiiii11111111111122
3
020100006f0054656c65666f / 020000
4
WWWWIIKKIIII111111111111 AAAA
R=read prefix
W=write prefix
I=ID (master)
i=ID (wiederholung im slave)
K=Kreis (gehört somit auch zur ID)
1-9=Feld 1-9
A=acknowledge
Somit müsste folgendes CSV das gewünschte leisten:
1
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment,field2,part (m/s),datatypes/templates,divider/values,unit,comment
>> Richtig, default circuit greift nur in default Definitionen. Das ist so>> gedacht.> Okay, ich dachte, das irgendwie nachbauen zu können, um dann die> "fertige" vrc700 auf Github zu stellen...
ja klar, einfach das Namenschema benutzen, also das ganze dann in
"15.700.csv" im de/vailllant Verzeichnis ablegen und schon kann circuit
und Ziel-Adresse aus den "*r" bzw. "*w" Zeilen verschwinden.
>> cd = keine Ahnung, scheint statisch zu sein>> 4c = auch keine Ahnung, ist aber manchmal cc - also sicher irgendein>> Bit-Status>> a1 = Raumtemperatur * 8, ich müsste also UCH durch 8 Teilen (geht das>> über 'divisor'?)>> 41 = ebenfalls noch unklar und statisch> Das scheint der neue Trend bei Vaillant zu sein: aus den 32 nutzbaren> Bits werden "irgendwo" welche genutzt und die restlichen entweder nicht> initialisiert, oder sie zeigen einen Status an. Inzwischen bin ich etwas> schlauer:>> Das MSB vom 2. Byte gehört mit zur Temperatur, daher entweder 0x4C oder> 0xCC. Beim 4. Byte wirds kritischer, da wird bei Temperaturen >32°C die> 0x41 zur 0x42 wird - eine reine Bit-Trennung ist da nicht mehr machbar;> man braucht einen Offset - also zusätzlich zum Divisor etwas, was> konstant abgezogen/hinzuaddiert wird!
wie genau? Schreib doch mal ein paar Beispiele mit Binärdaten und
zugehörigen Werten.
John B. schrieb:> ich meinte den Master-Teil, aber habs jetzt rausgefunden.> [...]> Somit müsste folgendes CSV das gewünschte leisten:
Erstmal wieder vielen Dank, John!!
Super - ich hatte "übersehen", dass ich das IGN:4 ja im Read-Template
angeben kann - dadurch ist mein Write-Error verschwunden!
Soweit hast du alles richtig angenommen - aber: sehe ich das richtig,
dass das "6F00;6F01" eine neu eingebaute Möglichkeit ist?? Dann muss ich
unbedingt eine neue Version kompilieren, das wäre wunderbar!
John B. schrieb:> ja klar, einfach das Namenschema benutzen,
Aaaahhh - das hatte ich versucht, aber scheinbar sind hier nur 3 oder 4
Zeichen zulässig. Mein "vrc700" klappte nicht, ich werde es auf "700"
ändern!
John B. schrieb:>> Das MSB vom 2. Byte gehört mit zur Temperatur, daher entweder 0x4C oder>> 0xCC. Beim 4. Byte wirds kritischer, da wird bei Temperaturen >32°C die>> 0x41 zur 0x42 wird - eine reine Bit-Trennung ist da nicht mehr machbar;>> man braucht einen Offset - also zusätzlich zum Divisor etwas, was>> konstant abgezogen/hinzuaddiert wird!>> wie genau? Schreib doch mal ein paar Beispiele mit Binärdaten und> zugehörigen Werten.
Okay, hier ein paar Beispiele. Aktuelle Raumtemperatur Heizkreis 2:
Hier scheint "cd_c____" immer statisch zu sein und das 2. Byte ist immer
entweder 4c oder cc, es zählt nur das höchste Bit zur Temperatur (ich
vermute fehlende Initialisierung bzw. Ignorieren der anderen Bits).
Verifizieren konnte ich das bei der Einwirkung der Raumtemperatur in der
Einstellung "Thermostat". Hier wird (wie im handbuch beschrieben) exakt
bei +3/16K der eingestellten Temperatur der Heizkreis ausgeschaltet und
bei -4/16K wieder eingeschaltet.
Bei Vorgabetemperaturen (meist max. in 0,5K Schritten einstellbar) steht
dort ordentlich 0000, kann jedoch beliebig gesetzt werden, ohne dass es
zu erkennbaren Fehlern führt. Bisher gehe ich also davon aus, dass nur
ein Offset von 0x41000000 dazu kommt.
Beispiel Solltemperatur Tag Heizkreis 2:
Die 41 kann aber zur 42 werden, wenn es um Temperaturen >32°C geht - und
sicher auch zur 40 bei negativen... Auf jeden Fall aber wird sie zu 00,
wenn die Temperatur nicht gesetzt/gültig ist.
Dazu hier einige Vorlaufsolltemperaturen Heizkreis 2 nach gleichem
Schema
1
ff15b52406020002010700 / 080102070000000000 = kein Wärmebedarf
Die Werte habe ich hier entsprechend gerundet, wie sie als D1C zum
Mischermodul geschickt werden. Die ersten 2 Bytes könnten dabei einfach
weitere Nachkommastellen aus der Berechnungsroutine sein...
Am Rande nochmal meine Beobachtungen zu den hier genannten Buchstaben:
RRRR = 0200 für read (0201 für write)
AA = Geltungsbereich: 00 global, 01 Warmwasser, 02 Heizkreis, 03 Zone
KK = bei Heizkreis/Zone die Kreisnummer 00-05
IIII = Index
?? = scheint eine Art Klassifizierung des Index zu sein (ist für alle
immer konstant, aber variiert bei verschiedenen Werten: 00-03)
Ach und bevor es langweilig wird - hier noch ein paar andere Werte mit
solchen seltsamen Offsets, diese sind hier aber nicht konstant, die
verbleibenden Bits scheinen noch weitere Bedeutungen zu haben (ich habe
jedenfalls weder für die Heizkurve, noch für die Temperaturüberhöhung
einen brauchbaren Offset/Faktor gefunden - müsste also nochmal alle
möglichen Werte einstellen und über eBus auslesen):
So, letzte Bitte für heute - vor allem, weil ich sicher ohnehin ebusd
neu compilieren muss:
Bei meinen Geräten stimmt das Template "errorhistory" nicht!
Keine Ahnung, ob das bei älteren Geräten so war/ist - aber mein Brenner
meldet alle Fehler OHNE Uhrzeit/Datum und alle die es tun, melden eine
2-Byte BCD Zeit. Definiert ist es als "VTI", also Hex-Zeit - was zu
einem "ERR: argument value out of valid range in decode" führt.
Ich habe das Zeitfeld mal in BCD:2 geändert, was an sich ganz brauchbar
aussieht, zur Kontrolle die Hexdaten danach:
1
# ebusctl read -f -d ... -i 0 errorhistory
2
2;2126;19.11.2015;1231
3
2;2051;09.11.2015;590
4
2;1808;06.01.2016;1511
5
# ebusctl w -h 15b50303010100
6
08022621191115cf04
7
080251200911154e02
8
08020818060116e705
Es müsste also noch ein eingebauter 2 Byte BCD Zeit-Datentyp ("BTM"?)
ergänzt werden.
Hallo John,
langsam sehe ich mehr durch. Ich habe im Changelog von der Kombination
der Messages gelesen und daher erstmal neu kompiliert. Zum Test habe ich
mir gleich einen Datentyp "BTM" gebastelt, der auch funktioniert:
1
{"BTM",16,bt_tim,BCD|REV,0xff,5,5,0},// time in BCD, 00:00 - 23:59 (0x00,0x00 - 0x59,0x23, replacement 0xff)
Leider klappt die Kombination der Felder nicht, ich sehe immer nur den
Inhalt des ersten! Kann ich das irgendwie debuggen?
[EDIT]
Ein 'log level debug' zeigt:
1
2016-01-27 21:30:45.344 [main debug] >>> r PhoneNumber
2016-01-27 21:30:45.718 [main info] read 700 PhoneNumber: Tel
19
2016-01-27 21:30:45.718 [main debug] <<< Tel
Erwartet hätte ich "Tel 9" - leider fast nur Leerzeichen, machte
keinen Spaß, das an der Steuerung einzugeben. g
Neue Konfigurationen habe ich mir auch in ein Debian-Paket gepackt (auf
dem Zielsystem habe ich kein git), was leider nicht sofort installieren
wollte! Ich musste dem dpkg ein '--force-overwrite' hinzufügen, weil
ebusd-configuration die Datei '/etc/ebusd/broadcast.csv' aus ebusd
überschreibt. Vielleicht sollte die lieber aus ebusd-configuration
wieder raus?
Nebenbei habe ich das mit --scanconfig mal getestet. Auch ein kleiner
Dämpfer: es läuft zwar und lädt meine Dateien, aber eine meiner selbst
erstellten melden beim Laden zu Laufzeit:
1
[main error] error reading scan config file /etc/ebusd/vaillant/52.vr_70.csv for ID "vr_70", SW0109, HW2903: ERR: duplicate entry
Leider sehe ich nicht, welche das sein soll - und die ersten/wichtigsten
definierten Meldungen gehen.
Wenn ich ein 'ebusd --checkconfig --scanconfig
ff52070400/0ab556525f373001092903' starte, meldet er keinen Fehler -
wenn ich '--scanconfig' weglasse, kommen ca. 1000 Duplikate...
Finde ich irgendwie, wo das Duplikat herkommt?
Sven G. schrieb:> Zum Test habe ich> mir gleich einen Datentyp "BTM" gebastelt, der auch funktioniert:>
1
{"BTM",16,bt_tim,BCD|REV,0xff,5,
2
>5,0},// time in BCD, 00:00 - 23:59 (0x00,0x00 - 0x59,0x23,
3
>replacement0xff)
Okay, kann ich ja mal noch mit dazu nehmen.
> Leider klappt die Kombination der Felder nicht, ich sehe immer nur den> Inhalt des ersten! Kann ich das irgendwie debuggen?
Das Problem ist das "00" Byte mitten drin, würd ich schätzen. Das hab
ich gestern übersehen. Somit kann man dafür die verketteten Messages
nicht benutzen. Also separate Definitionen draus bauen...
> Neue Konfigurationen habe ich mir auch in ein Debian-Paket gepackt (auf> dem Zielsystem habe ich kein git), was leider nicht sofort installieren> wollte! Ich musste dem dpkg ein '--force-overwrite' hinzufügen, weil> ebusd-configuration die Datei '/etc/ebusd/broadcast.csv' aus ebusd> überschreibt. Vielleicht sollte die lieber aus ebusd-configuration> wieder raus?
Das wird vielleicht in der nächsten Version passieren, mal sehen. Evtl.
baue ich noch ein paar der durch die Spezifikation definierten Messages
fest in ebusd ein.
> Nebenbei habe ich das mit --scanconfig mal getestet. Auch ein kleiner> Dämpfer: es läuft zwar und lädt meine Dateien, aber eine meiner selbst> erstellten melden beim Laden zu Laufzeit:>
1
[main error] error reading scan config file
2
> /etc/ebusd/vaillant/52.vr_70.csv for ID "vr_70", SW0109, HW2903: ERR:
3
> duplicate entry
> Leider sehe ich nicht, welche das sein soll - und die ersten/wichtigsten> definierten Meldungen gehen.>> Wenn ich ein 'ebusd --checkconfig --scanconfig> ff52070400/0ab556525f373001092903' starte, meldet er keinen Fehler -> wenn ich '--scanconfig' weglasse, kommen ca. 1000 Duplikate...> Finde ich irgendwie, wo das Duplikat herkommt?
Ohne "--scanconfig" kommen natürlich Duplikate, sofern Du nicht alle
Files löscht, die nicht zu Deiner Anlage passen.
Mit "--scanconfig": übergebe mal alle Deine scans an ebusd mit
"--checkconfig", dann sollte der problematische Kandidat schon
rauspurzeln.
John B. schrieb:> Das Problem ist das "00" Byte mitten drin, würd ich schätzen. Das hab> ich gestern übersehen. Somit kann man dafür die verketteten Messages> nicht benutzen. Also separate Definitionen draus bauen...
Hmm, nein - daran liegt es wohl nicht. Ich habe die Definition mal auf
"HEX:7" geändert, um hoffentlich beide 6 Zeichen incl. der 00 zu
bekommen - aber auch das gibt mit nur die 7 Werte des ersten Teils
zurück.
Ich habe mir mal die Code-Änderungen angesehen...
In 'Message::decodeLastData()' wird nur 'm_data->read()' aufgerufen -
diese wurde aber offenbar gar nicht für "chained messages" angepasst?!
Allerdings verstehe ich noch nicht wirklich, was da in welcher
Reihenfolge abläuft, deshalb sieh's mir nach wenn ich falsch liege.
Theoretisch ließe sich das ja aber mit beliebigen Nachrichten testen,
die gleich lange Antworten schicken - einfach mal als HEX definieren und
zu einer kombinieren. Wie müsste dann das Ergebnis aussehen?
Die Hex-Nachrichten und meine Config sind:
Doch das Ergebnis ist nur:
03 00 6f 00 54 65 6c 20 20 20 00
Interessant: wenn ich das auf "HEX:22" ändere, bekomme ich alle 22
Werte!
Damit könnte ich mir nun zumindest etwas basteln, was mir genau die 2x 6
Zeichen zurückgibt, nur leider mit Semikolon getrennt:
Auch wenn das schon sehr viel besser ist - kann ich die Trennung mit
Semikolon irgendwie ausschalten?
Ehrlich gesagt, fällt mir spontan ohnehin keine gute (andere)
Möglichkeit ein, wenn es um Nachrichten mit mehreren/anderen Inhalten
geht: Zeichenketten und HEX kann man leicht alle hintereinander nennen.
Aber 2 UCH aus verschiedenen Messages? Sollen die nacheinander oder
zusammengefasst werden?
Von daher ist es sicher schon richtig so, wie es ist!
Einzige Möglichkeit in meinen Augen:
Wenn 2 STR oder HEX aufeinander folgen (unabhängig von chained
messages), könnte man das Semikolon weglassen. Aber das verbaut dann
wieder die Möglichkeit, solche mit Semikolon getrennt auszugeben......
Also nochmal konkret: folgende Definition könnte folgendes Ergebnis
haben:
Nur was, wenn jemand eigentlich "00 01;04 05 06 07;08 09" erwartet
hätte?
Was meinst Du dazu?
John B. schrieb:> Mit "--scanconfig": übergebe mal alle Deine scans an ebusd mit> "--checkconfig", dann sollte der problematische Kandidat schon> rauspurzeln.
Sehr, sehr schön! Diese Möglichkeit stand nirgends und ich hab's ehrlich
gesagt nicht probiert. Für alle Interssierten: ich habe mir eine
quick&dirty Funktion gebaut, die Konfiguration für mehrere IDs zu
prüfen:
1
# function ebusscanid() { echo "ff${1}070400/$(ebusctl w -h ${1}070400 | head -1)" ;}
Sven G. schrieb:> Hmm, nein - daran liegt es wohl nicht. Ich habe die Definition mal auf> "HEX:7" geändert, um hoffentlich beide 6 Zeichen incl. der 00 zu> bekommen - aber auch das gibt mit nur die 7 Werte des ersten Teils> zurück.
naja, wenn Du zwei Nachrichten verkettest, muss die Länge natürlich
größer als 7 sein...
> Wenn 2 STR oder HEX aufeinander folgen (unabhängig von chained> messages), könnte man das Semikolon weglassen. Aber das verbaut dann> wieder die Möglichkeit, solche mit Semikolon getrennt auszugeben......> Was meinst Du dazu?
Das ist in meinen Augen zu kompliziert. Wenn der Hersteller verkettete
Messages nutzt, dann aber in einen Gesamtstring was anderes zwischen
rein schummelt, muss man halt damit leben.
Also ich stimme dem Quatsch mit dem Verketten von Nachrichten zu - eine
sinnvolle Lösung gibt's da nicht, ist halt Vaillant...
Es wäre jedoch toll, hierfür eine Lösung zu finden:
1
ff15b52406020002010700 / 080102070000000000 = kein Wärmebedarf
Ich habe mir mal den Code angesehen, einen Offset festzulegen ist wohl
gar nicht soo einfach. Zumal man dem auch beim Schreiben berücksichtigen
müsste... doofe Sache!
Oder jemand eine Idee?
>> Ich habe mir mal den Code angesehen, einen Offset festzulegen ist wohl> gar nicht soo einfach. Zumal man dem auch beim Schreiben berücksichtigen> müsste... doofe Sache!
Wenn sich manifestiert, dass das ein durchgängig bei neueren Geräten
verwendeter Datentyp ist, würde ich diesen einfach dazu bauen (samt
Offset).
Drum wärs mir wichtig, noch mehr Beispielwerte zu bekommen und diese
auch aus anderen Nachrichten (nicht nur 0700) sowie auch in
Schreibrichtung zu beobachten. Bekommst Du das hin?
John B. schrieb:> Drum wärs mir wichtig, noch mehr Beispielwerte zu bekommen und diese> auch aus anderen Nachrichten (nicht nur 0700) sowie auch in> Schreibrichtung zu beobachten. Bekommst Du das hin?
Zu anderen Geräten konnte ich solche Werte (noch) nicht beobachten,
vielleicht hat pierce da mehr Glück mit seiner VRC700 und der WP?!
In Schreibrichtung sehe ich diese folglich nur von der SmartphoneApp zur
VRC700 - hier auch schön zu sehen, dass die Temperatur nicht immer
einen Offset von 0x4100 und Faktor 8 hat, bei Warmwasser ist dieser
anders:
Aaaaaah - noch eine Erkenntnis. Und die passt sogar zum oben
geschilderten Bild:
Der letzte Wert scheint zusätzlich zum Offset die Genauigkeit
festzulegen!
Wie man oben schon erkennt, ist das 3. Byte bei 0x41 durch 8 zu teilen,
bei 0x42 durch 4 zu teilen und (!) 32 hinzuzurechnen.
Das sehe ich analog bei der schonmal erwähnten Temperaturüberhöhung, und
das zeigt noch etwas interessanteres:
Man sieht, dass selbst das höchstwertige Bit aus Byte 3 die Genauigkeit
steuert: bei 0x41 und Byte 3 größer gleich 0x80 ist durch 8 zu teilen,
darunter durch 16.
Somit ergibt sich für das Byte 4 plus MSB von Byte 3:
0x3f | 1 ==> Divisor 128, Offset 1 (>= 1K/°C)
0x40 | 0 ==> Divisor 64, Offset 2 (>= 2K/°C)
0x40 | 1 ==> Divisor 32, Offset 4 (>= 4K/°C)
0x41 | 0 ==> Divisor 16, Offset 8 (>= 8K/°C)
0x41 | 1 ==> Divisor 8, Offset 16 (>= 16K/°C)
0x42 | 0 ==> Divisor 4, Offset 32 (>= 32K/°C)
Ich nehme jetzt einfach mal an, dass das für Byte 1 und 2 analog gilt,
um Nachkommastellen abzubilden. Der Offset ist jeweils für die
verbleibenden 7 Bit aus Byte 3 nach Teilen durch den Divisor gedacht.
Und ich weiß leider noch nicht, ob sich damit negative Werte abbilden
ließen bzw. wie weit nach oben sich das theoretisch treiben ließe.
Denkbar wäre ja bis "0x43 | 0", wo dann Faktor 1 gelten würde für Werte
von 128-256K.
==> das klingt für mich dann doch SEHR nach einem neuen/eigenen Datentyp
und lässt mich hoffentlich noch mehr Hexwerte richtig interpretieren!!
Sven G. schrieb:> ==> das klingt für mich dann doch SEHR nach einem neuen/eigenen Datentyp> und lässt mich hoffentlich noch mehr Hexwerte richtig interpretieren!!
Ja, klingt nach nem echtem floating point. Könntest Du noch rausfinden,
wie negative Werte dargestellt sind? Ich nehme an mit gesetztem Bit 7 im
Exponenten-Tail.
Für alle Interessierten, meine decode/encode Routinen. Ich musste ein
wenig herumprobieren und habe bei der Heizkurve noch leichte
Rundungsabweichungen, aber das muss an der VRC intern liegen und zum
Anzeigen reicht es (setzen kann man sie eh nicht):
1
functiondecode(y){
2
varx,cls=(y>>23&0xff);
3
if(cls<120)return0;// theoretical "< 1", but reduced to 31 bit
4
if(cls>150)returnERR;
5
y-=(cls-1)<<23;
6
x=(y&0x7fffffff)/(1<<(150-cls));
7
if(y&0x80000000){
8
return-x;
9
}
10
returnx;
11
}
12
13
functionencode(x){
14
vary=0,lg;
15
if(x<0){
16
x=-x;
17
y=0x80000000;
18
}
19
lg=Math.floor(Math.log(x)/Math.log(2));
20
if(lg>23)returnERR;
21
if(lg<-6)return0;// theoretical -125, but reduced to 31 bit
22
// round up(!) to integer
23
y+=Math.ceil((1<<(23-lg))*x);
24
y+=(126+lg)<<23;
25
returny;
26
}
Ach ja - ich brauchte das für Node/JS, somit kann ich nur mit 32 Bit
(signed) Integern rechnen, was mir aber ausreicht. In C(++) könnte man
eine höherer Genauigkeit zulassen. Die Theoretischen 2^-125 halte ich
jedoch für Bullshit...
Sven G. schrieb:> Hätte ich auch vermutet. Habe jetzt lange gesucht und einen Wert> gefunden, den ich negativ einstellen kann: "AT Durchheizen"
hab nen neuen Basistyp "EXP" dafür eingebaut (4 bytes).
Kannst ja mal testen.
Wow - vielen Dank!
Vor allem auch der Hinweis auf "IEEE 754", hier z.Bsp. ein
Online-Umrechner:
http://www.h-schmidt.net/FloatConverter/IEEE754de.html
EDIT: 'EXR' trifft auf den Vaillant Typ zu - mein Fehler!!
--> ES GEHT!
EDIT2: Hast du bei der Implementierung big+little endian vertauscht?
Die o.g. Hexdaten sind doch "lillte endian", funktionieren aber mit EXR.
Sven G. schrieb:> Wow - vielen Dank!> Vor allem auch der Hinweis auf "IEEE 754", hier z.Bsp. ein> Online-Umrechner:> http://www.h-schmidt.net/FloatConverter/IEEE754de.html>> EDIT: 'EXR' trifft auf den Vaillant Typ zu - mein Fehler!!> --> ES GEHT!>> EDIT2: Hast du bei der Implementierung big+little endian vertauscht?> Die o.g. Hexdaten sind doch "lillte endian", funktionieren aber mit EXR.
das wollte ich gerade fragen. also eigentlich sollte EXP richtig sein,
sprich zu deinen beispieldaten passen.
Auf was für einer Maschine bist Du? Sprich was ergibt
John B. schrieb:> Auf was für einer Maschine bist Du? Sprich was ergibt
Tja... da wird's wohl schwierig :/
Ich lass das Ding auf einer Seagate Dockstar (armel) laufen und
kompiliere mit CodeSourcery Toolchain auf einer normalen x86 Box. Dessen
GCC meldet ordentlich "little endian", aber beim Crosscompiler ist davon
gar nichts definiert:
root@lxdevel:~# arm-none-linux-gnueabi-gcc -E -dM - </dev/null |grep END
8
root@lxdevel:~#
Was mich aber wundert: die "normalen" UIN, ULG usw. funktionieren ja
problemlos...
Allerdings habe ich gesehen, dass diese ja von Hand umgedreht werden...
Was mich jetzt aber wundert: auf BIG ENDIAN Maschinen wäre doch der
int32_t auch schon in BIG ENDIAN, also warum dort nochmal umdrehen??
Egal wie - da im Crosscompiler weder _BYTE_ORDER_ noch
_ORDER_BID_ENDIAN_ definiert sind, greift das if und er dreht es bei
mir um. Zwei mögliche Änderungen würden das verhindern:
a) #if defined _BYTE_ORDER_ && (_BYTE_ORDER_ ==
_ORDER_BIG_ENDIAN_)
...
b) #if _BYTE_ORDER_ != _ORDER_LITTLE_ENDIAN_
...
Aber nochmal: ist das überhaupt notwendig, wenn man davon ausgeht dass
Integer in gleicher Reihenfolge wie Floats gespeichert werden?
Bzw. müsste man dann nicht eher "#if _BYTE_ORDER_ !=
__FLOAT_WORD_ORDER__" nehmen und wenn man ganz penibel sein möchte, auch
noch PDB ENDIAN berücksichtigen??
Hallo zusammen,
ich bin neu hier und bei meiner Recherche zum eBus auf Euer Forum bzw.
diesen Thread gestossen. Generell: Sehr interessante Infos und Themen!
Zurzeit beschäftige ich mich mit meiner Vaillant Heizung und deren
Einstellungsoptimierung. In diesem Zusammenhang kommt man natürlich
schnell an den Punkt, die Betriebsparameter aufzuzeichnen und
analysieren zu wollen. Da die Anlage da ja alles schon "weiß", macht es
also Sinn, sich diese Daten auch direkt vom eBus zu holen.
Ohne jetzt lange drum herum zu reden: Die Platine von Benedikt Patt ist
also genau das, was ich brauche - die Einzelproduktion ist aber
natürlich nicht sehr wirtschaftlich. Daher auch von meiner Seite die
Frage, ob noch eine fertig geätzte Platin zum Verkauf steht (das
Bestücken kann ich selbst übernehmen).
Vielen Dank für eine Rückmeldung.
Grüße,
Andreas
Helmut H. schrieb:> Ich habe noch genug Platinen, einfach 'ne PN an mich !
Soweit ich weiß, trifft o.g. Aussage noch zu. Und die Platinen sind top!
Irgendwie scheine ich hier jedoch (fast) der einzige zu sein, der kein
SSOP selbst bestücken kann :(
Aber... meine sind jetzt eh alle weg!
Genau, muß man scheinbar nach jeder 3. Eintragung von Beiträgen hier
kundtun....
Helmut hat noch genug, einfach 'ne PN an mich aber: als angemeldeter
User ;-)
Sven G. schrieb:> Aber nochmal: ist das überhaupt notwendig, wenn man davon ausgeht dass> Integer in gleicher Reihenfolge wie Floats gespeichert werden?> Bzw. müsste man dann nicht eher "#if _BYTE_ORDER_ !=> __FLOAT_WORD_ORDER__" nehmen und wenn man ganz penibel sein möchte, auch> noch PDB ENDIAN berücksichtigen??
ich baue gerade einen autoconf check dafür ein und dann im code die
entsprechende selektion für 1:1, umgedreht, oder selbst ausrechnen.
Helmut H. schrieb:> Genau, muß man scheinbar nach jeder 3. Eintragung von Beiträgen hier> kundtun....>> Helmut hat noch genug, einfach 'ne PN an mich aber: als angemeldeter> User ;-)
Kurze Rückmeldung von mir:
1.) Platinen sind angekommen: Danke für die prompte Lieferung an Helmut.
2.) ...zusammengebraten
3.) ...angestöpselt
4.) ...läuft!
Ich musst nicht mal am Trimmer drehen, die Busnachrichten wurden gleich
anstandslos gelesen. Ich kann also die Platine ebenfalls nur empfehlen,
super Teil!
John B. schrieb:> Sven G. schrieb:>> Aber nochmal: ist das überhaupt notwendig, wenn man davon ausgeht dass>> Integer in gleicher Reihenfolge wie Floats gespeichert werden?>> Bzw. müsste man dann nicht eher "#if _BYTE_ORDER_ !=>> __FLOAT_WORD_ORDER__" nehmen und wenn man ganz penibel sein möchte, auch>> noch PDB ENDIAN berücksichtigen??>> ich baue gerade einen autoconf check dafür ein und dann im code die> entsprechende selektion für 1:1, umgedreht, oder selbst ausrechnen.
So, jetzt könntest das mal auf Deiner raffinierten Maschine checken.
Hallo,
ich habe heute meine Vaillant ecoTEC plus VC 206/5-5 am ebus analysiert.
Leider ist es ein HW-Version, für die ich noch keine CSV gefunden habe:
MF=Vaillant;ID=BAI00;SW=0608;HW=5502
Zur HW7401 habe ich bis jetzt folgende Abweichungen gefunden:
PartloadHcKW d.00 Heizungsteillast 6C00
WPPostrunTime d.01 Pumpennachlaufzeit 6400
BlockTimeHcMax d.02 Maximale Brennersperrzeit 2100
Andreas
John B. schrieb:> So, jetzt könntest das mal auf Deiner raffinierten Maschine checken.
Raffiniert?? :D
Also als Theoretiker müsste ich infrage stellen, ob der Test beim
configure an der richtigen Stelle sitzt, wenn man cross-compiliert. Aber
da ich selbst derzeit nur mit little endian Geräten zu tun habe, stört
mich das jetzt nicht. Man könnte auch einfach behaupten, dass das
Aufgabe des Crosscompilers ist! :)
Es funktioniert jetzt jedenfalls mit EXP, so wie soll - vielen Dank!!
Sven G. schrieb:> John B. schrieb:>> So, jetzt könntest das mal auf Deiner raffinierten Maschine checken.>> Raffiniert?? :D> Also als Theoretiker müsste ich infrage stellen, ob der Test beim> configure an der richtigen Stelle sitzt, wenn man cross-compiliert. Aber> da ich selbst derzeit nur mit little endian Geräten zu tun habe, stört> mich das jetzt nicht. Man könnte auch einfach behaupten, dass das> Aufgabe des Crosscompilers ist! :)
im Falle von crosscompile wird alles selbst ausgerechnet.
Sven G. schrieb:> Es funktioniert jetzt jedenfalls mit EXP, so wie soll - vielen Dank!!
sehr schön, dann passts ja jetzt.
Björn C. schrieb:> Hallo,>> ich wollte noch einmal daran erinnern, dass bei mir noch 5 eBus-USB> Adapter liegen, die einen neuen Besitzer suchen.
Was möchtest du den dafür haben.
Gruß Stefan
Helmut H. schrieb:> enau, muß man scheinbar nach jeder 3. Eintragung von Beiträgen hier> kundtun....>> Helmut hat noch genug, einfach 'ne PN an mich aber: als angemeldeter> User ;-)
Hi Mädels und Jungs,
endlich habe ich es auch zusammengebracht, und kann ich schon meine Wolf
R12 5W Steuerung steuern.
Bei meinem Konfiguration, wo auf dem eBus nur noch einer Regler im
Wohnzimmer gehängt wurde, habe ich nur ein regelmäßiges MM (von Master
an Master) Telegramm identifiziert, sonst keine andere Art von
Kommunikation. Der Regler schickt dieses Telegramm mit seiner
(Soll)werte (+Temperatur) alle 1-2 Minuten an die Steuerung:
2016-02-27 22:44:59.130 [update info] update MM cmd:
3ff1080008e606cd1680008019
Mit dem angehängten Config-Datei konnte ich das auch entschlüsseln:
2016-02-29 06:02:37.150 [update notice] update Sollwerte Regler:
5.898;21.898;-;Heizbetrieb;25.500
Und sogar solche Telegramme selber senden, und damit meine Heizung
steuern, yeah! :-)
Nur etwa störend ist mir, dass die Rückmeldung von eBusd eher eine
Fehlermeldung (timeout) ist, und im Protokoll sowas steht:
2016-03-04 21:17:34.200 [bus info] send message:
3ff10800083306001780a08019
2016-03-04 21:17:34.469 [bus error] send to f1: ERR: read timeout, retry
2016-03-04 21:17:34.818 [bus error] send to f1: ERR: read timeout, retry
2016-03-04 21:17:35.169 [bus error] send to f1: ERR: read timeout, retry
2016-03-04 21:17:35.548 [bus error] send to f1: ERR: read timeout
2016-03-04 21:17:35.549 [main error] send message part 0: ERR: read
timeout
Ich nehme mal an, ebusd wartet auf einen Antwort, die R12 antwortet aber
tatsächlich gar nicht, nimmt trotzdem die gesendete Werte wahr.
Vielleicht kann ich es irgendwie im Config-Datei angeben, dass er keinen
Antwort warten soll? Oder ist es eh egal, wenn's schon funktioniert? :)
Hat jemand hier zufällig noch Erfahrungen mit der uraltem Wolf Steuerung
gemacht? Antwortet sie auf etwas überhaupt?
Grüße,
Adam
Adam Hollik schrieb:> Ich nehme mal an, ebusd wartet auf einen Antwort, die R12 antwortet aber> tatsächlich gar nicht, nimmt trotzdem die gesendete Werte wahr.
Hast Du das durch raw logging nachvollzogen?
Ich vermute eher, das Gerät antwortet nicht rechtzeitig.
Du kannst ebusd da auf höhere Timeout einstellen, indem Du ebusd mit
zusätzlichem Parameter z.B. "-receivetimeout=30000" startest.
> Vielleicht kann ich es irgendwie im Config-Datei angeben, dass er keinen> Antwort warten soll? Oder ist es eh egal, wenn's schon funktioniert? :)
Nein, das geht rein vom eBUS Protokoll her nicht.
VG John
Hey, Herr Meister John!
Danke für den Hinweise, und generell vielen-vielen Dank für das tolle
Programm! Super Arbeit, und noch dazu aktiv Support.. :-)
also, -receivetimeout=30000 hat mir geholfen, seitdem bekomme ich nur
mehr "done" zurück, super!
Aus Raw-Protokoll sehe ich schon, dass alle Bytes einzeln bestätigt
wird, und die letzte "00" dauert bei mir bis zu 30 millisec, welche
Verzögerung von den Standardeinstellungen anscheinend nicht toleriert
wird (ebusd 2.0.0ea7efc):
2016-03-13 21:14:03.071 [bus notice] >3e
2016-03-13 21:14:03.076 [bus notice] <3e
2016-03-13 21:14:03.093 [bus error] send to f1: ERR: read timeout, retry
[..]
2016-03-13 21:14:03.417 [bus notice] <3e
2016-03-13 21:14:03.433 [bus notice] <00
2016-03-13 21:14:03.434 [main info] write Setvalues Regulator: done
Jetzt knappt es aber, also Danke!
VG, Adam
Adam Hollik schrieb:> Danke für den Hinweise, und generell vielen-vielen Dank für das tolle> Programm! Super Arbeit, und noch dazu aktiv Support.. :-)
Danke für die Blumen! :-)
> also, -receivetimeout=30000 hat mir geholfen, seitdem bekomme ich nur> mehr "done" zurück, super!>> Aus Raw-Protokoll sehe ich schon, dass alle Bytes einzeln bestätigt> wird, und die letzte "00" dauert bei mir bis zu 30 millisec, welche> Verzögerung von den Standardeinstellungen anscheinend nicht toleriert> wird (ebusd 2.0.0ea7efc):
der eBUS Standard sieht für die Anwort regulär etwa 15ms vor. Deshalb
ist das auch so eingestellt. Wenn also eine spezielle Anlage andere
Werte benötigt, muss man mit den entsprechenden Aufrufparameter
arbeiten.
VG John
Ich habe folgende Geräte am eBus:
05;Vaillant;COM00;0217;3103
08;Vaillant;HMU00;0206;0403
15;Vaillant;70000;0110;2103
76;Vaillant;VWZ00;0206;0403
ec;Vaillant;70000;0110;2103
Leider finde ich mom. noch keine passenden CSV-Dateien.
Hat jemand schon welche dafür erstellt und kann diese hier
bereitstellen?
Wenn jemand weiß, ob bestehende bzw. verfügbare CSV-Dateien
funktionieren,
bitte ich um kurze Info, mit dem Hinweis wie ich diese einsetzen kann.
Vielen Dank!
Hallo, nachdem ich fast ein Jahr nichts mehr gemacht habe wollte ich
letzte Woche wieder einsteigen. Leider tut mein ebusd auf Ubuntu nicht
mehr so wie ich möchte. Hab bereits mehrere Updates probiert und komme
nicht weiter. Es scheitert bereits am Scan Befehl im Terminal.
Hier mal ein Log zum besseren Verständnis:
root@LIFEBOOK-E754:~/ebusd# ebusd -f
2016-03-26 15:06:06.956 [main notice] ebusd 2.0.513a89b started
2016-03-26 15:06:06.958 [main notice] found messages: 11 (0 conditional
on 0 conditions, 0 poll, 4 update)
2016-03-26 15:06:06.973 [bus notice] signal acquired
2016-03-26 15:06:13.034 [bus notice] max. symbols per second: 129
2016-03-26 15:11:20.011 [bus notice] max. symbols per second: 141
2016-03-26 15:11:26.006 [bus notice] max. symbols per second: 142
2016-03-26 15:11:28.034 [bus notice] max. symbols per second: 236
Eingabe über zweites Terminal ebusdctl
localhost: scan
empty
Ausgabe:
2016-03-26 15:16:57.973 [main error] scan: empty
localhost: state
signal acquired, 92 symbols/sec (277 max), 1 masters
localhost: raw
raw output enabled
Ausgabe:
2016-03-26 15:28:42.872 [bus notice] <80
2016-03-26 15:28:42.874 [bus notice] <78
2016-03-26 15:28:42.875 [bus notice] <1c
2016-03-26 15:28:42.875 [bus notice] <ff
..........
..........
localhost: raw
raw output disabled
Vor einem Jahr konnte ich noch r / w Kommandos geben
und hatte auch beim Scan ausgaben 08,15 usw.
Hatte die bekannten Verzeichnisse gelöscht und dann neu die 2.x über
https..... installiert.
Nachdem viele Fehler bei den Config Daten gekommen sind hab ich die
Unterordner Vailant u.s.w. erstmal in einen anderen Ordner verzogen.
Holt jetzt nur die Standard _templates.csv und nicht die aus dem Vailant
Ordner.
Was könnte da jetzt schief laufen? Nach zwei Tagen verliere ich schon
langsam wieder die Lust;-) Bin halt kein Linux Freak.
Freu mich auf jede Hilfe. Danke
Hallo Horst,
das Problem hatte ich auch schon mal, hier sind die Symptome etwas
irreführend. Vermutlich liegt es an FHEM. Stop mal den FHEM Service und
lass den eBus Damon alleine laufen, dann funktioniert es wahrscheinlich.
Falls die Daten nicht korrekt reinkommen, kalibriere den Adapter noch
mal.
Wenn es dann funktionier: Reaktivier die automatische USB Erkennung in
der FHEM config und starte den Dienst wieder. Dann sollte es auch mit
FHEM wieder funktionieren.
Grüße,
Blademan
Blademan schrieb:> Hallo Horst,>> das Problem hatte ich auch schon mal, hier sind die Symptome etwas> irreführend. Vermutlich liegt es an FHEM. Stop mal den FHEM Service und> lass den eBus Damon alleine laufen, dann funktioniert es wahrscheinlich.> Falls die Daten nicht korrekt reinkommen, kalibriere den Adapter noch> mal.>> Wenn es dann funktionier: Reaktivier die automatische USB Erkennung in> der FHEM config und starte den Dienst wieder. Dann sollte es auch mit> FHEM wieder funktionieren.>> Grüße,> Blademan
Meinte natürlich "deaktivieren" der autom. USB-Erkennung....
Danke für den Tip!
Alsheimer lässt grüßen! An FHEM hab ich gar nicht mehr gedacht.
Könnte sein, dass dieser automatisch startet. Hab vor einem Jahr auch
mit FHEM gespielt. Werde es später mal probieren. Wie stoppt man den
Dienst FHEM.
Also nochmal Danke für den Tip
FHEM war zwar schon deinstalliert aber unter /var/lib/dpkg gibt es eine
Datei namens "status". In dieser Datei habe ich nun nach "fhem" gesucht
und den gesamten Zeilenblock gelöscht.
Jetzt funktioniert alles wieder wie im letzten Jahr.
Mal sehen wie ich nun weiter mache.
Es gibt hier im Forum ja schon einige schöne Abfrage- und
Steuerprogramme.
Leider noch nichts was ich einfach mal so nachbauen könnte.
Hab auch nur eine kleine Heizung ohne Solar usw.
Möchte eigentlich nur Warmwasser "ein" und "aus" schalten sowie den
Zustand loggen.
Ev.hat ja jemand im Forum einen Tip wo man sich nicht Wochenlang
einlesen muss.
Gruß aus Franken
Alex schrieb:> Ich habe folgende Geräte am eBus:>> 05;Vaillant;COM00;0217;3103> 08;Vaillant;HMU00;0206;0403> 15;Vaillant;70000;0110;2103> 76;Vaillant;VWZ00;0206;0403> ec;Vaillant;70000;0110;2103>> Leider finde ich mom. noch keine passenden CSV-Dateien.> Hat jemand schon welche dafür erstellt und kann diese hier> bereitstellen?>> Wenn jemand weiß, ob bestehende bzw. verfügbare CSV-Dateien> funktionieren,> bitte ich um kurze Info, mit dem Hinweis wie ich diese einsetzen kann.>> Vielen Dank!
Hallo Alex:
Wenn du ebusd 2.xx hast dann spiele diese Configs ein
svn --force export
https://github.com/john30/ebusd-configuration/trunk/ebusd-2.x.x/de
/etc/ebusd/
Danach alles außer 05, 08, 15, 76 und ec im Ordner /etc/ebusd/vaillant
löschen.
So steht es auch im ebusd WIKI
Hallo zusammen,
ich programmiere gerade an einem STM32F103 um die Parameter meiner
Vaillant Therme VC 146/5-5 zu loggen bzw. die Parameter zu ändern. Die
mir wichtigen Parameter sollen dann per CAN in meinen Hausbus gesendet
werden. Die Kommunikation mit der Therme klappt und Dank den
ebusd-Entwicklern und deren gesammelter cvs-Dateien bekomme ich folgende
Werte:
Vorlauf_soll
Vorlauf
Ruecklauf
Aussen-Temperatur
Boiler-Temperatur
Geblaese soll d.33
Geblaese ist d.34
Modulation soll
Pumpe ist d.13
Wasserdurchlauf d.29
Wasserdruck
das reicht mir erst mal. Um aber aktiv einzugreifen müssen die Befehle
dazu an den Regler (vcr 700) geschickt werden. Das klappt für die
Wunschtemperaturen und die Heizkurve auch schon Dank der Informationen
weiter oben. Hat jemand Ahnung wie man in der vcr 700 die Zeiten
ausliest oder verändert? Weiter oben wurde die Ferienzeit genannt. Da
ich dieses Internetmodul nicht habe kann ich auch nichts mitloggen.
Deshalb wäre ich euch sehr verbunden, wenn jemand die Möglichkeit hätte
dazu mal ein paar Bytes hier einzustellen.
Alex schrieb:> Ich habe folgende Geräte am eBus:>> 05;Vaillant;COM00;0217;3103> 08;Vaillant;HMU00;0206;0403> 15;Vaillant;70000;0110;2103> 76;Vaillant;VWZ00;0206;0403> ec;Vaillant;70000;0110;2103
Ich dachte, hierauf schonmal geantwortet zu haben...
Also @Alex und @temp:
Schickt mir eine PN und ich sende euch den Dropbox-Link zur aktuellen
15.700.csv - ist noch nicht ganz vollständig, aber Ferienzeit,
Zeitprogramme usw. sind schon drin.
Danke an Sven für den Link auf die csv-Datei. Das mit den Zeiten klappt.
Andreas S. schrieb:> Hallo,> ich habe heute meine Vaillant ecoTEC plus VC 206/5-5 am ebus analysiert.> Leider ist es ein HW-Version, für die ich noch keine CSV gefunden habe:> MF=Vaillant;ID=BAI00;SW=0608;HW=5502>> Zur HW7401 habe ich bis jetzt folgende Abweichungen gefunden:>> PartloadHcKW d.00 Heizungsteillast 6C00> WPPostrunTime d.01 Pumpennachlaufzeit 6400> BlockTimeHcMax d.02 Maximale Brennersperrzeit 2100
Hierzu habe ich auch eine Frage. Die Codes passen auch bei mir.
Allerdings macht es z.B. bei der Heizungsteillast keinen Unterschied ob
die auf auto oder 14kW(max) steht. Kleinere Wert stimmen. Das kriege ich
z.B.:
ff08b509030d6c00e300010e9500
|
14 fuer 14kW
Der Versuche das auf 0d (13) zu ändern klappt nicht.
ff08b509040e6c000de500000000
Hat jemand eine Idee?. Oder anders gefragt, wie kriegt ihr das raus wenn
niemand am Bus ist der sowas versendet. Man kann ja nicht blind drauf
los probieren.
Mittlerweile habe ich rausgefunden, dass wohl vrDialog das Mittel der
Wahl ist um Packete zu analysieren. Weiss jemand ob die aktuelle Version
davon eine VC 146/5-5 unterstützt?
Hallo zusammen,
bin seit einigen Wochen Besitzer einer Vaillant flexoTherm VWF 87/4 und
versuche, dem Teil die interessantesten Daten für meine Visu zu
entlocken. Ich verwende ebusd in der aktuellen Version. Folgende
Konfiguration:
05;Vaillant;COM00;0306;3103
08;Vaillant;HMU00;0211;0403
15;Vaillant;70000;0209;4103
52;Vaillant;VR_70;0109;2903
76;Vaillant;VWZ00;0211;0403
ec;Vaillant;70000;0209;4103
Da es bei den ebusd-Config-Files wohl noch nichts aktuelles zu diesen
Komponenten gibt, wollte ich mal fragen, ob hier schon jemand dem ebus
mehr Informationen entlockt hat?
Bisher konnte ich Status01, Status02, Außentemperatur auslesen.
Interessant wäre für mich noch Umweltertrag, Energieverbrauch Heizen und
Warmwasser etc.
Gruß,
Jörg
Hat eigentlich schon jemand angepasste CSV-Dateien für den HMU00 oder
den VR900? Mit der multiMatic-App kann man ja nicht so wirklich viel
anfangen;-)
@Alex:
Du scheinst ja eine vergleichbare Konfiguration wie meine zu haben.
Welche CSV-Dateien verwendest Du denn für den 05er, 08er und den 76er?
Gruß
Jörg
Hallo, ich habe schon vor längerem eine eBus Platine aufgebaut welche
auch unter UBUNTU sauber läuft. Leider aber nur auf der Kommando Ebene.
Der nächste Schritt sollte nun ein Raspi 3B sein welcher auch schon
vorliegt. Leider komme ich aus Zeitmangel einfach nicht dazu das Projekt
fertig zu stellen. Es ist zum Haare raufen wenn ich noch welche hätte;-)
Meine Bitte wäre ob Ihr mir nicht etwas auf die Sprünge helfen könnt.
Ich denke da an eine fertige Mini SD Karte. Würde demjenigen z.B. zwei
zusenden und Ihr schickt dann eine wieder zurück.
Ich hab eine Vaillant VSC 196-3 150 mit Calormatic 430
Mein Ziel war es diese mit dem Android Handy oder Tablet zu steuern.
Ein aktueller Zustand der Anlage sowie Heißwasser mal außerhalb der Zeit
einzuschalten würde mir schon genügen. Denke dann käme ich anhand
vorhandener Daten auf denen ich aufsetzen könnte wieder selbst weiter.
Außer dem Raspi 3B wäre auch noch ein QNAP150 sowie eine Fritzbox 7490
vorhanden.
Liebe Grüße aus Fürth
Horst
Hallo,
zum einen habe ich momentan wieder zwei eBus-Adapter zu verkaufen.
Bei Interesse bitte einfach per Nachricht bei mir melden!
Außerdem habe ich ein Problem mit einem ebusd-Kommando bzw. dem
Rückgabewert.
Es geht um folgende Abfrage aus der Datei 15.sdr_p.csv
wi,,CollPumpHRuntime,Laufzeit Solarpumpe,,,,"1F00",,,UIN
Besonderheit: in der Zelle rechts davon steht: UIN,,,
Das ist bei den anderen Abfragen nicht so.
eBusd liefert folgende Ausgabe:
2679;0
Um das Ergebnis mit VWmon zu verarbeiten, muss der hintere Wert
abgetrennt werden!
Im Normalfall würde man dafür ja ein "temp" oder ähnliches hinter die
Abfrage schreiben:
read CollPumpHRuntime hours zum Beispiel.
Allerdings finde ich nicht das richtige Attribut, um die Ausgabe zu
spalten.
Wer kann da helfen?
Gruß Björn
Björn C. schrieb:> Außerdem habe ich ein Problem mit einem ebusd-Kommando bzw. dem> Rückgabewert.> Es geht um folgende Abfrage aus der Datei 15.sdr_p.csv> wi,,CollPumpHRuntime,Laufzeit Solarpumpe,,,,"1F00",,,UIN>> Besonderheit: in der Zelle rechts davon steht: UIN,,,> Das ist bei den anderen Abfragen nicht so.>> eBusd liefert folgende Ausgabe:> 2679;0>> Um das Ergebnis mit VWmon zu verarbeiten, muss der hintere Wert> abgetrennt werden!> Im Normalfall würde man dafür ja ein "temp" oder ähnliches hinter die> Abfrage schreiben:> read CollPumpHRuntime hours zum Beispiel.> Allerdings finde ich nicht das richtige Attribut, um die Ausgabe zu> spalten.
Du kannst einfach den Index-basierten Abruf machen:
read CollPumpHRuntime .0
VG John
Horst S. schrieb:> Hallo, ich habe schon vor längerem eine eBus Platine aufgebaut welche> auch unter UBUNTU sauber läuft. Leider aber nur auf der Kommando Ebene.> Der nächste Schritt sollte nun ein Raspi 3B sein welcher auch schon> vorliegt. Leider komme ich aus Zeitmangel einfach nicht dazu das Projekt> fertig zu stellen. Es ist zum Haare raufen wenn ich noch welche hätte;-)> Meine Bitte wäre ob Ihr mir nicht etwas auf die Sprünge helfen könnt.> Ich denke da an eine fertige Mini SD Karte. Würde demjenigen z.B. zwei> zusenden und Ihr schickt dann eine wieder zurück.
Was soll denn genau drauf sein auf der SD, also z.B. welche Distribution
etc.?
Ich würde das schon machen, aber ich hab nur einen älteren RPi, d.h. um
sicher zu gehen, dass alles funktioniert, müsstest Du wahrscheinlich den
RPi mit schicken.
VG John
John B. schrieb:> Horst S. schrieb:>> Hallo, ich habe schon vor längerem eine eBus Platine aufgebaut welche>> auch unter UBUNTU sauber läuft. Leider aber nur auf der Kommando Ebene.>> Der nächste Schritt sollte nun ein Raspi 3B sein welcher auch schon>> vorliegt. Leider komme ich aus Zeitmangel einfach nicht dazu das Projekt>> fertig zu stellen. Es ist zum Haare raufen wenn ich noch welche hätte;-)>> Meine Bitte wäre ob Ihr mir nicht etwas auf die Sprünge helfen könnt.>> Ich denke da an eine fertige Mini SD Karte. Würde demjenigen z.B. zwei>> zusenden und Ihr schickt dann eine wieder zurück.>> Was soll denn genau drauf sein auf der SD, also z.B. welche Distribution> etc.?> Ich würde das schon machen, aber ich hab nur einen älteren RPi, d.h. um> sicher zu gehen, dass alles funktioniert, müsstest Du wahrscheinlich den> RPi mit schicken.>> VG John
Hallo John, ich bin für alles dankbar. Welche Linux Version da drauf
kommt wäre egal da ich den Raspi erstmal nur für den EBUS verwenden
möchte. Gerne kann ich dir den auch mitsenden wenn der Aufwand für dich
dadurch nicht zu groß wird. Hast du bei dir auch einen PHP Server schon
mit drauf um das ganze dann über einen Browser zu steuern oder wie
machst du das? Freut mich natürlich, dass sich der Chef selbs meiner
annimmt.
Gruß Horst
Horst S. schrieb:> Welche Linux Version da drauf> kommt wäre egal
Ich kann über gute Ergebnisse (einfaches Einrichten usw.) mit DietPi
berichten.
Läuft auf einem älteren Raspberry Pi B+ (512kB-Ram) seit ca. 10 Monaten
"lautlos" (nur der ev. ebusd-(Fehler)-Log biss/beißt sich (bei mir...)
etwas mit dem DietPi-Konzept, aber da sind ja seit 10 Monaten 'eh keine
Fehlermeldungen mehr... [Mein Dank geht da an John B. + allen weiteren
"Zeit"-Gebern der ebusd-Entwicklung])
:-)
Hallo zusammen,
hat noch jemand eine Platine oder einen aufgebauten eBus-USB-Adapter zu
verkaufen? Platine wäre mir zur Kostenoptimierung lieber, aber bei nem
fairen Preis wäre ich auch bereit einen fertigen Adapter zu kaufen.
Die Angebote aus dem Thread-Verlauf habe ich schon angefragt und leider
ist alles vergriffen.
Bitte direkt per PN, da ich nicht "alla Dooch" hier rein schaue.
Danke und Gruß aus dem Bamberger Land.
Michael
Kurze RÜckmeldung meinerseits: Der eBus-Adapter ist aufgebaut und
funktioniert. Danke an Helmut H. für die Platine und danke für die
Informationen in diesem Thread!
Unsere Vaillant VWS 62/3 führt einen umfangreichen Monolog auf dem Bus.
Leider stelle ich aber fest, dass die Anzahl an nützlichen Informationen
aber doch recht spärlich ist. Ich konnte zwar z.B. die "outsidetemp"
finden und irgendwas mit "...Flow...", aber viel mehr nützliche
Informationen sind irgendwie nicht dabei. Interessieren würde mich
nämlich auch die Temperatur im Warmwasserboiler.
Das Kommando "ebusctl info" zeigt folgendes an:
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 59
masters: 3
messages: 633
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201",
loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0370;HW=6901",
loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201",
loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201",
loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201",
loaded "vaillant/50.ehp.mc.csv"
Mir fehlt durch den doch recht frischen Kontakt mit ebusd und dem
USB-Koppler die Erfahrung bzw. das Gefühl, ob hier alles normal werkelt.
Jedenfalls sind in "/var/log/ebusd.log" schonmal keine Fehler enthalten.
Vielleicht kann ja jemand mit Erfahrung sagen, ob das geschriebene
plausibel aussieht und wo ich evtl. die Warmwassertemperatur finde.
Vielen Dank schon mal dafür!
Gruß Michael
M. W. schrieb:> Mir fehlt durch den doch recht frischen Kontakt mit ebusd und dem> USB-Koppler die Erfahrung bzw. das Gefühl, ob hier alles normal werkelt.
Das sieht schonmal alles ganz gut aus. Jetzt musst Du halt noch wissen,
was Du eigentlich wissen willst. Dann kannst Du gezielt danach schauen.
Bspw. lässt sich die Speichertemperatur mit folgendem Kommando auslesen:
1
ebuctl read HwcTemp
Du kannst mit folgendem Befehl nachschauen, was Du alles von der Anlage
abfragen kannst:
1
ebuctl find
Dann bekommst Du eine Liste, z.B. wie folgt:
1
broadcast datetime = ...
2
...
3
ehp ActualEnvironmentPower = 0
Der erste Wert ist dabei das Gerät, aus dem gelesen wird (also z.B.
"ehp"). Das wird beim "read" Befehl nach "-c" angegeben ("c" für
"circuit").
Der zweite Wert ist der Name der Nachricht, also z.B.
"ActualEnvironmentPower".
Somit kannst Du also mit:
1
ebuctl read -c ehp ActualEnvironmentPower
Die aktuelle Leistung abrufen, die aus der Umwelt gewonnen wird. Als
Antwort kommt dann z.B. "0", wenn die WP gerade nicht läuft.
VG John
Hallo, ich bräuchte mal eure Hilfe.
Nachdem mein Raspi nun läuft und ich auch schon viel damit gespielt habe
habe ich mal FHEM installiert.
Ein Prima Tool welches alles dafür alleine Installiert gab es im Fhem
Wiki
Leider war es nicht aktuell und somit bin ich wieder bei ebusd 2.0
gelandet.
Nun habe ich ebusd nochmals installiert und bei der Abfrage ebusd --v
ebusd 2.1.acae7c3 erhalten.
Danach wollte die Config Daten mit sudo dpkg -i --force-overwrite
ebusd-configuration-2.1.*deb installieren.
Nun habe ich folgende Antwort erhalten:
Vorbereitung zum Entpacken von
ebusd-configuration-2.1.b143f39-de_all.deb
... Entpacken von ebusd-configuration (2.1.b143f39-de) über
(2.1.b143f39-de) ... dpkg: Abhängigkeitsprobleme verhindern
Konfiguration von ebusd-configuration: ebusd-configuration hängt ab von
ebusd (>= 2.1)aber: Version von ebusd auf dem System ist 2.0. dpkg:
Fehler beim Bearbeiten des Paketes ebusd-configuration (--install):
Die Config Daten wurden zwar kopiert und neu angelegt aber ich bin mir
nun nicht sicher ob das passt.
Wenn ich FHEM starte und über den Browser abfrage habe ich nur ganz
wenig Werte die angezeigt werden und z.B. die Wochenprogramme werden gar
nicht angezeigt.
Kann das an der Deutschen ebusd Config liegen oder nutzt FHEM eine
eigene Config Datei? Habt Ihr da eine Idee. Was kann ich tun um zu sehen
ob der eBusd nun richtig installiert ist?
Wenn Ihr mir mitteilt welche Befehle und logs ich Posten soll würde ich
das gerne tun.
PS: Hallo John, zum Glück hatte ich dir den Raspi nicht gesendet, der
war kaputt und ich musste Ihn umtauschen. Hab jetzt Raspian drauf und es
geht auch ganz gut vorwärts. Ich denke die meisten Probleme kommen von
veralteten Infos aus dem Netz da diese sich noch auf V1.1 Befehle und
Englische Configs beziehen.
Gruß Horst
Horst S. schrieb:> Nun habe ich ebusd nochmals installiert und bei der Abfrage ebusd --v> ebusd 2.1.acae7c3 erhalten.
Also hast Du ebusd selbst kompiliert und nicht von einem Release Package
installiert.
> Danach wollte die Config Daten mit sudo dpkg -i --force-overwrite> ebusd-configuration-2.1.*deb installieren.
Durch das eigene Kompilat fehlt natürlich die Abhängigkeit. Ich würde
Dir dann empfehlen, die CSVs auch direkt via git zu nehmen anstelle
eines releases.
> Die Config Daten wurden zwar kopiert und neu angelegt aber ich bin mir> nun nicht sicher ob das passt.
Im Prinzip passt es auch so.
> Wenn ich FHEM starte und über den Browser abfrage habe ich nur ganz> wenig Werte die angezeigt werden und z.B. die Wochenprogramme werden gar> nicht angezeigt.
Welches Modul in fhem nutzt Du denn für ebusd?
VG John
Ich hoffe es ist ok, wenn ich hier meine Frage poste ...
Hab eine Brink Renovent Excellent 300 KWL, die eine eBus Schnittstelle
besitzt.
Jetzt hab ich mir mal die oben beschriebene Platine zusammengebastelt
und an meinen Raspberry Pi gehängt.
So wie es aussieht gibt es zu meinem Gerät aber noch keine
Konfigurationsdatei um Daten abzufragen bzw. Einstellungen zu ändern.
Was ich bisher rausfinden konnte:
pi@raspberrypi:~/ebusd $ ebusd -f -c /tmp --logareas bus --loglevel info
-d /dev/ttyUSB1
2016-12-04 20:56:19.799 [bus notice] signal acquired
2016-12-04 20:56:21.141 [bus notice] new master 37, master count 2
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.3.b4a596d
signal: acquired
symbol rate: 21
reconnects: 0
masters: 2
messages: 1
conditional: 0
poll: 0
update: 0
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 37: master #18
address 3c: slave #18, scanned "MF=ENCON;ID= ;SW=-;HW=-"
2016-12-04 21:17:21.519 [bus info] scan 3c cmd: 313c070400
2016-12-04 21:17:21.624 [bus notice] scan 3c completed (0 slaves left)
2016-12-04 21:17:21.625 [bus notice] scan 3c: ;ENCON; ;-;-
2016-12-04 21:17:21.625 [bus notice] scan finished
pi@raspberrypi:~ $ ebusctl scan result
3c;ENCON; ;-;-
pi@raspberrypi:~ $ ebusctl grab result
37fe07040a400816002102ffffffff = 2
37fefe010a45303030202020202020 = 2
Kann mir vielleicht jemand einen Tipp geben wie ich da jetzt am besten
weitermache um an ein funktionierendes Config-File zu bekommen?!
Danke schon mal und Grüße,
Daniel.
Daniel S. schrieb:> Kann mir vielleicht jemand einen Tipp geben wie ich da jetzt am besten> weitermache um an ein funktionierendes Config-File zu bekommen?!
das ist nicht ganz trivial. Am besten wäre es, wenn am Bus noch ein
Teilnehmer des Herstellers hängen würde, idealerweise mit Anzeige, so
dass man die angezeigten Werte bzw. durchgeführten Änderungen am Bus
mitschneiden kann.
Andernfalls ist es relativ aussichtlos, es sei denn das Gerät schickt
alle Daten von sich auf den Bus. Dann würden diese im grab result nach
und nach auftauchen.
Hallo Daniel,
den Weg den John beschreibt, habe ich bei mir auch durchgeführt. Ich hab
ja ein Bedienmodul, was zyklisch Nachrichten auf den Bus sendet.
Ansonsten ist die KWL außer Broadcasts unaufgefordert stumm. Das sieht
man ja an deinem grab result. Hast Du etwas mit meiner CSV-Datei
erreichen können?
@John: Mein Bedienmodul scheint nur eine Masteradresse und keine
Slave-Adresse zu haben. Im Log sehe ich dazu ein Timeout. Ich glaube das
ist dann wohl auch nicht EBUS-Standard. Damit entfällt dann auch wohl
leider die Möglichkeit das Bedienmodul selbst auch zu steuern:
localhost: info
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 22
masters: 3
messages: 84
conditional: 0
poll: 0
update: 4
address 01: master #6
address 31: master #8, ebusd
address 36: slave #8
address 37: master #18
address 3c: slave #18, scanned "MF=ENCON;ID= ;SW=-;HW=-"
im Log:
--- schnipp ---
2016-12-10 08:45:01.889 [bus notice] new master 01, master count 2
2016-12-10 08:45:01.935 [bus debug] ERR: SYN received during receive
command ACK, switching to ready
2016-12-10 08:45:02.023 [bus notice] new master 37, master count 3
2016-12-10 08:45:05.023 [bus info] send message: 31fe070400
2016-12-10 08:45:05.041 [bus debug] switching from ready to send command
2016-12-10 08:45:05.076 [bus debug] notify request: done
2016-12-10 08:45:05.076 [bus debug] read res:
2016-12-10 08:45:05.076 [bus debug] switching from send command to send
SYN
2016-12-10 08:45:05.077 [bus info] send message: 3106070400
2016-12-10 08:45:05.136 [bus debug] switching from ready to send command
2016-12-10 08:45:05.171 [bus debug] switching from send command to
receive command ACK
2016-12-10 08:45:05.219 [bus debug] notify request: ERR: SYN received
2016-12-10 08:45:05.219 [bus debug] ERR: SYN received during receive
command ACK, switching to ready
2016-12-10 08:45:05.219 [bus error] send to 06: ERR: read timeout, retry
--- schnipp ----
@Daniel: Es besteht die Möglichkeit bei Brink das ServiceTool
runterzuladen. Interessanterweise wie in meinem alten Beitrag
geschrieben, funktioniert das auch mit dem selbstgebauten EBUS-Adapter,
das originale Servicekabel kostet nämlich um die 300 Euro. Hiermit
kannst Du dann auch mit einer Funktion des ServiceTools die
Busnachrichten mitloggen.
Und ja, da das Tool .NET basierend ist und nicht binär ist, besteht auch
grundsätzlich die Möglichkeit des Reverse Engineerings.
Grüße
Patrick
Patrick K. schrieb:> @John: Mein Bedienmodul scheint nur eine Masteradresse und keine> Slave-Adresse zu haben. Im Log sehe ich dazu ein Timeout. Ich glaube das> ist dann wohl auch nicht EBUS-Standard. Damit entfällt dann auch wohl> leider die Möglichkeit das Bedienmodul selbst auch zu steuern:
Das Bedienmodul ist auf Master Adresse 01 nehme ich an?
> 2016-12-10 08:45:05.219 [bus error] send to 06: ERR: read timeout, retry
tja, das kann schon sein. Du könntest mit den Timeout Aufrufparametern
an ebusd etwas spielen, aber es sieht eher so aus, als würde das nichts
bringen.
VG John
John B. schrieb:> Das Bedienmodul ist auf Master Adresse 01 nehme ich an?>
korrekt.
>> 2016-12-10 08:45:05.219 [bus error] send to 06: ERR: read timeout, retry>> tja, das kann schon sein. Du könntest mit den Timeout Aufrufparametern> an ebusd etwas spielen, aber es sieht eher so aus, als würde das nichts> bringen.>
hatte schon --receivetimeout=99999 gesetzt. Dann ist das wohl
aussichtlos und das Bedienmodul ist auf gut Deutsch "strunzdumm". Dazu
kommt, dass dieses alle 30 Sekunden die Lüftungsstufe neu zur KWL
schreibt, nicht nur bei Änderungen.
Wenn ich die KWL also selber mal steuern will, muss ich entweder das
Bedienmodul außer Betrieb nehmen, oder selber öfters wie alle 30
Sekunden auf den Bus schreiben (Holzhammermethode).
An dieser Stelle John möchte ich mal ein Riesenlob und Riesen Dank für
deine geleistete Arbeit an ebusd aussprechen :-).
Gruß
Patrick
Patrick K. schrieb:> hatte schon --receivetimeout=99999 gesetzt. Dann ist das wohl> aussichtlos und das Bedienmodul ist auf gut Deutsch "strunzdumm". Dazu> kommt, dass dieses alle 30 Sekunden die Lüftungsstufe neu zur KWL> schreibt, nicht nur bei Änderungen.>> Wenn ich die KWL also selber mal steuern will, muss ich entweder das> Bedienmodul außer Betrieb nehmen, oder selber öfters wie alle 30> Sekunden auf den Bus schreiben (Holzhammermethode).
Tja, sieht das ganz danach aus. Hast Du noch mehr Komponenten am Bus
oder ist die KWL das einzige Gerät, das gesteuert wird?
Ich frage deshalb, weil man das Gerät theoretisch separieren könnte und
über einen eigenen Bus die Steuerung exclusiv mit ebusd übernehmen.
Oder Du findest einen Weg im Bedienmodul die Ansteuerung von KWL
abzuschalten.
> An dieser Stelle John möchte ich mal ein Riesenlob und Riesen Dank für> deine geleistete Arbeit an ebusd aussprechen :-).
Vielen Dank! Gern geschehen :-)
John B. schrieb:>> Tja, sieht das ganz danach aus. Hast Du noch mehr Komponenten am Bus> oder ist die KWL das einzige Gerät, das gesteuert wird?> Ich frage deshalb, weil man das Gerät theoretisch separieren könnte und> über einen eigenen Bus die Steuerung exclusiv mit ebusd übernehmen.> Oder Du findest einen Weg im Bedienmodul die Ansteuerung von KWL> abzuschalten.>
Die KWL ist das einzige Gerät was gesteuert wird. Der Bus besteht bei
mir nur aus einer einzigen KWL und dem Bedienmodul. Der Hersteller sieht
grundsätzlich noch vor, dass Gerät mit einem mechanischen Stufenschalter
schaltbar zu machen, welches dann über RJ12 direkt am Gerät
angeschlossen wird. In einer Plus-Version des Modells (ich habe nur
Basic) gibts es wohl auch noch einen 0-10V Steuer-Eingang. Beide sind
dann wohl höher priorisiert als die eingestellt Stufe über EBUS. Zudem
können mehrere KWLs als Slave definiert werden, also parallel geschaltet
zu einem Bedienmodul. Andere KWL-Modelle des Herstellers, ich glaube
auch das von Sven (Renovent Excellent) besitzen einen openTherm-Eingang.
Das ist bei mir aber nicht der Fall.
Was meinst Du mit separieren. Bräuchte die KWL dann nicht 2
Ebus-Eingänge?
Patrick K. schrieb:> Die KWL ist das einzige Gerät was gesteuert wird. Der Bus besteht bei> mir nur aus einer einzigen KWL und dem Bedienmodul.
Okay, in dem Fall könntest Du ja evtl. das bedienmodul einfach
abklemmen, oder? Also das hängt doch am eBUS dran, oder nicht?
John B. schrieb:> Patrick K. schrieb:>> Die KWL ist das einzige Gerät was gesteuert wird. Der Bus besteht bei>> mir nur aus einer einzigen KWL und dem Bedienmodul.>> Okay, in dem Fall könntest Du ja evtl. das bedienmodul einfach> abklemmen, oder? Also das hängt doch am eBUS dran, oder nicht?
Richtig. Das hatte ich ja oben aufgeführt. Ich bin halt von meiner
Vaillant auromatic 620/3 Steuerung verwöhnt, da geht das ja ganz locker
parallel.
Grüße
Patrick
Patrick K. schrieb:> Richtig. Das hatte ich ja oben aufgeführt. Ich bin halt von meiner> Vaillant auromatic 620/3 Steuerung verwöhnt, da geht das ja ganz locker> parallel.
naja, wenn in diesem Fall die Steuerung so unintelligent ist, hilft wohl
nichts...
VG John
Hallo, ich mal wieder. Möchte die Weihnachtszeit nutzen und schauen ob
ich wieder etwas weiter mit ebusd und FHEM komme. Als Anfänger unter
Linux ziemlich schwierig wie Ihr wisst. Hab ja mittlerweile auf einem
Raspi ebusd, perl und FHEM installiert. Leider passen die dazu im
Internet gefundenen Infos nicht zusammen. Ich würde euch daher die
nächste Zeit wahrscheinlich immer wieder mal belästigen.
1.) Da mein Raspi nun mit FHEM hochfährt kann ich den ebusd -f nicht
mehr ausführen da die ttyUSB0 ja schon vom FHEM belegt ist. Leider ist
das auch so wenn ich FHEM stoppe. Wie bekommt man ttyUSB0 wieder frei
für den ebusd?
2.) Die im Netz gefundene Installation für FHEM funktioniert für einige
Befehle wie Vorlauf, Rücklauf, Heizkurve schon. Für die meisten Befehle
werden aber Errors angezeigt. Ich hab eine Colormatic 430 und ich denke
in FHEM passt weder meine ebusd Version noch die Daten zusammen. Ev.
könnt Ihr mir ja mitteilen was ich euch als Hilfe senden könnte.
Ev. hat ja schon jemand was passendes für mich und ich müsste nur noch
bestimmte Daten austauschen. Im voraus schon mal vielen Dank.
Horst
Hab den ttyUSB0 wieder freibekommen indem ich den Service FHEM und eBusd
beendet habe (sudo service fhem stop). Da lacht jetzt sicher jeder Linux
Nutzer drüber;-)
Hätte hier noch einen Fehler aus meiner VSC 196/3-150
Was könnte das sein?
2016-12-30 17:31:23.162 [update notice] unknown BC cmd:
10feb516080025311730120516
2016-12-30 17:31:23.415 [update notice] unknown MS cmd: 1008b512020000 /
00
2016-12-30 17:32:41.915 [update notice] unknown BC cmd: 10feb51603011002
2016-12-30 17:33:02.392 [update notice] unknown BC cmd: 10feb505020400
2016-12-30 17:33:20.334 [update notice] unknown BC cmd:
10feb516080022331730120516
2016-12-30 17:33:20.591 [update notice] unknown MS cmd: 1008b512020000 /
00
2016-12-30 17:33:40.492 [update notice] unknown BC cmd: 10feb51603011002
.......
2016-12-30 17:58:12.624 [update notice] unknown BC cmd:
10feb516080014581730120516
2016-12-30 17:58:12.885 [update notice] unknown MS cmd: 1008b512020000 /
00
2016-12-30 17:59:01.238 [update notice] unknown BC cmd: 10feb505020400
2016-12-30 17:59:20.951 [update notice] unknown BC cmd:
10feb516080022591730120516
2016-12-30 17:59:21.207 [update notice] unknown MS cmd: 1008b512020000 /
00
2016-12-30 17:59:40.948 [update notice] unknown BC cmd: 10feb51603015001
2016-12-30 18:00:01.607 [update notice] unknown BC cmd: 10feb505020400
........
Und hier noch die ersten Meldungen nach dem ebusd -f nach dem Update auf
die neueste Software und Config-Files:
2016-12-30 18:04:06.521 [main notice] ebusd 2.4.79708d2 started
2016-12-30 18:04:06.551 [bus notice] signal acquired
2016-12-30 18:04:06.618 [main error] error reading config files: ERR:
duplicate entry, last error: /etc/ebusd/vaillant/15.392.csv:9
2016-12-30 18:04:06.618 [main error] error resolving conditions: ERR:
element not found, last error: condition scan id: message not found,
condition scan id: message not found, condition scan id: message not
found, condition scan id: message not found, condition scan id: message
not found, condition scan id: message not found, condition scan id:
message not found, condition scan id: message not found, condition scan
id: message not found, condition scan id: message not found, condition
scan id: message not found, condition scan id: message not found,
condition scan id: message not found, condition scan id: message not
found
2016-12-30 18:04:06.756 [bus notice] new master 03, master count 2
2016-12-30 18:04:06.765 [main error] error executing instructions: ERR:
duplicate entry, last error: , error loading
"/etc/ebusd/vaillant/bai.308523.inc" for "08.bai": ERR: duplicate entry,
included "/etc/ebusd/vaillant/errors.inc" for "08.ehp", included
"/etc/ebusd/vaillant/hcmode.inc" for "08.ehp", included
"/etc/ebusd/vaillant/hwcmode.inc" for "25.hwc", included
"/etc/ebusd/vaillant/timer.inc" for "25.hwc", included
"/etc/ebusd/vaillant/errors.inc" for "25.hwc", included
"/etc/ebusd/vaillant/mcmode.inc" for "51.mc.3", included
"/etc/ebusd/vaillant/timer.inc" for "51.mc.3", included
"/etc/ebusd/vaillant/errors.inc" for "51.mc.3", included
"/etc/ebusd/vaillant/roomtempoffset.inc" for "51.mc.3", included
"/etc/ebusd/vaillant/quick.inc" for "51.mc.3"
2016-12-30 18:04:06.765 [main notice] found messages: 653 (147
conditional on 50 conditions, 1 poll, 51 update)
2016-12-30 18:04:06.906 [bus notice] poll ehp HeatpumpType: 0
2016-12-30 18:04:08.738 [bus notice] new master 10, master count 3
2016-12-30 18:04:08.773 [update notice] update ehp Mode QQ=10: standby
2016-12-30 18:04:12.120 [bus notice] poll ehp HeatpumpType: 0
2016-12-30 18:04:14.848 [update notice] update ehp Status01 QQ=10:
57.0;51.0;1.312;49.0;48.0;on
2016-12-30 18:04:15.090 [update notice] unknown BC cmd:
10feb516080016041830120516
2016-12-30 18:04:15.345 [update notice] unknown MS cmd: 1008b512020000 /
00
2016-12-30 18:04:18.101 [bus notice] poll ehp HeatpumpType: 0
2016-12-30 18:04:18.892 [update notice] update ehp Mode QQ=10: standby
In FHEM komme ich jetzt auch schon etwas weiter.
Ist halt wieder alles Neuland.
@john30, @paddyx:
Hallo John, hallo Patrick!
Sorry, dass ich mich erst jetzt rühre ... habe die Antworten auf meine
Frage wohl irgendwie übersehen :-(
Zuerst mal euch allen ein GUTES NEUES JAHR und dir John ein fettes Lob
und Dankeschön für das ebusd Projekt!
Also, ich habe die letzten Tage etwas mit ebusd und meiner Brink
Renovent Excellent 300 rumgespielt und konnte schon einiges rausfinden.
Und ja, der EBUS-Adapter ist wirklich kompatibel mit dem Service-Tool
von Brink, welches von deren Homepage geladen werden kann.
Über das habe ich die meisten Kommandos entschlüsseln können.
Einige Kommandos, wie zB. das für die Fehlermeldungen (die letzten 10)
wie auch die Filtermeldung konnte ich leider noch nicht entschlüsseln,
da kein Fehler aktuell (Gott sei Dank) anliegt und der Filterwechsel
auch noch aussteht.
Im Anhang hab ich aber mal die bisherige Config-Datei dazugepackt, damit
nicht noch jemand bei Null anfangen muss!
Die Datei 3c.csv einfach in den Ordner encon kopieren und den ebusd
Service neu starten oder ein ebusctl reload machen.
LG Daniel.
Sven G. schrieb:> Also @Alex und @temp:> Schickt mir eine PN und ich sende euch den Dropbox-Link zur aktuellen> 15.700.csv - ist noch nicht ganz vollständig, aber Ferienzeit,> Zeitprogramme usw. sind schon drin.
@Sven G. und @John:
Ich habe seit einigen Tagen einen neuen Regler mit Zusatzmodulen,
nämlich:
"MF=Vaillant;ID=COM00;SW=0607;HW=3103" VR900
"MF=Vaillant;ID=BAI00;SW=0518;HW=7401" auroCompact
"MF=Vaillant;ID=70000;SW=0419;HW=4603" VRC700
"MF=Vaillant;ID=VR_70;SW=0109;HW=2903" VR_70
Würdet ihr mir bitte eure csv-Files für die VRC700 zukommen lassen? Dann
kann ich bei der Suche helfen und verstehe die Syntax der 700 besser.
Ich bin selber auf der Suche nach Ein-/Ausschalten der
"1*Speicherladung". Die Befehle für andere Regler funktionieren nicht.
Im Log habe ich beim Ein- und Ausschalten der Speicherladung direkt auf
dem VRC700 jeweils die zwei folgenden Meldungen gesehen:
Speicherladung ein
0015b52406020000007300 / 08010073000000103f
1008b512020064 / 00
Speicherladung aus
0015b52406020003010800 / 08030308000000a841
1008b512020000 / 00
Wenn ich die Werte auf den eBUS schreibe, kommt nur ein "ERR: element
not found" und es passiert nichts. Wenn ich Loglevel auf debug erhöhe,
sehe ich jede Menge "ERR: read timeout during receive response,
switching to skip".
Es gibt inzwischen einen (Zwischen)Stand der CSV für VRC700 auf GitHub:
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.700.csv
Ich muss mich mal ransetzen und den bereinigen und ergänzen.
Allen anderen sei weiterhin ans Herz gelegt, mir eine Mail zu schreiben
- die spezifische Diskussion würde hier alles zu unübersichtlich machen.
Die Aktivierung der Sonderfunktionen ist in der CSV auch noch nicht
vollständig enthalten. Wenn man die Nachrichten des VR900 beobachtet,
sieht man dass das ziemlich unübersichtlich umgesetzt ist!
Die beobachteten Meldungen haben damit nur bedingt etwas zu tun:
> 0015b52406020000007300 / 08010073000000103f
Wert der Außentemperatur, wird immer mal vom VR900 abgefragt.
> 1008b512020064 / 00
VRC700 schickt dem Brenner eine WW-Anforderung.
> 0015b52406020003010800 / 08030308000000a841
QuickVetoTemp Zone2 = 21°C (hast Du die in der App verstellt?)
> 1008b512020000 / 00
VRC700 meldet dem Brenner "keine WW-Anforderung".
Ich kann mich nicht mehr genau erinnern, wie ausgiebig ich das für die
Speicherladung getestet/beobachtet habe (da diese mit meinem
Trinkwassermodul keinen Sinn ergibt) - notiert habe ich aber:
$ ebusctl hex 15b52407020101000d0006
Prüfen kann man das anschließend in Register 00007800:
$ ebusctl hex 15b52406020000007800
06030078000900
(also 0900 = 1x Speicherladung)
Abbrechen aller Sonderfunktionen macht das VR900 generell über 00007800,
jedoch Setzen lassen sich die Funktionen darüber offenbar nicht, nur
abbrechen:
$ ebusctl hex 15b524080201000078000000
(Speicherladung wird allerdings nach 1h automatisch abgebrochen, ggf.
auch schon sobald der Speicher die gewünschte Temperatur hat)
Da die Speicherladung aber nur den WW-Kreis betrifft, sollte eine
Aktivierung/Deaktivierung auch allein über 01000d00 möglich sein - mit
oben verlinkter CSV also:
$ ebusctl w -c 700 HwcSFMode 6
$ ebusctl w -c 700 HwcSFMode 0
(6 = 1x Speicherladung, 0 = normal)
Sven G. schrieb:>> 0015b52406020000007300 / 08010073000000103f> Wert der Außentemperatur, wird immer mal vom VR900 abgefragt.>>> 1008b512020064 / 00> VRC700 schickt dem Brenner eine WW-Anforderung.>
Das wäre ja wohl die Speicherladung.
>> 0015b52406020003010800 / 08030308000000a841> QuickVetoTemp Zone2 = 21°C (hast Du die in der App verstellt?)>
Nope. Die App war nicht mal in der Nähe. Ist bei mir auch auf 21,5°C.
Komisch.
>> 1008b512020000 / 00> VRC700 meldet dem Brenner "keine WW-Anforderung".>
Und das wohl Speicherladung aus. Funktioniert bei mir aber nicht, wenn
ich das schreibe.
> Ich kann mich nicht mehr genau erinnern, wie ausgiebig ich das für die> Speicherladung getestet/beobachtet habe (da diese mit meinem> Trinkwassermodul keinen Sinn ergibt) - notiert habe ich aber:> $ ebusctl hex 15b52407020101000d0006>
Perfekt. Das schaltet die Speicherladung ein!
> Prüfen kann man das anschließend in Register 00007800:> $ ebusctl hex 15b52406020000007800> 06030078000900> (also 0900 = 1x Speicherladung)>
Passt. Sehe ich auch, wenn die Speicherladung = an ist.
> Abbrechen aller Sonderfunktionen macht das VR900 generell über 00007800,> jedoch Setzen lassen sich die Funktionen darüber offenbar nicht, nur> abbrechen:> $ ebusctl hex 15b524080201000078000000> (Speicherladung wird allerdings nach 1h automatisch abgebrochen, ggf.> auch schon sobald der Speicher die gewünschte Temperatur hat)
Passt auch. Schaltet die Speicherladung wieder aus.
Leider muss ich Speicherladung bei mir manuell ein- und ausschalten, da
das automatische Ausschalten bei mir nicht funktioniert, daher brauche
ich diese eBUS-Kommandos.
>> Da die Speicherladung aber nur den WW-Kreis betrifft, sollte eine> Aktivierung/Deaktivierung auch allein über 01000d00 möglich sein - mit> oben verlinkter CSV also:> $ ebusctl w -c 700 HwcSFMode 6> $ ebusctl w -c 700 HwcSFMode 0> (6 = 1x Speicherladung, 0 = normal)
Passt. Funktioniert auch anstandslos.
Die 15.700.csv habe ich mir von github geholt - wie kann ich helfen,
weitere Befehle zu entschlüsseln?
Hallo Daniel,
ich habe mich in den letzten Tagen vom Jahr 2016 auch nochmal
rangesetzt. Anbei meine letzte Version. Ist alles noch nicht so schön,
reicht mir aber erstmal für meine Visualisierung mit smarthome.py und
smartvisu. Die noch undefinierten Messages sind wohl für die
Plus-Version bestimmt, die ich nicht habe.
Deine Nutzung von negativen Multiplikatoren (zur Multiplizierung) kannte
ich noch nicht und habe ich bei mir übernommen.
Zusätzlich zur ersten Version mit meinem vorhandenen Bedienmodul die ich
Dir mal per Mail gesendet hatte, hat mir folgend auch das Service-Tool
von Brink und ILSpy geholfen.
Gruß
Paddy
Hallo Paddy,
vielen Dank für deine Config :-)
Schön langsam haben wir wirklich alles zusammen!
Ach ja, das mit den negativen Werten hat mir John verraten ...
Danke an den Thread hier - war schon auf der Suche nach einem
eBUS-Adapter und habe von Helmut H. zwei Platinen erstanden. Die erste
habe ich dann gleich geschrottet, weil ich den FT 232 RL per Hand
versucht habe zu löten. Pins krumm, Lötbrücken, Riesensauerei. Helmut
gab mir den Tipp mit einer Aluplatte auf einem Gasherd, aber in
Ermangelung eines Gasherds musste ein Bügeleisen herhalten. Hat auf
Anhieb funktioniert mit bleihaltiger Lötpaste und Flussmittel. Drei
kleine Lötbrücken gingen dann schnell mit Entlötlitze weg. Adapter läuft
einwandfrei.
https://youtu.be/v3IdK5dK5m4
Wow, wie interessant!
Ich will damit meine Vaillant Geotherm 61/3 auslesen über FHEM und würde
einen fertigen Adapter kaufen. Ist noch einer zu haben, oder kann mir
jemand einen bauen?
Hallo ihr Feaks,
Ich habe ein problem. Ich brauche einen adapter von ebus auf modbus tcp
für meine Weishaupt Heizung um meine WR Sol2.1 mit meinem WTC OW und dem
Rest der Heizung zu koppeln.
So einen Adapter kann man auch kaufen für ca.1200€ bei Weishaupt.
Wo bekomme ich so ein Teil zu einem fairen Preis?
Könnt ihr mir helfen?
MfG
Arnd Diekmann
...aber wo es schon um "faire Preise" geht - ich hätte auch ein
Anliegen, wenn auch in ganz anderer Dimension (mir trotzdem zu teuer):
Ich würde im Sommer gern meinen Vaillant Ölbrenner (icoVIT 156/3)
komplett ausschalten und nur die anfallende Solarenergie nutzen. Problem
dabei ist, dass meine Steuerung nur über EBus gespeist wird, und der nur
vom Brenner versorgt wird. Also: Brenner aus = Steuerung aus. Alle
anderen Komponenten speisen den Bus leider nicht, sondern hängen sich
nur passiv dran.
Jetzt habe ich von Vaillant den VR 38 für knapp 100 EUR gefunden, aber
nur um ein paar Volt auf den Bus zu geben scheint mir das auch zu viel.
Leider finde ich nirgends etwas, wie man den EBus "richtig" versorgt,
nur eine Skizze unter [1] auf Seite 29.
Leider fehlen hier Angaben zur notwendigen Spannungsversorgung UH und
auch die Beschaltung des LM317 scheint keinem Standard zu entsprechen
und OUT und ADJUST sind leider nicht beschriftet.
Kann mir jemand sagen, wie man auf einfache Weise EBus-Clients speisen
kann?
Sven
[1]
http://ebus-wiki.org/lib/exe/fetch.php/ebus/ebus_stuttgart_041201_ebus_only.pdf
Sven G. schrieb:> Kann mir jemand sagen, wie man auf einfache Weise EBus-Clients speisen> kann?
Laut Spezifikation (Kapitel 10.4 bzw. 10.5 in Spec_Prot_12_V1_3_1) ist
das nicht sehr kompliziert. Für ebusd Tests habe ich mir eine solche
nicht kaskadierende Versorgung gebastelt, das funktioniert einigermaßen.
John B. schrieb:> Laut Spezifikation (Kapitel 10.4 bzw. 10.5 in Spec_Prot_12_V1_3_1) ist> das nicht sehr kompliziert. Für ebusd Tests habe ich mir eine solche> nicht kaskadierende Versorgung gebastelt, das funktioniert einigermaßen.
Ja, diese Skizze ist mit der von mir verlinkten identisch.
Hast Du von Deinem Aufbau das Schaltbild? Beim LM317 ist sicher ADJUST
unten?! (und nur zur Sicherheit: Kondensator "0.1/50" = 100nF/15V ?)
Und die Spannung UH muss >=24V sein, richtig?
Und was heißt "einigermaßen"?? :-D
Sven
Sven G. schrieb:> John B. schrieb:>> Laut Spezifikation (Kapitel 10.4 bzw. 10.5 in Spec_Prot_12_V1_3_1) ist>> das nicht sehr kompliziert. Für ebusd Tests habe ich mir eine solche>> nicht kaskadierende Versorgung gebastelt, das funktioniert einigermaßen.>> Ja, diese Skizze ist mit der von mir verlinkten identisch.> Hast Du von Deinem Aufbau das Schaltbild? Beim LM317 ist sicher ADJUST> unten?! (und nur zur Sicherheit: Kondensator "0.1/50" = 100nF/15V ?)> Und die Spannung UH muss >=24V sein, richtig?
ich habs nur auf schnell auf Steckplatine verdrahtet. Das Schaltbild ist
doch im PDF, also was brauchst Du genau?
Die eingesetzten Komponenten kann ich Dir am WE nachschauen. /50 soll
bestimmt 50V heißen. Mein LM317 hat alle Beine unten, insofern passt die
Frage nicht :-)
> Und was heißt "einigermaßen"?? :-D
naja ich benutze das wie gesagt nur, um zwei Interfaces und zwei ebusd
Instanzen "gegeneinander" zu testen, also nicht produktiv.
John B. schrieb:>> Und die Spannung UH muss >=24V sein, richtig?>> ich habs nur auf schnell auf Steckplatine verdrahtet. Das Schaltbild ist> doch im PDF, also was brauchst Du genau?>> Die eingesetzten Komponenten kann ich Dir am WE nachschauen. /50 soll> bestimmt 50V heißen. Mein LM317 hat alle Beine unten, insofern passt die> Frage nicht :-)
Sorry, die "15V" waren ein Tippfehler, natürlich meinte ich "50V" - es
ging eher um die 0.1, ob das nun 100nF sind, erscheint mir recht gering
(ebenso die verwendeten Widerstände mit wenigen Ohm - aber das ist dann
wohl so).
Mit "unten" meinte ich die Abbildung im Schaltbild, dort sind leider
alle 3 Pins des LM317 nicht beschriftet. Inzwischen habe ich aber doch
im Datenblatt eine Referenzschaltung zu Konstantstromquelle gefunden,
aus der hervorgeht: 100nF sind richtig, Beschaltung wie überall
abgebildet (IN links, ADJ unten, OUT rechts).
Somit bleibt nur noch die Frage nach der zu verwendenden Speisespannung
UH.
Und wie mir inzwischen durch den Kopf geht: die Widerstände sollten
sicher etwas dicker ausgelegt werden...
Bei angenommenen 24V fließen durch (24R + 47R) ganze 338mA
Kurzschlussstrom. Über den 47R fallen also 15,9V ab - also muss der 5,4W
vertragen??
Oder habe ich hier einen Denkfehler?
Sven
Sven G. schrieb:> John B. schrieb:>>> Und die Spannung UH muss >=24V sein, richtig?>>>> ich habs nur auf schnell auf Steckplatine verdrahtet. Das Schaltbild ist>> doch im PDF, also was brauchst Du genau?>>>> Die eingesetzten Komponenten kann ich Dir am WE nachschauen. /50 soll>> bestimmt 50V heißen. Mein LM317 hat alle Beine unten, insofern passt die>> Frage nicht :-)>> Sorry, die "15V" waren ein Tippfehler, natürlich meinte ich "50V" - es> ging eher um die 0.1, ob das nun 100nF sind, erscheint mir recht gering> (ebenso die verwendeten Widerstände mit wenigen Ohm - aber das ist dann> wohl so).
ja 100nF klingt stimmig :-)
> Mit "unten" meinte ich die Abbildung im Schaltbild, dort sind leider> alle 3 Pins des LM317 nicht beschriftet. Inzwischen habe ich aber doch> im Datenblatt eine Referenzschaltung zu Konstantstromquelle gefunden,> aus der hervorgeht: 100nF sind richtig, Beschaltung wie überall> abgebildet (IN links, ADJ unten, OUT rechts).
ach so, ja m.W. ist ADJ in der Mitte.
> Somit bleibt nur noch die Frage nach der zu verwendenden Speisespannung> UH.
naja die sollte wohl etwas höher sein als die Zielspannung.
> Und wie mir inzwischen durch den Kopf geht: die Widerstände sollten> sicher etwas dicker ausgelegt werden...
definitiv, hab da glaub ich 1W genutzt und zusätzlich parallel auf drei
verteilt, also somit 3W.
> Bei angenommenen 24V fließen durch (24R + 47R) ganze 338mA> Kurzschlussstrom. Über den 47R fallen also 15,9V ab - also muss der 5,4W> vertragen??> Oder habe ich hier einen Denkfehler?
war da nicht noch ne Z-Diode drin? Dann wäre die Spannung nur noch rund
17V und somit 240mA, ergo 4W verteilt auf 2 Widerstände, womit dann 1,3W
bzw. 2,7W Leistung notwendig wären.
.....nachdem ich nochmal darüber nachgedacht habe:
Eigentlich sollte der LM317 doch den Strom konstant halten, bei 24R auf
52mA. Bei Kurzschluss des EBus-Ausgangs wird also auch auf diese 52mA
geregelt. Über 47R fallen demnach 2,4V ab, also 1/8W.
Problematisch wird's da vermutlich nur innerhalb des LM317...
Hinter OUT fallen schließlich nur die 1,25V über 24R, die 2,4V über 47R
und noch 0,7V über die Diode ab - bei 28V Speisespannung muss also der
LM317 23,6V "verbraten". Wenn man allerdings davon ausgeht, dass durch
ihn auch nur 52mA fließen, sind das ja auch "nur" ca. 1,25W - hört sich
also doch recht schlüssig an.
Hallo,
ich beschäftige mich ganz neu mit dem Thema. Die Hardware aufzubauen
ging recht schnell, aber die Software ... .
Ich hoffe ich nerve jetzt keinen, wenn ich vielleicht blöde Fragen
stelle.
Im Log des ebusd sehe ich eine Reihe von Statusmeldungen, z.B.
[update notice] update bai Status01 QQ=10: 35.5;35.5;-;38.0;54.0;off
[update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
[update notice] update bai currenterror QQ=10: -;-;-;-;-
Gehe ich recht in der Annahme, dass es sich hierbei im Meldungen
handelt, die Telegramme darstellen, die ein Busteilnehmer angefordert
hat und ein anderer beantwortet ?
Ich sehe in schöner Regelmäßigkeit Meldungen
[update notice] unknown MS cmd: 1008b512020064 / 00
[update notice] unknown MS cmd: 1008b5110100 / 086402130008000083
Das sind dann Meldungen, die der ebuds noch nicht dekodieren kann,
richtig ? Adresse 10 fragt Adresse 08 irgendwas ?
ebusctl info zeigt
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0113;HW=9602",
loaded "bai.0010015600.inc" ([PROD='0010015600']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=37000;SW=0129;HW=6002",
loaded "vaillant/15.370.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
wobei Adresse 10/15 nicht wirklich ein calorMATIC (VRT 370) ist. Es
handelt sich dabei vielmehr um ein Tado Smart Thermostat, der wohl ein
VRT 370 simuliert und daher auch nicht auf Slave-Anfragen reagiert.
btw. wie könnteich in meinem Beispiel die Error-History abfragen ?
Vielen Dank für jegliche Unterstützung.
lg.
TF
Thoralf F. schrieb:> Gehe ich recht in der Annahme, dass es sich hierbei im Meldungen> handelt, die Telegramme darstellen, die ein Busteilnehmer angefordert> hat und ein anderer beantwortet ?
richtig.
> Das sind dann Meldungen, die der ebuds noch nicht dekodieren kann,> richtig ? Adresse 10 fragt Adresse 08 irgendwas ?
richtig.
> btw. wie könnteich in meinem Beispiel die Error-History abfragen ?
ebusctl read errorhistory
VG John
John B. schrieb:> ebusctl read errorhistory
Hallo John,
danke für die Rückantwort. Das klappt so ja noch nicht wirklich. Was ich
bislang erfolgreich testen konnte war
ebusctl read -f -d 08 -i 0 errorhistory
1;-:-;-.-.-;23
bzw.
ebusctl read -v -d 08 -i 0 errorhistory
370 errorhistory status=1;time2=-:-;date=-.-.-;error=23
Am Display der Heizung kann ich jedoch 3 Fehler (jeweils Error
23)ablesen. Wie komme ich denn an alle Einträge ?
lg.
TF
Thoralf F. schrieb:> ebusctl read -f -d 08 -i 0 errorhistory> 1;-:-;-.-.-;23
ah stimmt, da brauchts ja noch Input.
Für ältere Einträge einfach -i 1, -i 2 etc. verwenden.
Vielen Dank. Klappt.
Ich probiere gerade mal, was mit meiner Heizung von den bereits
definierten Werten geht und was nicht. Alles aus der verwendeten
bai.0010015600.inc scheint jedenfalls nicht zu funktionieren, was auch
nicht wirklich verwunderlich ist. Werden die *.inc Dateien beim ebusctr
reload eigentlich auch mit eingelesen, ich habe das Gefühl, bei mir
nicht.
btw. Ist das eigentlich das richtige Forum für Austausch zum ebusd ?
µC.net ist ja doch eher der Hardwareanteil der Angelegenheit .... .
Hallo,
ich habe diesen Thread leider erst jetzt entdeckt. Das Thema eBus und
Vaillant verfolgte ich schon seit 2006. Da Vaillant überwiegend einen
proprietären eBus - Code verwendet, kam ich anfangs auch nicht weiter.
Das änderte sich Ende 2011. Die eBus Kommunikation der Vaillant eigenen
Steuersoftware wurde in deutsch - französischer Zusammenarbeit
analysiert. Das Ergebnis wurde in analyseVaillant3.xlsx festgehalten.
Die Exceldatei kann hier entnommen werden.
https://www.symcon.de/forum/threads/15272-Vaillant-Therme-%C3%BCber-eBus-steuern?p=191725#post191725
Der Thread an sich ist schon lesenswert.
Der Forums-User terenyi hat dann ein Meisterwerk geschrieben.
IP-Symcon ist eine Plattform zur Heimsteuerung und terenyi hat zwei
Module in PHP bereitgestellt.
eBus Connector
https://www.symcon.de/forum/threads/20487-eBus-Connector?highlight=eBus+Koppler
eBus Manager
https://www.symcon.de/forum/threads/20547-eBus-Manager
Für PHP empfand ich bestenfalls eine Hassliebe. Der PHP-Source von
terenyi war aber einfach nur toll geschrieben.
Die Software zum eBus Connector und eBus Manager ist jeweils im ersten
Beitrag von terenyi zu finden.
Ich hoffe ich konnte in der Sache weiterhelfen.
mfg klaus
Hi Klaus,
danke für die Info. Scheint aber erstmal nur mit Windows zu laufen. Der
ebusd ist dagegen eine *nix Software. Die Informationen aus dem von Dir
genannten Projekt könnten hilfreich sein, falls darin noch etwas
enthalten ist, was hier noch nicht "entschlüsselt" wurde. Das können
jedoch nur die Experten beurteilen.
Nochmals danke.
lg.
TF
Thoralf F. schrieb:> Scheint aber erstmal nur mit Windows zu laufen. Der> ebusd ist dagegen eine *nix Software.
Es ist PHP. Das kann man auch unter Windows laufen lassen. In der Regel
ist es auch ein *nix-System oder Ubuntu, .... Wäre sicher auch etwas für
einen Raspberry.
> Die Informationen aus dem von Dir> genannten Projekt könnten hilfreich sein, falls darin noch etwas> enthalten ist, was hier noch nicht "entschlüsselt" wurde.
Die Excel-Datei ist die eigentliche Quelle für den geknackten Code. Die
PHP - Software sagt Dir aber entscheidendes über die Anwendung. Ich
selber habe unter VB.NET programmiert und habe einige PHP-Passagen
übersetzt in VB.NET übernommen. Das war echt hilfreich. Allerdings habe
ich natürlich die Mittel, die es unter VB.NET bzw. C#.NET gibt
(Threading, Ereignissteuerung, ...) , eingesetzt.
Ich habe euren Thread bisher nur überflogen. Gibt es da eine
zusammenhängede Projektübersicht, Code?
mfg klaus
Thoralf F. schrieb:> ich habe gedacht verstanden zu haben, dass der Windows-Service (C#)> benötigt wird, und die php-Scripte darauf aufsetzen. Ist das falsch ?
IP-Symcom ist die Rahmenanwendung die es für diverse Betriebssyteme
gibt. Dazu kann man Module auch selber schreiben und in die
Rahmenanwendung integrieren. Mich hatte das grosse Paket aber nicht so
interessiert, da ich damals schon ein eigenes Heim-Steuersystem am
Laufen hatte und "nur" meinen neuen Vailland Brennwertkessel steuern
wollte.
https://www.symcon.de/service/Thoralf F. schrieb:> https://github.com/john30/ebusd/ ist die Quelle der Software und> Informationen hier. Und dann gibt es noch das
Der Service.
> http://ebus-wiki.org/doku.php und da
Das kannte ich damals schon. 2011/2012 ist m.E. die Wiki nicht komplett
mit dem neuen Wissen erweitert worden. Die Exceldatei
analyseVaillant3.xlsx ist ziemlich umfassend.
> https://forum.fhem.de/index.php/topic,29737.0.html.
FHEM hatte ich mir damals auch mal angeschaut. Ich bin sogar jetzt noch
automatisch eingeloggt worden. Im Kopf des Forums steht "FHEM ist ein
Perl Server für die Haustechnik".
Hat man wirklich etwas mit Perl zu tun? Ebusd ist ja in C++ geschrieben.
Seit dem ich hörte, Perl wäre die Mutter von PHP, ist Perl bei mir in
der Achtung gesunken.
mfg klaus
Klaus R. schrieb:> eBus Manager> https://www.symcon.de/forum/threads/20547-eBus-Manager
Schicht 2: Datenstrom-Management
Ich habe mit C# einen eBus Connector entwickelt, welcher im Hintergrund
als Windows-Service läuft, den Datenstrom von der virtuellen
COM-Schnittstelle in einzelne Nachrichten unterteilt und dann jede
Nachricht einzeln als UDP-Paket an IP-Symcon weiterleitet.
Außerdem lauscht der eBus Connector auf UDP-Pakete von IP-Symcon, welche
zu sendende eBus Nachrichten enthalten, die dann vom eBus Connector mit
dem Bus synchronisiert verschickt werden.
Klaus R. schrieb:> eBus Connector> https://www.symcon.de/forum/threads/20487-eBus-Connector?highlight=eBus+Koppler
Der eBus Connector funktioniert ähnlich zum eBus Adapter von Brownson
(siehe hier), ist aber als externes Programm und nicht als IPS-Modul
rSobald eine komplette Nachricht empfangen wurde, sendet der eBus
Connector diese als UDP-Paket (als Hex-String) and den eingestellten
Empfänger (z.B. IPS) weiter, wo die Nachricht dann verarbeitet werden
kann.ealisiert.
...
Mit dem eBus Connector können eBus Nachrichten über einen (virtuellen)
COM-Port gelesen und synchronisiert geschrieben werden. Der
Datenaustausch zwischen IPS und dem eBus Connector erfolgt via UDP.
...
Sobald eine komplette Nachricht empfangen wurde, sendet der eBus
Connector diese als UDP-Paket (als Hex-String) and den eingestellten
Empfänger (z.B. IPS) weiter, wo die Nachricht dann verarbeitet werden
kann.
Mit anderen Worten, das php-Zeugs kommuniziert per UDP mit dem Windows
Dienst. Im Gegensatz zum ebusd macht dieser eBus-Connector-Service
allerdings nichts weiter als die Daten vom Bus zu lesen und in Hex-Form
auf dem UDP-Port zur Verfügung zu stellen. Und umgekehrt zu schreiben.
Das Decodieren erfolgt per php und die Anzeige auch. Will ich also die
php-Scripte verwenden, müsste ich einen ähnlichen Dienst unter *nix
haben. Der ebusd wäre das nicht, da er die Bus-Nachrichten parsed und in
human readable Format übersetzt (vice versa), also in einer komplett
anderen Form bereitstellt.
Für die Nutzung von FHEM muss man nicht zwangsläufig Perl beherrschen,
gut wäre es aber. Ich persönlich benutze FHEM allerdings nicht, aber es
gibt da eine Menge von Aktivitäten, die auch anderweitig einsetzbar
sind.
lg.
TF
PS: Perl mit php zu vergleichen, wäre Äpfel mit Birnen zu vergleichen.
Thoralf F. schrieb:> Mit anderen Worten, das php-Zeugs kommuniziert per UDP mit dem Windows> Dienst. Im Gegensatz zum ebusd macht dieser eBus-Connector-Service> allerdings nichts weiter als die Daten vom Bus zu lesen und in Hex-Form> auf dem UDP-Port zur Verfügung zu stellen. Und umgekehrt zu schreiben.> Das Decodieren erfolgt per php und die Anzeige auch. Will ich also die> php-Scripte verwenden, müsste ich einen ähnlichen Dienst unter *nix> haben. Der ebusd wäre das nicht, da er die Bus-Nachrichten parsed und in> human readable Format übersetzt (vice versa), also in einer komplett> anderen Form bereitstellt.>
Ich wollte auch nicht sagen, man solle die PHP-Scripte verwenden. Das
würde nur in einer PHP-Welt einen Sinn ergeben, erst Recht unter
IP-Symcon. Für mich waren die PHP-Scripte von terenyi eine sehr gute
Vorlage.
> Für die Nutzung von FHEM muss man nicht zwangsläufig Perl beherrschen,> gut wäre es aber. Ich persönlich benutze FHEM allerdings nicht, aber es> gibt da eine Menge von Aktivitäten, die auch anderweitig einsetzbar> sind.>
Ich finde das Projekt auch nicht schlecht.
>> PS: Perl mit php zu vergleichen, wäre Äpfel mit Birnen zu vergleichen.
Die Perl - Syntax ist für mich etwas gewöhnungsbedürftig. PHP hat aber
zumindest im Grundsatz etwas von Perl geerbt. Ich musste mich vor Jahren
mal mit PHP4 beschäftigen. Zumindest damals war es zum Teil chaotisch.
Es schien so, als ob mehrere Entwickler die Sprache unabhängig von
einander erweitert hätten und dann noch in verschiedenen Stilen.
Manchmal dachte ich es kämen auch Fortran - Relikte vor. An Debugging,
wie unter .NET, war gar nicht zu denken!
mfg klaus
Hallo zusammen
Bin absolute neu im Thema. Ich möchte meine Heizung WOLF R20 DigiComfort
per eBus auslesen, Datenlongen, visualisieren. Ich interessiere mich nun
(zuerst) für den Adapter. Benötige dazu die Platine (bestückt oder
umbestückt).
Wo kann ich diese beziehen?
Hallo, ich habe die üblichen Verdächtigen hier angeschrieben und hatte
leider kein Glück mit meinem Gesuch. Drum frage ich nun auch mal hier im
Thread:
Hat jemand ein fertiges eBus-Interface (womöglich sogar mit Gehäuse)
anzubieten?
Eine kurze Rückmeldung wäre nett. Vielen Dank.
Helmut schrieb:> https://www.eservice-online.de/shop/ebus/ hat ganz viele
Das Gerät ist gut und der Preis angemessen. Durch selber löten kannst Du
Dir zwar ein paar Mark sparen, dann würde ich aber nicht auf den
Stundenlohn achten.
mfg klaus
Daraufhin habe ich die Datei 3c.csv von Daniel.S (siehe oben oder
https://github.com/dstrigl/ebusd-config-brink-renovent-excellent-300/blob/master/3c.csv)
genommen und "3c" durch "7c" ersetzt. Die in GitHub vorhandene Datei
"7c.renovent-excellent-400p.csv" klingt zwar naheliegender, aber die
Ergebnisse waren weniger passend (kein Pro-Modell).
Was mich nun wundert. Ich habe im ebus.log alle paar Sekunden folgenden
Inhalt: "2017-06-27 14:16:23.163 [update notice] update
Ventilatorbetrieb QQ=01: Reduziert". Diesen Wert kann ich auch mit
"ebusctl read" problemlos abfragen.
Aber alle anderen Werte sind leer:
ebusctl find
============
1
broadcast datetime = no data stored
2
broadcast error = E000
3
broadcast ident = ENCON; ;-;-
4
broadcast signoflife = no data stored
5
Abluftmenge = no data stored
6
Ablufttemperatur = no data stored
7
Aussenlufttemperatur = no data stored
8
BeleuchtungDisplay = no data stored
9
BetriebsstundenTotal = no data stored
10
Bypassbetrieb = no data stored
11
BypassHysterese = no data stored
12
BypassTemperatur = no data stored
13
eBusSynchFehler = no data stored
14
IstwertAbluftdruck = no data stored
15
IstwertZuluftdruck = no data stored
16
LuftmengeStufe0 = no data stored
17
LuftmengeStufe1 = no data stored
18
LuftmengeStufe2 = no data stored
19
LuftmengeStufe3 = no data stored
20
LuftmengeTotal = no data stored
21
RHSensorEmpfindlichkeit = no data stored
22
RHSensorVorhanden = no data stored
23
SoftwareVersion = no data stored
24
StaendigesUngleichgewicht = no data stored
25
TatsaechlicheAbluftmenge = no data stored
26
TatsaechlicheDrehzahlAbluft = no data stored
27
TatsaechlicheDrehzahlZuluft = no data stored
28
TatsaechlicheZuluftmenge = no data stored
29
UngleichgewichtMoeglich = no data stored
30
Ventilatorbetrieb = Reduziert
31
WertDIPSchalter = no data stored
32
ZentralheizungWRG = no data stored
33
Zuluftmenge = no data stored
34
broadcast ident = no data stored
35
memory eeprom = no data stored
36
memory ram = no data stored
37
scan.06 = no data stored
38
scan.7c = ENCON; ;-;-
Sobald ich aber das Bedienteil (= die Fernbedienung) nutze, werden die
Variablen größtenteils gefüllt.
Könntet ihr mir helfen und sagen wie ich das schaffe, dass ebusd die
Variablen zyklisch ausliest? Ein "ebusctl read Abluftmenge" liefert kein
Ergebnis.
Vielen Dank.
Funk O. schrieb:> Könntet ihr mir helfen und sagen wie ich das schaffe, dass ebusd die> Variablen zyklisch ausliest? Ein "ebusctl read Abluftmenge" liefert kein> Ergebnis.
Anscheinend nutzt Du ja schon für die Abfrage des EBus eine Software.
"ebusctl read" ist offensichtlich eine Funktion. Wenn Du dazu mehr sagen
könntest.
Ich selber habe den kompletten Stream in einem extra Thread lesen lassen
und die Sequenzen in eine Semaphore hineinschreiben lassen. Ein zweiter
Thread hat dann die Liste abgearbeitet. Beide Threads laufen
ereignisgesteuert.
mfg klaus
Hmm, jetzt bin ich irritiert. Ich nutze ebusd (v2.4 -
https://github.com/john30/ebusd). In diesem Thread ging es doch schon
ein wenig häufiger um diese Software. Darum nahm ich an, dass die
Vorgehensweise bekannt ist.
Ich habe es nun soweit verstanden, dass man die zyklischen Abfrage über
den Polling-Werten in der CSV-Datei konfigurieren kann. Nichtsdestotrotz
werden mir diese Werte nicht gefüllt. Per Broadcast wird anscheinend nur
der "Ventilatorbetrieb" übertragen. Aber kann ich nicht auch irgendwie
auf das KWL-Gerät lesend zugreifen?
Hallo,
ich hab mir ein Gehäuse erstellt und mit dem 3D Drucker gedruckt, falls
interesse besteht.
Druckdaten im STL format:
https://www.thingiverse.com/thing:2415554
mfg
Sascha
Hi,
ich hab Lötübung und einen eBus USB adapter gebraucht.
hab jetzt zwei Stück Adapter übrig, beide getestet und funktionierend,
aber man sieht dass es keine Maschine gelötet hat.
Warenwert ca. 20,50€, macht mir einen akzeptablen Vorschlag per pn.
LG
Hi,
kann es sein, dass der Kondensator C3 in der Schaltung nicht der
angegebene Reichelt "MKS-2-5 680N" sondern ein "MKS-2-50 680N" ist? Die
angegebene Best.-Nr. gibt es leider nicht bei Reichelt.
Ich habe vor den eBus Adapter nachzubauen und in openhab einzubinden.
Gibt es da bereits Erfahrungen von Jemanden?
Danke für die Hilfe
Axel T. schrieb:> Ich habe vor den eBus Adapter nachzubauen und in openhab einzubinden.> Gibt es da bereits Erfahrungen von Jemanden?
Bei mir läuft der Adapter mit Openhab 2 an einer Weishaupt Therme seit 2
Jahren vollkommen problemlos. Openhab läuft auf einem Raspberry Pi 3.
Gruß
Benedikt
Super! Vielen Dank für die rasche Antwort.
Klaus R. schrieb:> Ja, ein 5V Typ gibt es als MKS nicht.
Und nur um sicher zu gehen: ich baue anstatt des angegebenen "MKS-2-5
680N" jetzt den "MKS2-50 680N" ein, da es sich um einen Tippfehler in
der Liste handelt? Ich geh lieber auf Nummer sicher, denn wenn die Kiste
nach dem löten nicht läuft, bekomm' ich wohl niemals raus woran es liegt
;-)
Benedikt P. schrieb:> Bei mir läuft der Adapter mit Openhab 2 an einer Weishaupt Therme seit 2> Jahren vollkommen problemlos. Openhab läuft auf einem Raspberry Pi 3.
Welches Binding wird denn in openHAB für den converter verwendet?
Falls Interesse besteht:
Da ich jetzt auf einen WLAN-Adapter umsteigen werde, habe ich für die
USB-Version keine Verwendung mehr. Wenn jemand also an einem fertig
aufgebauten, getesteten Adapter im Gehäuse interessiert ist, möge er
sich bei mir per PN melden.
Einziger Unterschied zu den Bildern oben: ich habe keine USB-Buchse
verbaut, sondern ein 1,5m Kabel mit USB-A-Stecker direkt verlötet - das
ließe sich aber bei Bedarf und Vorhandensein einer USB-Buchse schnell
ändern.
und falls noch jemand einen braucht, ich hab noch einen übrig. Auch im
Gehäuse, LEDs nach aussen geführt, USB als auch Busseite
anschlussbereit, getestet.
Ich hätte Interesse an einer Platine oder auch vollständig aufgebautem
Adapter.
Möchte an meiner Lüftungsanlage Viessmann Vitovent 300-W ein paar Daten
aus dem E-Bus auslesen mit dem Wolf bzw. Brink-Servicetool
(BCSServiceTool).
Hat eventuell schon mal jemand damit neue Firmware in die Steuerungen
einer Lüftungsanlage geladen?
Tschüss
Maik
Hallo Maik,
für Platinen am besten Helmut H. oder Benedikt P. per PN anschreiben.
Zu deiner zweiten Frage:
Ich habe eine ähnliche Anlage (Brink Renovent Sky), habe aber noch keine
Firmwareupdate getestet. Die Frage wäre von meiner Seite, was Dir die
neue Firmware bringt? Gibt es Release-Notes oder ähnliches.
Gruß
Hallo Patrick,
eigentlich möchte ich die Lüftungsanlage an das Brink ehome-Modul bzw.
Wolf Link Pro anschließen. Beide sind fast identisch, hängen am E-Bus
und übertragen die Daten ins lokae Netz bzw. auf eine App.
Von Wolf gibt es auch noch einen I2C-Adapter auf Modbus-Adapter.
Meine Steuerplatine UWA-01 plus (von Brink) hat leider noch keinen
Modbus, aber E-Bus und I2C.
Damit das aber funktioniert, muss die Software in der Steuerung aktuell
sein.
Vorher wollte ich aber noch herausbekommen ob und welche meta-Daten
Seriennummer Gerätebezeichnung)über den E-Bus übertragen werden.
Tschüss
Maik
Hallo,
Ich habe aktuell auch Probleme den ebus zum laufen zu bringen.
Meiner Anlage ist eine Weishaupt WrSol.
Benutze den USB esera ebus Adapter.
Leider bekomme ich keinerlei Signale rein.
Habe schon probiert die Bus Adernpaare zu verdrehen aber es kommt
einfach nichts. ausser <aa... sollte ja eigentlich ok sein.
Kann mir jemand helfen ?
Sind denn überhaupt schon mehrere Teilnehmer am Bus?
Falls nicht, wäre erklärbar, warum die WrSol nicht unsinnig etwas über
den Bus schickt...
Es gibt im Netz aber Erkenntnisse, wie diese abzufragen ist, starte
vielleicht mal hiermit:
https://ebus-wiki.org/lib/exe/fetch.php/ebus/wrsol.pdf
Hallo,
in meinem Fall wär der WrSol 1.1 wirklich mit keinem andere Gerät per
eBus verbunden.
Habe dann eben den USB esera eBus Adapter direkt mit dem Bus Port des
WrSol verbunden.
Wie kann ich meine WrSol denn eigentlich abfragen ?
Hat niemand sowas am laufen.
Mit freundlichen Grüssen,
Kim
Vielen Dank für die Links.
Wenn ich den Raw ode des ebusd aktiviere dann habe ich von Zeit zu Zeit
diese Meldungen :
2019-04-05 21:09:44.914 [bus notice] <f1fefe010b
2019-04-05 21:09:45.624 [bus notice] <455336
2019-04-05 21:09:46.333 [bus notice] <3520b0
2019-04-05 21:09:47.041 [bus notice] <45204f
2019-04-05 21:09:47.058 [bus notice] <4bffc7
2019-04-05 21:14:44.679 [bus notice] <f1fefe010b
2019-04-05 21:14:45.387 [bus notice] <455336
2019-04-05 21:14:46.097 [bus notice] <3520b0
2019-04-05 21:14:46.804 [bus notice] <45204f
2019-04-05 21:14:46.821 [bus notice] <4bffc7
Kann mir da schon jemand helfen ?
mfg,
Kim
Hallo Kim,
mit welcher Software liest Du denn da den eBus aus?
Was ich da sehe sieht nicht typisch eBus aus. Auf dem Bus sollten eine
Reihe von "AA" zu sehen sein. Die kommen vom Master und signalisieren
den Anfang einer Nachricht oder bei vielen "AA" wird dem Client gesagt,
er könne jetzt was senden.
mfg klaus
Kim Hanesch schrieb:> Vielen Dank für die Links.>> Wenn ich den Raw ode des ebusd aktiviere dann habe ich von Zeit zu Zeit> diese Meldungen :>> 2019-04-05 21:09:44.914 [bus notice] <f1fefe010b> 2019-04-05 21:09:45.624 [bus notice] <455336> 2019-04-05 21:09:46.333 [bus notice] <3520b0> 2019-04-05 21:09:47.041 [bus notice] <45204f> 2019-04-05 21:09:47.058 [bus notice] <4bffc7> 2019-04-05 21:14:44.679 [bus notice] <f1fefe010b> 2019-04-05 21:14:45.387 [bus notice] <455336> 2019-04-05 21:14:46.097 [bus notice] <3520b0> 2019-04-05 21:14:46.804 [bus notice] <45204f> 2019-04-05 21:14:46.821 [bus notice] <4bffc7>> Kann mir da schon jemand helfen ?
also das sind merkwürdige Einträge, die alle nicht auftauchen dürften.
Bist du sicher, dass am UART nicht noch ein anderer Dienst außer ebusd
hängt?
@Klaus: er nutzt meinen ebusd: https://github.com/john30/ebusd/
Hi,
das ist ein Auszug aus meiner ebus Log Datei.
Am ebus hängt nur meine Raspberry und der Esera USB EBus Adapter.
Meine ebus Config sieht wie folgt aus :
ebusd --configpath=/etc/ebusd/weishaupt/ --scanconfig
--device=/dev/ttyUSB0 --latency=10000 --mqtthost=192.168.1.70
--mqttport=1883 --mqttjson --accesslevel='*'
Wenn ich den ebus Service stoppe und dann folgendmassen starte :
ebusd -f -c /tmp --logareas bus --loglevel info --lograwdata=bytes -d
/dev/ttyUSB0
Dann bekomme ich auch die beschrieben <AA.
Es scheint mir eben nur so als würde der WrSol 1.1 nicht selber auf den
Bus sprechen ohne Anfrage meinerseits.
Hi,
danke für die Links.
Schau mir das mal an. Bei mir ist halt immer noch das Problem dass sich
mit ebusctl info nichts am Bus bei mir meldet ?!
Immer nur diese :
address 31: master #8, ebusd
address 36: slave #8, ebusd
Kann es ein dass mein ebus Adapter von Esera defekt ist ? Hab den
nämlich Gebraucht ersteigert ?!
mfg, Kim
Kim Hanesch schrieb:> Kann es ein dass mein ebus Adapter von Esera defekt ist ?
Das kann ich mir nicht vorstellen. Ich hatte bestimmt drei Jahre lang
buchstäblich ein Drahtverhau am Laufen. Die Schaltung selber ist robust.
Und habe dann aus zeitlichen Gründen selber von Esera ein Fertiggerät
gekauft. Das hat noch nie Probleme gemacht und lief sofort.
Kim Hanesch schrieb:> Wenn ich den ebus Service stoppe und dann folgendmassen starte :>> ebusd -f -c /tmp --logareas bus --loglevel info --lograwdata=bytes -d> /dev/ttyUSB0>> Dann bekomme ich auch die beschrieben <AA.
Es scheint ja was zu kommen. Nehm mal Kontakt mit FHEM auf.
mdf Klaus
Hallo,
mittlerweile mit einem neuen EBUS ADapter bekomme ich folgendes Output :
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 1
max symbol rate: 22
min arbitration micros: 37
max arbitration micros: 144
min symbol latency: 3
max symbol latency: 5
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=TEM;ID=WRSOL;SW=0112;HW=0110"
Somit wir ja schonmal ein Gerät gefunden...Leider weiss ich jetzt nicht
so recht weiter
Hier der Log Output :
2019-11-23 11:56:39.987 [main notice] ebusd 3.4.v3.3-51-g57eae05 started
with auto scan
2019-11-23 11:56:40.313 [bus notice] bus started with own address 31/36
2019-11-23 11:56:40.502 [mqtt notice] connection established
2019-11-23 11:56:40.643 [bus notice] signal acquired
2019-11-23 11:57:46.005 [bus error] signal lost
2019-11-23 11:57:46.645 [bus notice] signal acquired
2019-11-23 11:57:48.277 [bus notice] new master f1, master count 2
2019-11-23 11:57:48.277 [update notice] received update-read broadcast
error QQ=f1: ES65 E OK
2019-11-23 11:57:52.502 [bus notice] scan f6: ;TEM;WRSOL;0112;0110
2019-11-23 11:57:52.503 [update notice] store f6 ident: done
2019-11-23 11:57:52.503 [update notice] sent scan-read scan.f6 QQ=31:
TEM;WRSOL;0112;0110
2019-11-23 11:57:52.504 [bus notice] scan f6: ;TEM;WRSOL;0112;0110
2019-11-23 11:57:52.572 [main error] unable to load scan config f6: list
files in tem ERR: element not found
2019-11-23 11:57:52.573 [main error] scan config f6: ERR: element not
found
2019-11-23 12:00:01.743 [main notice] update check: revision v3.4
available
Jetzt bräuchte ich dann mal passende Config Files.