SO, es läuft. Meine Vaillant-Heizung kann von FHEM nicht nur passiv überwacht werden, sondern auch abgefragt und gesteuert werden.
Die Beschreibung des selbst gebauten Interfaces (Kosten ca. 10 €) sowie eine schon relativ detaillierte Anleitung findet man hier: http://www.fhemwiki.de/wiki/EBUS.
Richtig gut hinbekommen habe ich das erst, als ich sowohl das selbstgebaute Interface, als auch ein Kommerzielles parallel betrieben habe - damit können sich die beiden gegenseitig belauschen. Das ist natürlich für den Endanwender jetzt nicht mehr nötig.
Aktuell verbessere ich sozusagen minütlich die Konfigurationsdateien für den ebusd, baue immer mehr Kommandos ein.
LG
pah
Moin,
klasse arbeit, kann gar nicht erwarten das ganze selber zu testen :-)
Mike
Hallo,
vielen Dank für diese Anleitung! Die größte Hürde wird für mich das Interface darstellen, aber ich werde mich da hoffentlich bald mal ran wagen ::)
schöne Grüße
Jo
Hm, ich habe demnächst das kommerzielle Interface - fast ungenutzt - abzugeben.
LG
pah
Danke für das Angebot. Ich muss mir allerdings erstmal Gedanken machen, was ich wo platzieren kann, da der Verteilerkasten für Hutschienenmontage nicht in Reichweite ist. Habe zudem einen Funkregler im Referenzraum, der den ebus-Anschluss hat. Ob ich dennoch direkt an die Therme gehen kann, muss ich noch klären.
schöne Grüße
Jo
kann mir jemand sagen ob (und eventuell mit welchen änderungen) dieses interface auch für den lbp bus (http://forum.fhem.de/index.php/topic,29762.0.html (http://forum.fhem.de/index.php/topic,29762.0.html), http://www.mikrocontroller.net/topic/218643 (http://www.mikrocontroller.net/topic/218643)) geeignet ist?
danke
andre
Die Logikpegel sind anders, und die Busgeschwindigkeit ist doppelt so hoch.
Nur die Logikpegel wirken sich auf die Schaltung aus, ggf. müsste man für das Empfangen den Schutzwiderstand vor dem Optokoppler ändern. Für das Senden müsste man den Spannungswert der Zenerdiode von 7,5 V auf ca. 5 V reduizieren (geschätzt). Außerdem hat dieser Bus invertierte Logikpegel, der Inverter U2-2 müsste also statt im Empfangszweig in den Sendezweig (das ist aber bitte nur ein Schnellschuss, erste Abschätzung, keine Garantie)
LG
pah
Ich habe im ursprünglichen Thread (http://forum.fhem.de/index.php/topic,22054.msg199452.html#msg199452) gelesen, dass die direkte Anbindung einer seriellen Schnittstelle mit 2400 baud den FHEM-Prozess stark ausbremsen kann. Bei der hier vorgestellten Lösung ist ja Hardware-seitig ein USB/RS232-Wandler und software-seitig der ebusd-Prozess zwischengeschaltet. Spricht etwas dagegen, ebusd und FHEM auf demselben Rechner, etwa einem Raspberry Pi, laufen zu lassen?
Natürlich spricht etwas dagegen: Die relativ schwache Performance des Raspberry.
Das sollte aber niemanden davon abschrecken, das zu probieren.
Im Übrigen habe ich niemals geschrieben, dass die 2400 Baud FHEM ausbremsen würden. Sondern dass der Raspberry Pi nahezu lahmgelegt wird, wenn er den EBUS an seinem GPIO-Port hat. Die Ursache ist übrigens nach wie vor unklar, ich habe aber weder Zeit, noch Lust, hieran Forschung zu treiben - darum habe ich lieber 6 € für das USB-Modul investiert.
LG
pah
Hallo pah,
das ist aber eine tolle Arbeit, wir werden uns direkt mal dran machen, die Schnittstelle zu realisieren.
Mal sehen was alles so mit meiner kleinen Anlage geht!
Vielen lieben Dank.
Holger
Finde ich schon mal sehr interessant. Leider hat unsere Heizung (Vaillant VKS) keinen eBus Anschluss. :-)
Gibt es aber dafür: http://waermeshop24.com/de/vaillant-zusatzmodul-vr-39-vks-vk-atmocraft-schnittst.-7-8-9-ebus
LG
pah
Meine Güte, warum poste ich denn oben im ersten Beitrag diesen LINK HIER http://www.fhemwiki.de/wiki/EBUS ?? >:(
pah
Ich verfolge dieses Themengebiet sehr aufmerksam. Die Steuerung meiner 1 Jahr alten Vaillant ecoTec Plus mit CalorMatic-Steuergerät 470f im Wohnzimmer ist das letzte fehlende Stück in meiner Heimautomatisierung. Allein das auslesen der zahlreichen Heizungsdaten würde mich brennend interessieren, aber auch die Möglichkeit, aus der Ferne die Heizung zu steuern.
Trotz aufmerksamen Studiums des Wiki-Artikels habe ich folgende Fragen:
- Wird das kommerzielle Modul einfach in der Heizung parallel zum Steuergerät an die Klemmen auf der Hauplatine angeschlossen? Dies geht aus der Wiki nicht hervor.
- Für die ecoTec-Plus gibt es noch keine Übersetzungs-Dateien. Wenn ich die Dateien der bisherigen Geräte vergleiche, gibt es überall Muster, und ich erkenne auch Parameter wieder. Kann man einfach eine solche Datei als Basis nehmen und werden dann Parameter, die es bei der Ecotec auch gibt, direkt übernommen?
- In den bisherigen Artikeln wird immer nur ausgelesen. pah schreibt, er kann auch Befehle setzen. Dafür finde ich kein Beispiel. Wie kann man z.B. den Betriebsmodus der Heizung umschalten, z.B. von "AUTO" auf "Nachtmodus", oder "1x Speicherladung" auslösen?
Vielleicht kann pah hierzu etwas sagen, da er seine Vaillant-Heizung bereits auch aktiv steuert.
Wenn diese Fragen geklärt sind, wäre ich durchaus geneigt, mir den kommerziellen ebus-Koppler zu kaufen. Ein Raspi liegt noch auf Reserve, und es ist ja bald Weihnachten.
Viele Grüße,
Heiko
Na, dann sehen wir mal:
ZitatWird das kommerzielle Modul einfach in der Heizung parallel zum Steuergerät an die Klemmen auf der Hauplatine angeschlossen?
Ja. Beide Buskoppler werden parallel zu allen anderen Geräten einfach an den EBUS angeklemmt. Wenn man sich in den Innereien nicht auskennt, sollte man schauen, ob die Heizungssteuerung einen EBUS-Anschluss herausgeführt hat (4-polig belegter 4er Modularstecker, 4P4C).
Zitat
Für die ecoTec-Plus gibt es noch keine Übersetzungs-Dateien. Wenn ich die Dateien der bisherigen Geräte vergleiche, gibt es überall Muster, und ich erkenne auch Parameter wieder. Kann man einfach eine solche Datei als Basis nehmen und werden dann Parameter, die es bei der Ecotec auch gibt, direkt übernommen?
Ich habe das so gelöst:
- Auf Basis einer Besipieldatei erst einmal nur auf den Bus gelauscht und die zyklischen einlaufenden Telegramme entziffert. Durch Vergleich mit den Einstellungen der Heizung sowie der "Absenderadresse" bekommt man daraus schon z.B. Vorlauftemperatur, Pumpenstatus, Speichertemperatur, Brennerstatus etc..
- Schwieriger ist, mit Hilfe des Befehls 15 (Adresse des Steuergerätes) B509 (Parameterabfrage) 0Dxx00 einzelne Register abzufragen. Bisher habe ich xx von 00 - 8F, also 9 x 16 = 134 Befehle getestet. Dabei kann man immer mal wieder einen Heizungsparameter ändern und sehen, was sich an den abgefragten Werten ändert. Dabei habe ich von 17 verschiedenen Registern bisher den Inhalt identifiziert - etwa solche wie den Ertrag meiner Solaranlage, oder die Ferienperioden. Ist nicht schwierig, sondern nur zeitaufwändig - und dabei hilft kolossal, wenn man zwei Buskoppler pararallel betreibt
- In den meisten Fällen lassen sich diese Parameter auch setzen, mit dem Befehl 15 B509 0Exx...
Ein einfacheren Weg gibt es natürlich - den habe ich aber bisher noch nicht beschritten: Software vrDialog besorgen und "mitschreiben", welche Befehle was machen. Bisher habe ich mich dabei aber noch nicht um eine Quelle gekümmert. Mal sehen, habe heute mein EU-Projektreview hinter michgebracht und wollte das nächste Woche noch einmal versuchen.
Zitat
In den bisherigen Artikeln wird immer nur ausgelesen. pah schreibt, er kann auch Befehle setzen. Dafür finde ich kein Beispiel. Wie kann man z.B. den Betriebsmodus der Heizung umschalten, z.B. von "AUTO" auf "Nachtmodus", oder "1x Speicherladung" auslösen?
Siehe oben ! ich hänge mal eine Liste an, die verschiedene Informationen über das Protokoll enthält.
LG
pah
Danke für deine ausführliche Antwort.
Ob es einen 4-poligen Modular-Stecker gibt, weiss ich adhoc nicht. Definitiv führen zum Calormatic nur 2 Adern - die habe ich selbst angeschlossen, nachdem der Maler durch war.
Also besteht der Bus somit nur aus 2 Adern?
Wenn ich den ebus elektrisch mit dem Bus-Koppler verbunden habe, könnte ich experimentieren.
Ich fasse also zusammen:
- Mit vrDialog bekommt man einen ebus-Adapter sowie passende Software, die aber nur unter Windows läuft. Dafür kann ich alle Parameter auslesen und Befehle setzen.
- In FHEM lässt sich das vermutlich nicht integrieren?
- Ziel ist auf jeden Fall die Integration in FHEM - eine Windows-Lösung kommt für mich nicht in Frage!
UpdateNach Durchsicht der Bedienungsanleitung hat der Bus auf dem Mainboard nur 2 Klemmen.
Es gibt dort keinen 4-poligen Modularstecker.
Wäre so aber einfacher, ich schließe im Heizraum einfach ein 2-adriges Kabel parallel auf die Klemmen an, führe es unten raus und in den ebus-Adapter?
Oder braucht der 4 Adern?
Hi,
beim Bauen der eBus Kommandos für Vaillant kann evtl. auch http://ebus.webhop.org/ (http://ebus.webhop.org/) helfen - insbesonders http://ebus.webhop.org/twiki/bin/view.pl/EBus/ServiceB5Vaillant (http://ebus.webhop.org/twiki/bin/view.pl/EBus/ServiceB5Vaillant).
Rainer
1. Ich habe keine Ahnung, ob man bei vrdialog einen Adapter mitbekommt - den bräuchte ich gar nicht, denn ich habe ja derzeit schon zwei. Vielleicht hat jemand hier in der Runde ja vrDialog im Einsatz ? Ich bräuchte das nur, um aus der enthaltenen Datenbank die Kommandos auszulesen.
2. Ja, der EBUS besteht nur aus zwei Adern, und die beiden hier diskutierten Adapter sind verpolungssicher.
LG
pah
Hallo zusammen,
ich habe eine Wolf Heizung, die ebenfalls über einen EBus verfügt.
Diese sollte dann doch auch über das Interface ansteuerbar sein?
Oder gibt es hier Unterschiede?
Grüße,
Thorsten
darüber würde auch ich mich super freuen
Wolf Brennwerttherame GB E 20 S
Nein, keine Hardware-Unterschiede.
Und bei der Software ebusd sind auch Beispieldateien für Wolf-Geräte dabei - allerdings muss man wahrscheinlich, wie bei Vaillant, erst mühsam die Daten decodieren.
LG
pah
Zitat von: heikoh81 am 11 Dezember 2014, 19:07:16
Ich verfolge dieses Themengebiet sehr aufmerksam. Die Steuerung meiner 1 Jahr alten Vaillant ecoTec Plus mit CalorMatic-Steuergerät 470f im Wohnzimmer ist das letzte fehlende Stück in meiner Heimautomatisierung. Allein das auslesen der zahlreichen Heizungsdaten würde mich brennend interessieren, aber auch die Möglichkeit, aus der Ferne die Heizung zu steuern.
[...]
Viele Grüße,
Heiko
Hallo Heiko,
ich habe exakt die gleiche Kombination (mit einer ecoTec Plus 206) bei mir laufen und überlege auch gerade, wo ich mich an den ebus ankopple und welchen Adapter ich dazu nehme. Evtl. können wir uns beim Entschlüsseln der Befehle austauschen, sobald die hardware bei mir läuft. Ich würde lieber gerne direkt an der Heizung an den ebus gehen, auch wenn die Einheit im Wohnzimmer einen Anschluss hat. Hast Du den Anschluss schon nach draußen gelegt?
schöne Grüße
Jo
Nachtrag: Meine ecoTec hat laut Installationsanleitung auf den Platine eine RJ1x (ist es RJ10 oder RJ11?) Buchse "Diagnosis über eBus, vrnetDIALOG" sowie zwei Schraubklemmen "Anschluss für externen eBus Regler". Ist es egal, an welchen dieser Anschlüsse ich mich ankopple? Die RJ-Buchse ist noch unbelegt und bietet sich eigentlich an.
Das klingt ja schonmal ganz gut..
Gibt es zum Schaltplan im Wiki eine Teileliste?
Grüße, Thorsten
@T: Das soll wohl ein Witz sein ?
@Jojo11: Ja, es ist egal, ob an die Buchse oder die Klemme. Problem ist, dass diese Modularbuchse sehr schmal ist: 4p4c bedeutet, dass man eben keine Standard-Telefonleitung nehmen kann (6 Kontakte breit), sondern z.B. eine alte Anschlussleitung eines Telefonhörers verwenden muss (oder einen neuen 4er Stecker mit der Crimpzange an ein neues Kabel setzen darf).
Ich habe gestern abend noch die neue Version des ebusd getestet. Ist leider etwas kryptisch bezüglich der Konfigurationsdateien. Habe als ersten Erfolg auch mit der neuen Version aktiv Daten aus meiner Heizung ausgelesen - aber die Broadcast-Messages kann ich bisher nur mit der alten Version empfangen.
Adapter ist am Montag in die Post gegangen.
LG
pah
Sehr gut, danke. Heute war er noch nicht da aber sobald er hier ist werde ich mal mein Glück versuchen.
schöne Grüße
Jo
Habe jetzt auch den ebus-koppler usb bestellt.
Sobald er da ist, werde ich loslegen.
@jojo:
Wir sollten in Kontakt bleiben wenn wir Befehle etc. für die ecotec plus finden, ok?
Auf jeden Fall, gerne.
schöne Grüße
Jo
Hi,
und noch mehr Details zu Vaillant: http://www.ip-symcon.de/forum/threads/19829-Vailant-Ecotec-Plus-und-VCR430-mit-eBus-steuern (http://www.ip-symcon.de/forum/threads/19829-Vailant-Ecotec-Plus-und-VCR430-mit-eBus-steuern)
Rainer
So, die ersten Schritte habe ich hinter mir.
Der ebus-Koppler ist angeschlossen, ebusd läuft auf einem separaten Raspberry Pi und diese Nachrichten gibt er aus:
2014-12-20 09:54:51.439 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c78f5
2014-12-20 09:54:55.462 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:54:59.439 [upd trace] update MS cmd: 1008b511010189 / 0959500080ff670100ff58
2014-12-20 09:55:05.438 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:55:09.454 [upd trace] update MS cmd: 1008b511010189 / 0959500080ff670100ff58
2014-12-20 09:55:15.453 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:55:19.462 [upd trace] update MS cmd: 1008b511010189 / 0959500080ff670100ff58
2014-12-20 09:55:21.428 [upd trace] update BC cmd: 10feb516080021550920120614bd
2014-12-20 09:55:21.664 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-20 09:55:25.504 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:55:29.478 [upd trace] update MS cmd: 1008b511010189 / 0959500080ff670100ff58
2014-12-20 09:55:31.461 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c78f5
2014-12-20 09:55:35.520 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:55:39.494 [upd trace] update MS cmd: 1008b511010189 / 0959500080ff670100ff58
2014-12-20 09:55:41.477 [upd trace] update BC cmd: 10feb5160301600777
2014-12-20 09:55:45.496 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
2014-12-20 09:55:49.512 [upd trace] update MS cmd: 1008b511010189 / 095a500080ff670100ff64
2014-12-20 09:55:51.531 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c78f5
2014-12-20 09:55:55.548 [upd trace] update MS cmd: 1008b5100900005a6effff00ff0080 / 01019a
Ich denke das sieht schon mal nicht schlecht aus ::)
Zitat von: Jochen68 am 20 Dezember 2014, 15:17:40Wäre es möglich, diesen "USB-Adapter-Typ" zu nennen (Bezeichnung) ?
Probier es mal mit der Bezeichnung FT232RL oder den Suchbegriffen USB und FTDI. Es gibt übrigens auch Adapter, die per Jumper zwischen 3,3V und 5V umschalten können. Das ist für diese Schaltung hier uninteressant, kann aber beim Experimentieren hilfreich sein.
Ich habe da mal auf Grundlage des Schaltplanes von pah einen Prototypen zusammengenagelt :D Mit dem, was ich so rumliegen hatte.
Läuft auch 8)
Das sieht ja ziemlich professionell aus für einen Prototypen :o
Ich verzweifle an dem Datensalat meiner Therme ???
Ebusd 0.5.0 läuft, telnet geht auch, aber irgendwie fehlt mir ein Minimalbeispiel, anhand dessen ich mal testen kann, wie man überhaupt Daten bekommt.
Wenn ich eine einzelne .csv-Datei erstelle und nur die eine Zeile aus dem wiki dort rein kopiere (http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)), mit welchem telnet-Befehl müsste sich dann die Aussentemperatur abrufen lassen? Spielt der Name der csv-Datei eine Rolle?
Mit cyc broad temp z.B. erhalte ich nur immer "command not found".
schöne Grüße
Jo
Das liegt daran, dass in Version 0.5.0 die csv-Dateien ein ganz anderes Format haben :-X
In Version 0.5.0 können derzeit auch keine Broadcasts gelesen werden :-\ :-\ :-\
Minimalbeispiele gibt es hier https://github.com/yuhu-/ebusd-configuration
Bis das alles behoben ist, vlt. besser Version 0.4. nehmen
Ich stehe mit den Entwicklern diesbezüglich schon in der Diskussion
LG
pah
Ok. Das hilft erstmal. Dann teste ich mal die ältere Version.
schöne Grüße
Jo
@UweH: Niedlich im Vergleich zu meiner Experimemtierplatine. Dazu fehlt mir dann doch immer dieZeit - so läuft z.B. mein 1-Wire-WIFI Interface immer noch auf einem Breadboard...
Spannungsregler und 2. Optokoppler sind wo ?
LG
pah
Solange es läuft... :)
Der Spannungsregler ist rechts neben der Gleichrichterbrücke, der (Dual-) Optokoppler wie auch die Z7,5 auf der anderen Seite, da sieht man jetzt nur die Lötpads. Leider hatte ich vor ein paar Tagen nicht tief genug in der Optokopplerkiste gewühlt. Ich hab gerade invertierende CMOS-Koppler gefunden, da könnte man sich wiederum den 4011 sparen. Viellicht mache ich mich in den nächsten Tagen nochmal dran zu schaffen...
Wenn man nach USB/RS232 Adpater oder Interface sucht, findet man eigentlich eine ziemlich große Auswahl...nur mal als Beispiel: http://www.alibaba.com/product-detail/USB-to-serial-UART-FTDI-interface_116816233.html (http://www.alibaba.com/product-detail/USB-to-serial-UART-FTDI-interface_116816233.html) oder
http://www.digikey.de/product-detail/de/USB-RS232-PCBA/768-1066-ND/2402470 (http://www.digikey.de/product-detail/de/USB-RS232-PCBA/768-1066-ND/2402470).
Das Bauteil, welches pah verwendet hat, hab ich aber auch nicht gefunden. Vielleicht verrät er seine Quelle noch... ;)
@Jochen68: Nun, das mit der fettgedruckten Zeile klärt dann die Frage nach weiterem Support für denjenigen.
@UweH: http://www.elv.de/mini-usb-modul-um2102-komplettbausatz.html. Wobei "Bausatz" ein Witz ist, die Stiftleisten kann man auch weglassen.
pah
Ach wie niedlich...für mich ist der Preis eher ein Witz. Der nackte FT232 kostet bei Reichelt 2,95. Plus dem restlichen Hühnerfutter bin ich bei ca. 8€ ohne Platine.
Stimmt. Ich habe diesen Tonfall nämlich ziemlich gefressen.
pah
Es gibt ein Update der ebusd-Software, sie kann jetzt produktiv verwendet werden. Die Versionsnummer ist zwar immer noch 0.5.0, aber broadcasts werden gelesen. Eine Anleitung zur Konfiguration (allerdings etwas rudimentär) findet man hier:
https://github.com/yuhu-/ebusd/wiki/Configuration
LG
pah
P.S.: Nachdem "Jochen68" auch bei den Anfängerfragen durch seinen mauligen Tonfall unangenehm aufgefallen ist, sollte er sich vielleicht privat mit den "kompetenteren Entwicklern" unterhalten und hier im Forum nicht mehr stören.
Danke für die Info. Dann werde ich mich doch mal an die neue Version wagen.
schöne Grüße
Jo
@Jojo:
Bist du schon weiter? Mein Ebus-Adapter kommt vermutlich morgen in die Packstation.
Dann möchte ich auch loslegen mit meiner Vaillent ecoTec Plus...
Hast du schon eine erste cfg zum Starten erstellt, die mit Version 0.5.0 läuft?
Im Prinzip funktioniert das setup. Mit den Beispiel-csv's kann ich einige wenige Werte per telnet abrufen. Die Rückgabewerte sind teilweise negativ und führen zu Abbrüchen des Daemons. Zur systematischen Untersuchung fehlt mir ein wenig die Dokumentation. Meine Therme scheint hauptsächlich B510, 511, 512 und 516 zu verwenden. Dazu finde ich aber nur wenige Informationen. Bis zur vollen Kontrolle dauert es wohl noch ;)
schöne Grüße
Jo
Im Ordner contrib/EBUS gibt es ein Sammelsurium von Dateien: Eine in Überarbeitung befindliche Dokumentaton des eBus für Vaillant-Geräte, eine Tabelle dazu, die gegenwärtige (noch sehr unreife) Version meiner Konfigurationsdatei vrs620.csv/ods (für Version 0.5.0 des ebusd), mehrere Class-Dateien für das ECMD_Device sowie ein Satz von Routinen für das Postprocessing der Werte.
Aus Sicherheitsgründen sind keine Befehle in meinen CSV-Dateien, die den Zustand der Heizung verändern könnten. Verwendung ohne Gewähr und Gewährleistung.
LG
pah
Vielen Dank! Ich denke dass ich auf dieser Basis etwas systematischer vorgehen kann.
[Nachtrag]
Kurze Rückmeldung:
Von den Broadcast Parametern funktionieren OutsideTempB, DateTimeB und StatusHC.
Weiterhin funktioniert das Auslesen von RoomTemp, HolidayRoomSetTemp und LcdContrast. Das ist immerhin schon ein guter Anfang.
Bei vielen anderen Parametern erhalte ich als Fehlermeldung "<<< ERR: invalid position. Segmentation fault". Manchmal gibt es dazu noch einen (falschen) numerischen Wert: "<<< -1616.00;ERR: invalid position. Segmentation fault.
Bei OperatingMode z.B. erhalte ich als Fehlermeldung "<<< ERR: read timeout. Segmentation fault".
Weiterhin ist mir aufgefallen, dass der Daemon jedesmal beendet wird, wenn ich per telnet einen Wert mit read auslese (feature?).
schöne Grüße
Jo
@JoJo11:
"It's not a feature, it's a bug" ;)
Ich habe die 0.3er Version des eBus-Daemons seit einigen Monate im Einsatz und bin damit sehr zufrieden. Hab mir gestern auch mal die aktuelle 0.5-Beta heruntergeladen, dabei die gleichen Probleme festgestellt und an Roland, den super engagierten Entwickler von ebusd zurückgemeldet. In der Thread-Verwaltung für die expliziten ebus-Anfragen knallt es zumindest noch bei mir (compiliert auf dem RPI),
Wenn Du also erste Erfahrungen sammeln möchtest, empfehle ich eher noch eine der Vorgängerversionen.
Am Besten erst einmal den ebus scannen, damit Du siehst, welche Komponenten anliegen und welche Kommando-Dateien eingesetzt werden können (ebusctrl scan). Das Ergebnis sieht dann ungefähr so aus:
06: 'Joh. Vaillant GmbH & Co.' ident: 'PMS00' sw: '01.07' hw: '43.02' s/n: '21122100301069873190005119N1' item: '0020061355'
08: 'Joh. Vaillant GmbH & Co.' ident: 'EHP00' sw: '04.16' hw: '72.01' s/n: '21114700100090700007125407N2' item: '0010004560'
Für diese Komponenten findest Du im Contrib-Ordner https://github.com/yuhu-/ebusd-configuration (https://github.com/yuhu-/ebusd-configuration) vielleicht schon die entsprechende Referenz. Eine Garantie gibt es allerdings nicht. Inbesondere bei den "set"-Befehlen (ab 0.5 heißen diese "write") sollte man sich hüten diese ahnungslos durchzuprobieren. Man weiß nie, welche Register man damit eventuell verstellt.
Danke. Ich würde mich halt ungern in eine "alte" Version einarbeiten, die andere Befehle verwendet.
Den scan werde ich mal durchführen. Die Beispiel-Dateien habe ich schon durchgetestet, komme aber damit nicht sehr weit. Set-Befehle werde ich natürlich bis auf Weiteres nicht testen :o
schöne Grüße
Jo
Kann ich nicht nachvollziehen.
Zum Testen von Befehlen nutze ich immer ebusctl direkt auf dem Raspberry - telnet ist da viel zu instabil.
Telnet wird allerdings vom EBUS-Device benutzt, und da bemerke ich keinerlei Abbrüche.
LG
pah
Mein ebus-USB-Wandler ist eingetroffen.
Allerdings scheitere ich schon an der Installation von ebusd - ich finde keine Schritt-für-Schritt-Anleitung, die funktioniert.
Könnte jemand die Schritte posten, inkl. holen der Dateien aus dem Repository & Kompilieren?
Vielen Dank.
svn co https://github.com/yuhu-/ebusd
cd ebusd/trunk
autogen.sh
make
make install
LG
pah
Zitat von: Prof. Dr. Peter Henning am 23 Dezember 2014, 13:52:52
[...]
Zum Testen von Befehlen nutze ich immer ebusctl direkt auf dem Raspberry - telnet ist da viel zu instabil.
[...]
Hab's gerade mal mit ebusctl getestet. Ich erhalte identische Fehlermeldungen und je nachdem auch Abbrüche des Dämons.
Werde nun erstmal den scan durchlaufen lassen.
@heikoh81
Ich musste autoconf noch installieren:
sudo modprobe -v ftdi_sio
sudo apt-get install autoconf
sudo wget https://github.com/yuhu-/ebusd/archive/master.zip
sudo unzip master.zip
cd ebusd-master
sudo ./autogen.sh
sudo make
sudo make install
schöne Grüße
Jo
Danke für die schnelle Antwort. Das make hat geklappt.
Zunächst musste ich aber noch folgende Pakete installieren:
apt-get install automake
apt-get install subversion
Ein kleiner Fehler in der Anleitung von pah war noch, es muss heißen:
./autogen.sh
Und wie rufe ich den ebusd dann auf?
Die gängigen Befehle scheitern leider:
/usr/bin/ebusd/ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777 -s
/etc/init.d/ebusd
Was heißt "scheitern" ? Muss doch eine Fehlermeldung da sein.
Wichtig:
Verzeichnis /etc/ebusd muss mindestens die Datei _templates.csv enthalten, in /etc/default/ebusd steht bei mir
# Default settings for ebusd. This file is sourced by /bin/sh from
# /etc/init.d/ebusd.
# Options to pass to ebusd
EBUSD_OPTS="-l All -d /dev/ttyUSB0"
Die Konfigurationsbeispiele bekommt man mit
svn co https://github.com/yuhu-/ebusd-configuration
LG
pah
Oder nur damit auf der Konsole ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
Befehl von UweH liefert:
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
2014-12-23 17:37:01.382 [bas event] ebusd started
2014-12-23 17:37:01.384 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-23 17:37:01.384 [bas error] error reading templates: ERR: file/element n ot found or not readable
2014-12-23 17:37:01.385 [bas error] error reading config files: ERR: file/elemen t not found or not readable
2014-12-23 17:37:01.385 [bas event] message DB: 0
2014-12-23 17:37:01.385 [bas event] updates DB: 0
2014-12-23 17:37:01.385 [bas event] polling DB: 0
/etc/init.d/ebusd liefert leider:
-bash: /etc/init.d/ebusd: No such file or directory
Update:
Die Anzeige oben aktualisiert leider nichts.
Am Ebus-Wandler USB blinkt die orangene LED ca. 1x je Sekunde, manchmal flackert sie auch.
Also Daten vom Ebus scheinen anzukommen, Befehle vom Parallel geschalteten Calormatic 470 werden sofort an der Therme umgesetzt.
Als erstes den ebus-Daemon starten, je nachdem wo dieser installiert ist, zum Beispiel
sudo /usr/local/bin/ebusd
Für die ersten Schritte würde ich den Daemon aber im Vordergrund laufen lassen, damit man das Prinzip besser versteht:
sudo /usr/local/bin/ebusd -f
Mit der Option -h kann man sich die anderen Optionen anschauen, welche ohne explizite Angabe mit sinnvollen Standardwerten vorbelegt sind.
Insbesondere die Option --checkconfig in der neuen Version 0.5 ist hierbei sehr sinnvoll. Sie sollte nach erfolgter Installation und dem Einspielen der csv-Kommandodateien genutzt werden, um die konsistente Konfiguration zu prüfen.
Nach erfolgreichem Start protokolliert der Daemon den gesamten "erspähten" eBus-Datenverkehr entweder zum Terminal (wenn Option -f) oder in das Logfile (zum Beispiel /var/log/ebusd.log).
Entweder via Telnet (oder in der neuesten 0.5er Version auch via Hilfsprogramm ebusctrl), kann man Kommandos beim ebus-Daemon absetzen.
Hierzu einfach mal das Wiki anschauen (https://github.com/yuhu-/ebusd/wiki/Daemon-Commands (https://github.com/yuhu-/ebusd/wiki/Daemon-Commands)).
BTW: Ich habe einen von den kommerziell vertriebenen ebus-Kopplern. Bevor dieser überhaupt Werte ausspuckt, muss dieser zuvor noch kalibriert werden. Sollte ebusd stumm bleiben, lohnt es such, hier mit der Fehlersuche zu beginnen.
@estege:
ich habe auch den kommerziellen USB-Wandler von eservice-online.
Ich sehe auf dem Hutschienen-Gehäuse aber keinen Poti oder dergleichen - wie also kalibrieren?
Update:
Manchmal sollte man doch in den Beipackzettel gucken.
Poti ist neben den Anschlussklemmen vorhanden. Wenn ich drehe, blinkt die Bus-LED fast durchgehend.
Leider ändert das am Output aber nichts, der steht so wie oben beschrieben.
Würde die Kommandozeile auch Rohdaten ausspucken, wenn keine Config-Dateien hinterlegt sind?
Heikoh81:
Wenn das Teilt blinkt, werden Daten empfangen. Ansonsten wurde doch ein kleiner Schraubendreher dazu geliefert, mit dem man an einer Stelle (verdeckt) den Poti einstellen kann.
Deine Installation scheint nicht vollständig zu sein (siehe Fehlermeldung beim Starten). Du solltest noch die csv-Konfigdateien herunterladen und den configcheck durchführen.
Poti habe ich gefunden.
Ich habe jetzt mal den Pfad
/etc/ebusd (merkwürdig, dass es den noch nicht gab?)
erstellt und dort eininge .csv abgelegt
Configcheck mache ich wie?
Wenn ich mich recht erinnere, hat der ebusd bei mir auch ohne csv-Dateien jede Menge Daten ausgegeben (siehe hier: http://forum.fhem.de/index.php/topic,29737.msg232957.html#msg232957 (http://forum.fhem.de/index.php/topic,29737.msg232957.html#msg232957)).
schöne Grüße
Jo
Das tut er, in der Tat.
LG
pah
Also
ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
liefert bei mir nur:
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
2014-12-23 18:22:48.507 [bas event] ebusd started
2014-12-23 18:22:48.508 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-23 18:22:48.514 [bas error] error reading templates: ERR: file/element not found or not readable
2014-12-23 18:22:48.518 [bas error] error reading config files: ERR: file/element not found or not readable
2014-12-23 18:22:48.530 [bas event] message DB: 0
2014-12-23 18:22:48.532 [bas event] updates DB: 0
2014-12-23 18:22:48.534 [bas event] polling DB: 0
Orangene LED blinkt durchgehend gedimmt, abundzu wird sie kurz heller.
Grüne LED neben den Klemmen leuchtet durchgehend.
Läuft auf dem selben Rechner evtl. auch fhem mit aktivierter USB-Autoerkennung?
schöne Grüße
Jo
JA! fhem wird aber gar nicht mehr benötigt, ist noch mit drauf.
Ich habe es mal auskommentiert.
Könnte es sein, dass die USB-Stromversorgung nicht ausreicht?
Es hängt noch ein Wifi-USB-Adapter am Raspi, neben dem ebus-Wandler.
ERFOLG. FHEM-USB hat den Wanlder blockiert.
Jetzt kommt:
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
2014-12-23 19:04:55.835 [bas event] ebusd started
2014-12-23 19:04:55.835 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-23 19:04:55.837 [bas error] error reading templates: ERR: file/element not found or not readable
2014-12-23 19:04:55.838 [bas trace] read config files
2014-12-23 19:04:55.838 [bas event] message DB: 0
2014-12-23 19:04:55.838 [bas event] updates DB: 0
2014-12-23 19:04:55.838 [bas event] polling DB: 0
2014-12-23 19:04:57.233 [upd trace] update BC cmd: 10feb51608005904192312021486
2014-12-23 19:04:57.472 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-23 19:05:01.278 [upd trace] update MS cmd: 1008b5100900006cffffff04ff004a / 01019a
2014-12-23 19:05:05.377 [upd trace] update MS cmd: 1008b511010189 / 096b614003ff2d0100ffe7
2014-12-23 19:05:07.378 [upd trace] update MS cmd: 1008b50401003d / 0a0309051923120214400387
2014-12-23 19:05:07.638 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
Sieht gut aus, oder?
Zitat von: heikoh81 am 23 Dezember 2014, 19:05:13
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
Hi @all,
ja sieht gut aus.
ALL ist bereits der default LogLevel. Ebenso /dev/ttyUSB0 als default Device. Solltest du also beides nicht benötigen.
lg roland
Hallo zusammen,
ich bekomme bei einem "ebusctl scan full" in undefinierten Zeitabständen (mal nach 2 Sekunden mal nach 10 mal später...) folgende Meldung:
2014-12-23 21:22:25.058 [bus error] scan 52 failed: ERR: read timeout
2014-12-23 21:22:25.549 [bus error] ERR: arbitration lost, retry
2014-12-23 21:22:25.889 [bus error] scan 54 failed: ERR: read timeout
2014-12-23 21:22:26.432 [bus error] scan 55 failed: ERR: read timeout
2014-12-23 21:22:26.979 [bus error] scan 56 failed: ERR: read timeout
2014-12-23 21:22:27.520 [bus error] scan 57 failed: ERR: read timeout
2014-12-23 21:22:28.072 [bus error] scan 58 failed: ERR: read timeout
2014-12-23 21:22:28.592 [bus error] scan 59 failed: ERR: read timeout
2014-12-23 21:22:29.123 [bus error] scan 5a failed: ERR: read timeout
2014-12-23 21:22:29.697 [bus error] scan 5b failed: ERR: read timeout
2014-12-23 21:22:30.232 [bus error] scan 5c failed: ERR: read timeout
2014-12-23 21:22:30.756 [bus error] scan 5d failed: ERR: read timeout
2014-12-23 21:22:30.835 [bus error] scan 5e failed: ERR: read timeout
2014-12-23 21:22:31.327 [bus error] ERR: arbitration lost, retry
2014-12-23 21:22:32.083 [bus error] scan 60 failed: ERR: read timeout
2014-12-23 21:22:32.593 [bus error] ERR: arbitration lost, retry
2014-12-23 21:22:32.928 [bus error] scan 62 failed: ERR: read timeout
2014-12-23 21:22:33.428 [bus error] scan 63 failed: ERR: read timeout
pure virtual method called
terminate called without an active exception
/etc/ebusd/start.sh: Zeile 2: 32582 Abgebrochen ebusd -a answer -d x.x.x.x:5000 -n -f -p 8888 -f -c /etc/ebusd checkconfig
Keine(fast) der vorhanden/breitgestellten (dankenswerterweise) Konfigs bzw. Parameter funktionieren bei mir (Therme: VSC 196/2 -C 150 und Colormatic VRC 430) wenn dann muss ich schon Glück haben eine zu erwischen die den Ebusd nicht direkt killt. Fehlermeldung sieht dann in etwa so aus (wobei diese aus dem normalen Lauf stamm mit der default config pms00.csv):
2014-12-23 21:33:40.780 [bas event] message DB: 31
2014-12-23 21:33:40.780 [bas event] updates DB: 0
2014-12-23 21:33:40.780 [bas event] polling DB: 6
2014-12-23 21:33:41.637 [bus trace] poll cmd: 0aedb509030d070062
2014-12-23 21:33:41.713 [bus error] poll pms00 BufferNtcTo failed: ERR: read timeout
2014-12-23 21:33:47.004 [bus trace] poll cmd: 0aedb509030d560003
2014-12-23 21:33:47.079 [bus error] poll pms00 YieldSum failed: ERR: read timeout
2014-12-23 21:33:53.010 [bus trace] poll cmd: 0aedb509030d0600f9
2014-12-23 21:33:53.084 [bus error] poll pms00 SolarNtcTo failed: ERR: read timeout
2014-12-23 21:33:58.399 [upd trace] update BC cmd: 10feb516080059332123120214e6
2014-12-23 21:33:59.018 [bus trace] poll cmd: 0aedb509030d3b00ec
2014-12-23 21:33:59.093 [bus error] poll pms00 YieldDay failed: ERR: read timeout
2014-12-23 21:34:05.020 [bus trace] poll cmd: 0aedb509030d0500cf
2014-12-23 21:34:05.030 [bus error] poll pms00 SolarNtcFrom failed: ERR: read timeout
/etc/ebusd/start.sh: Zeile 2: 710 Speicherzugriffsfehler ebusd -a answer -d x.xx.x:5000 -n -f -p 8888 -f -c /etc/ebusd checkconfig
Ach, ja ich verwende den LAN Adapter von e-Service.
Meine Vaillant Komponenten sind laut scan (irgendwan mit einer 0.3/0.4er eBusd Version gescannt):
08: 'Joh. Vaillant GmbH & Co.' ident: 'BAI00' sw: '05.16' hw: '74.01' item: '0010
15: 'Joh. Vaillant GmbH & Co.' ident: '43000' sw: '02.15' hw: '20.02' item: '0020
26: 'Joh. Vaillant GmbH & Co.' ident: '43000' sw: '02.15' hw: '20.02' item: '0020
Ich versuche seit ein paar Tagen(Wochen) - wenn die Zeit es zulässt - einen eigenen Deamon zu schreiben - den Broadcast habe ich schon im Griff, senden(read) bin ich dran.
Schöner wäre es den eBusd zu nutzen....
EDIT:
nur zur Info mit der "ehp00" Konfig habe ich auch das Problem:
2014-12-23 22:01:47.014 [bus trace] poll cmd: 0a08b509030d08005c
2014-12-23 22:01:47.032 [bus error] poll ehp00 BrineTempOutput failed: ERR: read timeout
2014-12-23 22:01:53.004 [bus trace] poll cmd: 0a08b509030d05001f
2014-12-23 22:01:53.084 [bus error] poll ehp00 EvaporatorTemp failed: ERR: read timeout
2014-12-23 22:01:57.047 [upd trace] update BC cmd: 10feb5160800580122231202142f
2014-12-23 22:01:59.017 [bus trace] poll cmd: 0a08b509030d040084
2014-12-23 22:01:59.096 [bus error] poll ehp00 CompressorTempOutput failed: ERR: read timeout
2014-12-23 22:02:05.002 [bus trace] poll cmd: 0a08b509030d0200e8
2014-12-23 22:02:05.082 [bus error] poll ehp00 CompressorTempInput failed: ERR: read timeout
2014-12-23 22:02:11.108 [bus trace] poll cmd: 0a08b509030d0d0006
2014-12-23 22:02:11.109 [bus error] poll ehp00 ExpansionValveInputTemp failed: SYN received
/etc/ebusd/start.sh: Zeile 2: 1941 Speicherzugriffsfehler ebusd -a answer -d x.x.x.x:5000 -n -f -p 8888 -f -c /etc/ebusd checkconfig
Grüße
Für deine Idents haben wir zur Zeit noch keine csv Dateien erstellt.
Zur Info. In den vorhandenen Konfigurationen ist Class gleich Ident und gleich dem Dateinnamen. Da für Class ein beliebiger Namen verwendet werden kann, heißt diese Feld jedoch Class.
Ah, der Entwickler von ebusd höchstpersönlich !
Freut mich, Herr Jax.
Die Konfigurationsdatei für die VRS620 läuft schon ganz gut jetzt. Probleme gibt es noch mit manchen verkorksten Datumsformaten von Vaillant. So z.B. lässt sich
17 0c 04
nicht als der 23.12.14 lesen.
LG
pah
Hallo Roland,
danke für die hilfreiche Info.
Speicherzugriffsfehler sollte dennoch nicht sein....
Ich werde mich dann mal durch den RAW Modus durchkämpfen.
Danke für die wirklich beieindruckende Arbeit(eBusd).
Hallo,
ein scan mit der aktuellen ebusd-Version ergibt bei mir Folgendes:
08;Joh. Vaillant GmbH & Co.;BAI00;0600;5502
14;Joh. Vaillant GmbH & Co.;rOD00;0115;0505
15;Joh. Vaillant GmbH & Co.;F4700;0114;6102
16;Joh. Vaillant GmbH & Co.;B7000;0120;6202
26;Joh. Vaillant GmbH & Co.;F4700;0114;6102
f6;Joh. Vaillant GmbH & Co.;F4700;0114;6102
schöne Grüße
Jo
Also bei mir kommen keine Synchronisation-Zeichen "AA", aber gültige Kommandos scheint der ebusd zu lesen.
Müssen Zeilen mit "AA" erscheinen (ebusd 0.5)?
Außerdem habe ich jetzt mal exemplarisch eine .csv von github nach /etc/ebusd gelegt.
Allerdings liefert ebusd --checkconfig folgendes:
root@fhemALT:~# ebusd --checkconfig
Error reading "/etc/ebusd/uih00.csv" line 5 field 14 value "": ERR: file/element not found or not readable
2014-12-24 10:47:08.050 [bas event] ebusd started
2014-12-24 10:47:08.051 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-24 10:47:08.052 [bas error] error reading templates: ERR: file/element not found or not readable
Erroneous item is here:
"r","","HolidayPeriod","Ferien Zeitraum","","","","4300","","","holiday","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 6 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","HolidayRoomSetTemp","Ferien Solltemperatur","","","","2200","","","temp","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 7 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","Password","Kennwort","","","","2C00","","","pin1-4","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 8 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","DesiredTemp","Solltemperatur","","","","0500","","","temp","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 9 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r1","","FlowTempSensor","Vorlauftemperatur Ist","","","","0200","","","tempsensor","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 12 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","TempIncrease","Temperaturüberhöhung","","","","2F00","","","temp","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 14 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","FrostProtectionDelayTime","Frostschutzverzögerung","","","","2E00","","","hours","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 15 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","TempErrorDetectTime","Temperaturfehlererkennung","","","","3300","","","hours","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 34 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","HeatBufferAvailable","Bufferspeicher vorhanden","","","","5C00","","","yesno","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 35 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear1","Energieertrag aktuelles Jahr Monat 1","","","","8400","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 36 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear2","Energieertrag aktuelles Jahr Monat 2","","","","8408","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 37 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear3","Energieertrag aktuelles Jahr Monat 3","","","","8410","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 38 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear4","Energieertrag aktuelles Jahr Monat 4","","","","8418","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 39 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear5","Energieertrag aktuelles Jahr Monat 5","","","","8420","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 40 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear6","Energieertrag aktuelles Jahr Monat 6","","","","8428","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 41 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear7","Energieertrag aktuelles Jahr Monat 7","","","","8430","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 42 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear8","Energieertrag aktuelles Jahr Monat 8","","","","8438","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 43 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear9","Energieertrag aktuelles Jahr Monat 9","","","","8440","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 44 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear10","Energieertrag aktuelles Jahr Monat 10","","","","8448","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 45 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear11","Energieertrag aktuelles Jahr Monat 11","","","","8450","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 46 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldThisYear12","Energieertrag aktuelles Jahr Monat 12","","","","8458","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 47 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear1","Energieertrag letztes Jahr Monat 1","","","","8500","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 48 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear2","Energieertrag letztes Jahr Monat 2","","","","8508","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 49 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear3","Energieertrag letztes Jahr Monat 3","","","","8510","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 50 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear4","Energieertrag letztes Jahr Monat 4","","","","8518","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 51 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear5","Energieertrag letztes Jahr Monat 5","","","","8520","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 52 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear6","Energieertrag letztes Jahr Monat 6","","","","8528","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 53 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear7","Energieertrag letztes Jahr Monat 7","","","","8530","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 54 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear8","Energieertrag letztes Jahr Monat 8","","","","8538","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 55 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear9","Energieertrag letztes Jahr Monat 9","","","","8540","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 56 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear10","Energieertrag letztes Jahr Monat 10","","","","8548","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 57 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear11","Energieertrag letztes Jahr Monat 11","","","","8550","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 58 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","EnergyYieldLastYear12","Energieertrag letztes Jahr Monat 12","","","","8558","","","energy","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 59 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r1","","EnergyYieldDayTransfer","Energieertrag Tagesübertrag","","","","8600","","","energy4","","","","","","","","",""
^
Error reading "/etc/ebusd/uih00.csv" line 60 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r1","","EnergyYieldSum","Energieertrag Gesamt","","","","8700","","","energy4","","","","","","","","",""
^
2014-12-24 10:47:08.148 [bas trace] read config files
2014-12-24 10:47:08.150 [bas event] message DB: 24
2014-12-24 10:47:08.151 [bas event] updates DB: 0
2014-12-24 10:47:08.152 [bas event] polling DB: 0
2014-12-24 10:47:08.154 [bas event] ebusd stopped
Woran könnte das nun liegen?
Zumindest scheint ebusd die Datei lesen zu können?
1. Nein, AA _darf_ nicht erscheinen.
2. Steht die Datei _templates.csv in /etc/ebusd ? _Muss_ dorthin.
LG
pah
Morgen,
zum Einstellen des Adapters eignet sich die Option --lograwdata. Damit wird im Logfile jedes Byte ausgegeben.
Dort sollten zwischen den Nachrichten viele SYN-Zeichen (AA) zu sehen sein.
Beim Starten vom ebusd werden bis zum ersten, sinnvollen Telegramm nur 00 ausgegeben.
Bei mir sieht das wie folgt aus.
root@raspberrypi:~/tmp/ebusd# src/ebusd/ebusd -f --lograwdata
2014-12-24 11:24:00.728 [bas event] ebusd started
2014-12-24 11:24:00.729 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-24 11:24:00.742 [bas trace] read templates
2014-12-24 11:24:00.943 [bas trace] read config files
2014-12-24 11:24:00.944 [bas event] message DB: 545
2014-12-24 11:24:00.945 [bas event] updates DB: 26
2014-12-24 11:24:00.947 [bas event] polling DB: 25
2014-12-24 11:24:00.954 [bus event] <00
2014-12-24 11:24:00.957 [bus event] <aa
2014-12-24 11:24:00.990 [bus event] <00
2014-12-24 11:24:00.992 [bus event] <00
2014-12-24 11:24:00.994 [bus event] <00
2014-12-24 11:24:00.996 [bus event] <00
2014-12-24 11:24:00.999 [bus event] <00
2014-12-24 11:24:01.001 [bus event] <00
2014-12-24 11:24:01.004 [bus event] <00
2014-12-24 11:24:01.006 [upd trace] update MM cmd: 000000000000
2014-12-24 11:24:01.008 [bus event] <00
2014-12-24 11:24:01.011 [bus event] <00
2014-12-24 11:24:01.013 [bus event] <00
2014-12-24 11:24:01.015 [bus event] <00
2014-12-24 11:24:01.017 [bus event] <00
2014-12-24 11:24:01.020 [bus event] <00
2014-12-24 11:24:01.022 [bus event] <00
2014-12-24 11:24:01.025 [bus event] <00
2014-12-24 11:24:01.027 [bus event] <00
2014-12-24 11:24:01.029 [bus event] <00
2014-12-24 11:24:01.032 [bus event] <00
2014-12-24 11:24:01.034 [bus event] <00
2014-12-24 11:24:01.037 [bus event] <00
2014-12-24 11:24:01.039 [bus event] <00
2014-12-24 11:24:01.042 [bus event] <00
2014-12-24 11:24:01.044 [bus event] <00
2014-12-24 11:24:01.047 [bus event] <00
2014-12-24 11:24:01.049 [bus event] <00
2014-12-24 11:24:01.051 [bus event] <00
2014-12-24 11:24:01.054 [bus event] <00
2014-12-24 11:24:01.056 [bus event] <00
2014-12-24 11:24:01.058 [bus event] <00
2014-12-24 11:24:01.061 [bus event] <00
2014-12-24 11:24:01.063 [bus event] <00
2014-12-24 11:24:01.065 [bus event] <00
2014-12-24 11:24:01.068 [bus event] <00
2014-12-24 11:24:01.071 [bus event] <00
2014-12-24 11:24:01.073 [bus event] <00
2014-12-24 11:24:01.075 [bus event] <00
2014-12-24 11:24:01.077 [bus event] <00
2014-12-24 11:24:01.080 [bus event] <00
2014-12-24 11:24:01.082 [bus event] <aa
2014-12-24 11:24:01.085 [bus event] <aa
2014-12-24 11:24:01.087 [bus event] <aa
2014-12-24 11:24:01.121 [bus event] <aa
2014-12-24 11:24:01.123 [bus trace] poll cmd: ffedb509030d0700b0
2014-12-24 11:24:01.125 [bus event] >ff
2014-12-24 11:24:01.131 [bus event] <ff
2014-12-24 11:24:01.134 [bus event] >ed
2014-12-24 11:24:01.141 [bus event] <ed
2014-12-24 11:24:01.143 [bus event] >b5
2014-12-24 11:24:01.149 [bus event] <b5
2014-12-24 11:24:01.151 [bus event] >09
2014-12-24 11:24:01.157 [bus event] <09
2014-12-24 11:24:01.160 [bus event] >03
2014-12-24 11:24:01.166 [bus event] <03
2014-12-24 11:24:01.168 [bus event] >0d
2014-12-24 11:24:01.174 [bus event] <0d
2014-12-24 11:24:01.177 [bus event] >07
2014-12-24 11:24:01.183 [bus event] <07
2014-12-24 11:24:01.185 [bus event] >00
2014-12-24 11:24:01.191 [bus event] <00
2014-12-24 11:24:01.194 [bus event] >b0
2014-12-24 11:24:01.200 [bus event] <b0
2014-12-24 11:24:01.204 [bus event] <00
2014-12-24 11:24:01.209 [bus event] <04
2014-12-24 11:24:01.212 [bus event] <30
2014-12-24 11:24:01.216 [bus event] <02
2014-12-24 11:24:01.220 [bus event] <00
2014-12-24 11:24:01.224 [bus event] <00
2014-12-24 11:24:01.229 [bus event] <e8
2014-12-24 11:24:01.232 [bus event] >00
2014-12-24 11:24:01.237 [bus event] <00
2014-12-24 11:24:01.240 [bus event] poll pms00 BufferNtcTo: 35.00;ok
2014-12-24 11:24:01.243 [bus event] >aa
2014-12-24 11:24:01.249 [bus event] <aa
2014-12-24 11:24:01.293 [bus event] <aa
2014-12-24 11:24:01.336 [bus event] <aa
2014-12-24 11:24:01.380 [bus event] <aa
2014-12-24 11:24:01.424 [bus event] <aa
2014-12-24 11:24:01.469 [bus event] <aa
2014-12-24 11:24:01.513 [bus event] <aa
2014-12-24 11:24:01.557 [bus event] <aa
2014-12-24 11:24:01.600 [bus event] <aa
2014-12-24 11:24:01.644 [bus event] <aa
2014-12-24 11:24:01.688 [bus event] <aa
2014-12-24 11:24:01.732 [bus event] <aa
2014-12-24 11:24:01.776 [bus event] <aa
2014-12-24 11:24:01.821 [bus event] <aa
2014-12-24 11:24:01.865 [bus event] <aa
2014-12-24 11:24:01.909 [bus event] <aa
2014-12-24 11:24:01.952 [bus event] <aa
2014-12-24 11:24:01.997 [bus event] <aa
2014-12-24 11:24:02.041 [bus event] <aa
2014-12-24 11:24:02.084 [bus event] <aa
2014-12-24 11:24:02.129 [bus event] <aa
2014-12-24 11:24:02.173 [bus event] <aa
2014-12-24 11:24:02.217 [bus event] <aa
2014-12-24 11:24:02.261 [bus event] <aa
2014-12-24 11:24:02.304 [bus event] <aa
2014-12-24 11:24:02.310 [bus event] <10
2014-12-24 11:24:02.317 [bus event] <08
2014-12-24 11:24:02.321 [bus event] <b5
2014-12-24 11:24:02.326 [bus event] <09
2014-12-24 11:24:02.330 [bus event] <03
2014-12-24 11:24:02.334 [bus event] <29
2014-12-24 11:24:02.338 [bus event] <01
2014-12-24 11:24:02.342 [bus event] <00
2014-12-24 11:24:02.347 [bus event] <23
2014-12-24 11:24:02.350 [bus event] <00
2014-12-24 11:24:02.355 [bus event] <05
2014-12-24 11:24:02.359 [bus event] <01
2014-12-24 11:24:02.364 [bus event] <00
2014-12-24 11:24:02.368 [bus event] <13
2014-12-24 11:24:02.372 [bus event] <02
2014-12-24 11:24:02.376 [bus event] <00
2014-12-24 11:24:02.381 [bus event] <a4
2014-12-24 11:24:02.385 [bus event] <00
2014-12-24 11:24:02.386 [upd trace] update MS cmd: 1008b5090329010023 / 050100130200a4
2014-12-24 11:24:02.388 [upd event] update ehp00 hwFlowTemp: 33.19;ok
2014-12-24 11:24:02.391 [bus event] <aa
2014-12-24 11:24:02.432 [bus event] <aa
2014-12-24 11:24:02.476 [bus event] <aa
2014-12-24 11:24:02.481 [bus event] <10
2014-12-24 11:24:02.489 [bus event] <fe
2014-12-24 11:24:02.494 [bus event] <b5
2014-12-24 11:24:02.498 [bus event] <05
2014-12-24 11:24:02.502 [bus event] <04
2014-12-24 11:24:02.506 [bus event] <27
2014-12-24 11:24:02.511 [bus event] <00
2014-12-24 11:24:02.515 [bus event] <19
2014-12-24 11:24:02.519 [bus event] <00
2014-12-24 11:24:02.523 [bus event] <23
2014-12-24 11:24:02.524 [upd trace] update BC cmd: 10feb505042700190023
2014-12-24 11:24:02.527 [bus event] <aa
2014-12-24 11:24:02.571 [bus event] <aa
2014-12-24 11:24:02.615 [bus event] <aa
2014-12-24 11:24:02.658 [bus event] <aa
2014-12-24 11:24:02.703 [bus event] <aa
2014-12-24 11:24:02.747 [bus event] <aa
2014-12-24 11:24:02.791 [bus event] <aa
2014-12-24 11:24:02.836 [bus event] <aa
2014-12-24 11:24:02.878 [bus event] <aa
2014-12-24 11:24:02.923 [bus event] <aa
2014-12-24 11:24:02.967 [bus event] <aa
2014-12-24 11:24:02.971 [bus event] <10
2014-12-24 11:24:02.980 [bus event] <fe
2014-12-24 11:24:02.984 [bus event] <b5
2014-12-24 11:24:02.988 [bus event] <05
2014-12-24 11:24:02.992 [bus event] <03
2014-12-24 11:24:02.995 [bus event] <4a
2014-12-24 11:24:03.000 [bus event] <01
2014-12-24 11:24:03.004 [bus event] <00
2014-12-24 11:24:03.008 [bus event] <f4
2014-12-24 11:24:03.009 [upd trace] update BC cmd: 10feb505034a0100f4
2014-12-24 11:24:03.012 [bus event] <aa
^C2014-12-24 11:24:03.035 [bas event] SIGINT received
2014-12-24 11:24:03.056 [bus event] <aa
2014-12-24 11:24:03.100 [bus event] <aa
2014-12-24 11:24:03.145 [bus event] <aa
2014-12-24 11:24:03.155 [bas event] ebusd stopped
_template.csv fehlte noch. Jetzt scheint es zu gehen - yuhuu.
Ist das was da erscheint sinnvoll?
Hinweis: Einen eneryyield (=Ertrag) kann ich nicht habe, da keine Solaranlage. Ich habe nur eine Brennwerttherme ohne jegliche Solartechnik oder ohne Wärmepumpe.
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 7777
2014-12-24 11:49:51.869 [bas event] ebusd started
2014-12-24 11:49:51.869 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-24 11:49:51.885 [bas trace] read templates
2014-12-24 11:49:51.910 [bas trace] read config files
2014-12-24 11:49:51.912 [bas event] message DB: 59
2014-12-24 11:49:51.913 [bas event] updates DB: 0
2014-12-24 11:49:51.914 [bas event] polling DB: 3
2014-12-24 11:49:52.110 [upd trace] update MS cmd: 1008b51009000061ffffff04ff006a / 01019a
2014-12-24 11:49:52.158 [bus trace] poll cmd: ff15b509030d870075
2014-12-24 11:49:52.259 [bus event] poll uih00 EnergyYieldSum: 1677722376
2014-12-24 11:49:58.039 [bus trace] poll cmd: ff15b509030d8600ee
2014-12-24 11:49:58.129 [bus error] poll uih00 EnergyYieldDayTransfer failed: ERR: invalid position
2014-12-24 11:49:58.231 [upd trace] update MS cmd: 1008b511010189 / 09615a5007ff690100ff0d
2014-12-24 11:50:00.148 [upd trace] update BC cmd: 10feb5160800035011241203140e
2014-12-24 11:50:00.386 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-24 11:50:02.167 [upd trace] update MS cmd: 1008b51009000061ffffff04ff006a / 01019a
2014-12-24 11:50:04.024 [bus trace] poll cmd: ff15b509030d020024
2014-12-24 11:50:04.114 [bus error] poll uih00 FlowTempSensor failed: ERR: invalid position
2014-12-24 11:50:08.270 [upd trace] update MS cmd: 1008b511010189 / 09615a5007ff690100ff0d
2014-12-24 11:50:10.043 [bus trace] poll cmd: ff15b509030d870075
2014-12-24 11:50:10.141 [bus event] poll uih00 EnergyYieldSum: 1677722376
2014-12-24 11:50:10.376 [upd trace] update MS cmd: 1008b50401003d / 0a031150112412031450078a
2014-12-24 11:50:10.635 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-24 11:50:12.376 [upd trace] update MS cmd: 1008b51009000061ffffff04ff006a / 01019a
2014-12-24 11:50:16.041 [bus trace] poll cmd: ff15b509030d8600ee
2014-12-24 11:50:16.132 [bus error] poll uih00 EnergyYieldDayTransfer failed: ERR: invalid position
2014-12-24 11:50:18.472 [upd trace] update MS cmd: 1008b511010189 / 09615a5007ff690100ff0d
Ok, so sieht es bei mir mit --lograwdata aus. Ist dann mein Poti korrekt eingestellt oder sind das zuviele AA:
2014-12-24 11:48:38.874 [bus event] <01
2014-12-24 11:48:38.878 [bus event] <00
2014-12-24 11:48:38.882 [bus event] <3d
2014-12-24 11:48:38.888 [bus event] <00
2014-12-24 11:48:38.898 [bus event] <0a
2014-12-24 11:48:38.902 [bus event] <03
2014-12-24 11:48:38.905 [bus event] <40
2014-12-24 11:48:38.909 [bus event] <48
2014-12-24 11:48:38.913 [bus event] <11
2014-12-24 11:48:38.918 [bus event] <24
2014-12-24 11:48:38.922 [bus event] <12
2014-12-24 11:48:38.926 [bus event] <03
2014-12-24 11:48:38.930 [bus event] <14
2014-12-24 11:48:38.935 [bus event] <50
2014-12-24 11:48:38.939 [bus event] <07
2014-12-24 11:48:38.944 [bus event] <69
2014-12-24 11:48:38.948 [bus event] <00
2014-12-24 11:48:38.949 [upd trace] update MS cmd: 1008b50401003d / 0a0340481124120314500769
2014-12-24 11:48:38.952 [bus event] <aa
2014-12-24 11:48:38.995 [bus event] <aa
2014-12-24 11:48:39.038 [bus event] <aa
2014-12-24 11:48:39.082 [bus event] <aa
2014-12-24 11:48:39.125 [bus event] <aa
2014-12-24 11:48:39.166 [bus event] <aa
2014-12-24 11:48:39.209 [bus event] <aa
2014-12-24 11:48:39.254 [bus event] <aa
2014-12-24 11:48:39.296 [bus event] <aa
2014-12-24 11:48:39.339 [bus event] <aa
2014-12-24 11:48:39.386 [bus event] <aa
2014-12-24 11:48:39.426 [bus event] <aa
2014-12-24 11:48:39.467 [bus event] <aa
2014-12-24 11:48:39.511 [bus event] <aa
2014-12-24 11:48:39.554 [bus event] <aa
2014-12-24 11:48:39.598 [bus event] <aa
2014-12-24 11:48:39.640 [bus event] <aa
2014-12-24 11:48:39.683 [bus event] <aa
2014-12-24 11:48:39.726 [bus event] <aa
2014-12-24 11:48:39.768 [bus event] <aa
2014-12-24 11:48:39.812 [bus event] <aa
2014-12-24 11:48:39.855 [bus event] <aa
2014-12-24 11:48:39.898 [bus event] <aa
2014-12-24 11:48:39.941 [bus event] <aa
2014-12-24 11:48:39.983 [bus event] <aa
2014-12-24 11:48:40.026 [bus event] <aa
2014-12-24 11:48:40.069 [bus event] <aa
^C2014-12-24 11:48:40.071 [bas event] SIGINT received
2014-12-24 11:48:40.113 [bus event] <aa
2014-12-24 11:48:40.155 [bus event] <aa
2014-12-24 11:48:40.198 [bus event] <aa
2014-12-24 11:48:40.201 [bas event] ebusd stopped
So ähnlich sieht es bei mir auch aus. Und EnergyYieldSum liefert bei mir auch Werte, obwohl ich keine Solarzellen habe.
schöne Grüße
Jo
"Solarzellen" sowieso nicht - die erzeugen Strom. Du meinst Solarkollektoren.
Das Problem ist eben, dass Vaillant bei unterschiedlichen Geräten die Register auch ganz unterschiedlich belegt hat.
Aber ein paar Dinge sind doch schon klar, z.B.
10 fe b5 16 = Broadcast (fe und 16) der Zentrale (10) von Vaillant (b5)
08 = Anzahl Bytes
00 = Status
03 = Sekunden 50=Minuten 11=Stunde 24=Tag 12=Monat 03=Wochentag Mittwoch 14=Jahr
0e = CRC
LG
pah
VORSICHT ist geboten. Ich hoffe ihr probiert nicht einfach irgendwelche Werte durch. Die Konfiguration muss auch zu Euren ebus Komponenten passen.
Fürs erste würde ich NUR das _template.csv und scan.csv in das Verzeichnis /etc/ebusd stellen.
ebusd starten und ein paar Minuten laufen lassen. ebusd sammelt anhand der zyklischen Nachrichten mögliche ebus Teilnehmer.
Ein 'ebusctl scan' startet einen Scan für die gesammelten Adressen. (scan full - einfach alle möglichen Teilnehmer)
Das Scan Ergebnis zeigt eine Spalte "ident". Die veröffentlichten Konfigurationsdateien sind bis jetzt nach diesen Ident benannt, ebenfalls entspricht Class in der Konfigurationsdatei dem Ident.
Gibt es für Eure Komopoenten bereits CSV Datei, so könnt Ihr die gerne verwenden. Beim Erstellen der fehlenden CSV Dateien kann ich behilflich sein.
Frohe Weihnachten
lg roland
Richtig, Solarkollektoren habe ich nicht. Aber Solarzellen auch nicht ::)
@yuhu: Danke für den Hinweis. Ich versuche ohnehin zunächst nur zu verstehen, was die Heizung so alles sendet. Vom aktiven Schreiben bin ich wohl noch weit entfernt.
schöne Grüße
Jo
Frohe Weihnachten in die Runde !
pah
P.S.: Habe sowohl Solarzellen, als auch Solarkollektoren. Fehlt aber Sonne...
Ja Danke, auch so :)
Sonnen...was? Wir müssen auf Wasserkraft umschwenken...jedenfalls hier im Norden. Hätte ich in jedem Fallrohr ein Strömungsgenerator eingebaut, könnte ich momentan ins Netz zurückspeisen... :-\
Wünsche ich ebenso!
schöne Grüße
Jo
Frohe Weihnachten an alle FHEMler :D
@yuhu:
Ich habe jetzt folgendes ausgeführt, scan.csv & _template.csv nach /etc/ebusd:
ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
mehrere Minuten laufen lassen, Terminalsitzung in den Hintergrund, 2. Terminalsitzung gestartet.
Dort:
ebusctl scan full
Danach
ebusctl scan result
liefert
root@fhemALT:~# ebusctl scan result
08;Joh. Vaillant GmbH & Co.;BAI00;0600;5502;21132500;100116400;001005433;N9
15;Joh. Vaillant GmbH & Co.;47000;0231;6002
26;Joh. Vaillant GmbH & Co.;47000;0231;6002
Einen Ident kann ich leider noch nicht erkennen.
Übrigens hat keine der hier bereitgestellten .csv einen lesbaren Outbook ergeben:
https://github.com/yuhu-/ebusd-configuration/blob/master/ebusd-0.5.x/vaillant/scan.csv (https://github.com/yuhu-/ebusd-configuration/blob/master/ebusd-0.5.x/vaillant/scan.csv)
Das einzige, was öfters erscheint, ist energy yield (welchen ich technisch nicht haben kann).
Viele Grüße,
Heiko
Na, dann gehen wir doch mal langsam vor.
Was liefern die drei Kommandos:
ebusctl write -h 08070400
ebusctl write -h 15070400
ebusctl write -h 26070400
Die fragen die ID-Daten der Geräte auf dem Bus ab, sowie die Versionsnummern der Hard- und Software. Liefert nichts weiter als den Output vom Scan - aber ist immerhin schon ein aktives Kommando
LG
pah
Ok, dass kommt nicht klar hervor.
08;Joh. Vaillant GmbH & Co.;BAI00;0600;5502;21132500;100116400;001005433;N9
15;Joh. Vaillant GmbH & Co.;47000;0231;6002
26;Joh. Vaillant GmbH & Co.;47000;0231;6002
Fett sind die Idents für die du Konfigdateien benötigst.
Bei mir läuft der 0.5er Ebusd sehr instabil - nur ein Beispiel:
2014-12-25 18:04:46.043 [net trace] [00009] connection opened 127.0.0.1
2014-12-25 18:04:46.044 [net debug] [00009] wait for result
2014-12-25 18:04:46.044 [bas event] >>> write -h 26070400
2014-12-25 18:04:46.044 [bas event] write hex cmd: 0a260704002f
2014-12-25 18:04:46.083 [bus debug] switching from ready to send command
2014-12-25 18:04:46.115 [bus debug] switching from send command to receive command ACK
2014-12-25 18:04:46.119 [bus debug] switching from receive command ACK to receive response
2014-12-25 18:04:46.169 [bus debug] switching from receive response to send response ACK
2014-12-25 18:04:46.176 [bus debug] notify request: success
2014-12-25 18:04:46.176 [bus event] read res: 0ab534333030300215200233
*** glibc detected *** ebusd: malloc(): smallbin double linked list corrupted: 0x0043bba0 ***
Speicherzugriffsfehler bekomme ich auch sehr oft ...
Ich bin noch auf der Suche nach der Ursache.
Grüße
Arthur
Hi amunra,
falls du etwas reproduzieren/provozieren kannst wäre folgende Vorgangsweise gut.
$ gdb path_to_ebusd/ebusd
...
(gdb) set args -f (und weitere Argumente)
(gdb) run
...
nach einem Fehler
(gdb) backtrace
Und das Ergebnis posten.
Hallo Roland,
sorry, anbei nun alle Daten:
2014-12-25 19:17:01.589 [bas event] >>> write -h 15070400
2014-12-25 19:17:01.590 [bas event] write hex cmd: 0a1507040098
2014-12-25 19:17:01.590 [net debug] [00002] wait for result
2014-12-25 19:17:01.641 [bus debug] switching from ready to send command
2014-12-25 19:17:01.673 [bus debug] switching from send command to receive command ACK
2014-12-25 19:17:01.678 [bus debug] switching from receive command ACK to receive response
2014-12-25 19:17:01.728 [bus debug] switching from receive response to send response ACK
2014-12-25 19:17:01.735 [bus debug] notify request: success
2014-12-25 19:17:01.735 [bus event] read res: 0ab534333030300215200233
2014-12-25 19:17:01.736 [bas event] <<< 0ab534333030300215200233
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5bff460 (LWP 29748)]
BusHandler::setState (this=0x38240, state=bs_sendSyn, result=0, firstRepetition=<optimized out>) at bushandler.cpp:602
602 unsigned char dstAddress = m_request->m_master[1];
(gdb) backtrace
#0 BusHandler::setState (this=0x38240, state=bs_sendSyn, result=0, firstRepetition=<optimized out>) at bushandler.cpp:602
#1 0x0000f746 in BusHandler::handleSymbol (this=0x38240) at bushandler.cpp:527
#2 0x0000f978 in BusHandler::run (this=0x38240) at bushandler.cpp:214
#3 0x0001ca46 in Thread::enter (this=0x38240) at thread.cpp:94
#4 0x0001ca52 in Thread::runThread (arg=<optimized out>) at thread.cpp:28
#5 0xb6fbcebc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0
#6 0xb6e24a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#7 0xb6e24a38 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Danke.
Ich bin jetzt ein bißchen weiter als vorher, habe allerdings wie im Baublog von Alexex vorgeschlagen mal die 1993 ohne den Patch kompiliert, da es für diese Version umfangreichere .csv-Dateien zu geben scheint. Läuft jetzt seit ca. 30min stabil.
Allerdings liefern die telnet-Befehle keine sinnvollen Werte:
get mv boiler_temp
0.000000 0
get mv VF1_temp
55.000000 0
command not found
get mv RF1_temp
15.000000 0
get mv heat_press
0.000000 0
get hw mode
error send ebus msg
get amu date
error ==> 38 00 00
get amu time
error ==> 00 07 61
get mv heat_pump
command not found
get mv heat_pump_io
255
get nv pump_stat
command not found
get mv pump_stat
255
get mv at_temp
0.000000 255
In meinem ebusd-Fenster erscheinen folgende Werte:
2014-12-26 14:18:26.371 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d b0 04 ff 67 01 00 ff 3e 00
2014-12-26 14:18:26.591 [EBH] 10 fe b5 16 03 01 b0 04 85
2014-12-26 14:18:26.592 [NOT] found: FEB5160301 type: 1 ==> id: 3
2014-12-26 14:18:26.593 [DBG] id: 3 elem: 0 p1: 2 p2: 3 p3: 0 p4: 0
2014-12-26 14:18:26.594 [DBG] buf: 4.687500
2014-12-26 14:18:26.594 [EBS] 4.687500
2014-12-26 14:18:28.503 [EBH] 10 08 b5 10 09 00 00 66 ff ff ff 04 ff 00 34 00 01 01 9a 00
2014-12-26 14:18:34.587 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d b0 04 ff 67 01 00 ff 3e 00
2014-12-26 14:18:36.695 [EBH] 10 08 b5 11 01 02 8a 00 06 03 3c 96 46 8c 6e e3 00
2014-12-26 14:18:38.692 [EBH] 10 08 b5 10 09 00 00 66 ff ff ff 04 ff 00 34 00 01 01 9a 00
2014-12-26 14:18:44.780 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d 80 04 ff 67 01 00 ff 7c 00
2014-12-26 14:18:46.778 [EBH] 10 08 b5 04 01 00 3d 00 0a 03 48 18 14 26 12 05 14 b0 04 7a 00
2014-12-26 14:18:48.900 [EBH] 10 08 b5 10 09 00 00 66 ff ff ff 04 ff 00 34 00 01 01 9a 00
2014-12-26 14:18:54.985 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d b0 04 ff 67 01 00 ff 3e 00
2014-12-26 14:18:56.953 [EBH] 10 08 b5 10 03 05 ff 01 98 00 01 01 9a 00
2014-12-26 14:18:58.990 [EBH] 10 08 b5 10 09 00 00 66 ff ff ff 04 ff 00 34 00 01 01 9a 00
2014-12-26 14:19:05.078 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d 80 04 ff 67 01 00 ff 7c 00
2014-12-26 14:19:07.127 [EBH] 10 fe b5 16 08 00 09 19 14 26 12 05 14 10
2014-12-26 14:19:07.129 [NOT] found: FEB5160800 type: 1 ==> id: 2
2014-12-26 14:19:07.130 [DBG] id: 2 elem: 0 p1: 7 p2: 0 p3: 0 p4: 0
2014-12-26 14:19:07.130 [DBG] buf: Fri
2014-12-26 14:19:07.131 [DBG] id: 2 elem: 1 p1: 5 p2: 6 p3: 8 p4: 0
2014-12-26 14:19:07.132 [DBG] buf: 26.12.2014
2014-12-26 14:19:07.133 [DBG] id: 2 elem: 2 p1: 4 p2: 3 p3: 2 p4: 0
2014-12-26 14:19:07.134 [DBG] buf: 14:19:09
2014-12-26 14:19:07.135 [EBS] Fri 26.12.2014 14:19:09
2014-12-26 14:19:07.365 [EBH] 10 08 b5 12 02 00 00 ca 00 00 00 00
2014-12-26 14:19:09.186 [EBH] 10 08 b5 10 09 00 00 66 ff ff ff 04 ff 00 34 00 01 01 9a 00
2014-12-26 14:19:13.293 [EBH] 10 08 b5 11 01 01 89 00 09 66 5d 80 04 ff 67 01 00 ff 7c 00
2014-12-26 14:19:15.290 [EBH] 10 08 b5 04 01 00 3d 00 0a 03 16 19 14 26 12 05 14 80 04 2a 00
2014-12-26 14:19:15.550 [EBH] 10 08 b5 11 01 02 8a 00 06 03 3c 96 46 8c 6e e3 00
2014-12-26 14:19:15.787 [EBH] 10 08 b5 12 02 00 00 ca 00 00 00 00
2014-12-26 14:19:17.698 [EBH] 10 18 07 04 00 ad
2014-12-26 14:19:18.446 [EBH] 10 18 07 04 00 ad
2014-12-26 14:19:19.192 [EBH] 10 18 07 04 00 ad
2014-12-26 14:19:19.934 [EBH] 10 50 07 04 00 b5
2014-12-26 14:19:20.680 [EBH] 10 50 07 04 00 b5
2014-12-26 14:19:21.427 [EBH] 10 50 07 04 00 b5
2014-12-26 14:19:22.172 [EBH] 10 ec 07 04 00 d4
2014-12-26 14:19:22.918 [EBH] 10 ec 07 04 00 d4
2014-12-26 14:19:23.665 [EBH] 10 ec 07 04 00 d4
2014-12-26 14:19:24.410 [EBH] 10 a0 07 04 00 2f
2014-12-26 14:19:25.158 [EBH] 10 a0 07 04 00 2f
2014-12-26 14:19:25.904 [EBH] 10 a0 07 04 00 2f
2014-12-26 14:19:26.650 [EBH] 10 ed 07 04 00 8a
2014-12-26 14:19:27.398 [EBH] 10 ed 07 04 00 8a
Wie wäre jetzt das weitere Vorgehen?
Also zwischenzeitlich bin ich soweit, dass die Außentemperatur zuverlässig in FHEM erscheint.
Nur wie komme ich nun an die anderen Werte? Vorlauf-IST, Vorlauf-Soll, Rücklauf-Ist, Speicher-IST, Systemdruck, Betirebsmodus, Brennerleistung in %?
Wenn ich es richtig verstehe, ist die Temp. und Zeit ein Broadcast, die anderen Werte muss man aber erst anfordern.
Doch wie mache ich das, wenn die get-commandos nicht funktionieren oder falsch interpretierte Werte liefern?
Na:
1. Dokumentation lesen und feststellen, was die wahrscheinlichen Kommandos für die Anforderung sind
2. Kommandos hexadezimal ausprobieren und nachsehen, was heaxadezimal zurückkommt
3. Interpretation verändern.
LG
pah
Also ohne Hilfe komme ich hier nicht weiter, da ich mit der HEX-Logik nicht vertraut bin.
Vielleicht liest yuhu (Roland) noch mit, er hatte weiter vorne angeboten, bei der Erstellung der .csv behilflich zu sein.
Alzu viel kann nicht mehr fehlen - immerhin habe ich schon die Außentemperatur im Minutentakt in FHEM, jetzt wären die anderen Systemwerte meiner Heizung auch noch toll.
Hallo heikoh81,
auf welcher Version von ebusd bist du nun unterwegs?
Du kannst einmal folgendes Testen.
aktuelle Version (0.5.0): ebusctl write -h 08b509030d7600
davor wäre es: hex 08b509030d7600
Das müsste wenn es stimmt die Aussentemperatur + Fühlerstatus für dein Gerät mit Ident BAI00 zurück liefern.
Kurz zum Aufbau (auch wenn es eine gute Spezifikation gibt)
QQ...ff - Absenderadresse von ebusd ergänzt (default 0xff)
ZZ...08 - Zieladresse
PB...b5 - Primär Befehl - b5 steht hier für Vaillant
SB...09 - Sekundär Befehl - Vaillant spezifisch
NN...03 - Anzahl Datenbytes im Master Telegramm
D1...0d - Tertitär Befehl - Vaillant spezifisch
D2...76 - der Datenpunkt als HEX (118)
D3...00 - der Datenpunkt als HEX (118)
CRC...wird von ebusd über QQ bis D3 berechnet und ergänzt. -->> Bei Broadcast wäre hier Schluss
ACK... Anwort vom Slave (00..OK, FF..NOK) an den Master. -->> Bei einem Master-Master Telegramm wäre hier Schluss
NN...0x - Anzahl Datenbytes in der Slave Antwort
Dx... Daten
CRC...über NN und DX vom Slave
ACK...Anwort vom Master (00..OK, FF..NOK) an den Slave
Ich kann sowohl 0.5 beta2 als auch rev.1993 verwenden.
Probeweise habe ich 0.5 beta laufen lassen, dann ebusctl, dann write -h 08b509030d7600
--> command not found
Mein Problem ist, dass mir die von dir genannte Doku leider überhaupt nichts sagt.
Bei den Hex-Codes steige ich leider aus.
@yuhu: Kann ich nicht bestätigen. Meine Therme (nicht die Kontrollstation) hat auch die ID BAI00 und liefert als Wert des Registers 7600 sechs Byte zurück: 0339fcaa3b
Das ergibt in keiner Darstellung die aktuelle Außentemperatur von 4,94 Grad Celsius
LG
pah
Hallo heikoh81
1) starte ebusd
2) Falls du eBusd mit Parameter -f gestartet hast, dann starte eine neue Terminal-Sitzung
3) gebe anschließend ein: ebusctl write -h 08b509030d7600 (wenn eBusd nicht abstürzt, dann bekommst du auch ein Ergebnis)
Den Wert "08b509030d7600" kannst du dann in die Konfig übertragen (ebus Version 0.3).
Das sieht dann in etwa wie folgt aus (Analog dazu muss das in die 0.5 Konfig übertragen werden):
get;BAI00;AussentemperaturFuehlerstatus;Aussentemperatur;MS;08;B509;3;0D7600;2;temp;sd;1,2;d2c;1.0;°C;-;Temperatur;sensor;sd;3;uch;-;-;-;Fühler;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Command über ebusd: get BAI00 AussentemperaturFuehlerstatus
Alles ungetestet - das ist nur ein Beispiel.
VG Arthur
Zitat von: Prof. Dr. Peter Henning am 26 Dezember 2014, 21:28:16
@yuhu: Kann ich nicht bestätigen. Meine Therme (nicht die Kontrollstation) hat auch die ID BAI00 und liefert als Wert des Registers 7600 sechs Byte zurück: 0339fcaa3b
Das ergibt in keiner Darstellung die aktuelle Außentemperatur von 4,94 Grad Celsius
Schlecht. Statt 7600 mal folgende Register testen.
1600
1700
1800
0200 müsste ein Druck sein
6B00
Hallo Roland,
haben meine Infos geholfen - laut KNX Forum schon?
Ich habe verstanden - fix kommt - kann ich sonst noch unterstüzen (fehlen noch Infos)?
VG Arthur
Wir arbeiten daran und im Moment sind keine weiteren Infos notwendig. Ich hoffe, dass ebusd bald stabil wird.
Ich selbst teste auf einem Raspberry Pi und einem ProLiant MicroServer.
Schade dass die GPIO Pins vom Raspberry nicht für eine Anbindung an den ebusd reichen. Sonst hätte ich schon einen 2. Adapter.
Zitat von: yuhu am 26 Dezember 2014, 21:41:34
Schlecht. Statt 7600 mal folgende Register testen.
1600
1700
1800
0200 müsste ein Druck sein
6B00
Bei meiner Therme ID BAI00 bekomme ich mit dem command (ebusd 0.5.0):
ebusctl write -h 08b5040100als result:
0a0352250227120614c003a2mein Deamon, kurze Zeit später gestartet, sagt dazu:
10 8 b5 4 1 0 3d 0 a 3 48 28 2 27 12 6 14 c0 3 1c 0
[START]_________________________________________________________________
Name:00 = no receiption,01 = receiption,02 = synchronized,03 = data valid Value: 3
Name:seconds Value: 48
Name:minutes Value: 28
Name:Hours Value: 2
Name:day Value: 27
Name:month Value: 12
Name:weekday Value: 6
Name:year Value: 14
Name:Außentemperatur Value: 3.8 °C
[ENDE]__________________________________________________________________
VG Arthur
P.S. Mit dem Command (ebusd 0.5.0):
ebusctl write -h 08b50400 bekomme ich die Außentemperatur inkl. Fühlerstatus auch (siehe dazu Spezifikation/Doku).
Hm, man kann natürlich die Außentemperatur auch in der Therme abfragen. Allerdings ist es performanter, sie aus den zyklischen Messages auf dem Bus zu übernehmen. Dafür gibt es es zwei Möglichkeiten:
Aus dem Broadcast
10 FE B516 01, gefolgt von 2 Byte Temperatur als D2B
Aus der Mitteilung von Zeit, Datum, Außentemperatur an die internen Module meiner VRS620, z.B. den 1. Heizkreis
10 26 B505 00, IGN:1;BTI;HDA;D2B
Wenn ich die Außentemperatur aktiv abfrage, sehe ich ebenfalls in der Kontrollstation nach:
15 B509 03 0D 0100 => 03=Anzahl Bytes 2800 00=Status OK 3f=CRC
Die 2800=dezimal 2*16+8 = 40. Divider ist 16, also 40:16 = 2,5 Grad Celsius => stimmt.
Von den internen Registern der VRS620 (Adresse 15, dann B509 05) habe ich 144 (0000 bis 8f00) getestet, 19 sicher identifiziert und bei ca. 10 weiteren zumindest einen Schimmer, was sie bedeuten können.
Die Abfragebefehle B504 sind allerdings effizienter, weil sie jeweils mehrere Register als Datengruppe zurückliefern. Davon habe ich 48 identifiziert
Ferner 30 Schreibbefehle B505 und 15 zyklische Nachrichten auf dem Bus
Die Therme (VC226 ecoTec exclusiv mit der ID BAI00 und der Adresse 08) habe ich bisher im Wesentlichen in Ruhe gelassen, da haben wir jetzt als Register
08b509030d 7600 => 03 39fcaa 3b unverändert seit gestern
08b509030d 1600 => 03 410755 8c
08b509030d 1700 => 03 11ffaa b3
08b509030d 1800 => 03 c40100 d4
08b509030d 0200 => 03 310600 0e
08b509030d 6B00 => 03 e3ffaa 95
Das Ganze während einer kurzen Schlafpause um 04:15 morgens. Sehen wir mal, was sich daran ändert. Gute Nacht.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 Dezember 2014, 04:59:12
Die Therme (VC226 ecoTec exclusiv mit der ID BAI00 und der Adresse 08) habe ich bisher im Wesentlichen in Ruhe gelassen, da haben wir jetzt als Register
08b509030d 7600 => 03 39fcaa 3b unverändert seit gestern
08b509030d 1600 => 03 410755 8c
08b509030d 1700 => 03 11ffaa b3
08b509030d 1800 => 03 c40100 d4
08b509030d 0200 => 03 310600 0e
08b509030d 6B00 => 03 e3ffaa 95
Im Moment kann ich nur die Werte aus meiner Therme beisteuern - vielleicht hilft es:
08b509030d 7600 => 03 1d0000 e7 Wert gestern: 03 4b0000 b2
08b509030d 1600 => 03 a90200 c1
08b509030d 1700 => 03 650200 b6
08b509030d 1800 => 03 e90300 ea
08b509030d 0200 => 03 ee0900 3c
08b509030d 6B00 => 03 e3ffaa 95VG Arthur
Na, dann gib mal ein:
ebusctl write -h 08B5110101
08 = Adresse Therme
B5 = Vaillant
11 = Burner Op Data
01 = Länge
01 = Kommando
Liefert bei mir derzeit
0966500080ffff0100ffd6
09 = Länge
66 = Vorlauftemperatur = 6*16+6 = 102 => dividieren durch 2, Datentyp ist D1C => 51 Grad Celsius
50 = Rücklauftemperatur = 5*16 = 80 => 40 Grad Celsius
0080 = 8000 (LSB zuerst) => kein Außentemperatursensor mit der Therme verbunden (stimmt)
ffff = Feste Wete zum Warmwasserspeicher, bei mir wegen der Anbindung an die VRS610 nicht belegt
01 = Brennerstatus (01 = Heizung, 02 Warmwasser)
00ff = weiß keiner, sind fest
d6 = CRC
Geht in die CSV-Datei ein als
r,THER,Status1,Vorlauf/Rücklauf/Brenner,,08,B511,01,,,D1C,,,,,,D1C,,,,,,D2B,,,,,,IGN:2,,,,,,UCH,,,,,,,,,
LG
pah
Ich habe, wie bereits geschrieben, massive Probleme die Werte abzufragen, nach ca. fünfzehn Versuchen (Speicherzugrifsfehler) und 20x ERR: read timeout, bekomme ich aktuell folgende Werte:
097c64d001544a0100ff02
09 = Länge
7c = Vorlauftemperatur = 7*16+12 = 124 => dividieren durch 2, Datentyp ist D1C => 62 Grad Celsius
64 = Rücklauftemperatur = 6*16+4 = 100 => dividieren durch 2, Datentyp ist D1C => 50 Grad Celsius
d001 =?
544a =?
01 = Brennerstatus (01 = Heizung, 02 Warmwasser)
00ff = weiß keiner, sind fest
02 = CRC
VG Arthur
Na, das ist doch schon etwas !
d001 = 01d0h = 1*256 + 13*16 + 0*1 = 464 => dividieren durch 256, Datentyp ist D2B => 1,8125 Grad Celsius Außentemperatur (gelogen, das ist höchstens auf 1/10 genau)
54 => 42 Grad Celsius mit Datentyp D1C, sollte Warmwasser-Speichertemperatur sein
4a => 37 Grad Celsius mit Datentyp D1C, sollte Warmwasser-Auslauftemperatur (oder Rücklauftemperatur ?) sein
Gratuliere, schon mal fünf Messwerte erhalten
Das sollte also in die CSV-Datei als
r,THER,Status1,VL-H/RL-H/VL-WW/RL-WW/Brenner,,08,B511,01,,,D1C,,,,,,D1C,,,,,,D2B,,,,,,D1C,,,,,,D1C,,,,,,UCH,,,,,,,,,
oder
r,THER,Status1,VL-H/RL-H/VL-WW/RL-WW/Brenner,,08,B511,01,,,temp1;temp1;temp;temp1;temp1;status
Doie Speicherzugriffsfehler sollten nicht vorkommen. Das deutet auf ein Problem mit dem Binary hin: Was ist das für ein Betriebssystem, ist das der aktiuelle Stand ? Gab es irgendwelche warnings beim compilieren ?
LG
pah
Command:
ebusctl read -v -f -m 10 THER Status1
liefert:
=62.0;=50.0;=1.812;=42.0;=36.0;=1
Mein System auf dem ich grade teste ist:
System: a20-cubietruck
OS: Linux xxxx 3.4.61+ #1 SMP PREEMPT Mon Dec 23 12:44:19 CST 2013 armv7l GNU/Linux
+ Updates/Upgrades Stand ca. von vor 3 Monaten
Keine warnings beim compilieren.
Ich kann noch auf einen anderen CT (produktiv) ausweichen und auf einen DEV RPI -> ist vielleicht auch noch eine Idee - probiere es mal nachher.
VG Arthur
Registeridentifikation für device BAI00 soweit
02 => Anlagendruck, Datentyp press;sensor
18 => Vorlauftemperatur, Datentyp temp;sensor
LG
pah
Müsste sein:
1600 --> WarmWasser Vorlauf (Soll/Zapf)temperatur
1700 --> Speicher Ist Temperatur
6B00 --> Rücklauftemperatur
Ich kann immer noch nicht folgen, aber vielleicht kann pah mir eine Beispielrechnung für folgenden Output geben.Bin einen Schritt weiter und verstehe die HEX-Logik nun allmählich:
- Die erste Ziffer beschreibt den Wert (0 - 9) * 16
- Die zweite Stelle ist ein Wert zw. 10 - 15, wobei a=10 b=11 c=12 d=13 e=14 f=15
Zum Testen verwende ich ebusd 0.5 beta2.
ebusctl write -h 08B5110101
liefert:
094949c003ff690000ffa3
Im anderen Terminal-Fenster stürzt ebusd in dem Moment des "write" sofort ab - lässt man es dagegen nur mitlauschen, läuft es wie ersichtlich stabil.
Segmentation fault, siehe ganz unten in nachfolgendem Code-Ausschnitt:
root@fhemALT:~# /root/ebusd50/trunk/src/ebusd/ebusd -f -l ALL -d /dev/ttyUSB0
2014-12-27 13:39:56.882 [bas event] ebusd started
2014-12-27 13:39:56.883 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-27 13:39:56.896 [bas trace] read templates
2014-12-27 13:39:56.898 [bas trace] read config files
2014-12-27 13:39:56.899 [bas event] message DB: 0
2014-12-27 13:39:56.900 [bas event] updates DB: 0
2014-12-27 13:39:56.901 [bas event] polling DB: 0
2014-12-27 13:39:57.810 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:39:59.811 [upd trace] update MS cmd: 1008b50401003d / 0a0301401327120614c003ae
2014-12-27 13:40:00.069 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 13:40:03.876 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:07.892 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:40:08.243 [upd trace] update MS cmd: 0315070400ae / 0ab5343730303002316002a0
2014-12-27 13:40:09.924 [upd trace] update BC cmd: 10feb5160301c0031c
2014-12-27 13:40:13.993 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:18.104 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:40:20.088 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 13:40:22.171 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:28.256 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:40:30.293 [upd trace] update MS cmd: 1008b50401003d / 0a0331401327120614c00358
2014-12-27 13:40:32.294 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:38.382 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:40:40.437 [upd trace] update MS cmd: 1008b5100305ff0198 / 01019a
2014-12-27 13:40:42.479 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:48.562 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:40:50.531 [upd trace] update BC cmd: 10feb5160800544013271206148e
2014-12-27 13:40:50.768 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-27 13:40:52.677 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:40:58.762 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:00.764 [upd trace] update MS cmd: 1008b50401003d / 0a0302411327120614c00344
2014-12-27 13:41:01.023 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 13:41:02.759 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:08.882 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:10.914 [upd trace] update BC cmd: 10feb5160301c0031c
2014-12-27 13:41:12.952 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:17.060 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:19.043 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 13:41:23.152 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:27.167 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:29.248 [upd trace] update MS cmd: 1008b50401003d / 0a0331411327120614c0038e
2014-12-27 13:41:33.273 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:37.336 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:39.308 [upd trace] update MS cmd: 1008b5100305ff0198 / 01019a
2014-12-27 13:41:43.454 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:47.557 [upd trace] update MS cmd: 1008b511010189 / 094849c003ff690000ff3e
2014-12-27 13:41:49.521 [upd trace] update BC cmd: 10feb51608005341132712061435
2014-12-27 13:41:49.755 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-27 13:41:53.627 [upd trace] update MS cmd: 1008b51009000000ffffff45ff00df / 01019a
2014-12-27 13:41:56.891 [net trace] [00001] connection opened 127.0.0.1
2014-12-27 13:41:56.894 [bas event] >>> write -h 08B5110101
2014-12-27 13:41:56.894 [bas event] write hex cmd: ff08b51101012d
2014-12-27 13:41:57.338 [bus event] read res: 094849c003ff690000ff3e
2014-12-27 13:41:57.340 [bas event] <<< 094849c003ff690000ff3e
2014-12-27 13:41:57.347 [net trace] [00001] connection closed
Segmentation fault
root@fhemALT:~#
Woran kann dies nun wieder liegen?
Wie wäre der write-Befehl für ebusd 0.1?
ebusctl write -h 08b509030d7600
liefert
033c00009c
Ich bräuchte aber auch hier ein Beispiel, wie dies nun in eine .csv übersetzt wird.
Bei meinen ersten Versuchen läuft --checkconfig dauernd auf Fehler, egal, an welcher Stelle ich ändere.
Zwischenzeitlich bin ich einen Schritt weiter.
root@fhemALT:~# ebusctl write -h 08B5110101
095d43c003ff680100ff8b
09 6c 5f 4003 ff68 01 00ff 1a
6c = (6*16+12)/2 = 54
5f = (5*16+15)/2 = 47,5
01 = Brenner an, Heizbetrieb?
An Therme abgelesen, im Menü Fachhandwerkerebene: Vorlauf IST 53 Rücklauf IST 47.
PASST ALSO, der Wert wird leicht geschwankt sein von der Therme zum PC...
Wie packe ich das nun in eine .csv?
Und wie bekomme ich noch Boiler IST (wird über Sonde gemessen, kann an Therme im Fachhandwerker-Menü abgelesen werden)?
Interessant wäre auch noch die Brennerleistung (wird per Balken im Standby-Menü an der Therme angezeigt) sowie der Systemdruck (wird ebenfalls angezeigt).
Und die Gebläsedrehzahl wäre noch interessant.
@pah:
Kann ich diese Zeile eigentlich für mich verwenden? Ich habe eine ecotec Plus.
r,THER,Status1,VL-H/RL-H/VL-WW/RL-WW/Brenner,,08,B511,01,,,temp1;temp1;temp;temp1;temp1;statusWie rufe ich dann über Telnet die Werte ab?
get THER Status1 funktioniert bei mir leider nicht.ebusctl read -v -f -m 10 THER Status1
liefert
message not defined
Darüber hinaus sagt ebusd 0.5 beim starten, wenn ich eine .csv nur mit der genannten Zeile verwende:
root@fhemALT:~# /root/ebusd50/trunk/src/ebusd/ebusd -f -l ALL -d /dev/ttyUSB0
2014-12-27 14:54:43.819 [bas event] ebusd started
2014-12-27 14:54:43.820 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-27 14:54:43.821 [bas error] error reading templates: ERR: file/element not found or not readable
2014-12-27 14:54:43.822 [bas error] error reading config files: ERR: file/element not found or not readable
2014-12-27 14:54:43.823 [bas event] message DB: 0
2014-12-27 14:54:43.823 [bas event] updates DB: 0
2014-12-27 14:54:43.823 [bas event] polling DB: 0
@yuhu:
Die neueste _template.csv auf github scheint fehlerhaft zu sein, zumindest meldet --checkconfig von ebusd 0.5 beta2 Fehler darin.
Viele Grüße,
Heiko
Ich habe mal noch einige der weiter vorne genannten writes abgesetzt.
Hier die Ergebnisse:
root@fhemALT:~# ebusctl write -h 08070400
0ab54241493030060055027a
root@fhemALT:~# ebusctl write -h 15070400
0ab5343730303002316002a0
root@fhemALT:~# ebusctl write -h 26070400
0ab5343730303002316002a0
root@fhemALT:~# ebusctl write -h 08b509030d7600
0330000074
root@fhemALT:~# ebusctl write -h 08b5040100
error connecting to localhost:8888
Der letzte Befehl mit der Außentemperatur bringt ebusd zum Abstutz - Segmentation fault.
@yuhu:
Nee, leider nicht. Register 16,17,6B liefern Werte, die mit keinem Sensor reading kompatibel sind.
@heikoh81:
HEX: Nein, auch der erste Wert kann von 0-F gehen, also FF = 15*16+15 = 255
Die Anworten lassen sich ganz einfach verstehen.
root@fhemALT:~# ebusctl write -h 08070400
0a b5 42 41 49 30 30 06 00 55 02 7a
0a = 10 ist die Nachrichtenlänge in Byte
b5 ist der Firmencode für Vaillant
42 41 49 30 30 sind die ASCII-Codes für BAI00
06.00 55.02 sind Versionsnummern Hardware/Software, binär codiert
Das letzte Byte ist immer der CRC-Code
root@fhemALT:~# ebusctl write -h 15070400
0a b5 34 37 30 30 30 02 31 60 02 a0
root@fhemALT:~# ebusctl write -h 26070400
0a b5 34 37 30 30 30 02 31 60 02 a0
34 37 30 30 30 sind ASCII codes für 47000, auch dann kommen wieder Versionsnummern
LG
pah
Ok, also mit dem write-Befehl kann ich meiner Heizung ja schon einige Werte entlocken.
Nun scheitere ich aber bei der Übertragung in .csv für ebusd 0.5.
Die genannte Zeile:
get;BAI00;AussentemperaturFuehlerstatus;Aussentemperatur;MS;08;B509;3;0D7600;2;temp;sd;1,2;d2c;1.0;°C;-;Temperatur;sensor;sd;3;uch;-;-;-;Fühler;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
würde ich nach Durchsicht der github-Beispiele für 0.5 in folgendes Umschreiben:
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment
r,BAI00,AussentemperaturFuehlerstatus,Aussentemperatur,MS,08,B509,3,0D7600,2,temp,sd,1;2,d2c,1.0,°C,,Temperatur,sensor,sd,3,uch,,,,Fuehler
Folgende Fehlermeldung:
root@fhemALT:~# /root/ebusd50/trunk/src/ebusd/ebusd --checkconfig
Error reading "/etc/ebusd/heiko.csv" line 2 field 5 value "MS": ERR: invalid numeric argument
Erroneous item is here:
"r","BAI00","AussentemperaturFuehlerstatus","Aussentemperatur","MS","08","B509","3","0D7600","2","temp","sd","1;2","d2c","1.0","°C","","Temperatur","sensor","sd","3","uch","","","","Fuehler"
^
2014-12-27 15:20:59.150 [bas event] ebusd started
2014-12-27 15:20:59.150 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-27 15:20:59.151 [bas error] error reading templates: ERR: file/element not found or not readable
2014-12-27 15:20:59.159 [bas trace] read config files
2014-12-27 15:20:59.160 [bas event] message DB: 0
2014-12-27 15:20:59.160 [bas event] updates DB: 0
2014-12-27 15:20:59.160 [bas event] polling DB: 0
2014-12-27 15:20:59.160 [bas event] ebusd stopped
Mein Tipp: In OpenOffice bearbeiten und dann erst nach CSV exportieren.
Ich hänge meine Dateien mal an, ebenso die im Entstehen begriffene Doku.
Achtung: Hier sind auch Schreibbefehle enthalten. Verwendung auf eigene Gefahr, ich übernehme keine Haftung für die Anwendung
LG
pah
Danke, das hilft schon einiges Weiter.
Ich habe einige Befehle durchprobiert - die RoomTemp passt nicht, die ist 21.0° laut CalorMatic 470.
Die OutsideTemp ist hier fehlerhaft, wird aber im Deamon korrekt angezeigt mit deiner Datei.
Der Systemdruck erscheint mir plausibel.
root@fhemALT:~# ebusctl read -v -f -m 10 THER Status1
status=0;status=ERR: invalid position
root@fhemALT:~# ebusctl read -v -f -m 10 THER ID
error connecting to localhost:8888
root@fhemALT:~# ebusctl read -v -f -m 10 RoomTemp
temp=22.88 °C [Temperatur];sensor=ok [Fühlerstatus]
root@fhemALT:~# ebusctl read -v -f -m 10 OutsideTemp
temp=-1616.00 °C [Temperatur];sensor=ERR: invalid position
root@fhemALT:~# ebusctl read -v -f -m 10 Pressure
error connecting to localhost:8888
root@fhemALT:~# ebusctl read -v -f -m 10 Pressure
press=2.232 bar [Druck];sensor=ok [Fühlerstatus]
root@fhemALT:~# ebusctl read -v -f -m 10 FlowTemp
temp=37.81 °C [Temperatur];sensor=ok [Fühlerstatus]
2-27 15:46:34.647 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 15:46:36.638 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:46:36.640 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 15:46:42.724 [upd trace] update MS cmd: 1008b511010189 / 094b4bc002ff660000ff8c
2014-12-27 15:46:42.725 [upd event] update MS StatusHC: 37.5;37.5;192;2;0
2014-12-27 15:46:44.848 [upd trace] update MS cmd: 1008b50401003d / 0a0345461527120614c0025f
2014-12-27 15:46:46.848 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:46:46.849 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 15:46:52.937 [upd trace] update MS cmd: 1008b511010189 / 094a4bc002ff660000ff11
2014-12-27 15:46:52.939 [upd event] update MS StatusHC: 37.0;37.5;192;2;0
2014-12-27 15:46:54.903 [upd trace] update MS cmd: 1008b5100305ff0198 / 01019a
2014-12-27 15:46:57.033 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:46:57.034 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 15:47:01.051 [upd trace] update MS cmd: 1008b511010189 / 094a4bc002ff660000ff11
2014-12-27 15:47:01.053 [upd event] update MS StatusHC: 37.0;37.5;192;2;0
2014-12-27 15:47:03.101 [upd trace] update BC cmd: 10feb51608000347152712061414
2014-12-27 15:47:03.103 [upd event] update BC DateTimeBC: 15:47:03;27.12.2014
2014-12-27 15:47:03.338 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-27 15:47:07.137 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:47:07.139 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 15:47:11.240 [upd trace] update MS cmd: 1008b511010189 / 094a4bc002ff660000ff11
2014-12-27 15:47:11.241 [upd event] update MS StatusHC: 37.0;37.5;192;2;0
2014-12-27 15:47:13.238 [upd trace] update MS cmd: 1008b50401003d / 0a0314471527120614c00295
2014-12-27 15:47:13.496 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 15:47:17.342 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:47:17.343 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 15:47:21.442 [upd trace] update MS cmd: 1008b511010189 / 094a4bc002ff660000ff11
2014-12-27 15:47:21.443 [upd event] update MS StatusHC: 37.0;37.5;192;2;0
2014-12-27 15:47:23.383 [upd trace] update BC cmd: 10feb5160301c0021d
2014-12-27 15:47:23.385 [upd event] update BC OutsideTempBC: 2.750
2014-12-27 15:47:27.534 [upd trace] update MS cmd: 1008b51009000000ffffff05ff0005 / 01019a
2014-12-27 15:47:27.536 [upd event] update MS SetBoiler: 1;77.0
Weiter oben konnte ich mittels write die korrekten Vorlauf- und Rücklauf-Temperaturen ermitteln.
Wie baue ich das hier jetzt ein?
Update:
Fast jeder write-Befehl führt zum Absturz des Deamon.
Woran kann das liegen?
;D Steht doch drin in Zeile 65 !
pah
2014-12-27 16:05:47.652 [upd event] update MS SetBoiler: 1;77.0
2014-12-27 16:05:51.713 [upd trace] update MS cmd: 1008b511010189 / 093d388002ff660100ff37
2014-12-27 16:05:51.714 [upd event] update MS StatusHC: 30.5;28.0;128;2;1
2014-12-27 16:05:53.698 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c6ee3
2014-12-27 16:05:57.810 [upd trace] update MS cmd: 1008b5100900006effffff04ff002b / 01019a
2014-12-27 16:05:57.812 [upd event] update MS SetBoiler: 1;77.0
Also das was bei StatusHC steht ist 100% identisch mit der Anzeige oben am kleinen Thermendisplay, Fachhandwerkerebene Menüpunkt D40 + D41.
Das kommt als Broadcast, ohne dass ich aktiv etwas abfragen muss :-)
Was bedeutet denn das SetBoiler? Die Werte machen für mich keinen Sinn.
Update:
root@fhemALT:~# ebusctl read -v -f -m 10 THER Status
temp1=31.0 °C [Temperatur];temp1=28.5 °C [Temperatur];temp=40.00 °C [Temperatur];temp1=- °C [Temperatur];temp1=51.0 °C [Temperatur];status=1
Das sieht doch gut aus, oder?
Nur die Außentemp. stimmt nicht.
Beim Broadcast erscheint diese korrekt:
2014-12-27 16:10:43.860 [upd trace] update BC cmd: 10feb51603018002d5
2014-12-27 16:10:43.861 [upd event] update BC OutsideTempBC: 2.500
VL WW/RL WW habe ich nicht, ich habe nur einen Heizkreis, der per Ventil umgeschaltet wird im WW-Betrieb.
Dafür habe ich eine Messsonde im 150l-Speicher, das sind wohl die 51°C.
Leider stürzt der Deamon sofort nach dem Befehl ab.
Wie könnte man das noch verbessern?
Äh - ja ? Ich sehe in dem Post noch keine Resultate.
LG
pah
Wie bekomme ich denn da jetzt einzelne Werte isoliert nach FHEM?
Die Telnet-Befehle
get BC OutsideTempBC
funktionieren nicht mehr.
Vermutlich funktioniert dann auch die Schnittstelle zu FHEM wie in der Wiki beschrieben nicht mehr:
# Außentemperatur
get A.Temp cmd {"cyc broad temp\n"}
get A.Temp expect ".*"
get A.Temp postproc { my $rval;\
if(($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
}else{\
$rval=sprintf("%5.2f °C",$_);\
}\
$rval; }
Hm,
etwas mehr Mitdenken und Doku lesen würde ich mir schon wünschen. ::)
Natürlich gilt "cyc broad temp" nicht mehr. Stattdessen gehört dorthin "read BC OutsideTemp".
LG
pah
Zitat von: Prof. Dr. Peter Henning am 27 Dezember 2014, 16:52:39
Äh - ja ? Ich sehe in dem Post noch keine Resultate.
LG
pah
Oh, ja entschuldigung jetzt ;o)
Zitat von: Prof. Dr. Peter Henning am 27 Dezember 2014, 12:38:06
Registeridentifikation für device BAI00 soweit
02 => Anlagendruck, Datentyp press;sensor
18 => Vorlauftemperatur, Datentyp temp;sensor
LG
pah
Zitat von: yuhu am 27 Dezember 2014, 12:48:38
Müsste sein:
1600 --> WarmWasser Vorlauf (Soll/Zapf)temperatur
1700 --> Speicher Ist Temperatur
6B00 --> Rücklauftemperatur
Meine aktuellen Werte dazu:
08b509030d 0200 => Anlagendruck => press=2.436 bar [Druck];sensor=ok [Fühlerstatus] -> kann ich aktuell nicht verifizieren (auf der Anzeige prüfen)
08b509030d 1800 => Vorlauftemperatur => temp=63.12 °C [Temperatur];sensor=ok [Fühlerstatus]
08b509030d 1600 => WarmWasser Vorlauf (Soll/Zapf)temperatur => temp=42.75 °C [Temperatur];sensor=ok [Fühlerstatus]
08b509030d 1700 => Speicher Ist Temperatur => temp=39.06 °C [Temperatur];sensor=ok [Fühlerstatus]
08b509030d 6B00 => Rücklauftemperatur => temp=-1.81 °C [Temperatur];sensor=cutoff [Fühlerstatus] -> verstehe ich nicht.
08b509030d 7600 => unklar.
VG Arthur
P.S: Seit dem Ebusd Update heute hatte ich keine EBusd Abstüze mehr - jedoch immer noch sehr oft "ERR: read timeout".
@pah:
Ich bin maximal bemüht, finde aber bei github keine Doku zu ebusd. Vielleicht stelle ich mich sehr unbeholfen an...
Und in dem von dir verlinkten PDF steht nirgends, dass r zu read im telnet wird :-(
Damit funktioniert es natürlich :-) *freu*
@arthur:
Wie update ich denn ebusd? Einfach neu per svn holen & kompilieren?
Die von dir genannten writes liefern bei mir auch etwas zurück - wie rechne ich das um, und wie bekomme ich es in die CSV?
root@fhemALT:~# ebusctl write -h 08b509030d 0200
03e50900b6
root@fhemALT:~# ebusctl write -h 08b509030d 1700
03260300cd
Zitat von: heikoh81 am 27 Dezember 2014, 17:10:19
@arthur:
Wie update ich denn ebusd? Einfach neu per svn holen & kompilieren?
ja.
Zitat von: heikoh81 am 27 Dezember 2014, 17:10:19
Die von dir genannten writes liefern bei mir auch etwas zurück - wie rechne ich das um, und wie bekomme ich es in die CSV?
root@fhemALT:~# ebusctl write -h 08b509030d 0200
03e50900b6
root@fhemALT:~# ebusctl write -h 08b509030d 1700
03260300cd
Meine CSV sieht so aus (du kannst es natürlich nach deinen Geschmack anpassen):
r,THER,Anlagendruck,Anlagendruck_Status,,08,B509,0d0200,,,press;sensor
r,THER,Vorlauftemperatur,Vorlauftemperatur_Status,,08,B509,0d1800,,,temp;sensor
r,THER,SpeicherIstTemperatur,SpeicherIstTemperatur,,08,B509,0d1700,,,temp;sensor
r,THER,WWSollTemp,WarmWasser Vorlauf (Soll/Zapf)temperatur,,08,B509,0d1600,,,temp;sensor
r,THER,WWIstTemp,Speicher Ist Temperatur,,08,B509,0d6b00,,,temp;sensorVG Arthur
@heikoh81:
Das Wiki gibt einen sehr guten Überblick zu den einzelnen Argumenten und Kommandos:https://github.com/yuhu-/ebusd/wiki (https://github.com/yuhu-/ebusd/wiki)
Mit dem neuesten Build 566 von heute aus github überlebt der Deamon folgendes Kommando:
ebusctl read -v -f -m 10 THER Status
Ich bin jetzt schon unglaublich weiter und habe dank pah's .csv die Vorlauftemp, Rücklauftemp, Speichertemp, Außentemp in FHEM :-)
Vielen Dank!!!!
@amunra:
Könntest du mir deine CSV'S für die heute von dir ermittelten writes mitteilen?
Der Systemdruck wäre noch eine sehr feine Sache für FHEM.
Ich kann nach wie vor keine häufigen Abstürze berichten, das Ding läuft stabil auf einem Raspberry Pi. Außerdem wird er durch einen Watchdog überwacht, der ihn im Zweifelsfall innerhalb von 5 Sekunden neu startet.
LG
pah
P.S.: Nur so als Randbemerkung, nichts für ungut aber: Es heißt Dämon, demon oder von mir aus auch noch daemon - aber niemals deamon.
Bis zum heutigen "Build" ist mir die 0.5er Version (auf meinem RPI) nach jedem expliziten Read (Zugriff auf ebus, nicht Polling-Ergebnis) mit Speicherfehler abgestürzt. Nun läuft er prima!
Ich konnte die aktuelle Version bislang nur noch mit dem neuen "find"-Kommando in die Knie zwingen. Aber das ist ja auch brand neu ...
Es wäre also Zeit für eine beta 3 ;)
Hallo heikoh81,
Zitat von: heikoh81 am 27 Dezember 2014, 20:52:46
@amunra:
Könntest du mir deine CSV'S für die heute von dir ermittelten writes mitteilen?
Der Systemdruck wäre noch eine sehr feine Sache für FHEM.
Ein Beispiel für die CSV Zeilen habe ich weiter oben schon gepostet.
Die Zeilen gibt es aber auch schon in der CSV von pah.
################################# Register Messages Boiler,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,THER,,,,08,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Pressure,Fülldruck,,,,0200,,,press;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg16,Reg16,,,,1600,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg17,Reg17,,,,1700,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,FlowTemp,Vorlauftemperatur,,,,1800,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg6B,Reg6B,,,,6B00,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg76,Reg76,,,,7600,,,status;temp;status;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
################################# Get Messages,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,VG Arthur
Stimmt, das ist in den CSV vo pah sogar schon drin.
Trotzdem danke für die schnelle Antwort. Läuft, ich sehe die Werte jetzt in FHEM :-)
Eine verwegene Frage habe ich natürlich, und die betrifft das setzen von Werten.
Wie könnte ich nun die Betriebsmodus von "Auto" auf z.B. "Nacht" setzen (so steuere ich momentan meine Anlage direkt am Calormatic 470, wenn ich das Haus verlasse)?
Oder Beeinflussung der Zieltemperatur?
Viele Grüße,
Heiko
Die CalorMatic ist das Steuergerät. Dann sollte man dem vertrauen und nicht an ihm vorbei die Therme direkt steuern. Es muss also das entsprechende Register in der Calormatic auf den Mode "Absenken" gestellt werden.
Was liefert denn "ebusctl write -h 25B5040101", und zwar jeweils im Normal- und im Nachtmodus ?
LG
pah
Hallo pah,
ja, das wäre natürlich toll, wenn ich über FHEM das Calormatic 470 beeinflussen könnte.
Geht das, d.h. nach Absetzen eines Befehls wechselt die Display-Anzeige des Calormatic 470?
In Betriebsart "Auto":
root@fhemALT:~# ebusctl write -h 25B5040101
ERR: read timeout
Neuester build von gestern. "Nacht" habe ich vorerst nicht probiert.
Viele Grüße,
Heiko
@amunra: Treffen bei dir die von mir genannten Register/Datenpunkte zu?
Wenn ja, bitte mal einen Scan ausführen wenn scan.csv im /etc/ebsud Verzeichnis
Zitatvon pah:
Nee, leider nicht. Register 16,17,6B liefern Werte, die mit keinem Sensor reading kompatibel sind.
vielleicht paßt auch die Konfig nicht zur Anlage.
Bitte ebenfalls einen Scan machen mit 'scan.csv' machen.
Meine Werte:
08b509030d 0200 => Anlagendruck => 1.798;ok
08b509030d 1800 => Vorlauftemperatur => 35.44;ok
08b509030d 1600 => WarmWasser Vorlauf (Soll/Zapf)temperatur => 40.12;ok
08b509030d 1700 => Speicher Ist Temperatur => 39.44;ok
08b509030d 6B00 => Rücklauftemperatur => -1.81;cutoff
08b509030d 7600 => Meine Interpretation: Außentemp ohne tempOffset + Sensor Status + unbekannt => -1.38;0;78.5
Erzeugt mit:
*r,THER,,,,08,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Pressure,Fülldruck,,,,0200,,,press;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg16,Reg16,,,,1600,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg17,Reg17,,,,1700,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,FlowTemp,Vorlauftemperatur,,,,1800,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg6B,Reg6B,,,,6B00,,,temp;sensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,Reg76,Reg76,,,,7600,,,temp;status;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Scan kommt....
VG Arthur
Hast du die Werte irgendwie überprüft? Display?
@yuhu:
Pressure & FlowTemp liefern bei meiner ecotec Plus mit Calormatic 470 die richtigen Werte, geprüft in Fachhandwerker-Therme und soweit zugänglich auch in Fachhandwerkerebene Calormatic.
0200 -> Auf dem Display der Therme
!1600 -> nicht überprüft
1800 -> Taste i -> Taste - (Auf dem Display der Therme)
1700 -> VCR 430 Menü: WWInfo Speichertemp IST
!6B00 -> nicht überprüft
7600 -> über andere Register (z.B: 08,B511,01) bekomme ich den Wert auch.
Der Scan liefert nach ca. 10-15 Minuten Laufzeit:
15;Joh. Vaillant GmbH & Co.;43000;0215;2002
Oft liefert der scan nichts, und steigt schon nach wenigen Sekunden aus.
Message:
>>> scan
2014-12-28 22:28:35.849 [bas event] <<< scan initiated
2014-12-28 22:28:35.919 [bus error] scan 08 failed: ERR: read timeout
2014-12-28 22:28:36.568 [bus event] scan: 15;Joh. Vaillant GmbH & Co.;43 000;0215;2002
2014-12-28 22:28:36.640 [bus error] scan 15 failed: ERR: read timeout
kann es sein, dass du die scan.csv nicht im Verzeichnis /etc/ebusd/ hast?
sonst müsste das ergebnis in etwa so aussehen
53;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301;21112630;6782<<<<0;907005276;N4
nein - die scan.csv (vor ca. 1 Stunde vom GitHub gezogen - Ebusd Stand gestern) liegt im /etc/ebusd Verzeichnis und sieht wie folgt aus:
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment
*r,scan,,,,,B509,,,,,,,,,,,,,
r,,id1,Scan ID,,,,24,,,IGN,,,,,,STR:8,,,
r,,id2,Scan ID,,,,25,,,STR:9,,,,,,,,,
r,,id3,Scan ID,,,,26,,,STR:9,,,,,,,,,
r,,id4,Scan ID,,,,27,,,STR:2,,,,,,IGN:7,,,
@yuhu: Natürlich passt die Konfiguration nicht zur Anlage - darum diskutieren wir ja hier 8)
Aber immerhin kann ich mit meiner Konfiguration schon fast alle Werte auslesen und auch verändern. Scan wolltest Du haben ? Liefert keine neuen Informationen:
15;Joh. Vaillant GmbH & Co.;UI ;0508;6201;21142200;200804650;907005736;N9
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21142100;200804630;907005476;N9
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21142100;200804630;907005476;N9
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21142100;200804630;907005476;N9
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21142100;200804630;907005476;N9
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21142100
15 ist die VRS620 selbst, die anderen Adressen sind die internen Module 23=Zirkulationspumpe CIR 25=Warmwasserkreis HWC 26=Heizkreis HC 50=Mischerkreis MIX EC=Solarkreis SOL
Allerdings erfasst der Scan nicht die angeschlossene Therme VC206C, die hat Adresse 08 => scan.csv müsste um diese Adresse ergänzt werden.
Eine manuelle Abfrage der ID unter Adresse 08 liefert (Formatierung nicht aus scan.csv, sondern von mir)
Joh. Vaillant GmbH & Co.;BAI00 07.03 74.01
LG
pah
Morgen,
@pah
ein 'scan full' müsste auch die Adresse 08 liefern.
für 15;Joh. Vaillant GmbH & Co.;UI ; müsste 0200 der Vorlauffühler sein
Bitte das nachfolgende mal testen.
SolarYield Sum uin 0600
SolarYield ThisYear1 uin 4400
SolarYield ThisYear2 uin 4408
SolarYield ThisYear3 uin 4410
SolarYield ThisYear4 uin 4418
SolarYield ThisYear5 uin 4420
SolarYield ThisYear6 uin 4428
SolarYield ThisYear7 uin 4430
SolarYield ThisYear8 uin 4438
SolarYield ThisYear9 uin 4440
SolarYield ThisYear10 uin 4448
SolarYield ThisYear11 uin 4450
SolarYield ThisYear12 uin 4458
SolarYield LastYear1 uin 4500
SolarYield LastYear2 uin 4508
SolarYield LastYear3 uin 4510
SolarYield LastYear4 uin 4518
SolarYield LastYear5 uin 4520
SolarYield LastYear6 uin 4528
SolarYield LastYear7 uin 4530
SolarYield LastYear8 uin 4538
SolarYield LastYear9 uin 4540
SolarYield LastYear10 uin 4548
SolarYield LastYear11 uin 4550
SolarYield LastYear12 uin 4558
SolarYield Old uin 4600
@yuhu:
Voller Scan liefert auch die 08 zurück.
Register 0200 ist in der Tat der externe Sensor VF1 - der ist aber in meinem System nicht vorhanden, weil die VRS620 die gemessene Vorlauftemperatur von der Therme holt. Die Abfrage via ebusd liefert also immer "cutoff". Wobei mir auffällt: Den Datentyp "sensor" solltet Ihr nicht mit 0=ok;85=circuit;170=cutoff belegen, sondern mit 0=ok;85=short;170=open. Das sind die gebräuchlichen Fachbegriffe.
Die monatsweise solaren Ertragsregister habe ich gestern schon gefunden (SONNE !). Wobei ich allerdings mit dem 4600 noch meine Probleme habe - zeigt jetzt denselben Inhalt wie 0600. Ich hoffe (kann das aber wegen mangelnder Sonne nicht überprüfen), dass 4600 den Wert zur letzten Mitternacht enthält - dann könnte man sehr schön aus der Differenz 0600 - 4600 den Tagesertrag sehen. Da ich auch meine Fotovoltaikanlage mit Tages-, Monats- und Jahreslog verfolge, wäre das eine schöne Ergänzung.
Darüber hinaus hat meine Anlage einen externen Durchflusssensor, der einen Impuls je Liter solaren Durchflusses abgibt und von der VRS620 ausgewertet wird. Zusammen mit dem 3. Speicherfühler, der am solaren Rücklauf hängt, und dem 2. Speicherfühler am Austritt der solaren Schleife im Speicher, benutz die VRS620 dies zur Ertragsmessung. Ich habe aber noch nicht gefunden, in welchem Register die rohe Impulszählung des Durchflusssensors steckt.
Leider ist das Verzeichnis für Anhangdateien voll, ich habe deswegen den gegenwärtigen Stand meiner vrs620.csv, die zughörige OpenOffice Datei (mit Exportbutton, erleichtert die Arbeit etwas) sowie die auf Version 0.5 angepassten Klassendateien für das ECMD-Device ins FHEM-Repository eingespielt: http://svn.code.sf.net/p/fhem/code/trunk/contrib/EBUS.
LG
pah
Edit: Auch für die solaren Ertragsregister habe ich andere Namen vorgesehen, die mehr den internationalen Gepflogenheiten entsprechen.
Könnte mir jemand einen Tipp geben, wie ich Befehle an die Calormatic senden könnte?
Z.B. Änderung von AUTO auf NACHT?
Nur nicht drängeln.
Was ergibt
ebusctl write -h 15B5040101 ?
(15, nicht 25)
Falls ein Timeout kommt, bitte einfach noch einmal absetzen.
LG
pah
Vielen Dank für deine schnelle Ant.
In Betriebsart Auto:
root@fhemALT:~# ebusctl write -h 15B5040101
0000
Was genau wurde mit diesem Kommando abgefragt?
Viele Grüße,
Heiko
Der Betriebszustand der CalorMatic.
Offenbar liefert sie aber für sich selbst nichts Sinnvolles zurück. Also fragen wir mal beim Heizkreis an
ebusctl write -h 26B5040101
LG
pah
Hmm, leider auch nicht besser :-(
root@fhemALT:~# ebusctl write -h 26B5040101
0000
Es fällt mir etwas schwer, dies zu glauben - denn das Steuergerät wird entweder komplett die Antwort verweigern, oder zusammen mit dem Datenwert sowohl die Anzahl der Datenbytes als auch einen CRC-Code liefern.
Also bitte mal mitteilen, (bei diesen beiden Kommandos), welche _Rohdaten_ auf dem Bus zu lesen sind (ebusd evtl. im Vordergrund starten).
LG
pah
@heikoh81
Welche Befehle hast du den für Ident 47000 schon identifiziert?
Hallo Roland,
bei mir laufen u.a folgende broadcast messages:
1008b511010189
1008b51101028a
Diese habe ich versucht in die broadcast.csv abzulegen und bekomme beim "reload" eine Meldung "ERR: duplicate entry" (Bei eigenen Templates bekomme ich auch diese Meldung).
Die Einträge sehen so aus:
b,broadcastStatus1,Status1,VL/RL/AussenT/VLWW/RLWW/Status,,08,B511,01,01,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,broadcastStatus2,Status2,OP Data from CI to Burner CU,,08,B511,01,02,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Hier wird scheinbar nur bis zu der Datenlänge geprüft?
Wie könnten die Einträge aussehen?
Danke.
P.S. Ein Fullscan hat heute funktioniert und liefert bei mir das:
08;Joh. Vaillant GmbH & Co.;BAI00;0516;7401
15;Joh. Vaillant GmbH & Co.;43000;0215;2002
26;Joh. Vaillant GmbH & Co.;43000;0215;2002
S/N wird wohl nicht mehr ermittelt bzw. ausgewertet.
EDIT:
ok, ich habe es wie folgt geändert (Source address hinzugefügt) und nun funktioniert es (gut, schön ist es nicht):
b,,Status,VL/RL/AussenT/VLWW/RLWW/Status,,08,B511,01,01,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
b,,Status2,OP Data from CI to Burner CU,10,08,B511,01,02,,temp1;temp1;temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
EDIT2:
Zu früh gefreut, Status2 nimmt die Status Werte an:
OK
update MS cmd: 1008b511010189 / 097a5c90014e4c0100ffb1
[upd event] update broadcast Status2: 61.0;46.0;1.562;39.0;38.0;1
nicht OK
[upd trace] update MS cmd: 1008b51101028a / 05033c96507884
[upd event] unknown MS cmd: 1008b51101028a / 05033c96507884
Nein, das sind keine Befehle an die CalorMatic, sondern allesamt zyklische Statusabfragen der CalorMatic an die Therme (10->08).
Es sei ganz ernsthaft (Lebensgefahr!) davor gewarnt, die Therme mit aktiven Steuerungsbefehlen an der CalorMatic vorbei steuern zu wollen. Aktive Steuerungsbefehle dürfen nur an die CalorMatic abgesetzt werden. Bisher haben wir aber noch nicht einmal versucht, sie zu steuern - die ganzen ausgetesteten Befehle sind lediglich Statusabfragen
(
@yuhu: Insofern ist es mehrdeutig, statt des ebusd-Kommando "hex" jetzt "write -h" zu verwenden
)
Also folgende Vorgehensweise: Wir testen jetzt mal den lesenden Zugriff auf die internen Register der CalorMatic. Mit
ebusctl write -h 15B509030D0000
wird das erste Register abgefragt, mit der Endung 0100 das 2. etc.. Bitte mal fortsetzen für die ersten 16 Register, also bis 15B509030D0F00
Die Antwort sollte jeweils aus mindestens 4 Byte bestehen.
Desweiteren kann man versuchen, das interne Heizkreismodul der CalorMatic lesend anzusprechen (jeweis als ebusctl write -h):
Registerabfragen 26B509030D0000 bis 0F00
Statusabfragen 26B5040100 bis 0F
LG
pah
Zitat von: Prof. Dr. Peter Henning am 30 Dezember 2014, 06:57:05
Es sei ganz ernsthaft (Lebensgefahr!) davor gewarnt, die Therme mit aktiven Steuerungsbefehlen an der CalorMatic vorbei steuern zu wollen. Aktive Steuerungsbefehle dürfen nur an die CalorMatic abgesetzt werden.
Ich kann dem nur beipflichten.
Zitat von: Prof. Dr. Peter Henning am 30 Dezember 2014, 06:57:05
(
@yuhu: Insofern ist es mehrdeutig, statt des ebusd-Kommando "hex" jetzt "write -h" zu verwenden
)
Jein, mit "write -h" wird der angegeben Hex-String (so wie er ist) auf den Bus geschrieben. Natürlich könnte man auch eine "read -h" implementieren. Ein write trifft es aber besser.
@yuhu: Nein, das meine ich anders. Aus Sicherheitsgründen sollte ein Benutzer in der Konfigurationsdatei (nicht in der CSV, sondern auf der Kommandozeile bzw. in der Einstellungsdatei) explizit angeben müssen, dass er Schreibbefehle absetzen will. Wenn man es ganz komfortabel haben will, könnte man im ebusd all die Kommandos, die tatsächliche Steuerbefehle absetzen, von einer weiteren expliziten Einstellung abhängig machen. Für Vaillant wären das in der Regel die B509030E und die B505-Befehle - aber erstens weiß ich (noch) nicht, ob es da noch weitere verändernde Befehle gibt, und zweitens benutzen natürlich noch andere Hersteller den EBUS.
LG
pah
P.S.: Ich habe mit Entsetzen festgestellt, dass in der allerneuesten trunk-Version vom ebusd meine Konfigurationsdatei nicht mehr das tut, was sie soll :(
Edit: Ist auch kein Wunder, man sollte keine global changes machen.... mein Fehler.
Hallo,
danke für die Informationen.
Dann habe ich broadcast Befehle, die offensichtlich auf den Bus schreiben (ein Senden an alle bzw. in die Runde), mit "auf dem Bus mitlauschen und die Messages abgreifen", falsch interpretiert.
Meine Idee war die Daten, die sowieso schon von den Teilnehmern über den Bus geschickt werden, zu verwenden. Aktiv abfragen ist sicher sinnvoller.
Derzeit beschäftige ich mich "nur" mit den bekannten Get Befehlen, an die Set Befehle möchte ich im Moment noch nicht dran.
VG Arthur
P.S: @pah es werden sicher viele Daten die Abgegriffen werden können. Wie ist deine bisherige Erfahrung mit ECMD und den classdefs (es sind sicher schon ein paar Hundert Zeilen Code oder)?. Ich denke, dass es schnell unübersichtlich wird? Siehst du Optimierungspotenziale (Verwendung der CSV als Template, etc.) in der bisherigen Implementierung? Danke.
Die classdefs sind deshalb wichtig, weil sie bestimmen, was in FHEM als "get" und "set" angezeigt wird (jedenfalls, so lange es noch kein Vaillant-Modul gibt ;) ).
Der eigentliche Code steht bei mir in der Datei 99_myUtils.pm, das ist viel flexibler. Neben manuell auszuführenden get-Befehlen (z.B. get TimerProgMonday) sind aber nur zwei wichtig: get mode (zyklisch von FHEM abgefragt einmal morgens kurz nach Mitternacht, holt die wesentlichen Einstellungsparameter; jeweils für Heizung, Warmwasser, Solar) und get state (zyklisch alle 60 Sekunden, fragt den aktuellen Betriebszustand ab).
LG
pah
@pah:Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2014, 18:50:33
Es fällt mir etwas schwer, dies zu glauben - denn das Steuergerät wird entweder komplett die Antwort verweigern, oder zusammen mit dem Datenwert sowohl die Anzahl der Datenbytes als auch einen CRC-Code liefern.
Also ich poste hier keine
falschen Rückmeldungen.
Ich poste genau das, was ich erhalte. Da habe ich auch viel zu wenig Ahnung um hier irgendjemand in die Irre führen zu wollen und auch zu viel Respekt von der vielen Mühe aller Teilnehmer, die in der Entwicklung und Entschlüsselung dieses ebusd liegt!!!!
ZitatAlso bitte mal mitteilen, (bei diesen beiden Kommandos), welche _Rohdaten_ auf dem Bus zu lesen sind (ebusd evtl. im Vordergrund starten).
Ich habe also ebusd im Vordergrund gestartet mit:
ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888Dann 2. Telnet-Verbindung zum Raspberry aufgebaut und dieses Kommando abgesetzt:
ebusctl write -h 15B5040101Ergebnis: (ich habe ein paar Zeilen davor und danach stehen lassen)
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
2014-12-30 14:36:50.979 [bas event] ebusd started
2014-12-30 14:36:50.981 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-30 14:36:50.995 [bas trace] read templates
2014-12-30 14:36:51.061 [bas trace] read config files
2014-12-30 14:36:51.062 [bas event] message DB: 117
2014-12-30 14:36:51.063 [bas event] updates DB: 15
2014-12-30 14:36:51.064 [bas event] polling DB: 0
2014-12-30 14:36:53.427 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:36:53.429 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:36:55.279 [upd trace] update MS cmd: 1008b50401003d / 0a035736143012021410019a
2014-12-30 14:36:55.538 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:36:55.772 [upd trace] update MS cmd: 1008b512020000ca / 0000
2014-12-30 14:37:12.941 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:37:13.217 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:13.218 [upd event] update MS SetBoiler: 1;77.0
2014-12-30 14:37:13.659 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:37:13.661 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:37:15.603 [upd trace] update BC cmd: 10feb51603011001ef
2014-12-30 14:37:15.605 [upd event] update BC OutsideTempBC: 1.062
2014-12-30 14:37:19.746 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:19.748 [upd event] update MS SetBoiler: 1;77.0
2014-12-30 14:37:20.053 [net trace] [00001] connection opened 127.0.0.1
2014-12-30 14:37:20.056 [bas event] >>> write -h 15B5040101
2014-12-30 14:37:20.057 [bas event] write hex cmd: ff15b5040101d6
2014-12-30 14:37:20.165 [bus event] read res: 0000
2014-12-30 14:37:20.167 [bas event] <<< 0000
2014-12-30 14:37:20.175 [net trace] [00001] connection closed
2014-12-30 14:37:23.728 [upd trace] update MS cmd: 1008b511010189 / 096d601001ff490100ff97
2014-12-30 14:37:23.730 [upd event] update MS StatusHC: 54.5;48.0;16;1;1
2014-12-30 14:37:25.837 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:37:29.815 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:37:29.817 [upd event] update MS SetBoiler: 1;77.0
^C2014-12-30 14:37:30.565 [bas event] SIGINT received
2014-12-30 14:37:30.682 [bas event] ebusd stopped
Das Abschießen von ebusd geschieht wohl durch STRG + C, wenn ich den Code hier fürs Forum kopiere - ebusd vom 26.12.2014 läuft extrem stabil seit mehreren Tagen 24/7, trotz minütlicher Telnet-Abfragen über FHEM.
Dasselbe dann nochmal für Befehl:
ebusctl write -h 26B5040101
root@fhemALT:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
2014-12-30 14:42:25.582 [bas event] ebusd started
2014-12-30 14:42:25.583 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-30 14:42:25.596 [bas trace] read templates
2014-12-30 14:42:25.651 [bas trace] read config files
2014-12-30 14:42:25.652 [bas event] message DB: 117
2014-12-30 14:42:25.653 [bas event] updates DB: 15
2014-12-30 14:42:25.654 [bas event] polling DB: 0
2014-12-30 14:42:26.559 [upd trace] update MS cmd: 1008b51101028a / 06033c82468c6eba
2014-12-30 14:42:27.584 [net trace] [00001] connection opened 127.0.0.1
2014-12-30 14:42:27.587 [bas event] >>> write -h 26B5040101
2014-12-30 14:42:27.587 [bas event] write hex cmd: ff26b50401017c
2014-12-30 14:42:27.668 [bus event] read res: 0000
2014-12-30 14:42:27.669 [bas event] <<< 0000
2014-12-30 14:42:27.677 [net trace] [00001] connection closed
2014-12-30 14:42:28.557 [upd trace] update MS cmd: 1008b5100900006dffffff04ff00b7 / 01019a
2014-12-30 14:42:28.559 [upd event] update MS SetBoiler: 1;77.0
^C2014-12-30 14:42:32.323 [bas event] SIGINT received
2014-12-30 14:42:32.441 [bas event] ebusd stopped
root@fhemALT:~# ebusctl write -h 15B509030D0000
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0200
01019a
root@fhemALT:~# ebusctl write -h 15B509030D0300
0712310e011e0c0e40
root@fhemALT:~# ebusctl write -h 15B509030D0400
01019a
root@fhemALT:~# ebusctl write -h 15B509030D0500
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0600
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0700
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0800
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0900
010299
root@fhemALT:~# ebusctl write -h 15B509030D00A0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00B0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00C0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00D0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00E0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00F0
036e01000a
Zitat von: yuhu am 29 Dezember 2014, 20:28:43
@heikoh81
Welche Befehle hast du den für Ident 47000 schon identifiziert?
Ich verwende die von pah bereitgestellten Dateien - selbst konnte ich leider noch nichts entschlüsseln :-(
http://forum.fhem.de/index.php/topic,29737.msg235842.html#msg235842
Wie kann ich jetzt weitermachen?
Viele Grüße,
Heiko
Hier liefere ich noch die fehlenden Abfragen nach.
Zitat von: Prof. Dr. Peter Henning am 30 Dezember 2014, 06:57:05
ebusctl write -h 26B509030D0000 bis 0F00 (Registerabfragen):
root@fhemALT:~# ebusctl write -h 26B509030D0000
036f01001c
root@fhemALT:~# ebusctl write -h 26B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0200
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0300
076363636363636310
root@fhemALT:~# ebusctl write -h 26B509030D0400
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0500
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0600
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0700
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0800
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0900
010299
root@fhemALT:~# ebusctl write -h 26B509030D0A00
0200002c
root@fhemALT:~# ebusctl write -h 26B509030D0B00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0C00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0D00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0E00
01009b
root@fhemALT:~# ebusctl write -h 26B509030D0F00
01009b
ebusctl write -h 26B5040100 bis 0F (Statusabfragen):
root@fhemALT:~# ebusctl write -h 26B5040100
0000
root@fhemALT:~# ebusctl write -h 26B5040101
0000
root@fhemALT:~# ebusctl write -h 26B5040102
0000
root@fhemALT:~# ebusctl write -h 26B5040103
0000
root@fhemALT:~# ebusctl write -h 26B5040104
0000
root@fhemALT:~# ebusctl write -h 26B5040105
0000
root@fhemALT:~# ebusctl write -h 26B5040106
0000
root@fhemALT:~# ebusctl write -h 26B5040107
0000
root@fhemALT:~# ebusctl write -h 26B5040108
0000
root@fhemALT:~# ebusctl write -h 26B5040109
0000
root@fhemALT:~# ebusctl write -h 26B504010A
0000
root@fhemALT:~# ebusctl write -h 26B504010B
0000
root@fhemALT:~# ebusctl write -h 26B504010C
0000
root@fhemALT:~# ebusctl write -h 26B504010D
0000
root@fhemALT:~# ebusctl write -h 26B504010E
0000
root@fhemALT:~# ebusctl write -h 26B504010F
0000
Warum ist es lebensgefährlich, wenn man an der Calormatic vorbeisteuert?
Was lebensgefährliches möchte ich nicht tun!
Die Heizung müsste sich doch egal welche Befehle ich ihr absetze immer im Rahmen ihrer physikalischen Grenzen (Maximal-Temperaturen etc.) bewegen, oder?
Viele Grüße,
Heiko
root@fhemALT:~# ebusctl write -h 15B509030D0000
036e01000a
=====> 03= Länge in Bytes 6e 01 = 016e = Temperaturwert (Datentyp temp.) Könnte die Außentemperatur sein, irgendetwas um 1,5 Grad Celsius 0a= CRC
root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
=====> 01 = Länge, Datenwert 0, 9b=CRC
root@fhemALT:~# ebusctl write -h 15B509030D0200
01019a
=====> 01 = Länge, Datenwert 1, 9a=CRC
root@fhemALT:~# ebusctl write -h 15B509030D0300
0712310e011e0c0e40
=====> 7 Bytes. Ich rate mal: 12h = 18 = Absenktemperatur 31h = 49 ?? Idealerweise die Parameter der Heizung verändern, und dieses register noch mal abfragen
root@fhemALT:~# ebusctl write -h 15B509030D0400
01019a
root@fhemALT:~# ebusctl write -h 15B509030D0500
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0600
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0700
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0800
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0900
010299
=====> AAAH: 1 Byte, dann ein Datenwert 02, dann CRC. Ist ein Statuscode. Wie verändert sich der, wenn man auf "Nacht" umschaltet ?
root@fhemALT:~# ebusctl write -h 15B509030D00A0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00B0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00C0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00D0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00E0
036e01000a
root@fhemALT:~# ebusctl write -h 15B509030D00F0
036e01000a
Code: [Auswählen]
root@fhemALT:~# ebusctl write -h 26B509030D0000
036f01001c
=====> 3 bytes Könnte Temperatur + Sensorstatus sein
etc.
Mach doch bitte mal eine ordentliche OpenOffice- oder Excel-Tabelle
LG
pah
Anbei die Befehle nochmals ausgeführt, Betriebsart Auto, Außentemperatur 1,06°C, Rücklauf 49°C.
root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0300
072a0d11011e0c0ec4
root@fhemALT:~# ebusctl write -h 15B509030D0900
010299
Betriebsart Nacht:
root@fhemALT:~# ebusctl write -h 15B509030D0900
01009b
Update: Außentemp: 1,06 °C, Rücklauf: 37,50°C
root@fhemALT:~# ebusctl write -h 15B509030D0100
01009b
root@fhemALT:~# ebusctl write -h 15B509030D0300
076363636363636310
Und nach Umschalten auf Betriebsart: "Systemaus (Frostschutz Aktiv)":
root@fhemALT:~# ebusctl write -h 15B509030D0900
01009b
Die Antworten für "Nacht" und "Systemaus" sind gleich.
Vielleicht ist das der Brennerstatus = Aus?
Könnte man daraus jetzt schon einen set-Befehl ableiten?
Aber ja. Versuch mal, das Register 0900 von außen zu beschreiben (Befehl ist 0E statt 0D für lesen)
15B509040E090000
Der könnte dann von "auto" auf "nacht" umschalten (keine Garantie - vielleicht zündet das auch die pannensichere Selbstvernichtung ;D )
Und mach von den erfolgreich gelesenen Werten mal eine Tabelle.
LG
pah
Also das funktioniert leider nicht.
Ich habe sowohl 15B509040E090000 als auch 15B509040E0900 probiert, weil das Kommando ja 2 Stellen länger war als bisher.
Output im ebusd-Vordergrund siehe unten.
2014-12-30 17:42:07.588 [net trace] [00014] connection opened 127.0.0.1
2014-12-30 17:42:07.591 [bas event] >>> write -h 15B509040E090000
2014-12-30 17:42:07.593 [bas event] write hex cmd: ff15b509040e09000056
2014-12-30 17:42:07.687 [bus event] read res: 0000
2014-12-30 17:42:07.690 [bas event] <<< 0000
2014-12-30 17:42:07.697 [net trace] [00014] connection closed
2014-12-30 17:42:10.516 [upd trace] update MS cmd: 1008b511010189 / 094a4a1001ff450000ffd3
2014-12-30 17:42:10.518 [upd event] update MS StatusHC: 37.0;37.0;16;1;0
2014-12-30 17:42:14.471 [net trace] [00015] connection opened 127.0.0.1
2014-12-30 17:42:14.474 [bas event] >>> write -h 15B509040E0900
2014-12-30 17:42:14.474 [bas event] write hex cmd: ff15b509040e090030
2014-12-30 17:42:14.565 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:15.132 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:15.699 [bus error] ERR: read timeout, retry send
2014-12-30 17:42:16.268 [bus error] ERR: read timeout,
2014-12-30 17:42:16.268 [bas error] write hex: ERR: read timeout
2014-12-30 17:42:16.268 [bas event] <<< ERR: read timeout
2014-12-30 17:42:16.276 [net trace] [00015] connection closed
Übrigens ist mein FHEM sofort wieder abgeschmiert, nachdem ich mit STRG + C die Werte aus putty kopiert und damit ebusd beendet habe.
Auch nach 4 Minuten bei 100% hat er sich nicht wieder gefangen, obwohl ebusd zwischenzeitlich wieder lief auf dem anderen Raspi.
Soll ich das mal in die Modul-Gruppe posten? Weil es hat eigentlich nix mit diesem Thread zu tun sondern muss an ECMD liegen?
014.12.30 17:42:32 1: 192.168.178.239:8888 disconnected, waiting to reappear (EBUS)
2014.12.30 17:42:32 1: 192.168.178.239:8888 reappeared (EBUS)
2014.12.30 17:46:39 1: Including fhem.cfg
PN an Boris ist raus. Habe das Problem nur ich?
Hab ihm geschrieben dass er gerne auch hier für alle Antworten kann.
Umschalten habe ich nur per Telnet auf dem ebusd-Raspi gemacht.
In FHEM werden bisher nur Werte gelesen und angezeigt (so habe ich die Abstürze bemerkt).
Hallo, poste mal Logs vom abstürzenden FHEM mit verbose 5 und logTraffic. Viele Grüße Boris
@yuhu
0b 4845495a4b524549532000 3b => HEIZKREIS => Name HZ1
Ich finde im Template kein entsprechenden Typ - oder übersehe ich etwas?
VG Arthur
STR:10
LG
pah
25 und damit vermutlich ca. 1/3 der Regsiter der VRC430 konnte ich heute Abend abfragen und entschlüsseln können.
VG Arthur
Gratulation.
LG
pah
Über "keinen" kann ich nichts sagen - aber ich habe es nicht.
LG
pah
Hmm, also was habe ich was andere vielleicht nicht haben?
- 2 FHEM-Slaves, über Telnet angebunden, Port 7072 und 7073
- pilight zur Steuerung von 433Mhz-Aktoren, pilight hat auch ein Master-Slave-Konzept eingebaut, ich habe aber nur 1 Master
Zwischenzeitlich habe ich den ebusd-Raspi mal komplett neu aufgesetzt, Basis Raspbian-Image vom 24.12.2014 mit allen Updates.
Deshalb musste ich auch ebusd neu kompilieren.
@pah:
Mit der neuesten ebusd Rev. 593 erhalte ich mit neuester _template.csv von Github für deine Vaillant.csv:
root@raspiebus:~# ebusd --checkconfig
2014-12-31 14:49:23.311 [bas event] ebusd started
2014-12-31 14:49:23.312 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-31 14:49:23.328 [bas trace] read templates
Error reading "/etc/ebusd/Vaillant_Protokoll_kurz.csv" line 15 field 17 value "": ERR: duplicate entry
Erroneous item is here:
"r","","RoomTempHoliday","Ferien Solltemperatur","","","","2200","","","temp","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
Error reading "/etc/ebusd/Vaillant_Protokoll_kurz.csv" line 18 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","Password","Passwort","","","","2C00","","","pin1-4","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
Error reading "/etc/ebusd/Vaillant_Protokoll_kurz.csv" line 85 field 17 value "": ERR: duplicate entry
Erroneous item is here:
"r","HWC","NightTemp","Absenktemperatur","","25","B504","0A","","","temp0;status","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
2014-12-31 14:49:23.394 [bas trace] read config files
2014-12-31 14:49:23.395 [bas event] message DB: 114
2014-12-31 14:49:23.396 [bas event] updates DB: 15
2014-12-31 14:49:23.397 [bas event] polling DB: 0
2014-12-31 14:49:23.400 [bas event] ebusd stopped
Was ist denn da der doppelte Wert?
Und nach Auskommentieren der genannten Zeile (da ich diese nicht momentan verwende).
root@raspiebus:~# ebusd --checkconfig
2014-12-31 14:52:07.834 [bas event] ebusd started
2014-12-31 14:52:07.835 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-31 14:52:07.851 [bas trace] read templates
Error reading "/etc/ebusd/Vaillant_Protokoll_kurz.csv" line 18 field 14 value "": ERR: file/element not found or not readable
Erroneous item is here:
"r","","Password","Passwort","","","","2C00","","","pin1-4","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
2014-12-31 14:52:07.909 [bas trace] read config files
2014-12-31 14:52:07.910 [bas event] message DB: 114
2014-12-31 14:52:07.911 [bas event] updates DB: 15
2014-12-31 14:52:07.911 [bas event] polling DB: 0
2014-12-31 14:52:07.915 [bas event] ebusd stopped
root@raspiebus:~#
Nach Auskommentieren aller 3 Zeilen läuft ebusd --checkconfig durch:
root@raspiebus:~# ebusd --checkconfig
2014-12-31 14:53:07.363 [bas event] ebusd started
2014-12-31 14:53:07.364 [bas trace] path to ebus configuration files: /etc/ebusd
2014-12-31 14:53:07.380 [bas trace] read templates
2014-12-31 14:53:07.434 [bas trace] read config files
2014-12-31 14:53:07.435 [bas event] message DB: 114
2014-12-31 14:53:07.436 [bas event] updates DB: 15
2014-12-31 14:53:07.437 [bas event] polling DB: 0
2014-12-31 14:53:07.440 [bas event] ebusd stopped
root@raspiebus:~#
Also mit der rev. 593 scheint nun alles nicht mehr richtig zu funktionieren.
Ich verwende die neueste template.csv und die Vaillant_Protokoll_kurz.csv, und einfachste Abfragen über manuelles Telnet klappen nicht mehr.
Erstaundlicherweise laufen diese Daten aber im Klartext über den ebusd-Log:
2014-12-31 15:14:35.422 [upd trace] update MS cmd: 1008b5100900006cffffff04ff004a / 01019a
2014-12-31 15:14:35.424 [upd event] update MS SetBoiler: 1;77.0
2014-12-31 15:14:39.520 [upd trace] update MS cmd: 1008b511010189 / 096046c002ff240100ffb6
2014-12-31 15:14:39.522 [upd event] update MS StatusHC: 48.0;35.0;192;2;1
2014-12-31 15:14:41.489 [upd trace] update MS cmd: 1008b5100305ff0198 / 01019a
2014-12-31 15:14:41.491 [upd event] unknown MS cmd: 1008b5100305ff0198 / 01019a
2014-12-31 15:14:44.253 [bas event] >>> read MS StatusHC
2014-12-31 15:14:44.254 [bas event] <<< message not defined
Im aktuellen ebusd git #bbd1353 kann die Klasse weggelassen werden, oder muss mit "-c" angegeben werden, also z.B.:
read StatusHC
@john30:
Das funktioniert.
Leider funktioniert das /etc/init.d/ebusd skript auch nicht mehr richtig - zumindest kommt gar keine Rückmeldung.
Auch mit komplett frischem Raspi, der nur ebusd drauf hat, stürzt FHEM in der Millisekunde ab, in der ich ebusd beende.
Es muss also an ECMD liegen.
okay, ECMD Problematik kann ich (noch) nicht beurteilen
Zitat von: john30 am 31 Dezember 2014, 15:48:10
Im aktuellen ebusd git #bbd1353 kann die Klasse weggelassen werden, oder muss mit "-c" angegeben werden, also z.B.:
read StatusHC
Hallo john30,
heißt das, dass der name(id) unique sein muss?
r THERM Aussentemp
r CI Aussentemp
darf es nicht geben?
VG Arthur
nein, es muss Klasse+Name unique sein (wird bei Start bzw. configcheck dann auch angemeckert).
Lässt man bei der Abfrage die Klasse weg, wird die erste Nachricht mit dem angegebenen Namen verwendet.
Zitat von: john30 am 31 Dezember 2014, 16:13:29
Lässt man bei der Abfrage die Klasse weg, wird die erste Nachricht mit dem angegebenen Namen verwendet.
darauf wollte ich hinaus - bei mehren configs (therme.csv ci.csv etc.) ist dann die Reihenfolge interessant.
Ich pers. werde die classe immer angeben, dann bin ich mir sicher wen ich anspreche. ;o)
Danke.
Hm, ich habe gestern etwa eine Stunde gebraucht, um das herauszufinden:
Ich traue dem auch noch nicht ganz - weil es nämlich durchaus Sinn machen könnte, die unterschiedlichen Teilgeräte auf unterschiedliche CSV-Dateien aufzuteilen. Dann hängt die Reihenfolge vom Dateinamen ab.
@heikoh81: pin1-4 ist nicht mehr aktuell, die Typen wurden umgebaut. Muss durch "code" ersetzt werden.
LG
pah
P.S.: Ich habe heute keine weiteren Arbeiten am EBUS vorgenommen, sondern eine Lösung programmiertt, die aus 12 Abfragen (im Abstand von je 2 Sekunden, um den normalen EBUS-Verkehr nicht zu behindern) eine Jahreslogdatei für meinen solaren Ertrag zusammenbaut, die mit normalen FHEM-Mitteln visualisiert werden kann.
Bei automatisierten Abfragen würde raten, immer die Klasse mit anzugeben. Für den manuellen Fall ist es ganz praktisch, weil es einfach schneller geht :) Dafür haben wir jetzt aber auch die noch elegantere Lösung über das "find" Kommando (z.B. "find temp").
@pah: ebusd beherrscht jetzt die Arbitrierung laut ebus Spezifikation inkl. forciertem Warten auf N SYN Symbole nach Verlust der Arbitrierung (Parameter --numbermasters). Insofern gibt es m.E. keinen Grund mehr, Wartezeit einzubauen.
Aus Sicht von FHEM aber schon. 12 EBUS reads in einem einzigen ECMD-Aufruf sind schon etwas heftig.
LG
pah
Zitat von: john30 am 31 Dezember 2014, 16:13:29
nein, es muss Klasse+Name unique sein (wird bei Start bzw. configcheck dann auch angemeckert).
Lässt man bei der Abfrage die Klasse weg, wird die erste Nachricht mit dem angegebenen Namen verwendet.
Das dürfte auch die von mir hier gepostete Fehlermeldung beim Configcheck erklären?
Wenn man es weiß, kein Problem. Mich hat es - wie pah auch - mind. 1h gekostet.
Gibt es irgendwo einen Changelog? Der bei Github enthält nur ein paar Zeilen allg. Text, und aus den Protokollen werde ich nicht wirklich schlau.
Ich denke auf eine so wichtige Änderung sollte irgendwo aktiv hingewiesen werden.
Viele Grüße,
Heiko
Guten Rutsch in die Runde.
LG
pah
Auch von mir einen Guten Rutsch an alle.
Auf ein Gutes Neues!
Viele Grüße,
Heiko
Mit dem neuen ebusd scheint es ein weiteres Problem zu geben, und zwar scheint die Telnet-Abfrage 2 Leerzeichen nach den Werten zurückzuliefern.
Dadurch funktioniert die Aufbereitung nicht mehr (aus dem FHEM-Wiki).
Also bei den alten Revs kam da keine Leerzeile. Ich glaube das müssen sich die ebusd-Programmierer mal anschauen, ob das Absicht oder ein Fehler ist.
read -c BC OutsideTempBC
2.062
read OutsideTempBC
2.062
FHEM-Log:
2014.12.31 18:20:46 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:21:33 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:22:34 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
2014.12.31 18:22:35 1: EBUS: unexpected answer "2.062\n\n" received (wrote "read -c BC OutsideTempBC", expected .*)
Meine Aufbereitungsdatei ebus_systemdruck.cfg:
# VaillantSystemdruck
get VaillantSystemdruck cmd {"read -c THER Pressure\n\n"}
get VaillantSystemdruck expect ".*"
get VaillantSystemdruck postproc { my ($SYSTEMDRUCK,$STATUS,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$SYSTEMDRUCK = "Keine Werte vorhanden";\
$STATUS = "Keine Werte vorhanden";\
}else{\
my @values=split(';',$_);\
$SYSTEMDRUCK = sprintf("%5.2f Bar",$values[0]);\
$STATUS = $values[1];\
$zval = sprintf("Systemdruck %5.2f Bar, Systemdruck Status %s", $values[0], $values[1]);\
}\
readingsSingleUpdate($hash, "Systemdruck", $SYSTEMDRUCK, 1);\
readingsSingleUpdate($hash, "Systemdruck Status", $STATUS, 1);\
$zval; }
Ich habe oben jetzt schon alle 3 Varianten probiert, leider kein Erfolg:
get VaillantSystemdruck cmd {"read -c THER Pressure\n\n"}
get VaillantSystemdruck cmd {"read -c THER Pressure\n"}
get VaillantSystemdruck cmd {"read -c THER Pressure"}
In Folge kommen in FHEM leider keine Werte mehr an.
Viele Grüße,
Heiko
Hallo,
habe dieses Topic geteilt und die ECMD-relevanten Teile in das zutreffende Forum verschoben.
Melde mich aus diesem Topic hier ab.
Grüße
Boris
Zitat von: heikoh81 am 31 Dezember 2014, 17:07:12
Das dürfte auch die von mir hier gepostete Fehlermeldung beim Configcheck erklären?
Wenn man es weiß, kein Problem. Mich hat es - wie pah auch - mind. 1h gekostet.
Gibt es irgendwo einen Changelog? Der bei Github enthält nur ein paar Zeilen allg. Text, und aus den Protokollen werde ich nicht wirklich schlau.
Ich denke auf eine so wichtige Änderung sollte irgendwo aktiv hingewiesen werden.
@heikoh81: wir sind mit ebusd immer noch im Beta Status, deshalb ist mit Änderungen, neuem Verhalten etc. nach wie vor zu rechnen. Sobald wir einen Release-Status erreicht haben, gibt es natürlich auch ein Changelog.
Mit der Option --configcheck sollte doch relativ klar sein, was falsch ist, oder nicht? Zumindest werden Duplikate mit entsprechender Meldung versehen und auch so gut wie möglich auf die fehlerhafte Position hingewiesen.
Zitat von: heikoh81 am 31 Dezember 2014, 18:27:33
Mit dem neuen ebusd scheint es ein weiteres Problem zu geben, und zwar scheint die Telnet-Abfrage 2 Leerzeichen nach den Werten zurückzuliefern.
Dadurch funktioniert die Aufbereitung nicht mehr (aus dem FHEM-Wiki).
Also bei den alten Revs kam da keine Leerzeile. Ich glaube das müssen sich die ebusd-Programmierer mal anschauen, ob das Absicht oder ein Fehler ist.
read -c BC OutsideTempBC
2.062
read OutsideTempBC
2.062
Wir haben vor kurzem auf ein HTTP-ähnliches Protokoll geschwenkt, weil ebusd jetzt auch mehr als eine Ergebnis-Zeile liefern kann. Deshalb ist das Ender der ebusd-Mittelung nun mit einer Leerzeile nach allen Daten markiert.
Ich schätze, das müsste im "expect" angepasst werden, sofern das einen Zeilenumbruch im String verträgt.
Die Anfrage ist nach wie vor mit einem einfachen Zeilenumbruch zu stellen, hier gibt es derzeit noch keinen Anwendungsfall um mehr als eine Zeile übertragen zu müssen/wollen. Insofern könnte es so stimmen:
# VaillantSystemdruck
get VaillantSystemdruck cmd {"read -c THER Pressure\n"}
get VaillantSystemdruck expect ".*\n"
...
Hier mal ein Beispiel, das bei mir funktioniert:
define ebusd ECMD telnet localhost:8888
set ebusd classdef ebusd ebusd.classdef
define ebus ECMDDevice
set ebus class ebusd
get ebus outsidetemp
Und die ebusd.classdef dazu:
get outsidetemp cmd {"r outsidetemp\n"}
get outsidetemp expect "\d+\.\d+\n\n"
get outsidetemp postproc { s/^(\d+\.\d+)\n\n$/$1/;; $_ }
Ich halte sehr viel mehr davon, solche Nachbearbeitung nicht in der ECMD-Klassendefinition unterzubringen, sondern mit einem ordentlichen Perl-Programm zu arbeiten.
LG
pah
@pah: ganz meiner Meinung. Stünde ich nicht mit Perl so auf Kriegsfuß, wäre das schon längst in meinem FHEM im Produktivbetrieb :)
Mal etwas Anderes: Mein EBUS-System ist immer noch etwas wirr in Bezug auf Broadcasts und direkte Abfragen.
Ich hatte bisher separate Klassen für die internen Module der vrs620, Beispiel: Klasse HC steht für Adresse 26 = Heizkreis 1.
Sowie eine Klasse MS für Master-Slave-Befehle, die auf dem Bus herumlaufen. Ein checkconfig findet keine Fehler
Jetzt habe ich in der Konfig
*re,SOL,,,,EC,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
re,,Status3,KollTemp/Status/Füllung/Power,,,,21,,,temp1;skip;status;percent1;percent1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
u,MS,StatusSOL3,KollTemp/Status/Füllung/Power,10,EC,B504,21,,,temp1;skip;status;percent1;percent1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Das Problem ist, dass mit Eurem neuen Parser der zyklisch gelesene MS-Befehl niemals erkannt wird, sondern eine MS-Message 10ECB5040121 (von 10->EC) bereits als "Status3" abgeheftet wird. Ein
ebusctl read MS StatusSOL3
liefert also immer "no data stored".
Allerdings greift ein
ebusctl read SOL Status3
nicht auf die empfangenen MS-Daten zurück, die ja schon im Puffer stehen sollten. Sondern setzt explizit ein FFECB5040121 (von FF->EC) auf den Bus ab. Das dauert natürlich viel länger, als das Lesen der schon empfangenen MS-Message.
Wie kann ich dem entgehen ?
LG
pah
@pah:
Die Config definiert in der angegebenen Weise zwei Mal die gleiche Nachricht mit dem einzigen Unterschied, dass MS-StatusSOL3 von ebusd niemals aktiv abgefragt werden darf (wegen des "u"). Insofern ist das so sicher nicht gewünscht. Ich würde die zweite Definition ("u") einfach rauswerfen und alles ist gut, denn alle reads und writes werden seit kurzem auch automatisch von ebusd mitgelesen, falls ein anderer Teilnehmer die Nachrichten absetzt.
OK, das ist eine wichtige Mitteilung. Ich habe es gerade eben noch einmal überprüft, das read SOL holt sich dann einfach die Daten, die zyklisch über den Bus gegangen sind.
Danke.
LG
pah
@pah & amunra:
Zitat von: amunra am 31 Dezember 2014, 01:45:00
25 und damit vermutlich ca. 1/3 der Regsiter der VRC430 konnte ich heute Abend abfragen und entschlüsseln können.
VG Arthur
Ist das die Calormatic 430?
Könnte man nochmals probieren, die Betriebsart per Write zu verändern.
Dies fehlt mir noch, dann wäre ich soweit schon zufrieden (einige IST-Werte und Betriebsart verändern sind meine Ziele).
Viele Grüße,
Heiko
Zitat von: heikoh81 am 02 Januar 2015, 11:00:05
@pah & amunra:
Ist das die Calormatic 430?
Könnte man nochmals probieren, die Betriebsart per Write zu verändern.
Dies fehlt mir noch, dann wäre ich soweit schon zufrieden (einige IST-Werte und Betriebsart verändern sind meine Ziele).
Viele Grüße,
Heiko
Hallo Heiko, Hallo pah,
ja, das ist Colormatic 430.
Ich bin immer noch im read-Modus, seit gestern habe ich nun insgesamt ca. 60 Register die ich auslesen kann (diese sind auch verifiziert).
Aktuell habe ich noch eine andere dringende Baustelle die höher priorisiert ist als ebus.
Ich kann dir ein Register nenen mit dem du den Betriebsmodus auslesen kannst und zwar:
15 B509 03 0D2F00Länge der zurück gelieferten Daten ist: 1 -> und zwar des Typs uchar
Mögliche Werte sind: 010299=AUTO, 01019a=MANU,01009b=AUS
Ich habe mir dafür einen eigenen Typ im Template gebaut (Name: hwmode2) der wie folgt aussieht:
hwmode2,UCH,0=off;1=manual;2=autoPrüfe bitte, ob du damit etwas sinnvolles lesen kannst.
Wie ein WRITE (auf Basis der vorliegenden Informationen) ausehen kann, dabei kann dir vielleicht (freundlicherweise) pah behilfrich sein, sonsten kannst du es ja mal ausprobieren (zur Info: mit 0E solltest du schreiben können).
Sorry - mehr geht im Moment nicht.
VG Arthur
Ich habe übrigens eine Calormatic 470, nicht 430 - da hatte ich mich vertan.
Also das scheint zu funktionieren - Probeweise manuell abgesetzt (Betriebsart an Calormatic war zu diesem Zeitpunkt AUTO - stimmt also):
root@raspiebus:~# ebusctl write -h 15B509030D2F00
010299Bei Betriebsart "NACHT" sowie identisch bei "SYSTEM AUS (Frostschutz Aktiv):
root@raspiebus:~# ebusctl write -h 15B509030D2F00
01049f
Wie wäre der schreibende Befehl für "NACHT" in diesem Fall?
Es reicht ja sicher nicht, wenn ich 0D durch 0E ersetze?
Zitat von: amunra am 02 Januar 2015, 16:58:18
Ich habe mir dafür einen eigenen Typ im Template gebaut (Name: hwmode2) der wie folgt aussieht:
hwmode2,UCH,0=off;1=manual;2=auto
D.h. ich füge den von dir genannten Code in die template.csv ein?
Und wie lautet dann die Zeile z.B. in der Vaillant_Protokoll_kurz.csv?
Viele Grüße,
Heiko
OK, auch mal wieder ein Fortschritt:
- Umschalten in den Partymodus (= Überspringen des Absenkens bis zur nächsten Heizperiode) wird bei der vrs620 mit dem Register 4e00 gesteuert.
- Werte: 0=no;1=HWC [Partyfunktion nur Warmwasserkreis];247=yes => neues Template party.
LG
pah
Zitat von: heikoh81 am 02 Januar 2015, 17:17:13
Ich habe übrigens eine Calormatic 470, nicht 430 - da hatte ich mich vertan.
Also das scheint zu funktionieren - Probeweise manuell abgesetzt (Betriebsart an Calormatic war zu diesem Zeitpunkt AUTO - stimmt also):
root@raspiebus:~# ebusctl write -h 15B509030D2F00
010299
Bei Betriebsart "NACHT" sowie identisch bei "SYSTEM AUS (Frostschutz Aktiv):
root@raspiebus:~# ebusctl write -h 15B509030D2F00
01049f
Wie wäre der schreibende Befehl für "NACHT" in diesem Fall?
Es reicht ja sicher nicht, wenn ich 0D durch 0E ersetze?
D.h. ich füge den von dir genannten Code in die template.csv ein?
Und wie lautet dann die Zeile z.B. in der Vaillant_Protokoll_kurz.csv?
Viele Grüße,
Heiko
Schreiben kannst du z.B. mit:
ebusctl write -h 15B509040E2F0002
Hallo,
so jetzt mal alle Antworten:
Zitat von: heikoh81 am 02 Januar 2015, 17:17:13
Wie wäre der schreibende Befehl für "NACHT" in diesem Fall?
ebusctl write -h 15B509040E2F00 00Zitat von: heikoh81 am 02 Januar 2015, 17:17:13
Es reicht ja sicher nicht, wenn ich 0D durch 0E ersetze?
Die Datenlänge ist 4 (BasisRegister+Status) und nicht mehr 3.
Zitat von: heikoh81 am 02 Januar 2015, 17:17:13
D.h. ich füge den von dir genannten Code in die template.csv ein?
Du kannst auch den vorhandenen Typ: hwmode verwenden, der hat bei mir aber nicht gepasst.
Typ in der CSV sieht dann so aus:
hwmode2,UCH,0=off;1=manual;2=auto,,Zitat von: heikoh81 am 02 Januar 2015, 17:17:13
Und wie lautet dann die Zeile z.B. in der Vaillant_Protokoll_kurz.csv?
Also alle Daten sind doch da => 1+1 ;o)
Das sieht dann so aus:
r,,OperatingModeHK,HK1_OPMode,,,,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Zur Info: Ich bin noch nicht auf der aktuellsten EBus Version (ich weiß aktuell nicht, ob sich da nicht evtl. was geändert hat).
VG Arthur
Hi,
darf ich die von Euch erstellten Konfigurationen (BAI00 bzw. 47000), wenn von Euch fertig erstellt und getestet, in https://github.com/yuhu-/ebusd-configuration (https://github.com/yuhu-/ebusd-configuration) veröffentlichen?
lg roland
Hier im Anhang meine gegenwärtige Konfiguration. Hat ein paar neue Register und ist in Bezug auf die Benennungen etwas systematischer geworden.
LG
pah
Kleine offtopic Frage: An meiner 620er Steuerung ist für die Solarthermie leider kein Wärmemengenzähler angeschlossen. Kann man diesen selbst (kostengünstig) nachrüsten?
Gesendet von meinem LG-D855 mit Tapatalk
Zitat von: amunra am 02 Januar 2015, 20:31:20
Schreiben kannst du z.B. mit: ebusctl write -h 15B509040E2F0002
Es passiert was an der Calormatic! Führe ich den Befehl aus, verschwindet das Auto-Symbol (Sonne bzw. Mondsichel) vom Display.
Das Auslesen des Status ergibt dann:
root@raspiebus:~# ebusctl write -h 15B509040E2F00 00
0000
root@raspiebus:~# ebusctl write -h 15B509030D2F00
01009b
Im Auto-Modus:
root@raspiebus:~# ebusctl write -h 15B509030D2F00
010299
Im Nachtmodus:
root@raspiebus:~# ebusctl write -h 15B509030D2F00
01049f
Viele Grüße,
Heiko
ZitatWie wäre also der Hex-Befehl für das Schreiben von 01049f?
ebusctl write -h 15B509040E2F00 0401=Datenlänge
04=Wert
9f=CRCVG Arthur
Hallo zusammen,
ich habe folgende Datentyp-Konstelation (Text, Float) im HolidayTemp Register:
010992=Frostschutz (UCH)
010a91=5°C (Min) (D1C)
... 0.5°C Schritten
013ca7=30°C (Max) (D1C)
Hat jemand dafür schon eine Definition bzw. eine oder ähnliche Konstelation? Danke.
Eine Idee (einzelne Werte eintragen) habe ich, aber schön ist die nicht, daher die Frage in die Runde.
VG Arthur
@NemoN:
http://waermeshop24.com/de/vaillant-volumenstromsensor-auromatic-620-3-waermemengenerf.
Habe ich aber auch schon für ca. 110 € gesehen.
Erforderlich: Auftrennen der Solarleitung(en). Ob man das selbst machen möchte ?
LG
pah
Hallo Arthur,
es hat tatsächlich funktioniert.
Ich konnte heute morgen mit deiner Erklärung die Heizung vom gestern Nacht manuell an der Calormatic eingestellten "Nacht-Modus" in den AUTO-Modus wechseln.
Die Heizung hat daraufhin brav begonnen, zuerst Warmwasser zu machen und dann zu heizen (von den Zeitfenstern genau so gewünscht).
root@raspiebus:~# ebusctl write -h 15B509040E2F0002
0000
root@raspiebus:~# ebusctl write -h 15B509030D2F00
010299
Zitat von: amunra am 02 Januar 2015, 20:48:00
r,,OperatingModeHK,HK1_OPMode,,,,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Wenn ich das r,, richtig deute, ist das ein Befehl zum Auslesen.
Kann man so auch einen Befehl zum schreiben auf den ebus stricken und wie wäre dieser?
Viele Grüße,
Heiko
@heikoh81:
Schau doch bitte auf die CSV (besser noch: ODS) Datei. Da steht alles drin.
In der zugegebenermaßen etwas kryptischen Syntax von ebusd steht am Anfang des Tabellenteil etwas in der Form (wobei ich nicht weiß. welchen Klassennamen Ihr verwendet habt - ich nehme mal 47000)
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Das bedeutet: In der Zeile
r,,OperatingModeHK,HK1_OPMode,,,,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
wird wegen des r in der ersten Spalte automatisch eingesetzt
r,47000,OperatingModeHK,HK1_OPMode,15,B509,0D,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
und das führt beim eingetippten Befehl ebusctl read OperatingModeHK zum abgesetzten Befehl
15B509030D2F00
Man braucht also nur die Zeile um ein kleines ";w" zu ergänzen:
r;w,,OperatingModeHK,HK1_OPMode,,,,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
um mit Hilfe des eingetippten Befehls ebusctl write OperatingModeHK 2 zum abgesetzten Befehl
15B509040e2F0002
zu kommen. Na, und falls oben in der Tabelle die Zeile mit "*w" noch fehlt: Das wirst Du hinbekommen.
LG
pah
Hallo pah,
ich habe mir grade bei mir die programmierbaren Schaltzeiten angesehen (diese liegen bei mir 15 B15 02 0000-0600)
Mir ist aufgefallen, dass in deinen Template für die Schaltzeiten, die Typen: slot1-3;days definiert sind.
Bist du dir da sicher, dass das richtig ist?
Bei mir bekomme ich ein 8 Byte(paar) zurück der wie folgt aufgeschlüsselt wird:
08 000024278a8a9001 f3 ==> 00=> 00 | 00 => 00 | 24 => 36/6=06:00 | 27=> 39/6 = 09:00 | 8a=> 138/6 =23:00 | 138/6 =23:00 | 90=>144/6=24:00
Damit sind die ersten 7 Byte(paare) des Typs: slot1-3 - soweit so gut.
Das letzte Bytepaar definiert die Gruppierung, also: 0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So das ergibt den TemplateTyp: daysel
Ist das bei dir auch so? Vielleicht kannst du das ja überprüfen.
Dies nur zur Info.
VG Arthur
Hallo pah,
ich verstehe es immer noch nicht ganz.
Ich habe folgendes einfach an die Vaillant.csv (Stand 27.12.2014) angehängt:
######HEIKO-BEFEHLE
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,47000,OperatingModeHK,HK1_OPMode,15,B509,0D,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Es kommt folgende Fehlermeldung:
root@raspiebus:~# ebusd --checkconfig
2015-01-03 14:17:02.694 [bas event] ebusd started
2015-01-03 14:17:02.694 [bas trace] path to ebus configuration files: /etc/ebusd
2015-01-03 14:17:02.710 [bas trace] read templates
Error reading "/etc/ebusd/Vaillant_Protokoll_kurz.csv" line 116 field 5 value "15": ERR: invalid address
Erroneous item is here:
"r","47000","OperatingModeHK","HK1_OPMode","15","B509","0D","2F00","","","hwmode2","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
2015-01-03 14:17:02.768 [bas trace] read config files
2015-01-03 14:17:02.769 [bas event] message DB: 114
2015-01-03 14:17:02.770 [bas event] updates DB: 15
2015-01-03 14:17:02.771 [bas event] polling DB: 0
2015-01-03 14:17:02.774 [bas event] ebusd stopped
Zumindest müsste damit doch immer der aktuelle Zustand ausgelesen werden.
Auf gleiche Weise könnte ich jetzt eine vollständige write-Zeile anfügen, wenn es denn funktionieren würde.
Viele Grüße,
Heiko
in der Zeile ist die Adresse falsch
r,47000,OperatingModeHK,HK1_OPMode,15,B509,0D,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
es muss so aussehen:
r,47000,OperatingModeHK,HK1_OPMode,15,B509,0D2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Bei dieser Definition:
######HEIKO-BEFEHLE
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
kann es aus so aussehen:
r,,OperatingModeHK,HK1_OPMode,,,2F00,,,hwmode2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
VG Arthur
P.S: Bearbeite, wie von pah auch schon empfohlen, die Einträge in OpenOffice, dann kannst du auch nichts (kaum etwas) falsch machen.
Danke für die schnelle Ant.
Tatsächlich hat einfach das Template "hwmode2" noch gefehlt.
Nachdem ich das in der _templates.csv angefügt habe:
betriebsartheiko,UCH,0=Aus;2=Auto;4=Nacht,,
funktioniert es so:
######HEIKO-BEFEHLE
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,BetriebsartLesen,AuslesenDerBetriebsart,,,,2F00,,,betriebsartheiko,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Und im Telnet:
root@raspiebus:~# telnet localhost 8888
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
read BetriebsartLesen
Nacht
Nacht stimmt in diesem Fall.
Viele Grüße,
Heiko
Viel fehlen kann jetzt nicht mehr:
######HEIKO-BEFEHLE
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r;w,,Betriebsart,AuslesenUndSchreibenDerBetriebsart,,,,2F00,,,betriebsartheiko,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Liefert noch:
read Betriebsart
Nacht
write Betriebsart 2
usage: 'write class name value[;value]*' or 'write -h ZZPBSBNNDx'
write 47000 Betriebsart 2
ERR: file/element not found or not readable
@amunra: Ist wohl ein Überbleibsel der alten templates. Bin gerade an einer anderen Baustelle, schaue mir das nachher an.
LG
pah
Zitat von: heikoh81 am 03 Januar 2015, 14:55:10
Viel fehlen kann jetzt nicht mehr:
In der Tat, gib doch mal ein:
ebusctl write 47000 Betriebsart Autooder
ebusctl write 47000 Betriebsart Ausoder
ebusctl write 47000 Betriebsart NachtVG Arthur
Danke für die schnelle Antw.
So funktioniert es:
root@raspiebus:~# ebusctl write 47000 Betriebsart Auto
done
root@raspiebus:~# ebusctl read Betriebsart
Auto
Viele Grüße,
Heiko
Ebus hat wohl ein 24:00 Uhr Bug im Zeitformat (das herauszufinden hat mich übrigens 1 Stunde gekostet ;o) ):
Hier ist die Endzeit auf 24 Uhr eingestellt:
08000024278a8a9001f3 ergibt: 0;00:00;06:00;06:30;23:00;23:00;[-:-];Mo-Fr
Hier ist die Endzeit auf 23:50 Uhr eingestellt:
08 000024278a8a8f01 2f ergibt: 0;00:00;06:00;06:30;23:00;23:00;[23:50];Mo-Fr
Meine "TimerProgMonday" TypDefinition lautet: status;slot;slot;slot;daysel (slot=>from;to)
VG Arthur
@amunra:
Welche Zeitfenster kann ich damit einstellen?
Meine kennt Heizbetrieb, Warmwasser, Warmwasser Zirkulationspumpe (allerdings keine vorhanden).
@alle:
Weiß jemand, wie die Betriebsart "1x Speicherladung" aktiviert werden kann?
Auf der Calormatic erscheint diese wie ein "Popup", d.h. die sonstige Anzeige ist ausgeblendet, und es gibt nur die Option "Abbrechen".
Ich vermute, die Calormatic priorisiert überchreibt hier kurzfristig die Zeitfenster für Warmwasser und setzt den WW-Sollwert auf dem ebus hoch.
Viele Grüße,
Heiko
Zitat von: heikoh81 am 03 Januar 2015, 19:52:58
@amunra:
Welche Zeitfenster kann ich damit einstellen?
Meine kennt Heizbetrieb, Warmwasser, Warmwasser Zirkulationspumpe (allerdings keine vorhanden).
Genau diese.
VG Arthur
Roland Jax hat jetzt noch ein paar Daten geschickt, diese sind aber noch nicht verifiziert. Hinzu kommt, dass für die vrs620 nicht nur unter der Adresse 15 Register existieren, sondern dass auch unter den Adressen 23 (Zirkulation) 25 (Hot Water Circuit HWC), 26 (Heating Circuit HC), 50 (Mixer Circuit) und EC (Solarkreis) eigene Register existieren (siehe meine Decodierung des Partymodus gestern...).
Bleibt also spannend...
LG
pah
Hallo zusammen,
auch von mir noch ein frohes Neues!
Da ich anderweitig ausgelastet war, konnte ich mich leider nicht aktiv mit dem ebus beschäftigen. Ich habe den thread aber mit Interesse weiterverfolgt und hoffe, in den kommenden Tagen wieder ein wenig mehr Zeit zu haben.
schöne Grüße
Jo
Ich hoffe mal, dass dies jemand von Vaillant mitliest:
Es ist einfach gruselig, was die Herrschaften bei Vaillant sich als tumben deutsch-englischen Mischmasch für ihre Kommandobezeichnungen ausdenken.
Beispiele:
EnableSonderdisplays
RaumTempOffsetEigenErwaerm
Incrementalgeber1Typ
LG
pah
so meine Ebus Ausbeute nach 3 Stunden im Keller vor der Therme:
67 Register (Menü d.0 - d.97 | d. 26/d. 58/d. 63/d. 76/d.97 fehlen mir noch) inkl. Status Anzeige inkl. An/Aus Schalter an der Therme - ja - den Status kann man auch abfragen, identifiziert und verifiziert. Einige ca. 10 passt der Datentyp noch nicht bzw. es gibt Unstimmigkeiten in den Werten wie z.B. ausgelesene Temperaturwert ist 1 °C niedriger als auf der Anzeige zu sehen -> eher Kleinigkeiten.
Insgesamt habe ich nun ca. 170 Register für meine Therme und CI.
Meine nächsten Schritte sind:
- Die Unstimmigkeiten in den Datentypen beseitigen
- Abgleich der Daten mit den Daten die pah bereitgestellt hat.
- Die ermittelten Werte (auch die der VRC430 immerhin sind es mittlerweile ca. 100 Register) kosmetisch aufbereiten (Namenskonvention...)
- Ein paar Schreibbefehle realisieren (Betriebsmodus, etc.)
- FHEM Integration
Also noch genug zu tun.
VG Arthur
Zitat von: amunra am 04 Januar 2015, 17:57:45
Einige ca. 10 passt der Datentyp noch nicht bzw. es gibt Unstimmigkeiten in den Werten wie z.B. ausgelesene Temperaturwert ist 1 °C niedriger als auf der Anzeige zu sehen -> eher Kleinigkeiten.
So ein Unterschied könnte an einem Offset liegen, welche man grundsätzlich einstellen kann. z.B. habe ich bei meiner Wärmepumpe -3 K für den Aussenfühler eingestellt.
Ahh, ok im konkreten Fall geht es um das Register: 0D7600 (Menü: d.47)
Jetzt sehe ich es - das hatten wir schon mal hier http://forum.fhem.de/index.php/topic,29737.msg236431.html#msg236431 (http://forum.fhem.de/index.php/topic,29737.msg236431.html#msg236431)
Damit ist der gelieferte Wert des Registers bestätigt.
VG Arthur
Namenskonvention ist gut. Ich habe schon angefangen, die kryptischen Vaillant-Begriffe zu systematisieren.
Das Ganze ist auch deshalb wichtig, weil man natürlich mit einem entsprechenden Vokabular auch Module schreiben kann, die ganz unterschiedliche Heizungssysteme visualisieren und steuern.
LG
pah
Ja, sehe ich auch so - man kann sich dabei aber ganz schön verzetteln. Es kommt u.a. darauf an wie weit man über den Tellerrand schaut, je mehr, desto komplexer wird es.
Für mich pers. sehe ich das als Basis/Grundvoraussetzung für die Integration in FHEM.
Das ist auch der Grund weshalb ich bisher kein Aufwand, in das durchaus komplexe Thema, investiert habe.
So richtig Gedanken habe ich mir bisher nicht gemacht, Ideen gibt es...:
- Integration mit FHEM Boardmitteln
- Integration von Außen
- Kombination aus beiden (Monitoring/Alerting intern - Daten zum Auswerten/Visualisieren extern)
- Eigenes FHEM Modul
- ...
Mit allen Vor- und Nachteilen.
Schön wäre es, wenn man das hier zusammen ausarbeiten könnte.
Ich bin gespannt wie sich das Thema entwickelt ...
VG Arthur
Na, wir werden sehen - Datensemantik betreibe ich professionell. EBUS hat aber dabei eine geringere Priorität, als andere Dinge.
LG
pah
@Arthur:
Zitat von: amunra am 04 Januar 2015, 17:57:45
67 Register (Menü d.0 - d.97 | d. 26/d. 58/d. 63/d. 76/d.97 fehlen mir noch) inkl. Status Anzeige inkl. An/Aus Schalter an der Therme - ja - den Status kann man auch abfragen, identifiziert und verifiziert. Einige ca. 10 passt der Datentyp noch nicht bzw. es gibt Unstimmigkeiten in den Werten wie z.B. ausgelesene Temperaturwert ist 1 °C niedriger als auf der Anzeige zu sehen -> eher Kleinigkeiten.
Insgesamt habe ich nun ca. 170 Register für meine Therme und CI.
Das ist ja großartig. Hast du diese in einem OpenOffice-Dokument & könntest du mir das mal schicken?
Zwischenzeitlich habe ich die Logik von ebusd ein ganz klein wenig verstanden und kann nun immerhin die Betriebsart von FHEM aus wechseln - das ist ein riesen Fortschritt, falls man mal vergessen hat, die Heizung auszumachen :-)
Insbesondere habe ich Interesse, folgende IST Werte noch in FHEM abzubilden:
- d005: Heizungsvorlauf Soll
- d009: ebus-Regler Soll
- d015: Pumpendrehzahl IST%
- d022: Warmwasser-Anforderung
- d023: Status Heizbetrieb
- d029: Wasser-Umlaufmenge Ist l/min
- d034: Ist-Gebläsedrehzahl
- d080: Betriebsstunden Heizung
- d081: Betriebsstunden Warmwasser
Sehr interessant wäre noch die Brenner-Ist-Leistung in % - auf der Therme wird diese angezeigt, aber nicht auf dem Calormatic.
Vielleicht liegt diese Information tatsächlich nur in der Thermen-Steuerung vor?
Viele Grüße,
Heiko
Hallo Heiko,
ich versuche mich nun auch an den diversen Registern - vorerst nur zum Lesen. Bisher laufen Anlagendruck, Vorlauftemperatur, SpeicherIstTemperatur, Raumtemperatur, Außentemperatur, Ferienmodus-Abfrage und Modus. Ist es Dir schon gelungen, die Wunschtemperatur zu lesen/schreiben, die man an der Calormatic einstellen kann (im Modus Raumaufschaltung)? Oder ist das das ebus-Regler Soll, welches Du erwähnt hast?
Mit der Implementierung in FHEM wollte ich erst loslegen, wenn ich die für mich interessanten Befehle zusammen habe.
schöne Grüße
Jo
Nein, ich kann momentan nur die Betriebsart schreiben. Zieltemperatur setzen wäre natürlich auch interessant.
Mit welchen ebusctl-Befehlen liest du den Ferienmodus und die Raum-Temperatur? Mit der Datei von pah weiter vorne bekomme ich für die Raumtemp. einen Wert, ich glaube der ist immer 1K verschoben (obwohl ich keinen Offset gesetzt habe).
Hallo,
Raumtemperatur rufe ich mit
*r,F4700,,,,15,B509,0D
r,,RoomTemp,Raumtemperatur,,,,0000,,,tempsensor
ab. Momentan zeigt das "21.56;ok" an. An der Calormatic wird 21.5°C angezeigt. Von dem Rundungsfehler mal abgesehen denke ich, dass der Wert stimmt.
Ferienmodus klappt mit:
r,,isInHoliday,Ferienmodus,,,,0E00,,,yesno
Hast Du eine Liste der bei Dir schon funktionierenden Befehle, die Du teilen würdest? Wir könnten uns das scannen auch gerne aufteilen.
d005...d081: Wie lautet der komplette Befehl dazu? Ich bekomme mit dem header oben (*r,F4700,,,,15,B509,0D) nur ERR: read timeout
Im Übrigen wälze ich mich bisher nur durch die Tabelle von pah.
schöne Grüße
Jo
Teile gerne nur weiß ich noch nicht, wie ich systematisch scannen kann.
Mit Hilfe aller hier im Thread (TAUSEND DANK NOCHMAL) konnte ich mir folgende Befehle erarbeiten:
IN AUTO-SCHALTEN
Befehl: 0E (schreiben)
ebusctl write -h 15B509040E2F0002
0000
Kontrolle 0D (lesen)
ebusctl write -h 15B509030D2F00
010299
IN TAG-MODUS SCHALTEN
Befehl:
ebusctl write -h 15B509040E2F0003
Kontrolle
ebusctl write -h 15B509030D2F00
010398
IN NACHT-MODUS SCHALTEN
Befehl:
ebusctl write -h 15B509040E2F0004
Kontrolle
ebusctl write -h 15B509030D2F00
01049f
IN SOMMER-MODUS SCHALTEN
Befehl:
ebusctl write -h 15B509040E2F0005
Kontrolle
ebusctl write -h 15B509030D2F00
01059e
Und in ebusd übersetzt:
in _templates.csv folgende Zeile anfügen (habe ich so genannt, damit ich weiß, dass diese von mir ist)
betriebsartheiko,UCH,0=Aus;2=Auto;3=Tag;4=Nacht;5=Sommer,,
In Vaillant_Protokoll_kurz.csv von pah unten angefügt:
######HEIKO-BEFEHLE
*r,47000,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,47000,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r;w,,Betriebsart,AuslesenUndSchreibenDerBetriebsart,,,,2F00,,,betriebsartheiko,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Dies alles ist für eine Calormatic 470/3 und eine ecotec Plus 5
Und in FHEM habe ich es wie im fhemwiki beschrieben mit ECMD eingebunden - ich verwende hierfür eine eigene "Klasse" und folgende benutzereigene Datei "ebus_betriebsart_schreiben.cfg":
# BetriebsartSchreiben
get BetriebsartSchreiben cmd {"write 47000 Betriebsart ".Value("VaillantBetriebsartEinstellen")."\n"}
get BetriebsartSchreiben expect ".*\n"
get BetriebsartSchreiben postproc {
}
Werte kommen in der Textform (siehe _templates.csv) aus einem Dropdown-Menü.
Hilft dir das weiter?
Viele Grüße,
Heiko
Wie "Dropdown-Menü" ?
Mit ECMDDevice ?
Genau das suche ich und bin noch nicht drüber gestolpert.
LG
pah
Auf jeden Fall, vielen Dank! Funktionieren denn bei Dir alle Befehle aus der Tabelle von pah? Welche Werte kannst Du auslesen? Habe selber eine ecotec plus und eine calormatic 470f. Müsste eigentlich identisch sein.
schöne Grüße
Jo
@heikoh81: Noch mal, echt dringend: Dropdown-Menü für Argumente in ECMDDevice ?
LG
pah
@Jojo:
Ich habe nur einen kleinen Teil der Tabelle von pah verarbeitet (siehe auch mein Screenshot):
- Außentemp aus Broadcast
- Datum/Uhrzeit aus Broadcast
- Vorlauf/Rücklauf/Brennerstatus aus Broadcast
- Systemdruck aus Broadcast
- Betriebsart - aktiv angefordert
- Vorlauf/Rücklauf/Warmwasser-Speicher/Brennerstatus - aktiv angefordert
@pah:
Ich habe folgende Elemente in fhem angelegt, damit das Dropdown funktioniert (siehe auch angehängter Screenshot):
(1) Dropdown-Feld:
define VaillantBetriebsartEinstellen dummy
attr VaillantBetriebsartEinstellen group Betriebsart_Einstellen
attr VaillantBetriebsartEinstellen room Vaillant
attr VaillantBetriebsartEinstellen setList state:Auto,Nacht,Tag,Sommer,Aus
attr VaillantBetriebsartEinstellen webCmd state
(2) Notify auf das Dropdown-Feld
define VaillantBetriebsartSchreiben_Click notify VaillantBetriebsartEinstellen {\
fhem("get VaillantBetriebsartSchreiben BetriebsartSchreiben");;\
}
attr VaillantBetriebsartSchreiben_Click group heatingControl
attr VaillantBetriebsartSchreiben_Click room Vaillant
(3) ECMD - insbesondere hier relevant der letzte Teil "VaillantBetriebsartSchreiben.class=/opt/fhem/FHEM/ebus_betriebsart_schreiben.cfg"
define EBUS ECMD telnet 192.168.178.239:8888
attr EBUS classdefs VaillantAussentemperatur.class=/opt/fhem/FHEM/ebus_aussentemperatur.cfg:VaillantVorlaufBroadcast.class=/opt/fhem/FHEM/ebus_vorlauf.cfg:VaillantSystemdruck.class=/opt/fhem/FHEM/ebus_systemdruck.cfg:VaillantWarmwasser.class=/opt/fhem/FHEM/ebus_warmwasser.cfg:VaillantBetriebsartLesen.class=/opt/fhem/FHEM/ebus_betriebsart_lesen.cfg:VaillantBetriebsartSchreiben.class=/opt/fhem/FHEM/ebus_betriebsart_schreiben.cfg
attr EBUS room Vaillant
(4) ECMD-Device
define VaillantBetriebsartSchreiben ECMDDevice VaillantBetriebsartSchreiben.class
attr VaillantBetriebsartSchreiben IODev EBUS
attr VaillantBetriebsartSchreiben group Heizung
attr VaillantBetriebsartSchreiben room Vaillant
(5) Die Klassen-Datei, die das Argument aus dem Dropdown als Variable bekommt und dann über ECMD den Befehl absetzt (im selben Ordner wie 99_my_Utils.pm):
Dateiname: ebus_betriebsart_schreiben.cfg
# BetriebsartSchreiben
get BetriebsartSchreiben cmd {"write 47000 Betriebsart ".Value("VaillantBetriebsartEinstellen")."\n"}
get BetriebsartSchreiben expect ".*\n"
get BetriebsartSchreiben postproc {
}
Ist es das, was du brauchst?
Viele Grüße,
Heiko
Ah, es hätte die vierte Codezeile genügt. Ich bin ehrlich gesagt nicht auf die Idee gekommen, das mit dem SetList Attribut zu machen. Und einen Extra-dummy will ich auch nicht einführen. Mal sehen, vielleicht baue ich einen Patch zum ECMDDevice, das wäre an der Stelle sogar sehr einfach.
LG
pah
Danke Heiko, das werde ich mal versuchen bei mir zu implementieren.
schöne Grüße
Jo
Freut mich, dass ich helfen konnte.
@amunra:
Möchte nochmal nach den Registern fragen, die du bereits gefunden hast, siehe mein Post http://forum.fhem.de/index.php/topic,29737.msg240816.html#msg240816 (http://forum.fhem.de/index.php/topic,29737.msg240816.html#msg240816)?
Zitat von: heikoh81 am 06 Januar 2015, 13:49:11
@amunra:
Möchte nochmal nach den Registern fragen, die du bereits gefunden hast, siehe mein Post http://forum.fhem.de/index.php/topic,29737.msg240816.html#msg240816 (http://forum.fhem.de/index.php/topic,29737.msg240816.html#msg240816)?
Geduld... in der aktuellen Form möchte ich keinem diese Tabelle zumuten -> ich bin dran - dauert aber noch etwas.
In der Zwischenzeit kannst du mit den angehängten Informationen versuchen ein paar Werte abzufragen (siehe Anhang).
VG Arthur
@Roland
Ist eine Funktion in ebusd angedacht, mit der ich alle commands (aus der csv) anzeigen lassen kann, etwas in der Form: ebusctl listallcmd/getallcmd
Als Ergebnis sollte dann eine auswertbare Liste (tab,csv) zurückgegeben werden.
Interessante Felder[DRAFT] wären:
type,class,name,comment,type/templates,divider/values,[opt]Filename
r1,ehp,brinetemp,TempXYZ,UCH,0=ok;85=circuit;170=cutoff,ehp.csv
Noch besser/schöner wäre - die gewünschten Felder anzugeben: ebusctl listallcmd [type,class,name,Filename,etc]
VG Arthur
Sorry for English instead of German.
I'm looking for Fault (Error) Codes for Vaillant. Is it possible to find out what is telegram contains it?
Noch eine Frage zur Schaltung: http://www.fhemwiki.de/wiki/Datei:EBUS-IF-USB.png
Vdd und GND vom 4011 (Vdd - Pin14 / GND - Pin7) sind nicht eingezeichnet.
Verbinde ich die einfach mit dem Vdd und GND die vom USB Modul kommen?
Ja. 5V.
LG
pah
@sskriblo:
I found error codes in registers 4a, 85,86,87. Try ebusd commands
ebusctl write -h 15b509030d4a00
etc.
Regards
pah
@Prof. Dr. Peter Henning, Thanks a Lot!
@sskriblo: Works ?
Regards
pah
Hallo zusammen,
nach gefühlten 1000 OpenOffice Abstürze (durch diese sind insgesamt mind. 1-2 Stunden Arbeit verloren gegangen) hänge ich einen Zwischenstand meiner Ergebnisse an.
Ja, leider nur ein Zwischenstand. Hintergrund ist, dass ich in der nächsten Zeit nicht mehr intensiv an dem Thema arbeiten kann, dennoch ist es eine gute Basis für weitere Schritte (Ein Anstoss für weitere Entwicklungen).
Zwischenstand weil:
- die Namensgebung noch nicht zu 100% steht. Ich habe versucht mich an die "ebusd" Konvention zu halten (so gut es irgendwie möglich war).
- einige(wenige) Register noch nicht zu 100% entschlüsselt/interpretiert sind.
- optimierungspotenzial bei der Typdefinition besteht.
- die Ergebnisse von pah (siehe Vaillant_Protokoll_kurz.ods von pah hier im Thread) noch nicht eingeflossen sind.
- writes noch fehlen
- sinnvolle polling/update Definitionen fehlen
Ein paar Worte zum Dokument:
Auf Basis der Dokuments von pah habe ich vier weitere Tabellen hinzugefügt:
1) BAI00_Main (Arbeitsdokument)
2) bai00 (Template)
3) VRC430_Main (Arbeitsdokument)
4) vrc430 (Template)
Tabelle 1) und 3) sind Arbeitstabellen, in denen ich meine Testergebnisse/Notizen/Raw Messages/Datentypen für ebusd etc. festgehalten und definiert habe. Also nicht wundern wenn es etwas wild aussieht.
Aus den beiden o.g. Tabellen resultiert Tabelle 2) und 4) (siehe Formeln) aus denen die entsprechenden CSV-Templates generiert werden können. Dafür kann der Export Button (Der Speicherort ist c:\temp) genutzt werden – alternativ kann die CSV via Standard Vorgehen - Menüpunkt-> Datei..... erstellt werden. Meine Empfehlung ,,nur in den Main Tabellen Veränderungen vornehmen".
Zu beachten ist, dass ich ein paar neue Datentypen in der _template.csv angelegt habe (siehe rot markierte Einträge in der Tabelle ,,templates"). Nur mit den Datentypen werden alle Befehle richtig interpretiert.
Beide Templates werden bei mir, von ebusd, fehlerfrei verarbeitet. (Getestet mit ebusd Stand Anfang Januar 2015).
Abschließend - der Einsatz der Dateien/Templates auf eigene Gefahr. Keine Gewähr, dass alle Befehle funktionieren und das tun was sie sollen.
Bitte um Nachsicht falls sich ein paar Fehler eingeschlichen haben.
VG Arthur
Sehr schöne Arbeit. Meine Therme identifiziert sich ja auch als BAI00, also werde ich davon sicher profitieren, danke.
Ich werde also den BAI00-Teil weitgehend übernehmen - bis auf die Kommandosyntax. Da arbeite ich nebenbei an einem semantisch motivierten Ansatz.
Den VRC430-Teil werde ich mal ansehen, um ggf. noch den einen oder anderen nützlichen Hinweis auf ein Register zu entnehmen.
LG
pah
Ach ja: Habe vorgestern mit einem Vaillant-Servicetechniker gesprochen - der war ganz hin und weg von der Sache.
Vielen Dank auch von mir! Sobald ich ein wenig mehr Zeit finde, werde ich mir die Befehle mal genauer anschauen und mit meiner Therme testen.
schöne Grüße
Jo
Kurze Rückmeldung: Sehr viele Deiner Befehle funktionieren mit meiner Therme :)
Zu DeviceTypeDSN kann ich sagen, dass ein Rückgabewert von 25 einer VC 206/5-5 entspricht.
Zitat von: Jojo11 am 11 Januar 2015, 10:16:04
Kurze Rückmeldung: Sehr viele Deiner Befehle funktionieren mit meiner Therme :)
Zu DeviceTypeDSN kann ich sagen, dass ein Rückgabewert von 25 einer VC 206/5-5 entspricht.
Sehr schön, hoffentlich haben noch mehr was davon.....
VG Arthur
Hallo Zusammen,
erst letzten Freitag ist mir dieser Thread aufgefallen.
Ihr habt hier super Arbeit geleistet. Vielen Dank an alle !
Seit Freitag probiere ich nun auch einige Punkte herauszufinden. Insbesondere haben mich die Fragen von Heiko und eure Antworten weitergebracht.
Da ich mich schon sehr lange mit dem Thema beschäftige, habe ich die SW von Vaillant (vrDIALOG 810/2) inkl. Vaillant-HW (eBUS-Adapter) im Einsatz. Auch der im WIKI beschriebene EBUS-Adapter lag bei mir rum.
Mit eurer Hilfe und 2 Rechner (einer mit vrDIALOG 810/2 und einer mit der Verbindung zur Raspberry) komme ich somit richtig gut an die Daten ran.
Ich habe eine Vaillant VSC S 196/2-C 200 HL und einen VRC 430 im Einsatz.
@Arthur (amunra): Vielen Dank für die Datei "Vaillant_Protokoll_amunra_1.0.ods". Läuft bei mir generell gut, habe aber ein paar Anpassungen vorgenommen, und würde gerne weitere Werte ergänzen, wenn das für dich in Ordnung ist.
Änderungen an Datei 'Vaillant_Protokoll_amunra_1.0.ods':
-> aus der Tabelle BAI00_Main die "," aus dem Beschreibungsfeld genommen
-> aus der Tabelle _templates uni10 in uin10 geändert und Datentyp von UNI auf UIN
-> BAI00_Main SolarPump_DK hinzugefügt auf Zeile47
-> BAI00_Main Wartungsdaten hinzugefügt (Zeile 75)
-> BAI00_Main TempGradientFailure_DK (Gradientenfehler = Anzahl der Boilerabschaltung wegen zu hohen Gradient) hinzugefügt
Ich habe die Datei mal 'Vaillant_Protokoll_amunra_1.0.1.ods' genannt
Gruß
Thomas
Hallo,
ist jetzt eher ein Linux-Problem, aber ich schaffe es einfach nicht, den ebusd mit Port 8888 automatisch starten zu lassen, sobald der Raspberry hochgefahren ist. Habe das ebusd.debian-Skript in /etc/init.d/ geschoben, in ebusd umbenannt und mit den entsprechenden Rechten versehen, aber das war wohl nicht die Lösung. Zur Zeit lasse ich ihn noch manuell im Vordergrund laufen mit /usr/local/bin/ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
Ein /etc/init.d/ebusd start geht ohne Fehlermeldung durch, aber auf Port 8888 ist er hinterher nicht erreichbar. Wo genau stelle ich den Port denn ein? Irgendwie bin ich verwirrt :-\
schöne Grüße
Jo
Hallo Thomas,
Zitat@Arthur (amunra): Vielen Dank für die Datei "Vaillant_Protokoll_amunra_1.0.ods". Läuft bei mir generell gut, habe aber ein paar Anpassungen vorgenommen, und würde gerne weitere Werte ergänzen, wenn das für dich in Ordnung ist.
gerne und danke -> weiter so.
VG Arthur
Die Daemon Parameter werden aus /etc/default/ebusd genommen.
Dazu gibt es im Verzeichnis "contrib/etc/default/ebusd.debian" eine Vorlage.
Ok, da habe ich nicht gesucht ;)
Jetzt habe ich als Optionen EBUSD_OPTS="-l All -d /dev/ttyUSB0 -p 8888" angegeben.
/etc/init.d/ebusd start
und in einem zweiten Fenster /usr/local/bin/ebusctl read mcOperatinghrs
Leider kommt wieder nur error connecting to localhost:8888
schöne Grüße
Jo
Nachtrag: Kleiner Zwischenerfolg. Nachdem ich im Startskript mal folgende Änderung vorgenommen habe, scheint dieses schon mal zu laufen.
#DAEMON=/usr/bin/ebusd
DAEMON=/usr/local/bin/ebusd
Oder auch nicht:
pi@rasp ~ $ /etc/init.d/ebusd start
[ ok ] Starting ebusd: ebusd.
pi@rasp ~ $ /etc/init.d/ebusd status
[FAIL] ebusd is not running ... failed!
Hallo,
ich bin wirklich kein Experte, aber das verstehe ich nicht:
Mit
EBUSD_OPTS="-f -l All -d /dev/ttyUSB0 -p 8888"
funktioniert das Starten per init.d-Skript und der Zugriff über Port 8888.
Mit
EBUSD_OPTS="-l All -d /dev/ttyUSB0 -p 8888"
geht es nicht.
Einziger Unterschied: Der Prozess läuft nicht mehr im Vordergrund. Soll das so sein?
schöne Grüße
Jo
Hallo in die Runde,
Ich will auch mal kurz eine Rückmeldung hier los werden.
Also, ich habe mir diesen Adapter:
http://www.mikrocontroller.net/topic/346833#new (http://www.mikrocontroller.net/topic/346833#new)
gebaut. Freundlicherweise hat Benedikt mir die Leiterplatte zur Verfügung gestellt.
Die Versionen vom ebusd vor der aktuellen Version hatte ich alle nicht vernünftig zum Laufen gebracht.
Der Adapter hängt bei mir an einer Vailland ecoTEC plus 196/3-5 mit calorMATIC 430.
ebusd läuft auf einem Raspberry B+, den ich in einem Hutschinengehäuse im Schaltschrank untergebracht habe.
fhem läuft auf einem BananaPi. Der ist in einem 10" Rack untergebracht.
Mein Ziel ist nicht die exerne Steuerung der Therme, sonden nur die Auswertung von folgenden Werten:
- VL und RL Temperatur Heizkreis
- Speicherladetemperatur
- Speichertemperatur
- Anlagendruck der Heizung
- Betriebszeit Brenner
- Betriebszeit Umwälzpumpe
Vor einer direkten Steuerung der Therme schrecke ich noch zurück.
Da der/die Entwickler vom ebusd hier ja mitlesen, hab ich mal eine Frage:
Ist es möglich den ebusd von telnet auf ssh umzustellen?
kawa
Ich habe die Kommandonamen systematisiert und an den Rest angepasst, sowie ein paar Bezeichnungen und Datentypen der bai00.csv korrigiert.
Und natürlich aus der Datei vrs620.csv diese Kommandos der Therme herausgelöst.
Ergebnis steht im contrib, als OpenOffice ebenso wie also CSV. Also hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/
LG
pah
@kawa0815: Eine "Umstellung" auf ssh ist, pardon das direkte Wort, absoluter Käse. ::)
Das würde dazu führen, dass wir mit FHEM ECMD nicht mehr darauf zugreifen können.
Wer das haben möchte, soll sich bitte per ssh auf seinem Raspberry einloggen, der den ebusd fährt - und kann dann per ebusctl die Daten abfragen.
pah
Echt super wie es hier weiter gegangen ist. (Zwischenzeitlich ruft die Arbeit wieder, deshalb geht es bei mir nun langsamer voran als über die Weihnachtstage.)
Mit den Tabellen von Arthur & pah ist es mir nun weiter gelungen, nun auch die Pumpenleistung %, Gebläsedrehzahl & und VorlaufSoll auszulesen. Sehr sehr gut.
Ich werde die neuesten Tabellen nun Schritt für Schritt untersuchen, ob es auch bei mir funktioniert.
Kurz wollte ich für alle meine neuesten Erkenntnisse hier teilen, direkt ergänzt in die .csv von pah weiter vorne im Thread:
################################# Register Messages Boiler,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,THER,,,,08,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#####HEIKO ANFANG 11.01.2015
r,,PumpeProzent,LeistungDerHeizpumpeInProzent,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,GeblaesedrehzahlIst,DrezahlDesGeblaesesInRpm,,,,8300,,,UIN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,VorlaufSoll,SollwertDesVorlaufsd05,,,,3900,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#####HEIKO ENDE 11.01.2015
Viele Grüße,
Heiko
wie groß ist die Wahrscheinlichkeit das in absehbarer Zukunft auch eine Wolf Therme gelesenund gesteuert werden kann
ich befürchte mein IT Verständnis ist nicht gut genug bei der Entwicklung zu helfen.
Super interessant
Für Wolf gibt es auch Beispielconfigs: http://www.fhemwiki.de/wiki/EBUS
Hallo,
weitere Ergänzungen:
die Wartungsdaten sind komplett drin:
-TempGradientFailure_DK
-TempDiffBlock_DK
-TempDiffFailure_DK
-PumpOperationHours_DK
-CH_PumpCommunt_DK
-TWV_Communt_DK
-FanOperationHours_DK
-FanCommunt_DK
-MaxTempDiffExtTFT_DK
-min_Ignitiontime_DK
-TDHW_max_DK
-TTANK_max_DK
-TFT_max_DK
-TankLoadPumpOperationHours_DK
-TankloadPumpCommunt_DK
-DHW_Waterflow_max_DK
-CounterStartAttempts3_DK
-CounterStartAttempts4_DK
-TRT_max_DK
Die Templates musste ich erweitern:
-seconds2
@pah: ergibt es Sinn, diese Datei irgendwie in die http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/ zu integrieren?
LG
Thomas
Zitat von: Prof. Dr. Peter Henning am 09 Januar 2015, 08:41:54
@sskriblo: Works ?
@Prof. Dr. Peter Henning, I have log from AtmoTEC plus & CalorMatic 630. This log has not following telegram: 15b509030d4a00.
My log has only one packet type with B509-03-0D:
1026
b509030d04008c00033b0300c800
I'll come back to boiler and re-write log again.
But my question. Why thermostat does not sending Error Code request?
Thanks and Regards,
Sergey
@Thomas03:
1. Bitte in solchen Fällen nicht die gesamte Tabelle anhängen, sondern nur die neuen Ergänzungen.
2. Auch den Dateinamen mit "amunra" sollte man nicht weiter verwenden, wenn man eigene Ergänzungen drin hat.
@sskriblo:
I am not sure if you understand me: You are not supposed to look up some log, but to issue a command to the ebusd which asks the controller to return the error codes. Try
ebusctl write -h 15b509030d4a00
LG
pah
Hallo pah,
ich möchte dich nochmals um deine Hilfe bitten, und zwar konnte ich dank deiner Hinweise ja schon erarbeiten, die Betriebsart meiner Calormatic zu setzen.
Nun möchte ich mich an die Raum-Soll-Temperatur (Aktuell sowie Nachtabsenkung) heranwagen.
Im Gegensatz zur Betriebsart, die man mit einstelligen Zahlen über den ebusctl-Befehl ansteuern konnte, erscheint mir die Temperatur nun etwas komplizierter.
Aus den bisher geposteten Dateien sind das die benötigten Code-Zeilen:
#################################,,,TEST: ebusctl write -h 15B5930D2E00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment
################################# Get Messages,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#,,0,##############VRC430 Base,,,,,,,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTemp,Manuell Solltemperatur,,,,3200,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTempLow,Absenktemperatur,,,,3000,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Frage in die Runde:
Was ist denn die QuickVeto-Temperatur?
Viele Grüße,
Heiko
Hallo,
hat es jemand schon geschafft, die aktuelle Version des ebusd im Hintergrund laufen zu lassen?
Gibt es dazu etwas Besonderes zu beachten? Installation als root? Eigentlich sollten alle Rechte mehr als ausreichend sein, aber das Startskript quittiert mit [ok] ohne dass der ebusd wirklich läuft :-[
schöne Grüße
Jo
Also die Dateien von amunra und die Erweiterungen der Foren-Teilnehmer sind echt gut, es funktioniert fast alles bei mir.
Folgende Beobachtungen:
- read -c vrc430 RoomTemp ==> um 1K zu hoch im Vergleich zur Display-Anzeige
- mcDesiredTempQV ==> liefert bei vorübergehender Erhöhung der Soll-Raumtemp. den korrekten Wert
- mcDesiredTemp ==> liefert 0.0, obwohl 21° an Calormatic vorgegeben
Für eine sinnvolle Steuerung ist mcDesiredTempQV schon einmal ein guter Ansatz.
Wie könnte ich diesen Wert auch schreiben, d.h. eine Temperatur in °C an die Calormatic übergeben?
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTempQV,QuickVeto Solltemperatur,,,,3C00,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Viele Grüße,
Heiko
Hallo Ihr Lieben,
bin vom Nachbarforum auf diesen Thread gestoßen worden. ich setzte auch eine ecoTec (aka bai00) mit Calormatic (430) ein. Der aktuelle ebusd ist übersetzt.
Leider fehlt mir irgendwie die Initialzündung, die ich hier (weiter) vorgehen muss:
Ich habe mir mal Deine csv's geladen und in /etc/ebusd kopiert.
Aber wie mache ich nun weiter? Muss ich auch was in der commands.csv haben?
Starte ich den ebusd bekomme ich folgende Meldungen:
2015-01-13 14:09:38.906 [bas trace] path to ebus configuration files: /etc/ebusd
2015-01-13 14:09:38.910 [bas trace] read templates
2015-01-13 14:09:38.911 [bas error] error reading config files: ERR: file/element not found or not readable
2015-01-13 14:09:38.911 [bas event] message DB: 0
2015-01-13 14:09:38.911 [bas event] updates DB: 0
2015-01-13 14:09:38.913 [bas event] polling DB: 0
2015-01-13 14:09:40.525 [upd trace] update MS cmd: 1008b5100900005678ffff04ff00d3 / 01019a
2015-01-13 14:09:40.525 [upd event] unknown MS cmd: 1008b5100900005678ffff04ff00d3 / 01019a
2015-01-13 14:09:44.537 [upd trace] update MS cmd: 1008b511010189 / 096464100cff680000ff72
2015-01-13 14:09:44.537 [upd event] unknown MS cmd: 1008b511010189 / 096464100cff680000ff72
2015-01-13 14:09:46.533 [upd trace] update BC cmd: 10feb5160301100ce2ein
ebusctl read vrc430 TempOutsidebringt nur die Fehlermeldung "message not defined".
Also irgendwas mache ich hier noch grundlegend falsch....
Kann und will mir vielleicht jemand helfen?!
Danke...Netstac
Zitat von: amunra am 10 Januar 2015, 22:04:29
Tabelle 1) und 3) sind Arbeitstabellen, in denen ich meine Testergebnisse/Notizen/Raw Messages/Datentypen für ebusd etc. festgehalten und definiert habe. Also nicht wundern wenn es etwas wild aussieht.
Aus den beiden o.g. Tabellen resultiert Tabelle 2) und 4) (siehe Formeln) aus denen die entsprechenden CSV-Templates generiert werden können. Dafür kann der Export Button (Der Speicherort ist c:\temp) genutzt werden – alternativ kann die CSV via Standard Vorgehen - Menüpunkt-> Datei..... erstellt werden. Meine Empfehlung ,,nur in den Main Tabellen Veränderungen vornehmen".
Zu beachten ist, dass ich ein paar neue Datentypen in der _template.csv angelegt habe (siehe rot markierte Einträge in der Tabelle ,,templates"). Nur mit den Datentypen werden alle Befehle richtig interpretiert.
Beide Templates werden bei mir, von ebusd, fehlerfrei verarbeitet. (Getestet mit ebusd Stand Anfang Januar 2015).
Abschließend - der Einsatz der Dateien/Templates auf eigene Gefahr. Keine Gewähr, dass alle Befehle funktionieren und das tun was sie sollen.
Okay...es hat mir keine Ruhe gelassen...mein Problem waren einige fehlende Typen (neben den rot martierten) in der _template-Datei. Dadurch hat er die Konfigurationen gar nicht erst geladen...
Frei nach dem Motto: Kaum macht man es richtig, schon funktioniert's kann ich nun einiges an Werten lesen.
Nun habe ich aber noch ein paar andere Fragen: Im Log sehe ich folgenden Output - ich denke mal, dass es sich dabei um cyclische Kommandos handelt, die aber nicht interpretiert werden können. Ist dem so?
2015-01-13 16:01:42.403 [upd trace] update MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:01:42.403 [upd event] unknown MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:01:48.407 [upd trace] update MS cmd: 1008b511010189 / 09745c600aff620400ff69
2015-01-13 16:01:48.407 [upd event] unknown MS cmd: 1008b511010189 / 09745c600aff620400ff69
2015-01-13 16:01:50.449 [upd trace] update MS cmd: 1008b51101028a / 05033c6c508281
2015-01-13 16:01:50.449 [upd event] unknown MS cmd: 1008b51101028a / 05033c6c508281
2015-01-13 16:01:52.462 [upd trace] update MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:01:52.462 [upd event] unknown MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:01:56.479 [upd trace] update MS cmd: 1008b511010189 / 097858600aff620400fff7
2015-01-13 16:01:56.479 [upd event] unknown MS cmd: 1008b511010189 / 097858600aff620400fff7
2015-01-13 16:01:58.449 [upd trace] update MS cmd: 1008b50401003d / 0a00275105ffffffff600a67
2015-01-13 16:01:58.449 [upd event] unknown MS cmd: 1008b50401003d / 0a00275105ffffffff600a67
2015-01-13 16:01:58.669 [upd trace] update BC cmd: 10feb5050204000b
2015-01-13 16:01:58.669 [upd event] unknown BC cmd: 10feb5050204000b
2015-01-13 16:02:02.455 [upd trace] update MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:02:02.455 [upd event] unknown MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:02:06.461 [upd trace] update MS cmd: 1008b511010189 / 09785e600aff620400ffae
2015-01-13 16:02:06.461 [upd event] unknown MS cmd: 1008b511010189 / 09785e600aff620400ffae
2015-01-13 16:02:12.495 [upd trace] update MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:02:12.495 [upd event] unknown MS cmd: 1008b5100900005c78ffff00ff00f5 / 01019a
2015-01-13 16:02:16.509 [upd trace] update MS cmd: 1008b511010189 / 097e68600aff620400ffea
2015-01-13 16:02:16.509 [upd event] unknown MS cmd: 1008b511010189 / 097e68600aff620400ffea
2015-01-13 16:02:18.473 [upd trace] update BC cmd: 10feb5160800350116130102152f
2015-01-13 16:02:18.473 [upd event] unknown BC cmd: 10feb5160800350116130102152f
2015-01-13 16:02:18.733 [upd trace] update MS cmd: 1008b512020000ca / 0000
2015-01-13 16:02:18.733 [upd event] unknown MS cmd: 1008b512020000ca / 0000
Wie kann man diese Kommandos interpretieren?
Wie kann ich nun meine gewünschte Warmwassertemperatur einstellen? An der Therme habe ich dazu ja den Drehknopf mit der Temperaturwahl. Ich gehe also davon aus, dass ich das auch über "bai00" machen muss und nicht über "vrc430", oder?
Kann mir jemand helfen, wie ich das einbaue?!
Danke...Netsrac
Klar - das sind z.B Kommandos des Controllers (10) an die Therme (08) von Vaillant (B5) zur Abfrage der Betriebsparameter (11), Datensatz 01.
Genau dieses Kommando wird übrigens sehr wohl geparst, siehe letzte Zeile in der bai00.csv bzw. Vaillant_Protokoll_kurz.ods hier aus dem Repository: http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/EBUS/
"Fehlende Typen" können es auch nicht sein, möglicherweise stimmt die Version der Datei _templates.csv einfach nicht.
LG
pah
P.S.: Bitte nicht für jedes Register einen eigenen Datentyp erfinden. Sondern stattdessen lieber die generischen Typen verwenden, mit entsprechenden Angaben für Teiler und Wertelisten.
Zitat von: Jojo11 am 12 Januar 2015, 19:57:34
Hallo,
hat es jemand schon geschafft, die aktuelle Version des ebusd im Hintergrund laufen zu lassen?
Gibt es dazu etwas Besonderes zu beachten? Installation als root? Eigentlich sollten alle Rechte mehr als ausreichend sein, aber das Startskript quittiert mit [ok] ohne dass der ebusd wirklich läuft :-[
schöne Grüße
Jo
Mit dem richtigen Hinweis aus diesem thread hat sich das Problem übrigens erledigt ::)
http://knx-user-forum.de/446726-post32.html (http://knx-user-forum.de/446726-post32.html)
schöne Grüße
Jo
Danke für den hinweis auf die aktualisierte bai000.csv das hat schonmal ein wenig geholfen.
Ich habe allerdings immer noch einige unbekannte Befehle, die angezeigt werden. Ist das bei anderen auch so (sprich sind die noch nicht interpretiert) oder habe ich einfach noch die falschen Configs?
Hier ein Auszug aus den unbekannten Befehlen:
2015-01-13 20:21:40.121 [upd event] unknown MS cmd: 0315b5130306640063 / 01019a
2015-01-13 20:21:40.181 [upd event] unknown MS cmd: 0315b5130306640063 / 01019a
2015-01-13 20:21:41.753 [upd event] unknown MS cmd: 1008b512020000ca / 0000
2015-01-13 20:21:51.541 [upd event] unknown MS cmd: 1008b50401003d / 0a00591810ffffffff400bf1
2015-01-13 20:21:51.807 [upd event] unknown MS cmd: 1008b51101028a / 05033c6c508281
2015-01-13 20:22:11.541 [upd event] unknown MS cmd: 1008b51101028a / 05033c6c508281
2015-01-13 20:22:21.573 [upd event] unknown MS cmd: 1008b50401003d / 0a00301910ffffffff400be4
2015-01-13 20:22:21.797 [upd event] unknown BC cmd: 10feb5050204000b
2015-01-13 20:22:40.721 [upd event] unknown MS cmd: 0315b513030600000e / 01019a
2015-01-13 20:22:40.829 [upd event] unknown MS cmd: 0315b513030600000e / 01019a
2015-01-13 20:22:40.893 [upd event] unknown MS cmd: 0315b513030600000e / 01019a
2015-01-13 20:22:41.001 [upd event] unknown MS cmd: 0315b513030600000e / 01019a
2015-01-13 20:22:41.841 [upd event] unknown MS cmd: 1008b512020000ca / 0000
2015-01-13 20:22:51.585 [upd event] unknown MS cmd: 1008b50401003d / 0a00012010ffffffff400be0
2015-01-13 20:22:51.857 [upd event] unknown MS cmd: 1008b51101028a / 05033c6c508281
2015-01-13 20:23:09.581 [upd event] unknown MS cmd: 1008b51101028a / 05033c6c508281
Entsprechend sortiert und duplikate rausgeworfen sind es diese Befehle, die nicht erkannt werden:
0315b513030600000e
0315b5130306640063
1008b50401003d
1008b51101028a
1008b512020000ca
10feb5050204000b
10feb5050229002c
Vielleicht kann mir ja nochmal jemand helfen....
Und dann habe ich mir diese Zeile nochmal angeschaut:
2015-01-13 20:34:16.605 [upd trace] update MS cmd: 1008b511010189 / 094c4a400bff7c0000ffb5
2015-01-13 20:34:16.605 [upd event] update bai00 StatusTHER: 38.0;37.0;180.00;-;62.0;0
Soll ja nach der Beschreibung folgendes sein:
StatusTHER,VL/RL/AussenT/VLWW/RLWW/Status
Also "Vorlauf", "Rücklauf" bekommen immerhin Meßwerte, auch wenn ich über 1-wire gemesen auf "41" und "29" komme...ist also fraglich, ob das wirklich stimmt.
Aber dann geht es los - die 180.00 für die Außentemperatur stimmt hoffentlich nicht - die wird an andere stelle auch korrekt angezeigt:
2015-01-13 20:35:55.497 [upd trace] update BC cmd: 10feb5160301400b1f
2015-01-13 20:35:55.497 [upd event] update BC OutsideTempBC: 11.250
Und dann kommt ein "-" und 62 Grad für Warmwasser stimmt auch nicht. Wobei der obere Teil des Warmwasserspeichers aktull 64 Grad hat, aber das ist ja nicht der Rücklauf.
Sollte Status dann angeben, ob der Brenner an ist oder nicht?! Gehe ich mal von aus...
Zu guter Letzt habe ich dann immer noch zyklisch diese Werte:
2015-01-13 20:38:45.294 [upd trace] update MS cmd: 1008b5100900005978ffff00ff00ca / 01019a
2015-01-13 20:38:45.294 [upd event] update MS SetBoiler: 1;77.0
Die verändern sich allerdings nie - was ist soll das sein?
Danke...Nersrac
Zu Deiner Beruhigung: Bei mir funktionieren auch nicht alle Befehle und manche liefern auch falsche Ergebnisse. Lies Dir mal den kompletten thread durch, dann bekommst Du vielleicht ein Gefühl dafür, wie viel Arbeit in der jetzigen Tabelle stecken dürfte. Dafür ist das Ergebnis wirklich beeindruckend. My 2 cents.
schöne Grüße
Jo
Das es viel Arbeit ist, ist mir schon klar und ich würde auch gerne mithelfen. Allerdings fehlen mir eben ein paar Hintergrundinfos, wie man das Ganze angehen muß.
Gruß, netsrac
Nun, diese Hintergrundinformation kann man sich durch Lesen der Dokumente im oben zitierten Repository beschaffen. Das haben wir auch so gemacht.
Viel Vergnügen.
pah
Hallo nochmal in die Runde,
ich habe nun auf Basis von pahs & amunras Datei einiges hinbekommen, auch das Schreiben von Werten.
Konkret kann ich steuern: Heizkurve, Nacht-Absenktemperatur, Vorübergehende Tages-Heiztemperatur, Calormatic-Thermostat-Aufschaltung (an/aus) sowie Betriebsart.
Was ich nicht geschafft habe, obwohl es doch das einfachste sein muss: Raumtemperatur IST lesen, Tagestemperatur SOLL dauerhaft so wie Nachttemperatur schreiben.
read -c 47000 mcDesiredTemp liefert 0.0, eingestellt an Calormatic ist 21.0.
read -c 47000 mcDesiredTempLow liefert korrekt 17.0
Hat das schon jemand geschafft? Ich habe eine Calormatic 470/3 und nicht wie amunra eine Calormatic 430.
Viele Grüße,
Heiko
Hallo Heiko,
Raumtemperatur IST funktioniert bei mir mit einer 470f. Schreiben habe ich bisher nur mit Modus versucht (auto, Nacht...).
schöne Grüße
Jo
Hallo,
langsam wird es unübersichtlich....
ZitatZitatread -c 47000 mcDesiredTemp liefert 0.0, eingestellt an Calormatic ist 21.0.
Die Klasse 47000 kenne ich nicht? - Welche Adresse/Register/Datentyp stecken dahinter.
Bei mir ist mcDesiredTemp wie folgt definiert:
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTemp,Manuell Solltemperatur,,,,3200,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,und liefert bei mir aktuell 21.0°C - das ist auch der Wert den ich auf dem Display der Colormatic ablesen kann.
ZitatRaumtemperatur IST lesen
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,displayroomtemp,display room temp,,,,8000,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Achtung in meinem Template war der Datentyp nicht korrekt!
Falsch "
temp2"(Data2b) richtig "
temp"(Data2c)
Im Template beinhaltet der command name Leerzeichen - das darf nicht sein (also Leerzeichen entfernen)!
@netsrac27
Zitat
Vielleicht kann mir ja nochmal jemand helfen....
Und dann habe ich mir diese Zeile nochmal angeschaut:
2015-01-13 20:34:16.605 [upd trace] update MS cmd: 1008b511010189 / 094c4a400bff7c0000ffb5
2015-01-13 20:34:16.605 [upd event] update bai00 StatusTHER: 38.0;37.0;180.00;-;62.0;0
Soll ja nach der Beschreibung folgendes sein:
StatusTHER,VL/RL/AussenT/VLWW/RLWW/Status
Also "Vorlauf", "Rücklauf" bekommen immerhin Meßwerte, auch wenn ich über 1-wire gemesen auf "41" und "29" komme...ist also fraglich, ob das wirklich stimmt.
Aber dann geht es los - die 180.00 für die Außentemperatur stimmt hoffentlich nicht - die wird an andere stelle auch korrekt angezeigt:
Die Definition muss wie folgt aussehen:
r,THER,Status,VL/RL/AussenT/VLWW/RLWW/Status,,08,B511,01,,,temp1;temp1;
temp2;temp1;temp1;status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
VG Arthur
Diesen Fehler habe ich nicht bemerkt, weil bei mir der Außentemperatursensor am Hauptcontroller vrs620 angeschlossen ist. Habe ich korrigiert und in die im Repository stehende bai00.csv eingecheckt.
Ich bin gerne bereit, ins Repository auch die Konfigurationsdatei für die vrc430 aufzunehmen (d.h. als gut editierbare Tabelle in die .ods-Datei, und als direkt verwendbare vrc430.csv).
Dazu müssen wir aber ein paar Konventionen einhalten, sonst gibt es Ducheinander.
1. Für Registerkommandos (B509) an den abgesetzten Controller lautet der Klassenname auf den Gerätenamen, also z.B. vrc430 (nicht 47000, das wäre die Vaillant-ID) oder vrs620.
2. Beim Aufruf von Registerkommandos muss immer der Klassenname verwendet werden. Damit entfällt das von Vaillant davorgesetzte "mc"
3. Bei Temperaturangaben etc: Zuerst Die beschreibende Komponente. Also z.B. Vorlauf="Flow". Dann die physikalische Größe, hier "Temp". Dann als Zusatz eventuell "Max", "Min", "Desired".
Damit wäre das Setzen der minimalen Speichertemperatur mit dem Kommando "ebusctl write vrs620 StorageTempMin" zu erreichen, und das Lesen der vom Controller bestimmten Vorlaufsolltemperatur mit "ebusctl read vrc430 FlowTempDesired". Die tatsächliche Vorlauftemperatur käme ohne diesen Zusatz aus, also "ebusctl read vrc430 FlowTemp".
4. Für Registerkommandos (B509) an das Heizgerät ist es sinnvoller, nicht den Gerätenamen als Klassennamen zu verwenden - sondern die Vaillant-Id (also z.B. bai00). Und zwar deshalb, weil ganz unterschiedliche Geräte dasselbe Interface haben. Also z.B. "read bai00 FanSpeed" und "read bai00 FanSpeedDesired".
Bei der vrs620 habe ich eine ganze Menge von B504/B505 Kommandos herausgefunden. B504 liest ganze Sätze von Daten und ist damit sehr viel effizienter, als die Registerkommandos, B505 schreibt Daten - und zwar mit einer Kontrolle der Parameterwerte. Das wird bei einem direkten schreiben auf die Register wohl nicht gemacht, insofern muss man mit dem Schreiben auf die Register sehr vorsichtig sein.
LG
pah
P.S.: Ich werde in den nächsten 3 Wochen nur sehr sporadisch Zeit haben, weil ich eine Großveranstaltung zu leiten habe.
Danke für den Tip mit dem StatusKommando...das macht jetzt schon mehr Sinn.
Noch eine Frage zu diesem Wert:
2015-01-14 09:13:51.607 [upd event] update MS SetBoiler: 1;77.0
Jemand eine Erklärung, das das darstellen soll?
Achja, und noch eine Frage zur Verkabelung:
Neben Therme und CalorMatic (wo ich den eBus abgreife) habe ich auch noch eine AutoMatic 560 - diese hat zwar auch einen eBus, ist aber mit dem eBus der Therme nicht verbunden, sondern nutzt nur einen Kontakt zur Therme um Warmwasser anzufordern.
Kann man die beiden eBus'se problemlos verbinden? Hat da jemand Erfahrung?
Danke...Netsrac
Prinzipiell ja, weil der EBUS multimasterfähig ist. Allerdings übernehme ich dafür keine Gewähr - denn ich habe keinen Schimmer, ob die beiden Controller dann eventuell widersprüchliche Befehle an die Therme absetzen.
LG
pah
Neine, Gewähr soll dafür auch niemand übernehmen - ist doch nur die Frage, ob das schonmal jemand gemacht hat... :-)
Zitat von: Prof. Dr. Peter Henning am 14 Januar 2015, 09:25:13
Prinzipiell ja, weil der EBUS multimasterfähig ist. Allerdings übernehme ich dafür keine Gewähr - denn ich habe keinen Schimmer, ob die beiden Controller dann eventuell widersprüchliche Befehle an die Therme absetzen.
Wer sich ein wenig prinzipieller über den EBUS informieren möchte: http://www.mikrocontroller.net/attachment/54958/eBUS_Stuttgart_041201_eBUS_Only.PDF
LG
pah
Hallo amunra,
danke für deine Antwort.
Zitat von: amunra am 13 Januar 2015, 23:16:09
Die Klasse 47000 kenne ich nicht? - Welche Adresse/Register/Datentyp stecken dahinter.
Sorry, mein Fehler, das stammt noch von einem Beitrag weiter vorne von pah, bei dem wir mit der Betriebsart experimentiert hatten.
Habe es jetzt auf vrc430 vereinheitlicht, es ist meine Calormatic 470/3.
Zitat
Bei mir ist mcDesiredTemp wie folgt definiert:
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTemp,Manuell Solltemperatur,,,,3200,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
und liefert bei mir aktuell 21.0°C - das ist auch der Wert den ich auf dem Display der Colormatic ablesen kann.
Funktioniert bei mir leider nicht.
Ich habe deine Teile 1:1 kopiert.
Wie könnte man das zum Laufen bekommen?
read -c vrc430 mcDesiredTemp
0.0
Dagegen liefert die manuelle Abfrage etwas - das ist doch eine Temperatur, oder?
root@raspiebus:~# ebusctl write -h 15B509030D3200
01009b
Zitat
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,displayroomtemp,display room temp,,,,8000,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Achtung in meinem Template war der Datentyp nicht korrekt!
Falsch "temp2"(Data2b) richtig "temp"(Data2c)
Im Template beinhaltet der command name Leerzeichen - das darf nicht sein (also Leerzeichen entfernen)!
Jetzt liefert es den korrekten Wert für Raumtemp IST an der Calormatic :-)
Viele Grüße,
Heiko
Nein, das ist keine Temperatur. Sondern ein Byte mit dem Wert 0
pah
D.h. ich kann die "Wunschtemperatur Tag" nicht über ebusd setzen, nur die Tag-Schnellwahl?
Natürlich kann man das. Mit dem richtigen Kommando.
LG
pahz
Das ist mir schon klar.
Wie bekomme ich das richtige Kommando heraus?
Zwischenzeitlich habe ich folgendes beobachtet:
write vrc430 mcDesiredTempQV 21.5
schreibt zwar die Zieltemperatur, und ich kann diese mit read auch wieder auslesen.
ABER: Keine Veränderung der vorübergehenden Wunschtemp. an der Calormatic. D.h. der Befehl wird ignoriert.
Dreht man dagegen kurz am Währad, so dass die Anzeige mit der vorübergehenden Wunschtemp. erscheint ("OK drücken für dauerhafte Änderung, aber nicht gedrückt"), dann kann man danach beliebig oft die wunschtemp. über oben genannten Befehl ändern.
Sobald aber die Automatik wieder von Nacht auf Tag (Symbol Sonne) geschaltet hat, beginnt es wieder von vorn.
D.h. Fernsteuerung nicht möglich, erst, nachdem man einmal am Rad gedreht hat.
Ich glaub ich dreh' hier langsam am Rad :-)
Viele Grüße,
Heiko
Update 21:13:
Gilt auch für das Setzen der Nacht-Absenktemperatur. Erst nachdem ich 1x im jeweiligen Auto-Zyklus das Rad gedreht habe, wird dieser Befehl umgesetzt.
Ohne Rad drehen funktioniert bisher die Betriebsart sowie Thermostat-Aufschaltung.
Habe es selber noch nicht testen können, aber hat Du mal geschaut, ob ein bestimmter Befehl über den ebus geht, wenn das Rad gedreht wird?
schöne Grüße
Jo
Nein noch nicht. Kannst du mir einen Tipp geben, wie ich das am besten beobachte?
ebusd mit -f im Vordergrund starten, oder?
Ich erinnere mich, dass ca. jede Sekunde irgendetwas über den Broadcast läuft, auch wenn man gar nichts verändert (u.a. Date/Time, Außentemp, VL,RL/Brenner Status).
Viele Grüße,
Heiko
Richtig. Dann einfach mal am Rad drehen und schauen, ob da was kommt. Ich versuche das am Wochenende auch mal.
schöne Grüße
Jo
Das ist nicht immer broadcast - sondern können ganz gezielte Master-Slave-Daten sein.
LG
pah
Zitat von: heikoh81 am 14 Januar 2015, 18:31:45
[...]
Funktioniert bei mir leider nicht.
Ich habe deine Teile 1:1 kopiert.
Wie könnte man das zum Laufen bekommen?
read -c vrc430 mcDesiredTemp
0.0
[...]
Hallo,
ich erhalte das gleiche Ergebnis mit der 470f. DesiredTemp kann ich auch nicht auslesen.
schöne Grüße
Jo
Für 470f teste bitte mal die Adressen 4400 bzw 8600.
Ich habe nicht die 470f (=Funk), sondern über 2-Draht-Bus.
###Calormatic 470/3
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,vrc430,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTemp,Manuell Solltemperatur,,,,4400,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcDesiredTemp2,Manuell Solltemperatur,,,,8600,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
read -c vrc430 mcDesiredTemp
55.0
read -c vrc430 mcDesiredTemp2
0.0
55°C ist bei mir die Ziel-Temperatur des Warmwasser-Speichers.
Ich habe mir jetzt folgenden Work-Around ausgedacht:
- Zeitprogramme komplett über FHEM
- Temperatur zuverlässig per Timer vorgeben mittels der Nachttemperatur, d.h. wenn nicht geheizt werden soll, wird einfach die Nachtabsenktemperatur neu gesetzt. Funktioniert bis jetzt im manuellen Test-Betrieb einwandfrei.
- Warmwasser-Aufladung über Sommer-Modus, in den Zeiten ist ein 24h-Zeitfenster für Warmwasser hinterlegt. D.h. FHEM schaltet zu den von mir gewünschten Zeiten für Wamwasser-Erzeugung in den Sommermodus
Dadurch kann ich das Auto-Programm vermeiden, das mir die auch das Setzen der Nachttemperatur ohne vorheriges Drehen am Rad verhindert.
D.h. wenn ich nie in das Auto-Programm schalte, bleibt die Schreibfähigkeit immer bestehen.
Viele Grüße,
Heiko
Was sagt den 2700?
read -c vrc430 mcDesiredTemp3
21.0
Könnte passen, das ist die Tagtemperatur.
dann sollte 3000 die Absenktemp sein.
Leute, bitte helft doch mit, die Semantik der Kommandos etwas zu verbessern. "Solltemperatur" sagt aus, dass es sich um die gegenwärtig angestrebte Temperatur handelt - aber wovon ? Wenn man das also ordentlich sortieren möchte, sollte es geben
RoomTempDay
RoomTempNight
RoomTempDesired
LG
pah
Zitat von: yuhu am 16 Januar 2015, 20:14:07
Für 470f teste bitte mal die Adressen 4400 bzw 8600.
Hallo,
4400 und 8600 liefern bei mir beide 55.0, welches die Warmwasser-Wunschtemperatur ist.
schöne Grüße
Jo
Hallo!
Ich möchte mich bei allen Entwicklern hier einmal bedanken für die tolle eBus Forschung! Ich lese hier schon länger ständig mit und habe vor einigen Tagen auch die eBus Schaltung lt. Wiki gebaut. Mit den Templates bin ich noch etwas verwirrt (es schwirren schon sehr viele Versionen herum) habe aber schon die für mich wichtigen Daten entlocken können und in Fhem integriert.
Besonderen Augenmerk habe ich auf mein Liebkind dem "YAF" gelegt und habe auch schon die ersten Sichten mit den eBus Daten eingebunden.
Der eBus (letzte Beta) läuft sehr stabil, lediglich wenn ich bei Änderung der Templates den eBus ständig stoppe und starte hängt sich Fhem komplett auf, muss dann sogar mit kill -9 stoppen weil ansonsten kein Zugriff mehr möglich ist, auch nicht mit "./fhem stop".
Habe eigenen Rasperry für eBus und einen für Fhem und kommuniziere via ECMD.
@heikoh81
du hast einmal erwähnt, du kannst die Daten der Brennlinie (Außentemperatursteuerung) schon auslesen? Hast du die notwendigen Parameter dafür? Habe die Ecotec Plus und die VCR430 direkt in die Therme eingebaut.
Ich kann zwar jetzt schon den Vorlauf über die Fühlerleitung (schalte einfach eine Widerstand per Relais) beeinflussen, aber perfekter wäre es die Brennlinie direkt per eBus zu verändern. Als Auslöser benutze ich die Wichtung der Valves, ab einem bestimmten Wert erhöhe ich den Vorlauf, sinkt die Wichtung wieder verringere ich den Vorlauf.
Hallo Reinhart,
Zitat von: Reinhart am 17 Januar 2015, 12:58:08
Der eBus (letzte Beta) läuft sehr stabil, lediglich wenn ich bei Änderung der Templates den eBus ständig stoppe und starte hängt sich Fhem komplett auf, muss dann sogar mit kill -9 stoppen weil ansonsten kein Zugriff mehr möglich ist, auch nicht mit "./fhem stop".
Habe eigenen Rasperry für eBus und einen für Fhem und kommuniziere via ECMD.
Dieses Problem hatte ich, wurde hier http://forum.fhem.de/index.php/topic,31307.html (http://forum.fhem.de/index.php/topic,31307.html) diskutiert und gelöst: http://forum.fhem.de/index.php/topic,31414.msg238985.html#msg238985 (http://forum.fhem.de/index.php/topic,31414.msg238985.html#msg238985)
Wann hast du fhem zuletzt geupdated? Der Fix ist im neuesten Update auf jeden Fall mit drin.
Dann geht die CPU-load beim Stoppen von ebusd zwar bis zu 20 Sekunden auf 100% (beim Raspi), danach fängt es sich aber wieder auf Normalniveau.
Zitat
@heikoh81
du hast einmal erwähnt, du kannst die Daten der Brennlinie (Außentemperatursteuerung) schon auslesen? Hast du die notwendigen Parameter dafür? Habe die Ecotec Plus und die VCR430 direkt in die Therme eingebaut.
Was meinst du mit "Brennlinie".
Ich habe den Befehl für die Heizkurve aus der Datei von pah & amunra, meinst du das?
###Calormatic 470/3
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,vrc430,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
##########################FUNKTIONIERT - Heizkurve Einstellungen
r;w,,mcHeatingCurve,Heizkurve,,,,3100,,,uin100,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#FUNKTIONIERT 13.01.2015 - beeinflusst Heizkurve
read -c vrc430 mcHeatingCurve
write vrc430 mcHeatingCurve 1.40
write vrc430 mcHeatingCurve 1.50
Deine Floorplans sehen toll aus! Sowas ist auch mein Ziel, aber ich stehe noch mit den CSSs auf Kriegsfuss - es klappt nicht so wie ich will.
Ich sehe da Werte, die ich noch nicht habe:
- Pumpe in Watt
- Betriebsstunden Gebläse
- Brennerstarts - bei mir zeigt es an der Therme nur kryptisch 55x100 an, wie kann man das umrechnen?
Viele Grüße,
Heiko
Update:
- 2700 = Tagtemperatur
- 3000 = Nachtabsenkung (steht so auch schon in der Datei von amunra).
Schreiben funktioniert in beiden Fällen, auch wenn die Heizung komplett im Auto-Modus ist und keiner am Rädchen dreht.
Durch Schreiben dieser beiden Werte kann man den Heizbetrieb also auch im Auto-Modus nun vollständig über FHEM-Steuern.
@Reinhart: es freut mich, einen YAF-Fan zu sehen. Die beiden Studenten, die das für mich realisiert haben, sind schon längst nicht mehr da - und ich habe YAF seitdem nicht mehr angefasst.
Betreffend den Wechsel der Konfiguration:
1. Neue Datei per sftp auf den Raspberry
2. ssh-Fenster auf den Raspberry setzen.
3. ebusctl reload liest die neue Konfiguration ein, ohne den ebusd neu zu starten.
Außerdem empfehle ich, den Watchdog-Timer des Raspberry zu nutzen, um den ebusd zu überwachen und ggf. neu zu starten.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 17 Januar 2015, 18:03:51
3. ebusctl reload liest die neue Konfiguration ein, ohne den ebusd neu zu starten.
Auch mal gut zu wissen, ich bemühte bislang immer /etc/init.d/ebusd restart...
Zitat
Außerdem empfehle ich, den Watchdog-Timer des Raspberry zu nutzen, um den ebusd zu überwachen und ggf. neu zu starten.
Ich habe bislang folgendes Problem, das seither 2x aufgetreten ist:
Mein Heizungs-Raspi mit USB-Ebus-Adapter von eservice-online läuft 24/7.
- Nach einem längeren, nicht genauer bekannten und variierenden Zeitraum >7 Tage stürtzt irgendetwas am Heizungs-Raspi ab.
- ebusd läuft noch, der Ebus-Adapter blinkt wie gewohnt, Raspian ist normal ansprechbare.
- ebusd-restart hilft nicht, danach immer noch kein Kontakt per telnet localhost 8888 möglich
Letztlich hilft nur shutdown -r now. Das könnte ich natürlich in einen cronjob packen für stabilen Betrieb.
Hat das Problem der Langzeit-Instabilität noch jemand?
Viele Grüße,
Heiko
LG
pah
[/quote]
@Prof.
Danke für den guten Tipp mit "reload". Das Problem was ich habe ist jenes, wenn ich in den Templates arbeite und Fehler einbaue, dann sehe ich die nur nach einem Neustart wie viele er eingelesen hat und wo ich suchen muss. Ist aber trotzdem schon viel besser so.
Ich finde es auch sehr schade, dass die Vorteile von YAF hier im Forum nicht so gut ankommen. Bei dem Bild der Ecotec ist die längste Arbeit das Bild suchen und die Eingabefelder zu zeichnen, der Rest geht mit YAF ja in wenigen Minuten. Im Augenblick muss ich aber mit einer alten 01_FHEMWEB.pm arbeiten weil sich ja bei den meisten Frontends durch die letzten Updates Fehler eingeschlichen haben. Leider ist so vorübergehend auch YAF unbrauchbar geworden wegen der JS Änderung.
@heikoh81
Danke für die Parameter der "Heizkurve", funktioniert tadellos. Ich werde mir das in den nächsten Tagen einmal einbauen und die entsprechende Logik überlegen bei welchen Schwellwerten ich die Kurve ändern soll.
Deine gesuchten Einträge sind folgende:
r,,PumpPower,d.15 => Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,BurnerStartsHC,d.82 => Brennerstarts Heizung,,,,2900,,,UIN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,FanOperatingHours,Gebläselaufzeit,,,,1B00,,,D2C,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,OperatingHoursHC,d.80 => Betriebsstunden Heizung,,,,2800,,,UIN,,hours,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
und bei der Brennerlaufzeit rechne ich nichts um, der Wert kommt schon in Stunden. Dürfte wohl ein Problem der unterschiedlichen templates sein. Hardware haben wir ja fast dieselbe.
pi@raspberrypi2 ~ $ ebusctl r OperatingHoursHC
10270
LG
Reinhart
Freut mich sehr, dass ich mit der Heizkurve weiterhelfen konnte :-)
Credits dafür gehen natürlich an pah, amunra, jojo und yuhu, die das alles rausgefunden haben!!!
Tausend Dank nochmal an alle!!!! ;)
Kennst du zum Prüfen der Funktion bereits ebusd --ceckconfig?
Das zeigt die Zeile und Spalte in der .csv an, wo der Fehler steckt.
Ich glaube, ganz identisch sind unsere Heizungen nicht!
Bei mir ist d.15 z.B. Pumpendrehzahl in %, auch Ok, aber ich sehe gern die Leistung.
Weiß irgendjemand für die Ecotec zufällig das Register für die Brennerleistung?
Die wird bei "Brenner an" in Form eines wachsenden Balkens genau wie der Systemdruck auf dem kleinen Thermen-Display in Echtzeit angezeigt.
Das wäre noch schön zu sehen, aber das Register ist bisher in keiner der Dateien enthalten!
Viele Grüße,
Heiko
Zitat von: heikoh81 am 17 Januar 2015, 17:40:38
Update:
- 2700 = Tagtemperatur
- 3000 = Nachtabsenkung (steht so auch schon in der Datei von amunra).
Schreiben funktioniert in beiden Fällen, auch wenn die Heizung komplett im Auto-Modus ist und keiner am Rädchen dreht.
Durch Schreiben dieser beiden Werte kann man den Heizbetrieb also auch im Auto-Modus nun vollständig über FHEM-Steuern.
Hallo yuhu und Heiko,
vielen Dank dafür! Insbesondere die Tag-Wunschtemperatur konnte ich bisher weder auslesen, noch schreiben.
Der nächste Schritt wäre jetzt wirklich, das alles mal aufzuräumen und ein wenig systematischer zu gestalten - zumindest meine Tabellen sehen aus wie Kraut und Rüben ::)
schöne Grüße
Jo
@Heiko
Danke nochmals für die Tipps betreffend eBus reload und --checkconfig. Beide Befehle bringen genau das Ergebnis wie bei einem Neustart, nur eben ohne Neustart und den damit verbunden Instabilitäten.
Ich glaube auch, dass es bei den Vaillant Thermen viele Variationen der Thermen bzw. der eingesetzten Software gibt und daher bei vielen Usern nicht alles 1:1 eingesetzt werden kann.
Ich habe ja auch aus vielen Postings aus diesem Thread die Templates zusammen gesucht und durchprobiert, daher die vielen Starts des eBus. Ich habe jetzt die Heizkurve mit deinen Parametern schon am laufen und kann sie bequem setzen. Die Automatik der Heizkurvenänderung beobachte ich zunächst noch ein paar Tage und werde sie dann stufenweise implementieren. Heizkurve setzen und am VRC überprüft, passt genau.
define HeizkurveEinstellen dummy
attr HeizkurveEinstellen group Heizkurve_Einstellen
attr HeizkurveEinstellen icon temp_control
attr HeizkurveEinstellen room Vaillant
attr HeizkurveEinstellen setList state:1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
attr HeizkurveEinstellen webCmd state
define HeizkurveSchreiben_Click notify HeizkurveEinstellen {\
fhem("get HeizkurveSchreiben HeizkurveSchreiben");;\
}
attr HeizkurveSchreiben_Click group heatingControl
attr HeizkurveSchreiben_Click room Vaillant
define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
attr HeizkurveSchreiben group Heizkurve_Einstellen
attr HeizkurveSchreiben room Vaillant
Heizkurven Verstellung nach Heiko (mit setlist), funktioniert.
Im Anhang noch meine komplette Fhem Vaillant Konfiguration (so wie im Bild ist die vaillant-komplett.txt) und die Class so wie ich sie derzeit einsetze. Ich habe alle meine Abfragen in eine Class Definition (bai00.cfg) gespeichert, sonst wird es zu übersichtlich. Auch die Writes für die Heizkurve. Vielleicht kann es jemand brauchen für Vergleichszwecke (die YAF Zeilen entfernen wers nicht hat), mir helfen solche Dateien immer gut für diverse Tests weiter.
Meine Therme: Vaillant Ecotec Plus VCW AT 246/3-5 (ich nehme an das AT steht für Österreich Version)
Calormatic: VRC 430 Softwareversion 2.15
Ich habe auch schon versucht mit meinem eBus Konverter direkt am Laptop die Vaillant VRDialog-Software zu starten , funktioniert aber nicht. Ich sehe zwar an den Leds, dass serielle Signale zum eBus gesendet werden, der eBus antwortet aber der Software nicht. Wenn ich mal Zeit habe, dann baue ich die Polenschaltung (Pegelanpassung) mit dem MAX 232 nach und versuche sie nochmals zu koppeln. Nachdem aber jetzt der eBus schon so gut funktioniert, hat das keine Dringlichkeit mehr. Ich habe auch schon aus einem Forum gelesen, das die Software mit einem Dongle (im Kabel) geschützt sein soll. Ich habe aber die Beta (von dem Vaillant.pl), da dürfte das nicht der Fall sein, denn ich kann alles starten und den eBus scannen um die Verbindung zu prüfen.
LG
Reinhart
Ich kenne zwar die "Polenschaltung" nicht - aber einen MAX232 halte ich für überflüssig, das ginge mit zwei Billig-Operationsverstärkern besser und variabler.
Darüber hinaus kann es nicht am Interface liegen, wenn der Adapter mit anderer Software funktioniert.
Die Vielfalt der Geräte ist natürlich der Grund, warum Vaillant in der vrDialog-Software eine echte Datenbank einsetzt, um den Zusammenhang zwischen Registern und Befehlen zu dokumentieren.
Das zeigt auch den Weg, den wir gehen müssen: Auf den Wiki-Seiten eine große Tabelle aufmachen, die für jede Gerätevariante die gefundenen Register mit dem Namen verknüpft.
Voraussetzung ist deshalb (und darum mein voriger Appell), dass man die Bezeichnungen ein wenig standardisiert.
Betreffend die Heizkurve: Die hat immer Steigung und Offset - beeinflussbar durch die eingestellte (nicht tatsächliche) Raumtemperatur. Diese "Heizkurve" sollten wir also sehen als eine lokale lineare Annäherung an die tatsächlich gewünschte Heizkurze.
Ziel solte hier also sein, einen schönen variablen PID-Regler zu programmieren (gibt es schon), der in regelmäßigen Abständen Offset und Steigung der Heizkurve anpasst (gibt es noch nicht). Damit ist sichergestellt, dass nicht FHEM die Heizung direkt steuert - sondern nur als "Überintelligenz" über der Heizung sitzt, so dass diese auch autonom laufen kann.
LG
pah
Zitat von: Reinhart am 18 Januar 2015, 16:44:33
Ich habe jetzt die Heizkurve mit deinen Parametern schon am laufen und kann sie bequem setzen. Die Automatik der Heizkurvenänderung beobachte ich zunächst noch ein paar Tage und werde sie dann stufenweise implementieren. Heizkurve setzen und am VRC überprüft, passt genau.
@Reinhard:
Was genau beeinflußt denn die Heizkurve? Bei mir ist sie standardmäßig auf 0.9 eingestellt.
Was für eine "Automatik der Heizkurvenveränderung" gibt es denn?
Eigentlich hätte ich gerne was in Abhändigkeit vom Wetterbericht :-)
Danke für die Tipps...Netsrac
Zitat von: netsrac27 am 19 Januar 2015, 14:08:07
Was genau beeinflußt denn die Heizkurve? Bei mir ist sie standardmäßig auf 0.9 eingestellt.
Was für eine "Automatik der Heizkurvenveränderung" gibt es denn?
Eigentlich hätte ich gerne was in Abhändigkeit vom Wetterbericht :-)
hier (http://www.bosy-online.de/Heizkurve.htm) ist das ganze recht gut beschrieben!
Hallo,
ich würde auch gern das Modul aus dem Wiki nachbauen, habe aber Probleme einen geeigneten Kondensator zu finden. Evtl. kann ja jeman einen Tipp geben. (reichelt oder conrad)
Grüße
Daniel
Zitat von: druschba am 19 Januar 2015, 16:07:59
Hallo,
ich würde auch gern das Modul aus dem Wiki nachbauen, habe aber Probleme einen geeigneten Kondensator zu finden. Evtl. kann ja jeman einen Tipp geben. (reichelt oder conrad)
Grüße
Daniel
das ist ein ganz normaler Elektrolykondensator mit 10 µF, axial oder radial ist egal, je nachdem wieviel Platz du hast. Der Wert ist hier nicht kritisch, da er nur die Spannung vom Regler glättet. Ich habe bei mir 33 µF genommen. Dich verwirrt vermutlich die Angabe im Wiki mit "10 u", gemeint ist hier 10 µF!
Hier von Conrad: http://www.conrad.de/ce/de/product/445503/Elektrolyt-Kondensator-radial-bedrahtet-25-mm-10-F-100-VDC-20--x-H-5-mm-x-11-mm-Yageo-SE100M0010AZF-0511-1-St/?ref=search&rt=search&rb=1 (http://www.conrad.de/ce/de/product/445503/Elektrolyt-Kondensator-radial-bedrahtet-25-mm-10-F-100-VDC-20--x-H-5-mm-x-11-mm-Yageo-SE100M0010AZF-0511-1-St/?ref=search&rt=search&rb=1)
LG
Reinhart
Danke.. dann kanns ja losgehen.
Ich melde mich wieder, wenn ich den Konverter gebaut habe.
Grüße
Zitat von: Prof. Dr. Peter Henning am 19 Januar 2015, 11:49:21
Betreffend die Heizkurve: Die hat immer Steigung und Offset - beeinflussbar durch die eingestellte (nicht tatsächliche) Raumtemperatur. Diese "Heizkurve" sollten wir also sehen als eine lokale lineare Annäherung an die tatsächlich gewünschte Heizkurze.
Ziel solte hier also sein, einen schönen variablen PID-Regler zu programmieren (gibt es schon), der in regelmäßigen Abständen Offset und Steigung der Heizkurve anpasst (gibt es noch nicht). Damit ist sichergestellt, dass nicht FHEM die Heizung direkt steuert - sondern nur als "Überintelligenz" über der Heizung sitzt, so dass diese auch autonom laufen kann.
LG
pah
Ja, ein PID Regler wäre genau das richtige dafür. Ich versuche (2 Fam. Haus am Berg und windige Gegend) eine möglichst kleine Heizkurve (1,1) einzustellen. Es kann dann aber bei viel Wind vorkommen, das die Heizleistung dieser Kurve nicht ausreicht. Mir gefällt daher der Ansatz diese Kurve mit der Wichtung (Valves-Modul überwacht Öffnungswinkel mehrerer Regler am Heizkörper am errechnet eine Wichtung) ab einer erreichten Schwelle parallel nach oben zu schieben. Dies erreiche ich momentan mit einem Relais, welches im Aussentemperaturfühler geschalten ist (Ruhekontakt) und einfach einen 100 Ohm Widerstand in Serie dazu schaltet. So wird eine tiefere Außentemperatur vorgetäuscht und somit der Vorlauf automatisch erhöht. Zusätzlich funktioniert natürlich der Außenfühler auch noch. Sinkt der Wert von Valve, dann wird die Kurve wieder abgesenkt. Man müsste jetzt mit diesem Wichtungs Wert den PID Regler ansteuern.
Fällt Fhem oder eBus aus, ist das weiter nicht kritisch da der letzte Wert ja in der Calormatic gespeichert ist und die Heizung somit noch läuft.
Die Schaltung funktioniert prima, nur nicht so schön wie ein PID Regler, ich habe somit ungefähr einen Offset von 7-10 Grad höheren Vorlauf.
Wegen der Templates muss ich dir völlig recht geben, man sieht ja schon jetzt, dass die paar Leute die sich damit befassen schon unterschiedliche Templates benötigen obwohl die Hardware ähnlich ist. Vermutlich sind diese Daten ja werksintern "geheim" und somit nicht zugänglich. Was bei welchen Thermen wann was geändert/erweitert wurde. Aber wenn die vRDialog eine Datenbank benutzt, müsste man an diese Daten herankommen. Ich werde mir die installierten Verzeichnisse einmal genau anschauen.
LG
Reinhart
Zitat von: druschba am 19 Januar 2015, 17:28:54
Danke.. dann kanns ja losgehen.
Ich melde mich wieder, wenn ich den Konverter gebaut habe.
Grüße
Als kleiner Tipp zum Abstimmen des Potis R3. Ich habe zusätzlich am Ausgang Pin4 des 4011 (RxD) eine Led mit 1K Ohm gegen Masse angeschlossen und kann somit die eBus Signale beobachten. Dann habe ich den USBtoSeriell Wandler am Laptop eingesteckt damit die Schaltung mit Spannung versorgt wird. Am Eingang der Schaltung (da wo später der eBus angeschlossen wird) habe ich dann mit einem regelbaren Netzgerät exakt 12 Volt eingespeist. Nun drehst du das Poti ganz langsam das die Led gerade nicht leuchtet. Erhöhst du nun die Spannung am Netzgerät, sollte die Led sofort leuchten. Mit dieser Einstellung wird dann der eBus sicher richtig interpretiert.
LG
Reinhart
@pah
ich habe mir jetzt die Datenbank von der VRdialog angesehen, sind ganz normale Access Dateien (MdB) und beinhalten verschiedene Tabellen mit Ids, Adressen etc. Besonders interessant finde ich die "vrdialog810.mdb" und hier die Tabellen "scanning" und "ident", welche offensichtlich alle Gerätetypen mit den IDs beinhaltet.
Dir sagt das sicher mehr als mir.
LG
Reinhart
Die LED sollte nicht "gerade nicht leuchten" - sondern bei angeschlossenem EBUS ständig flackern, weil die Synchronisationssignale einlaufen.
LG
pah
Hallo,
9600 (RoomTemp) zeigt leider bei mir die Wunschtemperatur an. Sobald die Heizung in den Nachtmodus geht, zeigt es 0.0 an. Und ich wundere mich schon, wie schön konstant die Temperatur doch ist ;D
8000 zeigt bei mir meist etwas um die 1.328 an, entspricht aber nicht der Außentemperatur.
Gibt es noch eine Adresse für den Außensensor?
schöne Grüße
Jo
@jojo:
Bei mir (Calormatic 470/3, ecotec plus) ist 8000 die RoomTemp.
Welche Geräte hast du nochmal?
Die Außentemp. bekomme ich mittels pah's Dateien aus dem Repository über den Broadcast.
Das war mit einer meiner ersten Gehversuche mit ebusd und einer der ersten Werte, die dann im Klartext angezeigt wurden:-)
u,BC,OutsideTempBC,Aussentemperatur ,10,FE,B516,01,,,D2B,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
@Reinhart:
Die Idee mit dem Kondensator zur Vortäuschung einer Außentemperatur ist natürlich klasse.
Bei mir gibt es in der Calormatic sowohl für Raum- als auch Außentemp. aber einfach einen Offset in Kelvin - würde das nicht dasselbe bezwecken?
Mir ist die Beeinflussung der Heizkurve aus folgendem Grund wichtig:
So wie ich verschiedene Quellen im Internet verstanden habe, ist die Heizkurve ein wichtiger Faktro zum verbrauchsoptimierten Fahren einer Heizung, d.h. die Heizkurve natürlich so klein wie möglich zu halten, damit die Raumtemp. gerade noch angenehm empfunden wird.
Und genau hier liegt das Problem - dieses Empfinden ist subjektiv (hängt sicherlich auch mit der Außentemp. zusammen, gerade (sehr feucht) finde ich es kälter als die -10° zwischen den Jahren).
Und wenn es nun gefühlt kälter ist, will ich es ein bißchen schneller warm in der Stube haben - in so einem Fall würde ich die Heizkurve ein bißchen Hochziehen, um den Vorlauf heißer zu kriegen.
Wenn es gefühlt nicht so kalt ist, will ich natürlich mit möglichst niedrigem Vorlauf fahren (Energieeinsatz, Heizungsverschleiß etc.)
Na, eben.
Es wirken viele Faktoren - Windgeschwindigkeit ist nur einer davon. Luftfeuchte ein anderer. Im Prinzip müsste man dieses hier
http://de.wikipedia.org/wiki/Windchill
auf diese Vielzahl von Faktoren erweitern.
Machbar ist das durchaus, weil man ja seine eigenen negativen Gefühle registrieren kann.
Im einfachsten Fall: Registrierung einer gewünschten Parameteränderung mit Uhrzeit, Wochentag und externen Faktoren. Evolutionäre Anpassung einer durch diese externen Faktoren geführten Heizkurve
Komplizierter: Regelbasiertes System, dem durch einen Korrekturwunsch ein neues Axiom hinzugefügt wird. Ein Reasoner bestimmt dann, ob die Temperatur derzeit erhöht werden muss.
LG
pah
Seltsam, dann muss ich mal weiter suchen. Habe die 470f.
Was anderes: Ich habe das ECMD wie im wiki beschrieben eingerichtet inkl timer, der jede minute die Werte abruft. Leider erscheint jede Abfrage im logfile, obwohl ich verbose auf 0 gesetzt habe. Gibt es eine Möglichkeit, die Meldungen zu unterdrücken?
schöne Grüße
Jo
Zitat von: Prof. Dr. Peter Henning am 19 Januar 2015, 19:44:30
Die LED sollte nicht "gerade nicht leuchten" - sondern bei angeschlossenem EBUS ständig flackern, weil die Synchronisationssignale einlaufen.
LG
pah
das "gerade nicht leuchten" bezieht sich auf die Kalibrierung des Potis mit angeschlossenem regelbaren Netzgerät (mind 7 - 15 V) am Buseingang der Schaltung. Im Betrieb mit angeschlossenem eBus flackert dann die Led sehr schön, vor allem wenn man Befehle absetzt ist die Antwort dann gut sichtbar. Es ist ja nur eine Hilfe zur genaueren Einstellung der Schaltschwelle der Nand Gatter. Man kann auch im aktiven Betrieb eine Einstellung vornehmen, weiß aber nie wo die Schwellen dann tatsächlich liegen. Der ideale Schaltpunkt lt. eBus Spezifikation liegt ja zwischen 12-15 V. (<12=Low, >15=High). Die Stellung des Potis hängt auch sehr vom verwendeten Typ des Optokopplers ab, ich habe den ILD74 (Dual Ausführung) verwendet und habe mir so etwas Platz gespart.
@pah
da ich ja einer der wenigen Anhänger (schade eigentlich) von dem komfortablen Frontend YAF bin und seit der JS Änderungen vor einigen Wochen in der 01_FHEMWEB.pm YAF ja nicht mehr funktioniert habe ich mir die 01_YAF.pm heute einmal genauer angesehen und gepatcht!
siehe: http://forum.fhem.de/index.php/topic,31999.msg248808.html#msg248808 (http://forum.fhem.de/index.php/topic,31999.msg248808.html#msg248808)
sub YAF_Request ($@) {
my ($htmlarg) = @_;
# %20 durch Leerzeichen ersetzen
$htmlarg =~ s/%20/ /g;
# modify by Reinhart "htmlarg: /YAF/www/global/yaf.htm" is incorrect, delete this
$htmlarg =~ s/www\///g;
habe hier die Pfadkorrektur durchgeführt und die Versionsnummer erhöht. Wenn hier keine negativen Rückmeldungen erfolgen, kannst du das BITTE nochmals anschauen und dann einchecken? Es wäre ewig schade wenn YAF für den schon sehr gut funktionieren eBus nicht mehr eingesetzt werden kann.
PS: kenne mich in Pearl nicht aus, habe mich aber schon einmal mit Python beschäftig und schaut ja ähnlich aus, sonst hätte ich den Fehler auch nicht gefunden.
LG
Reinhart
Zitat von: Jojo11 am 19 Januar 2015, 20:08:51
Hallo,
9600 (RoomTemp) zeigt leider bei mir die Wunschtemperatur an. Sobald die Heizung in den Nachtmodus geht, zeigt es 0.0 an. Und ich wundere mich schon, wie schön konstant die Temperatur doch ist ;D
8000 zeigt bei mir meist etwas um die 1.328 an, entspricht aber nicht der Außentemperatur.
Gibt es noch eine Adresse für den Außensensor?
schöne Grüße
Jo
Hallo,
einen kleinen Teilerfolg habe ich zu vermelden: Die 8000 zeigt bei nun doch die Raumtemperatur an, allerdings mit dem template "temp" und nicht mit "temp2". Mag sein, dass das hier schon korrigiert wurde, dann habe ich allerdings überlesen.
schöne Grüße
Jo
@Reinhart: Würde ich gerne machen, habe aber im Moment nur extrem wenig Zeit, das zu überprüfen. Ich müsste nämlich erst YAF bei mir installieren - und meine Zeit ist bis Ende nächster Woche durch das hier http://www.learntec.de vollkommen ausgelastet.
Vorschlag: Patch im Forum zu YAF veröffentlichen, wenn sich keine Probleme zeigen, checke ich das einfach so ein.
LG
pah
Zitat von: Jojo11 am 20 Januar 2015, 18:13:01
Mag sein, dass das hier schon korrigiert wurde, dann habe ich allerdings überlesen.
Ja, hier http://forum.fhem.de/index.php/topic,29737.msg245360.html#msg245360 (http://forum.fhem.de/index.php/topic,29737.msg245360.html#msg245360)
VG Arthur
Hallo zusammen,
zum Thema Ebusd Integration in FHEM sieht es bei mir im Moment so aus -> siehe Screenshots.
Was geht:
- Verbindung zum Ebusd vai EbusClient
- Set/Get DropDown Listeneinträge kommen dynamisch aus den Ebus-Config-Files
- Verarbeitung mehrerer Ebusd-Template-Files
- Definition: Hostename,Port.
- Definition: Pfad/Verzeichnis der Ebusd-Config-Dateien
Was fehlt:
- Verbindung via Telnet (für mich derzeit optional)
- Dynamische/Zyklische Aktualisierung der Readings (Definition Polling-Intervalle und Werte(per Regex,etc.?)) - Abfrage der Werte via at geht ja jetzt schon.
- etc.
VG Arthur
Läuft bei mir so: 1x pro Minute per at eine Gruppe von Lesebefehlen an 3 verschiedene ECMD-Devices, die über ECMD und telnet den ebusd abfragen.
Polling auf dem ebus brauche ich nicht - das macht m.E. das ganze nur langsamer, weil unnötig viele Befehle über einen langsamen Bus geschickt werden.
LG
pah
Zitat von: amunra am 21 Januar 2015, 13:04:02
Hallo zusammen,
[...]
- Set/Get DropDown Listeneinträge kommen dynamisch aus den Ebus-Config-Files
[...]
VG Arthur
Das sieht doch schon ziemlich komplett aus :)
Kannst Du evtl. anhand eines kleinen Beispiels erklären, wie Du diese Einträge dynamisch übernimmst?
schöne Grüße
Jo
Hallo,
leicht OT, aber evtl. hier auch von Interesse. Mit ECMD habe ich folgendes beobachtet:
FHEM läuft auf einem cubietruck, EBUSD auf einem Pi. Wenn ich den ebusd stoppe, fährt die Auslastung des cubietruck in die Höhe, so dass fhem nicht mehr reagiert. Es hilft nur ein Neustart des CT (und natürlich des ebusd). Kann ich das Einfrieren bei fehlender Verbindung zum ebusd unterdrücken?
schöne Grüße
Jo
Hallo,
Ich bin ganz neulich auf FHEM und dieses Forum angetroffen: zuerst, vielen Dank für die hilfreiche Beiträge and besonders für ebusd!
Der Grund dafür war, dass ich ein Gasgerät Protherm Condens Panther 30 KKO mit drahtlosem Regler Thermolink P/2 habe. Die Anleitung sagte was über eBUS, Protherm is Glied der Vaillant Gruppe, so habe ich das Geld aufs Spiel gesetzt und den eBUS-USB Koppler gekauft.
Glücklicherweise, ebusd sagt, dass es ein BAI00 ist.
$ ebusctl scan result
08;Joh. Vaillant GmbH & Co.;BAI00;0502;3302;21144000;100088631;610005132;N4
14;Joh. Vaillant GmbH & Co.;BADID;0000;0000;11440002;82005051N;8�� ;N8
15;Joh. Vaillant GmbH & Co.;E7f_2;0001;8002;21144000;201180840;082005051;N8
16;Joh. Vaillant GmbH & Co.;E7f_2;0203;7502;21144000;201180840;011808400;N8
26;Joh. Vaillant GmbH & Co.;E7f_2;0001;8002;01180840;011808400;082005051;N8
35;Joh. Vaillant GmbH & Co.;E7f_2;0001;8002;11440002;011808400;82005051N;8�
An der anderen Seite, Google hat nichts von "BADID" Regler gefunden, so ein bischen Forschung ist doch nötig. Main Ziel ist nur die verschiedene Werte abzulesen und einen Graf zuerstellen.
Jetzt eine Frage: sind die Befehle in BAI00 (in FHEM contrib auf SourceForge.net) für alle BAI00 Geräte die selbe oder muss man damit rechnen, dass die SW/HW Version (0502 und 3302?) auch eine Rolle spielt und deshalb ganz vorsichtig fortschreiten?
Hm, ich vermute: BADID = BAD ID => CRC-Fehler beim Auslesen.
08 = BAI00 ist die Gastherme. Kann sein, dass diese dieselben Register hat wie die anderen BAI00
15 = drahtloser Regler selbst
26 = Heizkreismodul ?
16 = Evtl. Warmwassermodul
35 = Evtl. Mischerkreis
Der zentrale Regler 15 kommuniziert per EBUS mit den internen Modulen - es sollte sich also auf dem Bus einiges tun, etwa die Steuerung des Heizkreises durch den zentralen Regler (1526B5....)
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Januar 2015, 20:32:18
Hm, ich vermute: BADID = BAD ID => CRC-Fehler beim Auslesen.
Ja, es klingt logisch.
Zitat von: Prof. Dr. Peter Henning am 21 Januar 2015, 20:32:18
15 = drahtloser Regler selbst
26 = Heizkreismodul ?
16 = Evtl. Warmwassermodul
35 = Evtl. Mischerkreis
Es könnte so sein, alerdings die Warmwasserding & Mischerkreis nicht in Betrieb sind.
Zitat von: Prof. Dr. Peter Henning am 21 Januar 2015, 20:32:18Der zentrale Regler 15 kommuniziert per EBUS mit den internen Modulen - es sollte sich also auf dem Bus einiges tun, etwa die Steuerung des Heizkreises durch den zentralen Regler (1526B5....)
ebusd läuft für eine Stunde oder so, manche Kommandos aus dem bai00.csv funktionieren schön - besonders StatusTHER - und einige nicht: z.B. PartialPower (die Antwort ist immer 0 kW).
Ich denke, dass es unmöglich ist die Drinnentemperatur aus dem drahtlosen Raumregler abzulesen, nicht war? Es ist wahrsheinlich so, das der Raumregler nur die Gastherme informiert (einmall in zehn minuten oder wenn manipuliert), das die Therme brennen soll oder nicht :-(
mk
@Jojo11
pah hat mir den Tipp mit "ebusctl reload" gegeben und damit du siehst ob auch die Templates korrekt geladen werden "ebusd --checkconfig" von heikoh81.
Aber du hast recht, wenn am Device was passiert der den eBus liest dann hilft das allerdings nicht viel. Da muss dann ein Watchdog mit eMail herhalten.
Ich habe nun schon seit Tagen keinen Neustart des eBus (die letzte Beta) mehr gemacht und alles läuft prima ohne Hänger. Wenn es mindestens eine Woche störungsfrei läuft, baue ich alles in ein Klarsicht Gehäuse von ELV und montiere es neben der Therme. Die LEDs möchte ich blinken sehen, denn das gibt eine erste Funktionskontrolle.
LG
Reinhart
Zitat von: Jojo11 am 21 Januar 2015, 19:18:08
Das sieht doch schon ziemlich komplett aus :)
Kannst Du evtl. anhand eines kleinen Beispiels erklären, wie Du diese Einträge dynamisch übernimmst?
schöne Grüße
Jo
Hallo Jojo11,
das würde jetzt den Rahmen sprengen (sorry), soviel kann ich (kurz/grob) erklären:
- Ich nutze nicht das ECMD Modul und auch kein(e) Dummy-Button(s) -> Es ist ein eigenes Modul
- Die CSV Datenstruktur ist ja vorgegeben – die Idee ist, die schon vorhandenen Informationen zu verwenden.
- Die CSV Datei wird eingelesen, entsprechend in ein Hash (Datenstruktur) gespeichert, verarbeitet (den zugehörigen Klassen zugewiesen) und an die Set/Get Funktionen des Moduls übergeben.
Dies nur als Kurzfassung.
VG Arthur
Warum soll das unmöglich sein? Habe auch einen Funkregler 470f, der auch über den ebus kommuniziert.
schöne Grüße
Jo
Zitat von: amunra am 21 Januar 2015, 21:16:43
Hallo Jojo11,
das würde jetzt den Rahmen sprengen (sorry), soviel kann ich (kurz/grob) erklären:
- Ich nutze nicht das ECMD Modul und auch kein(e) Dummy-Button(s) -> Es ist ein eigenes Modul
- Die CSV Datenstruktur ist ja vorgegeben – die Idee ist, die schon vorhandenen Informationen zu verwenden.
- Die CSV Datei wird eingelesen, entsprechend in ein Hash (Datenstruktur) gespeichert, verarbeitet (den zugehörigen Klassen zugewiesen) und an die Set/Get Funktionen des Moduls übergeben.
Dies nur als Kurzfassung.
VG Arthur
Ok, danke!
schöne Grüße
Jo
Zitat von: Jojo11 am 21 Januar 2015, 19:31:16
Hallo,
leicht OT, aber evtl. hier auch von Interesse. Mit ECMD habe ich folgendes beobachtet:
FHEM läuft auf einem cubietruck, EBUSD auf einem Pi. Wenn ich den ebusd stoppe, fährt die Auslastung des cubietruck in die Höhe, so dass fhem nicht mehr reagiert. Es hilft nur ein Neustart des CT (und natürlich des ebusd). Kann ich das Einfrieren bei fehlender Verbindung zum ebusd unterdrücken?
schöne Grüße
Jo
Verwendest du auch die aktuelle ECMD Version? In der neuen Version soll das Thema "einfrieren bei disconnect" behoben sein?
VG Arthur
ZitatIch denke, dass es unmöglich ist die Drinnentemperatur aus dem drahtlosen Raumregler abzulesen, nicht war? Es ist wahrsheinlich so, das der Raumregler nur die Gastherme informiert (einmall in zehn minuten oder wenn manipuliert), das die Therme brennen soll oder nicht :-(
Kann mich Jojo11 nur anschließen - probier doch die VRC430.csv (Datei gibt es hier im Forum) aus.
VG Arthur
Zitat von: amunra am 21 Januar 2015, 21:24:21
Verwendest du auch die aktuelle ECMD Version? In der neuen Version soll das Thema "einfrieren bei disconnect" behoben sein?
VG Arthur
Eigentlich schon. Fhem ist gestern aktualisiert worden.
schöne Grüße
Jo
Zitat von: Jojo11 am 21 Januar 2015, 21:17:48
Warum soll das unmöglich sein? Habe auch einen Funkregler 470f, der auch über den ebus kommuniziert.
schöne Grüße
Jo
Korrekt! Ich habe schon was abgelesen, jetz muss ich noch viel lernen. Ich komme wieder zurück wenn ich etwas ereiche.
Noch eine Sache würde mir helfen:
Die BC-Nachricht ist: update BC cmd: 10feb5160301500127
Die menschlesbare Wert ist: update BC OutsideTempBC: 1.312Die Nachrichtstruktur soll sein:
10 FE B516 01 temperature D2BNach der ebusd Wiki is der Datentyp
"D2B": signed number, -127.99 - +127.99 (fraction 1/256, divisor 256, 2 bytes)Wie soll man die Wert "5001" handeln um die 1.312 zu bekommen? 0x5001 ist dec 20481, dividiert bei 256 ist 80. Dass wäre -48 °C... Ich bin kein Programmer, sicher muss es einfach sein.
@MilanK. Nein. LSB (Least Significant Byte) zuerst ! Also 5001 => 0x0150 = 1*256 + 5*16 => dividieren durch 256 => 1 + 5/16. Das stimmt also
@amunra: Ich habe darüber nachgedacht, dafür ein weiteres ein eigenes FHEM-Modul zu schreiben und FHEM direkt mit _allen_Kommandos an den EBUS zu koppeln.. Aber erstens möchte ich weiterhin den ebusd auf einem separaten Raspberry laufen lassen, zweitens halte ich das Ganze für sehr gefährlich: Wenn es möglich ist, wichtige Betriebsparameter der Heizung per Mausklick aus der Entfernung zu setzen, ist dies eine erhebliche Sicherheitslücke. Damit meine ich nicht einmal einen Hack (Vaillant hat das ja aufgegeben wegen der Unsicherheit). Sondern z.B. eine Fehlbedienung. So könnte man (dummerweise) die Gasart ändern, oder die Vorlauftemperatur auf 150 Grad setzen und die Heizung zerstören.
Das ist viel zu riskant. Nicht umsonst schützt Vaillant wichtige Einstellungen bei der manuellen Eingabe (nicht auf dem EBUS) durch (na ja) Passwörter. Und von Fragen der Versicherung ganz zu schweigen.
Nun könnte man ja noch argumentieren, dass auf dem Raspberry ein separates FHEM laufen kann, das mit der Hauptinstanz über FHEM2FHEM kommuniziert. Das ist aber auch nur telnet.
Zusammengefasst also: ebusd auf einem separaten System, und Zugriff darauf mit ein paar kryptischen telnet Kommandos ist (etwas) sicherer, als das direkt in FHEM einzubauen.
Was also machen ? Mir schwebt vor, ein zentrales Modul zur Heizungssteuerung zu schreiben, das dann verschiedene backends hat, die mit unterschiedlichen Heizungssystemen kommunizieren. So etwas habe ich ja schon mit der OWX-Modulfamilie produziert.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 Januar 2015, 06:46:34
@MilanK. Nein. LSB (Least Significant Byte) zuerst ! Also 5001 => 0x0150 = 1*256 + 5*16 => dividieren durch 256 => 1 + 5/16. Das stimmt also
Danke.
Hallo pah,
soviel vorab – ich bin immer noch im ,,read-only" Modus unterwegs. ;o)
Mir ist in erster Linie wichtig alle notwendigen Daten zu erfassen, verstehen und daraus evtl. Optimierungen/Maßnahmen abzuleiten, ob diese Maßnahmen automatisiert (Stichwort: Pumpensteuerung via Aktor ja/nein? etc.) per FHEM oder manuell (mit Hilfe des vorhandenen Reglers) initiiert werden, ist mir persönlich (noch) nicht wichtig.
Das FHEM EBUS-Modul war/ist eher eine Machbarkeitsstudie/Evaluierung (hier fehlt mir die Möglichkeit, für den ausgewählten get/set Parameter, Werte vorzugeben(Dropdownlist) - aber das nur am Rande.) und keines Falls ein ganzheitlicher Ansatz, wie es dir vor schwebt – es ist max. ein Schritt/Teil von vielen. Ja, ich bin ganz bei dir, das Ändern der Parameter ist damit sehr einfach. Deine Bedenken sind somit nachvollziehbar und berechtigt. Ich sehe FHEM (insbesondere Steuerung der Thermen Betriebsparameter via Ebus) eher als Admin-Werkzeug und gehört, in der aktuellen Fassung, keinesfalls auf ein Tablet im Wohnzimmer.
Mein Schwerpunkt / meine Zielsetzung kurz-/mittelfristig liegt in der Visualisierung (Vorlauf- Rücklauftemp, Heizbetrieb, Betriebsstunden, Pumpe etc.) und Monitoring (Wasserdruck, Verfügbarkeit, Störungen etc.)
-Monitoring Möglichkeiten gibt es bereits out of the box.
-Visualisierung/Info-Panel (sogar Steuerung wäre denkbar/möglich), spiele ich mit dem Gedanken es via RSS-Modul zu realisieren. Aus diversen Gründen (Anpassungen relativ umständlich/aufwändig etc.) halte ich noch Abstand davon.
Fazit: Es bleibt also spannend...
VG Arthur
Hallo zusammen,
nun sind ja schon einige Beiträge seit meinem letzten Post vergangen, aber es ist wieder einiges Interessantes zusammengekommen.
Zitat von: Prof. Dr. Peter Henning am 22 Januar 2015, 06:46:34So könnte man (dummerweise) die Gasart ändern, oder die Vorlauftemperatur auf 150 Grad setzen und die Heizung zerstören. Das ist viel zu riskant. Nicht umsonst schützt Vaillant wichtige Einstellungen bei der manuellen Eingabe (nicht auf dem EBUS) durch (na ja) Passwörter. Und von Fragen der Versicherung ganz zu schweigen.
Ist das wirklich so, d.h. könnte ich über ebusd tatsächlich einen Vorlauf von 150°C einstellen?
Das würde mir ganz und gar nicht gefallen. Ich dachte bisher immer, ich bewege mich hier innerhalb hardwareseitiger Grenzwerte, auf die ich keinen Zugriff habe und auch gar nicht haben will!
Selbst bei Fehlbedienung erwarte ich, dass meine Therme nur so heiß wird wie technisch sicher möglich?
D.h. gebe ich 150°C vor, dann macht die Therme halt maximal 75°C?
ZitatNun könnte man ja noch argumentieren, dass auf dem Raspberry ein separates FHEM laufen kann, das mit der Hauptinstanz über FHEM2FHEM kommuniziert. Das ist aber auch nur telnet.
Zusammengefasst also: ebusd auf einem separaten System, und Zugriff darauf mit ein paar kryptischen telnet Kommandos ist (etwas) sicherer, als das direkt in FHEM einzubauen.
Das ist sicher eine zusätzliche Barriere.
Da man in den csv nur wenige Parameter schreibend freigibt, kann auch nichts über die Grenzen hinaus manipuliert werden.
Andererseits: Hat jemand erst Zugriff auf den Heizungs-Raspi, dann kann er auch die csv-Dateien verändern.
Zitat
Die LED sollte nicht "gerade nicht leuchten" - sondern bei angeschlossenem EBUS ständig flackern, weil die Synchronisationssignale einlaufen.
Was ist nun die optimale Einstellung?
Ich habe meinen so eingestellt, dass die organgene LED ununterbrochen schwach flackert, bisher läuft es reibungslos, aber ca. alle 5-7 Tage muss ich den Raspi rebooten, ebusd läuft noch.
Oder soll ich den Adapter so einstellen, dass die organgene LED nur ab und zu flackert?
Viele Grüße,
Heiko
Nein. Du sollst den Watchdog auf dem Raspberry installieren, der automatisch den ebusd neu startet - und wenn das nicht hilft, den ganzen Raspberry.
Mit Hilfe der "zweiten Diagnosebene" kann man sehr wohl die Betriebsparameter der Therme so verstellen, dass dies gefährlich ist. Und zwar nicht nur für die Hardware, sondern für Menschen.
LG
pah
Was ist die zweite Diagnoseebene? Kommt man mit ebusd da überhaupt ran?
Hat es jemand der mitlesenden auf der Calormatic 470/3 geschafft, die DesiredTemp für Warmwasser zu schreiben?
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,vrc430,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r;w,,hwDesiredTemp,Manuell Solltemperatur,,,,4400,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
liefert bei mir zwar die richtige Anzeige, aber writes mit einer anderen Temp. werden auf der Calormatic nicht angezeigt.
#LIEFERT NUR 0.0
#r,,mcDesiredTemp2,Manuell Solltemperatur,,,,8600,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
liefert bei mir nur 0.0, also keinen an meiner Anlage sinnvollen Wert.
Viele Grüße,
Heiko
Habe ich noch nicht getestet. Bisher setze ich nur Tages- und Nachttemperatur.
Würde gerne erst einmal die Sache mit dem Einfrieren bei fehlendem ebusd ändern. Sowas kann einem beim Produktivsystem den Spaß verderben ;D
schöne Grüße
Jo
@Jojo:
Das kann ich voll nachvollziehen. Ich war damals auch schockiert, weil mein Master-FHEM mittlerweile extrem viel produktive Aufgaben in meinem Haus macht, auch Alarmfunktionen durch 6 Bewegungsmelder inkl. Email-Versand von Bildern von IPCams - ein Absturz darf da wg. der Heizung nicht passieren.
Boris war damals sehr hilfsbereit und konnte mittels Logging auf höchster Detailstufe das Problem eingrenzen.
Vielleicht kannst du ihn kontaktieren, dass ihr auch so vorgeht wie bei mir damals.
Viele Grüße,
Heiko
Ich kann das Problem nicht nachvollziehen.
Bei mir ist das alles abgesichert - gestern habe ich z.B. zufällig einen meiner vier Raspberrys mit derselben IP-Adresse versehen, wie den Heizungs-Raspberry. Resultat ist natürlich, dass der ebusd nicht mehr erreichbar war.
Das merkt sofort ein notify:
define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:Outside.T.*err) { EBUSrecover("notify EBUS.N",0)}Damit wird der Recover-Prozess gestartet. Der fragt bis zu 30x in Abständen von 5 Sekunden nach, ob ein Reconnect erfolgreich ist:
###############################################################################
#
# EBUSrecover
#
###############################################################################
sub EBUSrecover($$)
{
my ($evt,$num) = @_;
Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
if(Value("EBUS") ne "opened"){
if( $num < 30){
$num++;
fhem("set EBUS reopen");
fhem("delete EBUSrecoverdly")
if($defs{"EBUSrecoverdly"});
fhem("define EBUSrecoverdly at +00:00:05 {EBUSrecover('EBUSrecover',$num)}");
}else{
fhem("set Device.warn EBUS")
}
}
}
Wenn das nicht geklappt hat, wird also der Dummy
Device.warn auf "EBUS" gesetzt.
Dieser Dummy ist als alarmSensor für das Modul Alarm gesetzt und löst Folgendes aus:
- Auf meinem 1-Wire FHEM-Display erscheint die Meldung "EBUS ausgefallen"
- Auf meinem digitalen Bilderrahmen erscheint im Meldungskasten der Text "EBUS ausgefallen"
- Mein HomeMatic MP3-Funkgong sagt laut und vernehmlich mit angenehmer Frauenstimme "Achtung, Systemstörung" und beginnt rot zu blinken.
Sonst passiert gar nichts, schon gar kein Absturz oder Einfrieren von FHEM.
Es könnte also sein, dass Euer Problem gar nicht auf Seiten von FHEM existiert, sondern auf Seiten des ebusd.
Bei mir läuft auf dem Raspberry der Watchdog, mit der folgenden Konfiguration /etc/watchdog.conf
max-load-1 = 24
test-timeout = 10
watchdog-device = /dev/watchdog
interval =5
realtime = yes
priority = 1
Im Verzeichnis /etc/watchdog.d steht die Datei ebusd mit dem folgenden Inhalt:
#!/bin/sh
# description: watchdog helper file for ebusd
#echo "Called as ebud $1"
case "$1" in
'test')
#--- Test for ebusd
if [ -s /var/run/ebusd.pid ] ; then
RUN=`ps -ef | grep ebusd.*USB0 | grep -v grep`
if [ "$RUN" != "" ] ; then
#echo "ebusd is already running"
exit 0
else
echo "ebusd defunct at "`date`
exit 1
fi
else
echo "ebusd not running, return 1 at "`date`
exit 1
fi
;;
"repair")
#-- Restarting ebusd
echo "ebusd restarting at "`date`
/etc/init.d/ebusd start
RETVAL=$?
#echo "retval from setting permissions is $RETVAL"
exit 0
;;
*)
exit 0
;;
esac
Et voila: alle 5 Sekunden testet der Watchdog, ob ebusd noch läuft und startet ihn ggf. neu. Probleme damit ? Unbekannt. System kann nur durch trotteliges Vorgehen des Hausherrn gestört werden, siehe oben.
LG
pah
Hi,
danke für das tolle Projekt, speziell an pah!
Ich werde pahs Schaltung löten und auch mit einem raspberry pi arbeiten.
Gibt es noch Änderungen an der Schaltung?
Habe eine Wolf COB Heizung mit BSP Schichtenspeicher, Mischermodul und Solar.
Die 3 Steuerungs Module hatten nicht einmal einen ebus dazwischen, habe ich nachverdrahtet und tut auch.
Weiss jmd. wie lange ein ebus Kabel sein darf? Ich kann das ebus Kabel zum raspberry ja an eine belegte ebus Klemme parallel anschliessen, oder?
Welches Linux empfehlt ihr für den raspberry pi? Solle man die vorinstallierte SD Karte nehmen oder besser runterladen?
Werde den raspberry pi B+ bestellen
Gruss Joachim
Keine Änderungen an der Schaltung, summt schön vor sich hin. Ich wünschte nur, ich hätte sie als Aufsatzplatine für den Raspberry gelötet - in dem Hutschienengehäuse ist nämlich noch massig Platz.
Klar ist der parallele Anschluss ok. Ich habe das getestet mit einem 10 m Fernmeldekabel (4 Adern geschirmt), tat bestens.
LG
pah
Danke für die schnell Antwort pah,
Platz ist kein Problem, aber eigentlich wollte ich so eine Rasterplatine nehmen, die dürfte etwas gross als Pi Aufsatz sein
LG
Joachim
Zitat von: Prof. Dr. Peter Henning am 26 Januar 2015, 05:45:15
Ich kann das Problem nicht nachvollziehen.
Bei mir ist das alles abgesichert - gestern habe ich z.B. zufällig einen meiner vier Raspberrys mit derselben IP-Adresse versehen, wie den Heizungs-Raspberry. Resultat ist natürlich, dass der ebusd nicht mehr erreichbar war.
Das merkt sofort ein notify:
define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:Outside.T.*err) { EBUSrecover("notify EBUS.N",0)}
[...]
LG
pah
Hallo,
das ist ja soweit auch alles gut beschrieben und ich würde es gerne umsetzen. Allerdings scheitert es nicht am ebusd-raspi, sondern daran, dass mein fhem ein disconnect gar nicht mitbekommt. Es friert mit Status "connected" schon ein. Ich habe einen timer, der jede Minute "einige" Werte abruft. Das waren 27. Habe das jetzt mal testweise komplett entfernt, was aber nicht geholfen hat. Es wird also zum Zeitpunkt des Stoppens kein Wert abgerufen. Selbst ein Restart des ebusd hilft nicht. Kaum hatte ich zur Fehlersuche mal global verbose auf 5 gesetzt, lief es ohne Absturz. Dann wieder verbose 2, Absturz. Ok, das wird jetzt wohl eher nichts damit zu tun haben, aber es scheint so, als würde es mal gehen und mal nicht.
Ich teste mal weiter.
schöne Grüße
Jo
Hallo ebusd Fans,
ich habe eine Bitte an die RPi User, bei denen der ebusd auf nem RPi läuft:
In meinem fork auf github (https://github.com/john30/ebusd.git) habe ich das Logging vom ebusd schlanker und direkter gemacht und ich würde nun gerne wissen, wie sich das auf dem RPi bemerkbar macht. Mir fehlt leider die Zeit, meinem die notwendige HW für den Buszugriff und das passende Image auf SD zu spendieren.
Insofern wäre es super, wenn das der ein oder andere mal compilieren und nen Tag lang laufen lassen könnte.
Noch was anderes zu einem älteren Beitrag:
"BADID" stammt definitiv nicht aus den Internas vom ebusd, sondern schlicht aus dem Register des adressierten Slaves. Es wurde ja gemunkelt, dass das evtl. eine ungültige CRC oder sowas sein könnte. Das ist es sicher nicht, da bei einer falschen CRC laut eBUS Protokoll der Transfer höchsten ein Mal wiederholt wird und beim erneuten CRC Fehler wird die Nachricht als nicht übermittelt eingestuft. Darauf nimmt ebusd ja Rücksicht.
Nachdem hier auch über Zugriffsrechte und potentielle Beschädigung der Komponenten durch fehlerhafte Writes auf dem Bus geredet wurde:
Ich überlege, ob es sinvoll wäre, jeder Nachricht einer CSV Config Datei eine Sicherheitsstufe zu verpassen. So könnte bspw. "0" (oder keine Stufe) für "das darf jeder" stehen, "1" für Zugriff erst nach Übermittlung der PIN in der Client-Connection zum ebusd (oder so ähnlich). Somit hätte man zumindest ein bisschen Sicherheit und wer keinerlei Nachrichten einer Stufe>0 haben will, könnte diese per Kommandozeilen Option vom ebusd ganz aus der Config nehmen lassen.
@john30: ich kann irgendwohin die binary data (raw dump file) uploaden, dann kann man ebusfeed benutzen. Gib mir ein Bescheid.
Hallo,
irgendwie schaffe ich es nicht, einen nicht-numerischen Rückgabewert des ECMDDevices per ReadingsVal zu erfassen.
Folgendes passiert z.B. im event Monitor:
2015-01-28 19:52:53.632 ECMDDevice HK.Hz BAI00.HCCirculationPump off
2015-01-28 19:52:53.830 ECMDDevice HK.Hz BAI00.HCPowerInteralPump: 15.00 W
Daraufhin habe ich folgendes notify erstellt:
define n_HCInternalPump notify HK.Hz:.* {\
if (ReadingsVal("HK.Hz", "BAI00.HCCirculationPump", "") eq "off"){\
...
Das event wird erkannt, aber die if-Bedingung wird ignoriert. Hat dazu jemand eine Idee? Liegt es am fehlenden Doppelpunkt im event?
schöne Grüße
Jo
Hallo Jojo11,
wie sehen die Readings bzw. der Reading-Wert BAI00.HCCirculationPump am HK.Hz Device aus? (->list).
Wie geht dein Noftify weiter? Ich sehe nur {if(){ ... damit fehlt etwas...
Beachte auch, dass der Reading-Wert evtl. "\n" beinhaltet - ist deine classdef sauber (habe da bisher keine Erfahrung mit ECMD).
Vielleicht hilft es.
VG
Danke für die Hinweise, das werde ich mal testen. Der Zeilenumbruch könnte es sein.
schöne Grüße
Jo
Ich empfehle doch sehr, die ECMD-Returns nicht in einem FHEM-Skript, sondern in einem echten Perl-Unterprogramm abzuarbeiten und dort den Rückgabewert vor der Verarbeitung von solchem Kram zu befreien.
LG
pah
Es war der doppelte Umbruch. Danke nochmal! Mangels Zeit und Erfahrung muss ich das im Moment leider in fhem machen, auch wenn Du natürlich recht hast. Wenn erstmal alles grob läuft werde ich das mal angehen.
schöne Grüße
Jo
@john30
Danke für die neuen Sourcen. Ich habe alles auf meinen Raspberry installiert und setze nun den neuen ebusd ein. Ich lasse da so wie von dir gewünscht nun ein paar Tage laufen. Es laufen zyklische Abfragen und auch mehrmals täglich Befehle aus Fhem (Heizkurve) darüber.
Ich muss aber sagen, dass ich bisher auch keine Probleme mit der Betaversion gehabt habe, solange ich den ebusd bei laufendem Fhem nicht ständig stoppe und wieder starte.
Die neue Binary ist nun statt 2,7 Mb nur mehr 2,3 Mb groß.
Falls wer nicht alles neu compilieren und installieren möchte, hänge ich nur die (Test) ebusd von john30 seine Sourcen hier mit an, ich hoffe das passt so. Compiliert am Raspberry B+.
LG
Reinhart
Zitat von: Jojo11 am 28 Januar 2015, 22:02:26
Es war der doppelte Umbruch. Danke nochmal! Mangels Zeit und Erfahrung muss ich das im Moment leider in fhem machen, auch wenn Du natürlich recht hast. Wenn erstmal alles grob läuft werde ich das mal angehen.
schöne Grüße
Jo
$result =~ s/\n//g; sollte eigentlich schon helfen alle Umbrüche (ebusd liefert mehrere) zu entfernen (das verwende ich in meinem EBUS Modul - bisher zuverlässig - bevor ich die readings schreibe).
VG
Ich habe jetzt meinen eBus Heizkurvenregler schon einige Zeit in Betrieb und es funktioniert alles sehr gut.
Basiswert ist die Wichtung "Valves" und über Setlist wird ein Schwellwert (bei mir 95) vorgegeben ab wo die Steuerung eingreifen soll. Mit einfachen IF Abfragen wird der Schwellwert alle 30 Minuten überprüft und gegebenenfalls via eBus die Heizkurve angehoben bzw. abgesenkt.
Die Heizkurve wird zwischen 0.9 bis 1.2 automatisch den Ventilanforderungen (Valves/Wichtung) angepasst.
Früher hatte ich eine fixe Heizkurve mit 1.1 eingestellt, was natürlich einen höheren Gasverbrauch mit sich brachte. Ich spare jetzt (nach einer Woche Beobachtung) mit Hilfe des automatischen eBus Reglers bis zu 2 m³ Gas pro Tag.
Somit ist für mich der eBus und dieses Projekt eine ganz tolle Sache die wirklich was bringt!
Während der gesamten Testphase (ab dem Zeitpunkt wo ich nicht mehr ständig stoppe/starte) läuft er sehr stabil und ich hatte keinen einzigen Freeze von Fhem mehr. Ich kann aber die Probleme von heikoh sehr gut nachvollziehen, denn selbst ein Watchdog kann da keine Abhilfe mehr schaffen.
Unten im Bild sieht man schön wie sich die automatische Vorlaufregelung (Heizkurve) der Ventilstellung der Heizkörper anpasst und entgegen wirkt. Ab 4:30 Uhr wir die Therme hochgefahren und die erforderliche Leistung ab dann optimal nachgeregelt.
LG
Hallo,
was ich nicht verstehe: Warum variierst Du nicht die Solltemperatur? Das entspricht einer Parallelverschiebung der Heizkurve bei gleichbleibender Steigung.
schöne Grüße
Jo
@Jojo11
im Prinzip habe ich eine Parallelverschiebung vorher gehabt. In Zeiten wo man den eBus noch nicht auslesen konnte, da habe ich im Außentemperaturfühler per FS20 einen Widerstand mit 100 Ohm vorgeschaltet, somit täuschte ich eine tiefere Außentemperatur vor und die Kurve verschob sich.
Ich glaube (vielleicht bilde ich mir das aber nur ein) das ich mit der direkten Steuerung der Heizkurve besser abschneide, weil ich somit die Kurve abflache und somit noch weniger Energie bei angenommener gleichbleibender Außentemperatur benötige.
Ein Heizkurvenwert von 0.9 wäre bei meinem 3-stöckigen Wohnhaus nicht möglich, aber mit Hilfe der automatischen Heizkurvenverstellung geht das nun leicht.
Genaue Aussagen über die tatsächliche Einsparung sind nur über längerem Zeitraum möglich, da sie sehr viel von den Umweltbedingungen abhängt. Im Augenblick ist es sehr günstig, da wir seit einer Woche in etwa die gleichen Bedingungen haben, in der Nacht unter Null und am Tag bis zu 4 Grad bei schwachem Wind.
Aber ich kann auch einmal deine vorgeschlagene Methode testen ob hier noch Unterschiede betreffend Einsparung sind.
schöne Grüße
Reinhart
Ok. Wenn ich soweit bin werde ich mich auch mal an eine solche Regelung wagen. Bisher kämpfe ich noch mit dem ebusd :)
schöne Grüße
Jo
Zitat von: joachimS am 26 Januar 2015, 11:48:36
Weiss jmd. wie lange ein ebus Kabel sein darf? Ich kann das ebus Kabel zum raspberry ja an eine belegte ebus Klemme parallel anschliessen, oder?
Ja, einfach Parallel anschließen.
Ich habe aus der Heizung ein normales 3-adriges Feuchtraumkabel herausgeführt, in ein IP67-Aufputz-Hutschienen-Gehäuse mit 12 Plätzen (von Pollin: http://www.pollin.de/shop/dt/MjU0OTQ0OTk-/Haustechnik/Installationsmaterial/Dosen_Verteiler/Feuchtraum_Kleinverteiler_PCE_T_Box_12.html) (http://www.pollin.de/shop/dt/MjU0OTQ0OTk-/Haustechnik/Installationsmaterial/Dosen_Verteiler/Feuchtraum_Kleinverteiler_PCE_T_Box_12.html))
Die bauseits vorhandene Leitung ins Wohnzimmer zur Calormatic dürfte auch so 12-20m lang sein, ungeschirmt, keine Ahnung wie das im Haus verläuft.
Ich habe am ebus-Adapter aber bemerkt, dass schon die kleinste Längenveränderung ein Neueinstellen des Potis erfordert.
Weiß gar nicht, wie das Vaillant macht, weil da muss man nichts von Hand kalibrieren und Vaillant weiß vorher ja auch nicht, wie lange die Leitungen im Haus sind.
ZitatWelches Linux empfehlt ihr für den raspberry pi? Solle man die vorinstallierte SD Karte nehmen oder besser runterladen?
Werde den raspberry pi B+ bestellen
Raspbian, am stabilsten, als Debian-Fork häufig mit Updates versorgt.
Ich würde das Geld nicht für eine vorbespielte SD-Karte ausgeben, lieber gezielt eine Class10 von Sandisk kaufen und mit Win32DiskImager selber flashen.
Es ist sehr einfach, und es gibt viele Tutorials dazu.
Allerdings muss ich sagen, dass ich schon 6 Raspis einsetze und das ganze deshalb mittlerweile leicht von der Hand geht.
Viele Grüße,
Heiko
Hallo!
Ich muss leider nochmals das alte Thema "eBus Dämon starten" aufgreifen!
Ich wollte heute den Dämon aktiveren (habe bis jetzt händisch gestartet) und hier so meine Wunder erlebt.
Nach viel lesen habe ich es zwar geschafft den eBus zumindest nach Neustart automatisch zu starten, aber die Probleme liegen beim Pidfile. Hier fehlen die Rechte im /run/ und das File kann nicht geschrieben werden, selbst wenn mit sudo gestartet wird.
ich starte so:
sudo ./ebusd.debian start
und erhalte auch "ok". Tatsächlich läuft auch der Dämon.
pi@raspberry2 ~ $ ps -aux|grep ebusd
warning: bad ps syntax, perhaps a bogus '-'?
See http://gitorious.org/procps/procps/blobs/master/Documentation/FAQ
root 2141 0.4 0.2 36260 1316 ? Ssl 16:28 0:08 /usr/local/bin/ebusd -l All -d /dev/ttyUSB0 -p 8888
aber es wird nirgends ein Pidfile angelegt, bzw wenn ich den Originalpfad des Pidfiles lasse, dann wird es angelegt aber mit 0 Byte Länge (weil er vermutlich selbst nicht schreiben kann).
pi@raspberry2 /etc/init.d $ sudo ./ebusd.debian status
read Config: /etc/default/ebusd
[FAIL] could not access PID file for ebusd ... failed!
mit der Statusabfrage kommt dann ein Fehler, weil nichts gelesen werden kann. Stop funktioniert aber wieder und beendet den ebusd.
Ich habe auch schon versucht den Pfad des Pidfiles umzulegen, es wird aber in diesem Pfad kein File angelegt obwohl ich Rechte und Besitzer auf "pi" geändert habe.
sudo mkdir /var/run/ebus
sudo chown pi:pi /var/run/ebus
folgende Pfade habe ich diesbezüglich in Verwendung:
/etc/default/ebusd (Konfiguration für ebusd)
/etc/init.d/ebusd.debian (Dämon Start-Stop-Script)
/etc/logratate.d/ebusd (Configs für das Logfile)
/usr/local/bin (hier liegen die 3 Binary)
und nachdem die Files alle dort liegen habe ich noch das Runlevel Script aktualisiert (wichtig damit Dämon nach Reboot auch startet)
cd /etc/init.d
sudo update-rc.d ebusd.debian defaults
Die genaue Struktur und der Inhalt der Scripte/Configs ist im Anhang.
Im Prinzip ist es mir fast egal, denn nach Netzausfall oder sonstiges startet der Raspi ja nun schon den eBus Dämon automatisch, nur mit einem Watchdog geht es in die Hose weil hier das Pidfile ausgelesen werden muss und genau diese Funktion passt noch nicht.
'test')
#--- Test for ebusd
if [ -s /var/run/ebusd.pid ] ; then
RUN=`ps -ef | grep ebusd.*USB0 | grep -v grep`
if [ "$RUN" != "" ] ; then
#echo "ebusd is already running"
Ich glaube ich bin nicht der einzige, der hier Probleme hat.
Hat dieses Problem des Pidfiles schon jemand gelöst und kann mir hier weiterhelfen?
Liebe Grüße
Reinhart
ein Teil ist mir nun schon klar, der Pfad für das Pidfile ist hardcoded in den Sourcen hinterlegt, daher kann man den Pfad nicht ändern.
LG
Aufgrund der hardcoded Sache und dem Rechtefehler des Pidfiles habe ich jetzt das Start- Stop Script abgeändert. Die Rechte werden jetzt gesetzt, die ProzessID richtig geschrieben und der Dämon somit auch richtig gestoppt. Es funktioniert zwar soweit, aber ein endgültige Lösung ist das sicher nicht.
#!/bin/sh
### BEGIN INIT INFO
# Provides: ebusd
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Start ebusd
### END INIT INFO
# modified by Reinhart, changed User rights in the Pidfile
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
if test -f /etc/default/ebusd; then
. /etc/default/ebusd
echo "read Config: /etc/default/ebusd"
fi
. /lib/lsb/init-functions
DAEMONUSER=root
DAEMON=/usr/local/bin/ebusd
PIDFILE=/var/run/ebusd.pid
test -x $DAEMON || exit 5
case $1 in
start)
if [ -e $PIDFILE ]; then
if $0 status > /dev/null ; then
log_success_msg "$DESC already started; not starting."
return
else
log_success_msg "Removing stale PID file $PIDFILE."
rm -f $PIDFILE
fi
fi
log_daemon_msg "Starting ebusd" "ebusd"
start-stop-daemon --start --quiet --pidfile $PIDFILE --user $DAEMONUSER --exec $DAEMON -- $EBUSD_OPTS
status=$?
log_end_msg $status
if [ -e $PIDFILE ]; then
chown $DAEMONUSER $PIDFILE
chgrp $DAEMONUSER $PIDFILE
chmod 644 $PIDFILE
pidof ebusd >$PIDFILE
fi
echo "ebus daemon is started"
;;
stop)
log_daemon_msg "Stopping ebusd" "ebusd"
start-stop-daemon --stop --retry 5 --quiet --oknodo --pidfile $PIDFILE --user $DAEMONUSER
log_end_msg $?
echo "ebus daemon is stopped"
rm -f $PIDFILE
;;
restart|force-reload)
$0 stop && sleep 2 && $0 start
;;
status)
status_of_proc $DAEMON "ebusd"
;;
*)
echo "Usage: $0 {start|stop|restart|force-reload|status}"
exit 2
;;
esac
modifiziertes File /etc/init.d/ebusd.debian für den Dämon Start.
Warum das doch bei einigen am Raspberry läuft verstehe ich immer noch nicht, aber bei mir läuft jetzt der Dämon somit richtig.
LG
Das Problem hatte ich auch. Du musst den Status auch mit sudo abrufen. Der daemon läuft ;)
schöne Grüße
Jo
@Reinhart:
Danke für das Testen auf dem RPi.
Hast Du das PID-File Problem mit meinem Fork oder mit Rolands?
@MilanK:
Danke für das Angebot. Ein Dump File hilft hier nicht wirklich, weil das Timing daraus nicht ersichtlich wird und das ist das einzig wichtige. Besser wäre, den ebusd eine gewisse Zeit lang laufen zu lassen und im Log nach Problemen zu suchen. Insbesondere vermehrte arbitration losses wären ein Hinweis auf einen potentiellen Kapazitäts-Engpass.
Zitat von: john30 am 31 Januar 2015, 08:55:13
@Reinhart:
Danke für das Testen auf dem RPi.
Hast Du das PID-File Problem mit meinem Fork oder mit Rolands?
ich habe das in folgender Reihenfolge installiert:die ursprüngliche Ebus-master, dann die Beta 5.x und dann habe ich deine Version compiliert und nur die die Binary "ebusd" ausgetauscht. Die Pid Probleme waren bei allen 3 Versionen gleich.
Es wird das Pidfile in
/run/ebus.pid mit Rechten "600" angelegt mit Null Byte, d.h. es wird nicht mit der ProzessID befüllt. Das ist auch der Grund, warum dann auch kein Restart und Stop funktioniert. Passt man hier bei vielen Restarts nicht auf, dann laufen bis zu 10 ebus Prozesse oder mehr. Das ist der Grund, warum ich jetzt die Dämon Startroutine bei mir geändert habe.
starten mache ich immer so:
cd /etc/init.d
sudo ./ebusd.debian start
sudo ./ebusd.debian stop
sudo ./ebusd.debian restart
Ich habe die Bezeichnung ebusd.debian zum testen so belassen, dann weiß ich genau was ich da starte, sonst gibt es sehr viele gleiche Namen wie die Binary etc.
Ich habe mich aber erst seit gestern mit dem Dämon beschäftigt, weil ich den eBus-Raspi Netzausfallsicher (nach dem Reboot ebusd Dämon starten) machen wollte. Gestern hatte ich natürlich Hänger im Fhem, durch ständiges abwürgen der ebusd mit kill -9, da funktioniert auch oft kein SSH mehr sondern nur mehr Power Off/On. Seit ich aber mit "meiner" Startroutine fertig bin und frisch gebootet habe läuft alles wieder bestens.
Du siehst ja in dem geänderten Dämonscript wo ich eingegriffen habe, Rechte setzen und mit Pidof die PorzessId ins Pidfile schreiben. Mir ist es auch erst klar geworden nachdem ich C Sourcen von dem ebusd mir angesehen habe. Offensichtlich klappt es aber doch bei vielen, denn außer heikoh und milan aus dem KNX-Forum geht es ja anscheinend bei den andern sofern die schon mit der Implementierung so weit sind.
PS: ich kann aber gerne noch was testen wenn du möchtest!
LG
Zitat von: Jojo11 am 31 Januar 2015, 00:27:12
Das Problem hatte ich auch. Du musst den Status auch mit sudo abrufen. Der daemon läuft ;)
schöne Grüße
Jo
klappt so leider nicht (siehe oben) weil dann keine ProzessID im Pidfile steht! File wird immer mit 0 Byte angelegt und kann mit "stop" nicht mehr gelöscht werden.
LG
Reinhart
Zitat von: Reinhart am 31 Januar 2015, 11:19:34
Es wird das Pidfile in /run/ebus.pid mit Rechten "600" angelegt mit Null Byte, d.h. es wird nicht mit der ProzessID befüllt. Das ist auch der Grund, warum dann auch kein Restart und Stop funktioniert. Passt man hier bei vielen Restarts nicht auf, dann laufen bis zu 10 ebus Prozesse oder mehr. Das ist der Grund, warum ich jetzt die Dämon Startroutine bei mir geändert habe.
Habs gerade gefixt (in john30): PID file ist jetzt für alle lesbar und nicht mehr leer und wird in $(prefix)/var angelegt.
Danke john30, werde das am späteren Nachmittag gleich testen!
Momentan scheint die Sonne und ich muss rauß!
LG
Reinhart
@john30
wollte dir kurze Rückmeldung geben: ebusd Dämon läuft nun auf dem Raspi tadellos und das Pidfile Problem ist erledigt!
Habe es so installiert:
nach /home/pi entpacken: https://github.com/john30/ebusd/archive/master.zip
cd /home/pi/ebusd.master
sudo ./autogen.sh
sudo make
sudo make install
sudo cp /home/pi/ebusd-master/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd (Dämonstartfile kopieren)
sudo chmod 755 /etc/init.d/ebusd (Script Rechte setzen, wenn es via PC kopiert wurde)
sudo update-rc.d ebusd defaults (Runlevel Script aktualisieren)
habe den Raspi dann rebootet und getestet. Dämon wird automatisch gestartet und das Pidfile inkl. PID ist vorhanden. Bei Stop wird es gelöscht und auch der Restart funktioniert nun perfekt.
Besten Dank für deine rasche und kompetente Umsetzung!
Liebe Grüße
Reinhart
@Reinhart:
Prima, das freut mich!
Eigentlich sollten jetzt alle user das PID file lesen dürfen, also "sudo cat /var/run/ebusd.pid" sollte ohne Probleme durch "cat /var/run/ebusd.pid" zu ersetzen sein.
Auch autogen und make sollten noch ganz gut ohne su klappen. Ab "make install" brauchts natürlich super Rechte.
LG John
normale User haben noch keine Rechte, hier der Test:
pi@raspberry2 /var/run $ cat /var/run/ebusd.pid
cat: /var/run/ebusd.pid: Keine Berechtigung
pi@raspberry2 /var/run $ ls -al ebusd*
-rw------- 1 root root 5 Jan 31 16:07 ebusd.pid
pi@raspberry2 /var/run $
also kann ein User nicht lesen sondern nur Root!
und so sehen die anderen bei mir aus:
-rw-r--r-- 1 root root 5 Jan 31 16:07 dhclient.wlan0.pid
-rw------- 1 root root 5 Jan 31 16:07 ebusd.pid
-rw-r--r-- 1 root root 5 Jan 31 16:07 ifplugd.eth0.pid
-rw-r--r-- 1 root root 5 Jan 31 16:07 ifplugd.lo.pid
-rw-r--r-- 1 root root 5 Jan 31 16:07 ifplugd.wlan0.pid
-rw-r--r-- 1 root root 5 Jan 31 16:07 inetd.pid
LG
@Reinhart:
Werden die Rechte des PID Files durch Dein init Script noch verändert?
Bei mir hatte das File wie erwartet 0644, also für jeden lesbar.
Was gibt denn "umask" bzw. "sudo umask" bei Dir aus?
@john30
Nein, habe jetzt dein Original Script verwendet, es ist eigentlich alles von dir vom letzten Download und Compile.
pi@raspberry2 /run $ umask
0022
LG
@Reinhart:
Rätsel gelöst, es hat noch "/run" im Pfad des via autoconf eingestellten PID Files gefehlt. Das File wurde dadurch fälschlicherweise unter /usr/local/var/ebusd.pid abgelegt (sofern das Verzeichnis existiert).
Jetzt wandert es in /usr/local/var/run/ebusd.pid oder mit "./autogen.sh --localstatedir=/var" wie gewünscht in "/var/run/ebusd.pid".
LG John
Zitat von: john30 am 31 Januar 2015, 08:58:54
@MilanK:
Ein Dump File hilft hier nicht wirklich, weil das Timing daraus nicht ersichtlich wird und das ist das einzig wichtige. Besser wäre, den ebusd eine gewisse Zeit lang laufen zu lassen und im Log nach Problemen zu suchen.
Ach so. Ich benutze Arch Linux auf RPi B+, speichere beide Log und Dump auf Netzplatte (solange durch sshfs, später plane ich Samba dafür) und ich sehe keine Probleme (I/O, CPU).
@John
habe das jetzt so gemacht wie du geschrieben hast und die autogen mit den Parametern aufgerufen, hat sich aber nichts geändert dadurch.
das Pidfle liegt ja schon korrekt in der /run und wird ja auch richtig beschrieben, da kann ich dir jetzt gedanklich nicht folgen.
Du brauchst dich jetzt aber nicht mehr bemühen, funktionieren tut es ja schon.
Ich bin aber gerne bereit weiter zu testen wenn du es benötigst. Oder hätte ich nochmals die Files vom Git holen müssen?
LG
Reinhart
hier noch die autogen, da gabs ein Warning.
pi@raspberry2 ~/ebusd-master $ sudo ./autogen.sh --localstatedir=/var
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking dirent.h usability... yes
checking dirent.h presence... yes
checking for dirent.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking poll.h usability... yes
checking poll.h presence... yes
checking for poll.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking termios.h usability... yes
checking termios.h presence... yes
checking for termios.h... yes
checking for pthread_setname_np in -lpthread... yes
checking for pselect... yes
checking for ppoll... yes
checking for doxygen... no
configure: WARNING: Doxygen not found - continuing without Doxygen support.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking dependency style of g++... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for ranlib... ranlib
checking whether make supports nested variables... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating docs/Makefile
config.status: creating src/lib/utils/Makefile
config.status: creating src/lib/ebus/Makefile
config.status: creating src/lib/ebus/test/Makefile
config.status: creating src/ebusd/Makefile
config.status: creating src/tools/Makefile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing depfiles commands
pi@
@MilanK:
Zitat von: MilanK am 31 Januar 2015, 19:38:39
... und ich sehe keine Probleme (I/O, CPU).
Super, vielen Dank für die Info!
@Reinhart:
Zitat von: Reinhart am 31 Januar 2015, 20:15:00
hier noch die autogen, da gabs ein Warning.
pi@raspberry2 ~/ebusd-master $ sudo ./autogen.sh --localstatedir=/var
...
checking for doxygen... no
configure: WARNING: Doxygen not found - continuing without Doxygen support.
...
Das macht nichts, dann bekommst Du halt nicht die Source-Code Dokumentation :-)
@Reinhart:
Zitat von: Reinhart am 31 Januar 2015, 20:09:30
@John
habe das jetzt so gemacht wie du geschrieben hast und die autogen mit den Parametern aufgerufen, hat sich aber nichts geändert dadurch.
das Pidfle liegt ja schon korrekt in der /run und wird ja auch richtig beschrieben, da kann ich dir jetzt gedanklich nicht folgen.
Du brauchst dich jetzt aber nicht mehr bemühen, funktionieren tut es ja schon.
Ich bin aber gerne bereit weiter zu testen wenn du es benötigst. Oder hätte ich nochmals die Files vom Git holen müssen?
Also eigentlich konnte es vorher noch nicht stimmen, weil "/run" im Pfad gar nicht enthalten war. Insofern bin ich etwas überfragt, warum bei Dir ohne frisches git pull das PID file unter /run/ebusd.pid vom binary erstellt wird. Bist Du sicher, dass das nicht ein init script tut?
LG John
Zitat von: heikoh81 am 24 Januar 2015, 20:06:57
Ist das wirklich so, d.h. könnte ich über ebusd tatsächlich einen Vorlauf von 150°C einstellen?
Das würde mir ganz und gar nicht gefallen. Ich dachte bisher immer, ich bewege mich hier innerhalb hardwareseitiger Grenzwerte, auf die ich keinen Zugriff habe und auch gar nicht haben will!
Selbst bei Fehlbedienung erwarte ich, dass meine Therme nur so heiß wird wie technisch sicher möglich?
D.h. gebe ich 150°C vor, dann macht die Therme halt maximal 75°C?
Ja, das ist wirklich so, man kann die 150 ° vorgeben.
Allerdings gibt es in der Therme einen Hardwareschutz "Sicherheitstemperaturbegrenzer (kurz STB). Der löst bei Übertemperaturen, in der Regel bei 110° aus.
Es reicht aber schon wenn ein bösartiger Mensch die Speicherladetemperatur auf 90° setzt oder den Legionellenschutz aktiviert.
Da kommen dann 90° aus dem Wasserhahn.
Fakt ist, das der ebusd über Telnet im heimischen Netzwerk hängt.
Jedem sollte schon klar sein, das alles was in der *.cfg parametriert ist auch über Telnet zugänglich und veränderbar ist.
Die *.cfg liegen aber in /etc/ebusd und sollten normalerweise dort nur vom root änderbar sein.
Ich hatte hier ja schon mal nach SSH gefragt, da allerdings eine recht rüde Antwort bekommen.
Jeder kann mit einem einfachen Scan feststellen wie viele Fritzboxen noch nicht gepatcht sind.
Hat man seinen Raspberry hinter so einer nicht gepatchten Box im Homenetz und setzt eine der *.csv mit allen set-Befehlen ein, ist das hochgradig leichtsinnig.
@kawa0815:
Wenn Dir der Transport der Daten über eine Klartext-Verbindung in Deinem Netz nicht sicher genug ist, kannst Du das ja völlig problemlos über SSH Tunneln (ebusd mit Option "--localhost" starten). Dafür braucht niemand irgendeinen Code ändern.
Die Sicherheit der Config Files liegt ja auch in Deinen Händen. Und ganz ehrlich: Wenn man eine Fritzbox dafür verwendet, dann öffnet man natürlich potentiell Tür und Tor für böswillige Leute.
Ganz abgesehen davon ist alles, was wir mit ebusd anstellen, generell gefährlich für die Anlage, weil wir in ein an sich geschlossenes System eingreifen. Darüber sollte man sich schon im Klaren sein.
LG John
@John
habe alles nochmals gecheckt, aber entscheidend ist eigentlich nur /etc/init.d und hier liegt deine Dämonstartroutine!
Auch in .depend.start ist nur der "ebusd" eingetragen. meine ursprünglichen Files mit Namen "ebusd.debian" habe ich auch alle gelöscht.
Ich habe auch das letzte Firmware-Update auf beiden Raspi mit 3.18.5 drauf.
pi@raspberry2 /etc/init.d $ uname -a
Linux raspberry2 3.18.5+ #744 PREEMPT Fri Jan 30 18:19:07 GMT 2015 armv6l GNU/Linux
wegen /run, das ist auf dem Raspi ja ein Link auf /var/run, deshalb vermute ich hat er es vorher auch schon gefunden. Das eigentliche Problem war ja nicht der Pfad, sondern nach dem Anlegen war es nicht mehr beschreibbar. Dies Problem hast du ja schon in der vorletzten Version schon gefixt.
pi@raspberry2 /var $ ls -al
insgesamt 102444
drwxr-xr-x 11 root root 4096 Jun 20 2014 .
drwxr-xr-x 23 root root 4096 Jan 31 18:12 ..
drwxr-xr-x 2 root root 4096 Jan 14 06:25 backups
drwxr-xr-x 10 root root 4096 Jan 1 1970 cache
drwxr-xr-x 39 root root 4096 Jan 1 1970 lib
drwxrwsr-x 2 root uucp 4096 Apr 30 2014 local
lrwxrwxrwx 1 root root 9 Jan 1 1970 lock -> /run/lock
drwxr-xr-x 8 root root 4096 Feb 1 06:25 log
drwxrwsr-x 2 root mail 4096 Jun 20 2014 mail
drwxr-xr-x 2 pi root 4096 Jan 30 15:38 opt
lrwxrwxrwx 1 root root 4 Jan 1 1970 run -> /run
drwxr-xr-x 4 root root 4096 Jan 1 1970 spool
-rw------- 1 root root 104857600 Jun 20 2014 swap
drwxrwxrwt 2 root root 4096 Apr 30 2014 tmp
pi@raspberry2 /var $
Vergiss bitte nicht die Version noch zu korrigieren, damit keine Verwechslungen mehr aufkommen, die steht noch auf 0.5.0!
pi@raspberry2 /var $ ebusd -V
ebusd 0.5.0
Auf jeden Fall danke nochmals für deinen Fix, der Dämon funktioniert bei meinem Raspi nun bestens!
Vielleicht testet heikoh das jetzt auch nochmals, bei dem hat es ja auch nicht funktioniert.
schöne Grüße
Reinhart
Zitat von: kawa0815 am 01 Februar 2015, 10:23:55Ich hatte hier ja schon mal nach SSH gefragt, da allerdings eine recht rüde Antwort bekommen.
Wie anderen gesagt haben: start ebusd mit --localhost um die anderen Computern am LAN zu blockieren. Dann benutz einfach:
[ ich@irgendwo_in_lan ]$ ssh user@ebus_comp ebusctl read OutsideTemp
1.062Man kann auch ein SSH Schlüssel verwenden so dass keine Passwort nötig ist. Es is auch möglich die SSH Komandos weiter zu beschränken mit "command" in $HOME/.ssh/authorized_keys, um z.B. "ebusctl write -h" nicht zu benutzen können.
http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding
Ja, est kann ein bischen Overkill für ebusd Computer sein...
Weiß jemand, ob dass möglich ist, die bestehende Leistung der Therme in kW abzulesen? (Vaillant / Protherm)
I habe nichts im Servicehandbuch (die Koden d.XX ) gefunden - nur die maximale Leistungbegrenzung. Doch, das Thermedisplay zeigt bis zu 5 Stuffen.
(Als Umgehung des Problems könnte ich wahrscheinlich die Gebläsedrehzahl kalibrieren.)
Diese Leistung ergibt sich doch ganz automatisch aus dem Gasverbrauch pro Zeiteinheit.
LG
pah
Zitat von: MilanK am 01 Februar 2015, 12:08:48
Weiß jemand, ob dass möglich ist, die bestehende Leistung der Therme in kW abzulesen? (Vaillant / Protherm)
I habe nichts im Servicehandbuch (die Koden d.XX ) gefunden - nur die maximale Leistungbegrenzung. Doch, das Thermedisplay zeigt bis zu 5 Stuffen.
(Als Umgehung des Problems könnte ich wahrscheinlich die Gebläsedrehzahl kalibrieren.)
Genau diese Info hätte ich auch noch gerne.
Das kleine Display in der ecotec zeigt die Info als Balken links an (genauso wie den Druck rechts), aber es gibt in der Fachhandwerker-Ebene dafür auch keinen Menüpunkt.
Gasverbrauch-Anzeige hat meine Heizung nicht.
Zitat von: kawa0815 am 01 Februar 2015, 10:23:55
Ja, das ist wirklich so, man kann die 150 ° vorgeben.
Allerdings gibt es in der Therme einen Hardwareschutz "Sicherheitstemperaturbegrenzer (kurz STB). Der löst bei Übertemperaturen, in der Regel bei 110° aus.
Es reicht aber schon wenn ein bösartiger Mensch die Speicherladetemperatur auf 90° setzt oder den Legionellenschutz aktiviert.
Da kommen dann 90° aus dem Wasserhahn.
Fakt ist, das der ebusd über Telnet im heimischen Netzwerk hängt.
Jedem sollte schon klar sein, das alles was in der *.cfg parametriert ist auch über Telnet zugänglich und veränderbar ist.
Die *.cfg liegen aber in /etc/ebusd und sollten normalerweise dort nur vom root änderbar sein.
Ok, das hilft schon weiter.
Eine hardware-seitiger Thermeschutz (Bimetall, wie auch immer) muss ganz sicher vorhanden sein, die Elektronik kann ja immer mal ausfallen, Werte falsch melden etc.
Die Warmwasser-Temperatur sehe ich gerade unkritisch - die kann ich nicht mal selber beeinflussen.
Viele Grüße,
Heiko
Aber natürlich.
Erstens kann man die Speichertemperatur einstellen, und zweitens gibt es z.B. bei mir wegen der Solarthermie einen Mischer, der max. ca. 55 Grad durchlässt.
LG
pah
@heikoh81
Ja schade, das der Verbrauch der Vaillant Thermen nirgendwo erfasst wird. Ich habe mir einfach einen Reedkontakt auf den Gaszähler gehängt und schalte ein Youless nach, dass wiederum über Fhem direkt ausgelesen wird.
Ich glaube du hattest einmal erwähnt, das bei dir der Dämon auch nicht funktionierte. John30 hat das Problem jetzt gelöst und funktioniert nun am Raspi sehr gut. Wenn du mal Zeit hast kannst das einmal testen. Lade einfach vom Git (john30) seine Version herunter. Ich kann dir aber auch gerne nur die fertige Binary "ebusd" hier hochladen wenn du die Steurerdateien alle schon hast.
Schöne Grüße
Reinhart
Zitat von: Prof. Dr. Peter Henning am 26 Januar 2015, 12:33:14
Keine Änderungen an der Schaltung, ...
Hi Peter,
Habe bitte folgende Fragen:
- Ist Vdd 5V oder 3,3V? Vermute 5V.
- Am 20K Poti R3: Sind die linken 2 Kontakte wirklich miteinander verbunden?
Müsste nicht der variable Kontakt von R3 ausschliesslich mit GND verbunden sein und nicht auch mit Pin 2 des Optokopplers?
http://www.fhemwiki.de/w/images/5/55/EBUS-IF-USB.png
Vielen Dank
Joachim
Hallo zusammen!
I bin ganz erfolgreich die Telegramme meiner Therme (Protherm, ähnlich dem Vaillant) zu entschlüssen and viele Angaben auszulesen, wie Temperatur (Außen, Innen Soll/Ist, Heizungwasser-Vorlauf/Rücklauf), Gebläsedreher, Brennerstatus.
Doch gibt es ein ausstehendes Telegramm, der von ID 10 (Master ID des drahtenlosen Reglers) zyklisch an die Therme (ID 08) gesendet wird:
PBSB ID Antwort
B510 - 0000XXffffffYYff00 / 01
(Ohne CRC, usw.)
Die XX ist 0x00 für Therme Off, oder 0x66 bis cca 0x7e für die Therme On.
YY ist immer nur 0x05 für Therme Off oder 0x04 für Therme On.
I habe es schon mit anderen Angaben von der Therme verglichen und es hat nur entfernte Beziehung mit dem Pumpestatus oder Brennerstatus (Leistungsstuffe).
Es kommt mir vor, es sagt was von dem Unterschied zwischen Innentemperatur Soll und Ist - je größer der Unterschied (Soll ist höher als Ist), desto größere ist die Wert des Kommandos XX.
Welchen Beschluss die Therme trifft (fristlose/verschobene schnelle/langsame Erhöhung des Leistungs), ist von dem Regler gesendetes Telegram nicht direkt abhangig. Wahrscheinlich liegt as an anderen Variablen (HWTemperatur, Heizkurve).
Kann jemand das bestätigen oder ein bischen mehr Information geben?
Milan
Zitat von: joachimS am 04 Februar 2015, 16:58:36
Hi Peter,
Habe bitte folgende Fragen:
- Ist Vdd 5V oder 3,3V? Vermute 5V.
- Am 20K Poti R3: Sind die linken 2 Kontakte wirklich miteinander verbunden?
Müsste nicht der variable Kontakt von R3 ausschliesslich mit GND verbunden sein und nicht auch mit Pin 2 des Optokopplers?
http://www.fhemwiki.de/w/images/5/55/EBUS-IF-USB.png
Vielen Dank
Joachim
Hallo Joachim
Die VDD ist 5V und am Poti sind beide an Gnd so wie im Schaltplan gezeichnet.
Da ich andere Optokoppler (Dual) einsetze habe ich auch noch den R2 ändern müssen um einen schönen Regelbereich zu erzwingen.
LG
Reinhart
Danke Reinhart
bin nicht der Elektronik Experte , aber dann kann man sich den linken Anschluss am Poti sparen.
Der Widerstand über den Schleifer ist immer kleiner.
Da freuen wir uns aber, wenn wir auch kluge Ratschläge vom Nicht-Experten bekommen - jedenfalls dann, wenn sie richtig sind.
pah
Gerne Peter ;)
Widerstände verstehe ich gerade noch, bei Deiner Schaltung wird es schon schwieriger.
danke nochmal für die Schaltung!
Zitat von: Prof. Dr. Peter Henning am 01 Februar 2015, 16:11:17
Aber natürlich.
Erstens kann man die Speichertemperatur einstellen, und zweitens gibt es z.B. bei mir wegen der Solarthermie einen Mischer, der max. ca. 55 Grad durchlässt.
Ich habe alle Registern in deinen Dateien und denen von amunra durchprobiert.
Bei keinem gelingt es mir, in der Calormatic 470/3 die WW-Temperatur zu setzen.
Zumindest auslesen kann ich sie, und er zeigt auch die Änderung an, wenn ich an der Calormatic das Soll manuell verändere, aber schreiben auf dieses Register klappt nicht.
###Calormatic 470/3
*r,vrc430,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,vrc430,,,,15,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
#LIEFERT 55.0 WARMWASSER Zieltemperatur
r;w,,hwDesiredTemp,Manuell WW-Solltemperatur,,,,4400,,,temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Zitat von: Reinhart am 01 Februar 2015, 16:44:05
@heikoh81
Ja schade, das der Verbrauch der Vaillant Thermen nirgendwo erfasst wird. Ich habe mir einfach einen Reedkontakt auf den Gaszähler gehängt und schalte ein Youless nach, dass wiederum über Fhem direkt ausgelesen wird.
Kannst du mal beschreiben, wie das mit dem Reed-Kontakt funktioniert? Vielleicht mit Fotos?
Zählst du damit 1 Umdrehung des Gaszählers oder wie?
Und woran ist der Reed-Kontakt angeschlossen? Direkt an einen Raspi?
Der Verbrauch wird nicht erfasst, aber die Leistung! Diese Info wäre schonmal super!
ZitatIch glaube du hattest einmal erwähnt, das bei dir der Dämon auch nicht funktionierte. John30 hat das Problem jetzt gelöst und funktioniert nun am Raspi sehr gut. Wenn du mal Zeit hast kannst das einmal testen. Lade einfach vom Git (john30) seine Version herunter. Ich kann dir aber auch gerne nur die fertige Binary "ebusd" hier hochladen wenn du die Steurerdateien alle schon hast.
Mit dem Patch von Boris funktioniert es.
Gerne kannst du mir die BIN mal schicken, dann tausche ich diese mal probeweise aus.
Viele Grüße,
Heiko
Die meisten modernen Gaszähler sind schon für eine Impulszählung vorbereitet. Mein Gaszähler stammt von der Fa. Itron, dazu habe ich das Teil hier in Einsatz
https://www.itron.com/mxca/en/productsAndServices/Pages/Cyble%20Sensor.aspx
Wirkt im Effekt wie ein Reed-Kontakt, arbeitet aber tatsächlich rein elektronisch (eingebaute Batterie, soll mehrere Jahre halten) mit berührungsloser magnetischer Ankopplung an den Zähler.
Gezählt wird das mit einem 1-Wire DS2423, ausgewertet mit den Modulen OWCOUNT/OWX. Darin ist auch monatliches und jährliches Logging enthalten, die Leistung der Therme (hier gemessen in m³ Gas pro Stunde) und der Energieverbrauch (hier gemessen in m³ Gas) für den heutigen Morgen sieht dann so aus wie auf dem Bild. Außerdem werden z.B. die Kosten aufsummiert - heute waren es wegen der konstant niedrigen Außentemperatur schon 1,73 €.
An dem Bild sieht man übrigens sehr schön, dass die Leistung der Gastherme sehr stark schwankt.
LG
pah
@heiko81
habe dir hier geschrieben, sonst weicht es zuviel vom Thema ab: http://forum.fhem.de/index.php/topic,26059.msg257868.html#msg257868 (http://forum.fhem.de/index.php/topic,26059.msg257868.html#msg257868)
@pah
Danke, ist auch ein interessante Variante (1-Wire). Aber es muss sich ohnehin jeder nach seinem verwendeten Typ des Gaszählers richten.
LG
Reinhart
Ich habe in dem genannten Thread einen Link zu einem extra für Deinen Zähler gefertigten Sensor gepostet.
http://www.pipersberg.de/Gaszahler/RF1-Impulsnehmer.pdf
LG
pah
Hallo,
woran kann es denn liegen, wenn der ebusd gar nichts mehr ausgibt? Ich habe nichts geändert, die LED flackert wie immer, den RPi habe ich schon neu gestartet und zwischenzeitlich vom Netz genommen, aber es kommen auf Anfragen einfach keine Werte mehr. Ich habe das nur deshalb bemerkt, weil sich mein FHEM-Rechner wieder mal aufgehangen hat, da er anscheinend keine Werte mehr vom RPi bekommen hat. Im Vordergrund-Modus kommen auch keine broadcast-Meldungen. Ebusd startet ohne Fehlermeldung. Read und reload werden enden im timeout ("ERR: arbitration lost"). Habe den ebusd dann entfernt und neu installiert, was aber nicht geholfen hat. Dass der ebus mal eine Zeit lang ruhig ist ist mir schonmal aufgefallen. Allerdings war das nicht reproduzierbar. Sieht fast so aus, als wäre meine Therme eingeschlafen :o
Mit der Calormatic 470f kommuniziert sie aber noch.
schöne Grüße
Jo
Seltsam, nach gefühlten 30 Neustarts und diversen Rechte-Modifikationen läuft der ebusd zumindest so, dass er Daten empfängt.
So gestartet:
$ sudo /usr/local/bin/ebusd -f -l ALL -d /dev/ttyUSB0
2015-02-07 09:50:05.664 [bas event] ebusd started
2015-02-07 09:50:05.665 [bas trace] path to ebus configuration files: /etc/ebusd
2015-02-07 09:50:05.684 [bas trace] read templates
2015-02-07 09:50:05.759 [bas trace] read config files
2015-02-07 09:50:05.760 [bas event] message DB: 158
2015-02-07 09:50:05.761 [bas event] updates DB: 0
2015-02-07 09:50:05.763 [bas event] polling DB: 0
erhalte ich folgende Ausgabe:
2015-02-07 09:50:57.925 [upd event] unknown MS cmd: 1008b51101028a / 06033c96468c78f5
2015-02-07 09:50:59.962 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:50:59.964 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:05.960 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:05.961 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:07.041 [net trace] [00001] connection opened 127.0.0.1
2015-02-07 09:51:07.044 [bas event] >>> read DisplayRoomTemp
2015-02-07 09:51:07.045 [bas trace] read cmd: ff15b509030d800082
2015-02-07 09:51:09.882 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:09.975 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:09.977 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:15.887 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:15.976 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:15.978 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:19.860 [bus error] ERR: arbitration lost, retry send
2015-02-07 09:51:19.951 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:19.953 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:25.899 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:25.988 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:25.989 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:27.891 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:27.951 [upd trace] update BC cmd: 10feb516080027510907020615a8
2015-02-07 09:51:27.953 [upd event] unknown BC cmd: 10feb516080027510907020615a8
2015-02-07 09:51:28.133 [bus error] ERR: arbitration lost, retry send
2015-02-07 09:51:28.190 [upd trace] update MS cmd: 1008b512020000ca / 0000
2015-02-07 09:51:28.192 [upd event] unknown MS cmd: 1008b512020000ca / 0000
2015-02-07 09:51:29.877 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:29.970 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:29.972 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:35.881 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:35.971 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:35.973 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:37.920 [bus error] ERR: arbitration lost, retry send
2015-02-07 09:51:37.994 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c78f5
2015-02-07 09:51:37.996 [upd event] unknown MS cmd: 1008b51101028a / 06033c96468c78f5
2015-02-07 09:51:39.901 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:39.993 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:39.995 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:45.903 [bus error] ERR: arbitration lost, retry
2015-02-07 09:51:45.990 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:45.992 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:47.934 [bus error] ERR: arbitration lost,
2015-02-07 09:51:47.934 [bas error] read: ERR: arbitration lost
2015-02-07 09:51:47.935 [bas event] <<< ERR: arbitration lost
2015-02-07 09:51:47.948 [net trace] [00001] connection closed
2015-02-07 09:51:47.972 [upd trace] update BC cmd: 10feb51603010000dc
2015-02-07 09:51:47.973 [upd event] unknown BC cmd: 10feb51603010000dc
2015-02-07 09:51:50.009 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:50.010 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:51:56.038 [upd trace] update MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:56.039 [upd event] unknown MS cmd: 1008b511010189 / 09554d0080ff660100ffb1
2015-02-07 09:51:58.018 [upd trace] update MS cmd: 1008b51101028a / 06033c96468c78f5
2015-02-07 09:51:58.019 [upd event] unknown MS cmd: 1008b51101028a / 06033c96468c78f5
2015-02-07 09:52:00.009 [upd trace] update MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
2015-02-07 09:52:00.011 [upd event] unknown MS cmd: 1008b5100900004b6effff00ff0043 / 01019a
Ist dies ein Problem der Verbindung oder des ebusd? Ich bin leider etwas ratlos.
schöne Grüße
Jo
@Jojo11:
Das sieht so aus, als könnte gar nichts mehr an das Interface geschrieben werden.
Welche Rechte hat denn /dev/ttyUSB0?
Läuft auf dem RPi irgendwas rechenintensives? Was sagt denn uptime so?
Zitat von: john30 am 07 Februar 2015, 10:02:39
@Jojo11:
Das sieht so aus, als könnte gar nichts mehr an das Interface geschrieben werden.
Welche Rechte hat denn /dev/ttyUSB0?
Läuft auf dem RPi irgendwas rechenintensives? Was sagt denn uptime so?
Hallo,
Rechte sind
$ ls -lt /dev/ttyUSB0
crw-rw---T 1 root dialout 188, 0 Feb 7 10:14 /dev/ttyUSB0
Uptime:
$ uptime
10:18:48 up 3:10, 2 users, load average: 0.00, 0.01, 0.05
Die beiden user sind dann wohl pi und su. Sonst läuft eigentlich nichts.
schöne Grüße
Jo
@Jojo11:
Ich fürchte, dann hat Dein Interface die Fähigkeit zu senden verloren. Zumindest sieht es sehr danach aus, wenn Du sonst an keiner Komponente (weder HW noch SW) irgendwas verändert hast.
Hast Du ein Selbstbau-Interface oder etwas fertiges im Einsatz?
:o Äh, nein, kein Selbstbau. Ist das Interface von eservice.
Wie kann denn sowas passieren? Ich werde jetzt nochmal alles stromlos setzen und dann nochmal testen.
schöne Grüße
Jo
@John30
ich teste ja schon über eine Woche deine Binary und wollte dir daher berichten das sie ohne irgendwelcher Probleme bei mir läuft.
Es wird im Augenblick zyklisch alle 6 Minuten der eBus mit je 15 Datenpunkten abgefragt, ohne Ausfälle, ohne Fehlermeldungen!
Ich mache sogar automatische Heizkurven Einstellungen mehrmals am Tag und FHEM setzt somit direkt Befehle an den eBus ab.
Sie Bild im Anhang, am 4.2 habe ich bewusst die Steuerung abgeschaltet um die Auswirkung an der Wichtung zu verfolgen, ansonsten alles fehlerfrei!
Ich kann daher nur sagen, der ebusd ist bei mir sehr stabil, prima Arbeit!
Therme: Vaillant Ecotec plus VCW AT 246/3-5
Busregler: VRC 430
eBus Interface: Eigenbau (Schaltung nach pah)
pi@raspberry2 ~ $ uptime
09:23:05 up 6 days, 15:08, 1 user, load average: 0,01, 0,04, 0,05
pi@raspberry2 ~ $
vor 6 Tagen war ein reboot weil ich den Raspi mit dem eBus-Interface in eine Gehäuse verbaut habe.
Schöne Grüße
Reinhart
Puuuuhhh. Läuft wieder :)
Allerdings musste ich dazu nicht nur den Strom entfernen (das hatte ich vorher schon einmal gemacht), sondern auch die ebus-Leitung abkoppeln.
Verstehen tue ich das nicht, aber ich bin ja auch kein Elektroniker ;D
Danke John!
schöne Grüße
Jo
@Reinhart:
Das freut mich, Danke fürs Feedback!
@Jojo11:
freut mich ebenfalls, dass es wieder läuft. Wieso allerings ein kurzes Abhängen der Leitungen Abhilfe schafft, kann ich mir auch nicht erklären (und das trotz Nebenstudium Elektrotechnik :-) ). Murphy's law schlägt wieder zu
Hmm, nachdem es jetzt ein paar Minuten gelaufen ist, hakt es wieder. Neue Theorie: Liegt nicht am Adapter sondern an der Software. Evtl. kann es sein, dass der RPi irgendwann neu gestartet ist und beim Neustart der ebusd "anders" gestartet wurde. Kann ich sehen, ob evtl. zwei/mehrere ebusd parallel laufen? Das hier gibt mir zu denken:
$ /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ /etc/init.d/ebusd stop
[ ok ] Stopping ebusd: ebusd.
$ /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ sudo /etc/init.d/ebusd status
[ ok ] ebusd is running.
$ sudo /etc/init.d/ebusd stop
[ ok ] Stopping ebusd: ebusd.
$ sudo /etc/init.d/ebusd status
[ ok ] ebusd is running.
schöne Grüße
Jo
Zitat von: Jojo11 am 07 Februar 2015, 11:55:43
Kann ich sehen, ob evtl. zwei/mehrere ebusd parallel laufen?
Folgendes Kommando:
ps ax|grep ebusdsollte ungefähr sowas liefern:
12345 pts/0 Sl+ 0:19 ./git/ebusd/src/ebusd/ebusd --pollinterval 30 -c config -f --loglevel notice --logareas all -d /dev/ttyUSB0
23456 pts/1 S+ 0:00 grep --color=auto ebusd
Die Zeile mit dem "grep" ist der eben gestartete Aufruf. Der Rest sollte nur eine Zeile sein...
$ ps ax|grep ebusd
2049 ? Ssl 0:08 /usr/local/bin/ebusd -f-l All -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A602DIPA-if00-port0 -p 8888
2710 pts/0 S+ 0:00 grep --color=auto ebusd
Seltsam. Diese Instanz bekomme ich mit dem init.d Skript nicht gestoppt.
Wobei ich mich gerade frage, was das "-f" da zu suchen hat ???
schöne Grüße
Jo
@Jojo11:
Welche Version vom ebusd hast Du denn im Einsatz?
Es gab da mal ein Problem mit dem init Script, weil das PID file leer war.
Wenn Du natürlich "-f" angibst, wird sowieso kein PID file erstellt, dann tut sich das init Script auch schwer, den Prozess zu finden...
Ich hatte ja heute nochmal aktualisiert. Bei mir läuft diese Version: https://github.com/yuhu-/ebusd (https://github.com/yuhu-/ebusd)
Seit ich das "-f" entfernt habe, funktioniert das Skript. Aber an dem eigentlichen Problem hat das nichts geändert :(
schöne Grüße
Jo
Zitat von: Jojo11 am 07 Februar 2015, 13:05:47
Bei mir läuft diese Version: https://github.com/yuhu-/ebusd (https://github.com/yuhu-/ebusd)
Wenn Du Muße hast, kannst ja mal meinen fork probieren:
https://github.com/john30/ebusd (https://github.com/john30/ebusd)
Da sind ein paar Verbesserungen drin. Einen Versuch ist es wert denke ich, auch wenn es wahrscheinlich bei Dir keinen Unterschied machen wird.
Die Log Level sind in meinem Fork allerdings etwas anders und lehnen sich an syslog an (error/notice/info/debug). Es wäre gut, wenn Du für einen Test auf "debug" stellst.
LG John
Ok, danke. Werde ich später am Tag mal testen und dann berichten.
schöne Grüße
Jo
@Jojo11
John30 hat ja die ebusd Version hier bei dieser Diskussion weiter verbessert. http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167 (http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167) und liegt in seinem Git.
Ich hänge dir hier die fertig compilierte Version an (am Raspi B+ compiliert), dann brauchst nicht alles neu laden. Die Datei entpacken und nach /usr/local/bin/ kopieren, Rechte kontrollieren (755). Das ist die Version wo dieser PID Fehler bereits behoben ist und nicht mehr mehrere Instanzen laufen können.
Bei mir läuft diese Version etwa eine Woche stabil und ohne Probleme.
Schöne Grüße
Reinhart
Vielen Dank. Kompiliert hatte ich schon ::)
Das Einzige, was mir aufgefallen ist (schon in der Vorgängerversion): Im init.d Skript steht DAEMON=/usr/bin/ebusd
Damit funktioniert es nicht. Bei mir wird der ebusd immer unter /usr/local/bin/ebusd installiert.
Ist das nur bei mir so?
Habe die Zeile halt geändert, aber an dem Sende-Problem ändert es nichts.
schöne Grüße
Jo
@Jojo11
Durch deinen Hinweis ist mir jetzt eingefallen, das ich ursprünglich das Problem mit dem Pfad /usr/bin/ebusd einmal so gelöst hatte, dass ich einfach die Binary dorthin kopiert hatte. Das hatte jetzt für meinen ganzen Tests den Effekt, dass wenn ich händisch im Vordergrund gestartet hatte immer die Binary von John30 benutzt habe und wenn ich den Dämon starte, dann die Binary von Yuhu benutze.
D.h. in der Binary von John30 ist im Dämonbetrieb dann noch ein Pfadfehler drinnen. Ich habe das jetzt anaylsiert und musste in der init.d das Startscript nochmals anpassen (Pfade ändern), jetzt funktioniert es.
#DAEMON=/usr/bin/ebusd
#PIDFILE=/var/run/ebusd.pid
DAEMON=/usr/local/bin/ebusd
PIDFILE=/usr/local/var/ebusd.pid
Jetzt funktioniert auch das Logfile korrekt, lediglich der Pfad /usr/local/var muss vorher für das Pidfile angelegt werden.
Ich glaube aber, das hat nichts zu tun das du nicht senden kannst, nur der Dämon sollte dann richtig laufen.
@John30
Sorry für meinen Fehler, dass ich die alte Binary von Yuhu im /usr/bin vergessen habe, somit habe ich immer 2-spurig getestet. Das erklärt jetzt auch warum letztens die Rechte nicht so passten, wie du es erwartet hättest. D.h, es ist dann leider der Pfad des Pidfiles noch nicht ganz korrekt. Warum es aber jetzt mit der Yuhu Variante plötzlich funktioniert, ist mir noch unklar. Logfile geht dort nicht.
Im Prinzip habe ich aber jetzt eine tolle Testumgebung, da ich durch Ändern des Dämonstartscriptes schnell beide Versionen testen und gegenüber stellen kann.
Fakt ist aber dann, beide Varianten (wenn man sie angepasst hat) funktionieren was die Stabilität betrifft tadellos bei mir. Ich habe jetzt den Dämon von John30 in Betrieb und schaue nochmals eine Woche.
LG
Reinhart
Zitat von: Jojo11 am 07 Februar 2015, 18:11:55
Habe die Zeile halt geändert, aber an dem Sende-Problem ändert es nichts.
Das habe ich mir schon gedacht...
Zitat von: Jojo11 am 07 Februar 2015, 18:11:55
Bei mir wird der ebusd immer unter /usr/local/bin/ebusd installiert.
Ist das nur bei mir so?
Das ist durchaus so gewollt. Die Pfade lassen sich einfach mit Hilfe des "configure" Scripts justieren. Wenn Du lieber alles in /usr statt /usr/local als Basisverzeichnis haben willst, dann brauchst Du nur autogen wie folgt zu starten:
./autogen.sh --prefix=/usr
Zitat von: Reinhart am 07 Februar 2015, 21:09:27
D.h, es ist dann leider der Pfad des Pidfiles noch nicht ganz korrekt.
Der Pfad des PID Files lässt sich seit kurzem auch mit Hilfe der Optionen an das configure Script anpassen ("localstatedir"). Ich habe gerade meinen fork aktualisiert (https://github.com/john30/ebusd/commit/44042026096d290f82f148454cbf1ebb45ba5d5e), so dass ab sofort das PID file per default unter "/var/run/ebusd.pid" angelegt wird.
Hallo,
der ebus macht mich fertig :-\
Nachdem ich heute nochmal die Leitungen getrennt und neu angeschlossen habe, scheint er wieder zu laufen. Alles deutet auf einen kombinierten hard-/software-/Bedienfehler hin ;D
Was ich mir vorstellen könnte ist evtl. eine kalte Lötstelle. Habe nochmal die Version von yuhu installiert.
schöne Grüße
Jo
@John30
Danke für die Änderung!
Ich weiß, das ich dich schon etwas nerve, aber es funktioniert noch nicht ganz.
habe folgendes durchgeführt nachdem ich die Autogen.sh aus deinem Fork angepasst habe.
cd /home/pi/ebusd.master
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd-master/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd (Dämonstartfile kopieren)
sudo chmod 755 /etc/init.d/ebusd (Script Rechte setzen, wenn es via PC kopiert wurde)
sudo update-rc.d ebusd defaults (Runlevel Script aktualisieren)
nun passt der Pfad der Binarys, sie werden jetzt brav im /usr/bin angelegt.
pi@raspberry2 ~/ebusd-master $ cd /usr/bin
pi@raspberry2 /usr/bin $ ls -al ebus*
-rwxr-xr-x 1 root root 332633 Feb 8 09:54 ebusctl
-rwxr-xr-x 1 root root 2320207 Feb 8 09:54 ebusd
-rw------- 1 root root 2769981 Feb 7 18:44 ebusd.old
-rwxr-xr-x 1 root root 307968 Feb 8 09:54 ebusfeed
Der Dämon läuft auch korrekt und er wird aus der /usr/bin gestartet.
pi@raspberry2 /usr/bin $ ps -aux|grep ebusd
root 9333 0.4 0.5 19872 2400 ? Ssl 10:02 0:01 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888
Das Pidfile läuft aber leider wieder in /usr/local/var/. Diesmal aber mit den richtigen Rechten.
pi@raspberry2 /usr/bin $ cd /usr/local/var/
pi@raspberry2 /usr/local/var $ ls -al
insgesamt 12
drwxr-sr-x 2 root staff 4096 Feb 8 10:02 .
drwxrwsr-x 11 root staff 4096 Feb 7 18:54 ..
-rw-r--r-- 1 root staff 5 Feb 8 10:02 ebusd.pid
Ich muss daher noch den Pfad in der Dämonstartrotine anpassen.
DAEMON=/usr/bin/ebusd
#PIDFILE=/var/run/ebusd.pid
PIDFILE=/usr/local/var/ebusd.pid
Mach jetzt ich noch was falsch oder fehlt noch was?
Wenn ich den Pfad ändere, funktioniert natürlich alles. Logfile funktioniert auch in /var/log/ebusd.log
Wegen mir brauchst du das aber nicht ändern, durch die kleine Scriptänderung kann ich gut damit leben.
Schöne Grüße
Reinhart
Zitat von: Jojo11 am 08 Februar 2015, 09:55:03
Hallo,
der ebus macht mich fertig :-\
Nachdem ich heute nochmal die Leitungen getrennt und neu angeschlossen habe, scheint er wieder zu laufen. Alles deutet auf einen kombinierten hard-/software-/Bedienfehler hin ;D
Was ich mir vorstellen könnte ist evtl. eine kalte Lötstelle. Habe nochmal die Version von yuhu installiert.
schöne Grüße
Jo
Hallo Jojo11
Nachdem hier kein anderer User über solche Probleme klagt, nehme ich auch an das mit deiner Hardware was nicht stimmt. Du schreibst zwar, in diesem Zustand blinken die Leds weiterhin, aber es kommt ja drauf an wo diese Leds angeschlossen sind und was sie aussagen sollen (nur TxD oder auch RxD). Ich kenne die Schaltung des Gerätes nicht, daher ist es schwierig hier genaueres zu sagen, aber es wird im Prinzip ein ähnliches Verfahren wie bei der Schaltung im Wiki (vielleicht sogar mit Operationsverstärker LMxxx) sein.
Ein thermischer Fehler könnte es ja auch noch sein, dann müsste der sich auch zeigen wenn nach einem "Reset" du das Gerät mit dem Hahrföhn etwas anwärmst, sollte dann nach kurzer Zeit ausfallen. Dann weißt du zumindest wo der Fehler liegt.
LG
Reinhart
yuhu- hat die ebusd repository aus GitHub gelöscht
https://github.com/yuhu-?tab=repositories
Nun gibt es noch:
https://github.com/John30
Besser eigene Kopie speichern...
Edit: Auch die Wiki is weg. Hat as jemand runtergeladen?
Zitat von: Reinhart am 08 Februar 2015, 11:48:06
Hallo Jojo11
Nachdem hier kein anderer User über solche Probleme klagt, nehme ich auch an das mit deiner Hardware was nicht stimmt. Du schreibst zwar, in diesem Zustand blinken die Leds weiterhin, aber es kommt ja drauf an wo diese Leds angeschlossen sind und was sie aussagen sollen (nur TxD oder auch RxD). Ich kenne die Schaltung des Gerätes nicht, daher ist es schwierig hier genaueres zu sagen, aber es wird im Prinzip ein ähnliches Verfahren wie bei der Schaltung im Wiki (vielleicht sogar mit Operationsverstärker LMxxx) sein.
Ein thermischer Fehler könnte es ja auch noch sein, dann müsste der sich auch zeigen wenn nach einem "Reset" du das Gerät mit dem Hahrföhn etwas anwärmst, sollte dann nach kurzer Zeit ausfallen. Dann weißt du zumindest wo der Fehler liegt.
LG
Reinhart
Hallo Reinhart,
es gestaltet sich durchaus komplex, den Fehler einzugrenzen. Leider ist das auch recht zeitintensiv.
schöne Grüße
Jo
Hallo,
falls jemand ähnliche Abstürze bei disconnects hat wie ich: Die DevIo.pm wurde modifiziert und ist ab morgen verfügbar (http://forum.fhem.de/index.php/topic,31307.0.html (http://forum.fhem.de/index.php/topic,31307.0.html)).
schöne Grüße
Jo
Zitat von: MilanK am 08 Februar 2015, 15:33:57
yuhu- hat die ebusd repository aus GitHub gelöscht
https://github.com/yuhu-?tab=repositories
Nun gibt es noch:
https://github.com/John30
Besser eigene Kopie speichern...
Edit: Auch die Wiki is weg. Hat as jemand runtergeladen?
Ja schade, aber Yuhu wird sicher seine Gründe haben.
Hier ein Auszug aus der Wiki der Version v0.5.0-Beta.3, die Dämon Commands stehen in der README.
Alles was in der Wiki stand ist auch in diesem Thread mehrfach enthalten.
Latest Version: v0.5.0-beta.3 (01.01.2015)
All install instructions below are for the latest version of ebusd.
Download
Pre-release version: v0.5.0-beta.3
Develpoment version: master
Compile
To compile it, please open a 'terminal' in the directory containing the unpacked source code.
Use the following commands to build ebusd. Square brackets indicate optional values.
$ ./autogen.sh [--prefix=/usr]
$ make
Silent building is enabled by default. If you have interest in all command-line options, or you will be prompted to debug information about the compile process, then compile ebusd with the following command.
$ make V=1
Installation
For installation just type the follwing command.
$ make install
For small systems you can use 'install-strip' for installation. (This will remove all symbols from object files)
$ make install-strip
Note: During installation, the directory /etc/ebusd is created. Without installation, this directory must be manually created.
LG
Bin dabei, das Wiki wieder aufzubauen. Hab ja eh ein gutes Stück davon geschrieben...
LG John
Na, dann werde ich in ein paar Tagen auch mal den neuen Code ausprobieren. Bei mir läuft der ebusd so stabil, dass ich das bisher vermieden habe.
LG
pah
Mir fällt seit einigen Tagen auf, dass die Logdatei von einem Tag so etwa 2,6 Mb groß ist. Die erste Hälfte der Logdatei ist mit lauter Nullen gefüllt, dann beginnt die Datei mit normalen Logdaten. Dies betrifft jetzt die aktuelle Logdatei.
in der logrotate (/etc/logrotate.d/ebusd) steht bei mir folgendes:
/var/log/ebusd.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
}
So wie ich das verstehe, sollten max. 7 Files komprimiert (gz) angelegt werden, und die aktuelle nicht größer als max. 1 Mb und täglich ein neues File. Das würde bedeuten, die logrotate zieht irgendwie nicht richtig. Die aktuelle müsste bei > 1Mb rotieren. Oder beißt sich da daily mit size?
Copytruncate kann es ja nicht sein, denn da würde sich der Fehler meiner Meinung ja nur im komprimierten File auswirken.
pi@raspberry2 /var/log $ ls -al ebusd.log*
-rw-r--r-- 1 root root 2755214 Feb 10 18:54 ebusd.log
-rw-r--r-- 1 root root 123203 Feb 10 06:25 ebusd.log.1.gz
-rw-r--r-- 1 root root 267780 Feb 9 06:25 ebusd.log.2.gz
-rw-r--r-- 1 root root 138344 Feb 8 06:25 ebusd.log.3.gz
-rw-r--r-- 1 root root 99 Jan 31 16:35 ebusd.log.4.gz
Komprimierte Dateien werden täglich um 06:25 angelegt und die Stelle wo die Nullen aufhören ist genau um 06:25.
Hat das Problem noch wer, oder liegt es nur bei meiner Konfiguration. Andere Logdateien funktionieren, das Problem ist nur bei der ebusd.log
geändert: Logdatei angehängt
LG
Reinhart
habe soeben einen Thread zum Thema logrotate mit Nullen gefunden.
https://groups.google.com/forum/#!topic/comp.unix.solaris/Zc7ysjMGprQ (https://groups.google.com/forum/#!topic/comp.unix.solaris/Zc7ysjMGprQ)
Das Problem müssten aber dann alle User haben.
So wie ich hier lese, müsste da der ebusd Source geändert werden.
Not using O_APPEND in the first case and using it properly in
the working case.
LG
@Reinhart: interessant, ich habe niemals davon gehört. Doch, funktioniert es gut bei mir (Arch Linux).
Kannst du probierien, ob ebusd den ebusd.log ganze Zeit geöffnet hält:
$ fuser -a /var/log/ebusd.log
(Es soll PIDs drücken. In meinem Fall gibts es kein. Möglich ist, daß es nichts mit 'fd' zu tun hat...)
Zitat von: Reinhart am 10 Februar 2015, 21:17:38
Not using O_APPEND in the first case and using it properly in
the working case.
okay, habs auf append umgestellt. wär cool, wenn Du das probieren könntest.
ich hatte so einen ähnlichen Fall mal in einem anderen Projekt. logrotate ist da manchmal bisschen zickig :-)
LG John
Zitat von: Reinhart am 08 Februar 2015, 11:18:19
Das Pidfile läuft aber leider wieder in /usr/local/var/.
Kann fast nicht sein. Hast Du den letzten Stand vom git genommen ("git pull")?
Was sagt denn bei Dir die Ausgabe von:
strings /usr/bin/ebusd |grep /runMit der aktuellen git Version kommt bei mir
/var/run/ebusd.pid raus.
Zitat von: MilanK am 10 Februar 2015, 21:48:48
$ fuser -a /var/log/ebusd.log
(Es soll PIDs drücken. In meinem Fall gibts es kein. Möglich ist, daß es nichts mit 'fd' zu tun hat...)
Wenn ich fuser als root aufrufe, dann zeigt es mir brav die PID vom ebusd.
Hallo zusammen,
ein paar Zwischenfragen zum Thema ebusd defs/commands vrc430/470:
- sind die hier im Forum beschriebenen Änderungen/Anpassungen (Datentyp-Definitionen etc.) in ein(das ursprüngliche) Dokument eingeflossen?
- hat jemand die vrc430 commands (bai00 sind dankenswerterweise von pah schon überarbeitet) nach den, wie ich finde sehr sinnvollem semantisch motivierten Ansatz von pah, angepasst und kann das hier bereitstellen?
Falls nicht, dann setze ich mich mal dran ... (dauert aber ein paar Tage).
Danke.
VG Arthur
P.S: @pah - Idee war die Config-Files in Wiki und/oder sourceforge/Github(EBUSD/contib) bereitzustellen - oder?
Ja, war die Idee.
Ich bin derzeit beruflich zu 150% ausgelastet, darum derzeit etwas weniger Posts von mir.
LG
pah
so, habe jetzt alles aus dem Git neu geladen und kompiliert. Vorher alle alten Verzeichnisse "ebusd*" auf dem Raspi verschoben.
Installiert habe ich mit der Standard Prozedur:
svn co https://github.com/john30/ebusd
cd /home/pi/ebusd/trunk
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd/trunk/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd
sudo chmod 755 /etc/init.d/ebusd
sudo update-rc.d ebusd defaults
Folgende Ergebnisse:
pi@raspberry2 ~/ebusd/trunk $ ps -aux|grep ebusd
root 13521 0.4 0.5 28068 2348 ? Ssl 12:54 0:09 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888
Dämon OK, Pfade OK.
pi@raspberry2 ~/ebusd/trunk $ sudo strings /usr/bin/ebusd |grep /run
can't open pidfile: /var/run/ebusd.pid
Pidifle kann mit "strings" nicht geöffnet werden, aber Pfad stimmt.
pi@raspberry2 ~/ebusd/trunk $ sudo cat /var/run/ebusd.pid
13521
Pidfile ist korrekter Pfad und auch die Pid ist korrekt eingetragen.
pi@raspberry2 ~/ebusd/trunk $ sudo fuser -a /var/log/ebusd.log
/var/log/ebusd.log: 13521
- Dämon ok
- Pidfile ok
- Logfile ok
- Logrotate ? (erst morgen)
Es sieht nun alles gut aus, ob Logrotate jetzt korrekt funktioniert sehe ich morgen Früh um 06:25 und werde dann noch berichten. Während der ganzen Installationsphase ist mir aufgefallen, das FHEM überhaupt nicht mehr aus der Ruhe zu bringen ist, er zeigt zwar im EBUS Status "Disconnect" an, aber das war es. Nachdem der ebusd am anderen Raspi wieder gelaufen ist habe ich "set EBUS reopen" abgesetzt und alles läuft wieder.
Übrigens, habe gestern auf Raspi 2 B gewechselt (SD Karte umgesteckt) und bin fasziniert von der Geschwindigkeit der Plots. Als YAF Anhänger habe ich nun auch deutlich mehr Speed bei der Anzeige der Grafiken (Bilder). Ebusd läuft auf Raspi B+ und werde hier nicht tauschen, der reicht bei weitem locker aus.
Schöne Grüße
Reinhart
Prima, Danke Dir fürs Testen!
Zitat von: Reinhart am 11 Februar 2015, 14:30:52
pi@raspberry2 ~/ebusd/trunk $ sudo strings /usr/bin/ebusd |grep /run
can't open pidfile: /var/run/ebusd.pid
Pidifle kann mit "strings" nicht geöffnet werden, aber Pfad stimmt.
Da bist Du jetzt auf die zugegebenermaßen etwas verwirrende Ausgabe reingefallen: Das "strings" Kommando extrahiert alle Strings aus dem Binary und spuckt diese aus. Einer der Strings in Deinem ebusd lautet also "can't open pidfile: /var/run/ebusd.pid", was zu erwarten war. Etwas verwunderlich ist nur, dass ein zweiter String "/var/run/ebusd.pid" nicht bei Dir erscheint. Der ist nämlich auch in dem ebusd Binary enthalten.
@john30
ja mit den "strings", da bin ich reingefallen, habe in der Manpage nachgelesen was der tut.
Betreffend Logrotate, das ist bei deiner neuen Version nun auch ok! Das Log wird ordentlich um 06:25 gepackt (ebusd.log.1.gz), das alte sauber gelöscht und ein neues begonnen.
Es dürfte sich aber bei der neuen Version ein kleiner Fehler eingeschlichen haben. Da ich jetzt die Logs genau untersuchen kann ist mir aufgefallen das es öfters zu Busfehlern kommt.
[bus error] ERR: arbitration lost, retry
Hier ein Beispiel:
2015-02-12 06:42:23.869 [update notice] update bai00 Status: 46.0;45.0;-0.438;56.0;51.0;0
2015-02-12 06:42:27.010 [main notice] >>> r anlagendruck
2015-02-12 06:42:27.115 [bus notice] read res: 03ca080092
2015-02-12 06:42:27.116 [main notice] <<< 2.250
2015-02-12 06:42:27.138 [main notice] >>> r vorlauftemperatur
2015-02-12 06:42:27.257 [bus notice] read res: 03f5020062
2015-02-12 06:42:27.258 [main notice] <<< 47.31
2015-02-12 06:42:27.280 [main notice] >>> r returntemp
2015-02-12 06:42:27.411 [bus notice] read res: 05cc0233fd0084
2015-02-12 06:42:27.412 [main notice] <<< 44.75
2015-02-12 06:42:27.434 [main notice] >>> r Fanspeed
2015-02-12 06:42:27.565 [bus notice] read res: 04b00c4ff373
2015-02-12 06:42:27.565 [main notice] <<< 324.8
2015-02-12 06:42:27.587 [main notice] >>> r PumpPower
2015-02-12 06:42:27.698 [bus notice] read res: 0143d8
2015-02-12 06:42:27.698 [main notice] <<< 67
2015-02-12 06:42:27.720 [main notice] >>> r wwsolltemp
2015-02-12 06:42:27.753 [bus error] ERR: arbitration lost, retry
2015-02-12 06:42:27.852 [update notice] unknown MS cmd: 1008b51009000073ffffff04ff0035 / 01019a
2015-02-12 06:42:28.128 [bus notice] read res: 03820300d7
2015-02-12 06:42:28.129 [main notice] <<< 56.12
2015-02-12 06:42:28.150 [main notice] >>> r mcHeatingCurve
2015-02-12 06:42:28.252 [bus notice] read res: 026e00f5
2015-02-12 06:42:28.252 [main notice] <<< 1.10
2015-02-12 06:42:31.874 [update notice] update bai00 Status: 53.0;44.0;-0.438;56.0;51.0;1
Meine Abfrage sieht dabei so aus.
define EBUS.Timer at +*00:06:00 get Aussentemp Aussentemp;;get Druck Druck;;get Vorlauf Vorlauf;;get Status status;;get Ruecklauf Ruecklauf;;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get WarmW.Temp. WarmW.Temp.;;get HKurve HKurve
d.h., ich hole alle 6 Minuten 9 Datenpunkte vom Bus. Irgendwie kommt der eBus jetzt manchmal durcheinander. Ich habe gezielt die älteren Logs jetzt durchforstet, aber da ist kein einziger Fehler enthalten. Ich habe jetzt temporär einmal die 9 Datenpunkte in 3-er Gruppen aufgeteilt und bis jetzt keinen weiteren Fehler mehr entdeckt. Läuft aber erst 1 Stunde so.
Ich kenne ja das eBus Protokoll nicht und weiß daher auch nicht ob das so ähnlich wie eine Colission-Domäne (TCP) funktioniert. Hier wird ja einfach 9,81 Mikro Sec. gelauscht und wenn nichts am Netz ist dann gesendet. Wenn nun gleichzeitig eine andere Station zu senden beginnt (bei gleicher Kabellänge) dann kommt es zu einer Kollision und das Paket wird wiederholt. Laut Log sieht das zumindest jetzt so aus, als würde Fhem den Befehlsstapel abarbeiten obwohl gleichzeitig noch eine Antwort unterwegs ist.
Ich hänge hier das Log von gestern an, da habe ich bis ungefähr zur Mittagszeit die alte "ebusd" und dann auf die letzte Version gewechselt. Ab dann beginnen die "arbitration" Fehler. Scheint mir auf jeden Fall ein Zusammenhang zu sein.
Ebenso wurde unter Fhem nun der erste Disconnect in der Nacht gemeldet (Mail) welchen aber der Watchdog eine Minute später selber beheben konnte.
edit 14:45: auch durch Ändern der Abfrage weniger Werte ist der Fehler NICHT behoben.
LG
Reinhart
Hallo zusammen,
melde mich auch mal wieder, habe aber die letzte Zeit immer mit gelesen.
Meine ebusd von ca. 28.12.2014 läuft ja auch weitestgehend stabil, per Cronjob starte ich den Heizungs-Raspi alle 3 Tage neu, weil ab ca. 5-7 Tagen irgendwas eingefroren ist (ebusd war noch aktiv, ebusd restart hat ebenfalls nichts gebracht, nur der reboot).
Zitat von: Reinhart am 07 Februar 2015, 16:47:49
@Jojo11
John30 hat ja die ebusd Version hier bei dieser Diskussion weiter verbessert. http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167 (http://forum.fhem.de/index.php/topic,29737.msg254167.html#msg254167) und liegt in seinem Git.
Bei mir läuft diese Version etwa eine Woche stabil und ohne Probleme.
Never change a running system :-)
Aber falls ich nun nochmal probieren möchte - ist die Binary noch aktuell oder lieber jetzt neu kompilieren aus dem john30-GIT?
Viele Grüße,
Heiko
"Arbitration lost" ist kein Fehler - sondern eigentlich zu erwarten, wenn auf einem Bus mehrere Master aktiv sein müssen.
LG
pah
@pah
Danke für die Aufklärung, dann verstehe ich das so wie eine ganz normale Kollision!
Das lustige an der Sache, ich habe heute Früh exakt um die selbe Uhrzeit wieder per Mail den Ausfall des eBus gemeldet bekommen. Dein Watchdog hat auch hier wieder perfekt funktioniert. Was ich aber nicht ganz verstehe, dass dieser Fehler plötzlich da war. Ich werde daher noch etwas experimentieren um herauszufinden woran das liegen kann. Im Prinzip sollte es mich ja nicht weiter stören, weil der Betrieb dadurch ja nicht eingeschränkt ist, ich bin halt vorsichtig wenn ich in den Logs Errors finde. Da bin ich vermutlich durch meine über 20-jährige Tätigkeit als System Manager zu sehr geprägt worden. Alles andere was eBus betrifft funktioniert ja mit der letzten Version perfekt. Yuhu und John haben da wirklich sehr gute Arbeit geleistet.
@heikoh81
ich kann dir gerne die letzte Binary posten, ich würde aber einfach alles neu aus dem SVN laden und kompilieren da John30 ja auch in diversen Scripten was geändert hat. Ein paar Posts weiter oben habe ich ja meine Vorgangsweise gepostet, die funktioniert bei mir (Raspi unter Debian) perfekt. Vor allem was Logging (logrotate, Pfad) und Dämon betrifft gabs doch einige Änderungen.
eBus via Cron neu starten war bei mir nie notwendig, da der Bus selbst ja läuft und läuft ......
Vielleicht noch ein Tipp, ich habe festgestellt, das die Raspis sehr empfindlich sind was DN betrifft. Das merkt man wenn man eine SSH Sitzung öffnet und zwischen Benutzername und Passwort es einige Sekunden dauert bis man das Passwort eingeben kann. Dass muss sofort gehen. Dann stimmt irgendwas im DNS nicht und du solltest in dieser Ecke weiter suchen. Ich habe sicherheitshalber auch noch in der Hosts meine Clients eingetragen, das ist zwar unsauber aber es gibt dann absolut keine Probleme mehr.
Zitat von: Reinhart am 13 Februar 2015, 08:40:46
Danke für die Aufklärung, dann verstehe ich das so wie eine ganz normale Kollision!
Genau, "arbitration lost" im Log ist zunächst einmal nichts schlimmes bzw. ungewöhnliches, weil dann einfach zu diesem Zeitpunkt zwei Teilnehmer eine nachricht auf den Bus absetzen wollten. Das ist im eBUS Protokoll vorgesehen und wegen der Arbitrierung kann es auch nur 25 Master am Bus geben.
Unschön wird es, wenn ebusd es dauerhaft nicht schafft, Zugang zum Bus zu bekommen. Dann werden abgesetzte Anfragen im Client mit "ERR: arbitration lost" beantwortet. Das sollte eher nicht passieren.
Zitat von: Reinhart am 13 Februar 2015, 08:40:46
Das lustige an der Sache, ich habe heute Früh exakt um die selbe Uhrzeit wieder per Mail den Ausfall des eBus gemeldet bekommen.
Wie sieht das denn genau aus? Kommen dann keine Nachrichten mehr durch oder "stirbt" der Dienst?? Das darf natürlich nicht sein, darum wäre ich um Hinweise dankbar.
LG John
Hallo
Zitat von: Prof. Dr. Peter Henning am 19 Januar 2015, 11:49:21
Betreffend die Heizkurve: Die hat immer Steigung und Offset - beeinflussbar durch die eingestellte (nicht tatsächliche) Raumtemperatur. Diese "Heizkurve" sollten wir also sehen als eine lokale lineare Annäherung an die tatsächlich gewünschte Heizkurze.
Ziel solte hier also sein, einen schönen variablen PID-Regler zu programmieren (gibt es schon), der in regelmäßigen Abständen Offset und Steigung der Heizkurve anpasst (gibt es noch nicht). Damit ist sichergestellt, dass nicht FHEM die Heizung direkt steuert - sondern nur als "Überintelligenz" über der Heizung sitzt, so dass diese auch autonom laufen kann.
Genau diese Gedanken habe ich mir auch gemacht. Ich möchte über das setzen der Heizkurve in meiner VCR 430 auch gern indirekt die Vorlauftemperatur einstellen.
Die Heizkurve der VCR 430 ist aber leider nicht linear. Hat hier jemand eine Idee, welche Funktion dahinter stecken könnte?
Lars
@john30
habe nun endlich den Fehler des täglichen "reconnect" des eBus gefunden. Der eBus ist unschuldig und hat mit der Sache nichts zu tun, im der syslog bin ich fündig geworden. Es wird gezielt die Wlan Verbindung restartet "Deleting Interface Wlan0", so ein Schmarn!
Feb 14 03:59:57 raspberry2 wpa_supplicant[1746]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:1d:7e:e3:80:80 reason=0
Feb 14 03:59:57 raspberry2 dhclient: Internet Systems Consortium DHCP Client 4.2.2
Feb 14 03:59:57 raspberry2 dhclient: Copyright 2004-2011 Internet Systems Consortium.
Feb 14 03:59:57 raspberry2 dhclient: All rights reserved.
Feb 14 03:59:57 raspberry2 dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb 14 03:59:57 raspberry2 dhclient:
Feb 14 03:59:57 raspberry2 dhclient: Listening on LPF/wlan0/00:13:ef:20:32:95
Feb 14 03:59:57 raspberry2 dhclient: Sending on LPF/wlan0/00:13:ef:20:32:95
Feb 14 03:59:57 raspberry2 dhclient: Sending on Socket/fallback
Feb 14 03:59:57 raspberry2 dhclient: DHCPRELEASE on wlan0 to 10.0.0.254 port 67
Feb 14 03:59:58 raspberry2 ifplugd(wlan0)[1674]: Link beat lost.
Feb 14 04:00:00 raspberry2 ntpd[2135]: Deleting interface #3 wlan0, 10.0.0.84#123, interface stats: received=351, sent=356, dropped=0, active_time=86330 secs
Feb 14 04:00:00 raspberry2 ntpd[2135]: 86.59.13.46 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 93.185.134.36 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 78.46.40.125 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: 86.59.80.170 interface 10.0.0.84 -> (none)
Feb 14 04:00:00 raspberry2 ntpd[2135]: peers refreshed
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: Executing '/etc/ifplugd/ifplugd.action wlan0 down'.
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: client: /sbin/ifdown: interface wlan0 not configured
Feb 14 04:00:08 raspberry2 ifplugd(wlan0)[1674]: Program executed successfully.
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Trying to associate with 00:1d:7e:e3:80:80 (SSID='Mobile' freq=2412 MHz)
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Association request to the driver failed
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: Associated with 00:1d:7e:e3:80:80
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: WPA: Key negotiation completed with 00:1d:7e:e3:80:80 [PTK=CCMP GTK=CCMP]
Feb 14 04:00:45 raspberry2 wpa_supplicant[1746]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:1d:7e:e3:80:80 completed (reauth) [id=0 id_str=]
Feb 14 04:00:46 raspberry2 dhclient: Internet Systems Consortium DHCP Client 4.2.2
Feb 14 04:00:46 raspberry2 dhclient: Copyright 2004-2011 Internet Systems Consortium.
Feb 14 04:00:46 raspberry2 dhclient: All rights reserved.
Feb 14 04:00:46 raspberry2 dhclient: For info, please visit https://www.isc.org/software/dhcp/
Feb 14 04:00:46 raspberry2 dhclient:
Feb 14 04:00:46 raspberry2 dhclient: Listening on LPF/wlan0/00:13:ef:20:32:95
Feb 14 04:00:46 raspberry2 dhclient: Sending on LPF/wlan0/00:13:ef:20:32:95
Feb 14 04:00:46 raspberry2 dhclient: Sending on Socket/fallback
Feb 14 04:00:46 raspberry2 dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
Feb 14 04:00:46 raspberry2 dhclient: DHCPREQUEST on wlan0 to 255.255.255.255 port 67
Feb 14 04:00:46 raspberry2 dhclient: DHCPOFFER from 10.0.0.254
Feb 14 04:00:46 raspberry2 dhclient: DHCPACK from 10.0.0.254
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Link beat detected.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Executing '/etc/ifplugd/ifplugd.action wlan0 up'.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: client: /sbin/ifup: interface wlan0 already configured
Feb 14 04:00:46 raspberry2 dhclient: bound to 10.0.0.84 -- renewal in 298635 seconds.
Feb 14 04:00:46 raspberry2 ifplugd(wlan0)[1674]: Program executed successfully.
Feb 14 04:00:47 raspberry2 ntpd[2135]: Listen normally on 4 wlan0 10.0.0.84 UDP 123
Feb 14 04:00:47 raspberry2 ntpd[2135]: peers refreshed
Feb 14 05:00:41 raspberry2 wpa_supplicant[1746]: wlan0: WPA: Group rekeying completed with 00:1d:7e:e3:80:80 [GTK=CCMP]
Das Ganze täglich zur selben Uhrzeit. Ich habe auch schon nachgelesen, angeblich könnte das ein Bug des Realtek Treibers ein, kann ich mir aber nicht vorstellen. Im Cronjob kann ich nichts finden, aber von irgendwo wo muss es ja getriggert werden. Ich suche aber nicht länger herum, sondern gebe dem Raspi auch ein Lan das unmittelbar in der Nähe (Gaszähler) ist. Wenn man es weiß, stört es auch nicht weiter, weil es ja automatisch wieder da ist.
LG
Reinhart
:) Hallo liebe eEusfahrer!
Ich lese seit geraumer Zeit hier mit und bin von den bisherigen Erkenntnissen tief beeindruckt. Tolle Arbeit!
Ich habe FHEM verteilt auf 3 RPIs laufen. Für Haus/Licht/Heizkörper usw, Aquarium und jetzt neu einen für die Heizung mit eBus Koppler. Ebusd läuft und ich kann die Daten auslesen.
Ich habe eine Wolf-Anlage und bisher für den ebusd 0.5.0 keine passenden csv-Dateien finden können. Das alte Repository ist ja down und bei john30 finde ich nur passende Files für Vaillant. Alles was ich bisher für Wolf finden konnte scheint ein anders Format zu sein.
Kann ich die cvs-Dateien der älteren Versionen konvertieren und/oder kann ich die Unterschiede irgendwo finden.
...bin für jeden Tipp dankbar.
LG Elmar
Zitat von: elmar am 18 Februar 2015, 11:19:17
Tolle Arbeit!
Merci für die Blumen :-)
Zitat von: elmar am 18 Februar 2015, 11:19:17
Ich habe eine Wolf-Anlage und bisher für den ebusd 0.5.0 keine passenden csv-Dateien finden können. Das alte Repository ist ja down und bei john30 finde ich nur passende Files für Vaillant. Alles was ich bisher für Wolf finden konnte scheint ein anders Format zu sein.
Kann ich die cvs-Dateien der älteren Versionen konvertieren und/oder kann ich die Unterschiede irgendwo finden.
Wenn Du magst, kannst mir Deine Files schicken, dann konvertier ich sie dir.
LG John
Hallo zusammen,
heute ist es so weit: ebusd 1.0.0 ist released. :D
Für die großen Releases plane ich (auch in Zukunft) Debian Packages bereit zu stellen (32/64 und RPi). Das aktuelle findet sich zum Download hier:
https://github.com/john30/ebusd/releases/latest (https://github.com/john30/ebusd/releases/latest)
Über Feedback jeglicher Art würd ich mich freuen!
LG John
Hallo hab auch ne Wolf,..
bin nur nicht so fit mir Debian Perl etc..
Mit Hilfe aber so einiges schon realisiert.. Würde mich ev mit anhängen--
Was für eine Anlage ist es denn ?
Ich hab eine Gasbrennwert GB20.
Würde dann alle Schritte von mir in einer Doku zusammenfassen..
@john30
Danke für das neue Release!
Ich habe es soeben compiliert und installiert! Während der Installation sind keine Fehler aufgetaucht und es meldet sich auch die 1.0.0
pi@raspberry2 /usr/bin $ ./ebusd -V
ebusd 1.0.0
Was mir im Log gleich ins Auge gefallen ist, das die Ausgabe jetzt zusätzlich den Wert QQ=10 enthält. Was bedeutet das?
Stört im Prinzip nicht weiter, würde mich nur interessieren.
2015-02-18 20:36:07.844 [update notice] update broadcast vdatetime QQ=10: 21:33:29;18.02.2015
2015-02-18 20:36:25.978 [update notice] update bai00 Status QQ=10: 33.0;33.0;1.312;29.0;31.0;0
so kommen jetzt die Daten an mit dem zusätzlichen "QQ=10"
2015-02-18 12:18:06.721 [update notice] update bai00 Status: 56.0;47.0;-4.562;46.0;47.0;1
so waren die Antworten früher
Ich werde natürlich so wie immer täglich die Logs kontrollieren und melde mich wenn was auffällt. Seit ich den eBus Raspberry im Lan habe gab es keine Fehler mehr. Auch die "arbitration lost" halten sich in Grenzen und tauchten nur mehr etwa alle Stunde auf.
PS:ich habe gerade gesehen ich habe die Version aus dem SVN ausgecheckt, ich hoffe jetzt es handelt sich dabei um dieselbe und habe da keinen Fehler gemacht ?
svn co https://github.com/john30/ebusd
LG
Reinhart
@ John
Zitat von: john30 am 18 Februar 2015, 20:50:32
Wenn Du magst, kannst mir Deine Files schicken, dann konvertier ich sie dir.
Danke, aber ich hab´ja (noch) keine gefunden.
Ich habe nur die wolf_cycle.csv, zur Version 0.2.x aus dem Repository, als Ausgangspunkt für meine Recherchen.
Würde da was brauchbares bei rauskommen?
btw: Update auf 1.0.0 ging problemlos :)
@ Franz
Ich habe einen Wolf CNK 32 Kessel mit Speicher, einen Weishaupt WG5 Gasbrenner und eine Wolf R3 als Regelung
Hast Du den ebusd schon laufen?
scan result
08;G. Kromschröder AG; Z ;0230;0206
0c;G. Kromschröder AG; ;0204;0184
15;G. Kromschröder AG; ;0204;0184
35;G. Kromschröder AG; ;0204;0184
50;G. Kromschröder AG; Z ;0230;0206
51;G. Kromschröder AG; Z ;0230;0206
75;G. Kromschröder AG; ;0204;0184
LG Elmar
Hab mich da noch nicht rangetraut. Brauch bei so was einfach noch zu viel Hilfe, und bisher war sonst wohl keiner mir einer Wolf.
@John30
man soll nicht immer gleich fragen wenn man selber nachschauen kann!
Ich habe mir die Sourcen angesehen und festgestellt, das du hier zusätzlich die SourceAdresse ausgibst.
logNotice(lf_update, "update %s %s from QQ=%2.2x: %s", clazz.c_str(), name.c_str(), srcAddress, data.c_str());
Ich nehme jetzt an, das ist die Busadresse.
LG
Reinhart
@Elmar und Franz
Vielleicht hilft euch die eBus Wiki weiter. Der Autor erwähnt, das die Wolf sehr gut dokumentiert sein sollen.
Er hat hier aber leider nur ein Beispiel der Solardaten.
http://ebus.webhop.org/twiki/bin/view.pl/EBus/Service50Kromschroeder (http://ebus.webhop.org/twiki/bin/view.pl/EBus/Service50Kromschroeder)
LG
Reinhart
@ Reinhart
Danke für den Tipp!
Das Wiki kenne ich natürlich,bin aber hier auch nicht wirklich weiter gekommen.
LG Elmar
Zitat von: Reinhart am 14 Februar 2015, 15:36:21
habe nun endlich den Fehler des täglichen "reconnect" des eBus gefunden. Der eBus ist unschuldig und hat mit der Sache nichts zu tun, im der syslog bin ich fündig geworden. Es wird gezielt die Wlan Verbindung restartet "Deleting Interface Wlan0", so ein Schmarn!
....
Das Problem ist schon rel. lange bekannt und taucht bei verschiedenen WLan Sticks mit Realtec-Chipsatz auf.
Ich habe auch 2 davon :(
Bei machen hilft es das Powermanagement mit "wireless-power off" in "/etc/network/interfaces" abzuschalten um den "Schlafmodus" zu deaktivieren.
LG Elmar
@Elmar
Danke für den Hinweis, habe es so ähnlich auch ergoogelt. Mir ist aber immer noch unklar wo hier der Bug sein soll, es wird ja täglich exakt um dieselbe Uhrzeit (auf die Sekunde genau) der Reconnect eingeleitet. Daher muss irgend ein Programm das ja Triggern, ob das wirklich das Powermanagement macht? Ich habe aber jetzt alles via Lan angebunden und somit diesen "Bug" umgangen. Somit habe ich den Wlan-Stick wieder frei für den Reserve Raspi, falls einer der Beiden einmal ausfallen sollte.
Zumindest konnte ich so den Watchdog gut testen, der es jedes Mal geschafft hat den Reconnect durchzuführen.
Ich hoffe du bist du schon weiter gekommen mit den Templates für deine Wolf Therme. Ich habe mich damit auch noch nie beschäftigt, weil ja für Vaillant schon alles fertig war. Aber ich glaube einen Artikel von Pah/Yuhu schon gelesen zu haben, wo er das sehr gut erklärt wie man die RAW Daten korrekt umrechnet.
Für mich ist zum Glück das Thema eBus abgeschlossen, da es bei meiner Vaillant Therme im Augenblick nichts mehr zu verbessern gibt. Ich schraube nur mehr am Feintuning des (Software) Reglers der die Heizkurve via eBus steuert. Die Steuerung hat sich nun geringfügig geändert, da ich seit kurzem eine Hocheffizienz Pumpe im Automatikmodus einsetze und diese bei nur 4-7 Watt für etwas weniger Wärmenachschub sorgt.
Schöne Grüße
Reinhart
Zitat von: Reinhart am 18 Februar 2015, 22:09:20
Was mir im Log gleich ins Auge gefallen ist, das die Ausgabe jetzt zusätzlich den Wert QQ=10 enthält. Was bedeutet das?
Das ist die Adresse des Nachrichten-Senders (in hex). Sofern eine Nachricht ohne dedizierte Ziel-Adresse in den config-Files auftritt, wird diese ebenso mit "ZZ=" ausgespuckt. Damit hat man im Log alles, was man zur Interpretation der Nachricht brauchen könnte.
Zitat von: Reinhart am 18 Februar 2015, 22:09:20
Ich werde natürlich so wie immer täglich die Logs kontrollieren und melde mich wenn was auffällt. Seit ich den eBus Raspberry im Lan habe gab es keine Fehler mehr. Auch die "arbitration lost" halten sich in Grenzen und tauchten nur mehr etwa alle Stunde auf.
Super, Danke schonmal!
Zitat von: Reinhart am 18 Februar 2015, 22:09:20
PS:ich habe gerade gesehen ich habe die Version aus dem SVN ausgecheckt, ich hoffe jetzt es handelt sich dabei um dieselbe und habe da keinen Fehler gemacht ?
Das ist kein Problem. github stellt hier nur mehrere Wege zum clonen bereit, ist also genau das selbe! :)
LG John
Zitat von: Franz Tenbrock am 18 Februar 2015, 21:14:00
Hallo hab auch ne Wolf,..
Ich hab eine Gasbrennwert GB20.
Welche config Files hattest Du denn dann bis jetzt im Einsatz?
Hab hier nur mitgelesen,
ist glaube ich noch ne Nummer zu Groß / hoch für mich
Würde mich eher an einen IT Spezi mit Wolf anhängen wollen ...
Ist ja ne super interessante Sache, sicher eine der sinnvollsten wenn es ums Energiesparen / Komofort geht.
Hab halt nur so nen kleinen Wandschalter an dem das programmieren ziemlich nervig ist.
Zitat von: elmar am 18 Februar 2015, 11:19:17
Ich habe eine Wolf-Anlage und bisher für den ebusd 0.5.0 keine passenden csv-Dateien finden können. Das alte Repository ist ja down und bei john30 finde ich nur passende Files für Vaillant. Alles was ich bisher für Wolf finden konnte scheint ein anders Format zu sein.
Kann ich die cvs-Dateien der älteren Versionen konvertieren und/oder kann ich die Unterschiede irgendwo finden.
hab jetzt mal ein Stück von den alten Wolf Files konvertiert:
https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf (https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf)
Nachdem ich selbst keine Wolf Anlage habe, bitte einfach mal nur lesend ausprobieren, ich kann natürlich keine Gewähr für die Richtigkeit übernehmen!
Also: enter at your own risk :-)
Hallo
hab mir das nun runtergeladen und auch mal reingeschaut
ebusd-configuration-master.zip
dort dann die wolf.csv
was soll/muss/kann ich nun damit anstellen nachsehen etc
Im Handbuch der Anlage?
no plan halt >:(
@John
Klasse !
Danke hab´s schon drin und zumindest wird mal was konvertiert angezeigt.
2015-02-20 02:14:23.313 [update notice] unknown MS cmd: 7051501407029a2d9a1700141e / 090001662d0080146432c9
2015-02-20 02:14:24.432 [update notice] update betrd regler QQ=10: aa;03;59.12;0.004;-;10.0;ff
2015-02-20 02:14:25.824 [update notice] update broadcast feuerung QQ=f1: 01;40;-;62.0;-;0;4
2015-02-20 02:14:28.248 [update notice] update broadcast feuerung QQ=03: 01;48;0;64.5;-;49;4
2015-02-20 02:14:28.735 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
2015-02-20 02:14:33.138 [update notice] update betrd regler QQ=10: aa;02;59.12;0.004;-;10.0;ff
2015-02-20 02:14:34.529 [update notice] update broadcast feuerung QQ=f1: 01;40;-;64.0;-;0;4
2015-02-20 02:14:37.486 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
2015-02-20 02:14:38.397 [update notice] update sollw regler QQ=03: 59.102;4.000;0;02;10.000
2015-02-20 02:14:41.906 [update notice] update betrd regler QQ=10: aa;03;59.12;0.004;-;10.0;ff
2015-02-20 02:14:43.298 [update notice] update broadcast feuerung QQ=f1: 01;40;-;64.0;-;0;4
2015-02-20 02:14:47.471 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
2015-02-20 02:14:48.482 [update notice] update broadcast feuerung QQ=03: 01;48;0;67.0;-;49;4
2015-02-20 02:14:52.039 [update notice] update betrd regler QQ=10: aa;02;59.12;0.004;-;10.0;ff
2015-02-20 02:14:53.453 [update notice] update broadcast feuerung QQ=f1: 01;40;-;67.0;-;0;4
2015-02-20 02:14:57.537 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
2015-02-20 02:14:58.478 [update notice] update sollw regler QQ=03: 59.102;4.000;0;02;10.000
2015-02-20 02:15:02.040 [update notice] update betrd regler QQ=10: aa;03;59.12;0.004;-;10.0;ff
2015-02-20 02:15:03.453 [update notice] update broadcast feuerung QQ=f1: 01;40;-;67.0;-;0;4
2015-02-20 02:15:07.538 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
2015-02-20 02:15:08.527 [update notice] update broadcast feuerung QQ=03: 01;40;0;69.0;-;49;4
2015-02-20 02:15:12.094 [update notice] update betrd regler QQ=10: aa;02;59.12;0.004;-;10.0;ff
2015-02-20 02:15:13.507 [update notice] update broadcast feuerung QQ=f1: 01;40;-;69.0;-;0;4
2015-02-20 02:15:17.537 [update notice] update sollw regler QQ=f1: 59.102;3.602;0;00;10.000
;D
Werd´s am Wochenende mal weiter vertiefen und prüfen.
LG Elmar
Leute, jetzt brauche ich mal bitte Unterstützung.
Denn ich habe heute früh versucht, von meiner älteren und wunderbar laufenden Version 0.5.0, mit den Konfigurationsdateien von hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/
auf die aktuelle Version umzustellen. Nach dem Übersetzen den ebusd mit --checkconfig gestartet, keine Fehlermeldung. Prima, denke ich mir - sollte also laufen.
Ist aber nicht so, in der Mehrzahl der Kommandos liefert mir der ebusctl ein ERR: element not found
Vielleicht ist jemand so nett und schreibt mir 5 Zeilen darüber, welche Änderung am Format der Konfigurationsdateien ich verpasst habe. Oder macht das hierin im Änderungsmodus: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_Protokoll_kurz.ods?format=raw und schickt sie mir.
Normalerweise habe ich keine Probleme, das selbst herauszufinden - bin allerdings im Moment beruflich extrem stark eingespannt.
LG
pah
Zitat von: Franz Tenbrock am 19 Februar 2015, 23:02:25
was soll/muss/kann ich nun damit anstellen nachsehen etc
Im Handbuch der Anlage?
Als erstes ebusd zum Laufen bringen. Dazu das fertige Package installieren (https://github.com/john30/ebusd/releases/latest (https://github.com/john30/ebusd/releases/latest)) oder die Quellen übersetzen: https://github.com/john30/ebusd/wiki/1.-Build-and-install (https://github.com/john30/ebusd/wiki/1.-Build-and-install).
Dann noch die Dateien in das ebusd config Verzeichnis (das sollte /etc/ebusd/ sein) kopieren und dann den Dienst starten.
Der Dienst protokolliert in eine Datei (normalerweise /var/ebusd/ebusd.log) und da solltest Du einen Blick rein werfen, z.B. so:
tail -f /var/ebusd/ebusd.log
Zitat von: Prof. Dr. Peter Henning am 20 Februar 2015, 05:14:40
Denn ich habe heute früh versucht, von meiner älteren und wunderbar laufenden Version 0.5.0, mit den Konfigurationsdateien von hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/
auf die aktuelle Version umzustellen. Nach dem Übersetzen den ebusd mit --checkconfig gestartet, keine Fehlermeldung. Prima, denke ich mir - sollte also laufen.
Ist aber nicht so, in der Mehrzahl der Kommandos liefert mir der ebusctl ein ERR: element not found
Das liegt nicht in den config files sondern an dem veränderten "read" Aufruf in der neuen Version. Es wird jetzt vor der Angabe der Message Klasse ein "-c" erwartet, da die Klasse optional ist. Siehe hier:
https://github.com/john30/ebusd/wiki/3.-Commands#read (https://github.com/john30/ebusd/wiki/3.-Commands#read)
Im HEAD vom master Branch ist das jetzt auch für "write" so umgesetzt ("-c" kann hier vor der Klasse stehen). Bis gestern war hier das "-c" nicht notwendig. Hintergrund ist, dass für ein "write" die Angabe der Klasse auf jeden Fall notwendig ist, um nicht aus Versehen auf das falsche Gerät zu schreiben.
Wenn ich das richtig sehe, sollten die http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/*.cfg Files mit einem search&replace zu patchen sein, bspw. so:
sed -ie 's/\(["0]\)read\s/\1read -c /g' *.cfgLG John
Hallo,
erst mal ein dickes Lob an alle hier. dank den Files kann ich fast alles was ich will auslesen und mit vwmon speichern.
eine frage habe ich jedoch: wenn mit einem read Aufruf mehrere Daten gleichen typs ausgegeben werden, wie schaffe ich es, dass nur der gewünschte wert angezeigt wird?
Viele Grüße
david
Zitat von: john30 am 20 Februar 2015, 07:05:44
Der Dienst protokolliert in eine Datei (normalerweise /var/ebusd/ebusd.log) und da solltest Du einen Blick rein werfen, z.B. so:
tail -f /var/ebusd/ebusd.log
Moin!
Also bei mir sind die Logdateien in "/var/log/"
tail -f /var/log/ebusd.logLG Elmar
@john30: Danke, das war es. Läuft wieder astrein - und die Sonne scheint auch.
LG
pah
Hallo zusammen,
ich verfolge den Ebus Thread nun auch schon eine Weile. Ich habe mir den Adapter von PAH der Wiki-Seite gebaut, dieser funktioniert klasse. Seit dieser Woche kann ich nun auch den Bus abhören. Hierfür danke an alle, die das Abfragen ermöglicht haben. :)
Mein Problem ist, ich hab keine Vaillant oder Wolf Anlage, sondern ich habe eine Luft Kompakt Wärmepumpe für Innenaufstellung von der Firma BARTL, diese besitzt eine TEM-Regelung (SE 6001 WPC). Über diese WP/TEM-Regelung finde ich sehr wenig Informationen im Netz. Ein paar Daten sind auf der Standard Ebus Konfig verfügbar - welche ich auch schon im Klartext sehe (Datum, Uhrzeit, Aussentemperatur, mittlere Speichertemperatur, WP RL)
Ein Bekannter von mir besitzt eine Ochsner WP ebenfalls mit TEM Regelung.
Wir sind dran und versuchen gerade noch mehr Datenpakete zu entschlüsseln.
Meine Frage an euch - gibt es hier im Forum noch andere BARTL/OCHSNER/TEM Leidensgenossen, welche ebenfalls gerade am entschlüsseln der Codes sind, oder vielleicht schon das eine oder andere Datenpaket herausgefunden haben.
Ich bin sehr an einem Erfahrungsaustausch interessiert!
Danke für viele Antworten ;)
Gruß Tomy
Hallo, hab im wiki nun auch einiges gelesen.
Es wird ja empfohlen einen Raspi zu nehmen.
Da ich noch nicht so fit bin wird das sicher für mich auch die bessere Variante sein, ev kann ich das ja später auf den cubitruck transferieren..
Reicht ein Raspi A aus, die sind ja wohl nun sehr billig zu bekommen...
oder besser B oder das neueste Modell.
Was würdet ihr machen.
Den Eigenbau Bus sollte ich wohl hinbekommen, nanoCul und fhemduino und einiges anderes hat ja auch geklappt
@Tomy: Ich würde mal beim Hersteller anfragen. Nicht alle hallen ihren Kram geheim.
LG
pah
Hallo!
Ich möchte mich als erstes bei allen für die tolle arbeit bedanken!
Habe Gestern begonnen meinen Rasperry Pi 2 (der nun genug Power haben sollte um alles auf ihn laufen zu lassen) zu konfigurieren.
EbusD läuft schon stabil, jedoch habe ich so meine Probleme mit den cvs Dateien und Fhem das nicht mehr übers interface erreichbar ist und ecmd?!
Muss diesen Thread heute Abend nochmal durchackern und hoffe das ich daraus schlau werde.
Meine Vaillant Heizung besteht aus folgenden Komponenten: 1x 620/3, 2x90/3, 1xVPM30/35, 1xVPM20S, 1xVR60, 1xVkk226/4 und vrnetdialog 860/2
pah´s files habe ich schon gezogen (Vielen dank nochmal) und werde versuchen diese einzubinden. woltle auch noch die files von yuhu ziehn, jedoch wurde alles gelöscht ! :-(
Hat jemand noch Backups von diesen?
weiters wollte ich fragen ob sowas wie im anhang (aus der weboberfläche der vrnetdialog) sinnvoll ist (nurmal plump aus dem html file kopiert).
wenn wir das brauchen können, dann setzte ich mich heute abend hin und mache eine saubere tabelle mit allen werten usw.
liebe grüße und vielen dank nochmals an alle!
mono
Da ein Popup erscheint das den Read und Write Befehl der VrNetDialog durchführt wäre es evtl. möglich da Daten mit zu schreiben?!
Muss ich mir heute Abend nochmals ansehen.
Lg
Zitat von: stinch am 20 Februar 2015, 09:24:15
eine frage habe ich jedoch: wenn mit einem read Aufruf mehrere Daten gleichen typs ausgegeben werden, wie schaffe ich es, dass nur der gewünschte wert angezeigt wird?
Du meinst sicher aneinander gehängte Felder mit ";" dazwischen. Die sind übrigens nicht unbedingt vom gleichen Typ, sondern einfach alle Teil der entsprechenden Message.
Um nur genau eines der Felder zu bekommen, musst Du beim "read" command einfach noch den Feldnamen dahinter schreiben, also z.B.
read -c ehp00 hwTankTemp temp
Zitat von: elmar am 20 Februar 2015, 09:27:44
Also bei mir sind die Logdateien in "/var/log/"
tail -f /var/log/ebusd.log
äh, ja. Schreibfehler :-)
Ist natürlich "/var/
log/ebusd.log"
Zitat von: monoton am 21 Februar 2015, 09:27:32
EbusD läuft schon stabil, jedoch habe ich so meine Probleme mit den cvs Dateien und Fhem das nicht mehr übers interface erreichbar ist und ecmd?!
Wie sehen denn Deine Probleme bzgl. der config genau aus?
Zitat von: monoton am 21 Februar 2015, 09:27:32
woltle auch noch die files von yuhu ziehn, jedoch wurde alles gelöscht ! :-(
Die config files sind hier:
https://github.com/john30/ebusd-configuration (https://github.com/john30/ebusd-configuration)
Zitat von: monoton am 21 Februar 2015, 09:27:32
weiters wollte ich fragen ob sowas wie im anhang (aus der weboberfläche der vrnetdialog) sinnvoll ist (nurmal plump aus dem html file kopiert).
wenn wir das brauchen können, dann setzte ich mich heute abend hin und mache eine saubere tabelle mit allen werten usw.
In "[bus]" scheint die Slave-Adresse im lower byte zu stehen. Allerdings fehlt die Parameter-Adresse. Vielleicht gibt es einen Zusammenhang zwischen "[id]" und der Parameter-Adresse. Das könnte man rauskitzeln, indem man den Wert über vrdialog oder das UI ändert und derweil am ebusd Log schaut, was so alles vorbeikommt.
Zitat von: Franz Tenbrock am 20 Februar 2015, 19:40:35
Hallo, hab im wiki nun auch einiges gelesen.
Es wird ja empfohlen einen Raspi zu nehmen.
Da ich noch nicht so fit bin wird das sicher für mich auch die bessere Variante sein, ev kann ich das ja später auf den cubitruck transferieren..
Reicht ein Raspi A aus, die sind ja wohl nun sehr billig zu bekommen...
oder besser B oder das neueste Modell.
Was würdet ihr machen.
Den Eigenbau Bus sollte ich wohl hinbekommen, nanoCul und fhemduino und einiges anderes hat ja auch geklappt
Hallo Franz!
Ich persönlich würde vom Preis/Leistungsverhältnis den B+ nehmen, da er schon die Micro SD und genug Schnittstellen hat. Von der Leistung her ist es beim eBus egal, der belastet den Raspi kaum, siehe Bild. Das neueste Modell 2 ist nicht notwendig, für Fhem schon eher da dies einen ordentlichen Leistungsschub bekommt, vor allem die Plots. Viel wichtiger finde ich beim Raspi das Netzteil, das mindestens 2 A (Hersteller Angaben) haben sollte, dann hast hier noch Reserve für Zusatz Hardware wie zB. den RS232-USB Konverter. Wichtig ist auch eine stabile Netzwerkverbindung, damit ECMD auch problemlos laufen kann, ich hatte da so meine Problem mit einem Wlan Adapter.
Ich habe auch den B+ für den eBus und den neuen Typ 2 für FHEM.
Schöne Grüße
Reinhart
Betreffend vrnetdialog: Wir haben in dieser Software ja eine Datenbank mit allen Kommandos. Leider nicht dokumentiert. Die Frage ist deshalb, ob man nicht eine offene Datenbank mit allen Geräten aufbaut. Die Datenbankinstanz im Netz kann ich zur Verfügung stellen.
Betreffend den Raspberry Pi: Ich habe derzeit vier davon in Betrieb, die besten Erfahrungen bezgl. WLAN habe ich hiermit genacht: http://www.reichelt.de/TPLINK-TLWN822N/3/index.html?&ACTION=3&LA=446&ARTICLE=124341&artnr=TPLINK+TLWN822N&SEARCH=TPLINK-TLWN822N
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2015, 12:15:44
Betreffend vrnetdialog: Wir haben in dieser Software ja eine Datenbank mit allen Kommandos. Leider nicht dokumentiert. Die Frage ist deshalb, ob man nicht eine offene Datenbank mit allen Geräten aufbaut. Die Datenbankinstanz im Netz kann ich zur Verfügung stellen.
Da wäre ich sofort dafür. Im Grunde ist das https://github.com/john30/ebusd-configuration (https://github.com/john30/ebusd-configuration) repository der Versuch, so eine DB aufzubauen.
Auf lange Sicht möchte ich aus der vrnet DB die Configs für alle enthaltenen Geräte generieren.
LG John
@Reinhart: Thanks für die Tips, mal sehe ev bekomme ich ja eine gebrauchten günstig ...
ist ev die Integration von einer thermischen Solaranalge mit vbus möglich?
http://forum.fhem.de/index.php/topic,10303.0.html
der vbus Adapter kostet fast 100 Euro :-(
das wird doch auch so was sein wie dieser hier besprochene Bus... ?
Zitat von: Franz Tenbrock am 21 Februar 2015, 18:53:04
http://forum.fhem.de/index.php/topic,10303.0.html
der vbus Adapter kostet fast 100 Euro :-(
das wird doch auch so was sein wie dieser hier besprochene Bus... ?
Ist leider vom Protokoll her nicht eBUS, sondern was anderes, siehe hier:
http://hobbyelektronik.org/w/index.php/VBus-Decoder (http://hobbyelektronik.org/w/index.php/VBus-Decoder)
ebusd hat heute ein neues Feature bekommen:
--dumpconfig (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options) für die Kommandozeile bzw. "find -f" (https://github.com/john30/ebusd/wiki/3.-Commands#find) für das Client Interface.
Damit werden die Message-Definitionen der CSV Files (bzw. die gefundenen bei "find -f") in der finalen Version ausgegeben, also mit eingearbeiteten Templates.
Wozu das Ganze? Z.b. für yawgd oder andere weiterführende Dienste, die die CSVs ohne Template brauchen um daraus Nachrichtenlisten o.ä. zu generieren.
Das Feature lässt sich natürlich auch nutzen, um die finale Struktur einer neu geschriebenen Message-Config anzuschauen.
LG John
Zitat von: john30 am 21 Februar 2015, 10:16:38
Du meinst sicher aneinander gehängte Felder mit ";" dazwischen. Die sind übrigens nicht unbedingt vom gleichen Typ, sondern einfach alle Teil der entsprechenden Message.
Um nur genau eines der Felder zu bekommen, musst Du beim "read" command einfach noch den Feldnamen dahinter schreiben, also z.B.
read -c ehp00 hwTankTemp temp
Hi,
mein Problem ist, das z.B. bei pah's csv z.B. bei "StatusHWC2" 3 Werte (Sp1 - Sp3) angezeigt werden und alle als temp definiert sind:
re,,StatusHWC2,Speicher SP1 � SP3,,,,0F,,,temp;temp;temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,So sieht bei mir die Ausgabe aus:
localhost: r -v StatusHWC2 temp
temp=66.12 °C [Temperatur];temp=36.94 °C [Temperatur];temp=-13.94 °C [Temperatur](Sp3 ist bei mir nicht vorhanden.)
Wie bekomme ich einzeln die 66.12 bzw 36.94?
Viele Grüße
david
1. Nicht mit der CSV-Datei arbeiten, sondern mit der OpenOffice-Datei
2. Darin ordentliche Feldnamen definieren, z.B. SP1, SP2, SP3
3. In eine CSV-Datei exportieren und
4. Beides der Allgemeinheit zur Verfügung stellen.
LG
pah
Zitat von: stinch am 22 Februar 2015, 09:16:08
mein Problem ist, das z.B. bei pah's csv z.B. bei "StatusHWC2" 3 Werte (Sp1 - Sp3) angezeigt werden und alle als temp definiert sind:
re,,StatusHWC2,Speicher SP1 � SP3,,,,0F,,,temp;temp;temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
So sieht bei mir die Ausgabe aus:
localhost: r -v StatusHWC2 temp
temp=66.12 °C [Temperatur];temp=36.94 °C [Temperatur];temp=-13.94 °C [Temperatur]
Wie bekomme ich einzeln die 66.12 bzw 36.94?
Mit dem aktuellen Code aus dem master Branch kann man jetzt bei "read" den gewünschten Feldnamen mit einem Index versehen, um nur diesen einen zu erhalten, also bei Dir z.B.:
read -v StatusHWC2 temp.0
@john30
der Index funktioniert prima, getestet am Status Vaillaint, dieser beinhaltet 4x temp1!
pi@raspberry2 ~/ebusd/trunk $ ebusctl read -m 10 status temp1.0
31.0
pi@raspberry2 ~/ebusd/trunk $ ebusctl read -m 10 status temp1.1
31.0
pi@raspberry2 ~/ebusd/trunk $ ebusctl read -m 10 status temp1.2
32.0
pi@raspberry2 ~/ebusd/trunk $ ebusctl read -m 10 status temp1.3
34.0
pi@raspberry2 ~/ebusd/trunk $ ebusctl read -m 10 status
31.0;31.0;3.000;32.0;34.0;0
Vorlauf und Rücklauf war jetzt gleich (Index 0 + 1 ).
Schöne Grüße
Reinhart
Zitat von: Reinhart am 22 Februar 2015, 21:29:42
der Index funktioniert prima, getestet am Status Vaillaint, dieser beinhaltet 4x temp1!
Super, vielen Dank!
LG John
@ John30
ich habe am WE leider nicht so viel Zeit investieren können, aber zumindest laufen die Wolf-csv Dateien bei mir.
Allerdings bekomme ich nur Daten zurück. Keine Feldnamen, Einheiten oder Kommentare.
Ist das richtig so ?
So wie bei stinch sieht es zumindest nicht aus:temp=66.12 °C [Temperatur];temp=36.94 °C [Temperatur];temp=-13.94 °C [Temperatur]
sondern eher so:
2015-02-20 02:14:43.298 [update notice] update broadcast feuerung QQ=f1: 01;40;-;64.0;-;0;4
LG Elmar
:) ok. Wer lesen kann ist doch im Vorteil...
read [-v] [-f] [-m SECONDS] [-c CLASS] NAME [FIELD[.N]]
-v be verbose (include field names, units, and comments)
das war´s wohl denke ich...
LG Elmar
Hallo,
@John: super, vielen dank für das Update. Genau das habe ich gebraucht.
@pah: selbstverständlich werde ich, wenn ich neue codes identifiziert habe, diese hier teilen. leider fehlt mir dabei bisher noch etwas das knowhow. ich versuche mich einzuarbeiten. woher weiß ich, welcher datentyp verwendet wird. kann ich das aus dem antworttelegramm auslesen?
Viele Grüße
david
Zitat von: Tomy am 20 Februar 2015, 15:25:34
Meine Frage an euch - gibt es hier im Forum noch andere BARTL/OCHSNER/TEM Leidensgenossen, welche ebenfalls gerade am entschlüsseln der Codes sind, oder vielleicht schon das eine oder andere Datenpaket herausgefunden haben.
Ich bin sehr an einem Erfahrungsaustausch interessiert!
Die Fernwärme im Haus meiner Mutter hat auch eine TEM Regelung (2940 glaube ich) aber ich komme wohl nicht so schnell dazu mir das anzusehen.
Wie muss ich denn bei der Analyse vorgehen? ebusd gibt mir z.b. folgendes aus:
2015-02-23 15:27:09.029 [update notice] update SOL StatusSOL3 QQ=10: 10.0;4;31.5;0.0
2015-02-23 15:27:09.193 [update notice] unknown MS cmd: 1008b513020508c6 / 0000
2015-02-23 15:27:09.538 [update notice] unknown MS cmd: 1026b509030d04008c / 035f0200bc
2015-02-23 15:27:09.704 [update notice] update MIX StatusMIX2 QQ=10: 32;0;32.88;21
2015-02-23 15:27:09.872 [update notice] unknown MS cmd: 100ab504010db5 / 053f01008037a7
2015-02-23 15:27:10.074 [update notice] update BC DateTimeBC: 15:27:04;23.02.2015
2015-02-23 15:27:10.524 [update notice] update BC OutsideTempBC: 3.000
2015-02-23 15:27:11.031 [bus error] ERR: arbitration lost, retry
2015-02-23 15:27:11.094 [update notice] update BC DateTimeBC2: 15:27:04;23.02.2015
2015-02-23 15:27:11.375 [bus notice] poll pms00 BufferNtcTo: 20.19;0
2015-02-23 15:27:11.573 [update notice] unknown MS cmd: 10edb50701077a / 01009b
wenn ich jetzt z.b. die 3 zeile analysieren möchte? ich gebe ebusctl write -h 26b509030d04008c ein. dann erhalte ich "ERR: invalid argument" anstatt ein Ergebnis. oder mache ich da einen Fehler?
Viele Grüße
david
@ John30
Zitat von: elmar am 23 Februar 2015, 12:19:13
:) ok. Wer lesen kann ist doch im Vorteil...
read [-v] [-f] [-m SECONDS] [-c CLASS] NAME [FIELD[.N]]
-v be verbose (include field names, units, and comments)
das war´s wohl denke ich...
Klappt leider doch nicht.
Beispiel
r -m 10 regler
50.199;6.801;0;01;60.000r -v -m 10 regler
ERR: element not found? Was mache ich falsch ?
LG Elmar
Zitat von: stinch am 23 Februar 2015, 15:51:35
Wie muss ich denn bei der Analyse vorgehen?
Ich würde versuchen, Nachrichten mit gleicher ID zu identifizieren und die gesendeten und empfangenen Werte bspw. im Laufe eines Tages beobachten. Die Länge der ID hängt bei Vaillant meist vom PBSB Wert ab (das sind die zwei Bytes nach der Ziel-Adresse, also z.B. in "unknown MS cmd: 1008b513020508c6 / 0000" wäre das "b513"). Die Nachrichten von Vaillant platzieren m.W. noch mindestens ein weiteres ID-Byte hinter das Master-Datenlängen-Feld NN (hier wieder: nach PBSB=b513 potentiell "0508", also beide Datenbytes). Nun kann man bspw. mit Hilfe von grep über ein ebusd Logfile von einem Tag nach den unterschiedlichen Ausprägungen einer Nachricht suchen. Z.B.:
egrep "cmd: 1008b5130205" /var/log/ebusd.logVieles wurde ja bereits auf http://ebus.webhop.org/twiki/bin/view.pl/EBus/ServiceB5Vaillant (http://ebus.webhop.org/twiki/bin/view.pl/EBus/ServiceB5Vaillant) identifiziert bzw. es gibt irgendwo ein Openoffice Dokument darüber. pah hat daran glaub ich auch schon weitergearbeitet und im fhem contrib was neueres abgelegt.
Zitat von: stinch am 23 Februar 2015, 15:51:35
ich gebe ebusctl write -h 26b509030d04008c ein. dann erhalte ich "ERR: invalid argument" anstatt ein Ergebnis. oder mache ich da einen Fehler?
Die "8c" ist hier die CRC, die rechnet der ebusd selbst aus, deshalb beim "write -h" einfach weglassen.
Hm, vielleicht sollte ich besser die CRC beim "unknown cmd:" log weglassen, da steht ja eh nix interessantes drin...
Zitat von: elmar am 23 Februar 2015, 15:54:31
Klappt leider doch nicht.
Beispiel
r -m 10 regler
50.199;6.801;0;01;60.000
r -v -m 10 regler
ERR: element not found
? Was mache ich falsch ?
Nanu, das sieht nach einem Bug aus. Könntest Du mir bitte Deine config files schicken? Oder einfach die Ausgabe von "find -f regler" hier posten, das reicht auch schon.
Ok gerne....
ebusctl find -f regler
u,sollw,regler,Sollwertübertragung des Reglers an andere Regler,,fe,0800,,temp2,m,D2B,,°C,Temperatur,temp2,m,D2B,,°C,Temperatur,leistungszwang,m,D1B,,%,Leistungszwang,status,m,HEX:1,,,Status,temp2,m,D2B,,°C,Temperatur
Die cvs sind noch original aus dem 0.5.0. wir von Dir hochgeladen.
Die configs ist komplett default.
LG Elmar
Zitat von: elmar am 23 Februar 2015, 17:54:05
ebusctl find -f regler
u,sollw,regler,Sollwertübertragung des Reglers an andere Regler,,fe,0800,,temp2,m,D2B,,°C,Temperatur,temp2,m,D2B,,°C,Temperatur,leistungszwang,m,D1B,,%,Leistungszwang,status,m,HEX:1,,,Status,temp2,m,D2B,,°C,Temperatur
Ah verstehe. Dafür gibts noch ein TODO im Code, das als nächstes zur Lösung ansteht.
Momentan geht der verbose mode bei read nur für Nachrichten, die aktiv abgefragt werden können. Für broadcast geht das z.B. nicht. Sorry, dauert ein paar Tage, dann ist es erledigt.
@John30
OK! Alls klar.
Dann bin ich ja beruhigt. Hatte schon leichte Kriese hier :D
LG Elmar
Für die Analyse unbekannter Befehle ist es immer sinnvoll, die Struktur der Telegramme zu verstehen
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_eBUS_v0.6.0_mod.pdf
Das Thema "Datenbank" habe ich angefangen. Ab dem kommenden Montag habe ich einen neuen Mitarbeiter, den werde ich mal darauf ansetzen, in unseren Wordpress-Auftritt eine Seite mit Lesezugriff auf diese DB zu integrieren.
LG
pah
@drdownload
Ich bin bei der TEM Regelung /Bartl WP dran! hab schon die WP-Soll Temp, WP VL,WP RL, Aussentemperatur, WW Temp, Speicher Temp Mitte, WW Temp Soll herausgefunden - TEM benutzt teilweise einen anderen Base Data Type für die Temperaturen (Divider 10 in 1/10 °C Auflösung).
Dank John30 (Thanx!) konnte ich diesen Type in der _templates.csv einfügen, damit er auch gelesen werden kann.
Sobald ich meine Doku für die bisher gefundenen Werte erstellt habe, werde ich diese hier veröffentlichen - sofern Interesse besteht :-)
Grüße
Tomy
Nicht HIER. So etwas gehört ins FHEM Repository unter contrib.
LG
pah
??
d.h ich kann/soll die CSV Dateien hier nicht einfach an einen Post anhängen?
Mir wäre es ehrlich gesagt lieber, wenn es nicht im FHEM Respository landen würde. Immerhin ist der ebusd nicht FHEM spezifisch.
Genau dafür ist das Repository unter https://github.com/john30/ebusd-configuration (https://github.com/john30/ebusd-configuration). Hier würde ich gern alles sammeln, was zusammenkommt, auch nicht nur Vaillant.
Über pull requests kann man ja schon zusammenarbeiten und es könnte somit eine gute und erprobte Sammlung entstehen.
Die Verzeichnisstruktur muss vielleicht noch etwas justiert werden, die alten "libebus" Zweige könnte man ins attic schicken und aus ebusd-0.5.x bspw. ein "current" o.ä. machen.
LG John
hallo nochmals!
danke john und pah für eure antworten leider ist mein kleiner krank geworden und braucht nun volle aufmerksamkeit. deshalb werde ich erst die kommenden tage mit meinem ebus/fhem projekt weiter machen.
ich hoffe ich kann mich dann nochmals an euch wenden! ;-)
das einzige was ich bis jetzt mal gemacht habe, war ein scan mittels ebusctl der folgendes ergab:
pi@raspberrypi ~ $ ebusctl scan result
05;Joh. Vaillant GmbH & Co.;VD600;0213;7501
06;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
08;Joh. Vaillant GmbH & Co.;BAI00;0703;7401
0a;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
12;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
15;Joh. Vaillant GmbH & Co.;UI ;0501;6201
1c;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
52;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301
53;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301
75;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
ed;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
fc;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
kann es sein das vd600 die vrs620 ist? weis wer was solsy ist? und warum ich soviele teilnehmer habe?
fragen über fragen.....
weiters habe ich heute mal meine kontakte bei Vaillant kontaktiert ob die mir die eine aufschlüsselung der ebus telegramme zukommen lassen können. mal sehen was dabei raus kommt. zumindest klang es am telefon alles machbar.
danke und lg
mono
Zitat von: monoton am 23 Februar 2015, 23:50:24
leider ist mein kleiner krank geworden und braucht nun volle aufmerksamkeit.
dann mal gute besserung!
Zitat von: monoton am 23 Februar 2015, 23:50:24
05;Joh. Vaillant GmbH & Co.;VD600;0213;7501
06;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
08;Joh. Vaillant GmbH & Co.;BAI00;0703;7401
0a;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
12;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
15;Joh. Vaillant GmbH & Co.;UI ;0501;6201
1c;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
52;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301
53;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301
75;Joh. Vaillant GmbH & Co.;RC C ;0501;6201
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301
ed;Joh. Vaillant GmbH & Co.;PMS00;0107;4302
fc;Joh. Vaillant GmbH & Co.;PMW00;0117;4402
Das ist ja ne stolze Liste :-) Hast Du dem ebusd die Vaillant Configsfiles vom github spendiert?
Du könntest mal die Datei https://github.com/john30/ebusd-configuration/blob/master/ebusd-0.5.x/vaillant/scan.csv (https://github.com/john30/ebusd-configuration/blob/master/ebusd-0.5.x/vaillant/scan.csv) in das ebusd config Verzeichnis (z.B. /etc/ebusd) legen, dann würde der Scan noch die Produktnummern der Geräte ausgeben. Damit kann man etwas mehr über die Geräte herausfinden.
VD600 ist das vrnetDialog System, hab ich auch im Einsatz.
Die SOLSY Identifikation sieht in der Tat merkwürdig aus, die Adressen sind normalerweise Zirkulation, Warmwasser, Mischer für Heizkreis (ohne die "26", die kenn ich noch nicht). Kann gut sein, dass das SOLSY all das aus einem Guss liefert.
MC2 ist ein weiterer Mischer (hab ich auch).
RC C sind Raumregler, einer für den ersten und einer für den zweiten Heizkreis (sind bei mir auch im Einsatz).
Adresse ED ist klassicherweise Solarregler.
Für BAI00 und PM* gibts glaube ich schon Configfiles.
LG John
danke! wird schon wieder werden. bei den kleinen geht das ja schnell das sie mal krank werden, aber genauso schnell sind´s wieder gesund! :-)
danke für die info welche bedeutung die einzelnen identifikationen haben denke da steht mir noch einiges bevor...
hoffe wirklich das ich da nähere infos von vaillant bekomme.
habe das soeben nochmal mit der scan.csv durchlaufen lassen. ich habe aber öfters scannen müssen um alle ergebnisse zu erhalten, hatte öfters einen bus error (arbitration lost, retry)
05;Joh. Vaillant GmbH & Co.;VD600;0213;7501;21114300;200037180;082006429;N5
06;Joh. Vaillant GmbH & Co.;PMS00;0107;4302;21114300;200714883;110003697;N4
08;Joh. Vaillant GmbH & Co.;BAI00;0703;7401;21114400;100075083;100006309;N4
0a;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6
12;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6
15;Joh. Vaillant GmbH & Co.;UI ;0501;6201;21114500;20 804650;907005828;N6
1c;Joh. Vaillant GmbH & Co.;RC C ;0501;6201;21120200;200400790;907005119;N0
23;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
25;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
26;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
50;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
52;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301;21112730;6782<<<<0;907005639;N4
53;Joh. Vaillant GmbH & Co.;MC2 ;0500;6301;21112730;6782<<<<0;907005639;N4
75;Joh. Vaillant GmbH & Co.;RC C ;0501;6201;21120200;200400790;907005114;N0
ec;Joh. Vaillant GmbH & Co.;SOLSY;0500;6301;21114500;200804630;907005738;N5
ed;Joh. Vaillant GmbH & Co.;PMS00;0107;4302;21114300;200714883;110003697;N4
fc;Joh. Vaillant GmbH & Co.;PMW00;0117;4402;21114300;100072683;110002438;N6
lg und gn8 :)
mono
SOLSY liefert das tatsächlich "alles aus einem Guss" - das ist in der vrs620 Konfiguratiinsdatei bereits berücksichtigt.
LG
pah
Zitat von: monoton am 24 Februar 2015, 00:50:24
habe das soeben nochmal mit der scan.csv durchlaufen lassen. ich habe aber öfters scannen müssen um alle ergebnisse zu erhalten, hatte öfters einen bus error (arbitration lost, retry)
Das ist bei derart vielen Geräten nicht verwunderlich.
Was sagt denn die Buslast bei Dir ("ebusctl state")?
Es hilft vielleicht, die Anzahl der Wiederholungen bei Arbitrierungsverlust zu erhöhen (z.B. "ebusd --acquireretries=5") oder auch die Anzahl der Master auf dem Bus (z.B. "ebusd --numbermasters=7"), das sind bei Dir mit ebusd immerhin 7.
LG John
Hallo!
Ich logge fleißig meine Wolf-Anlage und versuche die Codierungen nach zu vollziehen.
Klappt (Dank diesem Forumsbeitrag!) soweit auch schon ganz gut
ich bekomme aber immer auch mal so etwas:
2015-02-24 13:16:53.435 [update notice] unknown BC cmd: 30fe50230924be0200005d01000045
2015-02-24 13:16:54.247 [update notice] unknown MS cmd: 0708502203de2a0217 / 025e10b3
2015-02-24 13:16:54.670 [update notice] unknown MS cmd: 07085022036176015d / 021400df
2015-02-24 13:16:55.701 [update notice] unknown MS cmd: 0751502203900f0011 / 02900114
Hat da jemand eine Idee dazu?
50 22 und 50 23 konnte ich bisher in keiner eBus Doku finden.
Auch was die die Sache mit dem Slash bedeuten könnte ?
LG Elmar
Zitat von: elmar am 24 Februar 2015, 13:30:38
unknown BC cmd: 30fe50230924be0200005d01000045
"BC" steht für broadcast, also eine Nachricht an alle Teilnehmer (auch erkennbar an der Ziel-Adresse "fe").
Zitat von: elmar am 24 Februar 2015, 13:30:38
unknown MS cmd: 0708502203de2a0217 / 025e10b3
Auch was die die Sache mit dem Slash bedeuten könnte ?
"MS" steht für master-slave, also eine Nachricht, die von einem Master and einen Slave gesendet wurde. Der Master war hier die "07" und der Slave die "08".
Der Master hat den ersten Teil der Nachricht geschickt (vor dem Slash) und der Slave mit dem zweiten Teil (hinter dem Slash) geantwortet, also vom Master:
QQ=07
ZZ=08
PBSB=5022
NN=03
DD=de2a02
CRC=17
und darauf die Antwort vom Slave:
NN=02
DD=5e10
CRC=b3
OK! soweit verstanden :)
... und bereits vermutet.
Müsste ich, wenn ich die Daten entschlüsselt habe, 2 Zeilen in der CSV-Datei erstellen?
1x für M und 1x für S ?
LG Elmar
Natürlich nicht.
Bitte erst einmal alles lesen, was schon da ist - dann braucht man nicht bei jedem Komma und jedem Schrägstrich zu fragen. Insbesondere das bereits mehrfach zitierte http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_eBUS_v0.6.0_mod.pdf.
So ein Dokument wird auch für das Zeug von Wolf benötigt.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 24 Februar 2015, 17:50:47
Bitte erst einmal alles lesen, was schon da ist - dann braucht man nicht bei jedem Komma und jedem Schrägstrich zu fragen. Insbesondere das bereits mehrfach zitierte http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_eBUS_v0.6.0_mod.pdf.
So ein Dokument wird auch für das Zeug von Wolf benötigt.
Entschuldige bitte, es kommt nicht wieder vor.
LG Elmar
"Nicht wieder" hat gar keiner verlangt - auch ich habe hier schon triviale Fragen gestellt, weil ich den Wald vor lauter Bäumen nicht gesehen habe.
Aber eben vielleicht nicht bei jedem Schrägstrich - denn das ist alles dokumentiert.
LG
pah
Alles klar... :)
... und danke an für die bisher geleistete Arbeit und Unterstützung.
/_ G Elmar
@John30
Hallo,
gerade aktualisierte ich ebusd aus letze beta bei yuhu auf deine Version 1.0.0 und ebusd behält sich seltsam.
Arch Linux, Raspberry Pi B+.
Solange ich die Kommandos in CLI benutze (direkt oder in einem Bash Skript), alles ist okay:
$ ebusctl read FanSpeed
0
$ tail -f /var/log/ebusd/ebusd.log
2015-02-24 21:21:36.496 [network info] [00013] connection opened 127.0.0.1
2015-02-24 21:21:36.497 [main notice] >>> read FanSpeed
2015-02-24 21:21:36.498 [main info] read cmd: ff08b509030d8300aa
2015-02-24 21:21:36.499 [network debug] [00013] wait for result
2015-02-24 21:21:36.506 [bus debug] switching from ready to send command
2015-02-24 21:21:36.569 [bus debug] switching from send command to receive command ACK
2015-02-24 21:21:36.575 [bus debug] switching from receive command ACK to receive response
2015-02-24 21:21:36.603 [bus debug] switching from receive response to send response ACK
2015-02-24 21:21:36.611 [bus debug] notify request: done
2015-02-24 21:21:36.611 [bus notice] read res: 040000ffff15
2015-02-24 21:21:36.611 [main notice] <<< 0
2015-02-24 21:21:36.618 [network info] [00013] connection closed
Sobald ich das selbe Skript durch systemd.service (https://en.wikipedia.org/wiki/Systemd (https://en.wikipedia.org/wiki/Systemd)) aufrufe, ebusd log sagt:
2015-02-24 21:13:35.776 [network info] [00001] connection opened 127.0.0.1
2015-02-24 21:13:35.779 [main notice] >>> read FanSpeed
2015-02-24 21:13:35.780 [main info] read cmd: ff08b509030d8300aa
2015-02-24 21:13:35.782 [network debug] [00001] wait for result
2015-02-24 21:13:35.797 [bus debug] switching from ready to send command
2015-02-24 21:13:35.862 [bus debug] switching from send command to receive command ACK
2015-02-24 21:13:35.868 [bus debug] switching from receive command ACK to receive response
2015-02-24 21:13:35.897 [bus debug] switching from receive response to send response ACK
2015-02-24 21:13:35.906 [bus debug] notify request: done
2015-02-24 21:13:35.906 [bus notice] read res: 040000ffff15
2015-02-24 21:13:35.907 [main notice] <<< 0
2015-02-24 21:13:35.909 [network debug] [00001] wait for result
[b]2015-02-24 21:13:35.910 [main notice] >>>[/b]
2015-02-24 21:13:35.914 [main notice] <<< usage:
read Read value(s) 'read [-v] [-f] [-m SECONDS] [-c CLASS] NAME [FIELD]'
write Write value(s) 'write CLASS NAME VALUE[;VALUE]*' or 'write -h ZZPBSBNNDx'
find Find value(s) 'find [-v] [-r] [-w] [-p] [-d] [-c CLASS] [NAME]'
listen Listen for updates 'listen [stop]'
state Report bus state 'state'
scan Scan seen slaves 'scan'
Scan all slaves 'scan full'
Report scan result 'scan result'
log Set log area(s) 'log areas AREA[,AREA*]' (AREA: main|network|bus|update|all)
Set log level 'log level LEVEL' (LEVEL: error|notice|info|debug)
raw Toggle log raw data 'raw'
dump Toggle raw dump 'dump'
reload Reload config files 'reload'
stop Stop the daemon 'stop'
quit Close connection 'quit'
help Print this help page 'help'
Print command usage 'help COMMAND'
2015-02-24 21:13:35.917 [network info] [00001] connection closed
2015-02-24 21:13:35.919 [bus debug] switching from send response ACK to send SYN
2015-02-24 21:13:35.931 [bus debug] ERR: SYN received during send SYN, switching to ready
2015-02-24 21:13:36.778 [network debug] dead connection removed - 0
Ich verstehe nicht die Zeile um 21:13:35.910 mit leerem Kommando.
2015-02-24 21:13:35.910 [main notice] >>>
Es kann sein, daß systemd nicht die richtige Umgebung setzt wie es im Terminal existiert. Dennoch, das systemd.service funktionierte gut mit ebusd von yuhu...
Hast du eine Ahnung was los ist?
P.S. Ich versuchte extra "newline" im Terminal, aber es verursachte nicht das oben geschriebenes Verhalten:
$ ebusctl read FanSpeed $'\n'
0
EDIT: Als provisorische Lösung filtriere ich den Output durch "head -1", so daß die andere Zeilen weggeschmissen werden.
Zitat von: MilanK am 24 Februar 2015, 22:01:12
Ich verstehe nicht die Zeile um 21:13:35.910 mit leerem Kommando.
2015-02-24 21:13:35.910 [main notice] >>>
Ja, diese Zeile irritiert mich auch. Im Moment habe ich keine Erklärung dafür.
Du könntest versuchen, die Unterschiede im ENV herauszufinden, indem Du systemd anstatt auf das ebusd binary auf ein shell script verweist, das dann wiederum den ebusd startet. Darin könntest Du mit "export" die ENV in ein log file schieben und dann mit Deiner login shell ENV vergleichen.
Zitat von: MilanK am 24 Februar 2015, 22:01:12
Es kann sein, daß systemd nicht die richtige Umgebung setzt wie es im Terminal existiert. Dennoch, das systemd.service funktionierte gut mit ebusd von yuhu...
Hast du den ebusd frisch gebuildet oder das install package verwendet?
Zitat von: MilanK am 24 Februar 2015, 22:01:12
P.S. Ich versuchte extra "newline" im Terminal, aber es verursachte nicht das oben geschriebenes Verhalten:
Das bringt sicher nichts.
Zitat von: john30 am 24 Februar 2015, 22:12:23
Ja, diese Zeile irritiert mich auch. Im Moment habe ich keine Erklärung dafür.
Du könntest versuchen, die Unterschiede im ENV herauszufinden, indem Du systemd anstatt auf das ebusd binary auf ein shell script verweist, das dann wiederum den ebusd startet. Darin könntest Du mit "export" die ENV in ein log file schieben und dann mit Deiner login shell ENV vergleichen.
Hm. Es half nicht. Ich stellte auch direkt im Skript die selbe ENV um, wie die in meiner login shell bestehenden - keine Verbesserung.
Sollte ich es so verstehen, daß es nicht nur mit Systemd auftaucht? (Ich nehme an, daß du Debian benutzt.) Es wäre 'gut', weil ab und zu ist das ein vergeblicher Kampf mit Systemd...
Zitat
Hast du den ebusd frisch gebuildet oder das install package verwendet?
Frisch gebuildet, von hier https://github.com/john30/ebusd/archive/v1.0.0.tar.gz untergeladen.
P.S. Später schaffe ich ein Pull Request in GitHub für meine CSV Datei und auch für das Arch Build Package.
Zitat von: MilanK am 24 Februar 2015, 22:40:58
Hm. Es half nicht. Ich stellte auch direkt im Skript die selbe ENV um, wie die in meiner login shell bestehenden - keine Verbesserung.
Kannst Du mir mal Deine "config.h" als PN schicken (oder einfach an ebusd (at) johnm.de)? Vielleicht fehlt Deinem Linux ja was grundlegendes.
In der aktuellen Version des ebusd werden immer zusätzliche Leerzeilen nach einem Ergebnis ausgespuckt.
Das führt m.E. zum
2015-02-24 21:21:36.611 [main notice] <<< 0
Ich halte systemd für eine ziemlich untransparente Sache, möglicherweise schickt er das als Echo wieder an den ebusd zurück.
LG
pah
Zitat von: MilanK am 24 Februar 2015, 22:40:58
Sollte ich es so verstehen, daß es nicht nur mit Systemd auftaucht? (Ich nehme an, daß du Debian benutzt.) Es wäre 'gut', weil ab und zu ist das ein vergeblicher Kampf mit Systemd...Frisch gebuildet, von hier
So, hab jetzt mal eine RPi Umgebung mit Arch Linux und schon beim compilieren wird klar, dass es Unterschiede in der Architektur bzw. den Defaults des Compilers zu geben scheint.
Ich werd das mal vertiefen.
Hallo zusammen,
ich habe bei mir mittlerweile seit ein paar Wochen (und Dank Euch allen!) meine Heizung ( vsc-146/5 inkl. vr68/3 ) via eBus-Koppler ausgelesen.
Die wichtigsten Sachen bekomme ich auch ausgelesen.
Leider scheitere ich an den SP1/SP2/KOL-Fühlern. Ich hätte gedacht, dass ich diese via "EC" auslesen kann, aber leider kommt da bei mir nichts sinnvolles zurück.
Also als Beispiel:
liefert "ebusctl read StatusHWC2":
16.00;0.00;112.00
Wobei hier 16.00 mit Sicherheit nicht die Temperatur am SP1 ist! ;-)
Na ja, SP3 ist bei mir nicht angeschlossen...
Ein Scan liefert mir übrigens folgendes Ergebnis:
2015-02-26 08:44:04.606 [bus event] scan: 08;Joh. Vaillant GmbH & Co.;BAI00;0604;5502
2015-02-26 08:44:07.678 [bus event] scan: 15;Joh. Vaillant GmbH & Co.;47000;0420;1403
2015-02-26 08:44:58.467 [bus event] scan: a0;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:44:58.587 [bus event] scan: a1;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:45:26.306 [bus event] scan: ec;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:45:38.465 [bus event] scan: 26;Joh. Vaillant GmbH & Co.;47000;0420;1403
Was sind hier a0 und a1 (scheint ja eine Vr68/3 Besonderheit zu sein!?)?
Weiß jemand Rat?
Viele Grüße
Jens
Zitat von: brainbubble am 25 Februar 2015, 14:28:16
Was sind hier a0 und a1 (scheint ja eine Vr68/3 Besonderheit zu sein!?)?
laut DB könnte zumindest a0 eine actoSTOR Einheit sein.
So, ich habs endlich geschafft, einen Converter für die viel zitierte MDB zu schreiben. Sieht schon ganz gut aus, aber es fehlen noch dutzende Datentypen, um bspw. die BAI00 daraus zu generieren. Meine Anlagenkonfiguration purzelt schon schön dabei raus. Als Input wird der Scan benötigt plus bei manchen Geräten die konkrete Variante (bspw. Sole-Wasser-WP, oder Festwert/Mischerkreis).
Jetzt könnte man sich so langsam mal um vernünftige Benamung Gedanken machen und da in den Generator einbauen...
Nächste Woche gibt weitere News dazu.
LG John
OK, Datenbank steht zur Verfügung.
LG
pah
@john: Nein, kann nicht sein, es ist nur ein vih-s 300 verbaut...
Aber: ich habe beim "ec" die passenden Register für SP2, KOL und Ertragsfühler entdeckt, ebenso die für den Ertragswert, er scheint aber nur "vortagsaktuell" zu sein.
Die Register sind tatsächlich komplett andere, als in pah's ods-Datei (z.B. 0100 für SP2). Liegt dann wohl am vr-68/3 Solarmodul.
Sollte jemand diese Daten benötigen:
ecb509030d0100 - SP2 (temp)
ecb509030d0300 - Ertragsfühler (temp)
ecb509030d0400 - KOL (temp)
ecb509030d3f08 - Solarer Ertrag (UIN)
EDIT: Solarer Ertrag war nicht ganz korrekt, es war der Wert für den Ertrag im Februar... :-D
Achtung, da steckt bei Vaillant eine etwas verquere Logik dahinter:
Bei der Statusabfrage (StatusSOL2 in meiner vrs620-Datei) wird der aktuelle Ertragswert angezeigt. Lies man den SolarYield einzeln aus, wird der Wert vom Vortag angezeigt, aber gleichzeitig der aktuelle Wert ins Register geschrieben. Ich hole mir also automatisch jede Nacht um kurz nach Mitternacht den Wert von SolarYield, und ziehe diesen vom Ertragswert aus StatusSOL2 ab - et voila, der Ertrag des heutigen Tages.
Die Ertragsmessung selber macht die vrs620 mit einem "erweiterten Modus" - solarer Vorlauf, Rücklauf und ein Durchflussmessgerät. Diese Berechnung gefällt mir noch gar nicht: Erstens traue ich dem Wert nicht, den die vrs620 daraus ermittelt. Und zweitens erfolgt das immer nur in ganzen kWh. Ich habe aber das Zählregister für die Impulse des Durchflusssensors noch nicht gefunden.
LG
pah
Zitat von: brainbubble am 25 Februar 2015, 14:28:16
2015-02-26 08:44:58.467 [bus event] scan: a0;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:44:58.587 [bus event] scan: a1;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:45:26.306 [bus event] scan: ec;Joh. Vaillant GmbH & Co.;sol00;0315;1002
2015-02-26 08:45:38.465 [bus event] scan: 26;Joh. Vaillant GmbH & Co.;47000;0420;1403
Was sind hier a0 und a1 (scheint ja eine Vr68/3 Besonderheit zu sein!?)?
Inzwischen kann ich berichten, dass Deine a0 eine DHW und a1 eine CP Einheit sind. Steht zumindest so in der DB...
Hallo zusammen,
ich hab es auch endlich geschafft und ebusd soweit zum Laufen bekommen. DANKE hierzu an John30 und pah für eure hervorragende Arbeit. Da ich nur eine Therme (VSC246) habe und keine Steuereinheit stellt sich mir die Frage ob ich direkt Werte (wie WW Temp etc., actoStor AN/AUS) setzen kann. In der BAI00 sind leider bisher nur "read"-Werte drin. Da ich keine Steuereinheit habe, kann ich die Writes nicht loggen ... hat vielleicht einer von Euch schon Writes auf einer BAI00 eingesetzt?
LG Texel
Hallo, hab soeben ein altes Excelfile mit den writes gefunden.
habe das csv entsprechend ergänzt:
*r,bai00,,,,08,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*w,bai00,,,,08,B509,0E,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
(...)
r;w,,StorageTempDesired,d.07 => Speichertemperatur Soll,,,,0400,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Gesendet wird wohl etwas:
localhost: w bai00 StorageTempDesired 54.00
done
allerdings ändert sich der WW Wert in der Terme nicht:
localhost: r StorageTempDesired
55.00
Woran könnte es liegen? (vielleicht weil kein calormatic angeschlossen ist, d.h. die Terme reagiert dann nicht auf eBus Schreibbefehle?)
LG Texel
Doch, sollte sie. Wenn man die richtigen Befehle hat. Was geht denn als binäres Datenwort raus ?
LG
pah
Hallo,
Ich habe es mal "von Hand" probiert:
Write -h 08 b5 09 05 0e 04 00 a0 03
(Soll heißen, setze WW Temp auf a0 03 = 58.00 Grad...)
Es kommt ein 00 zurück.
Wenn ich dann die StorageTempDesired lese, kommt 02 70 03 zurück (also 70 03 = 55.00 Grad).
?
LG Texel
Sollte eigentlich stimmen. Tut es aber nicht...
Bin leider im Moment etwas unter Wasser.
LG
pah
Hallo zusammen,
nach einiger Zeit als passiv Mitlesender melde ich mich auch wieder zu Wort.
Erstmal großes Lob an alle hier für die Weiterentwicklung und natürlich an john30 für das neue GIT-Repository, das mittlerweile recht umfangreiche WIKI und das Bereitstellen von .deb-Dateien.
@alle:
Frage:
Wie kann ich das Logging in /var/log/ebusd.log reduzieren?
Ich verwende noch ebusd 0.50 erstellt am 29.12.2014, da ich leider noch keine Zeit für ein Update hatte.
Meine Frage: Wie kann ich den Dämon starten, mit LOGLEVEL=ERR?
Nach 3 Monaten Produktiv-Betrieb ist meine LOG-Datei auf 440MB angestiegen, obwohl ich dieses Log gar nicht brauche.
Geht hier ja auch in gewisser Weise um die Schonung der SD-Karte.
Ich bin in Linux nicht so tief drin, aber müsste ich in /etc/init.d/ebusd ansetzen?[/i]
start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --exec $DAEMON -- $EBUSD_OPTS
Kann ich hier irgendwie die -- $EBUSD_OPTS setzen auf LOGLEVEL=ERR?
Ich hatte zunächst versucht, in /etc/ebusd/ebusd.conf, diesen Eintrag zu setzen.
Nach Neustart von ebusd wächst die Log-Datei allerdings kontinuierlich weiter.
loglevel=ERR
Einen Reboot überlebt leider nicht:
Mittels SSH auf den Raspi, dort bei laufendem Daemon ebusctl eingegeben, dann "log loglevel error" scheint den gewünschten Effekt zu haben.
Aber überlebt das einen Reboot?
@texel:
Eventuell hatte ich das gleiche Problem wie du auch schon mal, siehe meinen Beitrag weiter vorne.
http://forum.fhem.de/index.php/topic,29737.msg251270.html#msg251270
Mir ist es nicht gelungen, die Warmwasser-Soll-Temperatur zu setzen, auch bei mir kam immer 0.0 als Rückmeldung beim Write und beim Read wurde die alte, an der Calormatic gesetzte Temperatur, angezeigt.
Das Thema Warmwasser hatte ich deshalb erstmal zurückgestellt.
Viele Grüße,
Heiko
@heikoh81
betreffend des Logfiles kannst du ja in der /etc/logrotate.d/ebusd das Logrotate nach deinen Bedürfnissen anpassen.
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
rotate 7 bedeutet hier 7 Files ablegen, täglich eines (daily). Sind die 7 Files da, wird das älteste gelöscht, daher der Name Logrotate!
So hast du nie mehr als 7 komprimierte alte Logs + das aktuelle. Natürlich kannst auf weniger verkürzen, nur wenn du gezielt einen Fehler suchst, dann kannst schlechter was finden.
John hat auch die Möglichkeit gegeben nach Loglevel zu loggen, dann müsstest du die Start-Options in /etc/default/ebusd ändern.
Bei mir ist es so eingestellt:
EBUSD_OPTS="-l /var/log/ebusd -d /dev/ttyUSB0 -p 8888"
Ich persönlich finde jedoch die Logrotate als die bessere Wahl, weil es alle Möglichkeiten erlaubt (loggen + archivieren + nach X Tagen löschen)
Du musst jedoch auf die letzte Version updaten, in den älteren Versionen gabs da Bugs mit dem Log und dem Logrotate!
LG
Reinhart
Danke für deine Antwort.
Logrotate kenne ich schon, allerdings läuft der Raspi dediziert für den ebusd-Adapter neben der Therme.
Mir geht es um die Langlebigkeit der SD-Karte im 24/7-Betrieb, deshalb möchte ich den Log ganz abschalten.
Bei mir gibt es keine /et/default/ebusd - gab's die bei Version 0.5 noch nicht?
Wie wäre denn der Standard-Inhalt - nur die von dir gepostete Zeile mit meiner benötigten Option:
EBUSD_OPTS="-l ERR"
Der bessere Weg ist, das Logging auf eine Ramdisk zu leiten.
LG
pah
Ramdisk wäre sicher auch eine gute Lösung, aber auch nur wenn auf "error" beschränkt wurde, sonst reicht das Ram unter Umständen nicht aus.
Aber auf die Frage von dir zurück zu kommen wie die richtige Syntax lautet bzw. wo man die Config Files bekommt.
Wenn du den ebusd ausgecheckt und compiliert hats, dann befindet sich auf dem Raspi das Verzeichnis /home/pi/ebusd-master/contrib/etc/ und hier sind alle Files die du für eine ordentliche Konfiguration des eBus Dämons benötigst. Wenn die Installationsrotine dies noch nicht erledigt hat, dann kopiere diese Files nach /etc/Unterverzeichnisname/Filename (zB: /etc/default/ebusd). Die Originalfiles heißen. xxxx.debian, diese sind natürlich umzubenennen.
Ich benutze davon:
default
EBUSD_OPTS="--logfile /var/log/ebusd --loglevel error -d /dev/ttyUSB0 -p 8888"
so wird nur der Eintrag "error" nach /var/log/ebusd geloggt
ebusd
hier liegen die csv
init.d
Standart Dämon Startrotine
logrotate.d
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
Aber bitte die letzte Version von John seinem GIT nehmen, sonst funktionieren wie bereits erwähnt einige Dinge nicht richtig.
Bei den Preisen der SD Karten ist es mir egal ob die nach einem Jahr hin ist, aber das muss jeder selbst entscheiden wie er das möchte, da möchte ich dir nichts dreinreden. Eine aktuelle Sicherung (Image) habe ich immer am Pc gespeichert.
LG
Reinhart
Pardon, aber das ist Unsinn. Selbst wenn das Logging auf "All" steht, passt das in den RAM meines Raspberry bestens hinein.
Außerdem muss natürlich der Watchdog nicht nur die Präsenz des ebusd überwachen und diesen ggf. neu starten, sondern auch nach verfügbarem Speicher schauen.
LG
pah
@pah
Natürlich hast du recht, wenn alles ok ist kann es keine Probleme geben, nur wenn Fehler auftreten kann man das anwachsen der Logs nicht voraussehen, aber dann ist eh die SD auch zugemüllt. Heikoh hatte ja erwähnt, er habe schon über 400Mb Log, das wäre dann allerdings etwas knapp. Nur hat er das Logrotate nicht aktiviert gehabt. Darum habe ich ihm ja empfohlen das Logrotate auf jeden Fall zu aktivieren und zusätzlich soll er noch die Ramdisk aktivieren und einhängen. Dann kann eigentlich nichts mehr schiefgehen und der Raspi (SD) möge lange leben!
Ich habe mir jetzt spaßeshalber am Raspi B+ (512Mb Ram) auch eine Ramdisk mit 100 Mb erstellt und die ganze /var/log ausgelagert. Ich werde in den nächsten Wochen das Verhalten beobachten. Welche Größe hast du auf deinem Raspi eingestellt? 300 Mb sollten ja in etwa frei zur Verfügung stehen.
@heikoh81
Die Anleitung zur Einrichtung der Ramdisk findest du hier: http://www.lexxi.at/2013/11/29/so-lebt-mein-raspberry-langer/ (http://www.lexxi.at/2013/11/29/so-lebt-mein-raspberry-langer/)
Die Befehle alle mit "sudo" ausführen.
pi@raspberry2 ~ $ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 5,7G 2,4G 3,1G 44% /
/dev/root 5,7G 2,4G 3,1G 44% /
devtmpfs 214M 0 214M 0% /dev
tmpfs 44M 236K 44M 1% /run
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 88M 0 88M 0% /run/shm
/dev/mmcblk0p5 60M 15M 45M 25% /boot
/dev/root 5,7G 2,4G 3,1G 44% /var/log.hdd
ramlog-tmpfs 100M 5,7M 95M 6% /var/log
wenn alles passt, sollte die ramlog-tmpfs (hier ganz unten) auftauchen und die /var/log eingehängt sein.
Mär 12 11:48:46 Enabling ramlog... [ OK ]
Mär 12 11:54:20 Enabling ramlog... [ OK ]
Mar 12 11:55:22 Stopping ramlog: Error: ramlog is not running [fail]
Mar 12 11:55:25 Starting ramlog-tmpfs 2.0.0: [ OK ]
nach dem ersten Reboot solltest du die Logdatei ramlog kontrollieren ob die Ramdisk auch gestartet wurde.
LG
Reinhart
Eine Woche "All" -> ca. 100 MB.
LG
pah
Danke, habe ich auch so eingestellt.
Schöne Grüße
Vielen Dank für eure vielen Hinweise zum Logging, und danke an Reinhart für die Schritt-für-Schritt-Anleitung.
Ramdisk ist definitiv auf der ToDo-Liste, das Tool Ramlog werde ich auf dem ebusd-Raspi vermutlich nicht verwenden, da reicht mir tempfs, weil ich auch bei Stromausfall eigentlich keine Sicherung brauche.
Anders sieht es für mein Produktiv-FHEM-System aus, da ist Ramlog ein Thema.
Das kopieren der contrib-Datei nach /etc/default/ebusd, Rechte 0644, Owner root, war übrigens die Lösung:
EBUSD_OPTS="--logfile /var/log/ebusd --loglevel error"
Jetzt wächst mein Log nicht mehr - Ziel erreicht.
Sobald ich Zeit finde, werde ich meinen Ebusd-Raspi auf Version 1.0 tagesaktuell aus dem GIT hochziehen - vorher natürlich ein SD-Image anfertigen, man weiß ja nie...
Viele Grüße,
Heiko
Zitat von: texel am 11 März 2015, 15:09:36
Write -h 08 b5 09 05 0e 04 00 a0 03
(Soll heißen, setze WW Temp auf a0 03 = 58.00 Grad...)
Es kommt ein 00 zurück.
Laut MDB is "0400" nur lesbar, also bringt es nichts, den Wert zu schreiben.
Ich nehme an, am Controller muss das eingestellt werden, nicht am "Brenner". Und der wird dann entsprechende B504/B505 Kommandos produzieren und die Solltemperatur dann wieder ins eigene "0400" Register ablegen.
Ein Ramlog kommt für mich definitiv nicht in Frage, denn bei einem potentiellen Stromausfall oder einem anderen Problem inkl. Verlust des RAM Inhalts ist dann zwangsweise auch das Log weg, was mich in so einem Fall sicher interessieren würde...
Zitat von: john30 am 12 März 2015, 21:54:35
Laut MDB is "0400" nur lesbar, also bringt es nichts, den Wert zu schreiben.
Ich nehme an, am Controller muss das eingestellt werden, nicht am "Brenner". Und der wird dann entsprechende B504/B505 Kommandos produzieren und die Solltemperatur dann wieder ins eigene "0400" Register ablegen.
Hallo zusammen,
Erstmal danke für die Tips!
Ich vermute auch, es liegt daran, dass ich keinen Controller habe und die Werte über B5 09 generell auf dem Brenner nicht geschrieben werden. Aber irgendwelche Befehle muss es ja geben, damit der "echte" Controller die Werte auf dem Brenner 08 setzen kann. ich hab es alternativ mit B5 10 probiert:
Write -h 08 B5 10 09 00 00 78 78 FF FF 00 FF 00
Rückmeldung 0101 (was auch immer 01 bedeutet). ... Ergebnis: leider wieder keine Änderung am Brenner
gibt es andere B5 09 Befehle die ein direktes schreiben auf den Brenner zulassen (damit ich testen kann, ob der Brenner überhaupt etwas annimmt)? bzw. Gibt es noch andere Befehle neben B5 09 od. B5 10 die ein direktes Schreiben auf den Brenner 08 zulassen?
LG Texel
@texel
Ich habe es jetzt getestet und die VRC 430 ausgebaut, dann kann ich zwar alles was die Therme selbst betrifft (Fanspeed etc.) auslesen, aber zB. keine Heizkurve lesen oder schreiben. Diese Register sitzen in der VRC 430 und wenn die fehlt gibt es ja auch keine witterungsgeführte Steuerung. Das betrifft alles was bei mir in der vrc430.csv eingetragen ist, wenn das Steuergerät selbst fehlt funktionieren diese nicht.
EBUS: unexpected answer "ERR: read timeout\n\n" received (wrote "r mcHeatingCurve\n", expected \d+\.\d+\n\n)
Timeout bei fehlender VRC430 laut Log Fhem
2015-03-13 08:24:35.088 [main error] read: ERR: read timeout
und so schaut die Fehlermeldung direkt am Bus aus.
Ich habe meine Calormatic 430 auch gebraucht um 120.-gekauft weil ich unbedingt eine Außentemperatursteuerung haben wollte und bin sehr zufrieden damit, ist aber immer ein gewisses Restrisiko dabei. Eine 470 wie du sie brauchst sind ja auch schon unter 200.- zu haben. zB: http://www.willhaben.at/iad/kaufen-und-verkaufen/moebel-wohnen-buero/vaillant-raumthermostat-calormatic-470-3-114573664?adId=114573664 (http://www.willhaben.at/iad/kaufen-und-verkaufen/moebel-wohnen-buero/vaillant-raumthermostat-calormatic-470-3-114573664?adId=114573664)
So wie das aussieht wirst du ohne Controller wohl nicht auskommen.
LG
Reinhart
Aber warum denn nicht ? Man muss "nur" herausfinden, mit welchen Befehlen sich der externe Regler bei der Therme anmeldet.
Also: Therme laufen lassen. VRC430 ausschalten. Therme ausschalten. 10 Minuten warten. Therme einschalten. 10 Minuten warten. VRC430 einschalten - und mitloggen (Option "All"), was die VRC430 auf den Bus schreibt.
Auch bitte mal auslesen das Register 0400 (mit 08 B509 0400) => "Digitaler Regler erkannt"
LG
pah
Zitat von: john30 am 12 März 2015, 21:57:32
Ein Ramlog kommt für mich definitiv nicht in Frage, denn bei einem potentiellen Stromausfall oder einem anderen Problem inkl. Verlust des RAM Inhalts ist dann zwangsweise auch das Log weg, was mich in so einem Fall sicher interessieren würde...
für einen Entwickler ist das Ramlog aus diesem Grund nicht so ideal. Aber im Prinzip ist es für den Normaluser nicht schlecht, vor allem erstellt das Ramlog jeden Tag in der Früh eine Sicherung (habe ich auch nicht gewusst und ist mir heute Früh aufgefallen) des aktuellen Inhalts nach /var/log.hdd so hat man wenigstens was in zum Nachschauen. Wobei wenn es crasht, will man meist den letzten Eintrag des Logs sehen.
LG
Reinhart
@pah
das von dir vorgeschlagene auszulesende Register liefert bei mir "invalid argument"
pi@raspberry2 ~ $ ebusctl scan result
08;Joh. Vaillant GmbH & Co.;BAI00;0518;7401;21091300;100043400;001005056;N0
15;Joh. Vaillant GmbH & Co.;43000;0215;2002;21110900;200285150;907006374;N5
26;Joh. Vaillant GmbH & Co.;43000;0215;2002;21110900;200285150;907006374;N5
pi@raspberry2 ~ $ ebusctl write -h 08b509030d7600
033c00009c
pi@raspberry2 ~ $ ebusctl write -h 08b5090400
ERR: invalid argument
LG
Reinhart
Zitat von: Reinhart am 13 März 2015, 17:54:33
das von dir vorgeschlagene auszulesende Register liefert bei mir "invalid argument"
pi@raspberry2 ~ $ ebusctl write -h 08b5090400
ERR: invalid argument
Hier fehlt sicher das Längenbyte hinter b509...
Zitat von: Prof. Dr. Peter Henning am 13 März 2015, 13:12:07
Aber warum denn nicht ? Man muss "nur" herausfinden, mit welchen Befehlen sich der externe Regler bei der Therme anmeldet.
Also: Therme laufen lassen. VRC430 ausschalten. Therme ausschalten. 10 Minuten warten. Therme einschalten. 10 Minuten warten. VRC430 einschalten - und mitloggen (Option "All"), was die VRC430 auf den Bus schreibt.
Hallo zusammen,
wäre jemand bereit dies zu tun? Ich würde das Logfile dann analysieren und die Anmeldebefehle bei meiner Therme testen. Es sollte am besten eine VRC430 / BAI00 Kombi sein. Ergebnisse poste ich dann hier, dann hilft es vielleicht auch anderen...
Vielen Dank!
LG Texel
also ich habe jetzt einmal den VRC430 ausgebaut (Aus/Einschalten kann ich den nicht), die Therme abgeschaltet und dann schrittweise wieder alles eingeschaltet. Dabei musste ich den Raspi mit dem ebus auch neu booten, weil der nach dem Ausbau des VRC430 immer die Meldung schrieb:
[bus notice] signal acquired
so richtig sehen kann ich im Log nichts wenn der Regler (im laufenden Betrieb) eingesetzt wird.
Hier die wesentlichen Ausgaben:
2015-03-14 09:16:25.366 [main notice] >>> r fillpressure press.0
2015-03-14 09:16:25.490 [bus notice] read res: 0333080057
2015-03-14 09:16:25.491 [main notice] <<< 2.099
# nach dieser Druckabfrage den VRC430 eingesteckt
2015-03-14 09:18:14.511 [update notice] unknown MS cmd: 1008b50401003d / 0a00570510fffffffff004b5
2015-03-14 09:18:14.772 [update notice] unknown MS cmd: 1008b513030664ff40 / 01019a
2015-03-14 09:18:19.608 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 09:18:23.716 [update notice] update bai00 StatusTHER QQ=10: 52.0;38.0;4.938;30.0;40.0;0
2015-03-14 09:18:27.915 [update notice] unknown BC cmd: 10feb5050229002c
2015-03-14 09:18:28.207 [update notice] unknown MS cmd: 1008b50401003d / 0a00110610fffffffff004ff
2015-03-14 09:18:28.475 [update notice] unknown MS cmd: 1008b51101028a / 05033c964664c6
2015-03-14 09:18:28.730 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-14 09:18:38.083 [update notice] unknown MS cmd: 1008b512020064ae / 0000
2015-03-14 09:18:38.369 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 09:18:43.795 [update notice] update bai00 StatusTHER QQ=10: 39.0;38.0;4.938;31.0;40.0;0
2015-03-14 09:18:45.730 [update notice] update broadcast outsidetemp QQ=10: 2.938
2015-03-14 09:18:47.817 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 09:18:53.828 [update notice] update bai00 StatusTHER QQ=10: 38.0;37.0;4.938;31.0;40.0;0
2015-03-14 09:18:57.800 [update notice] update MS SetBoiler: 1;77.0
Ich hänge das ganze Log hier an und habe es mit den wesentlichen Schritten des Aus/Ein Status kommentiert. Das Register 0400 kann ich nicht abfragen weil ich die richtige Syntax nicht kenne. Die einzige Antwort die ich auf 08b509 xx0d0400 bekomme ist die hier, aber die ist immer gleich (mit oder ohne VRC430), also ist das ein anderer Wert.
pi@raspberry2 /etc/init.d $ ebusctl write -h 08b509030d0400
0220034b
hier noch meine Geräte am Bus:
pi@raspberry2 ~ $ ebusctl scan result
08;Joh. Vaillant GmbH & Co.;BAI00;0518;7401;21091300;100043400;001005056;N0
15;Joh. Vaillant GmbH & Co.;43000;0215;2002;21110900;200285150;907006374;N5
Ich hoffe ihr könnt mit dem Log was anfangen.
LG
Reinhart
ich habe mir jetzt das Tageslog nochmals genau angesehen, jedesmal beim Einstecken des VRC430 kommen während im Display "Loading .." angezeigt wird diese Sequenzen:
2015-03-14 07:58:09.317 [update notice] unknown MS cmd: 1008b50401003d / 0a00001410ffffffffc00375
2015-03-14 07:58:09.576 [update notice] unknown MS cmd: 1008b513030664ff40 / 01019a
2015-03-14 08:32:15.543 [update notice] unknown MS cmd: 1008b50401003d / 0a00482310ffffffff400469
2015-03-14 08:32:15.802 [update notice] unknown MS cmd: 1008b513030664ff40 / 01019a
2015-03-14 09:18:14.511 [update notice] unknown MS cmd: 1008b50401003d / 0a00570510fffffffff004b5
2015-03-14 09:18:14.772 [update notice] unknown MS cmd: 1008b513030664ff40 / 01019a
2015-03-14 09:29:02.954 [update notice] unknown MS cmd: 1008b50401003d / 0a00051710ffffffff200571
2015-03-14 09:29:03.179 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-14 09:29:15.277 [update notice] unknown MS cmd: 1008b513030664ff40 / 01019a
Es beginnt immer mit der b504 01 003d gefolgt von b513 03 0664.
Die b504 wird im laufenden Betrieb auch alle 30 Sekunden gemeldet, die b513 nur beim Einstecken einmalig.
Beim letzten Versuch um 09:29 war auch einmal der b505 02 0400 dabei.
LG
Reinhart
Sage ich doch, dass man das rausbekommen kann ... :)
LG
pah
Hallo Reinhart,
Vielen Dank fürs Loggen!
Hab mir das mal bei meiner Therme angesehen.
der b5 04 (ich habe den mit Write geschrieben - update befehl gibt es ja nicht) bringt bei mir eine ähnliche (aber nicht identische Sequenz zurück). Wenn ich danach einen Write auf die VL Temp absetzt kann ich leider immer noch nicht schreiben. War also wohl nicht der Inititialisierungsbefehl.
Der Write auf 8b513030664ff kommt mit einem Read timeout zurück. (?)
Interessant ist noch der SetBoiler (B5 10). Allerdings ändert dieser die Temperatur auch nicht ..
Write -h 08 B5 10 02 01 40. Return 01 01
LG Texel
Der Set Boiler erscheint alle 10 Sekunden und ist in der VRC430.cvs eingetragen und wird offensichtlich vom Steuergerät zyklisch abgefragt.
u,MS,SetBoiler,VL Soll,10,08,B510,00,,,status;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Die beiden anderen Werte kann ich auch über ebusctl abfragen, scheint eventuell so eine Art Identifizierung (b513) des VRC430 zu sein. Die Werte vom b504 zählen irgendwie hoch, könnte daher ein Zeitstempel enthalten sein.
Bei dir ist ja kein VRC430 vorhanden, das würde deine Nichtantwort von b513 bestätigen, das sie nicht da ist. Wie das Zusammenspiel jetzt mit der 0400 verläuft, kann man daher nur weiter spekulieren.
pi@raspberry2 ~ $ ebusctl write -h 08b5040100
0a00202816ffffffff200504
pi@raspberry2 ~ $ ebusctl write -h 08b513030664ff
01019a
Im Prinzip wissen wir jetzt noch nicht recht viel mehr als vorher, nur dass eben diese beiden Telegramme über den Bus kommen wenn der Controller eingesteckt wird.
LG
Reinhart
habe nun noch eine interessante Beobachtung gemacht.
Wenn ich am Stellrad der Therme den Warmwasserregler leicht drehe, dann wird ständig der b513 gesendet, jedoch immer mit selben Inhalt. Ich habe immer um 1 Grad erhöht und gewartet bis das Display wieder zurück springt (etwa 1 Sekunde). Dann erneut 1 Grad. Aber diesmal sind es keine 08-er sondern 315-er!
2015-03-14 15:58:21.841 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:58:25.820 [update notice] update bai00 StatusTHER QQ=10: 36.0;36.0;4.938;35.0;37.0;0
2015-03-14 15:58:27.867 [update notice] update broadcast vdatetime QQ=10: 16:54:59;14.03.2015
2015-03-14 15:58:28.124 [update notice] unknown MS cmd: 1008b512020064ae / 0000
2015-03-14 15:58:29.897 [update notice] update MS SetBoiler: 1;77.0
# am Handregler Warmwasser der Therme leicht gedreht
2015-03-14 15:58:32.842 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 15:58:32.953 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 15:58:33.064 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 15:58:35.882 [update notice] update bai00 StatusTHER QQ=10: 36.0;36.0;5.125;35.0;37.0;0
2015-03-14 15:58:40.281 [update notice] unknown MS cmd: 1008b50401003d / 0a00325816ffffffff20051e
2015-03-14 15:58:40.549 [update notice] unknown MS cmd: 1008b51101028a / 05033c964668ca
2015-03-14 15:58:40.802 [update notice] unknown MS cmd: 1008b512020064ae / 0000
2015-03-14 15:58:50.189 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:58:56.055 [update notice] update bai00 StatusTHER QQ=10: 36.0;36.0;5.125;35.0;37.0;0
2015-03-14 15:58:57.994 [update notice] update broadcast outsidetemp QQ=10: 3.125
2015-03-14 15:59:00.087 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:06.090 [update notice] update bai00 StatusTHER QQ=10: 36.0;36.0;5.125;35.0;37.0;0
2015-03-14 15:59:08.066 [update notice] unknown MS cmd: 1008b51101028a / 05033c964668ca
2015-03-14 15:59:10.070 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:14.100 [update notice] update bai00 StatusTHER QQ=10: 36.0;36.0;4.938;35.0;37.0;0
2015-03-14 15:59:16.104 [update notice] unknown MS cmd: 1008b50401003d / 0a00095916fffffffff004db
2015-03-14 15:59:16.330 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-14 15:59:20.093 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:24.087 [update notice] update bai00 StatusTHER QQ=10: 35.0;36.0;4.938;35.0;37.0;0
2015-03-14 15:59:30.104 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:34.123 [update notice] update bai00 StatusTHER QQ=10: 35.0;35.0;5.125;35.0;37.0;0
2015-03-14 15:59:36.113 [update notice] update broadcast vdatetime QQ=10: 16:56:07;14.03.2015
2015-03-14 15:59:36.364 [update notice] unknown MS cmd: 1008b512020064ae / 0000
# am Handregler Warmwasser der Therme leicht gedreht
2015-03-14 15:59:37.696 [update notice] unknown MS cmd: 0315b513030600000e / 01019a
2015-03-14 15:59:37.759 [update notice] unknown MS cmd: 0315b513030600000e / 01019a
2015-03-14 15:59:37.869 [update notice] unknown MS cmd: 0315b513030600000e / 01019a
2015-03-14 15:59:37.976 [update notice] unknown MS cmd: 0315b513030600000e / 01019a
2015-03-14 15:59:40.112 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:44.135 [update notice] update bai00 StatusTHER QQ=10: 35.0;35.0;5.125;35.0;37.0;0
2015-03-14 15:59:46.136 [update notice] unknown MS cmd: 1008b50401003d / 0a00395916fffffffff0042d
2015-03-14 15:59:46.408 [update notice] unknown MS cmd: 1008b51101028a / 05033c964668ca
2015-03-14 15:59:50.116 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 15:59:54.143 [update notice] update bai00 StatusTHER QQ=10: 35.0;35.0;4.938;35.0;37.0;0
2015-03-14 15:59:56.089 [update notice] update broadcast outsidetemp QQ=10: 2.938
2015-03-14 15:59:58.140 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:00.036 [main notice] >>> write vrc430 mcHeatingCurve 1.00
2015-03-14 16:00:00.114 [bus notice] read res: 0000
2015-03-14 16:00:00.114 [main notice] <<< done
2015-03-14 16:00:06.572 [update notice] update bai00 StatusTHER QQ=10: 35.0;35.0;4.938;35.0;37.0;0
2015-03-14 16:00:08.569 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:14.579 [update notice] update bai00 StatusTHER QQ=10: 35.0;35.0;4.938;35.0;37.0;0
2015-03-14 16:00:16.581 [update notice] unknown MS cmd: 1008b50401003d / 0a00110017fffffffff004f8
2015-03-14 16:00:16.802 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-14 16:00:18.586 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:24.602 [update notice] update bai00 StatusTHER QQ=10: 36.0;35.0;4.938;35.0;37.0;1
2015-03-14 16:00:28.590 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:32.609 [update notice] update bai00 StatusTHER QQ=10: 44.0;35.0;4.938;35.0;37.0;1
2015-03-14 16:00:34.611 [update notice] update broadcast vdatetime QQ=10: 16:57:06;14.03.2015
2015-03-14 16:00:34.862 [update notice] unknown MS cmd: 1008b512020064ae / 0000
2015-03-14 16:00:38.621 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:42.635 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;37.0;1
2015-03-14 16:00:44.633 [update notice] unknown MS cmd: 1008b50401003d / 0a00400017fffffffff004e4
2015-03-14 16:00:44.909 [update notice] unknown MS cmd: 1008b51101028a / 05033c964668ca
2015-03-14 16:00:48.658 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:00:52.634 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;37.0;1
2015-03-14 16:00:54.574 [update notice] update broadcast outsidetemp QQ=10: 2.938
2015-03-14 16:00:58.646 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:01:02.671 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;36.0;1
# am Handregler Warmwasser der Therme leicht gedreht
2015-03-14 16:01:03.862 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 16:01:03.974 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 16:01:04.037 [update notice] unknown MS cmd: 0315b5130306640063 / 01019a
2015-03-14 16:01:04.630 [update notice] unknown MS cmd: 1008b51101028a / 05033c96466ac8
2015-03-14 16:01:08.647 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:01:12.641 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;36.0;1
2015-03-14 16:01:14.671 [update notice] unknown MS cmd: 1008b50401003d / 0a00110117fffffffff0042e
2015-03-14 16:01:14.897 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-14 16:01:16.687 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:01:22.661 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;36.0;1
2015-03-14 16:01:26.668 [update notice] update MS SetBoiler: 1;77.0
2015-03-14 16:01:32.679 [update notice] update bai00 StatusTHER QQ=10: 43.0;35.0;4.938;35.0;36.0;1
2015-03-14 16:01:34.689 [update notice] update broadcast vdatetime QQ=10: 16:58:06;14.03.2015
2015-03-14 16:01:34.942 [update notice] unknown MS cmd: 1008b512020064ae / 0000
LG
Ich habe jetzt wie im GIT-WIKI beschrieben 1.0.0 kompiliert (vorher alles gebackupt), und es klappt leider noch nicht reibungslos.
Fehler:
Gelöst: Pfad des DEAMON in der /init.d/ebusd geändert auf /usr/bin/local/ebusd
@john30: Dies ist noch ein Bug, oder? Habe genauso installiert wie in der WIKI beschrieben. Weiterhin wird das init.d-Skript mit make install nicht automatisch kopiert und eingerichtet, obwohl die WIKI dies suggeriert.
Das init.d-Skript wurde nicht automatisch kopiert, habe ich manuell gemacht und mit
update-rc.d ebusd defaults
am System angemeldet.
Trotzdem startet ebusd nicht beim Reboot.
Viele Grüße,
Heiko
Gelöst:
Mit read -f werden wieder Live-Werte gelesen.
Mein Problem waren gecachte Werte.
Ich habe nun vielmehr das Problem, dass meine writes aus fhem heraus nicht mehr klappen.
Ich habe das write in der ECMD-Datei bereits wie von pah weiter vorne geschrieben auf write -c ... angepasst, trotzdem kommen meine Befehle nicht an.
Bsp.:
# TagtemperaturSchreiben
get TagtemperaturSchreiben cmd {"write -c vrc430 mcDesiredTemp ".Value("VaillantTagtemperaturSollEinstellen")."\n"}
get TagtemperaturSchreiben expect ".*\n"
get TagtemperaturSchreiben postproc {\
}
bewirkt nichts.
In ebusctl:
localhost: write -c vrc430 mcDesiredTemp 21.0
done
localhost: read -c vrc430 mcDesiredTemp
21.5
==> auch keine Änderung.
Update:
Nach einigen Minuten (manchmal 5min oder mehr) erscheint der per write gesetzte Befehl dann tatsächlich auch mit dem Read.
@heikoh81
betreffend dem Pfad des ebusd, hast du bei der autogen.sh den Pfad auch gesetzt?
Ich mache es immer so wie ich hier einmal geschrieben habe: http://forum.fhem.de/index.php/topic,29737.msg260289.html#msg260289 (http://forum.fhem.de/index.php/topic,29737.msg260289.html#msg260289)
Dann dürfte auch das Problem des Dämonstarts gelöst sein, denn du musst einmalig die Runlevel Scripte aktualisieren (letzte Zeile) damit der eBus Dämon in die Startroutine aufgenommen wird.
LG
Reinhart
Zitat von: Reinhart am 14 März 2015, 21:49:47
betreffend dem Pfad des ebusd, hast du bei der autogen.sh den Pfad auch gesetzt?
Nein, weil laut Wiki:
Zitat
Configure your directory structure
The default destination of the compiled ebusd binary is /usr/local/bin/ebusd. If that's fine for you, simply type:
In der Bsp. init.d-Datei im contrib-Verzeichnis ist der Standard-Pfad aber /usr/bin, also passt das nicht zusammen.
Für Anfänger oder Linux-nicht-Experten eventuell bei ersten Gehversuchen nicht so leicht zu durchschauen...
@heikoh81
hast du noch deine Orginal cvs eingesetzt?
Ich habe meine alten wieder genommen (bzw angepasst), weil die neuen bei der vrc430 nicht funktionierten. Da wurden unter anderem einige Namen geändert.
LG
Es ist meine Original _templates.csv und Vaillant_Protokoll_kurz.csv.
Ich habe die einfach in /etc/ebusd gelassen, und das Dateidatum ist auch noch von meiner letzten Änderung.
also ich schreibe noch so und das funktioniert, auch über FHEM.
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write vrc430 mcHeatingCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*"
get HeizkurveSchreiben postproc { $_ }
pi@raspberry2 ~ $ ebusctl write vrc430 mcHeatingCurve 0.20
done
LG
Also interessant:
Wähle ich in FHEM einen neuen Wert, erscheint dieser als Wunschtemp. auf der Calormatic nach ca. 1-2 Sekunden (war glaub auch schon mit 0.5.0 so).
Der read-Befehl liefert aber noch
ewig den alten Wert - und irgendwann nach zufälliger Zeit den neuen.
Woran kann das liegen?
War bei 0.5.0 nicht so, da kam der neue Wert sofort im Read.
Wird da irgendwas gecached?
UPDATEDa wird tatsächlich was gecached.
https://github.com/john30/ebusd/wiki/3.-Commands
Zitat
Read value(s) from a configured message. The result can either be returned from the cache (without accessing the eBUS at all) or retrieved directly from the slave by querying it via the eBUS.
read -f
==> -f force reading from the bus (same as '-m 0')
Und tatsächlich:
localhost: read -c vrc430 mcDesiredTemp
21.0
localhost: read -f -c vrc430 mcDesiredTemp
21.5
(Beide Befehle innerhalb von 2 Sekunden abgesendet).
Das ist wohl die Änderung in der 1.0.
Dann werde ich meinen Reads wohl überall das -f hinzufügen - möchte immer die aktuellen Werte auslesen!
ja das ist komisch, ich lese alles ohne Parameter und bekomme den Wert sofort!
# Heizkurve lesen
get HKurve cmd {"r mcHeatingCurve\n"}
get HKurve expect "\d+\.\d+\n\n"
get HKurve postproc {$_}
zum Glück habe ich das was nicht gelesen!
LG
@heikoh81
ich habe jetzt viel getestet, aber ich schaffe es nicht, das mir der Wert verzögert ausgegeben wird. Ob ich mit "-f" oder nur mit "-c" oder ohne abfrage, erhalte ich den neuen SollWert immer sofort. Vielleicht ist das noch ein spezifisches Verhalten zwischen Master und Slave. Aber mit "-f" kann es sicher nicht schaden, den umsonst ist ja der Parameter nicht eingebaut worden. Der Parameter "-c" filtert ja nur gezielt auf die Klasse (vrc430) Eventuell verhält sich das nicht bei jedem Wert gleich? Kannst du vielleicht einmal mit der Heizkurve testen?
pi@raspberry2 ~ $ ebusctl read -f mcheatingcurve
1.10
pi@raspberry2 ~ $ ebusctl read -c vrc430 mcheatingcurve
1.10
pi@raspberry2 ~ $ ebusctl read mcheatingcurve
1.10
hier im Beispiel habe ich den neuen Sollwert 1.10 vorgegeben und sofort in der Konsole die 3 Kommandos abgesetzt.
LG
Reinhart
Hi,
ich habe jetzt das USB interface zusammen gelötet und es wird auch erkannt, hängt aber noch nicht am ebus.
Gibt es andere Funktionstests, Spannungen, die da sein müssen?
Auch find ich den ebusd code nicht mehr auf github.
Wo ist denn bitte der aktuelle code?
in contrib sind ja nur config Dateien
Thx!
Hallo Joachim
am besten du hängst das Interface an den Bus und stellst den Regler ein bis du einen vernünftigen Output in der Konsole bekommst. In der Konsole startest du wie folgt (sollte aber dann kein Dämon laufen, nur zum testen)
ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888
Den eBus installieren kannst du wie folgt direkt am Raspberry:
svn co https://github.com/john30/ebusd
cd /home/pi/ebusd/trunk
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp /home/pi/ebusd/trunk/contrib/etc/init.d/ebusd.debian /etc/init.d/ebusd
sudo chmod 755 /etc/init.d/ebusd
sudo update-rc.d ebusd defaults
wenn der erste Befehl nicht funktioniert musst du noch das SVN installieren.
sudo apt-get install Subversion
und eventuell noch:
sudo apt-get install autoconf
sudo apt-get install automake
Dann solltest du noch die /etc/default/ebusd anpassen:
EBUSD_OPTS="-l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888"
so wird einmal alles nach /var/log/ebusd.log mitgeloggt
wenn du die paar Schritte ausgeführt hast, den Raspberry einmal booten und dann schauen ob der Dämon läuft:
pi@raspberry2 /usr/bin $ ps -aux|grep ebusd
root 2677 0.4 0.5 36396 2604 ? Ssl Mär14 3:24 /usr/bin/ebusd -l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888
pi 3119 0.0 0.3 3596 1688 pts/1 S+ 09:41 0:00 grep --color=auto ebusd
pi@raspberry2 /usr/bin $
Hallo,
nach einer etwas längeren Pause komme ich nun wieder dazu, mich dem ebus zu widmen. Ich hatte meinen Koppler vom Hersteller überprüfen lassen. Dieser scheint allerdings bestens zu finktionieren.
Folgendes Phänomen habe ich hier: Wenn ich den ebusd laufen lasse, steigt er nach ca. einem Tag aus und gibt nur noch die Fehlermeldung "Err: Arbitration lost" zurück. Ich habe gestern die aktuelle Version aus dem git installiert (1.0.0), hatte das Problem aber auch schon mit 0.5. Ich habe den ebusd gestartet und nur alle paar Stunden mal einen Wert abgerufen. In FHEM habe ich ihn noch nicht wieder eingebunden. Die LED des Kopplers blinkt wie im normalen Betrieb.
USB-Koppler trennen und wieder verbinden hilft nicht. Ebenso hilft seltsamer Weise ein kompletter Neustart des RPi nicht. Ich bin leider etwas ratlos, wo ich den Fehler suchen könnte :-\ Legt der ebusd irgendwelche Dateien im Betrieb an, die ihn evtl. daran hindern, die Werte zu empfangen? Kann das etwas mit dem timing beim Empfang/Senden zu tun haben?
schöne Grüße
Jo
Hallo Jojo11!
Ich habe ja diese Meldungen auch, aber meist nur wenn FHEM gerade Abfragen macht und die zyklischen Telegramme der VRC430 kommen, so wie hier im Beispiel, mitten in der Abfrage kommt eine update notice:
2015-03-15 13:10:02.528 [main notice] <<< 1095
2015-03-15 13:10:02.547 [main notice] >>> r BurnerStartsHWC
2015-03-15 13:10:02.662 [bus notice] read res: 0211098c
2015-03-15 13:10:02.662 [main notice] <<< 2321
2015-03-15 13:10:02.682 [main notice] >>> r OperatingHoursHC
2015-03-15 13:10:02.801 [bus notice] read res: 027b2ab7
2015-03-15 13:10:02.802 [main notice] <<< 10875
2015-03-15 13:10:02.821 [main notice] >>> r OperatingHoursHWC
2015-03-15 13:10:02.939 [bus notice] read res: 02b108e2
2015-03-15 13:10:02.939 [main notice] <<< 2225
2015-03-15 13:10:02.959 [main notice] >>> r FanOperatingHours
2015-03-15 13:10:02.998 [bus error] ERR: arbitration lost, retry
2015-03-15 13:10:03.082 [update notice] unknown MS cmd: 1008b51101028a / 05033c964666c4
2015-03-15 13:10:03.350 [bus notice] read res: 029f35ce
2015-03-15 13:10:03.350 [main notice] <<< 857.94
2015-03-15 13:10:03.366 [main notice] >>> r BurnerFaults
2015-03-15 13:10:03.484 [bus notice] read res: 01019a
2015-03-15 13:10:03.485 [main notice] <<< 1
2015-03-15 13:10:03.504 [main notice] >>> r BurnerStartFaults1
2015-03-15 13:10:03.619 [bus notice] read res: 010299
2015-03-15 13:10:03.619 [main notice] <<< 2
2015-03-15 13:10:07.105 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:11.101 [update notice] update bai00 StatusTHER QQ=10: 31.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:13.101 [update notice] unknown MS cmd: 1008b50401003d / 0a00384814ffffffff200fde
2015-03-15 13:10:13.321 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-15 13:10:15.145 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:21.154 [update notice] update bai00 StatusTHER QQ=10: 31.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:25.180 [update notice] update MS SetBoiler: 1;77.0
2015-03-15 13:10:31.189 [update notice] update bai00 StatusTHER QQ=10: 30.0;31.0;15.125;31.0;36.0;0
2015-03-15 13:10:33.235 [update notice] update broadcast vdatetime QQ=10: 14:07:03;15.03.2015
2015-03-15 13:10:33.490 [update notice] unknown MS cmd: 1008b512020064ae / 0000
20
Laut John und pah ist das aber normal, weil das eben gleichzeitige Aktivitäten am eBus sind. Wenn bei dir aber dieser Fehler erst nach einem Tag auftritt, kann es doch nur in irgend einer Hardware liegen, oder? Ich habe heute das ganze Log bei mir durchforstet und seit Mitternacht etwa 30 solcher Errors gehabt, welche aber den normalen Betrieb absolut nicht stören. Ich frage aber alle 6 Minuten 19 Werte ab und FHEM steuert zwischendurch noch die Heizkurve.
Wenn du jetzt nichts abfragst sondern nur lauscht, dann kann es ja theoretisch auch eine andere Einheit sein die da am eBus solche Kollisionen hervorruft und dein Koppler meldet diese einfach. Wenn sich ab diesem Zeitpunkt dann nichts mehr tut kannst ja am Regler ein paar Kommandos absetzen (irgendwas ändern) und schauen ob die einerseits überhaupt an der Therme ausgeführt werden und wenn ja ob diese dann in der Konsole sichtbar ist. Wieviele Devices hast du denn am eBus hängen?
Eventuell auch einmal schauen ob die ebusd auch wirklich nur einmal am Raspi läuft. Ich hatte in der Anfangsphase auch mehrere Tasks laufen, da ist dann nichts mehr vorhersehbar.
Was machst du denn, das du den Koppler (eBus) dann wieder zum Laufen bekommst?
LG
Reinhart
@Jojo11
was mir noch eingefallen, du kannst ja einmal die Rawdata loggen.
Dazu einfach in der /etc/default/ebusd diese Optionline aktivieren (ändern und speichern) und dann einen Restart des ebusd durchführen.
EBUSD_OPTS="--logfile /var/log/ebusd --lograwdata -d /dev/ttyUSB0 -p 8888"
Dann siehst du zumindest was sich da am Bus tut und welche Bytes hier noch empfangen werden. Musst halt einen Tag so laufen lassen bis der Fehler kommt. Wenn du dann den Inhalt postest, kann John das sicher erklären.
LG
Hallo Reinhart,
vielen Dank für Deine Tipps. Das log-file habe ich mal erstellt (s. Anhang). Ich habe nur ab und zu mal DisplayRoomTemp abgerufen, was wie folgt definiert ist:
*r,vc470f,,,,15,B509,0D,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,DisplayRoomTemp,display room temp,,,,8000,,,temp,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Wie ich den ebus jetzt wieder ans Laufen bringe weiß ich ehrlich gesagt nicht. Alles stromlos setzen und warten hilft glaube ich. Aufgrund akuten Zeitmangels hatte ich für eine systematische Fehlersuche leider noch keine Zeit. Langsam glaube ich, der RPi läuft nicht rund.
schöne Grüße
Jo
das Log müsste sich John einmal ansehen, ob ich mit meiner Vermutung richtig liege.
Was ich darin sehe ist die Tatsache, dass dein Koppler ständig "FF" sendet bis er mit der "arbitration lost" abbricht. Dann kommen am Bus ein paar zyklische Daten und er beginnt sofort wieder zu senden, als möchte er das Paket quittieren.
2015-03-15 19:45:35.598 [bus notice] <46
2015-03-15 19:45:35.602 [bus notice] <8c
2015-03-15 19:45:35.606 [bus notice] <78
2015-03-15 19:45:35.610 [bus notice] <f5
2015-03-15 19:45:35.615 [bus notice] <00
2015-03-15 19:45:35.615 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-15 19:45:35.619 [bus notice] <aa
2015-03-15 19:45:35.662 [bus notice] <aa
2015-03-15 19:45:35.705 [bus notice] <aa
2015-03-15 19:45:35.706 [bus notice] >ff
2015-03-15 19:45:35.749 [bus notice] <aa
2015-03-15 19:45:35.750 [bus notice] >ff
2015-03-15 19:45:35.792 [bus notice] <aa
2015-03-15 19:45:35.793 [bus notice] >ff
2015-03-15 19:45:35.796 [bus notice] <10
2015-03-15 19:45:35.796 [bus error] ERR: arbitration lost,
2015-03-15 19:45:35.797 [main error] read: ERR: arbitration lost
2015-03-15 19:45:35.807 [bus notice] <08
hier so eine typische Situation, 1/10 Sekunde nachdem ein Wert am Bus gelesen wurde, beginnt der Koppler FF zu senden. Ich hoffe, ich deute das Log jetzt richtig. Ich kenne den Koppler den du verwendest leider nicht, aber man müsste einmal versuchen das Sendesignal zu unterbinden. Wenn das alles zugebaut ist, dann könnte man theoretisch eine Diode in Serie zum eBus Anschluß schalten. Also bei einem Draht vom eBus Anschluß des Kopplers eine Diode dazwischen schalten. Wenn sie verkehrt rum ist, dann empfängt er nichts mehr, dann einfach umdrehen. Den Versuch wäre es wert, falls du eine Diode herumliegen hast. (1N4148 oder 1N4007 etc.)
Bei mir sieht das ganz anders aus, mein selbstgebauter Koppler sendet niemals ">ff" !
PS: habe mir die Schaltung von pah nochmals angesehen, das mit der Diode wird nicht funktionieren, weil beim Senden zieht er einfach den High-Pegel auf etwa 8 Volt (LOW) herunter. Ich nehme an dein Buskoppler wird ja eine ähnliche Schaltung sein, zumindest dieselbe Funktion.
LG
Zitat von: Reinhart am 15 März 2015, 09:56:47
ich habe jetzt viel getestet, aber ich schaffe es nicht, das mir der Wert verzögert ausgegeben wird. Ob ich mit "-f" oder nur mit "-c" oder ohne abfrage, erhalte ich den neuen SollWert immer sofort.
Zwischenzeitlich läuft bei mir alles, und ich habe meine ECMD-Dateien entsprechend angepasst, dass jetzt die Werte mit Force abgerufen werden.
Gecachte Werte brauche ich nicht :-)
Bei Werten, die über Broadcast kommen (z.B. Außentemperatur), führt -f übrigens zu 0.0 - weil man Broadcast-Messages vermutlich nirgends anfordern kann.
Zitat von: Jojo11 am 15 März 2015, 13:20:00
Folgendes Phänomen habe ich hier: Wenn ich den ebusd laufen lasse, steigt er nach ca. einem Tag aus und gibt nur noch die Fehlermeldung "Err: Arbitration lost" zurück. Ich habe gestern die aktuelle Version aus dem git installiert (1.0.0), hatte das Problem aber auch schon mit 0.5.
Auch ich habe gelegentlich, vielleicht so 20-30 mal am Tag, diese Arbitration Lost.
Es funktioniert aber alles normal, sowohl lesen als auch schreiben.
====
Insgesamt habe ich jetzt auch Ramlog installiert & Logrotate für das ebusd-log, das mit loglevel error läuft.
Soweit alles gut mit 1.0.0.
Nochmal dank an alle.
@heikoh81
Super wenn nun bei dir auch alles klappt, ja es waren einige Änderungen von 0.5 auf 1.0, ich habe alle Zwischenschritte mitgemacht. Ich bin sehr zufrieden mit dem eBus und schon lange im Produktiv Betrieb.
Die Außentemperatur hole ich über die bai00.csv und nicht über den Status dann klappt es auch mit "-f".
pi@raspberry2 ~ $ ebusctl r -f -c bai00 outsidetemp
12.94;ok
bai00.csv
r,,OutsideTemp,d.47 => Außentemperatur ,,,,7600,,,tempsensor,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
LG
Reinhart
Zitat von: Jojo11 am 15 März 2015, 19:54:24
Wie ich den ebus jetzt wieder ans Laufen bringe weiß ich ehrlich gesagt nicht. Alles stromlos setzen und warten hilft glaube ich. Aufgrund akuten Zeitmangels hatte ich für eine systematische Fehlersuche leider noch keine Zeit. Langsam glaube ich, der RPi läuft nicht rund.
Hallo Jo,
was hast Du denn genau für ein eBUS Interface? Hängt der via USB dran und wenn ja, mit welchem Chipsatz? Falls nein, hängt er an der RPi GPIO UART? Die macht gravierende Timing Probleme, weil der UART so eingestellt ist, dass bis zu 16 Bytes gecacht werden, was einen Sendebetrieb in der Form völlig unmöglich macht (wegen der Arbitration).
Fragen über Fragen :-)
LG John
Zitat von: heikoh81 am 15 März 2015, 22:05:31
Bei Werten, die über Broadcast kommen (z.B. Außentemperatur), führt -f übrigens zu 0.0 - weil man Broadcast-Messages vermutlich nirgends anfordern kann.
Hallo Heiko,
mit welcher Version hast Du das denn so? Also frisch von GIT oder Release 1.0.0 oder was anderes?
Das klingt mir sehr nach dem Bug, den ich auch gern fixen würde...
LG John
Zitat von: john30 am 20 März 2015, 20:55:56
Hallo Jo,
was hast Du denn genau für ein eBUS Interface? Hängt der via USB dran und wenn ja, mit welchem Chipsatz? Falls nein, hängt er an der RPi GPIO UART? Die macht gravierende Timing Probleme, weil der UART so eingestellt ist, dass bis zu 16 Bytes gecacht werden, was einen Sendebetrieb in der Form völlig unmöglich macht (wegen der Arbitration).
Fragen über Fragen :-)
LG John
Hallo John,
Ich habe den ebus-Koppler von eservice über USB am RPi. Der Koppler wurde gerade überprüft und ist in Ordnung. Timing-Probleme hatte der Hersteller auch im Verdacht in meinen Fall.
schöne Grüße
Jo
Zitat von: heikoh81 am 14 März 2015, 21:55:24
Nein, weil laut Wiki:
In der Bsp. init.d-Datei im contrib-Verzeichnis ist der Standard-Pfad aber /usr/bin, also passt das nicht zusammen.
Für Anfänger oder Linux-nicht-Experten eventuell bei ersten Gehversuchen nicht so leicht zu durchschauen...
Okay, Danke für den Hinweis! Werde den default prefix bei Verwendung der autogen.sh auf /usr einstellen.
Zitat von: Jojo11 am 15 März 2015, 19:54:24
ebusd.zip
Aus Deinem Log ist ersichtlich, dass Du überhaupt nicht auf den Bus senden kannst, weil alle Versuche, die eigene Adresse zu schicken (>ff) in einem Timeout enden sobald die AUTO-SYN Einheit wieder ein SYN Zeichen produziert (<aa).
Also irgendwas ist da definitiv nicht in Ordnung. Ich würde jetzt spontan mal auf Lietungspegel oder Leitungslänge tippen, aber das ist jetzt schwer zu sagen, ohne Deine physische Umgebung zu kennen.
Nachtrag:
Ein Gutes hat Dein Log allerdings für sich: Es zeigt, dass ebusd mit dieser Situation nicht klar kommt (also dass er überhaupt nichts senden kann). Das muss ich noch fixen, löst aber sicher nicht Dein Problem.
Nachtrag 2: doch nicht, es dauert nur ne Weile, aber dann kommt brav ein "ERR: arbitration lost", was ja auch stimmt.
Super, danke erstmal für die Rückmeldung. Dann schaue ich mir das Kabel doch mal an. Der controller wurde wie geschrieben kontrolliert und sendet wohl auch zuverlässig.
schöne Grüße
Jo
Danke Reinhart,
Habe den demon jetzt auf meinem Odroid C1 am laufen, habe den ebus mal drangehängt, empfange aber über den gesamten Bereich des Potis nur:
odroid@SmartHome:~$ tail /var/log/ebusd.log
2015-03-22 21:03:39.483 [bus notice] signal acquired
2015-03-22 21:03:41.019 [bus error] signal lost
2015-03-22 21:03:47.445 [bus notice] signal acquired
2015-03-22 21:03:49.031 [bus error] signal lost
Zitat von: joachimS am 22 März 2015, 11:40:33
Danke Reinhart,
Habe den demon jetzt auf meinem Odroid C1 am laufen, habe den ebus mal drangehängt, empfange aber über den gesamten Bereich des Potis nur:
odroid@SmartHome:~$ tail /var/log/ebusd.log
2015-03-22 21:03:39.483 [bus notice] signal acquired
2015-03-22 21:03:41.019 [bus error] signal lost
2015-03-22 21:03:47.445 [bus notice] signal acquired
2015-03-22 21:03:49.031 [bus error] signal lost
Da würd ich mal das raw logging aktivieren, dann solltest Du relativ schnell sehen, wohin das Poti muss :-)
Es sollte dann ungefähr alle 40ms ein "<aa" da stehen, was das SYN Symbol ist.
So, ich hab jetzt mal einen Schwung generierter config Files auf https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de gepostet.
Die sind alle aus der sagenumwobenen vrnet***log MDB (Version 2.6.0.2 von 2010) generiert und somit lassen sich natürlich alle anderen enthaltenen Geräte theoretisch auch durch den Generator jagen. Ich habs jetzt aber erstmal auf Geräte beschränkt, die hier auch schon mal erwähnt wurden.
Jedes Gerät (sprich jede Slave-Adresse) hat jetzt seine eigene Datei, das ist übersichtlicher und hilft auch bei einer zukünftigen Auto-Selektion durch ebusd.
Die Nomenklatur der einzelnen Nachrichten, Datentypen und Felder ist nach wie vor work in progress und über konstruktive Vorschläge freue ich mich natürlich.
Ach ja, falls jemand eine neuere MDB zur Verfügung stellen kann (via PN), wäre das natürlich auch sehr hilfreich!
LG John
@john30
Kurzes Feedback zu den Config Files.
Das erste CSV File für meine VRC430 (43000.csv) das sofort zu 98% funktioniert und sehr viele Datenpunkte enthält. Ich bin immer noch am testen was nun so alles abgefragt werden kann.
2 Datenpunkte habe ich ändern müssen weil sie bei mir einen Fehler produzieren:
pi@raspberry2 /etc/init.d $ ebusd --checkconfig
2015-03-22 18:34:04.902 [main notice] Performing configuration check...
Error reading "/etc/ebusd/vrc430.csv" line 10 field 14 value "Aktueller Wochentag": ERR: element not found
Erroneous item is here:
"r","","ActualWeekday","Wochentag","","","","5F00","","","bday","","","Aktueller Wochentag"
^
Error reading "/etc/ebusd/vrc430.csv" line 17 field 14 value "heating curve of the first heating circuit": ERR: element not found
Erroneous item is here:
"r","","Hc1HeatCurve","Heizkurve Heizkreis 1","","","","3100","","","curve","","","heating curve of the first heating circuit"
Wenn du das jetzt wirklich mit einem Generator aus der MDB erzeugen kannst, ist das eine enorme Arbeitserleichterung und vermeidet Fehler.
Bei allen anderen Files die ich bis jetzt verwendet habe musste ich viele Anpassungen durchführen, weil eben eine VRC470 andere Datenpunkte hat als eine VRC430.
Danke dir für die viele Mühe.
Schöne Grüße
Reinhart
Zitat von: Reinhart am 22 März 2015, 19:48:45
2 Datenpunkte habe ich ändern müssen weil sie bei mir einen Fehler produzieren:
Ah, cool, Danke fürs Testen!
Hast Du den aktuellen Quellcode aus dem master Branch genommen, oder bist Du auf einer älteren Quelle?
Und sind die _templates.csv auch aus dem neuen vaillant_de oder anders?
LG John
@John30
habs von deinem Masterbranch genommen, habe auch den Fehler schon gefunden, lag bei mir.
Da du die _templates erweitert hast, funktionieren die neuen CSV natürlich nur wenn die auch gleichzeitig getauscht wird.
Bei der bai00.csv allerdings gibt es negative Werte, die terminieren mit "out of valid range"
pi@raspberry2 /etc/init.d $ ebusd --checkconfig
2015-03-22 19:52:49.374 [main notice] Performing configuration check...
Error reading "/etc/ebusd/bai00.csv" line 118 field 12 value "-100": ERR: argument value out of valid range
Erroneous item is here:
"r","","HEATSwitchactionsDK","d.82 Schaltspiele Heizbetrieb","","","","2900","","","UIN","-100","","Schaltspiele Heizbetrieb"
^
Error reading "/etc/ebusd/bai00.csv" line 119 field 12 value "-100": ERR: argument value out of valid range
Erroneous item is here:
"r","","HwcSwitchactionsDK","d.83 Schaltspiele BW Betrieb","","","","2300","","","UIN","-100","","Schaltspiele WW Betrieb"
LG
Reinhart
Was um Himmels Willen ist gemeint mit "Datenpunkt"?
LG
pah
Was um Himmels Willen ist gemeint mit "Datenpunkt"?
LG
pah
Zitat von: Reinhart am 22 März 2015, 21:20:22
Bei der bai00.csv allerdings gibt es negative Werte, die terminieren mit "out of valid range"
pi@raspberry2 /etc/init.d $ ebusd --checkconfig
2015-03-22 19:52:49.374 [main notice] Performing configuration check...
Error reading "/etc/ebusd/bai00.csv" line 118 field 12 value "-100": ERR: argument value out of valid range
Erroneous item is here:
"r","","HEATSwitchactionsDK","d.82 Schaltspiele Heizbetrieb","","","","2900","","","UIN","-100","","Schaltspiele Heizbetrieb"
Nanu, das wurde bei meinem config check gar nicht bemängelt...
Die -100 ist natürlich wieder was spezielles, da muss ich in die DB schauen, was das soll.[/code]
Zitat von: Prof. Dr. Peter Henning am 22 März 2015, 22:18:40
Was um Himmels Willen ist gemeint mit "Datenpunkt"?
Vaillant Nomenklatur für alle "d.01" etc. Werte.
Hallo, bin neu hier und daher erst ein paar Zeilen über mich.
Ich habe eine Vailant VSC 196/3-5 By 2012 und VRC 430 ohne Solarpanels.
Da ich im Internet gelesen hatte, dass man hier einiges über den EBus machen kann ich mir vor ein paar Wochen einen Ebus Adapter gebaut und mich in Linux Ubuntu 14 eingearbeitet.
Gar nicht so einfach mit den ganzen Berechtigungen. Nach tagelanger Recherche im Internet (Yuhu war down) bin ich dann auf die Seite von John30 gestoßen der das Thema ebus übernommen hatte.
Hierfür erst mal vielen Dank an John dafür.
Der EBus läuft auch mittlerweile aber trotz vielen Recherchen bleiben einige Fragen die ich hier mal einstellen möchte.
Denke das meiste sind einfache Fragen die ich als Anfänger nur noch nicht weiß.
1.) Ich starte ebusd -f, wie kann ich diesen stoppen ohne den Rechner runter zu fahren.
2.) Ich habe die Config Daten für Vailant 0.5 alle unter etc/ebusd (nicht Default) abgespeichert und mit 755 versehen. Denke da dürfen aber nur ausgewählte Files hin da ich viele Fehler bekomme.
3.) Es gibt die .csv und .ods files. Denke die sind entweder/oder
4.) Was muss/soll in den zu erstellenden "default Ordner" hatte hier erstmal die .csv Daten abgespeichert.
5.) Seit ein paar Tagen gibt es eine umfangreiche .csv Liste für die Version 1.0
Hier warte ich erstmal eure Meinung ab welche ich davon benutzen darf.
Im Voraus schon mal lieben Dank für eure Hilfe. Bin mal gespannt was kommt.
Für all zu dämliche Fragen schon mal Entschuldigung;-)
Hier mal ein Auszug aus dem log sowie einen scan.
2015-03-23 18:04:10.742 [bus notice] scan: 08;Joh. Vaillant GmbH & Co.;BAI00;0518;7401
2015-03-23 18:04:10.844 [bus notice] scan: 15;Joh. Vaillant GmbH & Co.;43000;0215;2002
2015-03-23 18:04:10.968 [bus notice] scan: ;21110800
2015-03-23 18:04:11.115 [bus notice] scan: ;21104700
2015-03-23 18:04:11.232 [bus notice] scan: ;100093433
2015-03-23 18:04:11.378 [bus notice] scan: ;200285150
2015-03-23 18:04:11.497 [bus notice] scan: ;100005576
2015-03-23 18:04:11.644 [bus notice] scan: ;907010914
2015-03-23 18:04:11.762 [bus notice] scan: ;N8
2015-03-23 18:04:11.909 [bus notice] scan: ;N7
2015-03-23 18:03:01.241 [main notice] ebusd started
2015-03-23 18:03:01.256 [main notice] message DB: 628
2015-03-23 18:03:01.256 [main notice] updates DB: 35
2015-03-23 18:03:01.256 [main notice] polling DB: 25
2015-03-23 18:03:01.257 [bus notice] signal acquired
2015-03-23 18:03:01.518 [bus error] poll mc2 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:03:03.823 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:07.102 [bus error] poll mc3 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:03:07.876 [update notice] unknown MS cmd: 1008b511010189 / 09665af0096e6e0100ff0b
2015-03-23 18:03:09.922 [update notice] unknown MS cmd: 1008b50401003d / 0a02170318fffffffff009d9
2015-03-23 18:03:10.155 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-23 18:03:13.073 [bus error] poll pmw00 Ntc1 failed: ERR: read timeout
2015-03-23 18:03:13.938 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:17.975 [update notice] unknown MS cmd: 1008b511010189 / 09665af0096e6e0100ff0b
2015-03-23 18:03:19.091 [bus error] poll pmw00 Ntc2 failed: ERR: read timeout
2015-03-23 18:03:24.012 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:25.075 [bus error] poll pmw00 Ntc3 failed: ERR: read timeout
2015-03-23 18:03:28.054 [update notice] unknown MS cmd: 1008b511010189 / 09665af0096e6e0100ff0b
2015-03-23 18:03:30.106 [update notice] update broadcast vdatetime QQ=10: 18:03:31;23.03.2015
2015-03-23 18:03:30.357 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:03:31.115 [bus error] poll uih00 FlowTempSensor failed: ERR: invalid position
2015-03-23 18:03:32.129 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:37.088 [bus error] poll uih00 EnergyYieldDayTransfer failed: ERR: invalid position
2015-03-23 18:03:38.191 [update notice] unknown MS cmd: 1008b511010189 / 09665af0096e6e0100ff0b
2015-03-23 18:03:40.193 [update notice] unknown MS cmd: 1008b50401003d / 0a02480318fffffffff00994
2015-03-23 18:03:40.462 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:03:42.242 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:43.092 [bus notice] poll uih00 EnergyYieldSum: 1107297072
2015-03-23 18:03:48.289 [update notice] unknown MS cmd: 1008b511010189 / 09665cf0096e6e0100ff52
2015-03-23 18:03:49.082 [bus error] poll pms00 YieldDay failed: ERR: read timeout
2015-03-23 18:03:50.290 [update notice] update broadcast outsidetemp QQ=10: 9.938
2015-03-23 18:03:52.345 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:03:55.080 [bus error] poll pms00 YieldSum failed: ERR: read timeout
2015-03-23 18:03:58.420 [update notice] unknown MS cmd: 1008b511010189 / 09665cf0096e6e0100ff52
2015-03-23 18:03:59.406 [main notice] >>>
2015-03-23 18:03:59.407 [main notice] <<< usage:
2015-03-23 18:04:01.105 [bus error] poll pms00 SolarNtcFrom failed: ERR: read timeout
2015-03-23 18:04:02.461 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:04:06.486 [update notice] unknown MS cmd: 1008b511010189 / 09665cf0096e6e0100ff52
2015-03-23 18:04:07.100 [bus error] poll pms00 SolarNtcTo failed: ERR: read timeout
2015-03-23 18:04:08.503 [update notice] unknown MS cmd: 1008b50401003d / 0a02170418fffffffff00956
2015-03-23 18:04:08.728 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-23 18:04:12.010 [bus notice] max. symbols per second: 143
2015-03-23 18:04:12.559 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:04:13.086 [bus error] poll pms00 BufferNtcFrom failed: ERR: read timeout
2015-03-23 18:04:16.571 [update notice] unknown MS cmd: 1008b511010189 / 09685cf0096e6e0100ff03
2015-03-23 18:04:19.081 [bus error] poll pms00 BufferNtcTo failed: ERR: read timeout
2015-03-23 18:04:22.651 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:04:25.131 [bus error] poll ehp00 BrineTempOutput failed: ERR: invalid position
2015-03-23 18:04:26.684 [update notice] unknown MS cmd: 1008b511010189 / 09685cf0096e6e0100ff03
2015-03-23 18:04:28.691 [update notice] update broadcast vdatetime QQ=10: 18:04:30;23.03.2015
2015-03-23 18:04:28.945 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:04:31.128 [bus notice] poll ehp00 CompressorTempInput: 122.88;ok
2015-03-23 18:04:32.765 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:04:36.795 [update notice] unknown MS cmd: 1008b511010189 / 09685cf0096e6e0100ff03
2015-03-23 18:04:37.115 [bus error] poll ehp00 CompressorTempOutput failed: ERR: element not found
2015-03-23 18:04:41.136 [update notice] unknown MS cmd: 1008b50401003d / 0a02510418fffffffff009fd
2015-03-23 18:04:41.409 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:04:41.665 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:04:43.230 [bus error] poll ehp00 EvaporatorTemp failed: ERR: invalid position
2015-03-23 18:04:49.364 [bus error] poll ehp00 ExpansionValveInputTemp failed: ERR: invalid position
2015-03-23 18:04:51.172 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:04:55.104 [bus error] poll ehp00 FlowTempIntern failed: ERR: invalid position
2015-03-23 18:04:56.970 [update notice] unknown MS cmd: 1008b511010189 / 09685cf0096e6e0100ff03
2015-03-23 18:04:58.907 [update notice] update broadcast outsidetemp QQ=10: 9.938
2015-03-23 18:05:00.995 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:01.136 [bus error] poll ehp00 HeatSystemPress failed: ERR: invalid position
2015-03-23 18:05:06.980 [update notice] unknown MS cmd: 1008b511010189 / 09685cf0096e6e0100ff03
2015-03-23 18:05:07.127 [bus notice] poll ehp00 BrinePress: 0.892;ok
2015-03-23 18:05:08.983 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:05:10.989 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:13.131 [bus error] poll ehp00 ReturnTempIntern failed: ERR: element not found
2015-03-23 18:05:15.004 [update notice] unknown MS cmd: 1008b511010189 / 09685ef0096e6e0100ff34
2015-03-23 18:05:17.012 [update notice] unknown MS cmd: 1008b50401003d / 0a0319051823030115f009ed
2015-03-23 18:05:17.232 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-23 18:05:19.099 [bus error] poll ehp00 VaporPressHigh failed: ERR: element not found
2015-03-23 18:05:21.020 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:25.013 [update notice] unknown MS cmd: 1008b511010189 / 09685ef0096e6e0100ff34
2015-03-23 18:05:25.111 [bus error] poll ehp00 VaporPressLow failed: ERR: element not found
2015-03-23 18:05:31.050 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:31.124 [bus error] poll mc2 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:05:35.063 [update notice] unknown MS cmd: 1008b511010189 / 09685ef0096e6e0100ff34
2015-03-23 18:05:37.033 [update notice] update broadcast vdatetime QQ=10: 18:05:38;23.03.2015
2015-03-23 18:05:37.106 [bus error] poll mc3 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:05:37.801 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:05:41.060 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:43.081 [bus error] poll pmw00 Ntc1 failed: ERR: read timeout
2015-03-23 18:05:45.079 [update notice] unknown MS cmd: 1008b511010189 / 09685ef0096e6e0100ff34
2015-03-23 18:05:47.087 [update notice] unknown MS cmd: 1008b50401003d / 0a0348051823030115f009f1
2015-03-23 18:05:47.355 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:05:49.111 [bus error] poll pmw00 Ntc2 failed: ERR: read timeout
2015-03-23 18:05:51.065 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:05:55.061 [update notice] unknown MS cmd: 1008b511010189 / 09685ef0096e6e0100ff34
2015-03-23 18:05:55.136 [bus error] poll pmw00 Ntc3 failed: ERR: read timeout
2015-03-23 18:05:57.029 [update notice] update broadcast outsidetemp QQ=10: 9.938
2015-03-23 18:06:01.013 [bus error] ERR: arbitration lost, retry
2015-03-23 18:06:01.109 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:01.371 [bus error] poll uih00 FlowTempSensor failed: ERR: invalid position
2015-03-23 18:06:05.094 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:07.086 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:06:07.167 [bus error] poll uih00 EnergyYieldDayTransfer failed: ERR: invalid position
2015-03-23 18:06:09.084 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:13.119 [bus notice] poll uih00 EnergyYieldSum: 4110418768
2015-03-23 18:06:15.123 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:17.137 [update notice] unknown MS cmd: 1008b50401003d / 0a0319061823030115f0090c
2015-03-23 18:06:17.360 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-23 18:06:19.038 [bus error] ERR: arbitration lost, retry
2015-03-23 18:06:19.183 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:19.392 [bus error] poll pms00 YieldDay failed: ERR: read timeout
2015-03-23 18:06:25.016 [bus error] ERR: arbitration lost, retry
2015-03-23 18:06:25.114 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:25.367 [bus error] poll pms00 YieldSum failed: ERR: read timeout
2015-03-23 18:06:29.133 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:31.108 [bus error] poll pms00 SolarNtcFrom failed: ERR: read timeout
2015-03-23 18:06:35.137 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:37.110 [bus error] poll pms00 SolarNtcTo failed: ERR: read timeout
2015-03-23 18:06:37.665 [update notice] update broadcast vdatetime QQ=10: 18:06:38;23.03.2015
2015-03-23 18:06:37.932 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:06:39.159 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:43.073 [bus error] poll pms00 BufferNtcFrom failed: ERR: read timeout
2015-03-23 18:06:45.157 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:47.168 [update notice] unknown MS cmd: 1008b50401003d / 0a0349061823030115f0098d
2015-03-23 18:06:47.444 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:06:49.099 [bus error] poll pms00 BufferNtcTo failed: ERR: read timeout
2015-03-23 18:06:49.694 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:06:53.208 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:06:55.105 [bus error] poll ehp00 BrineTempOutput failed: ERR: invalid position
2015-03-23 18:06:55.153 [update notice] update broadcast outsidetemp QQ=10: 9.938
2015-03-23 18:06:59.203 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:07:01.117 [bus notice] poll ehp00 CompressorTempInput: 122.31;ok
2015-03-23 18:07:03.215 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:07:05.203 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:07:07.125 [bus error] poll ehp00 CompressorTempOutput failed: ERR: element not found
2015-03-23 18:07:09.213 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:07:13.106 [bus error] poll ehp00 EvaporatorTemp failed: ERR: invalid position
2015-03-23 18:07:13.212 [update notice] unknown MS cmd: 1008b511010189 / 096a5ef0096e6e0100ff95
2015-03-23 18:07:15.208 [update notice] unknown MS cmd: 1008b50401003d / 0a0317071823030115f0098b
2015-03-23 18:07:15.430 [update notice] unknown BC cmd: 10feb5050204000b
2015-03-23 18:07:19.133 [bus error] poll ehp00 ExpansionValveInputTemp failed: ERR: invalid position
2015-03-23 18:07:19.242 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:07:23.237 [update notice] unknown MS cmd: 1008b511010189 / 096a60f0096e6e0100ff75
2015-03-23 18:07:25.097 [bus error] poll ehp00 FlowTempIntern failed: ERR: invalid position
2015-03-23 18:07:29.242 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:07:31.109 [bus error] poll ehp00 HeatSystemPress failed: ERR: invalid position
2015-03-23 18:07:33.255 [update notice] unknown MS cmd: 1008b511010189 / 096a60b0096e6e0000ff9b
2015-03-23 18:07:35.268 [update notice] update broadcast vdatetime QQ=10: 18:07:36;23.03.2015
2015-03-23 18:07:35.527 [update notice] unknown MS cmd: 1008b512020000ca / 0000
2015-03-23 18:07:37.093 [bus error] poll mc2 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:07:39.313 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
2015-03-23 18:07:43.091 [bus error] poll mc3 mcFlowTempSensor failed: ERR: read timeout
2015-03-23 18:07:43.686 [update notice] unknown MS cmd: 1008b511010189 / 096260b0096e6e0000ffb2
2015-03-23 18:07:45.386 [update notice] unknown MS cmd: 1008b50401003d / 0a0347071823030115b009c2
2015-03-23 18:07:45.653 [update notice] unknown MS cmd: 1008b51101028a / 05033c80507201
2015-03-23 18:07:47.392 [update notice] unknown MS cmd: 1008b510090000616effff00ff0041 / 01019a
Die dämlichen Fragen sind nicht das Problem. Aber die gigantisch langen Posts.
- Entweder als Code markieren oder als Datei anhängen - aber nicht im Text posten !
pah
Zitat von: Prof. Dr. Peter Henning am 23 März 2015, 21:05:52
Die dämlichen Fragen sind nicht das Problem. Aber die gigantisch langen Posts.
- Entweder als Code markieren oder als Datei anhängen - aber nicht im Text posten !
pah
[Danke für den Hinweis, denke das müsste jetzt passen/quote]
Zitat von: Jojo11 am 20 März 2015, 21:24:19
Ich habe den ebus-Koppler von eservice über USB am RPi. Der Koppler wurde gerade überprüft und ist in Ordnung. Timing-Probleme hatte der Hersteller auch im Verdacht in meinen Fall.
Hallo Jo,
mir ist noch was eingefallen: Hat das /dev/ttyUSBx auch das Schreib-Flag für alle?
Und Du könntest noch den Versuch wagen, bei jedem Senden an den Bus das Device zu flushen. Dazu den aktuellen Master Branch auschecken, in der Datei src/lib/ebus/device.cpp in Zeile 103 "fsync(m_fd)" hinzufügen, compilieren und schauen was passiert.
LG John
Zitat von: Hasont am 23 März 2015, 20:36:19
1.) Ich starte ebusd -f, wie kann ich diesen stoppen ohne den Rechner runter zu fahren.
STRG-c
Zitat von: Hasont am 23 März 2015, 20:36:19
2.) Ich habe die Config Daten für Vailant 0.5 alle unter etc/ebusd (nicht Default) abgespeichert und mit 755 versehen. Denke da dürfen aber nur ausgewählte Files hin da ich viele Fehler bekomme.
Richtig, Du solltest nur die Dateien nehmen, die zu Deiner Anlage passen. Alles andere ist fahrlässig und ruiniert im Zweifel Deine Geräte...
Zitat von: Hasont am 23 März 2015, 20:36:19
3.) Es gibt die .csv und .ods files. Denke die sind entweder/oder
Die ODS sind zum leichteren Editieren, werden aber von ebusd nie gelesen, da ebusd nur CSV unterstützt.
Zitat von: Hasont am 23 März 2015, 20:36:19
4.) Was muss/soll in den zu erstellenden "default Ordner" hatte hier erstmal die .csv Daten abgespeichert.
Wie gesagt, die passenden Dateien für Deine Anlage.
Siehe dazu auch u.a. das README: https://github.com/john30/ebusd-configuration
Zitat von: Hasont am 23 März 2015, 20:36:19
5.) Seit ein paar Tagen gibt es eine umfangreiche .csv Liste für die Version 1.0
Hier warte ich erstmal eure Meinung ab welche ich davon benutzen darf.
Für Deine Anlage laut scan:
Tipp fürs nächste Mal: lieber das Ergebnis von "ebusctl scan result" posten als das komplette Protokoll (das ist nur hilfreich, wenn es wirklich ans eingemachte geht).
LG John
Zitat von: Reinhart am 22 März 2015, 21:20:22
Bei der bai00.csv allerdings gibt es negative Werte, die terminieren mit "out of valid range"
Ich hab das nochmal verifiziert und kann das Problem nicht reproduzieren. Hast Du auch den master Branch von ebusd als Basis verwendet? Unter 1.0.0 war der spezielle Divider "-100" (=Reziprok von 100 also 1/100) noch nicht unterstützt.
Hallo John,
bevor ich mich an die Arbeit mache das ebus-Interface zusammen zu lötren, wollte ich fragen, ob es auch eine Konfigurationsdatei für ein Weishaupt WTC25N/F geben kann, bzw. ob du mir eine erstellen kannst?
Vielen Dank vorab.
MfG
Thomas
Zitat von: Papaloewe am 24 März 2015, 08:50:11
bevor ich mich an die Arbeit mache das ebus-Interface zusammen zu lötren, wollte ich fragen, ob es auch eine Konfigurationsdatei für ein Weishaupt WTC25N/F geben kann, bzw. ob du mir eine erstellen kannst?
Hallo Thomas,
das ist ein typisches Henne-Ei-Problem. Ohne ein Interface, mit dem man da mal mitlauschen kann, gibt es sicher keine Konfigurationsdateien dafür... Es sei denn Du rufst beim Hersteller an und fragst, ob sie das nicht freiwillig rausrücken wollen (mit einer positiven Antwort würde ich nicht unbedingt rechnen) ;)
Wir können aber gern versuchen, das zusammen zu erarbeiten. Siehe auch mein kleines Howto zu diesem Thema:
https://github.com/john30/ebusd/wiki/HowTos
Ach so, Grundvoraussetzung ist natürlich, dass die Anlage eine eBUS Schnittstelle besitzt. Sonst kannst Du Dir die Lötarbeit sicher sparen...
LG John
Zitat von: john30 am 22 März 2015, 17:14:33
So, ich hab jetzt mal einen Schwung generierter config Files auf https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de gepostet.
Falls sich jemand über die "*wi" und "*ws" in den generierten CSVs wundert:
In der MDB sind die einzelnen Nachrichten mit access level versehen ("User", "Installer", "Service"). Das wird in den Configfiles über "*w" (=keine besonderen Rechte), "*wi" (=Installateur), und "*ws" (=Service) wiedergegegen.
Das ist mein jetziger Ansatz, um zumindest eine leichte Hürde für write Messages zu haben, die vor versehentlichem groben Unfug bewahren soll.
So ist bspw. für eine BAI das Setzen der maximalen Brennersperrzeit (d.02) nur über die Angabe der Circuit (ehemals Class) plus angehängtem "#install" möglich, also z.B. "write -c bai00#install WPPostrunTime 5".
In einer zukünftigen ebusd Version wäre sogar denkbar, die "#" Suffixe an der Circuit in entsprechende reale Access Levels umzusetzen und für das Absetzen solcher Writes eine entsprechende Authentifizierung vom Client zu fordern. Zukunftsmusik :)
LG John
Hallo John,
danke für die schnelle Antwort. Ja, mein Weishaupt Brennwertgerät benutzt einen ebus.
Ich werde mich mal dranmachen ein entsprechendes Interface zu bauen.
Vorab habe ich bereits im Netz folgende Infos gefunden.
http://www.ip-symcon.de/forum/attachment.php?attachmentid=20387&d=1362383550 (http://www.ip-symcon.de/forum/attachment.php?attachmentid=20387&d=1362383550)
Kann man damit vielleicht schon etwas anfangen?
Gruß
Thomas
Hallo zusammen,
mein Problem mit dem Setzen der Soll-Temperatur (ohne VRC430) hat sich nun doch gelöst:
Anscheinend muss die Therme doch initialisiert werden:
localhost: Write -h 08 B5 04 01 00
0a00163102ffffffff0080
danach der write:
localhost: Write -h 08 B5 10 09 00 00 75 75 FF FF 00 FF 00
0101
anschließend die Temperatur auslesen:
localhost: r -f storagetempdesired
55.00
... und siehe da, neue Soll-Temp ist eingestellt... :) .. vielen Dank an alle für die guten Tipps!
Ich habe noch eine weitere Frage: bei meiner 246 habe ich einen actoStor Warmwasserspeicher angeschlossen. Am Bedienfeld der Therme lässt sich dieser mit dem Warmwassertemperaturknopf an- und ausschalten (Knopf auf Anschlag links -> Speicherladung aus, auf Anschlag rechts: Speicherladung aktiv (es erscheint dann ein "C" im Display).
Ich hab nun mit allen möglichen Befehlen versucht, die Speicherladung zu aktivieren/deaktivieren - aber leider ohne Erfolg. Ich wüsste noch nichtmal in welchem Register ich den die Speicherladung abfragen kann (mit und ohne "C" ändert sich rein gar nichts in den D.xx-Registern .. :(
Hat jemand eine Idee (bzw. lässt sich mit der VRC430 die Speicherladung an- und ausschalten)?
LG Texel
@texel
ich habe die von john30 weiter vorne geposteten neuen CSV die er mit dem Genrator erzeugt hat geladen und installiert.
Schau dir dann die aktuelle 43000.csv an, das hier könnte dein gesuchter Wert sein.
r;wi,,HwcParallelLoading,Parallele Ladung Warmwasserkreis,,,,"4800",,,onoff,,,Heizbetrieb und Speicherladung parallel
Bei den "wi" musst aber noch den Post von John30 lesen, sonst kannst mit denen nicht schreiben!
Du must mit den neuen Files aber einiges umstellen (bei der Abfrage in Fhem), weil die Texte sich nun geändert haben und lade bitte mindesten die 3 Files (_templates, bai00, 43000 evtl. auch noch die broadcast) sonst passt das nicht zusammen.
Ich hoffe es führt dich zum Erfolg!
LG
Reinhart
Zitat von: Papaloewe am 24 März 2015, 14:43:31
http://www.ip-symcon.de/forum/attachment.php?attachmentid=20387&d=1362383550 (http://www.ip-symcon.de/forum/attachment.php?attachmentid=20387&d=1362383550)
Kann man damit vielleicht schon etwas anfangen?
Ja, daraus könnte man schon Konfigurationsdateien konstruieren.
LG John
Für Deine Anlage laut scan:
Hallo John, vielen Dank für die Hilfe
Muss ich außer den zwei genannten auch noch die _templates hinzufügen?
LG
Horst
@john30
Danke für deinen Tipp, habe den eBus jetzt aktuell nochmals ausgecheckt und installiert, der Fehler mit den negativen Werten ist jetzt weg!
Sehr interessiert bin ich an diesen Energie Werten, was immer die genau aussagen sollen. Der Wert PrEnergySumHwc1DK erhöht den Counter pro Stunde etwa um 22000. Hat du eine Ahnung was das für eine Einheit sein soll (evtl. Liter/h oder Watt/h)? Ich logge die mit und möchte dann Anhand der Tageswerte Rückschlüsse ziehen. Den Gesamtgasverbrauch habe ich ja erfasst und kann somit vergleichen. Selbst wenn das Wh sind, wären das 2 m3 (bei 1m3 = 11,2 KWh). Seltsam, dass in meiner VrDialog Software dieser Wert nicht zu sehen ist, obwohl du ihn ja aus der MDB auslesen konntest.
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHwc1DK
2478342327
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHc1DK
4294967166
Schade, dass PrVortexFlowSensorValueDK bei mir leider nur 0 liefert. Der Durchflußsensor dürfte wohl nicht in allen Typen verbaut sein.
LG
Reinhart
Zitat von: john30 am 24 März 2015, 08:13:26
Hallo Jo,
mir ist noch was eingefallen: Hat das /dev/ttyUSBx auch das Schreib-Flag für alle?
Und Du könntest noch den Versuch wagen, bei jedem Senden an den Bus das Device zu flushen. Dazu den aktuellen Master Branch auschecken, in der Datei src/lib/ebus/device.cpp in Zeile 103 "fsync(m_fd)" hinzufügen, compilieren und schauen was passiert.
LG John
Hallo John,
das Seltsame ist ja, dass das Senden anfangs funktioniert und erst nach einer Weile nicht mehr.
Bin leider noch nicht dazu gekommen, das Kabel zu überprüfen. Werde das mit dem flushen mal testen. Danke!
schöne Grüße
Jo
Zitat von: Hasont am 24 März 2015, 19:00:52
Für Deine Anlage laut scan:
Hallo John, vielen Dank für die Hilfe
Muss ich außer den zwei genannten auch noch die _templates hinzufügen?
LG
Horst
ja unbedingt, da in der _templates neue Typen dazu gekommen sind, sonst bekommst du viele Fehler so wie ich die in Wirklichkeit gar nicht da sind.
LG
Zitat
das Seltsame ist ja, dass das Senden anfangs funktioniert und erst nach einer Weile nicht mehr.
und genau das deutet für mich auf einen thermischen Fehler hin! Als ich noch vor 20 Jahren CMOS bestückte Fernwirkplatinen reparierte war eines meiner wichtigsten Werkzeuge der Hahrföhn und der Kältespray. Lege doch das Gerät über Nacht in den Kühlschrank, wenn es dann funktioniert bearbeite es vorsichtig mit dem Föhn, fällt es dann aus, ist der Fehler gefunden. Kostet nichts und hilft dir sicher weiter, zumindest kannst du dann einen Hardwarefehler ausschließen.
Ich möchte den Technikern nichts unterstellen, aber es kommt sehr viel auf die Umgebung und die Dauer an wie die das Gerät getestet haben. Es gibt nicht umsonst elektronische Bauteile nach militärischen Spezifikationen, die haben unter anderem einen erweiterten Temperaturbereich.
LG
Hallo,
wenn ich auf der Wiki Seite auf den Link für den ebusd klicke (.../yuhu~) bekomme ich immer:
404 Seite nicht vorhanden.
Geht nur mir das so?
Ich habe mich bei github angemeldet und auch dann geht das nicht.
Funktioniert der Link nicht mehr?
Grüße
Detlef
Zitat von: Reinhart am 24 März 2015, 20:03:47
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHwc1DK
2478342327
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHc1DK
4294967166
Schau doch mal, was PrEnergyCountHc1DK bzw. PrEnergyCountHwc1DK liefern und teile mal das Ergebnis von PrEnergySumHwc1DK durch das Ergebnis von PrEnergyCountHwc1DK.
Weiß jemand, was das komische "DK" am Ende fast aller BAI Namen soll? Wenn das keinen tieferen Sinn besitzt, würde ich das noch im Generator rauswerfen...
LG John
Zitat von: Jojo11 am 24 März 2015, 20:33:05
das Seltsame ist ja, dass das Senden anfangs funktioniert und erst nach einer Weile nicht mehr.
Bin leider noch nicht dazu gekommen, das Kabel zu überprüfen. Werde das mit dem flushen mal testen. Danke!
Ah, das hatte ich nicht mehr auf dem Schirm. Um so merkwürdiger das ist:)
Kannst Du mal rausfinden, was lsusb über Dein Interface genau erzählt? Vielleicht gibt es ja in dem Kernelmodul etwas ähnlich skurriles wie beim RPi GPIO UART (konfiguriert auf 16 Bytes Puffer auf der Hardware)...
Zitat von: broesel am 24 März 2015, 22:51:05
wenn ich auf der Wiki Seite auf den Link für den ebusd klicke (.../yuhu~) bekomme ich immer:
Welches Wiki meinst Du denn genau?
Unter meinem https://github.com/john30/ebusd/wiki finde ich zumindest keinen gebrochenen Link mehr.
@Reinhart: Bitte nicht so wild im Nebel stochern, das hilft niemandem.
Zitat
Der Wert PrEnergySumHwc1DK erhöht den Counter pro Stunde etwa um 22000.
Was bitte ist gemeint damit, dass ein Wert den Counter erhöht ?
Zitat
Hat du eine Ahnung was das für eine Einheit sein soll (evtl. Liter/h oder Watt/h)?
Was bitte soll die Einheit Watt/h bedeuten ?
Zitat
Ich möchte den Technikern nichts unterstellen,
Das ist auch gut so. Wir sind hier nicht beim heiteren Fehlerraten, sondern bei einer systematischen Fehlersuche.
@Jojo11: Ich schlage vor, das Teil mal an einem anderen PC laufen zu lassen. den EBUS kann man beliebig verlängern, ich hatte zu Testzwecken auch mal ein 20m Kabel dran.
@John30: Wenn das beim Empfang passieren würde, hätt eich beim RPi auch auf einen puffer getippt. Ist aber beim Senden der Fall.
LG
pah
Hallo zusammen,
ich habe die folgenden scan-Ergebnisse:
08;Vaillant;BAI00;0518;7401
15;Vaillant;47000;0230;6002
50;Vaillant;V6100;0418;1902
Die Abfrage der "BAI00" und die "47000" funktionieren mit den ebusd-1.x.x csv-Dateien von john30 mittlerweile ganz hervorragend, vielen Dank dafür!
Gibt es für die "V6100" (Vaillant Mischermodul VR 61) ebenfalls csv-Dateien bzw. bereits bekannte Werte?
Viele Grüße
terry
@john30
Hier die Ergebnisse der Abfragen:
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHwc1DK
2479234685
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergyCountHwc1DK
8139307
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergySumHc1DK
4294967166
pi@raspberry2 ~ $ ebusctl read -f -m 10 PrEnergyCountHc1DK
17479637
PrEnergyCountHwc1DK und PrEnergySumHwc1DK zählen hoch, die anderen Hc liefern immer den selben Wert.
Ich hatte mir eigentlich gedacht die Abkürzung Hwc = HotWaterCounter und Hc = HeatingCounter, ist aber offensichtlich nicht so. Primary und Energy erklären sich von selbst, wobei der Ausdruck "Energy" in diesem Fall mit Kwh nicht unbedingt was zu tun haben muss. DK kann ich mir auch nicht erklären, wird aber offensichtlich nur in der bai00 verwendet.
Ich schreibe aber jetzt zur besseren Beobachtung beide (Count + Sum) in ein Log. ...Hc2 und ...Hc3 liefern alle 0.
LG
Reinhart
Zitat von: terryhoax am 25 März 2015, 09:07:29
50;Vaillant;V6100;0418;1902
Gibt es für die "V6100" (Vaillant Mischermodul VR 61) ebenfalls csv-Dateien bzw. bereits bekannte Werte?
Ich werd Deinen Scan heut Abend durch den Generator jagen, dann weiß ich mehr.
Zitat von: Prof. Dr. Peter Henning am 25 März 2015, 08:36:27
@John30: Wenn das beim Empfang passieren würde, hätt eich beim RPi auch auf einen puffer getippt. Ist aber beim Senden der Fall.
Gerade beim Senden ist ein Puffer jeglicher Art tödlich für das eBUS Protokoll, weil dann die Arbitrierung nicht funktionieren kann. Ich bin mir sehr sicher, dass das auch der Grund für die Probleme mit dem RPi UART ist, denn dort sind in den Kernel Sourcen fix 16 bytes als Puffer auf dem Chip konfiguriert.
Zitat von: Reinhart am 25 März 2015, 12:53:08
PrEnergyCountHwc1DK und PrEnergySumHwc1DK zählen hoch, die anderen Hc liefern immer den selben Wert.
Ich hatte mir eigentlich gedacht die Abkürzung Hwc = HotWaterCounter und Hc = HeatingCounter, ist aber offensichtlich nicht so. Primary und Energy erklären sich von selbst, wobei der Ausdruck "Energy" in diesem Fall mit Kwh nicht unbedingt was zu tun haben muss. DK kann ich mir auch nicht erklären, wird aber offensichtlich nur in der bai00 verwendet.
Hwc ist die von mir in den Generator übernommene Nomenklatur für "hot water circuit" und "Hc" selbiges für "heat circuit".
Für die nicht-1 Hcs liegt das fehlende Hochzählen wohl daran, dass Du eben nur eine heat circuit hast (nämlich die mit der 1). Oder hast Du mehrere?
Gut, dann werde ich bei Gelegenheit "DK" rauswerfen.
@pah
ZitatWas bitte ist gemeint damit, dass ein Wert den Counter erhöht ?
Bei den PrEnergy....... handelt es sich offensichtlich um den Datentyp "Zähler" (Counter) und dieser zählt in meinen Fall um den "Wert" 22000 pro Stunde hoch.
ZitatWas bitte soll die Einheit Watt/h bedeuten ?
ich meine damit Wh (Wattstunden).
Kältespray und Heißluft ist eine völlig legale Art der Fehlersuche unter Elektronikern, da gerade thermische Probleme meist nicht anders aufgefunden werden können. Es muss ja nicht immer die Software sein die solche Fehler produziert. Kein anderer Anwender hat diese Art von Fehler, daher die Vermutung das es eben auch die Hardware sein kann.
LG
Reinhart
Zitat von: john30 am 25 März 2015, 13:07:11
Hwc ist die von mir in den Generator übernommene Nomenklatur für "hot water circuit" und "Hc" selbiges für "heat circuit".
Für die nicht-1 Hcs liegt das fehlende Hochzählen wohl daran, dass Du eben nur eine heat circuit hast (nämlich die mit der 1). Oder hast Du mehrere?
Gut, dann werde ich bei Gelegenheit "DK" rauswerfen.
Danke für die Aufklärung.
Ja genau, habe nur einen "Heater".
LG
Zitat von: john30 am 25 März 2015, 13:00:35
Ich werd Deinen Scan heut Abend durch den Generator jagen, dann weiß ich mehr.
So, config file für V6100 ist im repository (https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/vaillant_de/v6100.csv). _templates.csv dazu nicht vergessen.
Zitat von: john30 am 25 März 2015, 13:07:11
Gut, dann werde ich bei Gelegenheit "DK" rauswerfen.
"DK" ist nun raus und ein paar andere merkwürdige Benennungen ebenso:
https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de
OK, und zur Nomenklatur:
HWC = Hot Water Circuit
HC = Heating Circuit (nicht Heat Circuit, auch nicht Heater Circuit)
MC = Mixer Circuit
SOL = Solar Circuit
Die Therme ist nicht der Heater, sondern der Burner.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 26 März 2015, 07:58:48
HWC = Hot Water Circuit
HC = Heating Circuit (nicht Heat Circuit, auch nicht Heater Circuit)
MC = Mixer Circuit
SOL = Solar Circuit
Das passt dann aber nicht zu den Angaben in "Vaillant_Protokoll_kurz.ods", zumindest was "MC" / "MIX" betrifft...
Was mir an Deiner ODS auch noch nicht gefällt:
- die Mixtur von "Boiler" und "Burner"
- die Verwendung von "BC" für Broadcast (BC suggeriert einen Begriff aus der Heiztechnik, was für "Broadcast" m.E. nicht wirklich stimmt)
Zitat von: john30 am 25 März 2015, 22:24:49
"DK" ist nun raus und ein paar andere merkwürdige Benennungen ebenso:
https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de
Hab das Verzeichnis jetzt umbenannt, da viele der Files nur ab ebusd 1.1.0 verwendbar sind:
https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.1.x/vaillant_de
Ebenso wurde aus "mix" jetzt "mc" um die Konvention besser einzuhalten. Darum haben sich auch ein paar Dateinamen entsprechend geändert.
Zitat
Das passt dann aber nicht zu den Angaben in "Vaillant_Protokoll_kurz.ods", zumindest was "MC" / "MIX" betrifft...
Was mir an Deiner ODS auch noch nicht gefällt:
- die Mixtur von "Boiler" und "Burner"
- die Verwendung von "BC" für Broadcast (BC suggeriert einen Begriff aus der Heiztechnik, was für "Broadcast" m.E. nicht wirklich stimmt)
Stimmt - in der veröffentlichten Datei ist das noch so drin. Ich komme aus beruflichen Gründen aber kaum dazu, einen sauberen Export meiner Dateien zu machen.
LG
pah
@john30
Danke für Änderung!
Was mir bei dem bai00.csv File aufgefallen ist, hier funktioniert die Rücklauftemperatur nicht mehr.
r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,tempsensor,,,Rücklauftemperatur
habe sie bei mir durch den alten Eintrag ersetzt, dann geht es wieder.
r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,temp,,,,tempmirror,,UIN,,,,,,sensor,,,Rücklauftemperatur
Kann es sein, das die Versionsnummer im "ebusd" noch nicht gesetzt ist? Habe vor 2 Tagen neu ausgecheckt. Du schreibst ja schon von V 1.1.0
pi@raspberry2 /usr/bin $ ls -al ebus*
-rwxr-xr-x 1 root root 131678 Mär 24 16:54 ebusctl
-rwxr-xr-x 1 root root 2412783 Mär 24 16:54 ebusd
-rwxr-xr-x 1 root root 106612 Mär 24 16:54 ebusfeed
pi@raspberry2 /usr/bin $ ebusd -V
ebusd 1.0.0
ansonsten sieht alles gut aus was ich bis jetzt getestet habe.
LG
Reinhart
Zitat von: john30 am 25 März 2015, 22:22:44
So, config file für V6100 ist im repository (https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/vaillant_de/v6100.csv). _templates.csv dazu nicht vergessen.
Super, vielen Dank @John30.
Funktioniert einwandfrei.
Gruß
terry
Hi, ich bin gerade am starten mit ebus...
Status: HW läuft, SW heute compiliert, läuft soweit, unsicher bin ich, welche csv files ich nehmen soll.
Die Heizung ist eine Vaillant VWL141/3 Luft-Wärmepumpe, mit Pufferspeicher, WW-Speicher und zusätzilch zwei Mischer (gesteuert von VR60/3) für FB-Vorlauftemperatur und Poolwärmetauscher.
ich hab die 1.1.x _templates.csv, broadcast.csv und scan.csv mal ins /etc/ebusd verzeichnis kopiert. Der scan schaut so aus:
08;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
15;Vaillant;UIH00;0374;6901;21131200
23;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
25;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
50;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
52;Vaillant;MC2 ;0500;6301;21134030;6782<<<<0;907008653;N3
53;Vaillant;MC2 ;0500;6301;21134030;6782<<<<0;907008653;N3
e0;Vaillant;OMU00;0118;5202;21132800;200752301;610006419;N2
e1;Vaillant;OMU00;0118;5202;21132800;200752301;610006406;N9
die adressen e0/e1 sind offensichtlich die beiden Wärmetauscher, 52/53 könnte der externe VR60/3 sein...
ich hätte mal vermutet, eine der ehp00xxx, uih00, und mc2.4 zu verwenden, aber das ist ja eigentlich die Frage.
Allerdings hab ich noch jede Menge "unknown MS command", z.B:
grab result
03e0b509040e3a0000 / 00
03e0b509040e480000 / 00
03e0b5210500020800e7 / 090000c400d100070000
03e1b509040e3a0000 / 00
03e1b509040e480000 / 00
03e1b5210500020800e7 / 090000c800d200070000
1008b50903290100 / 050100570100
1008b50903290700 / 050700490100
1008b50903290f00 / 050f00c80000
1008b5090329b801 / 03b80100
1008b5090329b901 / 03b90100
1008b5090329ba00 / 03ba0000
1008b5090329bb00 / 03bb0000
1008b5090329d300 / 05d300636363
1008b5090329e201 / 03e2018c
1008b509040ed10000 / 00
1008b51009000100000000000002 / 00
1008b5110102 / 050000c800c8
1008b511020300 / 0a4f013d08200500000000
1008b5130304cd01 / 0acd010100000001000100
1023b5040101 / 091e0200000006000100
1023b5040131 / 020000
1023b5040132 / 0a000000000000d0090000
1023b504020d00 / 050000008000
1023b505072b000100000000 / 00
1025b5040101 / 092a0200000003000100
1025b5040131 / 020000
1025b5040132 / 0a000000000000d0090000
1025b504020d00 / 050000f40000
1025b505072b000100000000 / 00
1025b50903290000 / 050000f40000
1025b509040ef40000 / 00
1050b5040100 / 0a0306561226030415800d
1050b5040101 / 09130100000081000100
1050b5040131 / 020001
1050b5040132 / 0a002806030101d0090100
1050b504020d00 / 0514003f0113
1050b505072b000100000000 / 00
1052b5040101 / 09050200000581000100
1052b5040131 / 020001
1052b5040132 / 0a002a06030101c0090100
1052b504020d00 / 050000620105
1052b505072b000100000000 / 00
1052b5090118 / 0a00000000000000000000
1053b5040101 / 09050200000581000100
1053b5040131 / 020001
1053b5040132 / 0a002a06030101c0090100
1053b504020d00 / 050000008005
1053b505072b000100000000 / 00
10feb505034a0100
10feb5160304d009
FHEM definitionen hab ich dzt. nur im test mit der aussentemp:
get A.Temp cmd {"read outsidetemp\n"}
l.g. und danke erwin
Zitat von: erwin am 26 März 2015, 15:00:35
08;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
15;Vaillant;UIH00;0374;6901;21131200
23;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
25;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
50;Vaillant;EHP00;0419;7201;21132300;200752140;006005070;N9
52;Vaillant;MC2 ;0500;6301;21134030;6782<<<<0;907008653;N3
53;Vaillant;MC2 ;0500;6301;21134030;6782<<<<0;907008653;N3
e0;Vaillant;OMU00;0118;5202;21132800;200752301;610006419;N2
e1;Vaillant;OMU00;0118;5202;21132800;200752301;610006406;N9
Interessant, das scheint ein ganzer Pool neuer Konfigurationsvarianten zu sein. Da muss ich mir erst was einfallen lassen, wie die einzelnen Varianten in ebusd-configuration sinnvoll abgelegt werden können. Ich schick Dir Dein Ergebnis mal direkt bevor ich das ins Repository lege. Kannst Du mir Deine Mail-Adresse per PN schicken?
Zitat von: Prof. Dr. Peter Henning am 26 März 2015, 12:23:41
Stimmt - in der veröffentlichten Datei ist das noch so drin. Ich komme aus beruflichen Gründen aber kaum dazu, einen sauberen Export meiner Dateien zu machen.
Gibts noch Vorschläge/Kommentare zu folgendem:
- CC = Circulation Circuit
- BC = Burner Circuit
- Storage = Tank/Storage/Speicher etc.
Fehlt noch was?
Zitat von: Reinhart am 26 März 2015, 13:31:33
Was mir bei dem bai00.csv File aufgefallen ist, hier funktioniert die Rücklauftemperatur nicht mehr.
r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,tempsensor,,,Rücklauftemperatur
Ups, mein Fehler. Da hab ich wohl zu schnell gelesen :) Wird natürlich korrigiert.
Zitat von: Reinhart am 26 März 2015, 13:31:33
Kann es sein, das die Versionsnummer im "ebusd" noch nicht gesetzt ist? Habe vor 2 Tagen neu ausgecheckt. Du schreibst ja schon von V 1.1.0
Ja, die Versionsnummer wird erst mit dem nächsten Release erhöht.
merci fürs prüfen!
Zitat von: erwin am 26 März 2015, 15:00:35
Allerdings hab ich noch jede Menge "unknown MS command", z.B:
Da bin ich schon dran. Dein grab result ist übrigens sehr hilfreich, Danke dafür!
Es wäre auch praktisch vom Rest die grab results z.B. nach einem Tag grabbing zu sammeln, dann könnte meine in Arbeit befindliche "common.csv" am Ende vielleicht für alle (oder hoffentlich die meisten) passen.
Also: Hiermit wird ein Wettbewerb für die schönsten Grab-Results ausgerufen! Der Gewinner bekommt ne Tafel Schokolade per Post ;-)
Wer mag, kann das auch gleich in das frisch angelegte Issue als Kommentar posten: https://github.com/john30/ebusd-configuration/issues/3
Zitat von: erwin am 26 März 2015, 15:00:35
Status: HW läuft, SW heute compiliert, läuft soweit, unsicher bin ich, welche csv files ich nehmen soll.
Die Heizung ist eine Vaillant VWL141/3 Luft-Wärmepumpe, mit Pufferspeicher, WW-Speicher und zusätzilch zwei Mischer (gesteuert von VR60/3) für FB-Vorlauftemperatur und Poolwärmetauscher.
ich hab die 1.1.x _templates.csv, broadcast.csv und scan.csv mal ins /etc/ebusd verzeichnis kopiert.
Sehr gute Vorarbeit! Du kannst schon mal mit folgenden Files probieren (write würd ich erst mal noch sein lassen):
- ehp00_airtowater.csv
- ehp00.hwc.csv
- ehp00.mc_mixercircuit.csv
- mc2.4.csv
- mc2.5.csv
- omu00.csv
- uih00.csv
Na, dann vereinheitlichen wir doch gleich. In dieser Systematik sollte es eben nicht SOL heißen, sondern SC = Solar Circuit.
Darüber hinaus bräuchten wir - für die Poolheizung - auch noch einen PC = Pool Circuit.
Bei den Speichern müssen wir aufpassen, "Storage" allgemein ist schon gut. Von der Funktionalität sind aber zu unterscheiden der Trinkwasserspeicher = HWStorage und der Heizungswasserspeicher = HStorage.
Vorlauf ist Flow, Rücklauf ist Return.
LG
pah
ZitatDarüber hinaus bräuchten wir - für die Poolheizung - auch noch einen PC = Pool Circuit.
Also: auf der UI der Vaillant heissen die einfach HK2, HK4, HK5.
@John30: ich hab jetzt das grab result aufs github gestellt: von gestern 22:00 Uhr bis heute ca. 9:00 Uhr, da waren etliche starts dabei, allerdings ist die WW und Pool heizung dzt. auf aus!
l.g. erwin
Hallo,
Macht es einen Unterschied ob beim Scan z.B. PMS00 oder PMS02 erscheint? Hier mein Scanergebnis:
localhost: scan result
06;Vaillant;PMS02;0209;8402;21133400;100143143;110005445;N9
08;Vaillant;BAI00;0703;7401;21134200;100041210;006006757;N3
0a;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
12;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
15;Vaillant;UI ;0507;6201;21134500;200804650;907012054;N6
23;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
25;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
26;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
50;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
ec;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
ed;Vaillant;PMS02;0209;8402;21133400;100143143;110005445;N9
fc;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
Das Ergebnis von Grab über den heutigen Tag werde ich ebenfalls posten.
Vielen Dank nochmals an die bisher geleistete großartige Arbeit.
Viele Grüße
David
Ich nehme an, mit "der UI" ist die Benutzungsoberfläche gemeint ...
Das stimmt nur bedingt, denn die Namen können frei gewählt und vergeben werden.
LG
pah
@john30
was mir beim Testen noch aufgefallen ist, in der bai00.csv fehlt noch d.14, d.15, d.17, d.18, d.19, d.20.
Oder wurden die vielleicht in eine andere Datei ausgelagert?
r,,PumpPowerDesired,d.14 => Leistung Heizungspumpe Soll,,,,0A04,,,UCH,0=auto;1=53;2=60;3=70;4=85;5=100,%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpPower,d.15 => Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,RegulationMode,d.17 => Regelungsmodus,,,,0C04,,,UCH,0=flow;1=return,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode,d.18 => Pumpenbetriebsart,,,,4904,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode2,d.19 => Pumpenbetriebsart 2. Pumpe,,,,0B04,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,StorageTempSetMax,d.20 => Maximale Speichersolltemperatur,,,,4304,,,temp,, °C,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
LG
Reinhart
Zitat von: Reinhart am 27 März 2015, 17:29:39
was mir beim Testen noch aufgefallen ist, in der bai00.csv fehlt noch d.14, d.15, d.17, d.18, d.19, d.20.
Die BAI gibt es in der DB in 6 verschiedenen Varianten abhängig von der HW Version. Für Deinen Scan sind diese Werte nicht definiert.
Wie schon gesagt, für den Variantenreichtum muss ich mir noch was überlegen...
Zitat von: stinch am 27 März 2015, 10:16:54
Macht es einen Unterschied ob beim Scan z.B. PMS00 oder PMS02 erscheint?
Das scheint keinen Unterschied zu machen. Hm, damit sind die Files schon wieder falsch benannt... grummel :)
Zitat von: stinch am 27 März 2015, 10:16:54
localhost: scan result
06;Vaillant;PMS02;0209;8402;21133400;100143143;110005445;N9
08;Vaillant;BAI00;0703;7401;21134200;100041210;006006757;N3
0a;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
12;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
15;Vaillant;UI ;0507;6201;21134500;200804650;907012054;N6
23;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
25;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
26;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
50;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
ec;Vaillant;SOLSY;0500;6301;21134500;200804630;907010779;N6
ed;Vaillant;PMS02;0209;8402;21133400;100143143;110005445;N9
fc;Vaillant;PMW01;0205;8302;21134800;100143113;110006279;N4
Hast Du zufällig mehr als eine Wasserstation (PMW)? Und wenn ja, wie ist dort jeweils der Adresschalter eingestellt?
Hi,
Nein ich hab nur eine wasserstation, eine solarstation, eine gastherme, einen Pufferspeicher und vrs620/3.
Viele Grüße
David
PS: Morgen früh stell ich das Grab Ergebnis online.
So, die config-files sind mal wieder im repo überarbeitet unter https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.1.x/vaillant_de :
- Dateinamen sind jetzt kürzer, je nachdem worauf ein File matched, also z.B. "bai.csv" für alle mit einem Ident "BAI*" im Scan result. Das wird für das kommende ebusd Feature "scanne und konfiguriere automatisch" benötigt.
- Die Circuit Namen sind vereinheitlicht. So ist z.B. ein Mixer immer mit Circuit "mc" (optional gefolgt von der Nummer bei zusätzlichen Heizkreisen) angegeben, eine Zirkulationspumpe mit "cc", ein Solarkreis mit "sc", ein Warmwasserkreis mit "hwc", Heizkreis mit "hc". Wenn in der DB keine Circuit hinterlegt ist, dann wird der Scan-Ident wie oben beschrieben verwendet, also z.B. "bai" oder "470".
- Bei allen Felder, die in der DB eine Einheit besitzen, hängt diese jetzt auch an der Definition dran bzw. wird durch die Template-Referenz eingesetzt.
Was noch fehlt wären einheitliche Namen für Raumtemperaturregler (Vorschlag "rc" für Room Controller) und für die UIs (Vorschlag "ui").
Ach ja, und ebusd 1.1.0 ist auch gerade released :-)
Rc ist keine gute idee - denn es wird ja nicht der Raum kontrolliert.
Vielmehr handelt es sich um einen Thermostaten, von mir aus auch noch Raumthermostaten (RT).
Auch User Interface ist zu generisch. Da wäre zwar Remote Control = Rc ok, birgt aber wegen des C Verwechselungsgefahr mit einem Circuit
LG
pah
Hallo,
habe jetzt die aktuelle Version gebaut und die neuen config files verwendet. Seitdem erhalte ich bei den messages im daemon fast nur noch "unknown ms ..."
Folgende config files verwende ich bei o.g. Scan:bai.csv, pms.csv, pmw.hwc.csv ,solsy.cc.csv ,solsy.mc.csv, _templates.csv, broadcast.csv , pms.sc.csv, scan.csv, solsy.hc.csv, solsy.sc.csv , ui.csv
Woran liegt das?
Wenn ich zusätzlich die solsy.cc.csv erscheint beim reload "Duplicate entry" error.
Viele Grüße
David
Hallo,
ich habe den ebus (1.1.0) heute auch frisch ausgecheckt und die CSV neu installiert, bei mir funktioniert soweit alles. Ich habe allerdings nicht so eine Menge Geräte wie du angeschlossen hast und benutze nur die bai,_templates,430, scan und common. Durch die neue common habe ich nur mehr 2 unknown ms.
Schau mal was ebusd --checkconfig so sagt und ob da Fehler sind?
pi@raspberry2 ~ $ ebusd --checkconfig
2015-03-29 18:47:19.370 [main notice] Performing configuration check...
2015-03-29 18:47:19.642 [main notice] found messages: 421 (0 poll, 11 update)
Müssten bei dir dann wesentlich mehr sein.
LG
Reinhart
Hallo,
Bei checkconfig kommt kein Fehler. Allerdings erscheint bei ebusd -V weiterhin 1.0.0. das versteh ich nicht.
pi@raspberrypi ~ $ ebusd -V
ebusd 1.0.0
pi@raspberrypi ~ $ ebusd --checkconfig
2015-03-29 23:09:50.132 [main notice] Performing configuration check...
2015-03-29 23:09:50.578 [main notice] found messages: 721 (0 poll, 9 update)
Viele Grüße
David
@stinch
Da scheint irgendwas schief gelaufen zu sein. Ich checke es immer nach der altbekannten Methode aus (obwohl der Prefix könnte glaube ich jetzt schon entfallen, den hat John30 als Default gesetzt, schadet aber nicht). Die CSV's hole ich allerdings händisch, da sich die im Augenblick fast täglich ändern. Ich habe beim Letzen Mal sogar den "alten" ebus Dämon laufen lassen (versehentlich) und sogar da wurde die Binary durch "make install" korrekt ersetzt, kopiert also tadellos darüber und startet offensichtlich auch den Dämon durch, da sofort ohne Neustart die V 1.1.0 erschien. Es kann aber bei dir eventuell auch sein, das die "alte" Binary auch noch in anderen Verzeichnissen liegt, diesen Fehler hatte ich am Anfang auch irgendwann einmal.
svn co https://github.com/john30/ebusd
cd /home/pi/ebusd/trunk
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
kompletter aktueller Checkout mit Compile und Install direkt am Raspi, dauert bei mir (Raspi+) ungefähr 10 Minuten.
pi@raspberry2 / $ /usr/bin/ebusd -V
ebusd 1.1.0
ergibt dann die aktuelle Version von 1.1.0.
pi@raspberry2 /usr/bin $ ls -al ebus*
-rwxr-xr-x 1 root root 131678 Mär 28 21:33 ebusctl
-rwxr-xr-x 1 root root 2436924 Mär 28 21:33 ebusd
-rwxr-xr-x 1 root root 106612 Mär 28 21:33 ebusfeed
und hier die aktuellen Dateigrößen der Binarys V 1.1.0, aus gecheckt am 28.03.
Ich hoffe die Infos helfen dir jetzt weiter und führen zum Erfolg.
LG
Reinhart
Zitat von: john30 am 22 März 2015, 17:05:56
Da würd ich mal das raw logging aktivieren, dann solltest Du relativ schnell sehen, wohin das Poti muss :-)
Es sollte dann ungefähr alle 40ms ein "<aa" da stehen, was das SYN Symbol ist.
Habe ich gemacht und auch das Poti mal durchgedreht.
Ergebnis:
odroid@SmartHome:~$ ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --lograwdata
2015-03-30 18:59:23.807 [main notice] ebusd started
2015-03-30 18:59:23.808 [main error] error reading templates: ERR: element not found
2015-03-30 18:59:23.808 [main notice] found messages: 0 (0 poll, 0 update)
2015-03-30 18:59:47.094 [bus notice] <00
2015-03-30 18:59:47.094 [bus notice] signal acquired
2015-03-30 18:59:47.119 [bus notice] <00
2015-03-30 18:59:47.441 [bus notice] <00
2015-03-30 18:59:47.461 [bus notice] <00
2015-03-30 18:59:47.624 [bus notice] <00
2015-03-30 18:59:47.873 [bus notice] <00
2015-03-30 18:59:48.431 [bus notice] <00
2015-03-30 18:59:50.018 [bus error] signal lost
2015-03-30 18:59:56.990 [bus notice] <00
2015-03-30 18:59:56.990 [bus notice] signal acquired
2015-03-30 18:59:58.013 [bus error] signal lost
2015-03-30 19:00:17.613 [bus notice] <00
2015-03-30 19:00:17.613 [bus notice] signal acquired
2015-03-30 19:00:19.050 [bus error] signal lost
2015-03-30 19:01:04.631 [bus notice] <00Wiederholt sich so jede Minute.
Habe noch keine Templates für Wolf installiert.
Hallo zusammen,
ich bin endlich mal wieder dazu gekommen, mich mit dem ebus zu beschäftigen. Da ich zuletzt ja einige Schwierigkeiten miit dem ebus-Koppler hatte, habe ich einen zweiten Raspberry Pi aufgesetzt und den ebusd 1.1 installiert. Ich habe sowohl das Kabel vom Koppler zur Therme als auch das USB-Kabel ausgetauscht. Zudem habe ich ein neues Netzteil verwendet. Die LED flackert wie gewünscht, aber leider funktioniert es immer noch nicht. Ich habe nur die _templates.csv in den entsprechenden Ordner kopiert. Folgenden output erhalte ich:
pi@raspberrypi ~ $ /usr/bin/ebusd --checkconfig
2015-03-30 17:00:38.919 [main notice] Performing configuration check...
2015-03-30 17:00:38.943 [main notice] found messages: 0 (0 poll, 0 update)
pi@raspberrypi ~ $ /usr/bin/ebusd -f -l ALL -d /dev/ttyUSB0
2015-03-30 17:00:56.772 [main notice] ebusd 1.1.0 started
2015-03-30 17:00:56.797 [main notice] found messages: 0 (0 poll, 0 update)
2015-03-30 17:00:57.269 [bus notice] signal acquired
2015-03-30 17:04:27.014 [bus error] signal lost
2015-03-30 17:04:27.171 [bus notice] signal acquired
2015-03-30 17:06:22.015 [bus error] signal lost
2015-03-30 17:06:22.115 [bus notice] signal acquired
2015-03-30 17:07:46.012 [bus error] signal lost
2015-03-30 17:07:46.125 [bus notice] signal acquired
2015-03-30 17:08:06.018 [bus error] signal lost
2015-03-30 17:08:06.111 [bus notice] signal acquired
So geht es dann weiter. Mit der calormatic 470f kann ich nach wie vor Einstellungen ändern aber ich sehe keine Nachrichten über den ebus laufen.
Dann ist mir aufgefallen, dass die Zeit des RPi noch nicht stimmt. Nachdem ich sie korrigiert habe, kamen auf einmal wieder Nachrichten über den ebus:
pi@raspberrypi ~ $ sudo dpkg-reconfigure tzdata
Current default time zone: 'Europe/Berlin'
Local time is now: Mon Mar 30 19:16:42 CEST 2015.
Universal Time is now: Mon Mar 30 17:16:42 UTC 2015.
pi@raspberrypi ~ $ /usr/bin/ebusd -f -l ALL -d /dev/ttyUSB0
2015-03-30 19:16:50.535 [main notice] ebusd 1.1.0 started
2015-03-30 19:16:50.555 [main notice] found messages: 0 (0 poll, 0 update)
2015-03-30 19:16:51.344 [bus notice] signal acquired
2015-03-30 19:16:51.377 [bus notice] new master 10
2015-03-30 19:16:51.378 [bus notice] new master 03
2015-03-30 19:16:51.379 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:01.099 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:09.063 [update notice] unknown BC cmd: 10feb516080008171930030115
2015-03-30 19:17:09.301 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-03-30 19:17:11.123 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:19.087 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-30 19:17:21.122 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:29.059 [update notice] unknown BC cmd: 10feb51603012008
2015-03-30 19:17:31.142 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:39.121 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-30 19:17:41.160 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:17:51.144 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:18:01.168 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:18:09.166 [update notice] unknown BC cmd: 10feb516080008181930030115
2015-03-30 19:18:09.401 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-03-30 19:18:11.182 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:18:19.149 [update notice] unknown BC cmd: 10feb505022900
2015-03-30 19:18:19.409 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-30 19:18:21.968 [update notice] unknown MS cmd: 1008b5100900003d6effff00ff00 / 0101
2015-03-30 19:18:29.179 [update notice] unknown BC cmd: 10feb51603012008
2015-03-30 19:18:31.261 [update notice] unknown MS cmd: 1008b5100900003e6effff00ff00 / 0101
2015-03-30 19:18:39.241 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-03-30 19:18:41.235 [update notice] unknown MS cmd: 1008b5100900003e6effff00ff00 / 0101
2015-03-30 19:18:51.251 [update notice] unknown MS cmd: 1008b5100900003e6effff00ff00 / 0101
Ich kann sogar wieder Werte abfragen (mit den entsprechenden .csv-Dateien). Ansonsten habe ich nichts geändert. Leider verstehe ich dieses Verhalten in keinster Weise. Kann die "Fehlfunktion" wirklich daran liegen, dass die Therme eine andere (=spätere) Zeit hatte (DCF-Funkuhr) als der RPi? Oder kann der Zeitpunkt des Startens des ebusd eine Rolle spielen?
...mal sehen, wie lange er jetzt läuft :-\
Nachtrag: Bei genauerer Betrachtung funktioniert z.B. mit der 470er csv-Datei "read OutsideTemp" ohne Probleme. "read RoomTemp" endet aber zuverlässig immer in einem "ERR: arbitration lost". Kann es etwas damit zu tun haben, dass die OutsideTemp ohne vorheriges Senden bereitgestellt wird? Das würde die Theorie untermauern, dass der Koppler nicht senden kann.
schöne Grüße
Jo
Mein log sieht ja ähnlich aus wie bei Jojo11.
Habe wie Jojo11 die Zeit im ebusd system und im Wolf BM synchronisiert und auch das wolf directory nach /etc/ebusd kopiert, so dass der ebusd jetzt 9 messages findet.
Der log zeigt aber dieselben messages :(
Zitat von: joachimS am 30 März 2015, 20:24:47
Mein log sieht ja ähnlich aus wie bei Jojo11.
Habe wie Jojo11 die Zeit im ebusd system und im Wolf BM synchronisiert und auch das wolf directory nach /etc/ebusd kopiert, so dass der ebusd jetzt 9 messages findet.
Der log zeigt aber dieselben messages :(
Die messages sind bei mir nicht das Problem. Im Gegenteil, sie zeigen ja, dass der Koppler am ebus mitlesen kann. Mit den entsprechenden (zu Deiner Anlage passenden) .csv-Dateien kannst Du sie "übersetzen".
schöne Grüße
Jo
Zitat von: stinch am 29 März 2015, 16:33:34
habe jetzt die aktuelle Version gebaut und die neuen config files verwendet. Seitdem erhalte ich bei den messages im daemon fast nur noch "unknown ms ..."
Folgende config files verwende ich bei o.g. Scan:bai.csv, pms.csv, pmw.hwc.csv ,solsy.cc.csv ,solsy.mc.csv, _templates.csv, broadcast.csv , pms.sc.csv, scan.csv, solsy.hc.csv, solsy.sc.csv , ui.csv
Woran liegt das?
Dazu müsstest Du mal ein paar Zeilen vom Log preis geben, sonst kann ich dazu nichts sagen.
Zitat von: stinch am 29 März 2015, 16:33:34
Wenn ich zusätzlich die solsy.cc.csv erscheint beim reload "Duplicate entry" error.
Du hast glaub ich die solsy.hwc.csv zusätzlich gemeint. Das liegt daran, dass Du bereits eine hwc curcuit in den Config-Files hast, nämlich die pmw.hwc.csv, das verträgt sich nicht gut. In diesem Falll müsstest Du in einer der beiden Dateien in den Zeilen 3-5 bzw. 3-6 aus ",hwc," z.B. ",hwc1," machen, um einen anderen Circuit-Namen dafür zu vergeben.
Wie ist das denn, macht Deine auromatic Warmwasser und Deine Frischwasserstation auch?
Zitat von: stinch am 29 März 2015, 23:11:40
Bei checkconfig kommt kein Fehler. Allerdings erscheint bei ebusd -V weiterhin 1.0.0. das versteh ich nicht.
Probier mal "which ebusd" und schau, wohin das andere frisch compilierte ebusd File abgelegt wurde.
Zitat von: joachimS am 30 März 2015, 19:19:44
Habe ich gemacht und auch das Poti mal durchgedreht.
Ergebnis:
odroid@SmartHome:~$ ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --lograwdata
2015-03-30 18:59:23.807 [main notice] ebusd started
2015-03-30 18:59:23.808 [main error] error reading templates: ERR: element not found
2015-03-30 18:59:23.808 [main notice] found messages: 0 (0 poll, 0 update)
2015-03-30 18:59:47.094 [bus notice] <00
2015-03-30 18:59:47.094 [bus notice] signal acquired
2015-03-30 18:59:47.119 [bus notice] <00
2015-03-30 18:59:47.441 [bus notice] <00
2015-03-30 18:59:47.461 [bus notice] <00
2015-03-30 18:59:47.624 [bus notice] <00
2015-03-30 18:59:47.873 [bus notice] <00
2015-03-30 18:59:48.431 [bus notice] <00
Sehr bizarr. Mach doch mal für ne Minute einen dump ("ebusctl dump") und schick mir die Datei via PN oder einfach an ebusd@johnm.de
Zitat von: Jojo11 am 30 März 2015, 19:27:28
Dann ist mir aufgefallen, dass die Zeit des RPi noch nicht stimmt.
Das ist ein wichtiger Hinweis. Vielleicht kann ich dadurch das Mysterium entschlüsseln.
Hast Du einen NTP konfiguriert?
Falls nicht, dann schau doch mal alle 60 Sekunden, wie sich die Systemzeit auf dem RPi im Vergleich zu der richtigen Uhrzeit ändert.
Ich vermute, dass da ein Problem im Detail steckt.
Zitat von: Jojo11 am 30 März 2015, 19:27:28
Ich kann sogar wieder Werte abfragen (mit den entsprechenden .csv-Dateien). Ansonsten habe ich nichts geändert. Leider verstehe ich dieses Verhalten in keinster Weise. Kann die "Fehlfunktion" wirklich daran liegen, dass die Therme eine andere (=spätere) Zeit hatte (DCF-Funkuhr) als der RPi? Oder kann der Zeitpunkt des Startens des ebusd eine Rolle spielen?
Nein, daran liegt es nicht.
Der ebusd macht aber für die Arbitrierung am Bus ein paar zeitlich abhängige Operationen und wenn Deine Systemzeit wild durch die Gegend springt, bringt das alles durcheinander.
Zitat von: Jojo11 am 30 März 2015, 19:27:28
Nachtrag: Bei genauerer Betrachtung funktioniert z.B. mit der 470er csv-Datei "read OutsideTemp" ohne Probleme. "read RoomTemp" endet aber zuverlässig immer in einem "ERR: arbitration lost". Kann es etwas damit zu tun haben, dass die OutsideTemp ohne vorheriges Senden bereitgestellt wird? Das würde die Theorie untermauern, dass der Koppler nicht senden kann.
Richtig, die outsidetemp kommt vermutlich vom broadcast, den der ebusd ja mitlesen kann. Wenn er aber nicht schreiben kann, dann kannst Du niemals aktiv irgendwas von einem anderen Gerät abfragen.
Ich vermute aber, dass dieses Problem auch mit deinem Zeitproblem in Zusammenhang steckt.
Zitat von: john30 am 30 März 2015, 21:55:06
Das ist ein wichtiger Hinweis. Vielleicht kann ich dadurch das Mysterium entschlüsseln.
Hast Du einen NTP konfiguriert?
[...]
Ich vermute aber, dass dieses Problem auch mit deinem Zeitproblem in Zusammenhang steckt.
Hallo John,
NTP habe ich konfiguriert. Ich verwende einen RPi mit debian wheezy. Das kommt von Haus aus mit NTP. Habe aber jetzt mal ntpdate eingerichtet.
Danach reboot und ebusd wieder gestartet: OutsideTemp geht auch nicht mehr (broadcast-Meldung): "ERR: arbitration lost". Mit Option -f bekomme ich wieder nur "signal lost"/"signal acquired" (s. oben).
Ich hatte mich vor kurzem lange mit dem Hersteller vom ebus-Koppler (eservice) unterhalten und ihm das Problem geschildert. Er vermutet auch ein timing-Problem. Der Koppler sei Hardware-seitig in Ordnung. Frage ich mich allerdings, warum nur ich diese Schwierigkeiten habe...? Der RPi ist weit verbreitet, der Koppler auch und meine Therme ist einen einfache Vaillant 206 mit 470f-Steuergerät :-\
schöne Grüße
Jo
Ich vermute, dass irgendwelche Prozesse auf dem RPi laufen und den bis an die Grenze belasten - oder er einen Hardware-Defekt hat
Habe schon einmal vorgeschlagen, den Buskoppler zu Testzwecken an einem anderen Rechner zu betreiben.
Man könnte auch mal ein komplett neues Image für das Betriebssystem auf eine neue SD-Karte spielen, und nur ebusd installieren.
LG
pah
@john30 & Reinhard:
Vielen Dank für eure Hilfe. Inzwischen habe ich version 1.1.0 compiliert. Die genannten Probleme bestehen jedoch unverändert weiterhin mit den neuen csv files.
Die alten funktionieren problemlos. Irgendeine Idee?
Viele Grüße
David
@stinch
wenn du schreibst, die alten funktionieren problemlos, was meinst du genau damit? Funktionieren die neuen Files aus der Konsole oder aus Fhem nicht?
John hat mit den neuen 1.1.0er CSV's ja einiges an der Namensgebung geändert und zum Schluß nochmals, da hat er diesen komischen Text "DK" noch entfernt. Ich musste hier ebenfalls meine Abfragen alle nach der neuen Namensgebung in Fhem umstellen.
Wenn dich nur die die "Textlosen" Meldungen in der Konsole stören, dann mache John einen "grab" und lade ihm das Ergebnis ins Git als Kommentar hoch! Siehe hier: http://forum.fhem.de/index.php/topic,29737.msg278309/topicseen.html#msg278309 (http://forum.fhem.de/index.php/topic,29737.msg278309/topicseen.html#msg278309)
pi@raspberry2 /etc/init.d $ ebusctl grab
done
pi@raspberry2 /etc/init.d $ ebusctl grab result
1008b5040100 / 0a00012723ffffffff800d
1008b5110101 / 093636800d3a3e0000ff
1008b5110102 / 05033c964666
sieht dann so ungefähr aus, bei dir wird es wesentlich mehr sein.
Anhand der vielen unterschiedlichen Konfigurationen an Geräten kann John dann versuchen eine "gemeinsame" common.csv zusammen stellen die für möglichst alle gilt. Ob es tatsächlich so einfach geht weiß ich nicht, aber so helfen wir ihm zumindest damit.
Hier kannst du dein Ergebnis für John dann posten: https://github.com/john30/ebusd-configuration/issues/3 (https://github.com/john30/ebusd-configuration/issues/3)
LG
Reinhart
Zitat von: Prof. Dr. Peter Henning am 31 März 2015, 10:57:08
Ich vermute, dass irgendwelche Prozesse auf dem RPi laufen und den bis an die Grenze belasten - oder er einen Hardware-Defekt hat
Habe schon einmal vorgeschlagen, den Buskoppler zu Testzwecken an einem anderen Rechner zu betreiben.
Man könnte auch mal ein komplett neues Image für das Betriebssystem auf eine neue SD-Karte spielen, und nur ebusd installieren.
LG
pah
Hallo pah,
wie oben geschrieben habe ich alles ausgetauscht: Neuer RPi, neue SD mit frischem wheezy, neues Netzteil, neues USB-Kabel und abgeschirmtes Kabel zur Therme (3 m lang). Ich habe nur wheezy installiert, LAN eingerichtet, NTP installiert und den ebusd natürlich.
schöne Grüße
Jo
Und anderer Computer ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 März 2015, 16:43:24
Und anderer Computer ?
LG
pah
Bin mir jetzt nicht sicher, welchen Du meinst. Der Raspberry wurde getauscht. Auf ihm läuft der ebusd und an ihn ist der Koppler angeschlossen. Sonst habe ich nur PC usw. von dem ich per SSH auf den RPi zugreife. FHEM läuft auf einem cubietruck, aber bisher versuche ich nur, den RPi mit Therme, Koppler und ebusd zum Laufen zu bringen.
schöne Grüße
Jo
Zitat von: Reinhart am 31 März 2015, 13:13:15
wenn du schreibst, die alten funktionieren problemlos, was meinst du genau damit? Funktionieren die neuen Files aus der Konsole oder aus Fhem nicht?
ich meine damit, dass ich mit den neuen Files in der Konsole viele "unknown ms" erhalte, die mit den alten Files decodiert werden.
ich nutze gar kein fhem. ich speichere die werte mittels vwmon in eine mysql Datenbank und lese dort die werte mittels php aus und gebe sie an meinen knx server weiter.
Viele Grüße
david
@Jo. Eben
Ich schlage vor, einen Desktop-Computer mit ebusd zu versehen und per USB (-Externder) mit dem Buskoppler zu verbinden.
LG
pah
Ok, das lässt sich machen. Werde mal mit einem Ubuntu-Laptop testen und berichten.
schöne Grüße
Jo
Zitat von: stinch am 31 März 2015, 19:00:16
ich meine damit, dass ich mit den neuen Files in der Konsole viele "unknown ms" erhalte, die mit den alten Files decodiert werden.
ich nutze gar kein fhem. ich speichere die werte mittels vwmon in eine mysql Datenbank und lese dort die werte mittels php aus und gebe sie an meinen knx server weiter.
Schick mir doch einfach mal deine alten Configfiles, dann kann ich da mehr dazu sagen.
Zitat von: Jojo11 am 31 März 2015, 09:24:49
OutsideTemp geht auch nicht mehr (broadcast-Meldung): "ERR: arbitration lost". Mit Option -f bekomme ich wieder nur "signal lost"/"signal acquired" (s. oben).
Ich vermute dass bis zum Zeitpunkt Deiner Abfrage noch keine passende broadcast Meldung vorbei kam. Darauf musst Du im Fall von broadcasts natürlich warten, weil diese Daten aus dem ebusd Cache gezogen werden.
Zitat von: Jojo11 am 31 März 2015, 09:24:49
Ich hatte mich vor kurzem lange mit dem Hersteller vom ebus-Koppler (eservice) unterhalten und ihm das Problem geschildert. Er vermutet auch ein timing-Problem. Der Koppler sei Hardware-seitig in Ordnung. Frage ich mich allerdings, warum nur ich diese Schwierigkeiten habe...? Der RPi ist weit verbreitet, der Koppler auch und meine Therme ist einen einfache Vaillant 206 mit 470f-Steuergerät :-\
Das ist eine gute Frage. Wenn Du magst kann ich mal über Ostern mit Teamviewer (oder via Windows Remote Desktop oder direkt über SSH) auf Deinen RPi drauf schauen, vielleicht finden wir das Problem.
@John: Vielen Dank für das Angebot!
Da ich mit einem Ubuntu-Laptop exakt das gleiche Verhalten vorgefunden habe, geht der Koppler heute erneut an den Hersteller zurück, um insbesondere die Sende-Funktion zu überprüfen :(
schöne Grüße
Jo
Zitat von: john30 am 01 April 2015, 08:03:24
Schick mir doch einfach mal deine alten Configfiles, dann kann ich da mehr dazu sagen.
Kann ich machen. Es sind jedoch die files _template, scan, bai00, pms00, pmw00 von dir sowie pah's pah.csv. Hatte daran nix geändert.
Viele Grüße
David
Ah. Damit ist der Fehler entweder im Bus (unwahrscheinlich), oder wirklich im Buskoppler (hm).
Tut mir ja leid, aber hier - und Anfangs auch bei Dir - hat das Ding einwandfrei funktioniert. Also soll eservice das Ding mal ansehen, die Gewährleistung gilt ja noch.
LG
pah
Kein Problem. Bei der ersten Überprüfung wurde wohl nur der Lesevorgang getestet. Es läuft wohl doch auf ein Problem der Schreibeinheit hinaus. Mal sehen was sich bei der Überprüfung ergibt.
schöne Grüße
Jo
Zitat von: john30 am 30 März 2015, 21:48:22
Sehr bizarr. Mach doch mal für ne Minute einen dump ("ebusctl dump") und schick mir die Datei via PN oder einfach an ebusd@johnm.de
Danke John,
John sagt es steht nicht viel drin.
Könnte also an meiner Eigenbau Schaltung liegen.
Habe ein Messgerät aber (noch) keinen Oszi. Überlege mir einen Billig Oszi über den Mikrofon Eingang oder den von LabNation zuzulegen.
Die minütlichen Signal acquired/lost messages, was beweisen die?
Ist das wirklich ein Signal oder versucht es der ebusd nur Timer gesteuert?
Ich habe mir bei der Schaltung grosse Mühe gegeben, hat jemand Vorschläge zur Fehlersuche, wie Referenzspannung?
@joachimS
ich teste das einfach so, dass ich am Buseingang (Ebus-1 und Ebus-2) ein regelbares Netzeil anschließe und langsam von 10 Volt auf 12 Volt hochregle. Bei >12 V sollte der Ausgang des Pin4 (oder Rxd) vom 4011 High werden. Ich habe hier am Pin4 noch eine Led über einen 1K Widerstand angeschaltet, somit sehe ich das optisch wenn der Ausgang High wird.
Wenn kein regelbares Netzteil zur Verfügung steht, dann mache mit einem Poti einen Spannungsteiler . Ein Ende des Poti auf + und das andere auf - und den Minus mit Ebus-2 verbinden. Der Schleifer ist dann Ebus-1. Das Netzteil sollte aber mindestens 13-15 Volt haben. Den eBus aber während diesem Test NICHT mit dem Heizsytem verbinden, sonst kannst was beschädigen.
Beim Senden wird es etwas komplizierter, dazu musst dann alles anschließen und über den PC (Raspi) was senden und der Collector des BD645 (oder Anode der Z-Diode) sollte dann im Takt etwas nach Minus gezogen werden (7,5V). Wirst aber mit einem normalen Multimeter nur schwer feststellen können. Besser wäre hier ein altes analoges Multimeter, das pulsiert dann. Aber der Sendeweg ist bei dir ja keine Frage, zunächst müssen die Broadcast einmal sauber kommen, dazu wird der Sendeweg nicht benötigt weil das Interface nur lauscht. Wenn das Poti auf diesen Schaltpunkt von 12V eingestellt wurde alles entfernen und wieder normal anschließen und wenn du eine Led eingebaut hast sollte diese dann alle paar Sekunden Blinken. Für weitere Diagnosen dann den Raw Modus zum loggen benutzen.
Damit es zu keiner Schwingneigung kommt, kannst zusätzlich zum 4011 noch auf der Spannungsversorgung (Pin7 + 14) einen 100nF Kondensator parallel schalten, aber möglichst nahe am IC. Ebenso kannst die beiden ungenutzten Eingänge des 4011 (Pin12 und 13) auf Minus legen, die könnten zu schwingen beginnen und somit Fehlfunktionen hervorrufen.
Bitte unbedingt beachten, während der Überprüfung mit dem regelbaren Netzteil, den eBus UNBEDINGT abklemmen, sonst kann es zu Zerstörungen/Fehlfunktionen deiner Geräte kommen. Auch der USB2ser Konverter sollte dazu abgeklemmt sein. Weiters solltest du darauf achten, beim Messen nicht abrutschen damit es zu keinem Kurschluß kommt. Wenn du dir nicht sicher bist, eventuell einen Kollegen fragen der sich etwas mit Elektronik auskennt damit er dir die Messungen durchführen kann. Aber wenn du die Schaltung alleine aufgebaut hast, sollte das auch keine Hexerei sein.
LG
Reinhart
Zitat von: Reinhart am 02 April 2015, 12:27:13
@joachimS
ich teste das einfach so, dass ich am Buseingang (Ebus-1 und Ebus-2) ein regelbares Netzeil anschließe und langsam von 10 Volt auf 12 Volt hochregle. Bei >12 V sollte der Ausgang des Pin4 (oder Rxd) vom 4011 High werden. Ich habe hier am Pin4 noch eine Led über einen 1K Widerstand angeschaltet, somit sehe ich das optisch wenn der Ausgang High wird.
Danke Reinhart,
Rxd bleibt auf Low bis >14 V (hoffe das war nicht zuviel, der 4011 verträgt ja auch Vdd von 15V)
Konnte den USB Konverter aber nicht abklemmen da er eingelötet ist. USB und ebus war abgeklemmt, dann hat allerdings der 4011 auch keine Spannung.
Ich habe auch nochmal die Schaltung überprüft und keinen Fehler gefunden.
Kann ich noch vor dem 4011 messen?
Am oberen Optokoppler liegen zwischen pin 1 + 2 nur 1,13V bei 12 V am ebus Eingang an, reicht das?
Bin leider beim Messen mit +12V an das Gehäuse vom 78L05 gekommen, was auf GND liegt. Dürfte höchstens den Dioden was gemacht haben, die haben aber alle noch 0,62V Durchlass Spannung und bei 12,6 V am ebus Eingang liegen noch zwischen 4 und 3, also im Gleichrichter, 11,2V an.
Mit ebus dran liegt zwischen 4 und 3, also im Gleichrichter, knapp 20V an.
Habe auch mal die Spannung am ebus Eingang vertauscht, ändert erwartungsgemäß nichts.
Den ebus hatte ich übrigens falsch angeschlossen, stattdessen hing ein Temperaturfühler dran.
Jetzt sind aber zwischen 1 und 2 ca. 21V, also ebus.
Ich verstehe die Schaltung leider nicht ganz. Welche Spannung müsste am oberen Optokoppler zwischen 1 und 2 liegen, damit an 4 und 5 was rauskommt? Steht komischerweise nicht im Datenblatt.
Ich vermute mal die Spannung fällt am BD645 und Z1 ab.
ZitatIch verstehe die Schaltung leider nicht ganz. Welche Spannung müsste am oberen Optokoppler zwischen 1 und 2 liegen, damit an 4 und 5 was rauskommt? Steht komischerweise nicht im Datenblatt.
Ich vermute mal die Spannung fällt am BD645 und Z1 ab.
Der ebus arbeitet ja so, dass logisch 1 eine Spannung von 15–24 V beträgt und logisch 0 zwischen 9–12 V.
Über R1 kommen nun die High Signale (logisch 1) und der Optokoppler (die integrierte Led leuchtet) schaltet dann durch. R1 dient hier als Strombegrenzung. Pin 4 des oberen Optokopplers (U1) wird nun positiv und steuert Pin2 des 4011 an. Mit dem nachgeschalteten U2-2 wird das Signal nochmals negiert. Der genaue Schaltpunkt hängt nun vom Poti R3 + R2 ab welcher den Pegel am Pin2 einstellt.
Wenn du den Schaltpunkt genau ermitteln konntest ist der Empfangsweg ja schon ok und brauchst eigentlich vor dem 4011er nicht mehr messen wenn hinten schon das Richtige herauskommt.
Der BD645, der Spannungsregler und U2-3 und U3 wird nur für den Sendeweg benötigt und hat für den Empfangsweg keinere weitere Bedeutung (elektronisch gesehen).
So wie du schreibst, ist deine Schaltung empfangstechnisch auf jeden Fall OK! Ich würde allerdings das Poti etwas verstellen, das zumindest schon >13 V auf High geschalten wird, das liegt schön in der Mitte der beiden logischen Pegel. Ich habe meine Schaltung auf exakt 12 V eingestellt und funktioniert seit dem Einschalten zu 100%.
Mir gefällt die Schaltung von pah sehr gut weil sie sehr zweckmäßig und trotz der integrierten galvanischen Trennung ein einfacher Aufbau ist. Somit ist auch hohe Zuverlässigkeit gegeben (wenn sie einmal richtig eingestellt ist).
LG
Reinhart
Zitat von: stinch am 01 April 2015, 16:59:19
Kann ich machen. Es sind jedoch die files _template, scan, bai00, pms00, pmw00 von dir sowie pah's pah.csv. Hatte daran nix geändert.
Nachdem sich die Files häufig geändert haben, hilft mir diese Info nichts. Ich brauche zumindest einen Zeitstempel oder die Git Version dazu. Dann kann ich ein Diff machen und rausfinden, warum das jetzt bei Dir potentiell anders aussieht.
Und zudem wäre auch eine etwas genauere Angabe, was für unknwon messages zu bekommst, hilfreich.
Ansonsten kann ich Dir nicht helfen.
@john30:
hab dir mal die csv files inkl grab result geschickt.
wenn ich die werte mittels read auslese funktioniert es auch mit den neuen files ohne Probleme.
Viele Grüße
david
Hallo, bin auch wieder einen Schritt weiter brauche aber nochmal eure Hilfe.
Benutze Ubuntu14 mit selbstgebauten Adapter von benedikt-patt und habe eine Vaillant VSC 196/3 5
Seit gestern habe ich die neueste eBusd Version sowie die _templates, bai, 430, scan und broadcast.csv eingespielt.
Denke Adapter und Software läuft prima und ich bekomme auch schon die ersten Broadcasts übersetzt.
[2015-04-04 14:37:23.145 [main notice] ebusd 1.1.0 started
2015-04-04 14:37:23.161 [main notice] found messages: 351 (0 poll, 9 update)
2015-04-04 14:37:23.203 [bus notice] signal acquired
2015-04-04 14:37:24.432 [bus notice] new master 10
2015-04-04 14:37:24.432 [bus notice] new master 03
2015-04-04 14:37:26.446 [update notice] update broadcast vdatetime QQ=10: 14:37:28;04.04.2015
2015-04-04 14:37:26.700 [update notice] unknown MS cmd: 1008b512020000 / 00
2015-04-04 14:37:28.482 [update notice] unknown MS cmd: 1008b510090000616effff04ff00 / 0101
2015-04-04 14:37:34.472 [update notice] unknown MS cmd: 1008b5110101 / 09685ef0096c6c0100ff
2015-04-04 14:37:36.529 [update notice] unknown MS cmd: 1008b5040100 / 0a0337371404040615f009
2015-04-04 14:37:36.793 [update notice] unknown MS cmd: 1008b5110102 / 05033c76506e
2015-04-04 14:37:46.581 [update notice] update broadcast outsidetemp QQ=10: 9.938
2015-04-04 14:40:17.473 [bus notice] scan: 08;Vaillant;BAI00;0518;7401
2015-04-04 14:40:18.222 [bus notice] scan: ;21110800
2015-04-04 14:40:18.325 [bus notice] scan: 15;Vaillant;43000;0215;2002
2015-04-04 14:40:18.443 [bus notice] scan: ;100093433
2015-04-04 14:40:18.590 [bus notice] scan: ;21104700
2015-04-04 14:40:18.709 [bus notice] scan: ;100005576
2015-04-04 14:40:18.856 [bus notice] scan: ;200285150
2015-04-04 14:40:18.973 [bus notice] scan: ;N8
2015-04-04 14:40:19.003 [bus notice] max. symbols per second: 153
2015-04-04 14:40:19.120 [bus notice] scan: ;907010914
Wenn ich über ebusctl den Befehl "ebusctl r HwcOPMode" eingebe bekomme ich die Antwort "Auto" zurück.
Was muss ich tun um den Wert von "Auto" auf "manuell" oder "aus" zu stellen.
Ich muss das doch nicht als Code eingeben sondern sicherlich auch über "cbusctl w HwcOPMode [Wert 0,1 oder2]".
Hab schon einiges probiert aber scheinbar hab ich da einen Gedankenfehler.
Ev. kann mir auch jemand helfen die "unknown MS cmd" aufzulösen.
1008b5 ist soweit klar aber dann kommen scheinbar Vaillant spezifische Kommandos und da finde ich im Netz nichts.
Besten Dank schon mal.
Wenn das Funktioniert dann würde ich mich im nächsten Step gerne einen RasPi zulegen.
Da ich hier ja im FHEM Forum bin noch die Frage ob ich den Perl Server auch erstmal auf der selben Maschine einrichte oder wie dieser z.B. auf einem QNAP112 oder der Fritzbox läuft.
Könnte der neue RasPi2 beides. Ich würde nur ungern zum NAS, der Fritzbox und ev. den RasPI noch einen Rechner laufen lassen.
Liebe Grüße und noch frohe Ostern
Horst
Zitat von: Reinhart am 02 April 2015, 16:37:41
Der ebus arbeitet ja so, dass logisch 1 eine Spannung von 15–24 V beträgt und logisch 0 zwischen 9–12 V.
Über R1 kommen nun die High Signale (logisch 1) und der Optokoppler (die integrierte Led leuchtet) schaltet dann durch. R1 dient hier als Strombegrenzung. Pin 4 des oberen Optokopplers (U1) wird nun positiv und steuert Pin2 des 4011 an. Mit dem nachgeschalteten U2-2 wird das Signal nochmals negiert. Der genaue Schaltpunkt hängt nun vom Poti R3 + R2 ab welcher den Pegel am Pin2 einstellt.
Wenn du den Schaltpunkt genau ermitteln konntest ist der Empfangsweg ja schon ok und brauchst eigentlich vor dem 4011er nicht mehr messen wenn hinten schon das Richtige herauskommt.
Der BD645, der Spannungsregler und U2-3 und U3 wird nur für den Sendeweg benötigt und hat für den Empfangsweg keinere weitere Bedeutung (elektronisch gesehen).
So wie du schreibst, ist deine Schaltung empfangstechnisch auf jeden Fall OK! Ich würde allerdings das Poti etwas verstellen, das zumindest schon >13 V auf High geschalten wird, das liegt schön in der Mitte der beiden logischen Pegel. Ich habe meine Schaltung auf exakt 12 V eingestellt und funktioniert seit dem Einschalten zu 100%.
Mir gefällt die Schaltung von pah sehr gut weil sie sehr zweckmäßig und trotz der integrierten galvanischen Trennung ein einfacher Aufbau ist. Somit ist auch hohe Zuverlässigkeit gegeben (wenn sie einmal richtig eingestellt ist).
LG
Reinhart
Zitat
Ich hab meinen Adapter mit einem einfachen Terminal justiert.
Terminal ohne Echo einstellen und Text Schreiben. Wenn dieser sauber gespiegelt wird sollte das ein Nachweis sein, dass der Adapter funktioniert.
Den Bus hatte ich auch über 1KOhm mit 20V gespeist.
@Hasont
du musst beim schreiben mit "-c" das CSV File angeben.
es gibt diese 3 Parameter: off, manual, Auto
r;w,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,0=off;1=manual;2=auto
und hier als Beispiel:
pi@raspberry2 ~ $ ebusctl r -f -m 10 HwcOPMode
auto
pi@raspberry2 ~ $ ebusctl w -c 430 HwcOPMode manual
done
pi@raspberry2 ~ $ ebusctl r -f -m 10 HwcOPMode
manual
LG
Reinhart
@Hasont
Betreffend der "unknown MS cmd", nimm die common.csv noch dazu, hier erweitert John ständig, dann dürfte auch die Betriebsart "standby" erscheinen.
Die 8b511er Meldung habe ich auch, hier kommuniziert offensichtlich die VRC430 mit dem Master, aber die stören mich nicht weiter.
Schöne Grüße
Reinhart
Zitat von: Reinhart am 06 April 2015, 09:34:50
@Hasont
Betreffend der "unknown MS cmd", nimm die common.csv noch dazu, hier erweitert John ständig, dann dürfte auch die Betriebsart "standby" erscheinen.
Die 8b511er Meldung habe ich auch, hier kommuniziert offensichtlich die VRC430 mit dem Master, aber die stören mich nicht weiter.
Schöne Grüße
Reinhart
@Reinhart
vielen Dank, jetzt klappt es bestens.
Jetzt kann ich ja dann an die Visualisierung ran.
Sehe du hast einen RasPi. Funktioniert der gut?
Hast du die Steuerung schon visualisiert und was hast du dafür genommen?
Gruß aus Fürth wo es gerade schneit!
Zitat von: Hasont am 06 April 2015, 10:08:34
Hast du die Steuerung schon visualisiert und was hast du dafür genommen?
Ich bin gerade dabei, eine Visualisierung basierend auf jsplumb zu realisieren. Siehe Screenshot.
Momentan werden die Daten noch über ein PHP Script vom ebusd abgeholt und in JSON umgewandelt. Wenn alles mal steht, werd ich ebusd um eine JSON Schnittstelle erweitern.
Hallo und Frohe Ostern.
Meine Brennwertanlage hat seit gestern eine Macke und wenn ich das im Netz so lese könnte es was größeres sein.... :-(
Wenn man nun heute eine neue Wandtherme kaufen müsste, welche Anlage läßt sich am besten in FHEM integrieren.
Zitat von: Hasont am 06 April 2015, 10:08:34
Sehe du hast einen RasPi. Funktioniert der gut?
Hast du die Steuerung schon visualisiert und was hast du dafür genommen?
Ja, habe es mit YAF hier aus dem Forum visualisiert, siehe hier: http://forum.fhem.de/index.php/topic,31999.msg261064.html#msg261064 (http://forum.fhem.de/index.php/topic,31999.msg261064.html#msg261064)
Ich erfasse auch jede Menge an eBus Daten im FHEM und ich steuere momentan vollautomatisch die Heizkurve (mit Valve einen einfachen Regler aufgebaut). Als Raspi habe ich auf den neuen Raspi 2 FHEM laufen und auf dem alten Raspi B+ den eBus. Zweiterer sitzt direkt neben der Therme. Raspi am Lan ist sehr zuverlässig (Watchdog ECMD läuft auch), im Wlan nicht so weil dieser täglich einmal neu startete (Bug im Wlan-Adapter).
@John30
hast du für deine Zeichnung ein spezielles Programm, oder kreierst du die händisch?
LG
Reinhart
Hallo zusammen,
nochmal die Frage in die Runde: hat jemand eine halbwegs aktuelle vrDialog zur Verfügung?
So langsam kommen immer mehr Geräte, für die die richtigen Werte in meinem Stand der MDB nicht zu finden sind (Januar 2011, Version 2.6.0.2).
Falls also jemand eine neuere besitzt, würde das die Qualität der generierten Konfigurationsdateien sicher verbessern...
Am besten per PN anschreiben.
Merci, John
Zitat von: Reinhart am 06 April 2015, 11:17:55
hast du für deine Zeichnung ein spezielles Programm, oder kreierst du die händisch?
Die Grafiken in den Blöcken habe ich aus Installationsanleitungen gezogen. Die sind noch nicht super schön, aber für den Anfang ausreichend.
Der Rest, also die Verbindungen, die Positionierung der Elemente, Beschriftung, aktiv/inaktiv Zustände etc. werden programmtisch erzeugt.
Der Plan ist, dass sich die Bestandteile nach Abfrage vom ebusd automatisch platzieren, je nach Anlagenkonfiguration und verfügbaren Circuits.
Dann sollte man die Grafiken doch bitte gleich als SVG erzeugen, genau dann kann man sie hinterher auch gut in ein Gesamtbild einpassen.
LG
pah
Zitat von: Reinhart am 02 April 2015, 16:37:41
Wenn du den Schaltpunkt genau ermitteln konntest ist der Empfangsweg ja schon ok und brauchst eigentlich vor dem 4011er nicht mehr messen wenn hinten schon das Richtige herauskommt.
Danke für die Erklärungen Reinhart, jetzt verstehe ich die Schaltung besser.
nein, den Schaltpunkt konnte ich nicht ermitteln
Rxd bleibt auf Low bis >14 V, höher habe ich nicht gewagt zu drehen.
Wie gesagt:
Am oberen Optokoppler liegen zwischen pin 1 + 2 nur 1,13V bei 12 V am ebus Eingang an, reicht das?
Vor R1 ist die Spannung am Gleichrichter natürlich ca. 11V, je nach Spannung am ebus Eingang.
Mein CNY17-4 hat keider keine sichtbare LED. Es ist der Fairchild DC-Optokoppler CNY17IV, 70 V, 50 mA, DIP6
Am Ausgang, zwischen Pin 4 und 5 des CNY17 liegen nur 0V bei einer Eingangsspannung zwischen 11 und 13,3V
@joachimS
da logisch1 am Ebus ja zwischen 15-24V beträgt, ist 12Volt am Ebus Eingang wohl zu wenig um ein durchschalten zu erzwingen. Du muss also höher drehen. Das Messen an den Beinchen der Optokoppler bringt nicht viel, außer du hast einen Verdrahtungsfehler. Der erste wichtige Messpunkt ist Pin3 des U2-1, dieser muss bei logisch 1 umschalten (auf 0 gehen)! Wenn das nicht klappt, dann messe am Pin2 des U2-1 und erhöhe am Eingang die Spannung, die sollte dann beim Durchschalten des CNY17 ansteigen.
Laut Datenblatt des CNY17 ist die Forward Voltage bei 1,25V, also sind die 1,13V die du misst noch zu wenig! Der GND für deine Messungen am 4011er ist der Gnd vom USB Anschluß!
Nachtrag: der 4011 ist leicht zu verstehen, das ist ein 4-fach Nand Gatter, also ein negiertes UND. Nur wenn beide Eingänge auf logisch 1 sind, dann geht der Ausgang auf 0. Alle anderen Zustände ergeben am Ausgang eine 1.
LG
Zitat von: Reinhart am 06 April 2015, 18:02:21
@joachimS
Laut Datenblatt des CNY17 ist die Forward Voltage bei 1,25V, also sind die 1,13V die du misst noch zu wenig! Der GND für deine Messungen am 4011er ist der Gnd vom USB Anschluß!
Thx Reinhart,
bin jetzt mal bis auf 20V am ebus Eingang gegangen,
Am oberen Optokoppler liegen zwischen pin 1 + 2 nur 1,16V bei 20 V am ebus Eingang an.
Warum komme ich da nicht höher?
die Spannung am Gleichrichter ist 18,46V
Zitat von: Prof. Dr. Peter Henning am 06 April 2015, 11:29:57
Dann sollte man die Grafiken doch bitte gleich als SVG erzeugen, genau dann kann man sie hinterher auch gut in ein Gesamtbild einpassen.
gute Idee, ist auch schon umgesetzt und so langsam trudeln reale Daten ein :)
@joachimS
wenn 20 V am Eingang anliegen, messe dann bitte einmal wieviel Strom in mA dann am eBus-Eingang fließen.
Ich werde diese Woche einen 2. Buskonverter bauen damit ich einen in Reserve habe, dann kann ich dir alle wesentlichen Messspannungen in die Schaltung eintragen.
LG
@joachimS
Ich habe heute einen Reserve Konverter gebaut.
Siehe da, er hat ebenso nicht funktioniert. Der Fehler war schnell gefunden, da ich einen anderen Optokoppler eingesetzt habe (einen ILD74, hat 2 Optokoppler in einem 8-pol Gehäuse) hat der ständig durchgesteuert. Ich habe daher den Vorwiderstand von 3k3 auf 33K geändert nun funktioniert alles perfekt.
Die ermittelten Spannungen habe ich dir in die Zeichnung eingetragen. So wie ich das sehe, hast du das gleiche Problem, ändere daher den R1 und es wird klappen. Die Optokoppler haben doch starke Streuungen, den diesen Typ habe ich in der produktiven Schaltung ohne Änderung des R1 schon in Betrieb.
LG
Reinhart
Hallo
und nun noch ein Foto von der Rückseite und jeder kann das ohne Probleme nachbauen :-)
Thanks
mal sehen was der Kundendienst am Do zu meinem Schätzchen sagt
ev gibts ja mal was neues mit top moderner Schaltung...
Zitat von: Reinhart am 07 April 2015, 19:24:41
@joachimS
Ich habe heute einen Reserve Konverter gebaut.
Siehe da, er hat ebenso nicht funktioniert. Der Fehler war schnell gefunden, da ich einen anderen Optokoppler eingesetzt habe (einen ILD74, hat 2 Optokoppler in einem 8-pol Gehäuse) hat der ständig durchgesteuert. Ich habe daher den Vorwiderstand von 3k3 auf 33K geändert nun funktioniert alles perfekt.
Die ermittelten Spannungen habe ich dir in die Zeichnung eingetragen. So wie ich das sehe, hast du das gleiche Problem, ändere daher den R1 und es wird klappen. Die Optokoppler haben doch starke Streuungen, den diesen Typ habe ich in der produktiven Schaltung ohne Änderung des R1 schon in Betrieb.
LG
Reinhart
Danke Reinhart,
bin heute endlich dazugekommen R1 auf 33K zu ändern, aber leider ohne Erfolg, hier meine Messungen:
14V (10V) am ebus:
Optokoppler 1,2
1,037 (1,017)
1,043 bei 16V
Optokoppler 1 und Gleichrichter 2
1,81 (1,79) hängt davon ab zu welchem ebus Anschluss man misst.
Ground und Optokoppler 4
0,12V
rxd und ground (0,003)
@joachimS
und was hast du an Pin2 und Pin4 des 4011, hier siehst du dann ob dies ausreicht um den Optokoppler durchzusteuern. Je nach Stellung des Potis R3 solltest du dann ähnliche Spannungen wie von mir ermittelt haben.
Bei meiner Platine war es ja das Problem, das der Optokoppler mit dem 3K3 ständig durchgesteuert war, deshalb die Änderung um den Strom zu begrenzen.
LG
Reinhart
Hallo,
heute habe ich den ebus-Koppler zurück erhalten. Das alte Gerät wurde ausgetauscht, da es anscheinend einen Defekt hatte. Das Neue habe ich soeben mal in Betrieb genommen. Es scheint einwandfrei zu funktionieren :)
schöne Grüße
Jo
Na, hurra, gratuliere.
LG
pah
Hallo Community,
bin ganz neu hier. Ich habe mich jetzt auch mal mit FHEM versucht und schon ein paar meiner Heizkörper ansteuern können. Ist echt spannend. Ich habe im Sommer vor, mir neben meiner Gasheizung noch eine Solaranlage mit Solarheizung zu zulegen. Kann ich die Solaranlage (http://www.waltermeier.com/de/waerme-klima-service/waerme/solarsysteme/) etc. einfach in das momentane FHEM System integrieren oder werde ich da auf Probleme stossen?
Sollen wir jetzt etwa die Dokumentation der Firma Oertli lesen, um diese Frage zu beantworten ?
Mach ich gerne, mein Stundensatz für solche Aufträge ist allerdings recht hoch. Bitte um kurze Bestätigung und Angabe der Rechnungsadresse.
LG
pah
@ Thomas 1235
da gibts hier im Forum einen eigenen Thread zu...
Hab zwar schon einiges gebastelt und am Laufen aber da trau ich mich noch nicht ran....
Hallo zusammen,
seit einiger Zeit lese ich meine TEM-Regelung für die WP mit der ebus 1.0 Version von John aus. Unter anderem auch den Status der Wärmepumpe.
Seit einiger Zeit wird der Status mittel Postprocessing nicht mehr in einem Reading dargestellt.
Hier als Beispiel mit der Statusmeldung "Abgeschaltet".
Das einzige was ich regelmäßig getan habe, ist FHEM mittels update-Befehl zu aktualisieren.
Hier seht ihr einen Mittschnitt der Logfiles funktionierend / nicht funktionierend.
2015.04.21 22:53:11 5: Cmd: >get HK.Hz WP.status<
2015.04.21 22:53:11 5: ECMDDevice: Analyze command >{"read -f -c heatpump mode"}<
2015.04.21 22:53:11 5: EBUS: sending command "read -f -c heatpump mode"
2015.04.21 22:53:11 5: SW: 72656164202d66202d63206865617470756d70206d6f6465
2015.04.21 22:53:11 5: EBUS: received answer "53;1;00;00;255;0;Abgeschaltet\n\n"
2015.04.21 22:53:11 5: Postprocessing "53;1;00;00;255;0;Abgeschaltet\n\n" with perl command { my ($wp_status); my $hash = $defs{"HK.Hz"}; if( ($_ eq "")||($_ eq "no data stored") ){ $wp_status = "err"; }else{ my @values=split(';',$_); $wp_status = sprintf("%s",$values[6]); } readingsSingleUpdate($hash, "WP_status", $wp_status, 1); }.
2015.04.21 22:53:11 5: Triggering HK.Hz (3 changes)
2015.04.21 22:53:11 5: Notify loop for HK.Hz WP_status: Abgeschaltet
2015.05.10 22:23:58 5: Cmd: >get HK.Hz WP.status<
2015.05.10 22:23:58 5: ECMDDevice: Analyze command >{"read -f -c heatpump mode\n"}<
2015.05.10 22:23:58 5: EBUS: sending command "read -f -c heatpump mode\n"
2015.05.10 22:23:58 5: SW: 72656164202d66202d63206865617470756d70206d6f64650a
2015.05.10 22:23:58 5: EBUS: received answer "53;1;00;00;255;0;Abgeschaltet\n\n"
2015.05.10 22:23:58 5: Postprocessing "53;1;00;00;255;0;Abgeschaltet\n\n" with perl command { my ($wp_status); my $hash = $defs{"HK.Hz"}; if( ($_ eq "")||($_ eq "no data stored") ){ $wp_status = "err"; }else{ my @values=split(';',$_); $wp_status = sprintf("%s",$values[6]); } readingsSingleUpdate($hash, "WP_status", $wp_status, 1); }.
2015.05.10 22:23:58 5: Postprocessed value is "WP_status: ".
Und hier noch der Code im CFG File:
# Status_wp
get WP.status cmd {"read -f -c heatpump mode\n"}
get WP.status expect ".*\n\n"
get WP.status postproc { my ($wp_status);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$wp_status = "err";\
}else{\
my @values=split(';',$_);\
$wp_status = sprintf("%s",$values[6]);\
}\
readingsSingleUpdate($hash, "WP_status", $wp_status, 1);\
}
Hat jemand ne Idee was passiert sein kann?
Dank euch schonmal.
Gruß
Tomy
Also ich kann nichts ungewöhnliches erkennen, außer dass die Anfrage jetzt ein newline am Ende hat, was aber nichts an der Antwort ändert.
Ich würde mal Debug Code einbauen, um zu sehen, was $wp_status enthält, bevor es FHEM übergeben wird.
LG John
Ich kann nur empfehlen, jede Art von "Businesslogik" nicht in dem Klassendefinitionsfile von ECMD abzulegen - sondern als ordentlich Perl-Programm in in die Datei myUtils.pm auszulagern.
LG
pah
Hallo, und einen schönen Guten Tag Herr Prof. Dr. Henning
Ich habe eine Frage zu ihrem Projekt (eBus), was ich übringens super finde.
Meine Terme (Vaillant) sendet das signal auch schnurlos (868mhz) an meine Station (calorMatic 392f) die mit Batterien betrieben wird ! Meine Frage dazu ist, kann ich das Signal auch abfangen z.b mit diesem modul http://www.reichelt.de/Weiteres-Zubehoer/ENOCEAN-PI-868/3/index.html?&ACTION=3&LA=2&ARTICLE=153300&GROUPID=6671&artnr=ENOCEAN+PI+868 (http://www.reichelt.de/Weiteres-Zubehoer/ENOCEAN-PI-868/3/index.html?&ACTION=3&LA=2&ARTICLE=153300&GROUPID=6671&artnr=ENOCEAN+PI+868)
und das System damit Steuern, wissen sie vielleicht was drüber ??
Danke für ihre mühe
Mit freundlichem Gruß
Arkadiusz S.
Hallo,
nein, das geht nicht. Wurde hier auch irgendwo schon erwähnt.
schöne Grüße
Jo
Wo wurde das erwähnt ? Es wurden so viele Protokolle auf 868 MHz schon geknackt, von der Vaillant-Funkschnittstelle habe ich aber noch nichts gesehen
LG
pah
Zitat von: Prof. Dr. Peter Henning am 14 Mai 2015, 17:34:51
Wo wurde das erwähnt ? Es wurden so viele Protokolle auf 868 MHz schon geknackt, von der Vaillant-Funkschnittstelle habe ich aber noch nichts gesehen
LG
pah
Da ich selber eine 470f besitze, habe ich auch zunächst in dieser Richtung gesucht (und das habe ich "erwähnt", allerdings nicht in diesem thread. Der entsprechenden thread lässt sich sicherlich finden.). Allerdings findet man zum Funk-Protokoll von Vaillant so gut wie gar keine Informationen.
Ich gehe aber mal davon aus, dass samseo gedacht hat, man könnte mit den hier besprochenen Routinen und Entschlüsselungen auch über ein entsprechendes Modul direkt per Funk die Therme auslesen/steuern. Weiterhin gehe ich nicht davon aus, dass er zuvor das Protokoll komplett entschlüsseln und reverse-engineeren wollte. Das verlinkte Modul ist explizit ein EnOcean-Modul.
Von daher würde ich behaupten, dass dieses Vorhaben nicht ohne hohen Aufwand zu bewerkstelligen ist. Unmöglich ist es aber sicherlich nicht.
Sollte ich falsch liegen hätte ich auch Interesse an Details zur Entschlüsselung.
schöne Grüße
Jo
Zu einer 470f gibt es ja auch ein Gegenstück und das sollte über eine eBUS Schnittstelle verfügen.
Insofern: keine Notwendigkeit das Funkprotokoll zu entschlüsseln...
Hallo,
ich habe mich endlich getraut ein Interface zu bauen (https://www.mikrocontroller.net/topic/346833 (https://www.mikrocontroller.net/topic/346833)) und anzuschließen. Und es scheint auch zu funktionieren. *freu*
Der ebusd ist auch kompiliert und läuft auf einem banana Pi.
Jetzt weiß ich aber nicht so recht wie weiter. Meine Heizung ist eine WOLF CGB-2-20 + Solarthermie mit Solarmodul SM1 + Außentemperaturfühler.
Wenn ich ebusd -f starte kommen folgende Meldungen:
2015-05-14 22:24:13.218 [main notice] ebusd 1.1.0 started
2015-05-14 22:24:13.219 [main error] error reading templates: ERR: element not found,
2015-05-14 22:24:13.222 [main notice] found messages: 4 (0 poll, 0 update)
2015-05-14 22:24:13.243 [bus notice] signal acquired
2015-05-14 22:24:14.979 [bus notice] new master 71
2015-05-14 22:24:14.980 [update notice] unknown BC cmd: 71fe50230908620900005d010000
2015-05-14 22:24:16.065 [bus notice] new master 03
2015-05-14 22:24:16.065 [update notice] unknown BC cmd: 03fe050308010000ff29143b10
2015-05-14 22:24:16.649 [bus notice] new master 30
2015-05-14 22:24:16.649 [update notice] unknown MM cmd: 3003050709550450000080ff64ff
2015-05-14 22:24:18.565 [update notice] unknown MS cmd: 305050140720000500190064 / 0900000080008000b405
2015-05-14 22:24:20.425 [update notice] unknown BC cmd: 30fe070009008010212214050415
2015-05-14 22:24:22.547 [update notice] unknown MS cmd: 3008502203cc0d00 / 02d100
2015-05-14 22:24:23.043 [update notice] unknown MS cmd: 3008502203cc1600 / 02cf00
2015-05-14 22:24:23.539 [update notice] unknown MS cmd: 3008502203cc6c01 / 020080
2015-05-14 22:24:24.033 [update notice] unknown MS cmd: 3008502203cc6f01 / 020000
2015-05-14 22:24:24.529 [update notice] unknown MS cmd: 3008502203cc1a27 / 02bf00
2015-05-14 22:24:25.024 [update notice] unknown MS cmd: 3008502203cc5327 / 020d00
2015-05-14 22:24:25.365 [update notice] unknown BC cmd: 71fe50180e0080008000800080008000800000
2015-05-14 22:24:25.517 [update notice] unknown MS cmd: 3008502203cc5427 / 020000
2015-05-14 22:24:26.095 [update notice] unknown BC cmd: 03fe050308010000ff29143b10
2015-05-14 22:24:26.735 [update notice] unknown MM cmd: 3003050709550450000080ff64ff
2015-05-14 22:24:28.730 [update notice] unknown MS cmd: 305050140720000500190064 / 0900000080008000b405
2015-05-14 22:24:36.157 [update notice] unknown BC cmd: 03fe050308010000ff29143b10
2015-05-14 22:24:36.824 [update notice] unknown MM cmd: 3003050709550450000080ff64ff
2015-05-14 22:24:38.735 [update notice] unknown MS cmd: 305050140720000500190064 / 0900000080008000b405
2015-05-14 22:24:39.590 [update notice] unknown BC cmd: 30fe03010ea500008000000000000000000000
2015-05-14 22:24:39.993 [bus notice] new master f1
2015-05-14 22:24:39.994 [update notice] unknown BC cmd: f1fe0800080005801000000032
2015-05-14 22:24:40.342 [update notice] unknown BC cmd: 71fe501710bc91f800f60200800080008000800080
2015-05-14 22:24:40.488 [update notice] unknown BC cmd: f1fe050308010000ff76ff3b10
2015-05-14 22:24:44.133 [update notice] unknown BC cmd: 30fe50230528000a1400
2015-05-14 22:24:44.367 [update notice] unknown BC cmd: 71fe50230908620900005d010000
2015-05-14 22:24:44.586 [update notice] unknown BC cmd: 30fe5023054423000000
2015-05-14 22:24:44.995 [update notice] unknown MS cmd: 3008502203cc0e00 / 024e02
2015-05-14 22:24:45.468 [update notice] unknown MM cmd: 3003502203cc0100
2015-05-14 22:24:46.242 [update notice] unknown BC cmd: 03fe050308010000ff29143b10
2015-05-14 22:24:46.489 [update notice] unknown MS cmd: 3076502203ccc103 / 020100
2015-05-14 22:24:46.986 [update notice] unknown MM cmd: 3003050709550450000080ff64ff
2015-05-14 22:24:48.183 [update notice] unknown MM cmd: 7130502309b0f40200045d010000
2015-05-14 22:24:48.987 [update notice] unknown MS cmd: 305050140720000500190064 / 0900000080008000b405
2015-05-14 22:24:53.083 [update notice] unknown MS cmd: 3008502203cc7301 / 024000
2015-05-14 22:24:53.491 [update notice] unknown MS cmd: 3008502203ccbf0a / 020200
2015-05-14 22:24:53.900 [update notice] unknown MS cmd: 3008502203cc1327 / 020000
2015-05-14 22:24:54.396 [update notice] unknown MS cmd: 3008502203cc3127 / 020000
2015-05-14 22:24:54.891 [update notice] unknown MS cmd: 3008502203cc3227 / 020000
Config-Files habe ich keine in /etc/ebusd. Kann ich die scan.cvs oder _template.cvs im GIT unter /vaillant_de/ nutzen?
Danke für die Hilfe.
dru
Zitat von: druschba am 14 Mai 2015, 22:31:30
Jetzt weiß ich aber nicht so recht wie weiter. Meine Heizung ist eine WOLF CGB-2-20 + Solarthermie mit Solarmodul SM1 + Außentemperaturfühler.
...
Config-Files habe ich keine in /etc/ebusd. Kann ich die scan.cvs oder _template.cvs im GIT unter /vaillant_de/ nutzen?
Du könntest die hier benutzen: https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf (https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf)
Und dann könnte man noch den Rest der alten Wolf config-files von hier https://github.com/john30/ebusd-configuration/tree/master/libebus-0.2.x/wolf (https://github.com/john30/ebusd-configuration/tree/master/libebus-0.2.x/wolf) konvertieren.
@john30: Na, dem stimme ich aber nicht zu. Die Möglichkeit einer funkgesteuerten Therme ist nicht uncharmant.
LG
pah
Ich habe festgestellt, dass die Funkverbindung zwischen Therme und Steuergerät sehr instabil ist. Bei mir ist eine Betondecke dazwischen. Übertragungsfehler werden nicht angezeigt, so dass man den optimalen Ort des Gerätes nur mühsam finden kann. Die Empfangsstärke wird in einem Untermenü angezeigt, allerdings auch nur mäßig oft aktualisiert. Im Nachhinein würde ich mich wohl wieder für eine kabelgebundene Version entscheiden.
schöne Grüße
Jo
Na, das ist allerdings ein Killerargument, Thema erledigt.
LG
pah
Etwas OT: Die Erfassung des solaren Ertrages ist bei meinem Vaillant-System granatenmäßig ungenau, obwohl die Steuerung Thermometer an Vorlauf und Rücklauf sowie einen Durchflusssensor hat. Nachdem mich die Werte etwas misstrauisch gemacht haben, habe ich dazu eine eigene Messung aufgebaut.
Per 1-Wire zähle ich sowohl die Impulse des Durchflusssensors, als auch messe ich die beiden Temperaturen. Dann noch etwas Mathematik: http://forum.fhem.de/index.php/topic,36825.0.html
Et voila: Gestern war ein optimaler Solartag (weiß ich von der PV-Anlage). Selbst gemessener Energieertrag der Röhrenkollektoren in den Warmwasserspeicher 9,93 kWh - aber das doofe Vaillant-System zeigt nur 5 kWh an.
LG
pah
Hallo!
Ich hab gerade eine neue Vaillant Heizung mit ebus bekommen, bin auf den Thread gestossen und würde den ebus Adapter gerne nachbauen.
Tolle Arbeit, die Ihr bisher gemacht habt!
Ich würde mich auch um eine Sammelbestellung Platinen kümmern wenn jemand ein Layout hätte (hab ich noch nie selbst gemacht mit Eagle o.ä.)
und wenn natürlich noch ein paar Leute mitbestellen möchten.
Die Kosten pro Platine lägen ab 10 Stück dann vermutlich deutlich unter 10 €,
hat jemand Interesse?
Gruß
Sven
also ich hätte schon interesse ein 2 platinen....
im thread findet sich eine schaltung....
Hallo,
ich habe mir ebenfalls einen Adapter für USB nachgebaut bzw. nachbauen lassen. Sobald ich einen Scan mache, bekomme ich sofort ein Done zurück, über den Bus flimmern dann aber jede Menge Sendeerrors. Ein Scan Result führt zu gar keinem Ergebnis, das Programm endet einfach nicht.
Ich habe einen Vaillant VRS620/3 und die _templates.crv sowie scan.csv aus dem Vaillant Ordner der 1.1 Version entnommen.
Hätte auch Interesse an einer Platine.
Zitat von: Dittel am 21 Mai 2015, 16:39:03
ich habe mir ebenfalls einen Adapter für USB nachgebaut bzw. nachbauen lassen. Sobald ich einen Scan mache, bekomme ich sofort ein Done zurück, über den Bus flimmern dann aber jede Menge Sendeerrors. Ein Scan Result führt zu gar keinem Ergebnis, das Programm endet einfach nicht.
Schau doch mal, ob der Prozess auch Schreibrecht auf dem device hat. Oder hast Du readonly aktiviert?
Das mit der Platine klingt sehr gut - aber ich hänge doch sehr an meinem Aufbau auf einer Lochrasterplatte...
LG
pah
Ok, dann wären wir bei 4 Platinen, falls sich pah von seinem Aufbau noch trennen möchte 5.
@NemoN: Hab den Thread nochmal durchgeschaut, eine Layout Datei hab ich nicht gefunden. Die Schaltung ist ja da,
bloss mit Eagle arbeite ich zum ersten Mal...
@UweH: Du hattest anfangs ein Bild von einem Prototypen gepostet, hast Du da evtl. noch die Daten da?
Grüsse
Sven
Na, bevor ich mich da festlege: Das Layout würde ich gerne sehen und Preis erfahren.
Trennen, wieso ? im gleichen Gehäuse befinden sich noch weitere Schaltungsbestandteile zur Ankopplung meiner VRS 620 an FHEM, u.a. werden diese aus der vom EBUS abgegriffenen 5V-Spannung versorgt.
LG
pah
Habe mit dem eBus-Koppler scheinbar das gleiche Problem wie Jojo11. Lesen funktioniert
ebusctl read -f TempDesired liefert 46.0
ebusctl read -f -d 50 TempDesired liefert 46.0
ebusctl write -c mc TempDesired 47.0 (bzw. auch mit 47)
done
aber der Wert wird nicht verändert oder mache ich etwas falsch?
Werde den Koppler zur Überprüfung schicken.
Wenn die angebotene Platine lesen und schreiben kann, nehme ich eine (Preis?).
Ich hänge noch am Layout...
Wenn das steht kann ich auf der Basis eine Aussage über den Preis machen,
Grüsse
Sven
Hätte evtl auch Interesse an einer Platine.
schöne Grüße
Jo
Hallo zusammen,
mittlerweile läuft bei mir alles recht gut. D.h. ich kann aus meiner Vaillant EcoBlock (Italienisches Modell) alles auslesen und auch schreiben.
Dank der aktuellen CSV Files kann ich auch den ACTOStor Warmwasserspeicher ein/ausschalten (erkennbar an dem "C" im Display der Heizung - Befehl im Ebusd Bai00 WarmstartDemand).
Alles gut soweit. Bisher hatte ich die Therme ohne eine Calormaticsteuerung betrieben. Nun hatte ich mich doch entschlossen eine Calormatic zu kaufen, um die Heizleistung der Außentemperatur anzupassen. Habe im Nachhinein wahrscheinlich das falsche Modell gekauft (430) .. hätte wohl eher die 470 nehmen soll. aber egal. Nun habe ich mit der neu angeschlossenen Calormatic 430 folgendes "Phänomen":
WarmstartDemand lässt sich nicht mehr direkt an der Therme schalten (wird vermutlich von der Calormatic übersteuert).
localhost: r -f WarmstartDemand
yes
localhost: w bai00 WarmstartDemand no
done
localhost: r -f WarmstartDemand
yes
nun habe ich versucht, den ActoStor über die Calormatic an-/auszuschalten.
Ich vermute, dass dies der Befehl HwcParallelLoading ist. Der steht aber auf "off" .. und an der Therme ist der WWSpeicher an (C leuchtet).
Seltsam ist auch, dass der Status bzgl. ACTOStor in der Calormatic auf "nicht erkannt" steht (ACTOstorDetected = no) - in der Therme wird aber etwas erkannt: (APCComStatus = 2). Muss man der Calormatic erst beibringen, dass die Therme eine ACTOStor hat - oder liegt es vielleicht an der alten Calormatic 430? ... sollte ich besser eine 470 verwenden? Die Heizung selbst ist auch nicht mehr die jüngste (4 Jahre alt, damals gab es die 470 noch nicht, drum habe ich gedacht, es ist wohl besser wenn ich eine 430 anschliesse).
Was sehr hilfreich wäre, wenn ihr bei euch auslesen könntet wie der Status von "APCComStatus" und "ACTOstorDetected" ist, falls ihr einen ACTOStor in Verbindung mit der Calormatic angeschlossen habt.
Danke und viele Grüße,
Texel
Na, Vorsicht mit der direkten Ansteuerung der Therme, wenn eine Regelung davor sitzt. Damit kann man die ganze Anlage beschädigen.
LG
pah
Zitat von: zentis666 am 21 Mai 2015, 21:18:23
Ok, dann wären wir bei 4 Platinen, falls sich pah von seinem Aufbau noch trennen möchte 5.
Du willst doch die Schaltung von pah (vergl. auch http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)) layouten und entsprechende Platinen herstellen lassen, oder? Da hab ich auch Interesse. Zusätzlich ne Stückliste bei reichelt o.ä. wäre natürlich auch noch super.
Gruß Dirk
Hi!
Genau das will ich.
Mangels Layout hab ich mich mal übers lange Wochenende mit Eagle beschäftigt
und ich hab versucht den Schaltplan von pah zu layouten. Das Ganze ohne SMDs.
Im Anhang mein Erstlingswerk, wäre toll wenn jemand der mitliest
und sowas schon mal gemacht hat mal draufschauen könnte ob das so passt.
Die FTDI232 Platine würde ich per gewinkelter Buchsenleiste aufstecken.
Bei ITEAD würden 10 Stück mit Versand 38$ kosten. Platinengrösse 52x48mm.
Wenn jemand noch einen Vorschlag wegen Gehäuse hat immer her damit.
Wie gesagt: alle Hinweise/Verbesserungen willkommen, meine erste Platine/Bestellung.
Gruß
Sven
Zitat von: zentis666 am 27 Mai 2015, 21:47:47
Die FTDI232 Platine würde ich per gewinkelter Buchsenleiste aufstecken.
Eine einfache Pin-Leiste hätte den Vorteil, dass das USB=>Serial "Modul" auch gegen ein anderes mit anderer Pinbelegung auszutauschen wäre... ;)
Zitat von: zentis666 am 27 Mai 2015, 21:47:47
ohne SMDs
Sehr gut. Grobmotoriker wie ich können mit dem "Fuddelkram" auch nix anfangen.
Hallo zusammen,
ich habe auch eine Vaillant ecoTec die ich gerne in FHEM (lesend) einbinden möchte.
Meine Lötkenntnisse beschränken sich allerdings eher auf "grobmotorische" Aufgaben, also Stecker oder Verbindungen aus dem Modellbaubereich.
Wie anspruchsvoll wäre es die hier besprochene Platine zu bestücken? Meint ihr ich habe da eine Chance? :P
bei dem zu erwarteten Preis,
Übung macht den Meister...
Zitat von: Franz Tenbrock am 28 Mai 2015, 12:38:42
bei dem zu erwarteten Preis,
Übung macht den Meister...
Das ist wahr, ich hätte dann auch Interesse an der Platine und einer Stückliste.
Erst einmal großes Lob für die Platinen-Initiative. Würde ich auch immer gerne machen, denke aber, dass mein Dienst an der Community besser in neuen Ideen geleistet wird.
Betreffend das Layout selbst: Ich spreche mich hiermit auch für eine möglichst universelle Ankopplung des USB-Teils aus. Zwei Gründe:
1. Unabhängigkeit vom speziellen USB-Adapter.
2. Möglichkeit, statt über USB direkt über WLAN auf den EBUS zu gehen. So, wie ich das hier gemacht habe: http://www.fhemwiki.de/wiki/1W-IF-WIFI.
Mit den neuen ESP8266-Modulen ist das für weniger als 5 € möglich.
Betreffend neue Ideen: Meine Abfragerei der Heizung via ECMD und das ganze Postprocessing ist inzwischen so umfangreich, dass ich das vielleicht demnächst in ein eigenes Modul auslagern werde.
LG
pah
Hallo,
bzgl. der Alternative zu ECMD kann ich Dein Vorhaben nur unterstützen. Hätte ich mehr Erfahrung in diesem Bereich, würde ich das auch machen. Mit ECMD habe ich immer noch Probleme, die mich daran hindern, den Ebus im Produktivsystem auszulesen. Biete mich gerne als Tester an.
schöne Grüße
Jo
Mit den neuen ESP8266-Modulen ist das für weniger als 5 € möglich.
Das Teil ist echt cool
winzig und scheinbar extrem vielseitig...
Zitat von: Prof. Dr. Peter Henning am 28 Mai 2015, 14:41:50
Betreffend das Layout selbst: Ich spreche mich hiermit auch für eine möglichst universelle Ankopplung des USB-Teils aus. Zwei Gründe:
1. Unabhängigkeit vom speziellen USB-Adapter.
2. Möglichkeit, statt über USB direkt über WLAN auf den EBUS zu gehen. So, wie ich das hier gemacht habe: http://www.fhemwiki.de/wiki/1W-IF-WIFI.
pah
Also in der ersten Version ist auf der Platine einfach eine 6er Lochreihe geplant die ich so verdrahtet habe, dass man wenn man eine Buchsenleiste da reinlötet
dieses FTDI232 Modul einfach anstecken kann (ebus.png im Anhang). Da eine einfache PIN Leiste einzulöten wäre ja kein Problem, da könnte man ranstecken was man will... sind halt 2 PINs unbelegt.
Alternative: vom Platz her wäre es kein Problem eine 4er PIN Leiste vorzusehen und diese etwas zum Rand hin zu verschieben, dann könnte man einen 4PIN auf 6PIN Adapter basteln und mit diesem die FTDI Platine auch anstecken. Oder halt was anderes.
Ist mir relativ egal, wäre für mich halt ein Adapter dazwischen mehr aber wenn das die Mehrheit für sinnvoll erachtet dann eben so (ebus2.png im Anhang).
@pah: Hattest Du das so gemeint?
Eine Liste mit den Reichelt Nummern hab ich auch, hoffe ich hab immer die richtigen Teile in der Eagle DB erwischt...
Da ich was SMDs angeht auch Grobmotoriker bin hab ich immer eher die größeren Teile genommen und immer ein bischen Platz gelassen, sollte kein Thema sein das Ding zu löten.
Ein Feedback von irgendwem der Ahnung hat zu meinen Platinen hätt ich noch gerne bevor ich bestelle, nicht dass durch irgendeinen dummen Fehler die Dinger nachher für die Tonne sind... die Dateien zur 4-Pin-Version auch nochmal im Anhang.
Verständnisfrage zur neuen WLAN Variante mit ESP8266-Modulen: das hängt per socat direkt am fhem oder? Dann brauche ich ja keinen Raspi mehr?!
Dann wäre ich auch an dieser Variante interessiert, spar ich mir einen Raspi im Keller.
Gruß
Sven
Na ja, die Datenmenge über eine solche Funkverbindung ist schon relativ hoch.
Es könnte also sein, dass ein einzelner Raspberry überfordert wäre, sowohl FHEM, als auch ebusd zu hosten - habe ich nicht ausprobiert. Eine Funkverbindung (die ggf. sogar aus dem EBUS mit Strom versorgt werden könnte, muss ich ebenfalls noch überprüfen) könnte es aber ersparen, den Raspberry direkt neben die Heizung zu setzen.
Auch könnte man sogar auf eine galvanische Trennung verzichten. So etwa: Man steckt ein kleines Ding mit Antenne seitlich in den EBUS-Anschluss seiner Heizung, und der ganze Rest läuft irgendwo anders.
LG
pah
Hi!
So, das Board ist geprüft und zwei Fehler sind raus ich hab die Platine nochmal verkleinert, langsam freunde ich mich mit Eagle an :D.
Im Anhang das optimierte Layout als Bild, Größe 3,8x5cm, Kosten wären dann also 3,50€ pro Platine plus Versand,
ich würde sagen 4,30€ komplett mit Umschlag und zur Post bringen und so. Die Teileliste mach ich am WE fertig,
Daten sind soweit bereit, es könnte also losgehen.
Bisherige Interessensbekundungen:
Jojo11 (1 + Teile)
tmak (1)
distel (1 + Teile)
NemoN (2)
Papaloewe (1)
zentis (1 ohne Teile)
Franz Tenbrock (1 + Teile)
amuna (1 + Teile)
Sind alle noch an Board?
1 Platine wäre dann noch übrig, wer mag noch?
Gruß
Sven
5 Euro wären auch ok, macht keinen wirklich ärmer.
Paypal möglich? erspart einfach die Überweisung.. unter Freunden kostenlos
Ich will halt nix dran verdienen...
Paypal geht, nehme auch Bitcoin, das ist noch schneller ;D
Nicht wundern wenn sich die Bilder nochmal leicht ändern, ein paar der Beschriftungen sind
im falschen Layer, die schiebe ich gerade noch hin und her...
Gruß
Sven
Hallo
ich wollte doch auch eine :o
machst du auch eine Bestellliste bei Conrad, oder bietest du ev auch die anderen Teile mit an
würde doch Sinn machen da die Versandkosten doch häufig höher als die Teile sind.
Wir machen Vorauskasse, du bestellst alles und dann alles in ein Tütchen.
Dann haben wir alle den gleichen Aufbau
Ist notiert, also 8 bestellt und 2 über.
Ich hatte die Teile vor 2 Wochen von Reichelt geholt, Bestellung kann ich machen,
dann schreibt mir nochmal wer Teile braucht und wer nicht.
Gruß
Sven
Ich würde gerne incl. Teile bestellen
aber nur wenn nicht zu viel Arbeit bzw. die anderen das auch wollen.
Zitat von: zentis666 am 29 Mai 2015, 19:00:50
dann schreibt mir nochmal wer Teile braucht und wer nicht.
Ich nen gern auch mit Bauteilen, hab Akt nix bei den Versendern auf der Wunschliste.
Hallo,
nun gut ;o), dann nehme ich den letzten inkl. Teile, kann damit eine Testumgebung aufbauen.
Viele Grüße und Danke.
Arthur
@John30
Wie ich sehe arbeitest du fleißig im Hintergrund und hast seit ein paar Tagen die 1.2 im Git online gestellt.
Ich habe mir die Version 1.2 installiert und war besonders auf die WebGui neugierig. Dazu habe ich mir am Raspi B+ (eBus Raspi) den Apache2 installiert und dein html Verzeichnis nach /var/www kopiert.
Wollte dir daher ein kurzes Feedback geben, das alles tadellos funktioniert und sogar unter Windows 10 mit Spartan klappt die Gui problemlos (die Objekte sind alle draggable und die Verbindungen werden automatisch nachgeführt bzw. eingefärbt).
Sollten in dieser statischen Testversion auch schon Messwerte dargestellt werden können oder kommt das dann erst in der dynamischen Version?
Auf jeden Fall kann ich dir nur gratulieren, das ist ein tolles Projekt und wird viele begeistern. Wie man sieht, bist du auch in Html sehr gut bewandert.
LG
Reinhart
Hallo,
ich würde auch das Komplettpaket mit Teilen nehmen. Danke!
schöne Grüße
Jo
Hallo!
Die Platinen sind bestellt und in Arbeit. Werden in 2-3 Wochen da sein (China).
Ich bin gerade dabei die Teile für die Bausätze rauszusuchen, wollte bei Reichelt bestellen.
BD645 bekomm ich da nicht, BD203 sieht von den Daten genauso aus (npn 60V 8,0A 60W TO220).
CNY17 Optokoppler nehm ich CNY17/I (Verstärkung 40-80%), in der Wiki steht ja die Teile sind in unkritisch, sollte also passen?!
Anschluss EBUS per 2er Schraubklemme, Anschluss USB-Modul etc. per 4er Stiftleiste.
Ich komme dann insgesamt auf 3,10€ pro Teilesatz plus anteiligem Versand.
Das wären dann bei momentanem Bestellstand 9€ komplett mit Platine und Versand und 4,30€ für nur Platine mit Versand.
Soll ich Euch noch je eine 4er und 6er Buchsenleiste dazulegen für einen kleinen Adapter um das FTDI Modul zu stecken?
Bisheriger Stand der Bestellung:
Jojo11 (1 Platine + Teile)
tmak (1 Platine)
distel (1 Platine + Teile)
NemoN (2 Platinen)
Papaloewe (1 Platine)
zentis666 (1 Platine ohne Teile)
Franz Tenbrock (1 Platine + Teile)
amuna (1 Platine + Teile)
jkriegl (1 Platine + Teile)
Gruß
Sven
Zitat von: zentis666 am 30 Mai 2015, 11:58:05
1 Platine wäre dann noch übrig, wer mag noch?
Wäre auch bereit aufzurunden, wenn wir das alle machen, ist dir ne Ersatzplatine finanziert. Deinen Aufwand wäre es alle mal wert.
Gruß Dirk
aufrunden auf 10 Euro
Buchsenleiste dazu
ev. kann PAH ja noch was dazu schreiben wie man später ev den ESP8266 dazu packen kann
Wo wir gerade dabei sind:
Gehäuse auch? In so was würde man die eBus Schnittstelle und eine zweite Platine reinbekommen,
egal ob ESP8266 oder FTDI...
ABS-Etui-Gehäuse 85x65x28mm, schwarz
http://www.reichelt.de/Etuigehaeuse/SP-2062-SW/3/index.html?&ACTION=3&LA=2&ARTICLE=33822&GROUPID=3356&artnr=SP+2062+SW
Gerne auch was anderes wenn jemand nen Vorschlag hat.
Gruß
Sven
Nehme die 10. (1 Platine + Teile)
Ok dann sind sie alle weg, prima!
Falls irgendjemand im Nachgang noch eine Sammelbestellung machen will kann er gerne die Produktionsdaten und die Stüli bekommen.
@tmak, NemoN, Papaloewe:
ich bestelle die Teile nächstes WE, sagt einfach im Laufe der Woche Bescheid falls Ihr Teile braucht.
Alles zusammen 10€ (Platine, Bauteile, 2 Buchsenleisten für den Anschluss des USB Moduls, Versand).
Falls jemand noch ein Gehäuse will, ich werde mir das hier mitbestellen:
http://www.reichelt.de/Etuigehaeuse/SP-2062-SW/3/index.html?&ACTION=3&LA=2&ARTICLE=33822&GROUPID=3356&artnr=SP+2062+SW
Jojo11 (1 Platine + Teile)
tmak (1 Platine)
distel (1 Platine + Teile)
NemoN (2 Platinen)
Papaloewe (1 Platine)
zentis666 (1 Platine ohne Teile)
Franz Tenbrock (1 Platine + Teile)
amuna (1 Platine + Teile)
jkriegl (1 Platine + Teile)
Gruß
Sven
@Reinhart
Zitat von: Reinhart am 29 Mai 2015, 21:06:06
Wie ich sehe arbeitest du fleißig im Hintergrund und hast seit ein paar Tagen die 1.2 im Git online gestellt.
Ich habe mir die Version 1.2 installiert und war besonders auf die WebGui neugierig. Dazu habe ich mir am Raspi B+ (eBus Raspi) den Apache2 installiert und dein html Verzeichnis nach /var/www kopiert.
Sollten in dieser statischen Testversion auch schon Messwerte dargestellt werden können oder kommt das dann erst in der dynamischen Version?
Den Apache brauchst du dafür nicht, weil ebusd jetzt optional auch einen HTTP Port aufmacht (command line Parameter "--httpport" und "--htmlpath").
Der Clou ist, dass ebusd die paar statischen Dateien liefern kann und eben auch die vom Bus gelesenen Daten als JSON.
Damit kommt Leben in die Seite :-)
Momentan ist das alles auf eine EHP ausgelegt, das wird also bei Dir wenig bis keine Daten anzeigen.
An der dynamischen Konfiguration der HTML Inhalte arbeite ich noch. Der Plan ist, dass am Ende alle Geräte, die in ebusd-configuration verfügbar sind, auch im HTML GUI angezeigt werden können.
Bis das klappt, dauerts aber noch ein Weilchen.
LG John
Danke für die Sammelbestellung. Würde es Sinn machen, diese um das USB Modul zu erweitern?
schöne Grüße
Jo
Ich hab meins von eBay mit kostenlosem Versand. http://pages.ebay.com/link/?nav=item.view&alt=web&id=321647516230
Ist sogar aus DE und war nach 2 Tagen da.
Wenn jemand ne Bezugsquelle auftut wo sich eine Sammelbestellung lohnt dann kann ich das wohl mit verschicken. Ansonsten selber kaufen.
Gesendet von iPhone mit Tapatalk
Danke für den Link. Dann bestell ich auch mal dort ::)
schöne Grüße
Jo
Gibt es für den Preis auch bei ELV.
LG
pah
Aber dort kommt noch die Versandpauschale hinzu, die in der selben Größenordnung liegt. Lohnt sich nicht, wenn man nur dieses Teil benötigt.
schöne Grüße
Jo
Zitat von: zentis666 am 30 Mai 2015, 14:06:53
Falls jemand noch ein Gehäuse will, ich werde mir das hier mitbestellen:
http://www.reichelt.de/Etuigehaeuse/SP-2062-SW/3/index.html?&ACTION=3&LA=2&ARTICLE=33822&GROUPID=3356&artnr=SP+2062+SW
Das Gehäuse nehme ich auch. Danke.
Viele Grüße
Arthur
Zitat von: john30 am 30 Mai 2015, 15:12:26
Der Clou ist, dass ebusd die paar statischen Dateien liefern kann und eben auch die vom Bus gelesenen Daten als JSON.
Damit kommt Leben in die Seite :-)
Momentan ist das alles auf eine EHP ausgelegt, das wird also bei Dir wenig bis keine Daten anzeigen.
An der dynamischen Konfiguration der HTML Inhalte arbeite ich noch. Der Plan ist, dass am Ende alle Geräte, die in ebusd-configuration verfügbar sind, auch im HTML GUI angezeigt werden können.
Bis das klappt, dauerts aber noch ein Weilchen.
LG John
Klasse Arbeit. Hab auch den html Ordner kopiert. Freu mich schon, wenn es dynamisch läuft und bei mir auch passt. DANKE!!!!
@John30,
Auch von mir Feedback und ein großes Danke!!!
ich hab die version 1.2.0 gestern auf dem raspi compiliert, läuft bestens!!!
Bein compilieren gabs einige warnings, FYI:
tcpsocket.cpp: In constructor 'TCPSocket::TCPSocket(int, sockaddr_in*)':
tcpsocket.cpp:34:11: warning: conversion to 'uint16_t {aka short unsigned int}' from 'unsigned int' may alter its value [-Wconversion]
tcpsocket.cpp: In member function 'TCPSocket* TCPClient::connect(const string&, const uint16_t&)':
tcpsocket.cpp:69:21: warning: conversion to 'in_port_t {aka short unsigned int}' from 'unsigned int' may alter its value [-Wconversion]
tcpsocket.cpp: In member function 'int TCPServer::start()':
tcpsocket.cpp:94:21: warning: conversion to 'in_port_t {aka short unsigned int}' from 'unsigned int' may alter its value [-Wconversion]
device.cpp: In static member function 'static Device* Device::create(const char*, bool, bool, void (*)(unsigned char, bool))':
device.cpp:70:23: warning: conversion to 'in_port_t {aka short unsigned int}' from 'unsigned int' may alter its value [-Wconversion] aber die sind kein Problem.
Webserver läuft, ist klar das hier noch nicht alles zur Konfiguration passt, aber etliche Werte werden schon richtig upgedated. (ich hab z.B. Pufferspeicher UND getrennt WW-speicher....)
Eine Frage zum testen der version 1.2.0: braucht der ebusd zur runtime zusätzliche libraries, oder reicht es das binary in ein directory zu kopieren, das konfig u. www-directory richtig zu setzen und zu starten?
Hintergrund: ich will mir die Version 1.1 jetzt noch nicht "zerschießen"..
l.g. erwin
Zitat von: erwin am 31 Mai 2015, 08:27:19
Bein compilieren gabs einige warnings, FYI:
ist bekannt, die Definition eines Ports ist pro Zielsystem etwas unterschiedlich. Macht aber nichts.
Zitat von: erwin am 31 Mai 2015, 08:27:19
Eine Frage zum testen der version 1.2.0: braucht der ebusd zur runtime zusätzliche libraries, oder reicht es das binary in ein directory zu kopieren, das konfig u. www-directory richtig zu setzen und zu starten?
nö, die Abhängigkeiten haben sich nicht geändert.
LG John
hallo,
ist es möglich, irgendwo her die version 1.1.0 nochmals zu erhalten.
1.2.0 scheint nicht mit vwmon zu funktionieren. dort erscheint immer ein Fehler "Socket receive failed or timeout for command read -c uih OutsideTemp tempsensor". mit 1.1.0 war dies noch problemlos möglich. der read Befehl ist korrekt. funktioniert problemlos über ebusctl - auch wenn ebusd über vwmon gestartet wurde.
Viele Grüße
david
ok, hab die 1.1.0 nochmal gefunden. damit funktioniert es wieder.
@John30
Danke für die Info!
Ich habe jetzt den Apache gestoppt und die Dämon Options geändert, jetzt läuft der "Webserver" auch nur über den ebusd so wie von dir erklärt.
EBUSD_OPTS="-l /var/log/ebusd.log -d /dev/ttyUSB0 -p 8888 --httpport=80 --htmlpath=/var/www"
Ja, ich habe in der index.html gesehen das im Augenblick alles auf "ehp" ausgelegt ist. Kann ich die "data-id" nach bestimmten Regeln selber zusammen bauen oder muss da auch am ebusd was angepasst werden damit die "data-library" auch befüllt wird?
LG
Reinhart
@zentis666: meine beiden platinen bitte mit Teile :-)
Gesendet von meinem LG-D855 mit Tapatalk
Zitat von: zentis666 am 30 Mai 2015, 14:06:53
ich bestelle die Teile nächstes WE, sagt einfach im Laufe der Woche Bescheid falls Ihr Teile braucht.
Alles zusammen 10€ (Platine, Bauteile, 2 Buchsenleisten für den Anschluss des USB Moduls, Versand).
Dann noch raus damit: Wohin mit unserer Kohle? Vertraue Dir mal, dass Du mit meinem Zehner nicht durchbrennst ;) Außerdem bist Du mit Layouten und Kümmern ja schon genug in Vorleistung gegangen!
Gruß Dirk
PS: Am Besten per PN, oder?
dito
8)
Zitat von: Reinhart am 31 Mai 2015, 19:31:52
Ja, ich habe in der index.html gesehen das im Augenblick alles auf "ehp" ausgelegt ist. Kann ich die "data-id" nach bestimmten Regeln selber zusammen bauen oder muss da auch am ebusd was angepasst werden damit die "data-library" auch befüllt wird?
Benötigt werden eigentlich nur die UI Sachen, also svgs für die entsprechenden Komponenten sowie die Info, wie eine Komponente mit einer anderen hydraulisch verschaltet wird, um die Verbindungen zu etablieren. Die Daten sind alle schon da, also ebusd-seitig ist nichts mehr zu tun.
Meine Vorstellung wäre, ein json File für jedes Gerät zu haben (anhand des circuit Namens unterschieden), in dem die Position und Benennung der Anschlüsse und der dargestellten Daten enthalten ist. Dann würde eine erste Verbindung zum ebusd die Gesamtliste der Nachrichten abrufen, daran die vorhandenen Geräte erkennen und diese dann im UI platzieren, nachdem die Info aus dem json File abgerufen wurde.
Wenn Du also Lust hast, dann schau doch mal in das Installationshandbuch-PDF Deiner Anlage und extrahiere ein svg für die einzelnen Bestandteile, dann können wir das mal in Angriff nehmen.
LG John
@zentis666 Ich nehme auch gerne alles zusammen! Danke!
@John30
Danke für deine Erklärungen und deinem Vorschlag!
Natürlich habe ich Interesse und habe auch schon die Installationshandbücher untersucht aber bei der Vaillant Ecotec habe ich noch keine brauchbaren Blockschaltbilder gefunden.
Im Prinzip ist es ja ähnlich deinem ehp.svg mit leichten Modifikationen. 2 Wärmetauscher, eine Umlaufpumpe für Heizkreislauf, ein drehzahlgesteuerter Ventilator. Eine Storage gibt es dann nicht weil die Heißwasserentnahme direkt erfolgt.
Wenn ich nichts brauchbares finde dann versuche ich ein svg mit Viso zu zeichnen. Ich muss allerdings schauen ob es zeitlich noch hinbekomme, weil ich in 10 Tagen eine größere Herz Op. habe und noch einiges vorher erledigen muss.
Aber das Prinzip der GUI ist mir dank deiner Erklärungen etwas klarer geworden.
LG
Reinhart
Zitat von: john30 am 14 Mai 2015, 08:37:03
Also ich kann nichts ungewöhnliches erkennen, außer dass die Anfrage jetzt ein newline am Ende hat, was aber nichts an der Antwort ändert.
Ich würde mal Debug Code einbauen, um zu sehen, was $wp_status enthält, bevor es FHEM übergeben wird.
LG John
Hallo John,
komme erst jetzt wieder dazu mich meinem Fehler zu widmen. Leider bin ich absoluter Perl Anfänger. Wie genau funktioniert das mit dem "Debug Code einbauen".
Lieben Dank für eine Antwort.
Gruß
Tomy
Hm, dann würde ich doch vorschlagen, Perl zu lernen...
Das haben wir alle so gemacht und, ja, das kostet Zeit und Mühe.
LG
pah
@Jojo11: Etwas verspätet, aber - wieso ? Ich zahle bei ELV Dank Kundenkarte (20 €/Jahr) keinerlei Versandkosten.
LG
pah
Na dann lohnt sich das ja für Dich. Ich bestelle bei ELV ca. einmal im Jahr. Damit bin ich wohl nicht die Zielgruppe für eine solche Porto-flatrate.
schöne Grüße
Jo
Zitat von: Prof. Dr. Peter Henning am 04 Juni 2015, 17:16:14
Hm, dann würde ich doch vorschlagen, Perl zu lernen...
Das haben wir alle so gemacht und, ja, das kostet Zeit und Mühe.
LG
pah
Hallo pah,
wie von dir vorgeschlagen habe ich nun einen Schnell-Kurs über Nacht in Perl belegt und damit mein Problem selbst gelöst. :D
Fehler war:
Ich hatte ein "event-on-change-reading" auf alle Readings mit einem Zahlentreshold belegt:
event-on-change-reading .*:0.3Dies führt dazu, dass Text-Readings keinen Inhalt mehr zurück geben.
Lösung "event-on-change-readings" aufteilen:
event-on-change-reading Status_Waermepumpe,WP.*:0.3,WW.*:0.3,SP.*:0.3,H.*:0.3,A.*:0.3Typischer Anfängerfehler halt :( ... nochmals danke für den Tip mit dem Perl lernen ;)
LG Tomy
Hallo!
Update unserer Sammelbestellung:
die Platinen sind fertig und in der Post,
Gruß
Sven
Gesendet von iPhone mit Tapatalk
Hallo,
ich habe nun auch endlich angefangen meinen ebus zu enträtseln.
Durch Eure klasse Arbeit steig ich auch so langsam dahinter. - Vielen Dank dafür!
Eines von vielen mir noch verbliebenen Rätseln ist ein Busteilnehmer.
Ein Scan liefert bei mir:
localhost: scan full
done
localhost: scan result
15;Vaillant;UI ;0307;6201
23;Vaillant;SOLSY;0302;6301
26;Vaillant;SOLSY;0302;6301
44;Vaillant;SOLSY;0302;6301
50;Vaillant;SOLSY;0302;6301
ec;Vaillant;SOLSY;0302;6301
Soweit hab ich alle Busteilnehmer verstanden bis auf den 44.
Kann mir jemand verraten, was das ist?
Danke.
Gruss,
Wolle
Zitat von: wollet42 am 07 Juni 2015, 14:52:34
Soweit hab ich alle Busteilnehmer verstanden bis auf den 44.
Schätze das ist ein Boiler.
John
@john30
was meinst Du mit Boiler - etwa den Warmwasserspeicher?
Also sollte ich dort irgendwie die Temperaturwerte fuer oberen und unteren Fuehler finden?
Danke.
Ein WW-Speicher ist kein Boiler.
Mit "Boiler" ist ein Wärme erzeugendes Gerät gemeint, z.B. eine Therme.
LG
pah
Auf den ersten Blick fällt mir auf das beim letzten Stand (ebusd2) des Ebus Konverters die Stromversorgung für den 4011 fehlt. Wurde dies noch vor der Bestellung korrigiert? Wo finde ich den letzten Stand des Konverters??
Seltsame Frage.
Was ist gemeint: Der Schaltplan ? Wenn ja, wieso dann ebusd2 ?
Oder die Platine ? Wenn ja, was soll "finde ich" bedeuten - finden des Bildes, oder der fertigen Platine ?
LG
pah
gemeint ist ebus2.brd und ebus2.sch von Zentis666 wie hier vor einigen Beiträgen zu finden war.
Es kamen dann auch noch 2 Bilder vom Board, hier konnte ich aber leider nicht viel erkennen, daher die Frage ob man das aktuelle Layout irgendwo finden kann...
Hi!
In dieser "ebus2" war das auch im Board Layout falsch, das war aber auch nicht die letzte Version.
Ich hab das Layout mit Eagle gemacht, wenn man da VCC und GND korrekt setzt, wird der 4011er automatisch angeschlossen,
das war einer der Fehler die ich dann korrigiert habe.
Meine Nummerierung war nicht ganz logisch, ich hatte erst 2 Varianten (ebus und ebus2),
nachdem klar war wie wir das anschliessen hab ich dann mit ebus1.1, 1.2 etc. weitergemacht.
ebus1.3 ist in Produktion gegangen, habs mal angehängt.
Ein Fehler ist aber noch drin: eagle hat eine andere Pinbelegung als pah im Schaltplan für den 78L05 (in und out vertauscht)
so dass wir den nicht wie auf der Platine gedruckt einlöten müssen sondern gedreht. Hab ich leider erst zu spät bemerkt,
ist aber kein Beinbruch.
Bestellungs-Update: die Teile und Gehäuse sind da, die Platinen noch nicht, sind immer noch "in transit".
Gruß
Sven
OK. Dann wird das schon so passen :)
Du hast die Gerber Files angehängt. Wenn du noch die Eagle dateien mit anhängst kann ich die mir gerne noch mal anschauen.
Hi!
Hier noch Board- und Schaltungsfile
Gruß
Sven
Hallo,
ich habe gerade von einer frühen auf die aktuelle ebusd-Version und die zugehörigen Konfigurationsdateien aktualisiert.
Gute Arbeit!
Ich habe bis auf einen auch alle Parameter übersetzen können.
Aber was ist aus folgender Abfrage geworden:
bai00.csv:rb,,mcPumpPower,Aktuelle Heizpumpenleistung in %,,,,7300,,,status,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Danke für Eure Hilfe!
Hallo,
jetzt muss ich mich auch mal melden. :-)
Ich habe es geschafft, über das eservice Modul und dem ebusd mit meiner Vaillant Therme zu kommunizieren. Hat soweit alles ohne grössere Probleme geklappt.
Worauf ich allerdings auch nach lesen von 55 Threadseiten keine einfache Antwort bekommen habe, ist die Einbindung in FHEM.
Zumindest für Systeme, bei denen FHEM und ebusd auf dem gleichen System läuft, hätte ich hier eine extrem einfache Lösung: CustomReadings.
bei mir sieht das in einem ersten Test so aus:
define HeizungReadings CustomReadings
attr HeizungReadings event-on-change-reading .*
attr HeizungReadings interval 120
attr HeizungReadings readingDefinitions OutsideTemp:qx(ebusctl read OutsideTemp),
TempVorlauf:qx(ebusctl read FlowTemp),
TempRuecklauf:qx(ebusctl read SDTRT),
WaterPressure:qx(ebusctl read WaterPressure),
Coll1Sensor:qx(ebusctl read Coll1Sensor),
YieldSensor:qx(ebusctl read YieldSensor)
attr HeizungReadings room Heizung
Generell funktioniert das. Im Moment habe ich allerdings noch das Problem, dass bei manchen Lesevorgängen an die Readings jede Menge Meldungen der Art "ERR: command not found" angehängt werden. Vielleicht geht das Lesen zu schnell. Würden ein paar delays helfen?
Spricht generell etwas gegen diese einfache Variante?
Gruß
Georg
Zitat von: Georg312 am 21 Juni 2015, 20:14:32
Worauf ich allerdings auch nach lesen von 55 Threadseiten keine einfache Antwort bekommen habe, ist die Einbindung in FHEM
Das Wiki hat da aber schon ein paar Infos parat... http://www.fhemwiki.de/wiki/EBUS#Konfiguration_FHEM (http://www.fhemwiki.de/wiki/EBUS#Konfiguration_FHEM)
Allerdings bislang noch kein Praxiswissen hier bei mir... ::)
Hallo zusammen,
sorry, wenn ich den alten Thread nochmal hochhole. Habe aber immer noch keine Lösung. Mittlerweile habe ich die Calormatic 470 gekauft. Allerdings wird in der Calormatic leider auch kein ActoStor erkannt. Zumindest bringt das Register ACTOstorDetected immer "no" zurück. Vermutlich wird drum auch an der Therme immer das "C" angezeigt und der Speicher immer geladen... könnte jemand von Euch vielleicht dieses Register auslesen (falls ihr auch ein ACTOstor verbaut habt, ob bei Euch "yes" drinsteht .. ?
Die Therme erkennt den ActoSTOR wohl, ansonsten würde ja kein C angezeigt werden, oder?
VG Texel
Zitat von: texel am 23 Mai 2015, 08:46:56
Hallo zusammen,
mittlerweile läuft bei mir alles recht gut. D.h. ich kann aus meiner Vaillant EcoBlock (Italienisches Modell) alles auslesen und auch schreiben.
Dank der aktuellen CSV Files kann ich auch den ACTOStor Warmwasserspeicher ein/ausschalten (erkennbar an dem "C" im Display der Heizung - Befehl im Ebusd Bai00 WarmstartDemand).
Alles gut soweit. Bisher hatte ich die Therme ohne eine Calormaticsteuerung betrieben. Nun hatte ich mich doch entschlossen eine Calormatic zu kaufen, um die Heizleistung der Außentemperatur anzupassen. Habe im Nachhinein wahrscheinlich das falsche Modell gekauft (430) .. hätte wohl eher die 470 nehmen soll. aber egal. Nun habe ich mit der neu angeschlossenen Calormatic 430 folgendes "Phänomen":
WarmstartDemand lässt sich nicht mehr direkt an der Therme schalten (wird vermutlich von der Calormatic übersteuert).
localhost: r -f WarmstartDemand
yes
localhost: w bai00 WarmstartDemand no
done
localhost: r -f WarmstartDemand
yes
nun habe ich versucht, den ActoStor über die Calormatic an-/auszuschalten.
Ich vermute, dass dies der Befehl HwcParallelLoading ist. Der steht aber auf "off" .. und an der Therme ist der WWSpeicher an (C leuchtet).
Seltsam ist auch, dass der Status bzgl. ACTOStor in der Calormatic auf "nicht erkannt" steht (ACTOstorDetected = no) - in der Therme wird aber etwas erkannt: (APCComStatus = 2). Muss man der Calormatic erst beibringen, dass die Therme eine ACTOStor hat - oder liegt es vielleicht an der alten Calormatic 430? ... sollte ich besser eine 470 verwenden? Die Heizung selbst ist auch nicht mehr die jüngste (4 Jahre alt, damals gab es die 470 noch nicht, drum habe ich gedacht, es ist wohl besser wenn ich eine 430 anschliesse).
Was sehr hilfreich wäre, wenn ihr bei euch auslesen könntet wie der Status von "APCComStatus" und "ACTOstorDetected" ist, falls ihr einen ACTOStor in Verbindung mit der Calormatic angeschlossen habt.
Danke und viele Grüße,
Texel
Hallo Sammelbesteller,
die Platinen sind heute eingetroffen, anbei ein paar Bilder. Ich mach die Sendungen am WE fertig und schick sie am Montag raus,
Gruß
Sven
(http://images.tapatalk-cdn.com/15/06/27/1d708b4e2acb68d7934f2f3b2e1bc419.jpg)
(http://images.tapatalk-cdn.com/15/06/27/7f38c1ba43a0cc3911f01167b3ffd140.jpg)
(http://images.tapatalk-cdn.com/15/06/27/e30be6690f7be06f1bb06f86508bc84c.jpg)
(http://images.tapatalk-cdn.com/15/06/27/1387e14be0a1876ed71c97edac48b7e5.jpg)
Gesendet von iPhone mit Tapatalk
Nett.
LG
pah
Danke!
schöne Grüße
Jo
Zitat von: zentis666 am 27 Juni 2015, 14:31:42
Ich mach die Sendungen am WE fertig und schick sie am Montag raus
Arrrgghhh! Da muss ich aber noch Bastelzeit-Budget beantragen! Wird knapp ;) - Wobei: Die Post streikt ja, da kanns ja auch noch dauern :D
Vielen Dank!
Geht relativ schnell, hatte das Ding in weniger als ner halben Stunde zusammengebraten (man siehts an den Fotos ;D)
Die Schaltung läuft auch prinzipiell an meiner Heizung.
Hab bloß noch Probleme bei der Einstellung des Potis, der Bereich in dem sinnvolle Daten kommen ist sehr klein.
Ich bekomme zwar Daten aber nach ein paar Sekunden ist immer das Bus-Signal weg. Hab schon über eine Stunde am Poti rumgestellt,
ich bekomme es nicht besser hin. Ich poste nachher noch ein logfile.
@zentis666
wenn ich mir die Fotos anschaue, dann habe ich den Eindruck du hast die Bauteile an der Rückseite der Platine nicht verlötet.
Wäre dies der Fall, dann wird je nach Art der Durchkontaktierung die Schaltung nicht besonders stabil arbeiten, CMos Bauteile haben sehr hochohmige Eingänge und neigen leicht zum schwingen wenn die Verlötung nicht zu 100% passt.
Schau dir das bitte noch einmal an, kann aber sein, dass das Foto mich etwas täuscht.
LG
@Texel: Ich weiß nicht, ob das hilft, aber ich habe festgestellt, daß manchmal nach dem Setzen eines Parameters beim Auslesen noch der alte Wert drin steht. Hier hilft ein "reload", dann zieht EBUSD die aktualisierten Werte... Also erst Wert schreiben, dann reload, dann Wert auslesen
Zitat von: Reinhart am 29 Juni 2015, 19:29:10
@zentis666
wenn ich mir die Fotos anschaue, dann habe ich den Eindruck du hast die Bauteile an der Rückseite der Platine nicht verlötet.
Danke für den Tip, ich hatte tatsächlich nur von einer Seite gelötet. Habe nochmal auf der oberen Seite nachgelötet,
ist aber noch das gleiche Verhalten.
Gruß
Sven
Gesendet von iPhone mit Tapatalk
Problem gelöst: bei meinem Raspi war ein 2A Samsung USB Netzteil, hab es ausgetauscht und nun ist der Bus stabil.
Gesendet von iPhone mit Tapatalk
Das ist super, wenn es bei dir nun funktioniert!
Das mit den Netzteilen ist ein allgemeines Problem, auch wenn 2A drauf steht hat man keine Garantie das der Strom auch geliefert wird. Hier kann man eigentlich nur probieren.
LG
Beim Raspi scheint das Problem nicht die maximale Stromstärke zu sein, sondern die Stabilität der Versorgungsspannung. Dazu gibt es hier zahlreiche Beiträge.
schöne Grüße
Jo
Zitat von: cs-online am 29 Juni 2015, 20:59:17
@Texel: Ich weiß nicht, ob das hilft, aber ich habe festgestellt, daß manchmal nach dem Setzen eines Parameters beim Auslesen noch der alte Wert drin steht. Hier hilft ein "reload", dann zieht EBUSD die aktualisierten Werte... Also erst Wert schreiben, dann reload, dann Wert auslesen
Reload ist etwas heftig, ein einfaches "read -f ..." tuts auch, damit wird der cache umgangen.
Hallo Sven,
die Teile sind heute angekommen, Danke.
Jetzt nur noch Zeit finden...
Viele Grüße
Arthur
@John: Danke für den Hinweis !!! Das kannte ich noch nicht, werd ich mal ausprobieren.
Hallo Sammelbesteller,
Noch ein Hinweis, hatte ich zwar schon weiter oben geschrieben aber lieber nochmal: der U4 (78L05) muss 180 Grad gedreht zum Druck eingelötet werden, sonst sind in und out vertauscht.
Gruß
Sven
Gesendet von iPhone mit Tapatalk
Hallo, ich habe auch den Ebusd mit FHEM auf einem Raspberry Pi2 ModelB bereits am laufen. Derzeit kann ich noch keine Probleme erkennen, obwohl EbusD und FHEM auf ein und dem selben Raspberry läuft. Allerdings fange ich mit FHEM erst an. Ist also sonst fast leer. Ich kann aber bereits mehere Daten meiner Vaillant Wärmepumpe VWS63-3 auslesen und im Diagramm darstellen. Also erstmal ganz herzlichen Dank an all die Softwareentwickler.
Zuerst möchte ich eine Übersicht über alle möglichen Ebusd-Befehle (sowie den Antworten dazu) bekommen. Anschließend kann ich dann die Befehle die ich nicht über FHEM ausführen möchte herausnehmen (wegen Sicherheitsbedenken die hier schon aufkamen).
Dazu habe ich mir vom Ebusd mit Option dumpconfig eine Liste generiert. Diese Liste wird nun in einem Perl-Programm nach Namen Sortiert und die entsprechende config-Datei ebus.cfg generiert. Außerdem wird ein Timer mit allen Befehlen geladen. So der Plan :) der schon fast fertig ist und teilweise bereits läuft.
Im Moment habe ich noch eine Frage zu den Befehlen aus der CSV-Datei ehp_brinetowater.csv.
Hier gibt es z.B. zu dem Befehl "SourceTempInput" eine "u" und eine "r" Variante. Dazu folgende Fragen:
-Das "r" steht wohl für "read". Wofür steht das "u"?
-Beide Befehle kann ich über telnet und den Ebusd an die Wärmepumpe absetzen. Allerdings nur wenn ich dem Ebusd mit read -h .... (send hex message) anspreche. Jedoch bekomme ich dann auch die Antwort in schwer lesbarem Hex-Format. Da beide Befehle ja den gleichen Befehlsnamen und die gleide Zieladresse haben, kann ich den Befehl nicht in Form von "read SourceTempInput" absetzen. Zumindest würde der Befehl immer nur einen von den Beiden definierten Varianten ausführen können. Als Lösung fällt mir nur ein die CSV-Datei entsprechend umzubauen, dass die beiden Befehle einen unterschiedlichen Namen bekommen...!? Gibt es hier nicht einen Besseren Weg? Sollte das so sein?
-->nachtrag... habe jetzt in der csv die Einträge für r,ehp... in r,ehp1 und u,ehp in u,ehp2 geändert... sollte also damit recht einfach behoben sein...
-Wäre es nicht sinnvoll die expect und postproc-Ausdrücke mit in die csv-Datei zu packen?
Gruß primi
Zitat von: primi am 02 Juli 2015, 14:28:22
-Das "r" steht wohl für "read". Wofür steht das "u"?
"u" steht für "upate" und macht die Nachricht zu einem passiven read, womit ebusd die Nachricht nur mitlauscht, aber nicht mehr selbst aktiv abfragen kann. Zudem wird über dieses Typzeichen auf eine andere defaults-Zeile umgeschwenkt (Zeile 4 der ehp_brinetowater.csv statt Zeile 3), so dass aus ff08b509030d0f00... dann ff08b50903290f00|XXXX... wird (zwei bytes in der Slave-Antwort ignorieren).
Zitat von: primi am 02 Juli 2015, 14:28:22
-Beide Befehle kann ich über telnet und den Ebusd an die Wärmepumpe absetzen. Allerdings nur wenn ich dem Ebusd mit read -h .... (send hex message) anspreche. Jedoch bekomme ich dann auch die Antwort in schwer lesbarem Hex-Format. Da beide Befehle ja den gleichen Befehlsnamen und die gleide Zieladresse haben, kann ich den Befehl nicht in Form von "read SourceTempInput" absetzen. Zumindest würde der Befehl immer nur einen von den Beiden definierten Varianten ausführen können. Als Lösung fällt mir nur ein die CSV-Datei entsprechend umzubauen, dass die beiden Befehle einen unterschiedlichen Namen bekommen...!? Gibt es hier nicht einen Besseren Weg? Sollte das so sein?
Ja das soll genau so sein, da die "29" Nachricht nur aktiv vom Controller an die WP gesendet wird und es wenig Sinn macht, das vom ebusd in der Form auch zu tun.
Zitat von: primi am 02 Juli 2015, 14:28:22
-->nachtrag... habe jetzt in der csv die Einträge für r,ehp... in r,ehp1 und u,ehp in u,ehp2 geändert... sollte also damit recht einfach behoben sein...
Das ist Quatsch, lies einfach ehp SourceTempInput. Wenn dir Daten aus dem Cache vom Alter her genügen, wird das neuere von beiden genommen. Andernfalls (mit "read -f") wird sowieso die "r" Nachricht verschickt und ausgewertet.
Zitat von: primi am 02 Juli 2015, 14:28:22
-Wäre es nicht sinnvoll die expect und postproc-Ausdrücke mit in die csv-Datei zu packen?
Das wär ziemlich sinnlos. Vernünftiger wäre es, ein eigenes FHEM Plugin für ebusd zu schreiben. Dafür fehlts mir aber an Zeit, Energie und Perl-Knowhow.
Zitat von: zentis666 am 27 Juni 2015, 14:31:42
Ich mach die Sendungen am WE fertig und schick sie am Montag raus
Heute angekommen - und dabei sind die noch gar nicht durch mit dem Streik - für ne Warensendung schon fast reguläre Laufzeit...
Danke Sven!
Jetzt nur noch das Löteisen aufheizen... aber es ist eh so warm :-/
Gern geschehen, viel Spass beim Basteln.
Gruss
Sven
Ja, auch von meiner Seite noch ein herzliches Dankeschön an Sven für seine Mühe.
Ich habe einen heißen Tag genutzt und das Teil zusammen gelötet.
Jetzt habe ich folgendes Problem:
root@beaglebone:~# ebusd -f --logareas=all --loglevel=debug
2015-07-07 21:44:45.690 [main notice] ebusd 1.2.0 started
2015-07-07 21:44:45.693 [main info] path to ebus configuration files: /etc/ebusd
2015-07-07 21:44:45.695 [main error] error reading templates: ERR: element not found,
2015-07-07 21:44:45.706 [main info] read config files
2015-07-07 21:44:45.707 [main notice] found messages: 8 (0 poll, 6 update)
2015-07-07 21:44:45.718 [bus notice] signal acquired
2015-07-07 21:44:47.000 [bus notice] max. symbols per second: 191
2015-07-07 21:44:54.003 [bus notice] max. symbols per second: 192
2015-07-07 21:44:57.234 [bus debug] ERR: SYN received during skip, switching to ready
2015-07-07 21:44:57.929 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2015-07-07 21:44:57.937 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2015-07-07 21:44:58.000 [bus notice] max. symbols per second: 193
2015-07-07 21:44:59.004 [bus notice] max. symbols per second: 199
2015-07-07 21:45:05.537 [bus debug] ERR: SYN received during skip, switching to ready
2015-07-07 21:45:05.763 [bus debug] ERR: SYN received during receive command, switching to ready
2015-07-07 21:45:06.496 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2015-07-07 21:45:06.502 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2015-07-07 21:45:37.596 [bus debug] ERR: SYN received during skip, switching to ready
2015-07-07 21:45:37.722 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2015-07-07 21:45:37.728 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2015-07-07 21:45:57.066 [bus debug] ERR: SYN received during skip, switching to ready
2015-07-07 21:45:57.103 [bus debug] ERR: invalid escape sequence during receive command, switching to skip
Endlich habe ich hohe Symbolraten, aber der Inhalt kann irgednwie nicht gelesen werden.
Habt ihr noch einen Tipp für mich?
Vielen Dank.
MfG
Thomas
Hallo , auch ich stehe noch vor dem Zusammenbau aber es hapert noch mit der Zeit
Es wäre schön wenn einer ein kleines howto schrieben könnte, einfach mit snapshot alle schritte protkollieren,
der Thread ist so ewig lang...wäre doch schön wenn auch weniger edv Kundige das nachbauen könnten...
Teile auch da, Thanks
Ich komme nicht mehr weiter.
Nach Feinjustierung sind jetzt die Fehler weg, aber ich bekomme keine einzige Meldung/Telegramm angezeigt.:
root@beaglebone:~# ebusd -f --logareas=all --loglevel=debug --lograwdata
2015-07-08 20:30:14.798 [main notice] ebusd 1.2.0 started
2015-07-08 20:30:14.801 [main info] path to ebus configuration files: /etc/ebusd
2015-07-08 20:30:14.803 [main error] error reading templates: ERR: element not found,
2015-07-08 20:30:14.813 [main info] read config files
2015-07-08 20:30:14.815 [main notice] found messages: 8 (0 poll, 6 update)
2015-07-08 20:30:14.827 [bus notice] <00
2015-07-08 20:30:14.829 [bus notice] signal acquired
2015-07-08 20:30:14.842 [bus notice] <00
2015-07-08 20:30:14.864 [bus notice] <00
2015-07-08 20:30:14.872 [bus notice] <00
2015-07-08 20:30:14.883 [bus notice] <00
2015-07-08 20:30:14.903 [bus notice] <00
2015-07-08 20:30:14.923 [bus notice] <00
2015-07-08 20:30:14.943 [bus notice] <00
2015-07-08 20:30:14.963 [bus notice] <00
2015-07-08 20:30:14.973 [bus notice] <f1
2015-07-08 20:30:14.983 [bus notice] <00
2015-07-08 20:30:14.991 [bus notice] <00
2015-07-08 20:30:15.002 [bus notice] <00
2015-07-08 20:30:15.022 [bus notice] <01
2015-07-08 20:30:15.027 [bus notice] <00
2015-07-08 20:30:15.042 [bus notice] <00
2015-07-08 20:30:15.065 [bus notice] <00
2015-07-08 20:30:15.074 [bus notice] <fc
2015-07-08 20:30:15.083 [bus notice] <00
2015-07-08 20:30:15.103 [bus notice] <00
2015-07-08 20:30:15.123 [bus notice] <00
2015-07-08 20:30:15.134 [bus notice] <fe
2015-07-08 20:30:15.142 [bus notice] <00
2015-07-08 20:30:15.163 [bus notice] <00
2015-07-08 20:30:15.185 [bus notice] <00
2015-07-08 20:30:15.191 [bus notice] <00
2015-07-08 20:30:15.203 [bus notice] <00
2015-07-08 20:30:15.223 [bus notice] <00
2015-07-08 20:30:15.228 [bus notice] <00
2015-07-08 20:30:15.243 [bus notice] <00
2015-07-08 20:30:15.265 [bus notice] <00
2015-07-08 20:30:15.275 [bus notice] <ff
2015-07-08 20:30:15.283 [bus notice] <00
2015-07-08 20:30:15.302 [bus notice] <00
2015-07-08 20:30:15.322 [bus notice] <00
2015-07-08 20:30:15.342 [bus notice] <00
2015-07-08 20:30:15.363 [bus notice] <00
2015-07-08 20:30:15.382 [bus notice] <00
2015-07-08 20:30:15.390 [bus notice] <00
2015-07-08 20:30:15.394 [bus notice] <ff
2015-07-08 20:30:15.403 [bus notice] <00
2015-07-08 20:30:15.415 [bus notice] <ff
2015-07-08 20:30:15.423 [bus notice] <00
2015-07-08 20:30:15.427 [bus notice] <00
2015-07-08 20:30:15.443 [bus notice] <00
2015-07-08 20:30:15.454 [bus notice] <ff
2015-07-08 20:30:15.465 [bus notice] <00
2015-07-08 20:30:15.483 [bus notice] <00
2015-07-08 20:30:15.503 [bus notice] <00
2015-07-08 20:30:15.523 [bus notice] <00
2015-07-08 20:30:15.543 [bus notice] <00
2015-07-08 20:30:15.563 [bus notice] <00
2015-07-08 20:30:15.583 [bus notice] <00
2015-07-08 20:30:15.590 [bus notice] <f2
2015-07-08 20:30:15.596 [bus notice] <ff
2015-07-08 20:30:15.604 [bus notice] <03
2015-07-08 20:30:15.609 [bus notice] <01
2015-07-08 20:30:15.615 [bus notice] <fe
2015-07-08 20:30:15.623 [bus notice] <00
2015-07-08 20:30:15.643 [bus notice] <00
2015-07-08 20:30:15.652 [bus notice] <80
2015-07-08 20:30:15.663 [bus notice] <00
2015-07-08 20:30:15.674 [bus notice] <fc
2015-07-08 20:30:15.683 [bus notice] <00
2015-07-08 20:30:15.703 [bus notice] <00
2015-07-08 20:30:15.723 [bus notice] <00
2015-07-08 20:30:15.734 [bus notice] <ff
2015-07-08 20:30:15.743 [bus notice] <00
2015-07-08 20:30:15.762 [bus notice] <00
2015-07-08 20:30:15.774 [bus notice] <fe
2015-07-08 20:30:15.785 [bus notice] <00
2015-07-08 20:30:15.792 [bus notice] <04
2015-07-08 20:30:15.799 [bus notice] <af
2015-07-08 20:30:15.805 [bus notice] <04
2015-07-08 20:30:15.809 [bus notice] <18
2015-07-08 20:30:15.823 [bus notice] <19
2015-07-08 20:30:15.829 [bus notice] <00
2015-07-08 20:30:15.833 [bus notice] <ec
2015-07-08 20:30:15.841 [bus notice] <19
2015-07-08 20:30:15.846 [bus notice] <00
2015-07-08 20:30:15.851 [bus notice] <60
2015-07-08 20:30:15.856 [bus notice] <df
2015-07-08 20:30:15.864 [bus notice] <00
2015-07-08 20:30:15.874 [bus notice] <fc
2015-07-08 20:30:15.883 [bus notice] <00
2015-07-08 20:30:15.902 [bus notice] <00
2015-07-08 20:30:15.923 [bus notice] <00
2015-07-08 20:30:15.942 [bus notice] <00
2015-07-08 20:30:15.954 [bus notice] <fc
2015-07-08 20:30:15.962 [bus notice] <00
2015-07-08 20:30:15.983 [bus notice] <00
2015-07-08 20:30:15.994 [bus notice] <ff
2015-07-08 20:30:16.003 [bus notice] <00
2015-07-08 20:30:16.023 [bus notice] <00
2015-07-08 20:30:16.032 [bus notice] <80
2015-07-08 20:30:16.045 [bus notice] <00
2015-07-08 20:30:16.062 [bus notice] <00
2015-07-08 20:30:16.070 [bus notice] <00
2015-07-08 20:30:16.083 [bus notice] <00
2015-07-08 20:30:16.102 [bus notice] <00
2015-07-08 20:30:16.123 [bus notice] <00
2015-07-08 20:30:16.142 [bus notice] <00
2015-07-08 20:30:16.162 [bus notice] <00
2015-07-08 20:30:16.183 [bus notice] <00
2015-07-08 20:30:16.196 [bus notice] <ff
2015-07-08 20:30:16.203 [bus notice] <00
2015-07-08 20:30:16.223 [bus notice] <00
2015-07-08 20:30:16.232 [bus notice] <c0
2015-07-08 20:30:16.243 [bus notice] <00
2015-07-08 20:30:16.253 [bus notice] <f7
2015-07-08 20:30:16.262 [bus notice] <00
2015-07-08 20:30:16.270 [bus notice] <00
2015-07-08 20:30:16.282 [bus notice] <00
2015-07-08 20:30:16.304 [bus notice] <00
2015-07-08 20:30:16.323 [bus notice] <00
2015-07-08 20:30:16.343 [bus notice] <00
2015-07-08 20:30:16.363 [bus notice] <00
2015-07-08 20:30:16.383 [bus notice] <00
2015-07-08 20:30:16.394 [bus notice] <fd
2015-07-08 20:30:16.403 [bus notice] <00
2015-07-08 20:30:16.423 [bus notice] <00
2015-07-08 20:30:16.432 [bus notice] <e0
2015-07-08 20:30:16.443 [bus notice] <00
2015-07-08 20:30:16.454 [bus notice] <ff
2015-07-08 20:30:16.465 [bus notice] <00
2015-07-08 20:30:16.470 [bus notice] <00
2015-07-08 20:30:16.483 [bus notice] <00
2015-07-08 20:30:16.503 [bus notice] <00
2015-07-08 20:30:16.522 [bus notice] <00
2015-07-08 20:30:16.543 [bus notice] <00
2015-07-08 20:30:16.554 [bus notice] <fe
2015-07-08 20:30:16.563 [bus notice] <00
2015-07-08 20:30:16.583 [bus notice] <00
2015-07-08 20:30:16.602 [bus notice] <00
2015-07-08 20:30:16.614 [bus notice] <fe
2015-07-08 20:30:16.623 [bus notice] <00
2015-07-08 20:30:16.633 [bus notice] <f0
2015-07-08 20:30:16.643 [bus notice] <00
2015-07-08 20:30:16.663 [bus notice] <00
2015-07-08 20:30:16.670 [bus notice] <80
2015-07-08 20:30:16.683 [bus notice] <00
2015-07-08 20:30:16.693 [bus notice] <fc
2015-07-08 20:30:16.702 [bus notice] <00
2015-07-08 20:30:16.725 [bus notice] <00
2015-07-08 20:30:16.743 [bus notice] <00
2015-07-08 20:30:16.763 [bus notice] <00
2015-07-08 20:30:16.783 [bus notice] <00
2015-07-08 20:30:16.802 [bus notice] <00
2015-07-08 20:30:16.823 [bus notice] <00
2015-07-08 20:30:16.833 [bus notice] <fc
2015-07-08 20:30:16.843 [bus notice] <00
2015-07-08 20:30:16.863 [bus notice] <00
2015-07-08 20:30:16.871 [bus notice] <00
2015-07-08 20:30:16.884 [bus notice] <00
2015-07-08 20:30:16.894 [bus notice] <fc
2015-07-08 20:30:16.902 [bus notice] <00
2015-07-08 20:30:16.923 [bus notice] <00
2015-07-08 20:30:16.943 [bus notice] <00
2015-07-08 20:30:16.963 [bus notice] <00
2015-07-08 20:30:16.982 [bus notice] <00
2015-07-08 20:30:16.994 [bus notice] <bc
2015-07-08 20:30:17.003 [bus notice] <00
2015-07-08 20:30:17.023 [bus notice] <00
2015-07-08 20:30:17.034 [bus notice] <fe
2015-07-08 20:30:17.043 [bus notice] <00
2015-07-08 20:30:17.062 [bus notice] <00
2015-07-08 20:30:17.071 [bus notice] <00
2015-07-08 20:30:17.082 [bus notice] <00
2015-07-08 20:30:17.102 [bus notice] <00
2015-07-08 20:30:17.123 [bus notice] <00
2015-07-08 20:30:17.143 [bus notice] <00
2015-07-08 20:30:17.162 [bus notice] <00
2015-07-08 20:30:17.182 [bus notice] <00
2015-07-08 20:30:17.194 [bus notice] <fc
2015-07-08 20:30:17.204 [bus notice] <00
2015-07-08 20:30:17.222 [bus notice] <00
2015-07-08 20:30:17.233 [bus notice] <fc
2015-07-08 20:30:17.243 [bus notice] <00
2015-07-08 20:30:17.262 [bus notice] <00
2015-07-08 20:30:17.271 [bus notice] <00
2015-07-08 20:30:17.282 [bus notice] <00
2015-07-08 20:30:17.293 [bus notice] <fc
2015-07-08 20:30:17.303 [bus notice] <00
2015-07-08 20:30:17.323 [bus notice] <00
2015-07-08 20:30:17.343 [bus notice] <00
2015-07-08 20:30:17.363 [bus notice] <00
2015-07-08 20:30:17.383 [bus notice] <00
2015-07-08 20:30:17.398 [bus notice] <fe
2015-07-08 20:30:17.403 [bus notice] <00
2015-07-08 20:30:17.423 [bus notice] <00
2015-07-08 20:30:17.434 [bus notice] <fe
2015-07-08 20:30:17.442 [bus notice] <00
2015-07-08 20:30:17.465 [bus notice] <00
2015-07-08 20:30:17.471 [bus notice] <80
2015-07-08 20:30:17.483 [bus notice] <00
2015-07-08 20:30:17.503 [bus notice] <00
2015-07-08 20:30:17.522 [bus notice] <00
2015-07-08 20:30:17.542 [bus notice] <00
2015-07-08 20:30:17.563 [bus notice] <00
2015-07-08 20:30:17.573 [bus notice] <fc
2015-07-08 20:30:17.583 [bus notice] <00
2015-07-08 20:30:17.603 [bus notice] <00
2015-07-08 20:30:17.623 [bus notice] <00
2015-07-08 20:30:17.642 [bus notice] <00
2015-07-08 20:30:17.662 [bus notice] <00
2015-07-08 20:30:17.672 [bus notice] <e0
2015-07-08 20:30:17.683 [bus notice] <00
2015-07-08 20:30:17.702 [bus notice] <00
2015-07-08 20:30:17.723 [bus notice] <00
2015-07-08 20:30:17.742 [bus notice] <00
2015-07-08 20:30:17.763 [bus notice] <00
2015-07-08 20:30:17.783 [bus notice] <00
2015-07-08 20:30:17.803 [bus notice] <00
2015-07-08 20:30:17.823 [bus notice] <00
2015-07-08 20:30:17.831 [bus notice] <00
2015-07-08 20:30:17.842 [bus notice] <00
2015-07-08 20:30:17.862 [bus notice] <00
2015-07-08 20:30:17.873 [bus notice] <f8
2015-07-08 20:30:17.883 [bus notice] <00
2015-07-08 20:30:17.902 [bus notice] <00
2015-07-08 20:30:17.922 [bus notice] <00
2015-07-08 20:30:17.943 [bus notice] <00
2015-07-08 20:30:17.962 [bus notice] <00
2015-07-08 20:30:17.983 [bus notice] <00
2015-07-08 20:30:17.994 [bus notice] <ff
2015-07-08 20:30:18.002 [bus notice] <00
2015-07-08 20:30:18.022 [bus notice] <00
2015-07-08 20:30:18.035 [bus notice] <fe
2015-07-08 20:30:18.044 [bus notice] <00
2015-07-08 20:30:18.063 [bus notice] <00
2015-07-08 20:30:18.072 [bus notice] <f0
2015-07-08 20:30:18.082 [bus notice] <00
2015-07-08 20:30:18.103 [bus notice] <00
2015-07-08 20:30:18.122 [bus notice] <00
2015-07-08 20:30:18.143 [bus notice] <00
2015-07-08 20:30:18.162 [bus notice] <00
2015-07-08 20:30:18.182 [bus notice] <00
2015-07-08 20:30:18.203 [bus notice] <00
2015-07-08 20:30:18.223 [bus notice] <00
2015-07-08 20:30:18.236 [bus notice] <ff
2015-07-08 20:30:18.243 [bus notice] <00
2015-07-08 20:30:18.253 [bus notice] <fe
2015-07-08 20:30:18.262 [bus notice] <00
2015-07-08 20:30:18.273 [bus notice] <f8
2015-07-08 20:30:18.282 [bus notice] <00
2015-07-08 20:30:18.304 [bus notice] <00
2015-07-08 20:30:18.314 [bus notice] <ff
2015-07-08 20:30:18.322 [bus notice] <00
2015-07-08 20:30:18.342 [bus notice] <00
2015-07-08 20:30:18.362 [bus notice] <00
2015-07-08 20:30:18.382 [bus notice] <00
2015-07-08 20:30:18.393 [bus notice] <fc
2015-07-08 20:30:18.399 [bus notice] <bf
2015-07-08 20:30:18.403 [bus notice] <00
2015-07-08 20:30:18.413 [bus notice] <fc
2015-07-08 20:30:18.422 [bus notice] <00
2015-07-08 20:30:18.436 [bus notice] <ff
2015-07-08 20:30:18.443 [bus notice] <00
2015-07-08 20:30:18.454 [bus notice] <ff
2015-07-08 20:30:18.464 [bus notice] <00
2015-07-08 20:30:18.474 [bus notice] <ff
2015-07-08 20:30:18.482 [bus notice] <00
2015-07-08 20:30:18.502 [bus notice] <00
2015-07-08 20:30:18.513 [bus notice] <fe
2015-07-08 20:30:18.522 [bus notice] <00
2015-07-08 20:30:18.542 [bus notice] <00
2015-07-08 20:30:18.562 [bus notice] <00
2015-07-08 20:30:18.582 [bus notice] <00
2015-07-08 20:30:18.602 [bus notice] <00
2015-07-08 20:30:18.614 [bus notice] <ff
2015-07-08 20:30:18.622 [bus notice] <00
2015-07-08 20:30:18.637 [bus notice] <ff
2015-07-08 20:30:18.643 [bus notice] <00
2015-07-08 20:30:18.662 [bus notice] <00
2015-07-08 20:30:18.674 [bus notice] <ff
2015-07-08 20:30:18.682 [bus notice] <00
2015-07-08 20:30:18.702 [bus notice] <00
2015-07-08 20:30:18.723 [bus notice] <00
2015-07-08 20:30:18.742 [bus notice] <00
2015-07-08 20:30:18.762 [bus notice] <00
2015-07-08 20:30:18.782 [bus notice] <00
2015-07-08 20:30:18.800 [bus notice] <1f
2015-07-08 20:30:18.805 [bus notice] <00
2015-07-08 20:30:18.810 [bus notice] <60
2015-07-08 20:30:18.814 [bus notice] <fe
2015-07-08 20:30:18.821 [bus notice] <01
2015-07-08 20:30:18.826 [bus notice] <00
2015-07-08 20:30:18.831 [bus notice] <00
2015-07-08 20:30:18.842 [bus notice] <00
2015-07-08 20:30:18.862 [bus notice] <00
2015-07-08 20:30:18.873 [bus notice] <fc
2015-07-08 20:30:18.882 [bus notice] <00
2015-07-08 20:30:18.902 [bus notice] <00
2015-07-08 20:30:18.922 [bus notice] <00
2015-07-08 20:30:18.942 [bus notice] <00
2015-07-08 20:30:18.962 [bus notice] <00
2015-07-08 20:30:18.982 [bus notice] <00
2015-07-08 20:30:19.002 [bus notice] <65
2015-07-08 20:30:19.007 [bus notice] <20
2015-07-08 20:30:19.011 [bus notice] <d1
2015-07-08 20:30:19.023 [bus notice] <08
2015-07-08 20:30:19.028 [bus notice] <40
2015-07-08 20:30:19.033 [bus notice] <ff
2015-07-08 20:30:19.041 [bus notice] <18
2015-07-08 20:30:19.047 [bus notice] <00
2015-07-08 20:30:19.051 [bus notice] <ec
2015-07-08 20:30:19.062 [bus notice] <0c
2015-07-08 20:30:19.067 [bus notice] <08
2015-07-08 20:30:19.073 [bus notice] <fe
2015-07-08 20:30:19.082 [bus notice] <00
2015-07-08 20:30:19.102 [bus notice] <00
2015-07-08 20:30:19.122 [bus notice] <00
2015-07-08 20:30:19.142 [bus notice] <00
2015-07-08 20:30:19.153 [bus notice] <fc
2015-07-08 20:30:19.163 [bus notice] <00
2015-07-08 20:30:19.181 [bus notice] <00
2015-07-08 20:30:19.203 [bus notice] <00
2015-07-08 20:30:19.208 [bus notice] <00
2015-07-08 20:30:19.213 [bus notice] <fe
2015-07-08 20:30:19.221 [bus notice] <18
2015-07-08 20:30:19.226 [bus notice] <08
2015-07-08 20:30:19.232 [bus notice] <f8
2015-07-08 20:30:19.242 [bus notice] <00
2015-07-08 20:30:19.262 [bus notice] <00
2015-07-08 20:30:19.282 [bus notice] <00
2015-07-08 20:30:19.302 [bus notice] <00
2015-07-08 20:30:19.322 [bus notice] <00
2015-07-08 20:30:19.342 [bus notice] <00
2015-07-08 20:30:19.362 [bus notice] <00
2015-07-08 20:30:19.382 [bus notice] <00
2015-07-08 20:30:19.401 [bus notice] <00
2015-07-08 20:30:19.422 [bus notice] <00
2015-07-08 20:30:19.441 [bus notice] <00
2015-07-08 20:30:19.462 [bus notice] <00
2015-07-08 20:30:19.482 [bus notice] <00
2015-07-08 20:30:19.502 [bus notice] <00
2015-07-08 20:30:19.521 [bus notice] <00
2015-07-08 20:30:19.542 [bus notice] <00
2015-07-08 20:30:19.562 [bus notice] <00
2015-07-08 20:30:19.582 [bus notice] <00
2015-07-08 20:30:19.601 [bus notice] <00
2015-07-08 20:30:19.621 [bus notice] <00
2015-07-08 20:30:19.641 [bus notice] <00
2015-07-08 20:30:19.661 [bus notice] <00
2015-07-08 20:30:19.681 [bus notice] <00
2015-07-08 20:30:19.688 [bus notice] <00
2015-07-08 20:30:19.701 [bus notice] <00
2015-07-08 20:30:19.720 [bus notice] <03
2015-07-08 20:30:19.725 [bus notice] <00
2015-07-08 20:30:19.741 [bus notice] <00
2015-07-08 20:30:19.763 [bus notice] <00
2015-07-08 20:30:19.781 [bus notice] <00
2015-07-08 20:30:19.802 [bus notice] <00
2015-07-08 20:30:19.821 [bus notice] <00
2015-07-08 20:30:19.842 [bus notice] <00
2015-07-08 20:30:19.862 [bus notice] <00
2015-07-08 20:30:19.881 [bus notice] <00
2015-07-08 20:30:19.902 [bus notice] <00
2015-07-08 20:30:19.922 [bus notice] <00
2015-07-08 20:30:19.942 [bus notice] <00
2015-07-08 20:30:19.953 [bus notice] <ff
2015-07-08 20:30:19.962 [bus notice] <00
2015-07-08 20:30:19.982 [bus notice] <00
2015-07-08 20:30:19.994 [bus notice] <ff
2015-07-08 20:30:20.001 [bus notice] <00
2015-07-08 20:30:20.022 [bus notice] <00
2015-07-08 20:30:20.041 [bus notice] <00
2015-07-08 20:30:20.062 [bus notice] <00
2015-07-08 20:30:20.082 [bus notice] <00
2015-07-08 20:30:20.102 [bus notice] <00
2015-07-08 20:30:20.121 [bus notice] <00
2015-07-08 20:30:20.141 [bus notice] <00
2015-07-08 20:30:20.161 [bus notice] <00
2015-07-08 20:30:20.181 [bus notice] <00
2015-07-08 20:30:20.202 [bus notice] <00
2015-07-08 20:30:20.221 [bus notice] <00
2015-07-08 20:30:20.232 [bus notice] <e0
2015-07-08 20:30:20.242 [bus notice] <00
2015-07-08 20:30:20.262 [bus notice] <00
2015-07-08 20:30:20.269 [bus notice] <00
2015-07-08 20:30:20.282 [bus notice] <00
2015-07-08 20:30:20.293 [bus notice] <fc
2015-07-08 20:30:20.301 [bus notice] <00
2015-07-08 20:30:20.307 [bus notice] <00
2015-07-08 20:30:20.321 [bus notice] <00
2015-07-08 20:30:20.342 [bus notice] <00
2015-07-08 20:30:20.361 [bus notice] <00
2015-07-08 20:30:20.374 [bus notice] <ff
2015-07-08 20:30:20.381 [bus notice] <00
2015-07-08 20:30:20.401 [bus notice] <00
2015-07-08 20:30:20.422 [bus notice] <00
2015-07-08 20:30:20.442 [bus notice] <00
2015-07-08 20:30:20.461 [bus notice] <00
2015-07-08 20:30:20.481 [bus notice] <00
2015-07-08 20:30:20.501 [bus notice] <00
2015-07-08 20:30:20.522 [bus notice] <00
2015-07-08 20:30:20.542 [bus notice] <00
2015-07-08 20:30:20.561 [bus notice] <00
2015-07-08 20:30:20.581 [bus notice] <00
2015-07-08 20:30:20.601 [bus notice] <00
2015-07-08 20:30:20.621 [bus notice] <00
2015-07-08 20:30:20.641 [bus notice] <00
2015-07-08 20:30:20.661 [bus notice] <00
2015-07-08 20:30:20.682 [bus notice] <00
2015-07-08 20:30:20.701 [bus notice] <00
2015-07-08 20:30:20.721 [bus notice] <00
2015-07-08 20:30:20.741 [bus notice] <00
2015-07-08 20:30:20.754 [bus notice] <ff
2015-07-08 20:30:20.762 [bus notice] <00
2015-07-08 20:30:20.781 [bus notice] <00
2015-07-08 20:30:20.801 [bus notice] <00
2015-07-08 20:30:20.821 [bus notice] <00
2015-07-08 20:30:20.841 [bus notice] <00
2015-07-08 20:30:20.861 [bus notice] <00
2015-07-08 20:30:20.881 [bus notice] <00
2015-07-08 20:30:20.901 [bus notice] <00
2015-07-08 20:30:20.921 [bus notice] <00
2015-07-08 20:30:20.941 [bus notice] <00
2015-07-08 20:30:20.961 [bus notice] <00
2015-07-08 20:30:20.981 [bus notice] <00
2015-07-08 20:30:21.002 [bus notice] <00
2015-07-08 20:30:21.022 [bus notice] <00
2015-07-08 20:30:21.041 [bus notice] <00
2015-07-08 20:30:21.061 [bus notice] <00
2015-07-08 20:30:21.082 [bus notice] <00
2015-07-08 20:30:21.102 [bus notice] <00
2015-07-08 20:30:21.122 [bus notice] <00
2015-07-08 20:30:21.141 [bus notice] <00
2015-07-08 20:30:21.161 [bus notice] <00
2015-07-08 20:30:21.181 [bus notice] <00
2015-07-08 20:30:21.201 [bus notice] <00
2015-07-08 20:30:21.221 [bus notice] <00
2015-07-08 20:30:21.241 [bus notice] <00
2015-07-08 20:30:21.262 [bus notice] <00
2015-07-08 20:30:21.281 [bus notice] <00
2015-07-08 20:30:21.302 [bus notice] <00
2015-07-08 20:30:21.321 [bus notice] <00
2015-07-08 20:30:21.325 [bus notice] <00
2015-07-08 20:30:21.330 [bus notice] <60
2015-07-08 20:30:21.341 [bus notice] <00
2015-07-08 20:30:21.361 [bus notice] <00
2015-07-08 20:30:21.382 [bus notice] <00
2015-07-08 20:30:21.402 [bus notice] <00
2015-07-08 20:30:21.422 [bus notice] <00
2015-07-08 20:30:21.442 [bus notice] <00
2015-07-08 20:30:21.461 [bus notice] <00
2015-07-08 20:30:21.482 [bus notice] <00
2015-07-08 20:30:21.501 [bus notice] <00
2015-07-08 20:30:21.522 [bus notice] <00
2015-07-08 20:30:21.541 [bus notice] <00
2015-07-08 20:30:21.562 [bus notice] <00
2015-07-08 20:30:21.582 [bus notice] <00
2015-07-08 20:30:21.601 [bus notice] <00
2015-07-08 20:30:21.621 [bus notice] <00
2015-07-08 20:30:21.641 [bus notice] <00
2015-07-08 20:30:21.661 [bus notice] <00
2015-07-08 20:30:21.681 [bus notice] <00
2015-07-08 20:30:21.701 [bus notice] <00
2015-07-08 20:30:21.721 [bus notice] <00
2015-07-08 20:30:21.742 [bus notice] <00
2015-07-08 20:30:21.761 [bus notice] <00
2015-07-08 20:30:21.781 [bus notice] <00
2015-07-08 20:30:21.801 [bus notice] <00
2015-07-08 20:30:21.821 [bus notice] <00
2015-07-08 20:30:21.833 [bus notice] <ff
2015-07-08 20:30:21.841 [bus notice] <00
2015-07-08 20:30:21.861 [bus notice] <00
2015-07-08 20:30:21.882 [bus notice] <00
2015-07-08 20:30:21.901 [bus notice] <00
2015-07-08 20:30:21.922 [bus notice] <00
2015-07-08 20:30:21.941 [bus notice] <00
2015-07-08 20:30:21.961 [bus notice] <00
2015-07-08 20:30:21.981 [bus notice] <00
2015-07-08 20:30:21.992 [bus notice] <fc
2015-07-08 20:30:22.001 [bus notice] <00
2015-07-08 20:30:22.022 [bus notice] <00
2015-07-08 20:30:22.042 [bus notice] <00
2015-07-08 20:30:22.061 [bus notice] <00
2015-07-08 20:30:22.083 [bus notice] <00
2015-07-08 20:30:22.090 [bus notice] <f0
2015-07-08 20:30:22.102 [bus notice] <00
2015-07-08 20:30:22.108 [bus notice] <20
2015-07-08 20:30:22.113 [bus notice] <ff
2015-07-08 20:30:22.121 [bus notice] <18
2015-07-08 20:30:22.126 [bus notice] <00
2015-07-08 20:30:22.130 [bus notice] <e8
2015-07-08 20:30:22.139 [bus notice] <0f
2015-07-08 20:30:22.144 [bus notice] <00
2015-07-08 20:30:22.149 [bus notice] <b0
2015-07-08 20:30:22.162 [bus notice] <10
2015-07-08 20:30:22.167 [bus notice] <00
2015-07-08 20:30:22.174 [bus notice] <ff
2015-07-08 20:30:22.182 [bus notice] <00
2015-07-08 20:30:22.192 [bus notice] <fe
2015-07-08 20:30:22.201 [bus notice] <00
2015-07-08 20:30:22.221 [bus notice] <00
2015-07-08 20:30:22.242 [bus notice] <00
2015-07-08 20:30:22.251 [bus notice] <ff
2015-07-08 20:30:22.261 [bus notice] <00
2015-07-08 20:30:22.281 [bus notice] <00
2015-07-08 20:30:22.303 [bus notice] <18
2015-07-08 20:30:22.308 [bus notice] <00
2015-07-08 20:30:22.313 [bus notice] <ff
2015-07-08 20:30:22.321 [bus notice] <18
2015-07-08 20:30:22.326 [bus notice] <00
2015-07-08 20:30:22.331 [bus notice] <c8
2015-07-08 20:30:22.341 [bus notice] <00
2015-07-08 20:30:22.361 [bus notice] <00
2015-07-08 20:30:22.381 [bus notice] <00
2015-07-08 20:30:22.401 [bus notice] <00
2015-07-08 20:30:22.423 [bus notice] <00
2015-07-08 20:30:22.432 [bus notice] <fc
2015-07-08 20:30:22.441 [bus notice] <00
2015-07-08 20:30:22.461 [bus notice] <00
2015-07-08 20:30:22.481 [bus notice] <00
2015-07-08 20:30:22.501 [bus notice] <00
2015-07-08 20:30:22.509 [bus notice] <40
2015-07-08 20:30:22.514 [bus notice] <ff
2015-07-08 20:30:22.523 [bus notice] <00
2015-07-08 20:30:22.528 [bus notice] <00
2015-07-08 20:30:22.533 [bus notice] <ef
2015-07-08 20:30:22.543 [bus notice] <09
2015-07-08 20:30:22.548 [bus notice] <21
2015-07-08 20:30:22.561 [bus notice] <20
2015-07-08 20:30:22.565 [bus notice] <00
2015-07-08 20:30:22.570 [bus notice] <f6
2015-07-08 20:30:22.579 [bus notice] <17
2015-07-08 20:30:22.584 [bus notice] <00
2015-07-08 20:30:22.601 [bus notice] <00
2015-07-08 20:30:22.612 [bus notice] <fe
2015-07-08 20:30:22.621 [bus notice] <00
2015-07-08 20:30:22.630 [bus notice] <90
2015-07-08 20:30:22.641 [bus notice] <00
2015-07-08 20:30:22.661 [bus notice] <00
2015-07-08 20:30:22.683 [bus notice] <00
2015-07-08 20:30:22.701 [bus notice] <00
2015-07-08 20:30:22.712 [bus notice] <fe
2015-07-08 20:30:22.718 [bus notice] <bf
2015-07-08 20:30:22.723 [bus notice] <00
2015-07-08 20:30:22.728 [bus notice] <50
2015-07-08 20:30:22.733 [bus notice] <fe
2015-07-08 20:30:22.743 [bus notice] <00
2015-07-08 20:30:22.752 [bus notice] <fc
2015-07-08 20:30:22.761 [bus notice] <00
2015-07-08 20:30:22.781 [bus notice] <00
2015-07-08 20:30:22.792 [bus notice] <fc
2015-07-08 20:30:22.801 [bus notice] <00
2015-07-08 20:30:22.821 [bus notice] <00
2015-07-08 20:30:22.841 [bus notice] <00
2015-07-08 20:30:22.853 [bus notice] <ff
2015-07-08 20:30:22.863 [bus notice] <00
2015-07-08 20:30:22.881 [bus notice] <00
2015-07-08 20:30:22.901 [bus notice] <00
2015-07-08 20:30:22.914 [bus notice] <ff
2015-07-08 20:30:22.919 [bus notice] <2f
2015-07-08 20:30:22.924 [bus notice] <00
2015-07-08 20:30:22.929 [bus notice] <c2
2015-07-08 20:30:22.933 [bus notice] <7d
2015-07-08 20:30:22.940 [bus notice] <1d
2015-07-08 20:30:22.945 [bus notice] <20
2015-07-08 20:30:22.950 [bus notice] <dc
2015-07-08 20:30:22.960 [bus notice] <75
2015-07-08 20:30:22.965 [bus notice] <20
2015-07-08 20:30:22.971 [bus notice] <f6
2015-07-08 20:30:22.982 [bus notice] <84
2015-07-08 20:30:22.988 [bus notice] <00
2015-07-08 20:30:23.003 [bus notice] <00
2015-07-08 20:30:23.010 [bus notice] <80
2015-07-08 20:30:23.021 [bus notice] <00
2015-07-08 20:30:23.041 [bus notice] <00
2015-07-08 20:30:23.050 [bus notice] <e0
2015-07-08 20:30:23.062 [bus notice] <00
2015-07-08 20:30:23.081 [bus notice] <00
2015-07-08 20:30:23.101 [bus notice] <00
2015-07-08 20:30:23.116 [bus notice] <ff
2015-07-08 20:30:23.122 [bus notice] <00
2015-07-08 20:30:23.127 [bus notice] <40
2015-07-08 20:30:23.132 [bus notice] <ff
2015-07-08 20:30:23.140 [bus notice] <55
2015-07-08 20:30:23.147 [bus notice] <00
2015-07-08 20:30:23.152 [bus notice] <ff
2015-07-08 20:30:23.161 [bus notice] <00
2015-07-08 20:30:23.181 [bus notice] <00
2015-07-08 20:30:23.201 [bus notice] <00
2015-07-08 20:30:23.213 [bus notice] <ff
2015-07-08 20:30:23.221 [bus notice] <00
2015-07-08 20:30:23.232 [bus notice] <fc
2015-07-08 20:30:23.241 [bus notice] <00
2015-07-08 20:30:23.260 [bus notice] <00
2015-07-08 20:30:23.281 [bus notice] <00
2015-07-08 20:30:23.292 [bus notice] <fe
2015-07-08 20:30:23.300 [bus notice] <00
2015-07-08 20:30:23.318 [bus notice] <7f
2015-07-08 20:30:23.324 [bus notice] <00
2015-07-08 20:30:23.328 [bus notice] <60
2015-07-08 20:30:23.332 [bus notice] <fe
2015-07-08 20:30:23.342 [bus notice] <01
2015-07-08 20:30:23.347 [bus notice] <40
2015-07-08 20:30:23.352 [bus notice] <ef
2015-07-08 20:30:23.362 [bus notice] <00
2015-07-08 20:30:23.367 [bus notice] <30
2015-07-08 20:30:23.371 [bus notice] <fb
2015-07-08 20:30:23.383 [bus notice] <03
2015-07-08 20:30:23.388 [bus notice] <08
2015-07-08 20:30:23.401 [bus notice] <00
2015-07-08 20:30:23.421 [bus notice] <00
2015-07-08 20:30:23.441 [bus notice] <00
2015-07-08 20:30:23.460 [bus notice] <00
2015-07-08 20:30:23.481 [bus notice] <00
2015-07-08 20:30:23.491 [bus notice] <f3
2015-07-08 20:30:23.501 [bus notice] <00
2015-07-08 20:30:23.521 [bus notice] <00
2015-07-08 20:30:23.541 [bus notice] <00
2015-07-08 20:30:23.561 [bus notice] <00
2015-07-08 20:30:23.580 [bus notice] <00
2015-07-08 20:30:23.595 [bus notice] <ff
2015-07-08 20:30:23.603 [bus notice] <00
2015-07-08 20:30:23.621 [bus notice] <00
2015-07-08 20:30:23.632 [bus notice] <fe
2015-07-08 20:30:23.641 [bus notice] <00
2015-07-08 20:30:23.661 [bus notice] <00
2015-07-08 20:30:23.681 [bus notice] <00
2015-07-08 20:30:23.693 [bus notice] <ff
2015-07-08 20:30:23.701 [bus notice] <00
2015-07-08 20:30:23.721 [bus notice] <00
2015-07-08 20:30:23.740 [bus notice] <00
2015-07-08 20:30:23.752 [bus notice] <fe
2015-07-08 20:30:23.758 [bus notice] <ff
2015-07-08 20:30:23.763 [bus notice] <00
2015-07-08 20:30:23.781 [bus notice] <00
2015-07-08 20:30:23.791 [bus notice] <7c
2015-07-08 20:30:23.796 [bus notice] <ff
2015-07-08 20:30:23.801 [bus notice] <00
2015-07-08 20:30:23.821 [bus notice] <00
2015-07-08 20:30:23.840 [bus notice] <00
2015-07-08 20:30:23.861 [bus notice] <00
2015-07-08 20:30:23.881 [bus notice] <00
2015-07-08 20:30:23.901 [bus notice] <00
2015-07-08 20:30:23.910 [bus notice] <f0
2015-07-08 20:30:23.921 [bus notice] <00
2015-07-08 20:30:23.940 [bus notice] <00
2015-07-08 20:30:23.961 [bus notice] <00
2015-07-08 20:30:23.972 [bus notice] <ff
2015-07-08 20:30:23.981 [bus notice] <00
2015-07-08 20:30:24.000 [bus notice] <00
2015-07-08 20:30:24.023 [bus notice] <00
2015-07-08 20:30:24.032 [bus notice] <ff
2015-07-08 20:30:24.040 [bus notice] <00
2015-07-08 20:30:24.061 [bus notice] <00
2015-07-08 20:30:24.081 [bus notice] <00
2015-07-08 20:30:24.100 [bus notice] <00
2015-07-08 20:30:24.122 [bus notice] <00
2015-07-08 20:30:24.132 [bus notice] <fe
2015-07-08 20:30:24.140 [bus notice] <00
2015-07-08 20:30:24.151 [bus notice] <fc
2015-07-08 20:30:24.161 [bus notice] <00
2015-07-08 20:30:24.181 [bus notice] <00
2015-07-08 20:30:24.200 [bus notice] <00
2015-07-08 20:30:24.221 [bus notice] <00
2015-07-08 20:30:24.231 [bus notice] <f8
2015-07-08 20:30:24.241 [bus notice] <00
2015-07-08 20:30:24.261 [bus notice] <00
2015-07-08 20:30:24.281 [bus notice] <00
2015-07-08 20:30:24.301 [bus notice] <00
2015-07-08 20:30:24.322 [bus notice] <00
2015-07-08 20:30:24.331 [bus notice] <fc
2015-07-08 20:30:24.341 [bus notice] <00
2015-07-08 20:30:24.360 [bus notice] <00
2015-07-08 20:30:24.381 [bus notice] <00
2015-07-08 20:30:24.392 [bus notice] <fe
2015-07-08 20:30:24.396 [bus notice] <fe
2015-07-08 20:30:24.400 [bus notice] <00
2015-07-08 20:30:24.420 [bus notice] <00
2015-07-08 20:30:24.431 [bus notice] <fc
2015-07-08 20:30:24.443 [bus notice] <00
2015-07-08 20:30:24.460 [bus notice] <00
2015-07-08 20:30:24.481 [bus notice] <00
2015-07-08 20:30:24.500 [bus notice] <00
2015-07-08 20:30:24.522 [bus notice] <00
2015-07-08 20:30:24.531 [bus notice] <f8
2015-07-08 20:30:24.541 [bus notice] <00
2015-07-08 20:30:24.561 [bus notice] <00
2015-07-08 20:30:24.580 [bus notice] <00
2015-07-08 20:30:24.592 [bus notice] <fe
2015-07-08 20:30:24.602 [bus notice] <00
2015-07-08 20:30:24.620 [bus notice] <00
2015-07-08 20:30:24.641 [bus notice] <00
2015-07-08 20:30:24.661 [bus notice] <00
2015-07-08 20:30:24.672 [bus notice] <ff
2015-07-08 20:30:24.680 [bus notice] <00
2015-07-08 20:30:24.701 [bus notice] <00
2015-07-08 20:30:24.723 [bus notice] <00
2015-07-08 20:30:24.741 [bus notice] <00
2015-07-08 20:30:24.761 [bus notice] <00
2015-07-08 20:30:24.781 [bus notice] <00
2015-07-08 20:30:24.791 [bus notice] <fc
2015-07-08 20:30:24.801 [bus notice] <00
2015-07-08 20:30:24.811 [bus notice] <ff
2015-07-08 20:30:24.821 [bus notice] <00
2015-07-08 20:30:24.840 [bus notice] <00
2015-07-08 20:30:24.863 [bus notice] <00
2015-07-08 20:30:24.871 [bus notice] <fc
2015-07-08 20:30:24.881 [bus notice] <00
2015-07-08 20:30:24.901 [bus notice] <00
2015-07-08 20:30:24.923 [bus notice] <00
2015-07-08 20:30:24.940 [bus notice] <00
2015-07-08 20:30:24.961 [bus notice] <00
2015-07-08 20:30:24.980 [bus notice] <00
2015-07-08 20:30:25.001 [bus notice] <00
2015-07-08 20:30:25.021 [bus notice] <00
2015-07-08 20:30:25.041 [bus notice] <00
2015-07-08 20:30:25.052 [bus notice] <ff
2015-07-08 20:30:25.062 [bus notice] <00
2015-07-08 20:30:25.072 [bus notice] <ff
2015-07-08 20:30:25.080 [bus notice] <00
2015-07-08 20:30:25.101 [bus notice] <00
2015-07-08 20:30:25.111 [bus notice] <fc
2015-07-08 20:30:25.125 [bus notice] <00
2015-07-08 20:30:25.129 [bus notice] <80
2015-07-08 20:30:25.140 [bus notice] <00
2015-07-08 20:30:25.161 [bus notice] <00
2015-07-08 20:30:25.171 [bus notice] <fe
2015-07-08 20:30:25.181 [bus notice] <00
2015-07-08 20:30:25.200 [bus notice] <00
2015-07-08 20:30:25.221 [bus notice] <00
2015-07-08 20:30:25.230 [bus notice] <f2
2015-07-08 20:30:25.240 [bus notice] <00
2015-07-08 20:30:25.260 [bus notice] <00
2015-07-08 20:30:25.271 [bus notice] <fc
2015-07-08 20:30:25.282 [bus notice] <00
2015-07-08 20:30:25.300 [bus notice] <00
2015-07-08 20:30:25.320 [bus notice] <00
2015-07-08 20:30:25.325 [bus notice] <00
2015-07-08 20:30:25.331 [bus notice] <fc
2015-07-08 20:30:25.342 [bus notice] <00
2015-07-08 20:30:25.361 [bus notice] <00
2015-07-08 20:30:25.380 [bus notice] <00
2015-07-08 20:30:25.391 [bus notice] <fe
2015-07-08 20:30:25.400 [bus notice] <00
2015-07-08 20:30:25.420 [bus notice] <00
2015-07-08 20:30:25.440 [bus notice] <00
2015-07-08 20:30:25.461 [bus notice] <00
2015-07-08 20:30:25.472 [bus notice] <ff
2015-07-08 20:30:25.480 [bus notice] <00
2015-07-08 20:30:25.491 [bus notice] <fc
2015-07-08 20:30:25.501 [bus notice] <00
2015-07-08 20:30:25.512 [bus notice] <ff
2015-07-08 20:30:25.520 [bus notice] <00
2015-07-08 20:30:25.525 [bus notice] <00
2015-07-08 20:30:25.531 [bus notice] <fe
2015-07-08 20:30:25.541 [bus notice] <00
2015-07-08 20:30:25.562 [bus notice] <00
2015-07-08 20:30:25.580 [bus notice] <00
2015-07-08 20:30:25.592 [bus notice] <ff
2015-07-08 20:30:25.600 [bus notice] <00
2015-07-08 20:30:25.620 [bus notice] <00
2015-07-08 20:30:25.641 [bus notice] <00
2015-07-08 20:30:25.660 [bus notice] <00
2015-07-08 20:30:25.680 [bus notice] <00
2015-07-08 20:30:25.692 [bus notice] <ff
2015-07-08 20:30:25.702 [bus notice] <00
2015-07-08 20:30:25.709 [bus notice] <80
2015-07-08 20:30:25.719 [bus notice] <00
2015-07-08 20:30:25.725 [bus notice] <00
2015-07-08 20:30:25.731 [bus notice] <fe
2015-07-08 20:30:25.740 [bus notice] <00
2015-07-08 20:30:25.751 [bus notice] <fc
2015-07-08 20:30:25.762 [bus notice] <00
2015-07-08 20:30:25.780 [bus notice] <00
2015-07-08 20:30:25.800 [bus notice] <00
2015-07-08 20:30:25.820 [bus notice] <00
2015-07-08 20:30:25.840 [bus notice] <00
2015-07-08 20:30:25.851 [bus notice] <fc
2015-07-08 20:30:25.860 [bus notice] <00
2015-07-08 20:30:25.880 [bus notice] <00
2015-07-08 20:30:25.900 [bus notice] <00
2015-07-08 20:30:25.921 [bus notice] <00
2015-07-08 20:30:25.926 [bus notice] <00
2015-07-08 20:30:25.932 [bus notice] <ff
2015-07-08 20:30:25.940 [bus notice] <00
2015-07-08 20:30:25.962 [bus notice] <00
2015-07-08 20:30:25.980 [bus notice] <00
2015-07-08 20:30:26.000 [bus notice] <00
2015-07-08 20:30:26.020 [bus notice] <00
2015-07-08 20:30:26.040 [bus notice] <00
2015-07-08 20:30:26.060 [bus notice] <00
2015-07-08 20:30:26.080 [bus notice] <00
2015-07-08 20:30:26.092 [bus notice] <ff
2015-07-08 20:30:26.100 [bus notice] <00
2015-07-08 20:30:26.111 [bus notice] <fc
2015-07-08 20:30:26.120 [bus notice] <00
2015-07-08 20:30:26.126 [bus notice] <00
2015-07-08 20:30:26.140 [bus notice] <00
2015-07-08 20:30:26.163 [bus notice] <00
2015-07-08 20:30:26.171 [bus notice] <fe
2015-07-08 20:30:26.180 [bus notice] <00
2015-07-08 20:30:26.200 [bus notice] <00
2015-07-08 20:30:26.220 [bus notice] <00
2015-07-08 20:30:26.240 [bus notice] <00
2015-07-08 20:30:26.260 [bus notice] <00
2015-07-08 20:30:26.281 [bus notice] <00
2015-07-08 20:30:26.289 [bus notice] <88
2015-07-08 20:30:26.300 [bus notice] <00
2015-07-08 20:30:26.320 [bus notice] <00
2015-07-08 20:30:26.327 [bus notice] <00
2015-07-08 20:30:26.342 [bus notice] <00
2015-07-08 20:30:26.363 [bus notice] <00
2015-07-08 20:30:26.368 [bus notice] <00
2015-07-08 20:30:26.380 [bus notice] <00
2015-07-08 20:30:26.401 [bus notice] <00
2015-07-08 20:30:26.411 [bus notice] <fc
2015-07-08 20:30:26.420 [bus notice] <00
2015-07-08 20:30:26.441 [bus notice] <00
2015-07-08 20:30:26.460 [bus notice] <00
2015-07-08 20:30:26.480 [bus notice] <00
2015-07-08 20:30:26.500 [bus notice] <00
2015-07-08 20:30:26.511 [bus notice] <ff
2015-07-08 20:30:26.520 [bus notice] <00
2015-07-08 20:30:26.527 [bus notice] <00
2015-07-08 20:30:26.540 [bus notice] <00
2015-07-08 20:30:26.559 [bus notice] <00
2015-07-08 20:30:26.563 [bus notice] <00
2015-07-08 20:30:26.580 [bus notice] <00
2015-07-08 20:30:26.589 [bus notice] <c0
2015-07-08 20:30:26.601 [bus notice] <00
2015-07-08 20:30:26.611 [bus notice] <fe
2015-07-08 20:30:26.620 [bus notice] <00
2015-07-08 20:30:26.639 [bus notice] <00
2015-07-08 20:30:26.651 [bus notice] <fc
2015-07-08 20:30:26.660 [bus notice] <00
2015-07-08 20:30:26.669 [bus notice] <c0
2015-07-08 20:30:26.680 [bus notice] <00
2015-07-08 20:30:26.691 [bus notice] <fc
2015-07-08 20:30:26.700 [bus notice] <00
2015-07-08 20:30:26.712 [bus notice] <ff
2015-07-08 20:30:26.720 [bus notice] <00
2015-07-08 20:30:26.728 [bus notice] <00
2015-07-08 20:30:26.739 [bus notice] <00
2015-07-08 20:30:26.759 [bus notice] <00
2015-07-08 20:30:26.764 [bus notice] <00
2015-07-08 20:30:26.780 [bus notice] <00
2015-07-08 20:30:26.793 [bus notice] <ff
2015-07-08 20:30:26.801 [bus notice] <00
2015-07-08 20:30:26.820 [bus notice] <00
2015-07-08 20:30:26.839 [bus notice] <00
2015-07-08 20:30:26.860 [bus notice] <00
2015-07-08 20:30:26.880 [bus notice] <00
2015-07-08 20:30:26.900 [bus notice] <00
2015-07-08 20:30:26.920 [bus notice] <00
2015-07-08 20:30:26.928 [bus notice] <00
2015-07-08 20:30:26.939 [bus notice] <00
2015-07-08 20:30:26.960 [bus notice] <00
2015-07-08 20:30:26.964 [bus notice] <00
2015-07-08 20:30:26.971 [bus notice] <fe
2015-07-08 20:30:26.980 [bus notice] <00
2015-07-08 20:30:27.002 [bus notice] <00
2015-07-08 20:30:27.020 [bus notice] <00
2015-07-08 20:30:27.039 [bus notice] <00
2015-07-08 20:30:27.060 [bus notice] <00
2015-07-08 20:30:27.071 [bus notice] <fe
2015-07-08 20:30:27.080 [bus notice] <00
2015-07-08 20:30:27.100 [bus notice] <00
2015-07-08 20:30:27.120 [bus notice] <00
2015-07-08 20:30:27.127 [bus notice] <c0
2015-07-08 20:30:27.140 [bus notice] <00
2015-07-08 20:30:27.159 [bus notice] <00
2015-07-08 20:30:27.164 [bus notice] <00
2015-07-08 20:30:27.180 [bus notice] <00
2015-07-08 20:30:27.191 [bus notice] <ff
2015-07-08 20:30:27.202 [bus notice] <00
2015-07-08 20:30:27.219 [bus notice] <00
2015-07-08 20:30:27.240 [bus notice] <00
2015-07-08 20:30:27.260 [bus notice] <00
2015-07-08 20:30:27.280 [bus notice] <00
2015-07-08 20:30:27.300 [bus notice] <00
2015-07-08 20:30:27.319 [bus notice] <00
2015-07-08 20:30:27.328 [bus notice] <00
2015-07-08 20:30:27.340 [bus notice] <00
2015-07-08 20:30:27.359 [bus notice] <00
2015-07-08 20:30:27.365 [bus notice] <00
2015-07-08 20:30:27.371 [bus notice] <f8
2015-07-08 20:30:27.380 [bus notice] <00
2015-07-08 20:30:27.402 [bus notice] <00
2015-07-08 20:30:27.419 [bus notice] <00
2015-07-08 20:30:27.440 [bus notice] <00
2015-07-08 20:30:27.460 [bus notice] <00
2015-07-08 20:30:27.479 [bus notice] <00
2015-07-08 20:30:27.500 [bus notice] <00
2015-07-08 20:30:27.520 [bus notice] <00
2015-07-08 20:30:27.528 [bus notice] <80
2015-07-08 20:30:27.540 [bus notice] <00
2015-07-08 20:30:27.560 [bus notice] <00
2015-07-08 20:30:27.565 [bus notice] <00
2015-07-08 20:30:27.571 [bus notice] <ff
2015-07-08 20:30:27.580 [bus notice] <00
2015-07-08 20:30:27.603 [bus notice] <00
2015-07-08 20:30:27.620 [bus notice] <00
2015-07-08 20:30:27.639 [bus notice] <00
2015-07-08 20:30:27.651 [bus notice] <fe
2015-07-08 20:30:27.662 [bus notice] <00
2015-07-08 20:30:27.679 [bus notice] <00
2015-07-08 20:30:27.700 [bus notice] <00
2015-07-08 20:30:27.720 [bus notice] <00
2015-07-08 20:30:27.729 [bus notice] <e0
2015-07-08 20:30:27.740 [bus notice] <00
2015-07-08 20:30:27.761 [bus notice] <00
2015-07-08 20:30:27.766 [bus notice] <00
2015-07-08 20:30:27.780 [bus notice] <00
2015-07-08 20:30:27.799 [bus notice] <80
2015-07-08 20:30:27.803 [bus notice] <00
2015-07-08 20:30:27.810 [bus notice] <fc
2015-07-08 20:30:27.820 [bus notice] <00
2015-07-08 20:30:27.839 [bus notice] <00
2015-07-08 20:30:27.859 [bus notice] <00
2015-07-08 20:30:27.871 [bus notice] <fe
2015-07-08 20:30:27.880 [bus notice] <00
2015-07-08 20:30:27.899 [bus notice] <00
2015-07-08 20:30:27.911 [bus notice] <fe
2015-07-08 20:30:27.920 [bus notice] <00
2015-07-08 20:30:27.930 [bus notice] <f0
2015-07-08 20:30:27.939 [bus notice] <00
2015-07-08 20:30:27.951 [bus notice] <fc
2015-07-08 20:30:27.960 [bus notice] <00
2015-07-08 20:30:27.966 [bus notice] <00
2015-07-08 20:30:27.971 [bus notice] <fe
2015-07-08 20:30:27.982 [bus notice] <00
2015-07-08 20:30:27.999 [bus notice] <00
2015-07-08 20:30:28.003 [bus notice] <00
2015-07-08 20:30:28.020 [bus notice] <00
2015-07-08 20:30:28.040 [bus notice] <00
2015-07-08 20:30:28.059 [bus notice] <00
2015-07-08 20:30:28.080 [bus notice] <00
2015-07-08 20:30:28.099 [bus notice] <00
2015-07-08 20:30:28.120 [bus notice] <00
2015-07-08 20:30:28.130 [bus notice] <f0
2015-07-08 20:30:28.142 [bus notice] <00
2015-07-08 20:30:28.159 [bus notice] <00
2015-07-08 20:30:28.166 [bus notice] <00
2015-07-08 20:30:28.180 [bus notice] <00
2015-07-08 20:30:28.199 [bus notice] <00
2015-07-08 20:30:28.204 [bus notice] <00
2015-07-08 20:30:28.219 [bus notice] <00
2015-07-08 20:30:28.239 [bus notice] <00
2015-07-08 20:30:28.259 [bus notice] <00
2015-07-08 20:30:28.280 [bus notice] <00
2015-07-08 20:30:28.299 [bus notice] <00
2015-07-08 20:30:28.319 [bus notice] <00
2015-07-08 20:30:28.330 [bus notice] <f0
2015-07-08 20:30:28.340 [bus notice] <00
2015-07-08 20:30:28.350 [bus notice] <f9
2015-07-08 20:30:28.359 [bus notice] <00
2015-07-08 20:30:28.367 [bus notice] <00
2015-07-08 20:30:28.379 [bus notice] <00
2015-07-08 20:30:28.399 [bus notice] <00
2015-07-08 20:30:28.404 [bus notice] <00
2015-07-08 20:30:28.419 [bus notice] <00
2015-07-08 20:30:28.440 [bus notice] <00
2015-07-08 20:30:28.460 [bus notice] <00
2015-07-08 20:30:28.480 [bus notice] <00
2015-07-08 20:30:28.500 [bus notice] <00
2015-07-08 20:30:28.520 [bus notice] <00
2015-07-08 20:30:28.530 [bus notice] <f8
2015-07-08 20:30:28.539 [bus notice] <00
2015-07-08 20:30:28.560 [bus notice] <00
2015-07-08 20:30:28.567 [bus notice] <00
2015-07-08 20:30:28.579 [bus notice] <00
2015-07-08 20:30:28.599 [bus notice] <00
2015-07-08 20:30:28.604 [bus notice] <00
2015-07-08 20:30:28.619 [bus notice] <00
2015-07-08 20:30:28.640 [bus notice] <00
2015-07-08 20:30:28.659 [bus notice] <00
2015-07-08 20:30:28.679 [bus notice] <00
2015-07-08 20:30:28.700 [bus notice] <00
2015-07-08 20:30:28.720 [bus notice] <00
2015-07-08 20:30:28.731 [bus notice] <fe
2015-07-08 20:30:28.740 [bus notice] <00
2015-07-08 20:30:28.759 [bus notice] <00
2015-07-08 20:30:28.767 [bus notice] <00
2015-07-08 20:30:28.779 [bus notice] <00
2015-07-08 20:30:28.799 [bus notice] <00
2015-07-08 20:30:28.805 [bus notice] <00
2015-07-08 20:30:28.811 [bus notice] <fc
2015-07-08 20:30:28.820 [bus notice] <00
2015-07-08 20:30:28.830 [bus notice] <fc
2015-07-08 20:30:28.840 [bus notice] <00
2015-07-08 20:30:28.859 [bus notice] <00
2015-07-08 20:30:28.882 [bus notice] <00
2015-07-08 20:30:28.899 [bus notice] <00
2015-07-08 20:30:28.920 [bus notice] <00
2015-07-08 20:30:28.931 [bus notice] <fe
2015-07-08 20:30:28.940 [bus notice] <00
2015-07-08 20:30:28.959 [bus notice] <00
2015-07-08 20:30:28.968 [bus notice] <00
2015-07-08 20:30:28.981 [bus notice] <00
2015-07-08 20:30:28.999 [bus notice] <00
2015-07-08 20:30:29.005 [bus notice] <00
2015-07-08 20:30:29.020 [bus notice] <00
2015-07-08 20:30:29.040 [bus notice] <00
2015-07-08 20:30:29.059 [bus notice] <00
2015-07-08 20:30:29.079 [bus notice] <00
2015-07-08 20:30:29.090 [bus notice] <fc
2015-07-08 20:30:29.100 [bus notice] <00
2015-07-08 20:30:29.120 [bus notice] <00
2015-07-08 20:30:29.131 [bus notice] <fe
2015-07-08 20:30:29.136 [bus notice] <bf
2015-07-08 20:30:29.142 [bus notice] <10
2015-07-08 20:30:29.147 [bus notice] <20
2015-07-08 20:30:29.152 [bus notice] <ef
2015-07-08 20:30:29.157 [bus notice] <1f
2015-07-08 20:30:29.162 [bus notice] <00
2015-07-08 20:30:29.180 [bus notice] <00
2015-07-08 20:30:29.200 [bus notice] <00
2015-07-08 20:30:29.220 [bus notice] <00
2015-07-08 20:30:29.239 [bus notice] <00
2015-07-08 20:30:29.259 [bus notice] <00
2015-07-08 20:30:29.271 [bus notice] <fc
2015-07-08 20:30:29.280 [bus notice] <00
2015-07-08 20:30:29.300 [bus notice] <00
2015-07-08 20:30:29.321 [bus notice] <00
2015-07-08 20:30:29.333 [bus notice] <ff
2015-07-08 20:30:29.339 [bus notice] <13
2015-07-08 20:30:29.344 [bus notice] <00
2015-07-08 20:30:29.349 [bus notice] <e1
2015-07-08 20:30:29.360 [bus notice] <87
2015-07-08 20:30:29.365 [bus notice] <00
2015-07-08 20:30:29.370 [bus notice] <fe
2015-07-08 20:30:29.381 [bus notice] <0c
2015-07-08 20:30:29.386 [bus notice] <00
2015-07-08 20:30:29.392 [bus notice] <ff
2015-07-08 20:30:29.397 [bus notice] <1f
2015-07-08 20:30:29.404 [bus notice] <00
2015-07-08 20:30:29.410 [bus notice] <f8
2015-07-08 20:30:29.422 [bus notice] <00
2015-07-08 20:30:29.439 [bus notice] <00
2015-07-08 20:30:29.460 [bus notice] <00
2015-07-08 20:30:29.480 [bus notice] <00
2015-07-08 20:30:29.499 [bus notice] <00
2015-07-08 20:30:29.520 [bus notice] <00
2015-07-08 20:30:29.534 [bus notice] <7f
2015-07-08 20:30:29.540 [bus notice] <00
2015-07-08 20:30:29.560 [bus notice] <00
2015-07-08 20:30:29.571 [bus notice] <ff
2015-07-08 20:30:29.580 [bus notice] <00
2015-07-08 20:30:29.599 [bus notice] <00
2015-07-08 20:30:29.609 [bus notice] <e0
2015-07-08 20:30:29.619 [bus notice] <00
2015-07-08 20:30:29.630 [bus notice] <fe
2015-07-08 20:30:29.639 [bus notice] <00
2015-07-08 20:30:29.660 [bus notice] <00
2015-07-08 20:30:29.681 [bus notice] <00
2015-07-08 20:30:29.700 [bus notice] <00
2015-07-08 20:30:29.720 [bus notice] <00
2015-07-08 20:30:29.735 [bus notice] <ff
2015-07-08 20:30:29.740 [bus notice] <00
2015-07-08 20:30:29.760 [bus notice] <00
2015-07-08 20:30:29.772 [bus notice] <ff
2015-07-08 20:30:29.780 [bus notice] <00
2015-07-08 20:30:29.790 [bus notice] <fd
2015-07-08 20:30:29.799 [bus notice] <00
2015-07-08 20:30:29.810 [bus notice] <f0
2015-07-08 20:30:29.820 [bus notice] <00
2015-07-08 20:30:29.841 [bus notice] <00
2015-07-08 20:30:29.859 [bus notice] <00
2015-07-08 20:30:29.880 [bus notice] <00
2015-07-08 20:30:29.900 [bus notice] <00
2015-07-08 20:30:29.920 [bus notice] <00
2015-07-08 20:30:29.931 [bus notice] <fe
2015-07-08 20:30:29.940 [bus notice] <00
2015-07-08 20:30:29.950 [bus notice] <fc
2015-07-08 20:30:29.960 [bus notice] <00
2015-07-08 20:30:29.980 [bus notice] <00
2015-07-08 20:30:30.001 [bus notice] <00
2015-07-08 20:30:30.010 [bus notice] <f8
2015-07-08 20:30:30.020 [bus notice] <00
2015-07-08 20:30:30.040 [bus notice] <00
2015-07-08 20:30:30.060 [bus notice] <00
2015-07-08 20:30:30.070 [bus notice] <fc
2015-07-08 20:30:30.080 [bus notice] <00
2015-07-08 20:30:30.099 [bus notice] <00
2015-07-08 20:30:30.119 [bus notice] <00
2015-07-08 20:30:30.140 [bus notice] <00
2015-07-08 20:30:30.151 [bus notice] <fe
2015-07-08 20:30:30.160 [bus notice] <00
2015-07-08 20:30:30.179 [bus notice] <00
2015-07-08 20:30:30.200 [bus notice] <00
2015-07-08 20:30:30.219 [bus notice] <00
2015-07-08 20:30:30.239 [bus notice] <00
2015-07-08 20:30:30.259 [bus notice] <00
2015-07-08 20:30:30.270 [bus notice] <fc
2015-07-08 20:30:30.279 [bus notice] <00
2015-07-08 20:30:30.300 [bus notice] <00
2015-07-08 20:30:30.320 [bus notice] <00
2015-07-08 20:30:30.331 [bus notice] <ff
2015-07-08 20:30:30.339 [bus notice] <00
2015-07-08 20:30:30.350 [bus notice] <fc
2015-07-08 20:30:30.360 [bus notice] <00
2015-07-08 20:30:30.368 [bus notice] <00
2015-07-08 20:30:30.373 [bus notice] <ff
2015-07-08 20:30:30.379 [bus notice] <00
2015-07-08 20:30:30.400 [bus notice] <00
2015-07-08 20:30:30.411 [bus notice] <fe
2015-07-08 20:30:30.420 [bus notice] <00
2015-07-08 20:30:30.440 [bus notice] <00
2015-07-08 20:30:30.460 [bus notice] <00
2015-07-08 20:30:30.470 [bus notice] <fc
2015-07-08 20:30:30.479 [bus notice] <00
2015-07-08 20:30:30.499 [bus notice] <00
2015-07-08 20:30:30.510 [bus notice] <fc
2015-07-08 20:30:30.519 [bus notice] <00
2015-07-08 20:30:30.539 [bus notice] <00
2015-07-08 20:30:30.559 [bus notice] <00
2015-07-08 20:30:30.571 [bus notice] <fc
2015-07-08 20:30:30.581 [bus notice] <00
2015-07-08 20:30:30.591 [bus notice] <ff
2015-07-08 20:30:30.599 [bus notice] <00
2015-07-08 20:30:30.611 [bus notice] <ff
2015-07-08 20:30:30.620 [bus notice] <00
2015-07-08 20:30:30.640 [bus notice] <00
2015-07-08 20:30:30.660 [bus notice] <00
2015-07-08 20:30:30.680 [bus notice] <00
2015-07-08 20:30:30.699 [bus notice] <00
2015-07-08 20:30:30.720 [bus notice] <00
2015-07-08 20:30:30.736 [bus notice] <3e
2015-07-08 20:30:30.742 [bus notice] <00
2015-07-08 20:30:30.760 [bus notice] <00
2015-07-08 20:30:30.773 [bus notice] <fe
2015-07-08 20:30:30.780 [bus notice] <00
2015-07-08 20:30:30.799 [bus notice] <00
2015-07-08 20:30:30.811 [bus notice] <fe
2015-07-08 20:30:30.819 [bus notice] <00
2015-07-08 20:30:30.840 [bus notice] <00
2015-07-08 20:30:30.860 [bus notice] <00
2015-07-08 20:30:30.879 [bus notice] <00
2015-07-08 20:30:30.890 [bus notice] <fe
2015-07-08 20:30:30.900 [bus notice] <00
2015-07-08 20:30:30.919 [bus notice] <00
2015-07-08 20:30:30.939 [bus notice] <00
2015-07-08 20:30:30.960 [bus notice] <00
2015-07-08 20:30:30.974 [bus notice] <fe
2015-07-08 20:30:30.980 [bus notice] <00
2015-07-08 20:30:31.000 [bus notice] <00
2015-07-08 20:30:31.011 [bus notice] <fe
2015-07-08 20:30:31.019 [bus notice] <00
2015-07-08 20:30:31.040 [bus notice] <00
2015-07-08 20:30:31.050 [bus notice] <fc
2015-07-08 20:30:31.060 [bus notice] <00
2015-07-08 20:30:31.079 [bus notice] <00
2015-07-08 20:30:31.099 [bus notice] <00
2015-07-08 20:30:31.119 [bus notice] <00
2015-07-08 20:30:31.139 [bus notice] <00
2015-07-08 20:30:31.151 [bus notice] <fe
2015-07-08 20:30:31.161 [bus notice] <00
2015-07-08 20:30:31.179 [bus notice] <00
2015-07-08 20:30:31.200 [bus notice] <00
2015-07-08 20:30:31.211 [bus notice] <fe
2015-07-08 20:30:31.219 [bus notice] <00
2015-07-08 20:30:31.240 [bus notice] <00
2015-07-08 20:30:31.260 [bus notice] <00
2015-07-08 20:30:31.279 [bus notice] <00
2015-07-08 20:30:31.299 [bus notice] <00
2015-07-08 20:30:31.310 [bus notice] <fc
2015-07-08 20:30:31.320 [bus notice] <00
2015-07-08 20:30:31.340 [bus notice] <00
2015-07-08 20:30:31.359 [bus notice] <00
2015-07-08 20:30:31.380 [bus notice] <00
2015-07-08 20:30:31.399 [bus notice] <00
2015-07-08 20:30:31.420 [bus notice] <00
2015-07-08 20:30:31.439 [bus notice] <00
2015-07-08 20:30:31.460 [bus notice] <00
2015-07-08 20:30:31.471 [bus notice] <fe
2015-07-08 20:30:31.480 [bus notice] <00
2015-07-08 20:30:31.500 [bus notice] <00
2015-07-08 20:30:31.521 [bus notice] <00
2015-07-08 20:30:31.530 [bus notice] <fc
2015-07-08 20:30:31.539 [bus notice] <00
2015-07-08 20:30:31.559 [bus notice] <00
2015-07-08 20:30:31.575 [bus notice] <ff
2015-07-08 20:30:31.581 [bus notice] <00
2015-07-08 20:30:31.600 [bus notice] <00
2015-07-08 20:30:31.613 [bus notice] <ff
2015-07-08 20:30:31.620 [bus notice] <00
2015-07-08 20:30:31.640 [bus notice] <00
2015-07-08 20:30:31.659 [bus notice] <00
2015-07-08 20:30:31.680 [bus notice] <00
2015-07-08 20:30:31.688 [bus notice] <00
2015-07-08 20:30:31.699 [bus notice] <00
2015-07-08 20:30:31.719 [bus notice] <00
Mann sieht bei den RAW-Daten auch keine "AA", so wie es beschrieben wird.
Was ist da los? Mein Brenner ist von Weishaupt WTC25.
Der Bus besteht zwischen Brenner und Fern-Bedieneinheit.
"scan full" und "grab" bringen auch gar kein Ergebnis.
LG
Thomas
Kannst Du nicht wenn der Scan läuft justieren bis die "aa"s kommen?
Ich meine bei mir kamen die "00"er auch an irgendeiner Poti-Einstellung,
wenn ich dann aber weitergedreht habe, kamen irgendwann die "aa"s.
Ich möchte nochmal auf den Einflussfaktor der Stromversorgung hinweisen:
3 der in diversen Foren empfohlenen Netzteile für den Raspi führen bei meiner Konfiguration (Raspi B+ mit ebus Adapter, sonst nix dran)
nach wenigen Sekunden bis zu einigen Minuten zu "signal lost".
Das waren im Detail ein Samsung U90EWE Netzteil, ein iPad Air Netzteil und ein
Rydges High-Quality PC Netzteil mit 2A.
Ein Anker 40W 5fach Netzteil hat zuerst funktioniert, dann kam nach Minuten wieder "signal lost".
Letztendlich hab ich nun einen aktiven 7fach USB Hub von Dlink als Stromversorgung dran,
zusätzlich ein USB Kabel mit 2 Entstördrosseln zwischen Hub und Raspi, damit scheint es nun zu laufen.
Könntest Du auch nochmal vergleichen ob Du mit einem anderen Netzteil andere Ergebnisse bekommst.
Gruß
Sven
Ich habe an den Ebus Adapter, zum testen, mal an ein USB-Modul geklemmt.
Read Befehle werden mit "signal lost" quitiert - ein paar Broadcast Informationen kommen durch.
Ich habe an meinen cubietruck ein USB Hub inkl. Netzteil, das bisher zuverlässig seine Dienste, auch mit HM-USB, verrichtet.
@Sven:
Funktioniert (auch "read" Befehle) dein Adapter so wie der an uns geliefert wurde?
Welche Ebusd Version verwendest Du?
Wie ist dein Ebus Adapter angebunden - USB FTDi Adapter - korrekt?
Bei mir muss ich den Poti "voll" aufdrehen damit ein Signal kommt - wie ist die Einstellung bei dir?
Stromversorgung habe ich auch in verdacht, aber noch nicht verifiziert (die Zeit fehlt :o( ) - getestet habe ich die Versorgung über USB FTDI Adapter und Versorgung über ein externes Netzteil - alles ohne Erfolg.
Hast Du an deinen USB Adapter etwas an den Baud Werten geändert?
Weiterer Ansatz wäre ein paar Werte zu messen.
Gruß
Arthur
Bei mir kommen entweder nur 'FF', oder nur "00", je nach Einstellung des Potis.
Aber keine"AA"s!
Der Stellbereich ist nur ganz minimal und bei ca. 3/4 vom Vollausschlag.
Könnte man nicht durch Verändern des Spannungsteilers mit einem kleineren Poti den Stellbereich vergrößern?
Ich habe jetzt mit zwei unterschiedlichen Schaltungen jeweils nach Schaltplan von Pah getestet.
Einmal mit der Platine von Sven und einmal auf dem Steckbrett.
Dann habe ich mit zwei unterschiedlichen Computern und USB Schnittstellen experimentiert, einmal mit einem Beaglebone und dann noch mit einem Laptop. Zwei unterschiedliche Stecker Netzteile am Beaglebone, 2A und 2,5A getestet.
Das machte alles keinen Unterschied!
Ich habe dabei immer die letzte EBUSD Version compiliert.
Jetzt versuche ich nochmal mit einem kleinen Labornetzteil.....
Ist denn der ebus von Weishaupt vielleicht etwas Besonderes, oder liegt es an meinem FTDI USB Interface?
Das habe ich leider nur einmal und kann es daher nicht ausschließen.
LG
Thomas
Hallo Arthur,
ich hab am Anfang ewig an dem Poti rumgestellt, der Bereich in dem Werte kamen ist kurz vor Vollausschlag.
"Signal lost" hab ich immer mal wieder bekommen, mal schneller, mal weniger schnell.
Dann kam der Hinweis, es könnte ein Bauteil nicht korrekt verlötet sein, da hab ich zunächst von oben nochmal verlötet,
da ich 3 Sockel verwendet hatte, kam ich nicht mehr an die Punkte da drunter dran, also Sockel ausgelötet und Bauteile so rein.
Hat aber nix gebracht.
Ich hatte zwischenzeitlich aussentemperaturbedingt nicht so viel Zeit / Lust mich drum zu kümmern,
außerdem hab ich verschiedene Netzteile zusammengesucht und ausprobiert.
Da ich mit meinem Anker Netzteil eine deutliche Verbesserung der signal losts bekommen habe (ohne zwischendurch am Poti zu fummeln ;-),
hab ich nach einer möglichst stabilen Stromversorgung gesucht und bin in irgendeinem Forum auf den USB Hub und das Kabel mit Entstördrossel gekommen.
Die aktuelle Poti - Einstellung ist auf dem anhängenden Foto zu sehen. Ca. 2 Teilstriche unter oberem Endanschlag.
Mein USB Hub ist erst gestern gekommen, mit dem gibt es nun endlich und seit 24h kein "signal lost" mehr.
Aktuell scanne ich den Bus, scheint zu funktionieren.
Meine Konfiguration ist im Prinzip wie im Wiki, Raspi B+, USB FTDi-Adapter, Ebus-Adapter, dann noch DLink USB Hub und USB Kabel mit Entstördrossel (keine Ahnung ob die nötig sind, auf jeden fall scheint es damit zu gehen). Die Baud-Rate hab ich nicht geändert
Ebusd 1.2.0
Gruß
Sven
Zitat von: Papaloewe am 08 Juli 2015, 22:26:43
Bei mir kommen entweder nur 'FF', oder nur "00", je nach Einstellung des Potis.
Aber keine"AA"s!
Der Stellbereich ist nur ganz minimal und bei ca. 3/4.
Ok, bei mir sieht es wie folgt aus:
2015-07-08 22:52:41.188 [bus notice] <17
2015-07-08 22:52:41.192 [bus notice] <00
2015-07-08 22:52:41.192 [bus notice] new master 10
2015-07-08 22:52:41.193 [update info] update MS cmd: 1008b5110101 / 093638f00f3e4c0002ff
2015-07-08 22:52:41.193 [bus notice] new master 03
2015-07-08 22:52:41.193 [update notice] unknown MS cmd: 1008b5110101 / 093638f00f3e4c0002ff
2015-07-08 22:52:41.196 [bus notice] <aa
2015-07-08 22:52:41.196 [bus debug] ERR: SYN received during skip, switching to ready
2015-07-08 22:52:41.242 [bus notice] <aa
2015-07-08 22:52:41.287 [bus notice] <aa
2015-07-08 22:52:41.332 [bus notice] <aa
2015-07-08 22:52:41.378 [bus notice] <aa
2015-07-08 22:52:41.423 [bus notice] <aa
2015-07-08 22:52:41.468 [bus notice] <aa
2015-07-08 22:52:41.512 [bus notice] <aa
2015-07-08 22:52:41.560 [bus notice] <aa
2015-07-08 22:52:41.605 [bus notice] <aa
2015-07-08 22:52:41.649 [bus notice] <aa
2015-07-08 22:52:41.696 [bus notice] <aa
2015-07-08 22:52:41.741 [bus notice] <aa
2015-07-08 22:52:41.785 [bus notice] <aa
2015-07-08 22:52:41.830 [bus notice] <aa
^C2015-07-08 22:52:41.874 [bus notice] <aa
2015-07-08 22:52:41.874 [main notice] SIGINT received
2015-07-08 22:52:41.918 [bus notice] <aa
2015-07-08 22:52:41.962 [bus notice] <aa
2015-07-08 22:52:41.980 [main notice] ebusd stopped
Ich habe Vaillant im Einsatz - daher keine Erfahrung mit Weishaupt - sorry.
@Sven: Danke für die Informationen und das Bild.
Was fehlt ist - hast Du aktiv Werte abgefragt (z.B Aussentemp oder Innentemp etc.)?
Ja, signal lost scheint nicht tragisch zu sein - das Thema hatten wir in in ein paar Threads zuvor.
Ebusd Version scheint dann eher 1.2.0 zu sein.
Ich nehme an, dass du an den Baud Werten (USB Adapter) nichts geändert hast - korrekt?
Brauche da auch ein wenig mehr Zeit mir das genau anzuschauen... :o(
Viele Grüße
Arthur
@Arthur: das sieht doch ganz gut aus...
Ich hänge noch am Scan:
wenn ich den ebusd starte bekomme ich
pi@ebuspi ~ $ ebusd -f -l All -d /dev/ttyUSB0 -p 8888
2015-07-08 22:58:04.237 [main notice] ebusd 1.2.0 started
2015-07-08 22:58:04.239 [main error] error reading templates: ERR: element not f
ound,
2015-07-08 22:58:04.243 [main notice] found messages: 4 (0 poll, 0 update)
2015-07-08 22:58:04.262 [bus notice] signal acquired
2015-07-08 22:58:05.476 [bus notice] new master 10
2015-07-08 22:58:05.477 [bus notice] new master 03
2015-07-08 22:58:05.478 [update notice] unknown MS cmd: 1008b51009000046ffffff04
0000 / 0101
2015-07-08 22:58:11.560 [update notice] unknown MS cmd: 1008b5110101 / 093d3e301
13f5f0000ff
2015-07-08 22:58:13.548 [update notice] unknown MS cmd: 1008b5110100 / 08ec01120
000000001
2015-07-08 22:58:13.766 [update notice] unknown BC cmd: 10feb51603013011
2015-07-08 22:58:15.547 [update notice] unknown MS cmd: 1008b51009000046ffffff04
0000 / 0101
Soweit ok denke ich.
Wenn ich nun zusätzlich den Scan starte, bekomme ich aber
2015-07-08 22:59:56.013 [bus error] ERR: arbitration lost, retry
2015-07-08 22:59:56.106 [update notice] unknown MS cmd: 1008b51009000046ffffff04
0000 / 0101
2015-07-08 22:59:59.990 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:00.076 [update notice] unknown MS cmd: 1008b5110101 / 093d3e001
13f5f0000ff
2015-07-08 23:00:01.980 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:02.075 [update notice] unknown MS cmd: 1008b5040100 / 0a0304002
3080703150011
2015-07-08 23:00:02.257 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:02.332 [update notice] unknown MS cmd: 1008b5110102 / 06033c964
6826e
2015-07-08 23:00:02.515 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:02.572 [update notice] unknown MS cmd: 1008b512020000 / 00
2015-07-08 23:00:06.027 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:06.119 [update notice] unknown MS cmd: 1008b51009000046ffffff04
0000 / 0101
2015-07-08 23:00:10.047 [bus error] ERR: arbitration lost, retry
2015-07-08 23:00:10.134 [update notice] unknown MS cmd: 1008b5110101 / 093d3e001
13f5f0000ff
2015-07-08 23:00:12.080 [bus error] ERR: arbitration lost, retry
Ich dachte zuerst die arbitration losts sind ok, nach 20 Minuten oder so scannt er dann verschiedene IDs durch und dann kommt nach jedem Scanversuch ERR: arbitration lost, retry.
Verstehe ich das richtig: lesen geht aber schreiben nicht?
Gruß
Sven
Hallo Sven, HalloThomas,
etwas an euren Ebusd-Konfigs passt noch nicht.
Habt ihr die entsprechenden(passenden) CSV-Files im /etc/ebusd Verzeichnis?
ZitatVerstehe ich das richtig: lesen geht aber schreiben nicht?
Nein, ein
ebusctl r DisplayedRoomTempergibt:
ERR: no signal
oder
ERR: arbitration lost
Viele Grüße
Arthur
Ok, danke, ich hatte bisher nur die scan.csv und _template.csv im /etc/ebus-Ordner.
Ich hab die 470.csv noch dazukopiert (hab eine Vaillant 470 Calormatic 470 an meiner Anlage)
und bekomme
pi@ebuspi ~ $ ebusctl r DisplayedRoomTemp
ERR: arbitration lost
und beim 2. Mal
pi@ebuspi ~ $ ebusctl r DisplayedRoomTemp
ERR: invalid position
zu 1). ist das gleiche Verhalten wie bei mir! !CHECK!
zu 2). ebusctl r -f DisplayedRoomTemp kann die Abfrage forciert werden. Ergebnis sollte das gleiche sein "ERR: arbitration lost"
Gut - "nicht gut" - scheinbar hat die Hardware ein sende Problem.
Viele Grüße
Arthur
Also der Schaltplan ist ok denke ich, hab ihn mehrmals gecheckt. Ich hänge die Daten aber nochmal an.
Weitere potentielle Fehlerquellen:
- ich habe statt BD645 (gabs nicht bei Reichelt) den BD203 verwendet, der hatte sehr ähnliche Daten.
- es gibt vom CNY17 verschiedene Verstärkungen, ich hab den CNY17-I verwendet, Verstärkung 40-80%.
Gruß
Sven
Ebusd Version würde ich fast ausschließen, da ich mit einem eBUS Koppler von eservice einwandfrei Daten abfragen kann.
Bei Elektro spezifischen Themen steige ich aus -> Vielleicht kann Reinhart unterstützen - wie wir vorgehen sollen, um das Problem einzugrenzen?
Viele Grüße
Arthur
Ja ein bisschen Hilfe wäre gut. Ich bin da auch nicht "vom Fach".
Die Platinen haben auf jeden Fall 100% e-Test beim Hersteller durchlaufen und ich hab eine der Platinen mal mit nem Durchgangsprüfer überprüft und nichts gefunden.
Gesendet von iPhone mit Tapatalk
::) ::)
Leute, natürlich ist der Schaltplan "ok" - erstens veröffentliche ich nichts, was ich nicht selbst vorher getestet habe, und zweitens läuft das System bei mir seit Veröffentlichung des Schaltplans einwandfrei.
Lesen: Wenn der Regelbereich des Trimmpotis zu klein ist, bitte mal den Wert überprüfen - sind das 20 kOhm ?
Schreiben: Hier scheint bei den beschafften Bauteilen etwas im Argen zu sein. Der BD645 ist ein Darlington-Transistor (=2 Transistoren in einem, sozusagen). Heißt: Er hat wirklich eine hohe Verstärkung. Moderne Vergleichstypen sind BD697 und BD897. Ich nehme an, dass der BD203 ein viel zu geringe Verstärkung hat, um mit dem relativ schwachbrüstigen Signal aus dem Optokoppler den kräftigen EBUS auf niedriges Potenzial zu ziehen.
Netzteil: Spielt überhaupt keine Rolle, weil es nur den Raspberry und den USB-Konverter bedient, nicht die EBUS-Seite. Ganz im Gegenteil habe ich aus der vom EBUS gewonnenen Spannung von 5V auch noch (in einer Erweiterung meiner Heizungsankopplung um einen Durchflusssensor) andere Bauteile versorgt.
LG
pah
@pah: es ging doch nicht um Deinen Schaltplan, dass der läuft ist klar, es ging mir um meine eagle-Datei.
Wollte nur überprüfen ob ich nicht doch irgendwo eine Verbindung vergessen habe oder einen Punkt zu setzen.
Oder ob bei der Platinen-Fertigung was schief gegangen ist.
Danke für den Hinweis mit dem BD203, das ist dann mein Fehler gewesen, hatte bei Reichelt nach nem Vergleichsbauteil gesucht.
Ich schau heute abend mal bei unserer lokalen Elektronik Apotheke rein ob die einen haben und probier das aus.
Das verwendete Poti ist ein "75H 20K :: Cermet-Miniatur-Regler, liegend, 6mm 20 K-Ohm", sollte passen.
Lesen geht ja auch (inzwischen) gut.
Ich versteh dann bloß nicht ganz warum bei mir das verwendete Netzteil so einen Unterschied macht, bei manchen Netzteilen bekomme ich innerhalb von Sekunden
"signal lost", wenn ich diesen Hub nehme, nicht (natürlich ohne am Poti zu drehen).
Gruß
Sven
Zitat von: zentis666 am 09 Juli 2015, 08:42:02
Ich schau heute abend mal bei unserer lokalen Elektronik Apotheke rein ob die einen haben und probier das aus.
Für die ohne lokale Elektro-Apotheke:
http://www.ebay.de/itm/BD645-Transistor-npn-60V-8-0A-60W-TO220-/311068350232
kommt da 2,50 inkl. Versand. Liegt damit verm. in der Größenordnung der lokalen Apotheke (meine Erfahrungen sind da etwas betagt).
Gruß Dirk
Netzteil: Es kann natürlich sein, dass die Ausgangsspannungen (und eventuelle Störungen auf der 5V-Leitung) bei den Netzteilen so stark differieren, dass sie die Schaltschwelle bei dem einfachen Komparator aus 4011-Gattern merklich beeinflussen. Man sollte also tatsächlich überprüfen, welche Spannung hier anliegt - und ggf. noch einen Kondensator spendieren, der Störungen etwas abmildert.
Statt eines alten BD645 (da sieht man mal, wie alt ich bin - der flog seit ca 20 Jahren bei mir in der Bastelkiste herum ...) für 2,50 € kann man auch so etwas verwenden - für 29 Cent. Ist aber nicht getestet damit.
http://www.conrad.de/ce/de/product/151057/Darlington-Leistungstransistor-STMicroelectronics-TIP121-NPN-Gehaeuseart-TO-220-IC-5-A-Emitter-Sperrspannung-UCEO-80?ref=searchDetail
LG
pah
Zitat von: Prof. Dr. Peter Henning am 09 Juli 2015, 11:32:10Statt eines alten BD645 (da sieht man mal, wie alt ich bin - der flog seit ca 20 Jahren bei mir in der Bastelkiste herum ...) für 2,50 € kann man auch so etwas verwenden - für 29 Cent. Ist aber nicht getestet damit.
Das das technisch geht - da vertraue ich Deinem Urteil.
Allerdings haben hier ja nicht alle ne Versandkosten-Flatrate beim Elektronikversender, so dass die 2,50 (inkl. Versand) bei Ebay für einige immer noch günstiger als 0,29 + 5,95 Versand = 6,24 sind. Klar, der ein oder andere hat eh was zu bestellen, aber bei Conrad hilft es ja auch nicht, wenn man ein günstiges Buch dazubestellt...
Wo ich grad von Flatrate schreib: 0,90 bei ELV für nen BD645: http://www.elv.de/transistor-bd645.html
Aber wie immer im Leben: Für jeden gibt es das passendste ;o) Das exakt passende ist meist nicht verfügbar.
Zitat von: amunra am 08 Juli 2015, 23:58:10
Ebusd Version würde ich fast ausschließen, da ich mit einem eBUS Koppler von eservice einwandfrei Daten abfragen kann.
Bei Elektro spezifischen Themen steige ich aus -> Vielleicht kann Reinhart unterstützen - wie wir vorgehen sollen, um das Problem einzugrenzen?
Viele Grüße
Arthur
Natürlich kann ich euch helfen!
Die Schaltung von pah und ebenfalls der ebusd 1.2.0 ist zu 100% in Ordnung, sonst würde es ja bei keinem funktionieren. Ebenso weiß ich, dass es auch schwierig sein kann die Schaltung zu verstehen wenn man wirklich keine Ahnung von der Elektronik hat. Aber mit etwas Logik sollte es fast jeder hinbekommen.
Bevor ihr hier im Finsteren herumtappt, würde ich euch wirklich die Methode empfehlen, anstatt des Ebus ein regelbares Netzteil anzuschließen, ich habe ja beide Schaltungen so in Betrieb genommen. siehe hier: http://forum.fhem.de/index.php/topic,29737.msg281006.html#msg281006 (http://forum.fhem.de/index.php/topic,29737.msg281006.html#msg281006)
Die Led am zur Diagnose würde ich dabei sehr empfehlen, könnt ihr ja fliegend nur zur Einstellung darüber hängen. Ob die Platine noch einen Fehler hat oder die Bauteile ein zu hohe Streuung aufweisen, spielt keine Rolle, mit der Messmethode und dem regelbaren Netzteil sollte der Fehler auf jeden Fall gefunden werden. Das regelbare Netzteil hat nur den Sinn, die logische 1 von >12 Volt oder die 0 durch <12 V am Bus zu simulieren und so ein statischen Zustand zum Messen zu schaffen. Habt ihr dabei das Poti einmal eingestellt, braucht es auch nicht wieder geändert werden.
Und geht bitte schrittweise vor, zunächst muss der Empfangsweg ok sein, dann erst schaut aufs Senden. Betreffend dem Sendeweg, schaut auf die Tipps die euch pah betreffend des Sendetransistors hier noch gegeben hat, auch ich habe einen (Darlington) Vergleichstransistor eingesetzt.
Wenn einer von euch sich zutraut den Fehler auf der Schaltung zu suchen, dann könnt ihr ja das Wissen für die anderen weiter geben.
Wenn wirklich gar nichts geht, dann könnte ich euch anbieten, das mir einer seine "defekte" Schaltung zuschickt und ich den Fehler suche. Würde halt etwas dauern, da ich aus Österreich bin. Aber versucht es vorher einmal selbst.
LG
Reinhart
Nachtrag:
als Sendetransistor habe ich in beiden Schaltungen den BDX53B von Conrad eingebaut (weil Conrad nichts anderes lagernd hatte) und funktioniert perfekt!
Achtet aber unbedingt bei der Zehnerdiode, dass die wirklich 1,3 Watt hat!
LG
Reinhart
Hallo Reinhard, danke für die ausführliche Anleitung. Die "Sammelbestellungsdiode" hat 1,3W.
Da bei Arthur und mir der Empfang funktioniert scheint der Empfangsweg prinzipiell ok zu sein.
Alle, die keinen Empfang haben (ich hab bisher nur Papaloewe gesehen?) probiert mal bitte meine Poti Einstellung (s. Foto von gestern) und falls das nichts bringt Reinhards Anleitung. Wer noch nicht gelötet hat und gerade anfangen will, sollte den BD203 nicht verbauen!
Ich werde heute Abend mal den Transistor tauschen und dann berichten.
Gruß
Sven
Gesendet von iPhone mit Tapatalk
Hallo Sven,
ich habe heute auch die Teile bekommen. Vielen Dank nochmal für Deine Bemühungen!
Mit dem Zusammenbau warte ich dann mal noch ein wenig ;)
schöne Grüße
Jo
Hallo Reinhard,
vielen Dank für deine Unterstützung.
Ich bin der mit dem Empfangsproblem, da sind die anderen schon weiter ;-(.
Ich konnte die Schaltschwelle von 12V bei meiner Schaltung auf dem Steckbrett nach dem von dir beschriebenen Verfahren nachvollziehen. Das scheint also soweit ok.
Da habe ich mal einfach mit dem Multimeter die Spannung am ebus nachgemessen (DC) und siehe da es sind nur ca. 6V! Ist das denn so richtig? (Fabrikat: Weishaupt)
Gruß
Thomas
Bei mir wird es heute nichts mit testen, hab keinen passenden Transistor bekommen :-\
Hab das Ding von ebay bestellt,
Gruß
Sven
6V am Ebus sind definitiv zu wenig,
Minimum sind 8V, 8-12V = LOW, 15 - 24V = HIGH
Möglicherweise ein defektes Kabel mit hohem Innenwiderstand ?
LG
pah
Erfolgsmeldung!
Kaum nimmt man den richtigen Transistor, schon gehts ::)
Jetzt kommt nach
pi@ebuspi ebusd -f -l All -d /dev/ttyUSB0 -p 8888
und
pi@ebuspi ~ $ sudo ebusctl scan full
pi@ebuspi ~ $ sudo ebusctl scan result
08;Vaillant;BAI00;0113;9602;21150400;100155963;100005190;N9
15;Vaillant;47000;0420;1403;21144700;201712800;082060262;N1
26;Vaillant;47000;0420;1403;21144700;201712800;082060262;N1
und pi@ebuspi ~ $ ebusctl r DisplayedRoomTemp
-1616.00
Aber nach ca. 15 min kam gerade wieder signal lost trotz Brimborium mit USB Hub usw. :-(
Jetzt kann ich mich also dem Thema widmen...
@pah / Reinhart: würdet Ihr nochmal unterstützen? Wie geht man am Besten vor?
pah hat geschrieben Spannung am 4011 Gatter messen,
ich hab nur ein Multimeter da, reicht das oder brauchts ein Oszilloskop um irgendwelche Spannungsschwankungen auszumessen?
Gruß
Sven
Zitat von: Papaloewe am 09 Juli 2015, 19:20:26
Hallo Reinhard,
vielen Dank für deine Unterstützung.
Ich bin der mit dem Empfangsproblem, da sind die anderen schon weiter ;-(.
Ich konnte die Schaltschwelle von 12V bei meiner Schaltung auf dem Steckbrett nach dem von dir beschriebenen Verfahren nachvollziehen. Das scheint also soweit ok.
Da habe ich mal einfach mit dem Multimeter die Spannung am ebus nachgemessen (DC) und siehe da es sind nur ca. 6V! Ist das denn so richtig? (Fabrikat: Weishaupt)
Beachte bitte die Bilder von zentis666, das der Spannungsregler anders als beim Aufdruck der Platine eingesetzt werden muss, sonst stimmt die Polung nicht und die In/Out sind verkehrt rum!
Gruß
Thomas
wie dir pah schon geschrieben hat, kann das mit 6 V nicht funktionieren weil das weit außerhalb der eBus Spezifikation liegt. Bei meiner Vaillant messe ich am ebus (mit angeschlossener Schnittstelle) 20,5 Volt und die wird im Takt (etwa alle 2-3 Sekunden) herunter gezogen.
Ist das jetzt die Spannung die du mit angeschlossenem Adapter misst oder ohne. also im Leerlauf?
Ansonsten schließe alles am ebus der Weishaupt ab und messe nochmals, dann sollte es passen. Wenn die selbst gebaute Schnittstelle der Verursacher des hohen Spannungsabfalls ist, überprüfe bitte ob der 78L05 richtig eingelötet wurde, bzw. den Transistor, die 4 Dioden und ob bei der Zenerdiode alles passt. Polung und Lötfehler bzw. Kurzschlüsse von kleinen Zinntropfen überprüfen!
LG
Reinhart
Zitat von: zentis666 am 10 Juli 2015, 17:00:06
Aber nach ca. 15 min kam gerade wieder signal lost trotz Brimborium mit USB Hub usw. :-(
Jetzt kann ich mich also dem Thema widmen...
@pah / Reinhart: würdet Ihr nochmal unterstützen? Wie geht man am Besten vor?
pah hat geschrieben Spannung am 4011 Gatter messen,
ich hab nur ein Multimeter da, reicht das oder brauchts ein Oszilloskop um irgendwelche Spannungsschwankungen auszumessen?
Gruß
Sven
ein normales Multimeter (analog oder digital) genügt vollkommen. Messen musst immer die beiden Eingänge und den zugehörigen Ausgang des Nand-Gatters und vergleiche mit der Logiktabelle ob es passt (beide Eingänge H ergibt L, alles andere ist H). Seltsam, dass es 15 Minuten geht. Wenn was zu schwingen beginnt (siehst du NICHT am Multimeter), kannst über die VDD des 4011 sicherheitshalber einen Kondensator löten (zB: 33nF oder 100nF, ist nicht kritisch dieser Wert) und lege die beiden unbenutzten Eingänge des 4011 auf Masse und schaue nochmals ob der Fehler auftritt.
Du weist aber schon, das "
Arbitration lost" im Betrieb normal sind, siehe hier.
2015-07-10 10:11:22.295 [update notice] update bc Mode QQ=10: standby
2015-07-10 10:11:26.287 [update notice] unknown MS cmd: 1008b5110101 / 097a62d01264560200ff
2015-07-10 10:11:32.198 [bus error] ERR: arbitration lost, retry
2015-07-10 10:11:32.295 [update notice] update bc Mode QQ=10: standby
2015-07-10 10:11:36.288 [update notice] unknown MS cmd: 1008b5110101 / 097a64d01264560200ff
Viel Erfolg
Reinhart
Ok, danke dann probiere ich das mal, und ja ich weiß dass arbitration lost normal ist, es geht hier nur um Signal lost... Das Signal findet er dann meist nicht wieder.
Gruß
Sven
Gesendet von iPhone mit Tapatalk
ZitatIst das jetzt die Spannung die du mit angeschlossenem Adapter misst oder ohne. also im Leerlauf?
Die 6V messe ich ohne angeschlossenen Adapter, direkt an der Bedieneinheit, welche seltsamerweise einwandfrei funktioniert.(?)
Gut, jetzt weiß ich wo ich suchen muss. Ich vermute, dass es wirklich am Kabel liegen könnte.
Ich werde nun einmal direkt am Brenner, an den ebus Anschlussklemmen messen und das mit und ohne angeklemmtes Kabel. Danach bin ich bestimmt schlauer.
Melde mich und werde berichten...
LG
Thomas
ich habe soeben in der Weishaupt Doku nachgelesen und da ist mir aufgefallen, dass man hier die Speisung des eBus einstellen kann.
Schau dir bitte einmal die Parameter P12 und P71 genauer an.
P 12 Kesseladresse
1 = Einzelgerät A ... E = Kaskade, DDC-System (1, A: eBus-Speisung aktiv, B ... E: schaltbare eBus-Speisung P 71)
P 71 eBus-Speisung (nur wenn P12 = A ... E)
--- = nicht aktiv
1 = aktiv
LG
Zunächst Vielen Dank an pah und Reinhart für die Unterstützung.
Mein Transistor ist unterwegs - ist vielleicht Morgen da?
@Sven
Deine Probleme kann ich in meinem Umfeld nicht bestätigen:
2015-07-10 21:44:48.725 [main notice] ebusd 1.2.0 started
2015-07-10 21:44:48.814 [main notice] found messages: 439 (0 poll, 11 update)
2015-07-10 21:44:48.822 [bus notice] signal acquired
2015-07-10 21:44:51.010 [bus notice] new master 10
2015-07-10 21:44:51.010 [bus notice] new master 03
2015-07-10 21:44:51.011 [update notice] unknown MS cmd: 1008b5110101 / 093c3c001436240002ff
2015-07-10 21:44:53.020 [update notice] update broadcast vdatetime QQ=10: 21:44:56;10.07.2015
2015-07-10 21:45:32.072 [update notice] unknown BC cmd: 10feb505020400
2015-07-10 21:45:52.274 [update notice] update broadcast vdatetime QQ=10: 21:45:55;10.07.2015
2015-07-10 21:46:02.467 [update notice] unknown BC cmd: 10feb505022900
2015-07-10 21:46:02.760 [update notice] unknown MS cmd: 1008b5040100 / 0a03034621100705150014
2015-07-10 21:46:03.028 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-07-10 21:47:11.018 [bus error] signal lost
2015-07-10 21:47:11.449 [bus notice] signal acquired
2015-07-10 21:48:19.695 [update notice] update broadcast outsidetemp QQ=10: 19.000
2015-07-10 21:48:29.738 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-07-10 21:48:47.782 [update notice] unknown MS cmd: 1008b5110101 / 093c3c001436240002ff
2015-07-10 21:48:58.018 [update notice] update broadcast vdatetime QQ=10: 21:49:01;10.07.2015
2015-07-10 21:49:06.172 [update notice] unknown MS cmd: 1008b5110101 / 093c3c001436240002ff
2015-07-10 21:50:54.517 [update notice] unknown MS cmd: 1008b5110101 / 093c3c001436240000ff
2015-07-10 21:52:14.176 [update notice] update broadcast outsidetemp QQ=10: 19.000
2015-07-10 21:53:31.894 [update notice] unknown MS cmd: 1008b5110101 / 093a3a001434240002ff
2015-07-10 21:53:52.322 [update notice] update broadcast vdatetime QQ=10: 21:53:55;10.07.2015
2015-07-10 21:54:12.701 [update notice] update broadcast outsidetemp QQ=10: 19.000
2015-07-10 21:54:41.041 [bus error] signal lost
2015-07-10 21:54:41.086 [bus notice] signal acquired
2015-07-10 21:55:50.856 [update notice] update broadcast vdatetime QQ=10: 21:55:53;10.07.2015
2015-07-10 21:56:11.257 [update notice] update broadcast outsidetemp QQ=10: 19.000
2015-07-10 21:56:50.147 [update notice] update broadcast vdatetime QQ=10: 21:56:53;10.07.2015
2015-07-10 21:57:05.044 [bus error] signal lost
2015-07-10 21:57:05.391 [bus notice] signal acquired
2015-07-10 21:57:18.040 [bus error] signal lost
2015-07-10 21:57:18.099 [bus notice] signal acquired
2015-07-10 21:57:39.135 [update notice] unknown BC cmd: 10feb505020400
2015-07-10 21:58:17.705 [update notice] update broadcast outsidetemp QQ=10: 19.000
2015-07-10 21:58:27.966 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-07-10 21:59:16.993 [update notice] update broadcast outsidetemp QQ=10: 18.812
2015-07-10 21:59:43.589 [update notice] unknown MS cmd: 1008b5110101 / 093a3a001434240002ff
2015-07-10 22:00:16.250 [update notice] update broadcast outsidetemp QQ=10: 18.812
2015-07-10 22:00:34.920 [update notice] unknown BC cmd: 10feb505020400
2015-07-10 22:00:59.049 [bus error] signal lost
2015-07-10 22:00:59.340 [bus notice] signal acquired
2015-07-10 22:02:04.655 [update notice] unknown MS cmd: 1008b5040100 / 0a00090222ffffffffd013
2015-07-10 22:02:04.927 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-07-10 22:02:12.765 [update notice] update broadcast outsidetemp QQ=10: 18.812
2015-07-10 22:03:50.933 [update notice] update broadcast vdatetime QQ=10: 22:03:53;10.07.2015
2015-07-10 22:04:11.286 [update notice] update broadcast outsidetemp QQ=10: 18.812
2015-07-10 22:05:26.969 [update notice] unknown MS cmd: 1008b5110101 / 093a3ad01334240002ff
"signal lost" Meldungen tauchen bei mir auch auf, aber Signal findet er immer wieder.
Mitlerweile läuft es schon ca. eine Stunde.
Viele Grüße
Arthur
diese "Signal lost" Geschichte ist schon etwas merkwürdig, habe so einen Fehler keinen einzigen im Log.
Jojo11 hatte ja ursprünglich einen defekten BusKoppler, welcher Probleme beim Senden hatte und der zeigte ja genau dieselben Fehler die ihr jetzt hier postet. http://forum.fhem.de/index.php/topic,29737.msg279899.html#msg279899 (http://forum.fhem.de/index.php/topic,29737.msg279899.html#msg279899)
Nach Austausch seines Kopplers funktionierte dann alles. Bei zentis666 bin ich mir nicht sicher, da das Problem nach tausch des Transistors nun erst nach 15 Minuten auftritt. Nur zeigt es sehr wohl, das der Sendetransistor (richtiger Typ) eine große Rolle spielt.
@amunra: Kannst du denn auch Werte über den eBus einstellen?
Gibt es denn jetzt überhaupt einen der die Platine nachgebaut hat und bei dem alles funktioniert, auch der Sendeweg und ohne "Signal lost"?
Der Sendetransistor hat die Aufgabe, über die Zenerdiode das Signal des eBus (25 V) gegen 8V zu ziehen um somit das Low Signal zu bilden, gleichzeitig sollte aber die Gesamtstromaufnahme am Bus pro Gerät 28mA nicht übersteigen.
LG
Ich bin bei meiner Suche etwas weiter gekommen,
hab den Kondensator eingelötet und die beiden unbenutzen Eingänge am 4011 auf Masse gelegt.
Der Fehler kommt immer noch.
Aber:
nachdem "signal lost" kommt, zeigt dmesg auf dem pi folgendes:
[ 2625.865290] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 3286.080975] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Ich dachte zuerst vielleicht schaltet der pi das Gerät ab, da die Power LED vom USB Adapter nach Signal Lost aus war.
Die LED geht dann erst wieder an, wenn ich denn ebusd stoppe und neu starte.
Ich hab mal das Power-Management vom USB Adapter abgeschaltet:
Man legt eine Datei an /etc/modprobe.d/ftdi_sio.conf, Inhalt:
options ftdi_sio rtw_power_mgnt=0 rtw_enusbss=0
Nach Reboot leider wieder "signal lost" (nach ca. 50 Minuten), die Status LED bleibt aber nun auch nach "signal lost" an.
Ich nutze Debian Wheezy, Kernel 3.18,
dem Link nach zu urteilen scheint das ein Problem des Kernels zu sein:
http://newscentral.exsees.com/item/e456459d879e22822b972ae69412f9bb-fae6cb5da605e65f6df936ce6abbcb11 (http://newscentral.exsees.com/item/e456459d879e22822b972ae69412f9bb-fae6cb5da605e65f6df936ce6abbcb11)
Gruß
Sven
@zentis666
Sehr gut, du gibt's nicht auf und suchst fleißig weiter!
Bei Kernel Treibern bin ich nicht der richtige Mann dafür, aber ich habe dir ein paar Logs gemacht.
Deine Bobachtung würde auch erklären, warum du mit den Netzteilen so Probleme hast.
pi@raspberry2 ~ $ uname -a
Linux raspberry2 3.18.7+ #755 PREEMPT Thu Feb 12 17:14:31 GMT 2015 armv6l GNU/Linux
pi@raspberry2 ~ $ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Ich habe den Kernel 3.18.7, aber nicht den FTDi eingebunden, sondern den PL2303.
Erkennt er dann in der dmesg so:
[ 3.477642] usb 1-1.5: new full-speed USB device number 4 using dwc_otg
[ 3.610375] usb 1-1.5: New USB device found, idVendor=067b, idProduct=2303
[ 3.631317] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 3.651643] usb 1-1.5: Product: USB-Serial Controller
[ 3.664263] usb 1-1.5: Manufacturer: Prolific Technology Inc.
[ 4.436575] udevd[161]: starting version 175
[ 6.026296] usbcore: registered new interface driver usbserial
[ 6.252530] usbcore: registered new interface driver usbserial_generic
[ 6.448605] usbserial: USB Serial support registered for generic
[ 6.693137] usbcore: registered new interface driver pl2303
[ 6.923574] usbserial: USB Serial support registered for pl2303
[ 7.135185] pl2303 1-1.5:1.0: pl2303 converter detected
[ 7.298081] usb 1-1.5: pl2303 converter now attached to ttyUSB0
wenn ich hier allerdings herumpfusche und in den Raw Modus schalten möchte (wie im Thread dort erklärt), dann habe ich ebenfalls "Signal lost" Probleme und es kommen nur mehr Broadcasts durch.
stty -F /dev/ttyUSB0 38400 raw
2015-07-11 16:04:44.478 [bus notice] signal acquired
2015-07-11 16:04:47.864 [update notice] update broadcast outsidetemp QQ=10: 23.062
2015-07-11 16:04:49.038 [bus error] signal lost
2015-07-11 16:04:49.906 [bus notice] signal acquired
2015-07-11 16:04:52.034 [bus error] signal lost
2015-07-11 16:04:52.797 [bus notice] signal acquired
2015-07-11 16:04:58.024 [bus error] signal lost
2015-07-11 16:04:58.806 [bus notice] signal acquired
2015-07-11 16:05:03.021 [bus error] signal lost
2015-07-11 16:05:03.778 [bus notice] signal acquired
2015-07-11 16:05:08.005 [bus error] signal lost
2015-07-11 16:05:08.773 [bus notice] signal acquired
2015-07-11 16:05:09.960 [bus notice] new master 10
2015-07-11 16:05:09.960 [bus notice] new master 03
2015-07-11 16:05:09.960 [update notice] update bc Mode QQ=10: standby
2015-07-11 16:05:13.024 [bus error] signal lost
2015-07-11 16:05:13.790 [bus notice] signal acquired
Muss dann den Pi neu booten, dann passt wieder alles!
LG
@Reinhart: Danke für die logs!
Ich hab jetzt den ebusd auf einen altes Netbook mit Ububtu umgezogen, und seit knapp 2h kein signal lost, sieht gut aus. Ich lasse das jetzt mal bis morgen laufen.
Dann müsste ich also den USB Adapter auf dem Raspi per PL2303 einbinden. Da muss ich mich erst mal einlesen. Interessanterweise musste ich bei Anschluss als Netbook die Poti Einstellung des Adapters um ca. einen Teilstrich nach unten korrigieren, sonst findet er kein Signal.
Jetzt reichts mir für heute, ich schmeiß den Grill an, der hat (noch) keinen Ebus
@zentis666
ich habe da gar nichts selbst eingebunden, so wird mein USB-Konverter vom Raspi nach dem booten automatisch erkannt.
Zumindest weis man jetzt, woher die "Signal lost" kommen und braucht nicht mehr länger an der Schaltung suchen.
Hast du denn die Möglichkeit einen anderen Typ von USB Konverter zu testen, das wäre jetzt das einfachste.
LG
Reinhart
@Reinhart: ich hab gerade nix anderes da aber die USB Konverter kosten ja nicht die Welt... Hast Du nen Link zu Deinem? Dann hol ich mir noch so ein Teil...
Gesendet von iPhone mit Tapatalk
Zitat von: zentis666 am 11 Juli 2015, 17:46:46
Dann müsste ich also den USB Adapter auf dem Raspi per PL2303 einbinden.
Wenn Du die RPi interne serielle Schnittstelle meinst, dann ist das kein guter Plan. Denn im Kernel wird diese fix mit 16 Bytes Puffer konfiguriert, was ein Killerkriterium für aktives Senden auf dem eBUS ist.
Ich kann Dir nur empfehlen, einen vernünftigen externen USB-serial Wandler einzusetzen, am besten auf FTDI Basis.
Zitat von: john30 am 12 Juli 2015, 09:20:38
Ich kann Dir nur empfehlen, einen vernünftigen externen USB-serial Wandler einzusetzen, am besten auf FTDI Basis.
USB Wandler mit Ebus Adapter arbeiten an meinem Ubuntu-Netbook jetzt schon über 12h ohne Probleme, also scheint es tatsächlich ein Software Problem zu sein.
Ich verwende folgendes Gerät:
http://www.ebay.de/itm/321647516230Was wäre denn Deiner Erfahrung nach ein vernünftiger externer USB Wandler?
Sollte man den vorhandenen tatsächlich tauschen?
Das Linux auf dem Raspi zu ändern wäre ja auch eine Option.
Gruss
Sven
also ich habe den da, sieht zwar ein bisschen anders aus als am Bild: http://www.amazon.de/PL2303-Konverter-Adapter-Modul-freiem-PL2303HX-versendet/dp/B00AVRIDB0/ref=sr_1_4?ie=UTF8&qid=1436688741&sr=8-4&keywords=usb+pl2303 (http://www.amazon.de/PL2303-Konverter-Adapter-Modul-freiem-PL2303HX-versendet/dp/B00AVRIDB0/ref=sr_1_4?ie=UTF8&qid=1436688741&sr=8-4&keywords=usb+pl2303)
Aber die billigste Methode wäre jetzt ein Downgrade vom Kernel, mit der älteren Version (< 3.18) soll es ja laut Bericht tadellos geklappt haben. Ich weiß aber jetzt nicht genau ob die Fhem und eBus getrennt am Raspi hast. Ich betreibe den ebus auf einem eigenen Raspi, schon aus örtlichen Gründen. Habe die ganzen eBus Sachen direkt unter der Therme hinter einer Abdeckung fix verbaut. Habe auch Lan Kabel dort und der Watchdog von pah überwacht die Verbindung und startet diese notfalls neu.
Zumindest bist du nun sicher, das der selbst gebaute Konverter und ebusd funktioniert! Es wäre jetzt noch interessant ob die anderen Kollegen mit "lsusb" auch den selben Treiber mit dem gleichen Kernel eingebunden haben. Aber ich glaube die warten noch auf den Sendetransistor.
LG
Reinhart
Dazu gibt es einen ganzen Thread.
http://forum.fhem.de/index.php/topic,28552.msg213889.html#msg213889
Fazit: Serielle Schnittstelle des Raspberry Pi ist nur eine Krücke und für EBUS vollkommen ungeeignet.
LG
pah
Zitat von: zentis666 am 12 Juli 2015, 09:53:47
Ich verwende folgendes Gerät:
http://www.ebay.de/itm/321647516230
Was wäre denn Deiner Erfahrung nach ein vernünftiger externer USB Wandler?
Der sollte passen, ist ja ein FTDI Chip.
Ob es jetzt wirklich ein Problem mit dem eingesetzen Kernel ist, kann ich nicht sagen.
Du könntest ebusd mit "--lograwdata" starten (produziert allerdings sehr viel Logging!) und nach dem Signal loss schauen, was für Symbole noch vom Bus kommen.
Hallo Leute,
also ich bin raus aus dem Thema!
Nachdem Reinhart mir den Hinweis mit den speziellen ebus-Parametern an dem Weishaupt Geräte gegeben hat, habe ich versucht diese Einstellung bei mir zu finden.
Ich musste leider festellen, dass ich noch ein altes Brennwertgerät von Weihaupt besitze (Bauj. 96), zwar mit der Berzeichnung "WTC25NF", aber das hat keinen ebus, sondern nur RS485 zwischen Kessel und Bedieneinheit.
Mensch war ich blöd!!! :-[
Trotzdem möchte ich den Beteiligten für ihre Unterstützung danken.
LG
Thomas
Zitat von: john30 am 12 Juli 2015, 10:48:29
Du könntest ebusd mit "--lograwdata" starten (produziert allerdings sehr viel Logging!) und nach dem Signal loss schauen, was für Symbole noch vom Bus kommen.
Nach dem signal lost kommt vom Bus gar nichts mehr:
pi@ebuspi ~ $ ebusd -f -l All -d /dev/ttyUSB0 -p 8888 --lograwdata
2015-07-12 16:23:45.153 [main notice] ebusd 1.2.0 started
2015-07-12 16:23:45.327 [main notice] found messages: 342 (0 poll, 0 update)
2015-07-12 16:23:45.368 [bus notice] <00
2015-07-12 16:23:45.370 [bus notice] signal acquired
2015-07-12 16:23:45.372 [bus notice] <00
2015-07-12 16:23:45.374 [bus notice] <00
2015-07-12 16:23:45.376 [bus notice] <00
2015-07-12 16:23:45.378 [bus notice] <00
2015-07-12 16:23:45.380 [bus notice] <00
2015-07-12 16:23:45.383 [bus notice] <00
2015-07-12 16:23:45.385 [bus notice] <00
2015-07-12 16:23:45.387 [bus notice] <00
2015-07-12 16:23:45.389 [bus notice] <00
2015-07-12 16:23:45.392 [bus notice] <00
2015-07-12 16:23:45.395 [bus notice] <00
2015-07-12 16:23:45.397 [bus notice] <00
2015-07-12 16:23:45.399 [bus notice] <00
2015-07-12 16:23:45.401 [bus notice] <00
2015-07-12 16:23:45.404 [bus notice] <00
2015-07-12 16:23:45.406 [bus notice] <00
2015-07-12 16:23:45.408 [bus notice] <00
2015-07-12 16:23:45.410 [bus notice] <00
2015-07-12 16:23:45.413 [bus notice] <00
2015-07-12 16:23:45.415 [bus notice] <00
2015-07-12 16:23:45.417 [bus notice] <00
2015-07-12 16:23:45.419 [bus notice] <00
2015-07-12 16:23:45.422 [bus notice] <00
2015-07-12 16:23:45.424 [bus notice] <00
2015-07-12 16:23:45.426 [bus notice] <00
2015-07-12 16:23:45.428 [bus notice] <00
2015-07-12 16:23:45.430 [bus notice] <00
2015-07-12 16:23:45.432 [bus notice] <00
2015-07-12 16:23:45.435 [bus notice] <00
2015-07-12 16:23:45.437 [bus notice] <00
2015-07-12 16:23:45.439 [bus notice] <00
2015-07-12 16:23:45.441 [bus notice] <00
2015-07-12 16:23:45.443 [bus notice] <00
2015-07-12 16:23:45.446 [bus notice] <00
2015-07-12 16:23:45.448 [bus notice] <00
2015-07-12 16:23:45.451 [bus notice] <00
2015-07-12 16:23:45.453 [bus notice] <00
2015-07-12 16:23:45.456 [bus notice] <aa
2015-07-12 16:23:45.458 [bus notice] <aa
2015-07-12 16:23:45.460 [bus notice] <aa
2015-07-12 16:23:45.498 [bus notice] <aa
2015-07-12 16:23:45.541 [bus notice] <aa
2015-07-12 16:23:45.584 [bus notice] <aa
2015-07-12 16:23:45.626 [bus notice] <aa
2015-07-12 16:23:45.670 [bus notice] <aa
2015-07-12 16:23:45.713 [bus notice] <aa
2015-07-12 16:23:45.756 [bus notice] <aa
2015-07-12 16:23:45.799 [bus notice] <aa
2015-07-12 16:23:45.843 [bus notice] <aa
2015-07-12 16:23:45.885 [bus notice] <aa
2015-07-12 16:23:45.929 [bus notice] <aa
2015-07-12 16:23:45.972 [bus notice] <aa
2015-07-12 16:23:46.015 [bus notice] <aa
2015-07-12 16:23:46.057 [bus notice] <aa
2015-07-12 16:23:46.100 [bus notice] <aa
2015-07-12 16:23:46.143 [bus notice] <aa
2015-07-12 16:23:46.186 [bus notice] <aa
2015-07-12 16:23:46.229 [bus notice] <aa
2015-07-12 16:23:46.272 [bus notice] <aa
2015-07-12 16:23:46.315 [bus notice] <aa
2015-07-12 16:23:46.360 [bus notice] <aa
2015-07-12 16:23:46.402 [bus notice] <aa
2015-07-12 16:23:46.445 [bus notice] <aa
2015-07-12 16:23:46.488 [bus notice] <aa
2015-07-12 16:23:46.531 [bus notice] <aa
2015-07-12 16:23:46.573 [bus notice] <aa
2015-07-12 16:23:46.617 [bus notice] <aa
2015-07-12 16:23:46.661 [bus notice] <aa
2015-07-12 16:23:46.664 [bus notice] <10
2015-07-12 16:23:46.670 [bus notice] <08
2015-07-12 16:23:46.674 [bus notice] <b5
2015-07-12 16:23:46.678 [bus notice] <10
2015-07-12 16:23:46.683 [bus notice] <09
2015-07-12 16:23:46.688 [bus notice] <00
2015-07-12 16:23:46.692 [bus notice] <00
2015-07-12 16:23:46.697 [bus notice] <00
2015-07-12 16:23:46.701 [bus notice] <ff
2015-07-12 16:23:46.706 [bus notice] <ff
2015-07-12 16:23:46.711 [bus notice] <ff
2015-07-12 16:23:46.715 [bus notice] <05
2015-07-12 16:23:46.719 [bus notice] <00
2015-07-12 16:23:46.724 [bus notice] <00
2015-07-12 16:23:46.729 [bus notice] <7e
2015-07-12 16:23:46.735 [bus notice] <00
2015-07-12 16:23:46.744 [bus notice] <01
2015-07-12 16:23:46.748 [bus notice] <01
2015-07-12 16:23:46.752 [bus notice] <9a
2015-07-12 16:23:46.756 [bus notice] <00
2015-07-12 16:23:46.757 [bus notice] new master 10
2015-07-12 16:23:46.758 [bus notice] new master 03
2015-07-12 16:23:46.760 [update notice] unknown MS cmd: 1008b51009000000ffffff050000 / 0101
2015-07-12 16:23:46.762 [bus notice] <aa
2015-07-12 16:23:46.805 [bus notice] <aa
2015-07-12 16:23:46.847 [bus notice] <aa
2015-07-12 16:23:46.891 [bus notice] <aa
2015-07-12 16:23:46.934 [bus notice] <aa
2015-07-12 16:23:46.977 [bus notice] <aa
2015-07-12 16:23:47.021 [bus notice] <aa
2015-07-12 16:23:47.062 [bus notice] <aa
2015-07-12 16:23:47.106 [bus notice] <aa
2015-07-12 16:23:47.149 [bus notice] <aa
2015-07-12 16:23:47.192 [bus notice] <aa
2015-07-12 16:23:47.236 [bus notice] <aa
2015-07-12 16:23:47.279 [bus notice] <aa
2015-07-12 16:23:47.322 [bus notice] <aa
2015-07-12 16:23:47.364 [bus notice] <aa
2015-07-12 16:23:47.407 [bus notice] <aa
2015-07-12 16:23:47.451 [bus notice] <aa
2015-07-12 16:23:47.493 [bus notice] <aa
2015-07-12 16:23:47.536 [bus notice] <aa
2015-07-12 16:23:47.579 [bus notice] <aa
2015-07-12 16:23:47.622 [bus notice] <aa
2015-07-12 16:23:47.665 [bus notice] <aa
2015-07-12 16:23:47.708 [bus notice] <aa
2015-07-12 16:23:47.752 [bus notice] <aa
2015-07-12 16:23:47.796 [bus notice] <aa
2015-07-12 16:23:47.839 [bus notice] <aa
2015-07-12 16:23:47.882 [bus notice] <aa
2015-07-12 16:23:47.926 [bus notice] <aa
2015-07-12 16:23:47.969 [bus notice] <aa
2015-07-12 16:23:48.013 [bus notice] <aa
2015-07-12 16:23:48.056 [bus notice] <aa
2015-07-12 16:23:48.099 [bus notice] <aa
2015-07-12 16:23:48.142 [bus notice] <aa
2015-07-12 16:23:48.185 [bus notice] <aa
2015-07-12 16:23:48.228 [bus notice] <aa
2015-07-12 16:23:48.272 [bus notice] <aa
2015-07-12 16:23:48.314 [bus notice] <aa
2015-07-12 16:23:48.357 [bus notice] <aa
2015-07-12 16:23:48.400 [bus notice] <aa
2015-07-12 16:23:48.443 [bus notice] <aa
2015-07-12 16:23:48.486 [bus notice] <aa
2015-07-12 16:23:48.530 [bus notice] <aa
2015-07-12 16:23:48.572 [bus notice] <aa
2015-07-12 16:23:48.616 [bus notice] <aa
2015-07-12 16:23:48.659 [bus notice] <aa
2015-07-12 16:23:48.701 [bus notice] <aa
2015-07-12 16:23:48.744 [bus notice] <aa
2015-07-12 16:23:48.788 [bus notice] <aa
2015-07-12 16:23:48.831 [bus notice] <aa
2015-07-12 16:23:48.874 [bus notice] <aa
2015-07-12 16:23:48.916 [bus notice] <aa
2015-07-12 16:23:48.960 [bus notice] <aa
2015-07-12 16:23:49.003 [bus notice] <aa
2015-07-12 16:23:51.029 [bus error] signal lost
^C2015-07-12 16:24:08.569 [main notice] SIGINT received
2015-07-12 16:24:08.676 [main notice] ebusd stopped
Zitat von: zentis666 am 12 Juli 2015, 16:24:55
Nach dem signal lost kommt vom Bus gar nichts mehr:
oh, nicht gut. Schau doch mal, ob es einen syslog Eintrag gibt. Vielleicht ist das device gestorben...
wie schon geschrieben, dmesg zeigt
[ 296.352152] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[ 297.903354] ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Zitat von: zentis666 am 12 Juli 2015, 16:43:23
wie schon geschrieben, dmesg zeigt
Hängt Dein FTDI Adapter an einem USB Hub oder direkt am Pi?
Offensichtlich wurden in Deine Kernel-Version 3.18 einige Updates am FTDI Treiber reingepatcht, die nicht besonders gut waren.
Kannst Du einen Versuch mit Kernel 4.0 oder 3.14 starten?
Der Adapter hängt direkt dran. Nach Update auf 4.0.7 das gleiche Verhalten. Downgrade hab ich noch nicht gemacht. Probier ich mal aus...
Gesendet von iPhone mit Tapatalk
Test mit Kernel 3.12:
auch signal lost, fängt sich aber ab und zu dann doch wieder, dmesg zeigt:
[ 98.022157] ftdi_sio ttyUSB0: failed to get modem status: -32
^[[Api@ebuspi ebusd -f -l All -d /dev/ttyUSB0 -p 8888 --lograwdata
2015-07-12 17:17:23.442 [main notice] ebusd 1.2.0 started
2015-07-12 17:17:23.631 [main notice] found messages: 342 (0 poll, 0 update)
2015-07-12 17:17:23.639 [bus notice] <00
2015-07-12 17:17:23.640 [bus notice] signal acquired
2015-07-12 17:17:23.642 [bus notice] <5e
2015-07-12 17:17:23.644 [bus notice] <40
2015-07-12 17:17:24.228 [bus notice] <aa
2015-07-12 17:17:24.271 [bus notice] <aa
2015-07-12 17:17:24.315 [bus notice] <aa
2015-07-12 17:17:24.358 [bus notice] <aa
2015-07-12 17:17:24.399 [bus notice] <aa
2015-07-12 17:17:24.442 [bus notice] <aa
2015-07-12 17:17:24.486 [bus notice] <aa
2015-07-12 17:17:24.529 [bus notice] <aa
2015-07-12 17:17:24.572 [bus notice] <aa
2015-07-12 17:17:24.616 [bus notice] <aa
2015-07-12 17:17:24.658 [bus notice] <aa
2015-07-12 17:17:24.701 [bus notice] <aa
2015-07-12 17:17:24.744 [bus notice] <aa
2015-07-12 17:17:24.787 [bus notice] <aa
2015-07-12 17:17:24.830 [bus notice] <aa
2015-07-12 17:17:24.874 [bus notice] <aa
2015-07-12 17:17:24.918 [bus notice] <aa
2015-07-12 17:17:24.960 [bus notice] <aa
2015-07-12 17:17:25.002 [bus notice] <aa
2015-07-12 17:17:25.046 [bus notice] <aa
2015-07-12 17:17:25.089 [bus notice] <aa
2015-07-12 17:17:25.131 [bus notice] <aa
2015-07-12 17:17:25.174 [bus notice] <aa
2015-07-12 17:17:25.217 [bus notice] <aa
2015-07-12 17:17:25.261 [bus notice] <aa
2015-07-12 17:17:25.305 [bus notice] <aa
2015-07-12 17:17:25.348 [bus notice] <aa
2015-07-12 17:17:25.391 [bus notice] <aa
2015-07-12 17:17:27.000 [bus error] signal lost
2015-07-12 17:17:45.552 [bus notice] re-opened /dev/ttyUSB0
2015-07-12 17:17:45.555 [bus notice] <00
2015-07-12 17:17:45.555 [bus notice] signal acquired
2015-07-12 17:17:45.556 [bus notice] <00
2015-07-12 17:17:45.559 [bus notice] <00
2015-07-12 17:17:45.560 [bus notice] <00
2015-07-12 17:17:45.562 [bus notice] <a7
2015-07-12 17:17:45.564 [bus notice] <fd
2015-07-12 17:17:45.599 [bus notice] <aa
2015-07-12 17:17:45.643 [bus notice] <aa
2015-07-12 17:17:45.686 [bus notice] <aa
2015-07-12 17:17:45.728 [bus notice] <aa
2015-07-12 17:17:45.771 [bus notice] <aa
2015-07-12 17:17:45.815 [bus notice] <aa
2015-07-12 17:17:45.858 [bus notice] <aa
2015-07-12 17:17:45.900 [bus notice] <aa
2015-07-12 17:17:45.944 [bus notice] <aa
2015-07-12 17:17:45.987 [bus notice] <aa
2015-07-12 17:17:46.030 [bus notice] <aa
2015-07-12 17:17:46.073 [bus notice] <aa
2015-07-12 17:17:46.116 [bus notice] <aa
2015-07-12 17:17:46.159 [bus notice] <aa
2015-07-12 17:17:46.203 [bus notice] <aa
2015-07-12 17:17:46.246 [bus notice] <aa
2015-07-12 17:17:46.288 [bus notice] <aa
2015-07-12 17:17:46.331 [bus notice] <aa
2015-07-12 17:17:46.374 [bus notice] <aa
2015-07-12 17:17:46.416 [bus notice] <aa
2015-07-12 17:17:46.460 [bus notice] <aa
2015-07-12 17:17:46.503 [bus notice] <aa
2015-07-12 17:17:46.546 [bus notice] <aa
2015-07-12 17:17:46.590 [bus notice] <aa
2015-07-12 17:17:46.633 [bus notice] <aa
2015-07-12 17:17:46.675 [bus notice] <aa
2015-07-12 17:17:46.680 [bus notice] <10
2015-07-12 17:17:46.685 [bus notice] <08
2015-07-12 17:17:46.689 [bus notice] <b5
2015-07-12 17:17:46.694 [bus notice] <11
2015-07-12 17:17:46.698 [bus notice] <01
2015-07-12 17:17:46.704 [bus notice] <01
2015-07-12 17:17:46.708 [bus notice] <89
2015-07-12 17:17:46.714 [bus notice] <00
2015-07-12 17:17:46.722 [bus notice] <09
2015-07-12 17:17:46.725 [bus notice] <3d
2015-07-12 17:17:46.729 [bus notice] <3e
2015-07-12 17:17:46.734 [bus notice] <a0
2015-07-12 17:17:46.738 [bus notice] <17
2015-07-12 17:17:46.742 [bus notice] <3f
2015-07-12 17:17:46.746 [bus notice] <60
2015-07-12 17:17:46.751 [bus notice] <00
2015-07-12 17:17:46.755 [bus notice] <00
2015-07-12 17:17:46.759 [bus notice] <ff
2015-07-12 17:17:46.763 [bus notice] <14
2015-07-12 17:17:46.768 [bus notice] <00
2015-07-12 17:17:46.768 [bus notice] new master 10
2015-07-12 17:17:46.770 [bus notice] new master 03
2015-07-12 17:17:46.771 [update notice] unknown MS cmd: 1008b5110101 / 093d3ea0173f600000ff
2015-07-12 17:17:46.773 [bus notice] <aa
2015-07-12 17:17:46.815 [bus notice] <aa
2015-07-12 17:17:46.859 [bus notice] <aa
2015-07-12 17:17:46.901 [bus notice] <aa
2015-07-12 17:17:46.944 [bus notice] <aa
2015-07-12 17:17:46.987 [bus notice] <aa
2015-07-12 17:17:47.030 [bus notice] <aa
2015-07-12 17:17:47.072 [bus notice] <aa
2015-07-12 17:17:47.116 [bus notice] <aa
2015-07-12 17:17:47.159 [bus notice] <aa
2015-07-12 17:17:47.204 [bus notice] <aa
2015-07-12 17:17:47.247 [bus notice] <aa
2015-07-12 17:17:47.290 [bus notice] <aa
2015-07-12 17:17:47.334 [bus notice] <aa
2015-07-12 17:17:47.377 [bus notice] <aa
2015-07-12 17:17:47.420 [bus notice] <aa
2015-07-12 17:17:47.463 [bus notice] <aa
2015-07-12 17:17:47.506 [bus notice] <aa
2015-07-12 17:17:47.549 [bus notice] <aa
2015-07-12 17:17:47.592 [bus notice] <aa
2015-07-12 17:17:47.635 [bus notice] <aa
2015-07-12 17:17:47.678 [bus notice] <aa
2015-07-12 17:17:47.722 [bus notice] <aa
2015-07-12 17:17:47.765 [bus notice] <aa
2015-07-12 17:17:47.808 [bus notice] <aa
2015-07-12 17:17:47.850 [bus notice] <aa
2015-07-12 17:17:47.893 [bus notice] <aa
2015-07-12 17:17:47.937 [bus notice] <aa
2015-07-12 17:17:47.979 [bus notice] <aa
2015-07-12 17:17:48.023 [bus notice] <aa
2015-07-12 17:17:48.065 [bus notice] <aa
2015-07-12 17:17:48.108 [bus notice] <aa
2015-07-12 17:17:48.152 [bus notice] <aa
2015-07-12 17:17:48.195 [bus notice] <aa
2015-07-12 17:17:48.238 [bus notice] <aa
2015-07-12 17:17:48.280 [bus notice] <aa
2015-07-12 17:17:48.323 [bus notice] <aa
2015-07-12 17:17:48.366 [bus notice] <aa
2015-07-12 17:17:48.410 [bus notice] <aa
2015-07-12 17:17:48.454 [bus notice] <aa
2015-07-12 17:17:48.497 [bus notice] <aa
2015-07-12 17:17:48.540 [bus notice] <aa
2015-07-12 17:17:48.583 [bus notice] <aa
2015-07-12 17:17:48.625 [bus notice] <aa
2015-07-12 17:17:48.669 [bus notice] <aa
2015-07-12 17:17:48.712 [bus notice] <aa
2015-07-12 17:17:48.716 [bus notice] <10
2015-07-12 17:17:48.720 [bus notice] <ec
2015-07-12 17:17:48.724 [bus notice] <07
2015-07-12 17:17:48.729 [bus notice] <04
2015-07-12 17:17:48.734 [bus notice] <00
2015-07-12 17:17:48.739 [bus notice] <d4
2015-07-12 17:17:48.786 [bus notice] <aa
2015-07-12 17:17:48.830 [bus notice] <aa
2015-07-12 17:17:48.873 [bus notice] <aa
2015-07-12 17:17:48.916 [bus notice] <aa
2015-07-12 17:17:48.960 [bus notice] <aa
2015-07-12 17:17:48.965 [bus notice] <10
2015-07-12 17:17:48.969 [bus notice] <ec
2015-07-12 17:17:48.973 [bus notice] <07
2015-07-12 17:17:48.977 [bus notice] <04
2015-07-12 17:17:48.983 [bus notice] <00
2015-07-12 17:17:48.987 [bus notice] <d4
2015-07-12 17:17:49.035 [bus notice] <aa
2015-07-12 17:17:49.079 [bus notice] <aa
2015-07-12 17:17:49.121 [bus notice] <aa
2015-07-12 17:17:49.164 [bus notice] <aa
2015-07-12 17:17:49.208 [bus notice] <aa
2015-07-12 17:17:49.212 [bus notice] <10
2015-07-12 17:17:49.216 [bus notice] <ec
2015-07-12 17:17:49.221 [bus notice] <07
2015-07-12 17:17:49.225 [bus notice] <04
2015-07-12 17:17:49.231 [bus notice] <00
2015-07-12 17:17:49.235 [bus notice] <d4
2015-07-12 17:17:49.283 [bus notice] <aa
2015-07-12 17:17:49.327 [bus notice] <aa
2015-07-12 17:17:49.370 [bus notice] <aa
2015-07-12 17:17:49.413 [bus notice] <aa
2015-07-12 17:17:49.455 [bus notice] <aa
2015-07-12 17:17:49.460 [bus notice] <10
2015-07-12 17:17:49.465 [bus notice] <fe
2015-07-12 17:17:49.470 [bus notice] <b5
2015-07-12 17:17:49.474 [bus notice] <16
2015-07-12 17:17:49.478 [bus notice] <08
2015-07-12 17:17:49.482 [bus notice] <00
2015-07-12 17:17:49.488 [bus notice] <50
2015-07-12 17:17:49.492 [bus notice] <17
2015-07-12 17:17:49.497 [bus notice] <17
2015-07-12 17:17:49.501 [bus notice] <12
2015-07-12 17:17:49.506 [bus notice] <07
2015-07-12 17:17:49.511 [bus notice] <07
2015-07-12 17:17:49.515 [bus notice] <15
2015-07-12 17:17:49.519 [bus notice] <bd
2015-07-12 17:17:49.520 [update notice] unknown BC cmd: 10feb516080050171712070715
2015-07-12 17:17:49.525 [bus notice] <aa
2015-07-12 17:17:49.568 [bus notice] <aa
2015-07-12 17:17:49.610 [bus notice] <aa
2015-07-12 17:17:49.653 [bus notice] <aa
2015-07-12 17:17:49.697 [bus notice] <aa
2015-07-12 17:17:49.701 [bus notice] <10
2015-07-12 17:17:49.706 [bus notice] <fe
2015-07-12 17:17:49.710 [bus notice] <b5
2015-07-12 17:17:49.714 [bus notice] <16
2015-07-12 17:17:49.720 [bus notice] <03
2015-07-12 17:17:49.724 [bus notice] <04
2015-07-12 17:17:49.728 [bus notice] <00
2015-07-12 17:17:49.732 [bus notice] <17
2015-07-12 17:17:49.738 [bus notice] <85
2015-07-12 17:17:49.739 [update notice] unknown BC cmd: 10feb51603040017
2015-07-12 17:17:49.742 [bus notice] <aa
2015-07-12 17:17:49.785 [bus notice] <aa
2015-07-12 17:17:49.828 [bus notice] <aa
2015-07-12 17:17:49.871 [bus notice] <aa
2015-07-12 17:17:49.915 [bus notice] <aa
2015-07-12 17:17:49.918 [bus notice] <10
2015-07-12 17:17:49.922 [bus notice] <08
2015-07-12 17:17:49.927 [bus notice] <b5
2015-07-12 17:17:49.933 [bus notice] <12
2015-07-12 17:17:49.937 [bus notice] <02
2015-07-12 17:17:49.942 [bus notice] <00
2015-07-12 17:17:49.946 [bus notice] <00
2015-07-12 17:17:49.950 [bus notice] <ca
2015-07-12 17:17:49.956 [bus notice] <00
2015-07-12 17:17:49.964 [bus notice] <00
2015-07-12 17:17:49.968 [bus notice] <00
2015-07-12 17:17:49.974 [bus notice] <00
2015-07-12 17:17:49.975 [update notice] unknown MS cmd: 1008b512020000 / 00
2015-07-12 17:17:49.978 [bus notice] <aa
2015-07-12 17:17:50.021 [bus notice] <aa
2015-07-12 17:17:50.064 [bus notice] <aa
2015-07-12 17:17:50.108 [bus notice] <aa
2015-07-12 17:17:50.150 [bus notice] <aa
2015-07-12 17:17:50.193 [bus notice] <aa
2015-07-12 17:17:50.236 [bus notice] <aa
2015-07-12 17:17:50.279 [bus notice] <aa
2015-07-12 17:17:50.322 [bus notice] <aa
2015-07-12 17:17:50.366 [bus notice] <aa
2015-07-12 17:17:50.409 [bus notice] <aa
2015-07-12 17:17:50.451 [bus notice] <aa
2015-07-12 17:17:50.494 [bus notice] <aa
2015-07-12 17:17:50.537 [bus notice] <aa
2015-07-12 17:17:50.581 [bus notice] <aa
2015-07-12 17:17:50.624 [bus notice] <aa
2015-07-12 17:17:50.667 [bus notice] <aa
2015-07-12 17:17:50.710 [bus notice] <aa
2015-07-12 17:17:50.714 [bus notice] <10
2015-07-12 17:17:50.720 [bus notice] <08
2015-07-12 17:17:50.724 [bus notice] <b5
2015-07-12 17:17:50.729 [bus notice] <10
2015-07-12 17:17:50.733 [bus notice] <09
2015-07-12 17:17:50.737 [bus notice] <00
2015-07-12 17:17:50.742 [bus notice] <00
2015-07-12 17:17:50.746 [bus notice] <00
2015-07-12 17:17:50.752 [bus notice] <ff
2015-07-12 17:17:50.756 [bus notice] <ff
2015-07-12 17:17:50.760 [bus notice] <ff
2015-07-12 17:17:50.764 [bus notice] <01
2015-07-12 17:17:50.770 [bus notice] <00
2015-07-12 17:17:50.774 [bus notice] <00
2015-07-12 17:17:50.779 [bus notice] <26
2015-07-12 17:17:50.784 [bus notice] <00
2015-07-12 17:17:50.794 [bus notice] <01
2015-07-12 17:17:50.799 [bus notice] <01
2015-07-12 17:17:50.803 [bus notice] <9a
2015-07-12 17:17:50.807 [bus notice] <00
2015-07-12 17:17:50.808 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2015-07-12 17:17:50.813 [bus notice] <aa
2015-07-12 17:17:50.856 [bus notice] <aa
2015-07-12 17:17:50.899 [bus notice] <aa
2015-07-12 17:17:50.941 [bus notice] <aa
2015-07-12 17:17:50.985 [bus notice] <aa
2015-07-12 17:17:51.028 [bus notice] <aa
2015-07-12 17:17:51.072 [bus notice] <aa
2015-07-12 17:17:51.114 [bus notice] <aa
2015-07-12 17:17:51.160 [bus notice] <aa
2015-07-12 17:17:51.204 [bus notice] <aa
2015-07-12 17:17:51.247 [bus notice] <aa
2015-07-12 17:17:51.290 [bus notice] <aa
2015-07-12 17:17:51.333 [bus notice] <aa
2015-07-12 17:17:51.376 [bus notice] <aa
2015-07-12 17:17:51.419 [bus notice] <aa
2015-07-12 17:17:51.463 [bus notice] <aa
2015-07-12 17:17:51.506 [bus notice] <aa
2015-07-12 17:17:51.550 [bus notice] <aa
2015-07-12 17:17:51.593 [bus notice] <aa
2015-07-12 17:17:51.636 [bus notice] <aa
2015-07-12 17:17:51.680 [bus notice] <aa
2015-07-12 17:17:51.723 [bus notice] <aa
2015-07-12 17:17:51.765 [bus notice] <aa
2015-07-12 17:17:53.011 [bus error] signal lost
^C2015-07-12 17:18:32.440 [main notice] SIGINT received
2015-07-12 17:18:32.549 [main notice] ebusd stopped
Ich hab das Downgrade mit sudo rpi-update <hash der Version> gemacht, ich hab bei https://github.com/Hexxeh/rpi-firmware/commits/master (https://github.com/Hexxeh/rpi-firmware/commits/master) kein 3.14 gefunden.
Zitat von: zentis666 am 12 Juli 2015, 17:21:21
Test mit Kernel 3.12:
2015-07-12 17:17:27.000 [bus error] signal lost
2015-07-12 17:17:45.552 [bus notice] re-opened /dev/ttyUSB0
2015-07-12 17:17:45.555 [bus notice] <00
2015-07-12 17:17:45.555 [bus notice] signal acquired
Na das ist doch schon mal ein Teilerfolg. Dann sehe ich die Problematik mit dem neueren Kernel bestätigt. Jetzt müsste man mal anschauen, wann der Schmarrn aus den Kernel-Quellen wieder verschwindet...
Ich hab die Tests mit einem der "Problem-Netzteile" gemacht, also genauer gesagt mit
einem Rydges High-Quality PC Netzteil (2A), das ja immer mal wieder für den Raspi empfohlen wird,
da kommt der Signal lost immer schön schnell ;-)
Ich wollte nochmal die 3.10er Kernel Version probieren, nach Downgrade kommt die Kiste leider nicht mehr hoch ...
werde sie mal neu aufsetzen und auf dem 3.12er Kernel noch mal mit meiner Referenz-Stromversorgung (DLink USB Hub)
testen und noch mal berichten.
Gruß
Sven
Zitat von: Papaloewe am 12 Juli 2015, 13:15:52
Ich musste leider festellen, dass ich noch ein altes Brennwertgerät von Weihaupt besitze (Bauj. 96), zwar mit der Berzeichnung "WTC25NF", aber das hat keinen ebus, sondern nur RS485 zwischen Kessel und Bedieneinheit.
schade, dass du nicht schon einmal früher am vermeintlichen eBus gemessen hast, hättest aber auch keinen Grund gehabt.
Aber vielleicht hilft es so wenigstens anderen die gleiches vorhaben!
Bei Baujahr 96 wird es aber ohnehin nicht mehr lange dauern, bis der eBus bei dir einzieht!
LG
Reinhart
Bei mir scheint es nun zu laufen!
Mit Kernel 3.12.36 und meinem USB Hub als Stromversorgung für den Raspi läuft es nun seit einiger Zeit ohne "signal lost".
Das Problem mit den Netzteilen hab ich aber wie schon geschrieben weiterhin, nun findet er aber
bei Verwendung eines "Problemnetzteils" wenigstens mit dem 3.12er Kernel das Bus Signal wieder.
Mein Fazit:
- momentan: Kernel 3.12.36 oder früher verwenden
- wenn verstärkt "signal lost" kommen probiert ein anderes Netzteil
- einige in diversen Foren empfohlenen Netzteile machen bei mir auch Probleme
- am Besten schneidet hier bisher ein USB Hub ab
- die Verwendung eines 100nF Kondensators am 4011 hat bei mir leider nichts in Punkto "signal lost" gebracht.
Jetzt kann ich mich endlich der Einbindung in fhem widmen ;-)
Danke nochmal an alle die sich an der Problemlösung beteiligt haben für ihre Hilfe!
Grüsse
Sven
Es freut mich für dich, dass du dieses erstmals in Verbindung mit dem eBus aufgetretene Problem nun lösen konntest. Die Vielfalt der USB2ser Wandler wird hier noch einiges zeigen. Es ist seltsam, das diese Probleme erst jetzt auftauchen, die älteren Wandler zeigten diesen Fehler nicht. Es sind doch einige Leute die pah seine Schaltung im Einsatz haben.
Ich weis zwar nicht was pah und die anderen für einen Kernel haben, aber wie man sieht spielt der bei bestimmten Wandlern eh keine Rolle. Bei mir funktioniert es ebenfalls mit dem Kernel 3.18 störungsfrei.
Danke, dass du so unermüdlich bei der Fehlersuche gearbeitet hast und es somit vielen Nachbauern für die Zukunft erleichtert hast.
Hoffentlich verschwindet dieses Problem mit neueren Kernel dann eh von selbst!
LG
Reinhart
Hallo zusammen,
entschuldigt bitte meine späte Rückmeldung.
Ein paar Informationen habe ich auch
- die Post (der neue Transistor) ist heute (ja, heute) angekommen
- ich habe vor ca. zwei Stunden den neuen Transistor im Einsatz
Fazit:
- "senden" funktioniert! Vielen Dank für die Unterstützung und den richtigen Hinweiß. Damit ist es bestätigt, dass es mit dem richtigen Transistor funktioniert.
- Betrieb seit ca. 1,5 Stunden am Cubieboard via USB-FTDI Adapter http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-Neu-/321647516230?pt=LH_DefaultDomain_77&hash=item4ae3af9a46 (http://www.ebay.de/itm/FT232RL-FTDI-USB-zu-TTL-Serien-Converter-Adapter-Modul-5V-3-3V-Fur-Arduino-Neu-/321647516230?pt=LH_DefaultDomain_77&hash=item4ae3af9a46) bisher ohne "singal lost" Probleme. Damit ist es recht deutlich, dass die "signal lost" Probleme nichts mehr mit den EBUS Adapter zu tun haben.
Entschuldight bitte die Kurzfassung, vielleicht hilft es....
Viele Grüße
Arthur
Hallo, hab zwar die Teile bin aber noch nicht zum basteln gekommen.Bei dir läuft das Ganze auf dem Cubie? Der Rest von FHEM auch, oder nur die Heizungssteuerung?
Werde mir den Transistor dann besorgen wenn ich nächste mal in Dortmund beim C bin.
Ansonsten nach Wiki?
Hallo Franz Tenbrock,
meine rudimentäre Heizungssteuerung – wenn man das überhaupt so nennen darf – habe ich bisher auf einem Testsystem in Betrieb. Ich verwende ein cubietruck als Server, auf dem Server läuft auch eine FHEM Instanz mit unterschiedlichen aktiven Modulen. Die FHEM Anbindung läuft bzw. lief bisher über ein eigens dafür entwickeltes FHEM Modul siehe hier: http://forum.fhem.de/index.php/topic,29737.msg249278.html#msg249278 (http://forum.fhem.de/index.php/topic,29737.msg249278.html#msg249278). Das Modul muss/möchte ich komplett überarbeiten, da Ebusd mittlerweile einfachere Möglichkeiten bietet an die Befehle und Daten, die in den CSV-Dateien definiert sind, zu kommen. Mit den neuen Möglichkeiten kann ich ca. 80% des Quellcodes entfernen und mache damit das Modul schlanker. Aktuell kann ich auch nicht sagen, ob ich meine Heizungssteuerung jemals auf der produktiven HW laufen lasse (Stichwort: Ich habe auf dem Prod System zeitkritische Prozesse laufen). Derzeit habe ich andere höher priorisierte Aufgaben/Porjekte. Aus diesem Grund kann ich im Moment nicht abschätzen wann ich dazu komme das Modul zu überarbeiten.
Fazit: Es gibt hier sicher Ebusd Nutzer die mehr Erfahrung haben als ich, dafür habe ich es noch nicht in der Komplexität/Ausprägung im Einsatz.
Viele Grüße
Arthur
Hallo,
ich wollte ich mal für die Arbeit bedanken, die in den ebusd und das Erforschen der Vaillant Konfigurationsparameter gesteckt wurde.
Für diejenigen, welche das Löten und Inbetriebnehmen des Konverters hinter sich habe ist es sicher interessant die verschiedenen Parameter einfacher zu visualisieren. Ich habe mir dazu ein Modul geschrieben, dass ich hier vorstellen möchte.
Das Modul analysiert die .csv Files, die auch der ebusd verwendet und erlaubt es alle Variablen mit "get" abzufragen.
Mit der Funktion "set" ist es mögliche Attribute zu generieren und einem Reading zuzuordnen. Die Readings werden dann in einem Interval vom ebusd abgefragt. Es ist auch möglich Werte nur jeden n-ten Zyklus abzufragen um den ebus nicht zu stark zu belasten.
Durch den Umweg über das Attribut ist es möglich die teilweise kryptischen Namen aus den .csv Files in einen eigenen Namensraum zu mappen.
Aktuell läuft das Modul in Verbindung mit meiner Vaillant Heizung (ecoTec plus, calorMatic 470/2, vr61, Wasserspeicher, zwei getrennte Heizkreise für Heizkörper und Fußbodenheizung). Ich verwenden den Adapter von eservice-online.de.
Bei Interesse kann ich das Modul auch im contrib Zweig zur Verfügung stellen und ich bin auch bereit Erweiterungen zu implementieren.
Viele Grüße
Andy
Zitat von: jamesgo am 18 Juli 2015, 14:56:29
Hallo,
ich wollte ich mal für die Arbeit bedanken, die in den ebusd und das Erforschen der Vaillant Konfigurationsparameter gesteckt wurde.
Für diejenigen, welche das Löten und Inbetriebnehmen des Konverters hinter sich habe ist es sicher interessant die verschiedenen Parameter einfacher zu visualisieren. Ich habe mir dazu ein Modul geschrieben, dass ich hier vorstellen möchte.
Das Modul analysiert die .csv Files, die auch der ebusd verwendet und erlaubt es alle Variablen mit "get" abzufragen.
Mit der Funktion "set" ist es mögliche Attribute zu generieren und einem Reading zuzuordnen. Die Readings werden dann in einem Interval vom ebusd abgefragt. Es ist auch möglich Werte nur jeden n-ten Zyklus abzufragen um den ebus nicht zu stark zu belasten.
Durch den Umweg über das Attribut ist es möglich die teilweise kryptischen Namen aus den .csv Files in einen eigenen Namensraum zu mappen.
Aktuell läuft das Modul in Verbindung mit meiner Vaillant Heizung (ecoTec plus, calorMatic 470/2, vr61, Wasserspeicher, zwei getrennte Heizkreise für Heizkörper und Fußbodenheizung). Ich verwenden den Adapter von eservice-online.de.
Bei Interesse kann ich das Modul auch im contrib Zweig zur Verfügung stellen und ich bin auch bereit Erweiterungen zu implementieren.
Viele Grüße
Andy
Hallo jamesgo,
ich wäre brennend an diesem Modul interessiert, da ich gerade überlege wie ich alle Parameter übernehmen kann.
Ansonsten muss man dieses sehr umständlich über diese CLASS Sachen bauen.
Könntest du diese bereit stellen mit einer kleinen Anleitung?
Danke im voraus
Gruß
Hallo,
ich hätte ebenfalls großes Interesse an einem alternativen Modul. ECMD läuft bei mir nicht sehr stabil.
schöne Grüße
Jo
Hallo!
Dem schließe ich mich an, das Modul kommt mir gerade recht, meine bisherige Implementierung läuft zwar, ist aber noch recht rudimentär. Eine kurze Anleitung wäre top. Schonmal danke für die Mühe!
Gruss
Sven
Gesendet von iPhone mit Tapatalk
Ich habe mir inzwischen auch ein modul geschrieben. allerdings lese ich die vom ebusd erkannten csv befehle direkt aus dem ebusd aus ( option dumpconfig). anschliessen werden diese sortiert verarbeitet und als neue datei mit zusaetzlichen parameter fuer postproc und timer abgespeichert. somit kann man die parameter dauerhaft anpassen. ist bereits eine datei vorhanden werden neue befehle ergaenzt. anschliessen wird eine ebus.cfg datei und auch timerdefinitionen erstellt.
ich bin noch ein bisschen am testen und verfeinern. der aktuelle stand scheint aber schon zu gehen.
ich plane noch die postproc anweisungen passen zum datentyp der antwort zu generieren. werde aber den jetzigen stand auch demnaechst hier zu veroeffentlichen.
Leute, das ist alles schön und gut. Aber m.E. muss dabei eine gewisse Abstraktion stattfinden, denn es macht wenig Sinn, jeden Befehl des Vaillant-Controllers von FHEM aus steuern zu wollen. Das ist auch nicht sicher genug.
Also noch einmal der Vorschlag, der schon lange im Raum steht:
1. Einigung auf ein "Standard"-Set von Befehlen, diese sind von einem Frontend-Device aus absetzbar
2- Verschiedene Backends, die nichtnur EBUS, sondern auch andere Heizungssysteme steuern können.
LG
pah
gedacht war es fuer mich auch nur um erstmal alle lesebefehle mitit den antworten zu sehen. welche befehle ich leztendlich benoetige sehe ich doch erst wenn ich mir alle angeschaut habe. nicht benoetigte kann ich dann in dem generiertem dumpconfig file auskommentieren oder noch sicherer in den csv dateien loeschen.
ECMD funktioniert! -> mMn ist es für Ebusd suboptimal.
@pah
könntest Du bitte 1) und 2) näher spezifizieren? Hintergrund: Ich könnte das eine oder andere in die Entwicklung einfließen lassen und einen ersten Wurf hier bereitstellen.
Zitat1. Einigung auf ein "Standard"-Set von Befehlen, diese sind von einem Frontend-Device aus absetzbar
Der Standard Set ist durch die CSV Files definiert, der lässt sich mit den Boardmitteln ermitteln "ebusctl find (-r(get)/-w(set))". - das wäre mein Ansatz.
Im Detail: Set der möglichen Abfragen über "ebusd" ermitteln, den Rest über default FHEM Mechanismen "notifies/ats"? - damit überlebt man, hoffentlich, ein paar Updates (sowohl Ebusd als auch FHEM).
Zitat2- Verschiedene Backends, die nichtnur EBUS, sondern auch andere Heizungssysteme steuern können.
Siehe Punkt 1. Ansatz ist Ebusd Tools/Mittel zu nutzen, sonst wird es problematisch? Bitte in kleinen Schritten denken - sonst wird das nichts.
Was genau meinst du mit "Backends"? Im konkretem Fall reden wir doch von Ebusd oder? Ich vermute Du meinst DevIo "telnet, ebusctl, etc."?
Vielen Dank und Grüße
Arthur
Hallo,
hier eine kurze Beschreibung zum Modul 98_GAEBUS.pm:
- 98_GAEBUS.pm nach /opt/fhem/FHEM kopieren
- nun bekommt man eine Beschreibung wenn man "help GAEBUS" in der telnet session oder im Eingabefenster des GUI eingibt
- die .csv files aus /etc/ebusd nach /opt/fhem/ebusd kopieren
- define ebus GAEBUS <servername>
- jetzt kann man alle Variablen aus dem .csv files mit "get" interaktiv abfragen (Ergebnis als popup)
- mit "set" kann man (über den Umweg eines Attributes) readings definieren, die dann zyklisch abgefragt werden
@pah: Als Abstraktionsebene sehe ich meine Implementierung Readings über den Umweg eines Attributes zu definieren. D.h. nicht alle Werte werden permanent abgefragt sondern nur diejenigen für die ein "lokaler" name für das reading definiert wurde. Werte die sich nicht permanent ändern frage ich z.B. nur alle 10 Zyklen ab (suffix ":10" beim Namen des readings). Analog möchte ich das auch zum schreiben implementieren.
Die Idee die Variablennamen statt aus den .csv files direkt vom ebusd zu bekommen finde ich sehr gut.
Grüße
Andy
Vier kurze Anfänger-Fragen zur Platine (von zentis666): ;)
- Wo ist bei der grauen eBus Anschlussklemme der + Pol? Oder ist die Schaltung verpolungssicher?
- Muss TX/RX zum USB Modul 1:1 verbunden sein oder muss es gedreht werden? (Platine TX->USB RX / Platine RX -> USB TX)
- Ich vermute für den Vorwiderstand der "Status" LED (zwischen PIN4 und PIN7 am 4011) muss es nicht exakt 1k Ohm sein? (Hab nur 920 Ohm da :-)
- Die Platine zieht die Versorgungspannung von den 5V die vom USB Modul kommen? (muss also angeschlossen sein?)
Bitte mal einen Blick auf meinen Originalschaltplan im Wiki werfen. Ebus Anschluss ist verpolungssicher. Nix gedreht. Ja.
LG
pah
EBUS Stabilität
Hallo Zusammen,
die EBUS-Anbindung an eine Vaillant VSC S 196/2-C 200 über den Ebus-Koppler USB von eservice habe ich nun seit ca. 6 Monaten in Betrieb. Es läuft auch recht ordentlich.
Probleme habe ich bei der Stabilität. In unregelmäßigen Abständen (mal 7 Tage, mal 1 Tag, mal 3 Tage) sammelt mein FHEM (extra RasPi) keine Daten mehr. Wenn ich in dieser Situation den EBUS-RasPi komplett per Hand neu starte (Shutdown -r) und in FHEM den EBUS wieder verbinde, läuft es wieder.
In der Störungssituation verhält sich der EBUS-RasPi folgend:
pi@raspberrypi / $ sudo etc/init.d/ebusd status
Ergebnis:
[ ok ] ebusd is running.
Wenn ich nun den Befehl:
pi@raspberrypi / $ ebusctl read OutsideTemp
absetzte, passiert ca. 3 Minuten nix und dann kommt:
recv: Connection reset by peer
Ebusd-Version ist:
pi@raspberrypi / $ ebusd -V
ebusd 1.1.0
auch die Überprüfung der Prozesse (aus /etc/watchdog.d/ebusd)
ps -ef | grep ebusd.*USB0 | grep -v grep
bringt:
root 2112 1 13 Aug13 ? 08:44:34 /usr/bin/ebusd -d /dev/ttyUSB0
Nun nun bin ich am Ende. Wie soll der Watchdog auf dem EBUS-RasPi feststellen, dass mit dem EBUSD etwas nicht funktioniert, wenn der Prozess läuft.
Hat einer von euch eine Idee, wo ich weiter suchen kann ?
Gruß
Thomas
Hallo Thomas,
schau doch mal in die /var/log/syslog. Evtl. verschwindet dein USB device (/dev/ttyUSB0) kurz.
Auch ein "fuser /dev/ttyUSB0" wäre interessant.
Grüße
Andy
Hallo Andy,
danke für deine Antwort.
fuser:
pi@raspberrypi / $ sudo fuser /dev/ttyUSB0
/dev/ttyUSB0: 2112
/var/log/syslog.1 vom 15.08.2015 (sieht für mich vollkommen normal aus):
Aug 15 06:25:08 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 15 07:17:01 raspberrypi /USR/SBIN/CRON[2870]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 08:17:01 raspberrypi /USR/SBIN/CRON[2883]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 09:17:01 raspberrypi /USR/SBIN/CRON[2895]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 10:17:01 raspberrypi /USR/SBIN/CRON[2907]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 11:17:01 raspberrypi /USR/SBIN/CRON[2920]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 12:17:01 raspberrypi /USR/SBIN/CRON[2930]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 13:17:01 raspberrypi /USR/SBIN/CRON[2944]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 14:17:01 raspberrypi /USR/SBIN/CRON[2956]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 15:17:01 raspberrypi /USR/SBIN/CRON[2967]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 16:17:02 raspberrypi /USR/SBIN/CRON[2978]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 17:17:01 raspberrypi /USR/SBIN/CRON[2991]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 18:17:01 raspberrypi /USR/SBIN/CRON[3003]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 19:17:01 raspberrypi /USR/SBIN/CRON[3014]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 20:17:01 raspberrypi /USR/SBIN/CRON[3028]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 21:17:01 raspberrypi /USR/SBIN/CRON[3041]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 22:17:02 raspberrypi /USR/SBIN/CRON[3052]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 15 23:17:01 raspberrypi /USR/SBIN/CRON[3066]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 00:17:01 raspberrypi /USR/SBIN/CRON[3078]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 01:17:01 raspberrypi /USR/SBIN/CRON[3090]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 02:17:01 raspberrypi /USR/SBIN/CRON[3104]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 03:17:01 raspberrypi /USR/SBIN/CRON[3118]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 04:17:01 raspberrypi /USR/SBIN/CRON[3286]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 05:17:01 raspberrypi /USR/SBIN/CRON[3483]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 06:17:01 raspberrypi /USR/SBIN/CRON[3494]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 06:25:01 raspberrypi /USR/SBIN/CRON[3504]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
/var/log/syslog vom 16.08.2015 (die Watchdog-Einträge habe ich heute erzeugt, da ich den Watchdog ein paarmal neu gestartet habe):
Aug 16 06:25:14 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 06:25:15 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1927" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Aug 16 06:47:01 raspberrypi /USR/SBIN/CRON[3628]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ))
Aug 16 07:17:01 raspberrypi /USR/SBIN/CRON[3639]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 08:17:01 raspberrypi /USR/SBIN/CRON[3651]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 09:17:01 raspberrypi /USR/SBIN/CRON[3661]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 10:17:01 raspberrypi /USR/SBIN/CRON[3671]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 11:17:01 raspberrypi /USR/SBIN/CRON[3827]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 11:59:41 raspberrypi watchdog[3968]: starting daemon (5.12):
Aug 16 11:59:41 raspberrypi watchdog[3968]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 11:59:41 raspberrypi watchdog[3968]: ping: no machine to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: file: no file to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: pidfile: no server process to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: interface: no interface to check
Aug 16 11:59:41 raspberrypi watchdog[3968]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 11:59:41 raspberrypi watchdog[3968]: cannot open /dev/watchdog (errno = 13 = 'Permission denied')
Aug 16 11:59:51 raspberrypi watchdog[2240]: stopping daemon (5.12)
Aug 16 11:59:51 raspberrypi kernel: [226953.010231] watchdog stopped
Aug 16 11:59:56 raspberrypi watchdog[4000]: starting daemon (5.12):
Aug 16 11:59:56 raspberrypi watchdog[4000]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 11:59:56 raspberrypi watchdog[4000]: ping: no machine to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: file: no file to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: pidfile: no server process to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: interface: no interface to check
Aug 16 11:59:56 raspberrypi watchdog[4000]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 11:59:56 raspberrypi watchdog[4000]: cannot set timeout 60 (errno = 22 = 'Invalid argument')
Aug 16 11:59:56 raspberrypi watchdog[4000]: hardware wartchdog identity: BCM2708
Aug 16 12:00:28 raspberrypi watchdog[4000]: stopping daemon (5.12)
Aug 16 12:00:28 raspberrypi kernel: [226989.967988] watchdog stopped
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: starting watchdog keepalive daemon (5.12):
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: int=5 alive=/dev/watchdog realtime=yes
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: hardware wartchdog identity: BCM2708
Aug 16 12:00:34 raspberrypi wd_keepalive[4049]: unable to disable oom handling!
Aug 16 12:01:13 raspberrypi wd_keepalive[4049]: stopping watchdog keepalive daemon (5.12)
Aug 16 12:01:13 raspberrypi kernel: [227035.131621] watchdog stopped
Aug 16 12:01:19 raspberrypi watchdog[4101]: starting daemon (5.12):
Aug 16 12:01:19 raspberrypi watchdog[4101]: int=5s realtime=yes sync=no soft=no mla=24 mem=0
Aug 16 12:01:19 raspberrypi watchdog[4101]: ping: no machine to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: file: no file to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: pidfile: no server process to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: interface: no interface to check
Aug 16 12:01:19 raspberrypi watchdog[4101]: test=none(10) repair=none(0) alive=/dev/watchdog heartbeat=none temp=none to=root no_act=no
Aug 16 12:01:19 raspberrypi watchdog[4101]: cannot set timeout 60 (errno = 22 = 'Invalid argument')
Aug 16 12:01:19 raspberrypi watchdog[4101]: hardware wartchdog identity: BCM2708
Aug 16 12:17:01 raspberrypi /USR/SBIN/CRON[4137]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 13:17:01 raspberrypi /USR/SBIN/CRON[4191]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 16 14:17:01 raspberrypi /USR/SBIN/CRON[4203]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sieht für mich nicht so aus, als ob das System die USB-Verbindung verloren hätte.
Was noch komisch ist, dass die /var/log/ebusd.log aktuelle Werte enthält:
2015-08-16 15:15:00.097 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:02.091 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:15:04.105 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:08.107 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:10.114 [update notice] unknown MS cmd: 1008b5040100 / 0a0310151516080715f00e
2015-08-16 15:15:10.337 [update notice] unknown BC cmd: 10feb505020400
2015-08-16 15:15:14.111 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:18.111 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:24.116 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:28.118 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:30.136 [update notice] unknown BC cmd: 10feb516080032151516080715
2015-08-16 15:15:30.387 [update notice] unknown MS cmd: 1008b512020000 / 00
2015-08-16 15:15:34.133 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:38.133 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:40.136 [update notice] unknown MS cmd: 1008b5040100 / 0a0341151516080715f00e
2015-08-16 15:15:40.406 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:15:44.138 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:48.149 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:15:50.096 [update notice] unknown BC cmd: 10feb5160301f00e
2015-08-16 15:15:52.153 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:15:58.160 [update notice] unknown MS cmd: 1008b5110101 / 094246f00e4c580000ff
2015-08-16 15:16:00.156 [update notice] unknown MS cmd: 1008b5110102 / 05023c3c5078
2015-08-16 15:16:02.160 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:16:08.169 [update notice] unknown MS cmd: 1008b5110101 / 096054f00e52580400ff
2015-08-16 15:16:10.181 [update notice] unknown MS cmd: 1008b5040100 / 0a0311161516080715c00e
2015-08-16 15:16:10.401 [update notice] unknown BC cmd: 10feb505020400
2015-08-16 15:16:12.193 [update notice] update bc Mode QQ=10: standby
2015-08-16 15:16:18.203 [update notice] unknown MS cmd: 1008b5110101 / 097c62c00e68580400ff
Noch eine Idee ?
Gruß
Thomas
Hallo Thomas,
wenn das Problem nach dem 15.08 6:25 aufgetaucht ist ... dann deutet nichts auf ein USB Problem hin.
Aufgefallen ist mir nur, dass bei mir eine Version 1.2.0 (vom ebusd) läuft (als Debian pkg heruntergeladen und installiert).
Ich habe auch den Adapter von e-service. Erst seit ich einen HUB mit Stromversorgung dazwischen gehängt habe läuft der ebusd ohne Ausfälle.
Grüße
Andy
Hallo Andy,
danke.
Ja, das Problem ist nach dem 15.08.2015 aufgetaucht.
Das mit der Version habe ich mir auch schon überlegt, da John30 ja in der Changelog zu 1.2 ja schreibt : "notify running requests on device error".
Ein HUB mit eigener Stromversorgung habe ich auch dran.
Okay, ich glaube ich werde gleich mal auf die Version 1.2 updaten.
Danke und Gruß
Thomas
hallo zusammen,
habe neulich den eService eBus-LAN-Koppler zugelegt.
ebusd 1.2 funktioniert unter ubuntu ohne probleme. meine anlage besteht aus Wolf Gas-Therme CGB-20 kombiniert mit Wolf Solaranlage.
Die Steuerungen sind wolf BM und Wolf SM.
bin gerade dabei paar telegramme zu entziffern.
Ist da evtl. jemand schon weiter und kann mir paar templates liefern ?
besten dank im voraus
tony
Hi, hab mir jetzt das Modul 98_GAEBUS.pm installiert und bin begeistert. Auf welchen Wert muss das Attribut do_not_modify gesetzt werden, um das setzen von Werten zu verhindern?
@tonyf:
Hallo, wie hast du den eBUS-LAN-Koppler eingebunden? (cfg-File? wieso Port 5000, wo wird dies eingestellt?), magst du es beschreiben?
auf deine Frage:
Vorgehensweise bei einem neuen Heizungssystem
in: http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)
@gima84:
Hi, mir sagt 98_GAEBUS.pm nichts, woher hast du dieses Modul, was macht es?
Danke, Gerhard
Hallo,
ich glaube du hast einen Fehler im "Device specific help" gefunden.
Die attribute:
dummy
showtime
gibt es nicht.
do_not_notify und loglevel haben die standard funktion von fhem.
do_not_notify kann auf 0 oder 1 gesetzt werden.
Falls du tatsächlich "do_not_modify" meinst. Wo hast du das gefunden?
Die Version von 98_GAEBUS.pm die ich hochgeladen hat kann keine Variablen verändern.
Grüße
Andy
Zitat von: Gerhard am 20 August 2015, 11:13:21
@tonyf:
Hallo, wie hast du den eBUS-LAN-Koppler eingebunden? (cfg-File? wieso Port 5000, wo wird dies eingestellt?), magst du es beschreiben?
auf deine Frage:
Vorgehensweise bei einem neuen Heizungssystem
in: http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)
hallo Gerhard,
- in der anleitung des kopplers steht wie man diesen einichtet. auf der eservice homepage befindet sich die sw zum downloaden: Ethernet Config-Tool.
einfach den koppler ins netzwerk einhängen und die sw starten. die sw sucht das gesamte nw nach einem koppler.
wenn alles geklappt hat, erscheint dieser in der sw oberfläche - s. bild. jetzt kannst du die ip und kommunikationsport einrichten, dieses habe ich bei default 5000 gelassen.
achtung: das ist nicht der komm port von ebusd sondern nur von dem koppler.
beim aufruf von ebusd kannst du anstelle des usb kopplers auch einen lan koppler angeben:
ebusd -f -l ALL -d 192.168.178.44:5000 -p 8888 (die ip und das komm port); hier ist auch der komm port von ebusd
- ich habe mich schon gut eingearbeitet, habe auch schon paar telegramme entschlüsselt. leider noch schwierigkeiten die daten ins cvs zu übernehmen - wolf spezifisch, wäre super wenn einer tips geben kann, bsp:
SM -> alle
71 FE 50 17 10 00 01 FA 01 FB 02 00 80 00 80 00 80 00 80 00 80 D9
^ 01 = Solarpumpe läuft ?
^ unbekannt
^ ^ Kollektortemperatur
^ ^ WW Solar Temperatur
gruss
tony
Hallo tonyf,
danke für die Erklärung!!
In diesem Thread auf Seite 50 ist ein Beitrag von john30: « Antwort #737 am: 14 Mai 2015, 22:42:27 » über deine Frage.
Ich habe eine Vaillant Anlage, und somit kenne ich mich mit Wolf nicht aus, sorry.
https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf (https://github.com/john30/ebusd-configuration/tree/master/ebusd-0.5.x/wolf)
https://github.com/john30/ebusd-configuration/tree/master/libebus-0.2.x/wolf (https://github.com/john30/ebusd-configuration/tree/master/libebus-0.2.x/wolf)
Gerhard
@ Gerhard: 1 Seite vorher gibts das zum Download (#900)
@ jamesgo: Wer lesen kann ist klar im Vorteil :-) Sorry für die blöde Frage.
Hi tonyf,
ich habe eine WOLF CGB-2-20 mit BM2, Solarmodul SM1 und Aussenfühler. Ein wenig habe ich schon hinbekommen.
Ich hänge meine Dateien einfach mal an. User mit Wolf-Anlagen scheinen hier im Forum nicht so viel unterwegs zu sein. Ich habe die Daten aus den Beispielen aus dem GIT genommen und ein wenig modifiziert und die Kommentare ergänzt. Außerdem habe ich die Konfigurationsdateien getrennt, um es für mich übersichtlicher zu halten. (Die csv Dateien müssen in das Konfigurations-Verzeichnis)
Soweit ich die Sache verstanden habe, haben die Master bei mir folgende Adressen :
SM1 - 71
BM2 - 30
HCM2 (Regler) - F1
GBc-e (Feuerung) - 03
Mit der Konfiguration kann ich folgendes auslesen:
Außentemperatur
Außentemperatur gemittelt
Vorlauftemperatur
Rücklauftemperatur
Warmwassertemperatur
Datum
Zeit
Wochentag
Kollektortemperatur
Wassertemperatur am Wärmetauscher
Solarpumpe an/aus
Grüße
druschba
Hallo
hab auch eine Wolf Anlage, habe auch den Bausatz hier aus dem Thread, liegt aber noch in der Kiste weil ich einfach keine Zeit finde...
Werde mich sicher aber in den Wintermonaten damit beschäftigen..
super danke druschba ..
jetzt sind zwar mehr telegramme lesbar aber auch mehr fragen - s.bild.
ich glaube mir fehlt noch das knowhow wie die daten ins csv zu übertragen sind.
kannst du mir netterweise noch die erste kommentar zeile im csv ganz genau erklären:
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field1,part (m;s),type / templates,divider / values,unit,comment,field2,part (m;s),type / templates,divider / values,unit,comment,field3,part (m;s),type / templates,divider / values,unit,comment,field4,part (m;s),type / templates,divider / values,unit,comment,field5,part (m;s),type / templates,divider / values,unit,comment,field6,part (m;s),type / templates,divider / values,unit,comment,field7,part (m;s),type / templates,divider / values,unit,comment,field8,part (m;s),type / templates,divider / values,unit,comment
wäre super anhand eines beispiels was du bereits eingetragen hast:
b,,solar,solartemperaturen,,,5017,,pumpe,,UCH,0xbc=off;0xbd=on,,Solarpumpe,nix,,HEX,,,,kollektortemp,,temp,,,Kollektortemperatur,wwsolartemp,,temp,,,WW Solartemperatur,,,,,,,,,,,,,,,,,,,,,,,,
besten dank & gruss
tony
Mein Tipp: Nicht die CSV von Hand editieren. Sondern importieren in Open Office, dort editieren und dann wieder exportieren.
LG
pah
vielen dank Professor ..
super tipp, jetzt sieht das ganze etwas humaner aus.
schuld daran war ms office 2013 (evtl. habe ich was falsches eingestellt) - es sah wie text datei aus - s. bild.
mit open office ist es jetzt schön tabellarisch.
danke & gruss
tony
Hallo an alle!!
Ich bin neu unerfahren und möchte mir eine Lösung zu meinem Problem suchen.
Ich habe eine Vailant ecoTec exclusiv VC206 mit com DIALOG2.0 und möchte aus unterschiedlichen Gründen von dieser Fernwartung befreit werden..... Da ich aber dennoch eine Fernwartung haben möchte bin ich durch suchen auf dieses Forum gestoßen.
Ich habe mir nun schon etliches durchgelesen und versucht zu verstehen wie ich mein Projekt umsetzen könnte.
gekauft habe ich mir nun folgendes:
- Raspberry PI2; inkl. allem was zum Betrieb notwendig ist
- USB TTL Adapter
Ich habe mir nun mehrfach die Beschreibung:
http://www.fhemwiki.de/wiki/EBUS durchgelesen....
Scheitere aber dann daran bei:
- Auswahl einen Images für den Raspberry (ich möchte Ebusd und FHEM auf dem gleichem Gerät betreiben)
- externe Beschaltung für den USB TTL Konverter - brauche ich die Beschaltung??? teilweise steht das diese benötigti wird, teilweise nicht????
oder anders Herum gefragt: hat jemand ein fertiges funktionierendes Image herumliegen dass ich auf den Raspberry aufspiele und alles läuft??? Würde natürlich auf dafür zahlen!
Danke für Eure HILFE
Wieso ttl adapter? EBus hat doch keine ttl-pegel!?
Zitat von: christianh am 24 August 2015, 21:09:28
- Auswahl einen Images für den Raspberry (ich möchte Ebusd und FHEM auf dem gleichem Gerät betreiben)
Ich lasse aktuell zumindest den fhem auf einem "stinknormalen" Rasbian laufen - da sollte auch der Ebusd seinen Dienst drauf tun.
Wieso ttl adapter? EBus hat doch keine ttl-pegel!?....
was ist das sonst für ein USB Adapter mit dem ich den raspberry mit dem ebus verbinde?
http://www.fhemwiki.de/wiki/EBUS ::) ::) ::)
LG
pah
ich möchte nicht nerven aber irgendwie finde ich nur diesen: 1-Wire Adapter USB DS9490R ... und der sieht aber nicht wirklich wie in der Abbildung http://www.fhemwiki.de/wiki/EBUS aus...
... muss ich dann noch eine externe Beschaltung machen?
Lies Dir die Seite nochmal komplett durch. Dort findest Du Antworten.
schöne Grüße
Jo
Vielleicht bin ich zu blöd oder ich übersehe einfach jedesmal irgendwo einen Satz...
Als erstes steht: Eigenbau... kaufe einen Adapter mit FTDI chip und hänge eine externe Beschaltung lt. Abbildung dazu...
... wenn aber die externe schaltung dabei ist (inkl. Gleichrichtung) wie kann sich der Adapter mit dem ebus unterhalten?
Falls ich da was nicht verstehe bitte ich um einen direkten link dorthin wo ich dieses Gerät kaufen kann.
Kommerzielle USB Ebus Lösung:
http://www.eservice-online.de/produkte/ebus/135/ebus-koppler-usb .... ist das der Richtige?
Ja, das ist der Richtige.
schöne Grüße
Jo
@christianh: Doch, das nervt wirklich - denn in dem Artikel steht tatsächlich alles drin.
Mein Tipp: Bei diesem Kenntnisstand auf keinen Fall einen Selbstbau versuchen, sondern das Gerät von eservice kaufen.
Ach ja: Für eine Erklärung der Schaltung habe ich keine Zeitressourcen.
LG
pah
Ich hab mir einen Adapter von eservice bestellt! Hoffe dass ich den bald bekomme, sodass ich noch in der kommenden Woche mit dem Projekt halbwegs fertig werde.
Als Vorbereitung bis der USB Adapter hier ist habe ich fhem auf den raspberry installiert und läuft auch schon.
Kann ich noch etwas vorbereiten? Oder ist es besser auf den Adapter zu warten diesen am ebus anzuschließen und dann weiter zu machen?
ZitatHierbei wird ein kommerziell für ca. 6,00 € erhältliches USB-Modul ...
Würde gerne das eBus-Interface aufbauen, finde aber das Bauteil/Fertigplatine (grün) "USB to Seriell" mit FTDI-Chip nicht.
Kann mir jemand bitte einen TIPP geben wo ich das Teil kaufen kann ? Danke. ...
Zitat von: RainerS am 27 August 2015, 20:32:47
Würde gerne das eBus-Interface aufbauen, finde aber das Bauteil/Fertigplatine (grün) "USB to Seriell" mit FTDI-Chip nicht.
Kann mir jemand bitte einen TIPP geben wo ich das Teil kaufen kann ? Danke. ...
Hier das Teil von pah:
http://forum.fhem.de/index.php/topic,29737.msg233425.html#msg233425 (http://forum.fhem.de/index.php/topic,29737.msg233425.html#msg233425)
Gruß
Arthur
Meine Güte, die Teile gibt es wirklich überall:
http://www.elv.de/mini-usb-modul-um2102-komplettbausatz.html
LG
pah
Für einen Anfänger ist Debian schon eine Herausforderung....
Ich hätte versucht EBUSD zu installieren....
Zuerst hätte ich mir die Quelle gesucht und dann eine Anleitung zur installation...
Gefunden habe ich das:
https://github.com/john30/ebusd/wiki/1.-Build-and-install
Sobald ich das mache:
pi@raspberrypi ~/ebusd $ ./autogen.sh
./autogen.sh: 7: ./autogen.sh: autoreconf: not found
kann mir bitte wer helfen!
Zitat von: amunra am 27 August 2015, 20:38:26
Hier das Teil von pah:
http://forum.fhem.de/index.php/topic,29737.msg233425.html#msg233425 (http://forum.fhem.de/index.php/topic,29737.msg233425.html#msg233425)
Gruß
Arthur
@amunra: Danke Dir :D
@ Rainer. Der link funktioniert nicht mehr... File not found!
Wäre schön wenn mir wer hilft ... Und auch anschließend.
Ebusd und fhem laufen am selben raspberry - was muss ich einstellen sodass fhem vom ebusd die Daten über nimmt.... Kann ich alles von der ebus wiki über nehmen?
lade dir das fertige ebusd pkg herunter statt zu versuchen es selbst zu übersetzten:
aus https://github.com/john30/ebusd/releases/tag/v1.2.0
ebusd-1.2.0_armhf.deb
... installieren dann mit
dpkg -i ebusd-1.2.0_armhf.deb
@jamesgo danke hat super geklappt ... soll ich das nun auch mit den config datein machen?
die Konfigurationen kommen als Zip-File - kein pkg.
Nach /etc/ebusd werden nur die kopiert, die zur Heizung passen.
ich glaube ich habe nun den dämon am laufen. wie kann ich nun kontrollieren ob die daten richtig vom USB koppler gelesen werden?
@jamesgo die Konfigurationen kommen als Zip-File ..... muss ich die laden (Vailant ecoTec exclusiv VC206)?
Muss ich bai.scv von https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de nehmen? und wie bekomme ich die in das richtige verzeichnis (welches)
2015-08-28 20:09:32.611 [main error] error reading config files: ERR: end of inp
ut reached, /etc/ebusd/broadcast.csv:4
2015-08-28 20:09:32.611 [main notice] found messages: 0 (0 poll, 0 update)
2015-08-28 20:09:32.639 [bus notice] signal acquired
2015-08-28 20:09:38.734 [bus notice] new master 10
2015-08-28 20:09:38.734 [update notice] unknown MS cmd: 1050b505021800 / 00
2015-08-28 20:09:40.476 [update notice] unknown MS cmd: 1050b505023001 / 0101
kann mir da wer weiterhelfen?
NACHTRAG!!!
habe ebusd am laufen; diverse csv datein (bei mir sinds die Bai,
470,_templates) ins etc/ebusd verzeichnis kopiert und bekomme bei ebusd
--checkconfig lauter fehlermeldungen wie diese:
Error reading "/etc/ebusd/BAI00.csv" line 5456 field 1 value "</html>":
ERR: end of input reached
Erroneous item is here:
"</html>"
wie kann ich überprüfen ob ebusd mit den scv datein richtig
funktioniert?? oder kann ich das erst wenn ich FHEM installiert habe?
also die csv datein im raw Format!!
dann hab ich noch folgende meldungenen:
ebusd --checkconfig
2015-08-29 22:56:23.055 [main notice] Performing configuration check...
Error reading "/etc/ebusd/_templates.csv" line 1 field 3 value "divider / values": ERR: invalid numeric argument
Erroneous item is here:
"# template name","type / templates","divider / values","unit","comment"
^
Error reading "/etc/ebusd/bai.csv" line 1 field 5 value "[QQ]": ERR: invalid numeric argument
Erroneous item is here:
"# type (r[1-9]","circuit","name","[comment]","[QQ]","ZZ","PBSB","[ID]","field1","part (m/s)","datatypes/templates","divider/values","unit","comment","","","","","","","","","","","",""
^
2015-08-29 22:56:23.137 [main notice] found messages: 338 (0 poll, 0 update)
Hallo christianh!
Ich weiß jetzt nicht woher du die Templates hast, ich nehme an von deinem geposteten Link von John. Wenn du zum Beispiel auf der _templates bist, dann klicke doch im rechten Bildbereich auf "Raw" und schaue dir dann das Ergebnis an.
# template name,type / templates,divider / values,unit,comment
#ebus specification types:,,,,
cntstarts,BCD:3,,,Anlaufzähler
cntminutes,BCD,,min,Betriebsstunden
cnthours,BCD:3,,h,Betriebsstunden
......
das sollte so ausschauen. Du kannst den gesamten Inhalt dieser "Raw" Anzeige kopieren und neu auf /etc/ebusd als _templates.csv speichern. Die Fehler sollten dann weg sein. Als Editor verwende ich persönlich PSpad, da der die Linux konformen Einstellungen beherrscht und direkt per FTP speichern kann (sofern die IP eingerichtet ist).
Bitte die Dateien mit keinem normalen Notepad o.ä. bearbeiten, oder mache es so wie es pah vorgeschlagen hat.
Checke deine Dateien nochmals, dann wird es klappen. Ich habe zusätzlich noch die broadcast, scan und common im Verzeichnis.
LG
Man kann die CSV (Comma Separated Value) Dateien nicht mit dem Kontextmenü ("rechte Maustaste") speichern - dann kommt der HTML-Code mit hinein.
Die CSV-Dateien sollte man auch auf keinen Fall direkt bearbeiten, sondern mit Open Office aus OO Calc Dateien (Endung .ods) nach CSV exportieren. Sehr viel übersichtlicher.
LG
pah
ja das wars!!
alles als zipdatei auf den raspberry extrahiert und an die passende stelle kopiert....
pi@raspberrypi /var/log $ ebusd --checkconfig
2015-09-03 22:09:14.637 [main notice] Performing configuration check...
2015-09-03 22:09:14.735 [main notice] found messages: 398 (0 poll, 9 update)
denke das schaut nun gut aus!
Ich habe folgende datein
pi@raspberrypi /etc/ebusd $ ls
470.csv bai.csv broadcast.csv ebusd.log _templates.csv v61.csv
und bekomme nun einen neuen fehler.... aus der
2015-09-03 22:00:27.661 [update notice] unknown MS cmd: 1050b51303041f00 / 0a1f$
2015-09-03 22:00:27.814 [bus error] scan 6c failed: ERR: read timeout
2015-09-03 22:00:28.359 [bus error] scan 7d failed: ERR: read timeout
2015-09-03 22:00:28.852 [bus error] scan 8a failed: ERR: arbitration lost
2015-09-03 22:00:29.060 [bus error] scan 93 failed: ERR: read timeout
2015-09-03 22:00:29.605 [bus error] scan 9d failed: ERR: read timeout
2015-09-03 22:00:30.097 [bus error] scan a8 failed: ERR: arbitration lost
teilweise kann ebsud dann was entschlüsseln....
2015-09-03 22:06:12.766 [update notice] update broadcast outsidetemp QQ=10: 15.$
2015-09-03 22:05:53.738 [update notice] update broadcast vdatetime QQ=10: 22:15$
aber ansonsten steht da immer
2015-09-03 22:05:36.658 [update notice] unknown MS cmd: 1050b505021800 / 00
2015-09-03 22:05:38.672 [update notice] unknown MS cmd: 1050b505023001 / 0101
2015-09-03 22:05:40.723 [update notice] unknown MS cmd: 1008b5110101 / 09343490$
2015-09-03 22:05:41.376 [update notice] unknown MS cmd: 1050b51303041f00 / 0a1f$
2015-09-03 22:05:42.717 [update notice] unknown MS cmd: 1050b505053cc501c501 / $
2015-09-03 22:05:42.974 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2015-09-03 22:05:43.263 [update notice] unknown MS cmd: 1050b51303041300 / 0a13$
2015-09-03 22:05:44.686 [update notice] unknown MS cmd: 1050b5040137 / 0200ff
2015-09-03 22:05:44.975 [update notice] unknown MS cmd: 1008b5100900000060ffff0$
2015-09-03 22:05:46.663 [update notice] unknown MS cmd: 1050b505021800 / 00
2015-09-03 22:05:48.724 [update notice] unknown MS cmd: 1050b505023001 / 0101
beim befehl ebusctl kommt dies:
pi@raspberrypi /var/log $ ebusctl scan result
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0420;1403
26;Vaillant;47000;0420;1403
50;Vaillant;V6100;0418;1902
muss ich noch eine andere datei nehmen um alles zu entschlüsseln (oder zumindest 50%)?
Erstens ist da nichts "verschlüsselt".
Und zweitens sagt ebusd doch ganz genau, was los ist: 10-50-b5-05-02-18-00 .... ist ein Kommando von der Steuerung = Gerät 10 an Gerät 50 = V6100 vom Hersteller b5 = Vaillant. Das Kommando lautet 05 = "set burner operational data" und hat ein Datenpaket bestehend aus 2 Bytes 18 und 00.
Wenn das Kommando in den CSV-Dateien (und noch einmal: die sind nicht sinnvoll von Hand editierbar) nicht vorkommt, muss man es eben eintragen und herausfinden, was es tut.
LG
pah
Sollte nicht mit den eingespielten CSV Dateien der code übersetzt werden?
Von wo bekomme ich die Informationen was die Kommando bytes sind?? Z.b. 05 set burner optional data?
Das haben viele von uns hier im Forum in mühevoller Kleinarbeit herausgefunden...
Nämlich durch Lesen der Daten und Vergleich mit dem, was die Geräte dann tun.
In die 05er Kommandos würd eich mich übrigens nicht einmischen - die gehen von der Steuerung an die anderen Geräte.
Wichtig ist, die Register etc. der Steuerung lesen und setzen zu können. Damit überwacht und steuert man die Heizung.
Und auch nochmal der Tipp: Niemals versuchen, die CSV-Dateien zu bearbeiten - immer mit Open Office und dann exportieren.
LG
pah
OK die 05er lass ich links liegen - brauch ich auch nicht. Für mich wäre wichtig die Temperatur (Vorlauf Beziehungsweise Raumtempatur) anschließend in fhem ändern zu können.
Ich war bisher der Meinung ebusd muss die binären Daten der vaillant Geräte in lesbaren Text umwandeln, sodass diese in fhem übernommen werden können.
Falls ich falsch liege bitte ich um Berichtigung.
Kann ich nun das Beispiel aus der fhem wiki nehmen und die Daten in fhem übernehen sodass ich die Raumtemperatur steuern?
Zitat von: jamesgo am 19 Juli 2015, 09:04:50
Hallo,
hier eine kurze Beschreibung zum Modul 98_GAEBUS.pm:
[...]
Grüße
Andy
Hallo,
da nun wohl wieder die kältere Jahreszeit beginnt, hätte ich auch gerne Zugriff auf meine Heizung. Da ich mit ECMD Probleme habe (FHEM-Absturz wenn device nicht verfügbar), würde ich gerne dieses Modul mal ausprobieren. Kann mir jemand sagen, der es verwendet, was passiert, wenn der Rechner, auf dem der ebusd läuft, plötzlich ausfällt? Idealer Weise in einer Konfiguration, bei der 10-20 Parameter regelmäßig aktualisiert werden.
Danke!
schöne Grüße
Jo
Bei mir läuft alles stabil, uptime_text 50 days, 06 hours, 50 minutes
Das Register -c hc 3300 liefert 3 Datenbytes (Felder). Da bei mir der Heizkreis auf HK2 ist, benötige ich das 2. Byte (1. Byte HK1 ist der Brennerkreis)
ebusctl write -h 26b509030d3300 031e201e (15;16;15)
Ich habe daher den csv-Eintrag erweitert
r;w,,TempDesiredLow,Absenksollwert,,,,"3300",,,temp1;temp1;temp1,,,
ebusctl read -f -c hc TempDesiredLow 15.0;16.0;15.0
ebusctl read -f -c mc TempDesiredLow 15.0 (dieser csv-Eintrag ist noch unverändert)
Da ich das 2. Datenfeld verändern möchte versuche ich zu schreiben
usage: write [-c] CIRCUIT NAME [VALUE[;VALUE]*]
ebusctl write -c hc TempDesiredLow 15.0;17.0* und erhalte
ERR: end of input reached -bash: 17.0*: Kommando nicht gefunden.
oder
ebusctl write -c hc TempDesiredLow 15.0* ERR: invalid numeric argument
ebusctl write -c hc TempDesiredLow 15.0 ERR: end of input reached
Was mache ich falsch? Das Semikolon macht wohl Probleme. Muss ich die hex-Schreibweise benutzten?
Verwende: ebusctl of ebusd 1.1.0
Das Schreiben von Registern mit nur einem csv-Datenfeld funktioniert
ebusctl write -c ui RoomTempHoliday 16.0 done. Klappt auch über fhem.
Ganz toll wäre es, wenn man mit Feld-Index, wie beim Lesen, schreiben könnte.
ebusctl read -c hc TempDesiredLow temp1.1 17.0 (Die Komplexität ist mir klar.)
Du hast in der CSV-Datei angegeben, dass 3 Parameter verwendet werden sollen. Ich vermute deshalb, dass write auch genau 3 Parameter erwartet, also z.B.
ebusctl write -c hc TempDesiredLow 15.0;17.0;15.0
[VALUE[;VALUE]*] bedeutet, dass man optional mindestens einen Wert angeben kann; also z.B. 1.0 oder 1.0;2.0;3.0;4.0. Der Stern gehört zur Beschreibung und ist nicht Bestandteil des Wertes.
Hallo Jo,
>>98_GAEBUS.pm ...
>>
>>Kann mir jemand sagen, der es verwendet, was passiert, wenn der Rechner, auf dem der ebusd läuft, plötzlich ausfällt?
Der Socket zum ebusd bleibt normalerweise permanent offen. Fällt der Rechner mit dem ebusd aus gibt es einen Fehler beim Lesen und es wird bei nächsten Lesen versucht den Socket neu aufzubauen.
Falls nun der Rechner noch erreichbar ist, aber der Prozess fehlt kommt ein ganz kurzer timeout zum Tragen. Ich bin mir aber nicht sicher was passiert, falls die IP nicht mehr errechbar ist.
Ich werde das heut abend mal ausprobieren und berichten.
Grüße
Andy
Sehr gut, danke! Werde das Modul in den kommenden Tagen auch mal testen.
schöne Grüße
Jo
@Christian.
Hatte ich bereits alles ausprobiert. Aber es klappt mit
ebusctl w -c hc TempDesiredLow "15.0;17.0;15.0" done
Hallo zusammen,
da ich mich bisher mit dem Thema ebus nicht tiefer auseinandergesetzt habe, zukünftig aber Besitzer einer Wolf Gastherme nebst KWL seint werde, eine Frage an Euch:
Können mittels der neuen Wolf ebus / Ethernet-Schnittstelle und ebusd Daten aus den Wolf Geräten gelesen bzw. diese auch gesteuert werden?
Hier mal ein Link zur Dokumentation:
http://www.wolf-heiztechnik.de/fileadmin/content/Downloads/Montage-Bedienungsanleitungen/Regelungen/3064356_201508_ISM8i_Montage-u.Bedienungsanleitung.pdf
Angehängter Screenshot aus dem oben verlinkten pdf zeigt eine Beispielkommunikation.
Viele Grüße & Danke
xray
Hallo,
ich habe heute das Modul 98_GAEBUS.pm in den Contrib-Zweig von FHEM eingecheckt.
Neu ist folgendes:
- event-on-change-reading wird nun unterstützt
- geänderte Timeouts beim Warten auf Antwort vom ebusd
- nach Verbindungsabbruch zum ebusd wird das Abfragen von readings nach zwei erfolglosen Versuchen aufgegeben
- ich habe mit einer Implementierung für writes angefangen. Dies ist aber noch nicht fertig
@Jojo11: nach einem Verbindungsabbruch zum ebusd verhindert die Variable NEXT_OPEN dass der Socket innnerhalb 60 Sekunden wieder geöffnet wird. Zusätzlich werden in der Schleife nur zwei "reads" versucht und danach abgebrochen.
Somit sollte ein Ausfall des ebusd (bzw. des Systems auf dem er läuft) nur minimale Auswirkung auf fhem haben und es sollte zu keinem "hängenbleiben" kommen.
Grüße
Andy
Super, danke! Habe es (die alte Version) gerade mal eingebunden. Läuft soweit schon mal. Sobald ich Zeit finde werde ich die einzelnen Werte einbinden und ein wenig damit experimentieren. Meine csv's sind auch noch nicht perfekt ::)
schöne Grüße
Jo
Zitat von: jamesgo am 09 September 2015, 12:36:16
Hallo,
ich habe heute das Modul 98_GAEBUS.pm in den Contrib-Zweig von FHEM eingecheckt.
...
Irgendwie kann ich es nicht finden. Kannst Du die Datei nochmal anhängen?
schöne Grüße
Jo
Zitat von: Jojo11 am 10 September 2015, 19:46:17
Irgendwie kann ich es nicht finden. Kannst Du die Datei nochmal anhängen?
schöne Grüße
Jo
hier (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/) liegt es doch (Dateiname: 98_GAEBUS.pm)
oder direkt Download (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/98_GAEBUS.pm?format=raw)
Ups, danke. Frage mich gerade, warum ich auf github suche :-[^-^
schöne Grüße
Jo
Hallo,
seit fast 2 Jahren nutze ich jetzt FHEM zu Steuerung von Thermostaten, Rolladen und Licht.
Jetzt habe ich heute durch Zufall festgestellt, dass Ihr hier auch die Heizung mit einbindet.
Bevor ich mir jetzt den Rasperry und den Koppler bestelle, zwei Fragen:
- Ich habe eine Vaillant calormatic 630 mit EBUS. Gibt es damit schon Erfahrungen oder nutzen die Vaillant Steuerung alle gleiche/ähnliche Steuerbefehle
- Für mich kommt nur ein eservice-Koppler in Frage. Was empfehlt Ihr, LAN oder USB ... LAN wäre mir wegen der Entfernung zwischen Heizung und Steuerung lieber.
Viele Grüße,
Volker
ZitatIch habe eine Vaillant calormatic 630 mit EBUS. Gibt es damit schon Erfahrungen oder nutzen die Vaillant Steuerung alle gleiche/ähnliche Steuerbefehle
Ob damit schon jemand Erfahrungen gesammelt hat, entzieht sich meiner Kenntnis. Und leider können die Befehle auch voneinander abweichen. Dann muss man eben etwas experimentieren und erst einmal mit wenigen Daten anfangen.
ZitatFür mich kommt nur ein eservice-Koppler in Frage. Was empfehlt Ihr, LAN oder USB ... LAN wäre mir wegen der Entfernung zwischen Heizung und Steuerung lieber.
Wen jemand eine Präferenz hat, ist eine Empfehlung relativ sinnlos...
Allerdings ist "Entfernung" kein Hinderungsgrund für USB - ich betreibe diverse Interfaces für FHEM in bis zu 20 m Entfernung an USB, mit einem so genannten Bus-Extender für ein paar Euro. Auch verstehe ich das Argument nicht. Dem Raspberry ist es egal, an welcher Stelle er auf dem EBUS sitzt - das kann bei der Steuerung ebenso wie bei der Heizung sein, und damit beliebig nahe an dem Buskoppler. Mein Heizungs-Raspberry sitzt direkt neben dem EBUS-Koppler auf einer Hutschiene im Keller, und spricht per WLAN mit dem FHEM-Rechner (übrigens nicht als FHEM2FHEM).
LG
pah
ZitatWen jemand eine Präferenz hat, ist eine Empfehlung relativ sinnlos...
Da habe ich meine Frage nicht präzise genug gestellt: ich meinte, welche Vor- und Nachteile es für das eine oder das andere gibt.
Wie "beschäftigt" ist der Rasperry eigentlich mit dem EBUS-Daemon. Könnte man dort auch noch FHEM laufen lassen oder ist eine Trennung notwendig?
Viele Grüße,
Volker
Zitat von: Prof. Dr. Peter Henning am 11 September 2015, 04:24:16
[...] und spricht per WLAN mit dem FHEM-Rechner (übrigens nicht als FHEM2FHEM).
LG
pah
Das wiederum würde mich interessieren. Wie hast Du denn diese Kommunikation umgesetzt und warum nicht über FHEM2FHEM?
schöne Grüße
Jo
@macos: Der EBUS spuckt ziemlich viele Daten aus, weil dauernd Synchronisationssignale gesendet werden. Das führt beispielsweise dazu, dass die serielle Schnittstelle eines RPi damit überfordert ist (Emulation in Software), während der USB-Port ganz gut damit zu Recht kommt.
Ich habe keine Erfahrung mit FHEM und ebusd auf demselben RPi. Würde ich aber schon alleine aus Sicherheitsgründen trennen - wenn in meine Solarthermie der Blitz einschlägt, ist FHEM nicht gefährdet.
@Jojo11: Ganz einfach mit ECMD/ECMDDevice, so wie im Wiki beschrieben. FHEM2FHEM ist dafür viel zuviel overhead.
LG
pah
Zitat von: jamesgo am 09 September 2015, 12:36:16
Hallo,
ich habe heute das Modul 98_GAEBUS.pm in den Contrib-Zweig von FHEM eingecheckt.
Neu ist folgendes:
- event-on-change-reading wird nun unterstützt
- geänderte Timeouts beim Warten auf Antwort vom ebusd
- nach Verbindungsabbruch zum ebusd wird das Abfragen von readings nach zwei erfolglosen Versuchen aufgegeben
- ich habe mit einer Implementierung für writes angefangen. Dies ist aber noch nicht fertig
@Jojo11: nach einem Verbindungsabbruch zum ebusd verhindert die Variable NEXT_OPEN dass der Socket innnerhalb 60 Sekunden wieder geöffnet wird. Zusätzlich werden in der Schleife nur zwei "reads" versucht und danach abgebrochen.
Somit sollte ein Ausfall des ebusd (bzw. des Systems auf dem er läuft) nur minimale Auswirkung auf fhem haben und es sollte zu keinem "hängenbleiben" kommen.
Grüße
Andy
Hallo Andy,
habe das Update eingespielt und bin endlich mal zum testen gekommen.
Alle cvs Datein werden gelesen und ich kann die Werte mit GET auch abfragen.
Nun habe ich ein paar Sachen mit SET hinzugefügt, aber leider passiert dort nichts.
Der UpdateCnt zählt fleißig vor sich hin, aber es kommen keine Werte.
Bei "GET reading" steht auch nichts hinter. Ist das Normal?
Hier mal ein kleiner Auszug vom Log:
2015.09.11 16:47:53 3: ebus1: reopen
2015.09.11 16:47:53 3: GAEBUS opening ebus2 device 192.168.1.7(8888)
2015.09.11 16:47:53 3: GAEBUS device opened (ebus2)
2015.09.11 16:48:13 3: ebus2 get cmd v r~ehp~Date~Datum
2015.09.11 16:48:13 3: ebus2 execute r -f -v -c ehp Date
2015.09.11 16:48:13 3: ebus2 answer v date=11.09.2015 [Aktuelles Datum]
2015.09.11 16:48:29 3: ebus2: set r~broadcast~ident~Identifikation
2015.09.11 16:48:57 3: ebus2 execute -f -c
2015.09.11 16:48:57 3: ebus2 answer r ERR: command not found
2015.09.11 16:58:18 3: ebus2 execute -f -c
2015.09.11 16:58:18 3: ebus2 answer r ERR: command not found
2015.09.11 16:58:57 3: ebus2 get cmd v r~ehp~AccelerationTestMode~Servicezeit
2015.09.11 16:58:57 3: ebus2 execute r -f -v -c ehp AccelerationTestMode
2015.09.11 16:58:57 3: ebus2 answer v yesno=no [Schnelltest. Bei Servicezeit AN werden die Zeitschritte für das Energiebilanz-Integral von 1 min auf 1 sec umgestellt und damit die Energiebilanzierung um den Faktor 60 beschleunigt. Die Mindestlaufzeiten des Kompressors werden nicht verändert.]
2015.09.11 16:59:14 3: ebus2 get cmd v r~ehp~SourceTempInput~Quellentemperatur
2015.09.11 16:59:14 3: ebus2 execute r -f -v -c ehp SourceTempInput
2015.09.11 16:59:14 3: ebus2 answer v tempsensor=19.38 °C [Temperatur] sensor=ok [Fühlerstatus]
2015.09.11 16:59:27 3: ebus2: set r~ehp~SourceTempInput~Quellentemperatur
2015.09.11 17:05:43 3: ebus2 execute -f -c
2015.09.11 17:05:43 3: ebus2 answer r ERR: command not foundHier das List vom GAEBUS:
Internals:
CFGFN
DEF 192.168.1.7:8888 120
DevType EBUSD
DeviceAddress 192.168.1.7:8888
DeviceName ebus2
FD 114
Interval 120
NAME ebus2
NR 733
PARTIAL
STATE Connected
TYPE GAEBUS
UpdateCnt 12
Attributes:
room Heizung
r~broadcast~ident~Identifikation
r~ehp~ActualEnvironmentPowerPercentage~ActualEnvironmentPowerPercentage
r~ehp~ActualEnvironmentPower~ActualEnvironmentPower
r~ehp~SourceTempInput~Quellentemperatur
r~ehp~YieldEnvironmentEnergy~Energieertrag
userattr r~broadcast~ident~Identifikation r~ehp~ActualEnvironmentPowerPercentage~ActualEnvironmentPowerPercentage r~ehp~ActualEnvironmentPower~ActualEnvironmentPower r~ehp~SourceTempInput~Quellentemperatur r~ehp~YieldEnvironmentEnergy~Energieertrag Danke und Gruß
Denny
Hallo Denny,
damit du readings bekommst musst du den Attributen noch einen Wert geben. Dieser wird dann als Name für das Reading verwendet.
z.B.
r~ehp~ActualEnvironmentPower~ActualEnvironmentPower EnergieAktuell
Erzeugt dann ein Reading "EnergieAktuell"
Grüße
Andy
Zitat von: jamesgo am 11 September 2015, 17:14:28
Hallo Denny,
damit du readings bekommst musst du den Attributen noch einen Wert geben. Dieser wird dann als Name für das Reading verwendet.
z.B.
r~ehp~ActualEnvironmentPower~ActualEnvironmentPower EnergieAktuell
Erzeugt dann ein Reading "EnergieAktuell"
Grüße
Andy
PERFEKT, meine Rettung!
Läuft.
Freue mich schon auf den Schreibmodus!
Danke und Gruß
Denny
Zitat von: Prof. Dr. Peter Henning am 11 September 2015, 16:12:53
[...]
@Jojo11: Ganz einfach mit ECMD/ECMDDevice, so wie im Wiki beschrieben. FHEM2FHEM ist dafür viel zuviel overhead.
LG
pah
Ok, klar. Das geht natürlich auch. Habe leider mit ECMD so ein paar Problemchen, aber das neue Modul GAEBUS sieht ja vielversprechend aus.
schöne Grüße
Jo
Was für Probleme ? Bei mir läuft das astrein.
Man darf halt die Auswertung nicht mit ECMD machen, sondern muss den zurückgelieferten String in einer netten kleinen Perl-Prozedur aufbrechen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 September 2015, 19:26:16
Was für Probleme ? Bei mir läuft das astrein.
Man darf halt die Auswertung nicht mit ECMD machen, sondern muss den zurückgelieferten String in einer netten kleinen Perl-Prozedur aufbrechen.
LG
pah
Wenn mein EBUS-Kontroller aussteigt, was damals aufgrund des Defektes öfters mal der Fall war, ist mein komplettes FHEM auf dem anderen Rechner eingefroren. Selbiges passierte, wenn ich den Raspi mit ebusd einfach ausgeschaltet habe. Habe damals die Fehlersuche mangels Zeit abgebrochen - der "Fehler" ist auch nicht so trivial bzw. einfach zu finden weil sich im log nichts finden ließ.
schöne Grüße
Jo
@jamesgo
Zunächst mal Danke für das Modul GAEBUS!
Beim Setzen von Attributen (set ebus1 ...) mit Umlauten im Text kommt noch eine Fehlermeldung "invalid Parameter". Die Umlaute ( und das ß ) werden im Drop-Down-Listenfeld als ? auf einem schwarzen Hintergrund dargestellt. Der Rest funktioniert sehr gut. Ich habe zwar über GAEBUS noch nichts "produktiv", d.h. die Heizungsteuerung mit den "writes" läuft noch auf Basis ECMD.
Ich werde das Modul noch eine Zeitlang parallel einsetzen und die Stabilität im Auge behalten. Ich habe aber auch mit ECMD keine Probleme, lediglich bin ich am ebus-Raspi von Wlan auf Lan gewechselt, da mein Wlan Treiber täglich einen Reset auslöste. Gegenüber ECMD spart dein Modul einiges an Tipparbeit und erleichtert vor allem Einsteigern die Realisierung ihrer Projekte.
LG
Hallo Reinhart,
danke fürs ausprobieren, das mit den Umlauten werde ich mir anschauen.
@alle die auf "writes" warten: Heute abend habe ich eine Version engecheckt, die auch Werte setzten kann.
Hier aber nochmal eine Warnung, die pah schon öfters formuliert hat:
Werte setzen kann sich zerstörerisch auf die Anlage auswirken.
Vaillant hat sich zwar für einen "offenen" ebus entschieden, aber bestimmt nicht damit gerechnet,
dass mittels eines ebusd jeder nach belieben Befehle senden kann.
Wer vor 10 Jahren einen BIOS update gemacht hat, hat sich aus meiner Sicht auf vergleichbarem Niveau befunden.
Wenn ihr aber (so wie ich) Parameter eurer Heizungskomponenten verändern wollt, dann könnt ihr das folgendermaße machen:
- attribut "ebusWritesEnabled" auf 1 setzten
- mittels "set" ein "w~..." attribut erzeugen
- dem Attribut einen Wert geben. (ich verwende immer "set-<wert>". Damit stehen alle setzbaren Variablen untereinander.
- mit "set" kann nun ein write-Befehl an den ebusd gesendet werden
Ein Beispiel (das geht natürlich alles direkt im Web-Gui)
attr ebus1 ebusWritesEnabled 1 # danach erscheinen "w~..." parameter beim set
set ebus1 w~470 Time~Zeit # definiert ein neues Attribut (wie bei den readings)
attr ebus1 w~470~Time~Zeit set-time # nun hat das Kind einen Namen ... nämlich "set-time"
set ebus1 set-time 20:09:09 # und schon ist die Zeit meiner Heizung verstellt (... und wird von der Funkuhr wieder korrigiert)
Der Wert wird 1:1 and den ebusd weitergeben und die Antwort wird angezeigt.
Ich habe bewusst den Umstand über "ebusWritesEnabled" und den Attributen gewählt um den "ups ... das wollte ich gar nicht" Effekt zu vermeiden.
Falls Fragen oder Problem auftauchen ... einfach Melden.
Grüße
Andy
Zitat von: jamesgo am 11 September 2015, 20:18:22
Hallo Reinhart,
danke fürs ausprobieren, das mit den Umlauten werde ich mir anschauen.
@alle die auf "writes" warten: Heute abend habe ich eine Version engecheckt, die auch Werte setzten kann.
Hier aber nochmal eine Warnung, die pah schon öfters formuliert hat:
Werte setzen kann sich zerstörerisch auf die Anlage auswirken.
Vaillant hat sich zwar für einen "offenen" ebus entschieden, aber bestimmt nicht damit gerechnet,
dass mittels eines ebusd jeder nach belieben Befehle senden kann.
Wer vor 10 Jahren einen BIOS update gemacht hat, hat sich aus meiner Sicht auf vergleichbarem Niveau befunden.
Wenn ihr aber (so wie ich) Parameter eurer Heizungskomponenten verändern wollt, dann könnt ihr das folgendermaße machen:
- attribut "ebusWritesEnabled" auf 1 setzten
- mittels "set" ein "w~..." attribut erzeugen
- dem Attribut einen Wert geben. (ich verwende immer "set-<wert>". Damit stehen alle setzbaren Variablen untereinander.
- mit "set" kann nun ein write-Befehl an den ebusd gesendet werden
Ein Beispiel (das geht natürlich alles direkt im Web-Gui)
attr ebus1 ebusWritesEnabled 1 # danach erscheinen "w~..." parameter beim set
set ebus1 w~470 Time~Zeit # definiert ein neues Attribut (wie bei den readings)
attr ebus1 w~470~Time~Zeit set-time # nun hat das Kind einen Namen ... nämlich "set-time"
set ebus1 set-time 20:09:09 # und schon ist die Zeit meiner Heizung verstellt (... und wird von der Funkuhr wieder korrigiert)
Der Wert wird 1:1 and den ebusd weitergeben und die Antwort wird angezeigt.
Ich habe bewusst den Umstand über "ebusWritesEnabled" und den Attributen gewählt um den "ups ... das wollte ich gar nicht" Effekt zu vermeiden.
Falls Fragen oder Problem auftauchen ... einfach Melden.
Grüße
Andy
Da freu ich mich schon drauf!
Dann kann ich endlich die Zirkulationspumpe interaktiv ein und ausschalten.
Danke schonmal im voraus
Gruß
Denny
Hallo Denny,
das war aber eine schnelle Antwort :-)
Ich möchte dich nicht desillusionieren aber so wie die DCF die Zeit meine Heizung immer wieder korrigiert kann es sein dass ein Steuerungseingriff immer wieder überschrieben wird.
Du kannst aber bestimmt Parameter wie folgende ändern:
- Heizkurve
- Zeitprogramme (wann soll die Pumpe laufen)
- Soll-Temperaturen
- Party-Modus
- Urlaubs-Zeiten usw.
Wenn aber meine "470" dem "bai" einen Befehl schickt ... dann macht sie das immer wieder und hartnäckig.
An dieser Stelle Eingreifen zu wollen wird nicht funktionieren.
Grüße
Andy
Nochmal die Warnung etwas deutlicher: Ich rate davon ab, einen Wärmeerzeuger (z.B.Therme) und andere Anlagenkomponenten, die von einer existierenden Heizungssteuerung gelenkt werden, direkt über den EBUS zu steuern. Abgesehen vom Überschreiben der Werte (das dann z.B. im Extremfall dazu führen könnte, dass die Zirkulationspumpe 1x pro Sekunde gestartet und gestoppt wird) ist das gesamte Regelverhalten der Heizungsanlage dann undefiniert.
Alle Schreibbefehele auf den EBUS sollten nur dazu dienen, die existierende Heizungssteuerung zu beeinflussen. Das reicht auch in der Regel aus, um alle wünschbaren Parameter zu steuern.
Also:
- Lesen der Parameter von Anlagenkomponenten: ja
- Setzen der Parameter von Anlagenkomponenten: nein
- Lesen der Steuerungsparameter: ja
- Setzen der Steuerungsparameter: ja
Meine Zirkulationspumpe steuere ich nachgelagert hiermit:
http://www.fhemwiki.de/wiki/1W-WPump
LG
pah
Hallo Reinhart,
bei mir sieht das so aus wie im angehängten Screenshot. (also ok)
Kannst du mal ein "file" auf ein .csv file machen? Ist das UTF-8?
Welche Version von GAEBUS verwendest du?
Sieht das .csv file ok aus wenn du es auf der Maschine mit einem Editor anschaust?
Ich denke ich muss die Umlaute in html entities umwandeln. Würde das aber gerne testen.
Danke
Andy
@jamesgo
ich dachte auch zunächst, dass meine locale Einstellungen am Raspi nicht passen, aber die sind ok.
hier die csv, habe sie auch mit PSPad gegen gecheckt, auch der steht unter Format auf UTF-8. Im Editor sind die Umlaute alle ok.
pi@raspberry2 /etc/ebusd $ file --mime-encoding *.csv
430.csv: utf-8
bai.csv: utf-8
broadcast.csv: utf-8
und die locale am Raspi (beide , ebusd + fhem ) steht auf de_AT.UTF-8
Vielleicht passt ihm ja de_AT nicht und ich sollte auf de_DE stellen?
Die Version vom GAEBUS kann ich dir nicht sagen, aber ich habe sie vor ein paar Tagen nach deinem Post vom Server geladen.
LG
@jamesgo
Ich habe das Modul jetzt mal eingerichtet und lese damit alle 2 Minuten knapp 30 Parameter. Soweit läuft alles stabil, vielen Dank erstmal dafür!
Was mir aufgefallen ist:
- Wenn sich die csv-Dateien nur minimal ändern (Bezeichnung einer Variable z.B.), dann verschieben sich die Werte. Der betroffene Wert fällt natürlich weg bzw. erzeugt einen fehlerhaften Rückgabewert. Alle anderen Werte aber sind teilweise vertauscht. Kann das sein? Ich bin noch am experimentieren mit den Bezeichnungen der Parameter, daher ist mir das mehrmals passiert.
Weiter habe ich folgende log-Meldung regelmäßig bekommen:
2015.09.13 07:05:53.269 2: VC206 old answer 69.0
Der Wert ändert sich und entspricht einem existierenden und abgefragten Wert (Temperatur Warmwasserspeicher). Was hat diese Meldung zu bedeuten?
Schreiben von Werten habe ich noch nicht probiert.
schöne Grüße
Jo
Hallo Jo,
die .csv Dateien sind die Basis. Wenn die Parameter nach eine Änderung "weg" sind (weil Umbenannt) führt das zu Lesefehlern, bzw timeouts. Das passt auch zu den Meldungen, die dir im Log aufgefallen sind.
Bevor ich einen neuen Befehl zum ebusd schicke lese ich nochmal von dem socket. Wenn ich da was zurückbekomme bedeutet das, dass die Antwort auf die letzte Abfrage zu spät gekommen ist und nicht verarbeitet wurde. ("old message").
Wenn bei diesem ersten lesen nichts zurückkommt, der ebusd aber danach noch eine Antwort auf einen alten Befehl liefert.
Dann verschieben sich die Werte (was du auch beobachtest) und beim nächsten lesen kommt wieder ein "old message".
Änder doch mal in Zeile 749 den timeout von
my $timeout = 1.8;
in
my $timeout = 5;
Evtl. ist dein ebusd auch langsamer als meiner und der timeout zu klein (Ich verwende einen beaglebone black ... der hat 2 cores. Der "alte" Raspberry PI hat nur einen core)
Das sollte dein Problem lösen.
Grüße
Andy
Hallo Reinhart,
ich habe mal eine Version erstellt, bei der die Umlaute durch die html entities ersetzt werden. (siehe Anhang)
Ist dein Anzeigeproblem damit gelöst?
Grüße
Andy
Hallo jamesgo,
ich versuche seit gestern Abend dein Modul 98_GAEBUS.pm in den Griff zu bekommen.
So sieht meine config bisher aus:
define ebus1 GAEBUS 192.168.0.85:8888
attr ebus1 ebusWritesEnabled 0
attr ebus1 room 50_Therme
Wenn ich "get ebus1 r~430~Date~Datum" ausführe, erhalte ich auch "date=13.09.2015 [Aktuelles Datum] " zurück.
Nur wie automatisiere ich das?
Jegliche Versuche in fhem.cfg Attribute zu setzen scheitern mit Fehlermeldung.
Kannst Du mal ein kurzes Beispiel geben wie ds aussehen muss?
Danke Kawa
Hallo Kawa,
wenn du im Web UI ganz unten auf "Device specific help" klickst, dann bekommst du die Commandref zum Modul.
Gut ist dass du erst mal ohne Schreibzugriffe anfangen willst.
Im Wesentlichen:
- über "set" eine Variable auswählen, die du regelmäßig abfragen willst.
- durch klicken auf "set" ein Attribut erzeugen z.B. heist das Attribut dann "r~430~Date~Datum"
- diesem Attribut einen Wert geben. Dieser Wert ist dann der Name für dein reading, dass per default alle 300 Sekunden abgefragt wird.
Viel Erfolg
Andy
Zitat von: jamesgo am 13 September 2015, 10:17:10
Hallo Jo,
die .csv Dateien sind die Basis. Wenn die Parameter nach eine Änderung "weg" sind (weil Umbenannt) führt das zu Lesefehlern, bzw timeouts. Das passt auch zu den Meldungen, die dir im Log aufgefallen sind.
Bevor ich einen neuen Befehl zum ebusd schicke lese ich nochmal von dem socket. Wenn ich da was zurückbekomme bedeutet das, dass die Antwort auf die letzte Abfrage zu spät gekommen ist und nicht verarbeitet wurde. ("old message").
Wenn bei diesem ersten lesen nichts zurückkommt, der ebusd aber danach noch eine Antwort auf einen alten Befehl liefert.
Dann verschieben sich die Werte (was du auch beobachtest) und beim nächsten lesen kommt wieder ein "old message".
Änder doch mal in Zeile 749 den timeout von
my $timeout = 1.8;
in
my $timeout = 5;
Evtl. ist dein ebusd auch langsamer als meiner und der timeout zu klein (Ich verwende einen beaglebone black ... der hat 2 cores. Der "alte" Raspberry PI hat nur einen core)
Das sollte dein Problem lösen.
Grüße
Andy
Danke, nachdem ich timeout hochgesetzt habe, verschwindet die Meldung. Mein ebusd läuft auf einem RPi B der ersten Generation.
schöne Grüße
Jo
Hallo Jo
Prima. Dann werde ich den höheren Timeout als default übernehmen.
Grüße
Andy
Zitat von: jamesgo am 13 September 2015, 13:00:10
Hallo Kawa,
- über "set" eine Variable auswählen, die du regelmäßig abfragen willst.
- durch klicken auf "set" ein Attribut erzeugen z.B. heist das Attribut dann "r~430~Date~Datum"
- diesem Attribut einen Wert geben. Dieser Wert ist dann der Name für dein reading, dass per default alle 300 Sekunden abgefragt wird.
Viel Erfolg
Andy
Danke, ich hätte gleich fragen sollen!
Geht alles soweit.
kawa
Zitat von: jamesgo am 13 September 2015, 11:42:21
Hallo Reinhart,
ich habe mal eine Version erstellt, bei der die Umlaute durch die html entities ersetzt werden. (siehe Anhang)
Ist dein Anzeigeproblem damit gelöst?
Grüße
Andy
leider nein!
Ich nehme an, es geht um diese Stelle:
s/ä/\ä/g;
s/Ä/\Ä/g;
s/ü/\ü/g;
s/Ü/\Ü/g;
s/ö/\ö/g;
s/Ö/\Ö/g;
s/ß/\ß/g;
s/\"/\"/g;die letzte Zeile habe ich geändert weil sich mein Highlighter im PSPad hier beschwert hatte. Ich habe auch versucht ein großes A durch Doppel AA zu ersetzen, klappt auch nicht. Selbst eine Neustart des Raspi zeigt hier keine Änderung.
Ebenfalls habe ich noch ein "cat bai.csv" versucht, hier werden Umlaute richtig ausgegeben (weil ja Putty bei SSH + Telnet auf UTF-8 eingestellt ist). Generell klappen auch Umlaute in Fhem, Räume etc. kann ich problemlos mit Umlauten anlegen. Ich habe auch etwas gegoogelt, offensichtlich haben einige diese Art von Problem und dürfte wirklich UTF-8 basierend sein. Komisch nur, dass ich im Augenblick ich der einzige hier bin, der dieses Phänomen hat. Bin mir gar nicht sicher ob das überhaupt von GAEBUS kommt. Wenn das nur bei mir so ist, kann ich ja bis ich den Fehler gefunden habe die Texte in den csv vorerst ändern.
Meine Umgebung: Rasperry Pi 2 mit Rasbian
Trotzdem ein Dankeschön für deine Mühe!
LG
Hallo,
mir ist noch etwas aufgefallen. Wenn ich z.B. die Solltemperatur mit "set xxx xxx 21" über das Interface ändere (bestätigt durch "done") und unmittelbar danach mit ebusctl über die commandline den selben Parameter abfrage, ist die Änderung noch nicht umgesetzt. Erst wenn ich über das Interface mit "get xxx xxx" den Wert abfrage, ist dieser geändert, was auch über ebusctl bestätigt wird. Bedeutet das, dass eine Änderung auch nur im 2-Minuten-Intervall übertragen wird und man für eine unmittelbare Übertragung den entsprechenden Wert gleich nach dem Setzen nochmal Abrufen sollte?
schöne Grüße
Jo
Hallo Jo,
das Setzen eines Wertes wird direkt an den ebusd geschickt und das "done" ist die Antwort.
Beim Abfragen über ebusctl bekommst du einen Wert aus dem cache des ebusd.
Du musst die "-f" oder "-m 1" Option verwenden damit der read den Wert tatsächlich abfrägt.
Der "get" verwendet immer die "-f" Option. Deshalb ist der cache danach aktualisiert.
Grüße
Andy
@jamesgo
habe den Fehler jetzt gefunden, kann aber nicht genau sagen was es war.
Ich habe mit sudo die csv Files vom Fhem Raspi gelöscht und vom ebus Raspi nochmals rüber kopiert und sofort die locale Attribute kontrolliert.
Habe auch noch den Gegentest mit deiner Übersetzung gemacht und diese entfernt, dann funktioniert lustigerweise nur das "ü" nicht, der Rest klappt.
D.H. die Version die du mir gepostet hast funktioniert bei meiner Konfiguration mit der Anzeige jetzt zu 100%.
LG
Zitat von: jamesgo am 11 September 2015, 20:30:24
Hallo Denny,
das war aber eine schnelle Antwort :-)
Ich möchte dich nicht desillusionieren aber so wie die DCF die Zeit meine Heizung immer wieder korrigiert kann es sein dass ein Steuerungseingriff immer wieder überschrieben wird.
Du kannst aber bestimmt Parameter wie folgende ändern:
- Heizkurve
- Zeitprogramme (wann soll die Pumpe laufen)
- Soll-Temperaturen
- Party-Modus
- Urlaubs-Zeiten usw.
Wenn aber meine "470" dem "bai" einen Befehl schickt ... dann macht sie das immer wieder und hartnäckig.
An dieser Stelle Eingreifen zu wollen wird nicht funktionieren.
Grüße
Andy
Hallo Andy,
das ist mir schon klar was ich steuern soll und was nicht.
Jetzt ist es bei mir so, das die Warmwasser Zirkulation in der Woche nur Früh und Abends läuft.
Also wenn jemand zu Hause ist.
Wenn meine Frau jetzt aber mal einen Tag frei hat, beklagt sie sich immer das sie kein Warmwasser hat.
Nun möchte ich es über eine Perlfunktion so lösen, das man das Wochenprogramm von der Zirkulation anpassen kann.
Also auswerten was für eine Wochentag ist, Zeitprogramm in Heizung anpassen und am Abend über ein at wieder zurück setzen.
Ich denke das sollte gehen oder?
Ab wann ist die neue Version Online?
Ich denke wir sollten einen neuen Thread aufmachen, wo es direkt um GAEBUS geht oder?!?!?!?!
Danke und Gruß
Denny
Zitat von: jamesgo am 13 September 2015, 18:56:29
Hallo Jo,
das Setzen eines Wertes wird direkt an den ebusd geschickt und das "done" ist die Antwort.
Beim Abfragen über ebusctl bekommst du einen Wert aus dem cache des ebusd.
Du musst die "-f" oder "-m 1" Option verwenden damit der read den Wert tatsächlich abfrägt.
Der "get" verwendet immer die "-f" Option. Deshalb ist der cache danach aktualisiert.
Grüße
Andy
Alles klar, wieder etwas gelernt :o
Vielen Dank!
schöne Grüße
Jo
Fragen rund um das Modul 98_GAEBUS.pm nun in einem separaten Thread
http://forum.fhem.de/index.php/topic,41064.0.html (http://forum.fhem.de/index.php/topic,41064.0.html)
Zitat von: Reinhart am 13 September 2015, 17:47:28
leider nein!
Ich nehme an, es geht um diese Stelle:
s/ä/\ä/g;
s/Ä/\Ä/g;
s/ü/\ü/g;
s/Ü/\Ü/g;
s/ö/\ö/g;
s/Ö/\Ö/g;
s/ß/\ß/g;
s/\"/\"/g;
die letzte Zeile habe ich geändert weil sich mein Highlighter im PSPad hier beschwert hatte. Ich habe auch versucht ein großes A durch Doppel AA zu ersetzen, klappt auch nicht. Selbst eine Neustart des Raspi zeigt hier keine Änderung.
Ebenfalls habe ich noch ein "cat bai.csv" versucht, hier werden Umlaute richtig ausgegeben (weil ja Putty bei SSH + Telnet auf UTF-8 eingestellt ist). Generell klappen auch Umlaute in Fhem, Räume etc. kann ich problemlos mit Umlauten anlegen. Ich habe auch etwas gegoogelt, offensichtlich haben einige diese Art von Problem und dürfte wirklich UTF-8 basierend sein. Komisch nur, dass ich im Augenblick ich der einzige hier bin, der dieses Phänomen hat. Bin mir gar nicht sicher ob das überhaupt von GAEBUS kommt. Wenn das nur bei mir so ist, kann ich ja bis ich den Fehler gefunden habe die Texte in den csv vorerst ändern.
Meine Umgebung: Rasperry Pi 2 mit Rasbian
Trotzdem ein Dankeschön für deine Mühe!
LG
zunächst mal Hallo in die Runde, bin zwar nicht Neu hier, habe die gesamte Zeit mitgelesen und versucht umzusetzen - hat dank diese Thread auch super funktioniert.
Daher erstmal vielen Dank an alle Beteiligten insbesondere für den ebusd und auch für das GAEBUS Modul!!! :)
@Reinhart: Nein Du bist nicht alleine und ich wollte auch schon die Texte in der csv ändern - aber Dank jamesgo scheint das ja jetzt nicht mehr notwendig - kann leider noch nicht testen, da ich nicht zuhause bin. Melde mich sobald ich getestet habe in dem neuen Thread für GAEBUS.
LG an alle für die wirklich super Arbeit!
Mikel
Wenn wir einen Chipsatz empfehlen, wieso sollte dann ein anderer "auch i.O." sein ?
LG
pah
Nun, das ist ein sinnvolles Argument, dann sollte das auch mit demModul funktionieren - aber eine Garantie kann natürlich niemand übernehmen.
LG
pah
@john30
mir ist aufgefallen, dass die Rückgabewerte von dem Befehl "find -f" unstimmig sind.
Ich bin mir nicht sicher, ob das ein Bug ist oder ich das Ergebnis falsch interpretiere.
Es geht im speziellen um das Feld "comment" (ich nenne es "description") (Achtung: nicht zu verwechseln mit dem Feld/der Spalte [comment]) - bei diversen Einträgen entspricht der Wert im Feld "comment" mit dem Wert der in der CSV Datei hinterlegt ist.
Bei diversen Einträgen stehen jedoch Werte, die ich nicht nachvollziehen kann.
(http://up.picr.de/23133503ix.jpg)
Beispiel:
find -f ActualWeekday
ergibt:
r,430,ActualWeekday,Wochentag,,15,b509,0d5f00,bday,s,BDY,0=Mon;1=Tue;2=Wed;3=Thu;4=Fri;5=Sat;6=Sun,,Aktueller Wochentag
"comment" entspricht also: "Aktueller Wochentag" (siehe Screenshot)
Der Wert entspricht dem Wert, der in der CSV hinterlegt ist - so weit so gut.
Mit dem Befehl:
find -f BMUFlowTempOrVF1
erhalte ich:
r,430,BMUFlowTempOrVF1,Vorlauftemperaturfühler 1,,15,b509,0d8700,tempsensor,s,D2C,,°C,Temperatur,sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
"comment" entspricht also: "Fühlerstatus" (siehe Screenshot)
Den Wert finde ich nicht in der CSV! In der CSV steht der Wert: "value of either an externally connected flow temperature sensor or the BMU's internal flow sensor if an external sensor is missing"
Dieses Verhalten zieht sich durch alle Werte durch - manche entsprechen der Beschreibung, die in der CSV hinterlegt ist, aber eben nicht alle.
Könntest du bitte erklären wie die Werte zustande kommen?
Wenn ich noch ein Wunsch äußern dürfte: Ich würde mir wünschen die Felder, die mit dem Befehl "find -f" zurückgegeben werden zu bestimmen.
Beispiel:
find -r -w -f [type][poll][circuit][comment][spalte n]
Ok, wenn wir bei den Wünschen schon sind [nice to have] ;o)
Die ebusd Version auch über telnet abfragen zu können anstatt über die tools. Hintergrund ist, dass FHEM nicht zwangsläufig auf dem System läuft auf dem die ebus-tools installiert sind.
Danke und Viele Grüße
Arthur
Zitat von: amunra am 16 September 2015, 21:47:01
mir ist aufgefallen, dass die Rückgabewerte von dem Befehl "find -f" unstimmig sind.
Könntest du bitte erklären wie die Werte zustande kommen?
das schaue ich mir am Wochenende mal an.
Zitat von: amunra am 16 September 2015, 21:47:01
Wenn ich noch ein Wunsch äußern dürfte: Ich würde mir wünschen die Felder, die mit dem Befehl "find -f" zurückgegeben werden zu bestimmen.
Beispiel:
find -r -w -f [type][poll][circuit][comment][spalte n]
Dafür habe ich mal ein issue auf github angelegt: https://github.com/john30/ebusd/issues/1
Zitat von: amunra am 16 September 2015, 21:47:01
Die ebusd Version auch über telnet abfragen zu können anstatt über die tools. Hintergrund ist, dass FHEM nicht zwangsläufig auf dem System läuft auf dem die ebus-tools installiert sind.
Das geht schon, z.B. "telnet localhost 8888" oder "nc localhost 8888".
Ich selbst benutze ebusctl überhaupt nicht.
VG John
Zitat von: john30 am 17 September 2015, 08:24:50
das schaue ich mir am Wochenende mal an.
Danke und vielleicht ergänzend noch folgende Info/Erkenntnis - Die description/der comment scheint bei einigen Datensätzen dem comment, der in der Datentyp-Definition (_template.csv) hinterlegt ist, zu entsprechen. Dabei wird auch nur der comment des zweiten Wertes zurückgegeben.
r -v BMUFlowTempOrVF1Result:
tempsensor=45.00 °C [Temperatur];sensor=ok [Fühlerstatus]Ich vermute, dass das nur dann passiert wenn der zurückgegebene Wert aus mehr als ein Rückgabewert besteht. *komisch formuliert - ich hoffe es dennoch verständlich.
Zitat von: john30 am 17 September 2015, 08:24:50
Das geht schon, z.B. "telnet localhost 8888" oder "nc localhost 8888".
Ich selbst benutze ebusctl überhaupt nicht.
Ok, ich finde es nicht - ich meine den Befehl mit dem ich die Version abfragen kann - könntest du mir ein Tipp geben wie? Danke.
Viele Grüße
Arthur
Hallo amunra!
Wie ich sehe hast du auch eine 430 eingebaut!
Kannst du bei deiner 430 die Wochen-Timer per ebus auslesen?
Ich habe auch schon händisch die Schaltzeiten verändert um am ebus mitgelogt, da kommt aber auch nichts.
LG
Zitat von: Reinhart am 17 September 2015, 14:40:36
Wie ich sehe hast du auch eine 430 eingebaut!
Kannst du bei deiner 430 die Wochen-Timer per ebus auslesen?
Ja, richtig ich habe eine 430.
Meinst du die?
(http://up.picr.de/23139140aa.png)
Falls ja, dann kann ich es seit Anfang des Jahres (siehe dazu die entsprechenden Files im FHEM-contrib).
Viele Grüße
Arthur
P.S: Falls du die ebusd default config hast - ich meine die hier (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de), dann sind die Register dort nicht drin - ich vermute viele weitere Daten die wir Anfang des Jahres erarbeitet haben auch nicht.
Hallo zusammen,
ich habe eine Frage an die Wolf Besitzer. Ich habe eine CGB2-14 mit BM2 Modul und ISM7i, außerdem habe ich den Ebus-Koppler von Eservice als USB Version hier rumliegen.
Nun versuche ich schon seit einer Weile, den Ebus Koppler mit der Anlage zu verheiraten, leider klappt es nicht. Wenn ich denn mal mit dem Poti überhaupt Daten empfange sind diese unnütz (getestet mit HTerm) (fast nur Hex 00 oder EB, aber keine AA oder irgendwas ähnliches)
Schalte ich die Heizungsanlage komplett aus und mit angeschlossenem Koppler ein, so wird mein Heizgerät nicht mehr gefunden, erst wenn ich den Ebus Koppler wieder abstecke, wird das Heizgerät auch wieder gefunden.
Lasse ich den Koppler bei eingeschalteter Heizung dran, bekomme ich nach kurzer Zeit eine Störmeldung für den Thermostaten. Alles sehr komisch. Die Probleme bekomme ich sowohl an der HCM als auch an dem X32 Connecter der sich an der Platine befindet wo die BM-2 steckt.
Habt Ihr irgendwas besonderes machen müssen, damit Ihr werte lesen könnt? Könnte es an der ISM7i liegen? Hat die jemand von euch?
Viele Dank für Hinweise.
@amunra
Zunächst mal Danke für die schnelle Antwort!
Da muss ich ja gewaltig was verschlafen haben, gibt es da 2 Varianten vom ebus (ebus und ebus1), eine am Git und eine im "Fhem-contrib" oder betrifft dies nur die Config-Files? Wo finde ich dieses "Fhem-contrib", kannst du mir da einen Link posten, im Git finde ich da nichts was du gepostet hast?
LG
Reinhart
Zitat von: Reinhart am 17 September 2015, 17:38:13
@amunra
Zunächst mal Danke für die schnelle Antwort!
Da muss ich ja gewaltig was verschlafen haben, gibt es da 2 Varianten vom ebus (ebus und ebus1), eine am Git und eine im "Fhem-contrib" oder betrifft dies nur die Config-Files? Wo finde ich dieses "Fhem-contrib", kannst du mir da einen Link posten, im Git finde ich da nichts was du gepostet hast?
LG
Reinhart
Hier (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/) der link zum FHEM-contrib und hm ja, ich verstehe - die 430er Register sind da nicht drin - du findest "mein" letzten Stand hier (http://forum.fhem.de/index.php/topic,29737.msg243551.html#msg243551).
Nein, und es gibt "eigentlich" keine zwei Varianten ;o) - Hintergrund ist, dass in die config files von john unsere Erkenntnisse nicht eingeflossen sind. Mir ist das schon lange aufgefallen, ich wollte das auch hier melden, aber erst wenn ich die Daten genau analysiert habe bzw. ein Abgleich gemacht habe.
Viele Grüße
Arthur
sorry, ich sehe grade, dass im Verlauf doch noch ein paar Anpassungen vorgenommen wurden - der letzte Stand wäre dann der hier (http://forum.fhem.de/index.php/topic,29737.msg244295.html#msg244295)
Viele Grüße
Danke amunra, jetzt bin ich im Bilde!
habe die Zeitprogramme aus deiner 430er in meine hinzugefügt (da ich ja auch einiges geändert habe) und es funktioniert schon alles bestens.
Ich werde mir die nächsten Tage dann eine Visualisierung der Zeiteingaben basteln.
LG
Reinhart
Zitat von: Reinhart am 17 September 2015, 17:38:13
Da muss ich ja gewaltig was verschlafen haben, gibt es da 2 Varianten vom ebus (ebus und ebus1)...
Kurze Aufklärung bzgl. der zwei git Versionen:
Hintergrund ist, dass die derzeitige 1.x Version von ebusd diesen Herbst/Winter noch einige Überarbeitungen erfahren wird und ich die jetzige unangetastet behalten wollte. Darum wurde die alte ebusd nach ebusd1 umbenannt und dann das Repository komplett auf ebusd kopiert. Hier wird dann die Arbeit an Version 2 weiter gehen.
VG John
@john30
Noch ein Feature-Request hätte ich (ja, jetzt den Arm ;o)), und zwar:
Mit dem Befehl:
r -p 3 Date
kann ich die polling-prio ,,Date" setzten – nach Restart des ebusd services ist die Definition *futsch* => schlecht.
So, jetzt kommt die Herausforderung (Beachtung der Rechte etc.) – mein Wunsch wäre es den Parameter persistent setzen zu können – also extern (von außen – per cmdline) in die csv zu schreiben. CSV Parameter (dauerhaft) zu modifizieren ist aktuell nicht möglich – korrigiere mich wenn ich falsch liege.
Was denkst du? Alternative (auch schon fertige perl Funktionen csv Files zu modifizieren) habe ich – will nur wissen, ob das angedacht ist? Das Thema ist nicht akut (workaround: csv bearbeiten *unschön*).
Viele Grüße
Arthur
P.S. Vielleicht sind das auch ein paar Denkanstöße für Herbst/Winter.
@pah und @john
Zum Thema Vollständigkeit der Dateien gibt es Defizite.
Wie gehen wir das an?
Gibt es überhaupt Bedarf?
Daten liegen:
hier (github Ebusd) (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de)
hier (sourceforge FHEM) (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/)
und im Forum (z. B. hier (http://forum.fhem.de/index.php/topic,29737.msg244295.html#msg244295)).
Problematik: Semantik
Alternative - jeder sucht sich das raus was er braucht - schön ist das nicht.
Viele Grüße
Arthur
Zitat von: amunra am 17 September 2015, 22:06:29
mein Wunsch wäre es den Parameter persistent setzen zu können – also extern (von außen – per cmdline) in die csv zu schreiben.
das ist in der Tat kein leichtes Unterfangen, da die CSVs ja im ebusd komplett in die einzelnen Nachrichten und -Bestandteile aufgelöst werden.
Was sich machen ließe, wäre ein zusätzliches File, in das man die Änderungen der poll Settings ablegen könnte. Ist nicht perfekt, würde aber den Zweck erfüllen...
Zitat von: amunra am 17 September 2015, 22:36:25
@pah und @john
Zum Thema Vollständigkeit der Dateien gibt es Defizite.
Wie gehen wir das an?
Gibt es überhaupt Bedarf?
Könntest Du den zweiten Link nochmal posten?
Wie wäre es mit einem kolaborativen Projekt, in dem wir gemeinsam an den Tabellen arbeiten? Bsp. als Google Tabelle?
Ich wäre bereit, mitzumachen.
Allerdings schwebt mir immer noch eine ordentliche Datenbank vor, wäre auch bereit, den Server dafür zur Verfügung zu stellen. So etwa in der Form: ebusd connected sich mit der DB, um neue Gerätedateien zu holen.
LG
pah
Zitat von: john30 am 18 September 2015, 07:56:38
das ist in der Tat kein leichtes Unterfangen, da die CSVs ja im ebusd komplett in die einzelnen Nachrichten und -Bestandteile aufgelöst werden.
Was sich machen ließe, wäre ein zusätzliches File, in das man die Änderungen der poll Settings ablegen könnte. Ist nicht perfekt, würde aber den Zweck erfüllen...
Ok, wenn ich länger darüber nachdenke, dann ist der Nutzen zu gering. Man stellt die Pollingintervalle einmal ein so wie man sie braucht und verändert die nicht ständig - bei Bedarf kann man einzelne Werte ja auch forciert abrufen. Also, alles gut.
Zitat von: john30 am 18 September 2015, 07:58:49
Könntest Du den zweiten Link nochmal posten?
Wie wäre es mit einem kolaborativen Projekt, in dem wir gemeinsam an den Tabellen arbeiten? Bsp. als Google Tabelle?
Link habe ich im post gefixt.
@amunra
Habe ich mich doch zu früh gefreut, deine 430.cvs funktioniert bei meiner 430 nur teilweise.
Ich kann jeweils nur den Montag abrufen und zurück wird jeweils das Blockprogramm Mo-Fr ausgegeben.
pi@raspberry2 ~ $ ebusctl r -f mcTTMonday
0;03:30;19:30;20:00;20:00;20:00;20:00;Mo-Fr
pi@raspberry2 ~ $ ebusctl r -f mcTTTuesday
ERR: element not found
pi@raspberry2 ~ $ ebusctl r -f mcTTSaturday
ERR: element not found
pi@raspberry2 ~ $ ebusctl r -f mcTTSunday
ERR: element not found
pi@raspberry2 ~ $ ebusctl r -f hwTTMonday
1;06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr
pi@raspberry2 ~ $ ebusctl r -f cpTTMonday
2;06:00;22:00;22:00;22:00;22:00;22:00;Mo-Fr
Warmwasseraufbereitung und Zirkulationspumpe habe ich nicht und sind abgeschaltet (vielleicht liegen hier die Unterschiede), aber die Register geben was zurück, ebenfalls nur Montag.
Es sieht für mich so aus, als würde Vaillant die Geräte mit unterschiedlichen Adressen bzw. Registern ausliefern, je nach Softwarestand. Ich habe Software Version 2.15 in der CalorMatic. Wo diese Zeitprogramme in der 430 gespeichert sind ist ja der Therme letztlich egal und muss es ja auch nicht wissen, Hauptsache es erfolgt der Ein-Befehl über den Bus.
Für mich sind die Zeitprogramme aber nicht so wichtig, weil die ohnehin von Fhem übersteuert werden. Sie dienen nur der Grundeinstellung und werden im Betrieb dann von Fhem mit dem externen Thermostatkontakt gesteuert. Zusätzlich wird noch je nach Wärmebedarf die Heizkurve stufenlos beeinflusst und genau diese Funktionen sind ja bei unseren 430 beide gleich.
Das nur so nebenbei bemerkt. D.h. eine ordentlich Db. so wie pah es anstrebt ist sehr schwer realisierbar wenn nun die Geräte sich noch in der Softwareversion unterscheiden. Ich habe solche Meldungen in diesem Thread noch nirgends gelesen, sind aber offensichtlich real und würde auch so manche Fehlfunktion bei anderen Usern erklären.
mit dieser cvs habe ich getestest und lieferte oben dargestellte Fehlfunktionen
*r,vrc430mcp,,,,15,B515,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTMonday,Zeitfenster Montag,,,,0000,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTTuesday ,Zeitfenster Dienstag,,,,0100,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTWednesday ,Zeitfenster Mittwoch,,,,0200,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTThursday ,Zeitfenster Donnerstag,,,,0300,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTFriday ,Zeitfenster Freitrag,,,,0400,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTSaturday ,Zeitfenster Samstag,,,,0500,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTSunday ,Zeitfenster Samstag,,,,0600,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,vrc430mct,,,,15,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTMondayTemp,Temperatur Montag,,,,1901,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTTuesdayTemp,Temperatur Dienstag,,,,1902,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTWednesdayTemp,Temperatur Mittwoch,,,,1903,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTThursdayTemp,Temperatur Donnerstag,,,,1904,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTFridayTemp,Temperatur Freitag,,,,1905,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTSaturdayTemp,Temperatur Samstag,,,,1906,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,mcTTSundayTemp,Temperatur Sonntag,,,,1907,,,day;temp1;temp1;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,vrc430wwp,,,,15,B515,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTMonday,Warmwasser Zeitfenster Montag,,,,0001,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTTuesday,Warmwasser Zeitfenster Dienstag ,,,,0101,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTWednesday,Warmwasser Zeitfenster Mittwoch,,,,0201,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTThursday,Warmwasser Zeitfenster Donnerstag,,,,0301,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTFriday,Warmwasser Zeitfenster Freitag,,,,0401,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTSaturday,Warmwasser Zeitfenster Samstag,,,,0501,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,hwTTSunday,Warmwasser Zeitfenster Sonntag,,,,0601,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*r,vrc430cpp,,,,15,B515,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTMonday,Zirkulationspumpe Zeitfenster Montag,,,,0002,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTTuesday,Zirkulationspumpe Zeitfenster Dienstag,,,,0102,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTWednesday,Zirkulationspumpe Zeitfenster Mittwoch,,,,0202,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTThursday,Zirkulationspumpe Zeitfenster Donnerstag,,,,0302,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTFriday,Zirkulationspumpe Zeitfenster Freitrag,,,,0402,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTSaturday,Zirkulationspumpe Zeitfenster Samstag,,,,0502,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,cpTTSunday,Zirkulationspumpe Zeitfenster Sonntag,,,,0602,,,status;slot;slot;slot;daysel,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
LG
Reinhart
Hallo Reinhart,
der Fehler:
pi@raspberry2 ~ $ ebusctl r -f mcTTTuesday
ERR: element not found
pi@raspberry2 ~ $ ebusctl r -f mcTTSaturday
ERR: element not found
pi@raspberry2 ~ $ ebusctl r -f mcTTSunday
ERR: element not found
deutet darauf hin, dass der Befehl nicht gefunden wird. Grund dafür, wie in diesem Fall, ist eine unsaubere Config.
In den von dir genannten Werten hat sich wohl ein Fehler eingeschlichen - in der CSV ist noch ein "leerzeichen" drin - einfach entfernen und erneut versuchen, dann sollte es gehen.
Die Tage stimmen wohl auch noch nicht ganz - da muss man an den Datentypen noch was drehen.
VG Grüße
Arthur
P.S: Wenn ein Wert nicht geht kannst du auch eine Abfrage auf HEX-Basis machen z.B: ebusctl write -h 15b504021905 für die Abfrage "mcTTFridayTemp". Den Result kannst du dann entsprechend umrechnen. So bin ich zumindest immer vorgegangen.
EDIT: Ich habe auch die Software Version 2.15 in der CalorMatic.
Ach, ja und mit Leerzeichen meine ich dieses: r,,mcTTWednesday ,<----------------------- | es sind noch mehr die ein Leerzeichen beinhalten.
Danke dir, über das Leerzeichen habe ich zigmal darüber gelesen!
Es läuft jetzt soweit, die Tage dürften passen. es wird so sein, das wenn Blockzeiten verwendet werden, diese immer am Beginn des Blockes angezeigt werden (Mo-Fr und Sa-So). D.h. in meinen Fall werden am Montag und am Samstag die Blocktage mit ausgegeben.
LG
Die Wochenprogramme scheinen mir noch nicht ganz zu stimmen bzw. klar zu sein - die Register reichen von 0000 bis 0699 (nur kurz überflogen) - also da ist noch etwas Aufklärungsarbeit nötig.
VG
Arthur
@amunra
Zitat von: amunra am 16 September 2015, 21:47:01
mir ist aufgefallen, dass die Rückgabewerte von dem Befehl "find -f" unstimmig sind.
Zur Analyse bräuchte ich Deine CSVs, sonst kann ich lange suchen. Also am besten zippen und mir schicken: ebusd@ebusd.eu
Zitat von: amunra am 18 September 2015, 14:23:04
Ach, ja und mit Leerzeichen meine ich dieses: r,,mcTTWednesday ,<----------------------- | es sind noch mehr die ein Leerzeichen beinhalten.
Ich werde im ebusd noch einbauen, dass leading+trailing spaces im Namen der Message entfernt werden, dann kann das nicht mehr passieren.
siehe https://github.com/john30/ebusd/issues/3
Zitat von: Prof. Dr. Peter Henning am 18 September 2015, 08:27:01
Allerdings schwebt mir immer noch eine ordentliche Datenbank vor, wäre auch bereit, den Server dafür zur Verfügung zu stellen. So etwa in der Form: ebusd connected sich mit der DB, um neue Gerätedateien zu holen.
Im Prinzip bin ich auch eher ein Freund von Datenbanken, als von CSVs. Aber jemand muss das dann aktiv pflegen, so wie jetzt die CSVs im github, die ja größtenteils aus der mdb generiert wurden.
Datei-Zugriff ist halt immer noch etwas einfacher, als DB-Zugriff, und easy mittels git pull aktuell zu halten.
Man könnte auch eine DB anfangen und daraus regelmäßig die CSVs generieren. Das fände ich auch OK.
Als neues Feature für ebusd 2.0 ist diesen Herbst die Option "--autoconf" geplant, die nach einem Bus Scan die zur Anlage passenden CSVs automatisch auswählt. Man könnte jetzt natürlich noch einen Schritt weiter denken und statt lokaler Dateien gleich die CSVs von einem Webservice um die o.g. DB abrufen. Ich persönlich bin allerdings eher kein Freund davon, aber wenn die Mehrheit das befürwortet, würd ich das schon implementieren.
Zitat von: amunra am 17 September 2015, 10:28:48
Ok, ich finde es nicht - ich meine den Befehl mit dem ich die Version abfragen kann - könntest du mir ein Tipp geben wie? Danke.
von welcher Version sprichst Du denn?
Zitat von: john30 am 19 September 2015, 08:30:15
von welcher Version sprichst Du denn?
von dieser:
ebusd -Vebusd 1.2.0Viele Grüße
Arthur
Zitat von: amunra am 19 September 2015, 09:23:59
von dieser:
ebusd -V
ebusd 1.2.0
Ah, verstehe. Die ist derzeit noch nicht über den Port abfragbar. Ich mach mal ein Ticket dafür: https://github.com/john30/ebusd/issues/4
Das trimmen der Message Namen etc. ist jetzt eingebaut.
Und noch was hab ich heute committed:
Der Cache für die Werte im ebusd wird jetzt automatisch invalidiert, wenn bspw. eine Nachricht geschrieben wird. Somit kann in Zukunft ein read unmittelbar nach einem write ohne die Option "-f" aufgerufen werden und es wird trotzdem der aktuelle Wert geholt.
Super, danke! Werd ich gleich mal testen.
schöne Grüße
Jo
Zitat von: john30 am 19 September 2015, 08:05:09
@amunraZur Analyse bräuchte ich Deine CSVs, sonst kann ich lange suchen. Also am besten zippen und mir schicken: ebusd@ebusd.eu
Hallo John,
sorry - habs überlesen - ich habe keine spezielle - ich verwende die hier (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/vaillant_de) - also der Auslieferungszustand.
VG Arthur
Zitat von: amunra am 16 September 2015, 21:47:01
Dieses Verhalten zieht sich durch alle Werte durch - manche entsprechen der Beschreibung, die in der CSV hinterlegt ist, aber eben nicht alle.
Könntest du bitte erklären wie die Werte zustande kommen?
Okay, Problem gefunden. Eigentlich sollte es so sein, dass ein Kommentar bei einer Message Definition den Kommentar bei den referenzierten Templates ersetzt.
Das ist jetzt behoben.
Dabei hab ich auch noch entdeckt, dass die Ersetzung der Namen bei Verwendung von Templates nicht ganz richtig war. Ist jetzt auch korrigiert. Somit wird jetzt z.B. "tempsensor" richtig in "temp" und "sensor" aufgelöst statt in "tempsensor" und "sensor".
Zitat von: amunra am 19 September 2015, 09:23:59
von dieser:
ebusd -V
ebusd 1.2.0
Dafür gibt es jetzt das neue Kommando "info" oder einfach "i". Das gibt dann so etwas aus:
version: ebusd 1.2.0
signal: acquired
symbol rate: 22
masters: 5
messages: 1081
Zitat von: john30 am 20 September 2015, 11:55:16
Dafür gibt es jetzt das neue Kommando "info" oder einfach "i". Das gibt dann so etwas aus:
version: ebusd 1.2.0
signal: acquired
symbol rate: 22
masters: 5
messages: 1081
Hallo John,
super - danke - ich habe es gleich mal bei mir eingebaut.
(http://up.picr.de/23168669mu.png)
Was mir auffällt ist, dass die Anzahl der "messages" (siehe Screenshot) von der Anzahl der commands "cmdCntAll" (siehe Screenshot) - ermittelt per "find -r -w -f " - abweicht, das muss ich mir mal in ruhe anschauen.
Viele Grüße
Arthur
Zitat von: john30 am 20 September 2015, 11:32:45
Okay, Problem gefunden. Eigentlich sollte es so sein, dass ein Kommentar bei einer Message Definition den Kommentar bei den referenzierten Templates ersetzt.
Das ist jetzt behoben.
Dabei hab ich auch noch entdeckt, dass die Ersetzung der Namen bei Verwendung von Templates nicht ganz richtig war. Ist jetzt auch korrigiert. Somit wird jetzt z.B. "tempsensor" richtig in "temp" und "sensor" aufgelöst statt in "tempsensor" und "sensor".
Hallo John,
danke auch hierfür, auch wenn das Ergebnis, auf den ersten Blick, nicht dem entspricht was ich erwartet hatte (bzw. ich brauche ;o)). Was genau ich meine, beschreibe ich wenn ich mir das in ruhe angesehen habe.
Möglicherweise ist das Thema auch obsolet, sobald die Möglichkeit besteht die Felder zu definieren.
Viele Grüße
Arthur
Hallo,
ich habe eine Vaillant GeoTherm Plus (Luftwärmepumpe) und ich benutze diese mit GAEBUS.
Nun fehlen mir aber scheinbar noch irgendwelche csv Datein.
Meine Heizung kann folgende Zeitprogramme ändern: Heizung, Warmwasser, Zirkulationspumpe Warmwasser.
Aber irgendwie fehlen mir die von der Heizung, in welcher Konfigurationsdatei müssten diese stecken?
Laut common.csv müsste es der "bc" Circuit sein, aber da finde ich nichts.
Danke und Gruß
Denny
Bitte etwas mehr Informationen: Welche CSV-Dateien funktionieren schon, welche Kommandos funktionieren schon ?
LG
pah
Bei ,,Sparen bis"- Sparfunktion kann man die Zeit an der VRS 620 nur halbstündlich eingeben. Anzuzeigen mit dem Register 26,b509,0d4b00, im Kommentar der csv steht entsprechend: saving function is activated until read value * 1/2 h,to,s,TTM,,,bis
Nun liefert aber TTM: truncated time as "hh:m0" (multiple of 10 minutes, 1 byte). Man bräuchte also einen Base Data Type, bei dem man selbst den Divisor angibt oder eben der Divisor 2 ist. Jetzt muss man das Ergebnis mit 3 multiplizieren. Bei Eingabe von 18:00 ist das Ergebnis 0;06:00.
Ist der Divisor (multible of 10 minutes) fix oder ein ein Default-Wert, den man mit einem eigenen Wert (im Template) überschreiben kann? Habe es nicht ausprobiert (wegen Template-Erweiterung).
VG Josef K.
Zitat von: nightstorm99 am 21 September 2015, 07:27:26
Hallo,
ich habe eine Vaillant GeoTherm Plus (Luftwärmepumpe) und ich benutze diese mit GAEBUS.
Nun fehlen mir aber scheinbar noch irgendwelche csv Datein.
Meine Heizung kann folgende Zeitprogramme ändern: Heizung, Warmwasser, Zirkulationspumpe Warmwasser.
Aber irgendwie fehlen mir die von der Heizung, in welcher Konfigurationsdatei müssten diese stecken?
Laut common.csv müsste es der "bc" Circuit sein, aber da finde ich nichts.
Danke und Gruß
Denny
Ich antworte mir mal selber!
Die Zeiten für die Heizung ist im Circuit von mc hinterlegt, nun kann ich diese auch auslesen.
Zitat[Bitte etwas mehr Informationen: Welche CSV-Dateien funktionieren schon, welche Kommandos funktionieren schon ?/quote]
Konnte ich von Arbeit leider aus nicht genau sagen, aber hab sie jetzt gefunden.
Gruß Denny
Hallo,
kurze Frage zum ebusd. Mir ist aufgefallen, dass er bei mir wieder ein riesiges log-File anlegt (/var/log/ebusd.log). Wo kann ich nochmal einstellen, dass dieses file nicht angelegt wird? War da nicht mal unter /etc/default eine Konfigurationsdatei? Hat sich das geändert? Habe ganz normal selber kompiliert und habe ansonsten nichts verändert.
Nachtrag: Hat schon jemand mit einer Calormatic 470f oder 470 erfolgreich die Zeitprogramme auslesen können? Irgendwie komme ich da nicht weiter.
schöne Grüße
Jo
Zitat von: amunra am 20 September 2015, 17:16:21
Hallo John,
danke auch hierfür, auch wenn das Ergebnis, auf den ersten Blick, nicht dem entspricht was ich erwartet hatte (bzw. ich brauche ;o)). Was genau ich meine, beschreibe ich wenn ich mir das in ruhe angesehen habe.
Möglicherweise ist das Thema auch obsolet, sobald die Möglichkeit besteht die Felder zu definieren.
Viele Grüße
Arthur
Hallo John,
ich denke ich hab's?
Bei der Generierung der Templates scheint mMn etwas nicht richtig gelaufen zu sein.
Beispiel (430.csv aus dem repo):
(http://up.picr.de/23192412xa.jpg)
Jetzt ist offensichtlich der Kommentartext, der für die Message Definition vorgesehen ist, in das Kommentarfeld des referenzierten Templates/typs gerutscht.
(http://up.picr.de/23192418oz.jpg)
Die Message Definition "
DisplayedRoomTemp" hat als Kommentar
"Raumtemperatur Ist" - das müsste mMn durch
"Aktuelle Raumtemperatur" erstezt werden, denn der Typ "Temp" hat nichts mit "Aktuelle Raumtemperatur" zu tun.
Ist das nachvollziehbar/verständlich? ;o) Was meinst du?
Danke und Viele Grüße
Arthur
@jojo11
Das Logfile solltest du in /etc/logrotate.d/ebusd konfigurieren. Ich habe es so eingestellt.
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
hier wird alle 7 Tage rotiert und komprimiert, das aktuelle ist normal lesbar. ZB: kannst rotate auf 2 stellen, wenn dir die Anzahl der Files zuviel ist.
Da sieht dann wie im Bild aus und wächst NICHT mehr!
LG
Reinhart
Vielen Dank!
schöne Grüße
Jo
@Jojo11
betreffend der Zeitprogramme für die 470, ich habe die 430 und habe die cfg von amunra genommen, die funktioniert bei mir!
http://forum.fhem.de/index.php/topic,29737.msg243551.html#msg243551 (http://forum.fhem.de/index.php/topic,29737.msg243551.html#msg243551)
Vielleicht hilft dir die bei der 470 auchweiter.
Auswerten mach ich mit Pah seiner universellen "Vaillant_routines.pl" Routine. Ich musste hier zwar noch die Reihenfolge anpassen, weil bei der 430 der Status vor den Schaltzeiten kommt. Hier die Anpassung von pah seiner Routine für die 430. Unten im Bild das Ergebnis von Pah seiner Auswerteroutine. Das besondere daran, die arbeitet dynamisch, wenn also mehr Schaltzeiten pro Tag programmiert sind, werden die auch angezeigt.
sub Vaillant_Timer($)
{
my @values=split(/[; ]/,$_);
#-- suppress leading zero ?
for(my $i=0;$i<7;$i++){
$values[$i]=~s/^0//;
}
my $sval=sprintf("%s-%s",$values[1],$values[2]);
$sval .=sprintf(", %s-%s",$values[3],$values[4])
if($values[3] ne $values[4]);
$sval .=sprintf(", %s-%s",$values[5],$values[6])
if($values[5] ne $values[6]);
return $sval;
}
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_routines.pl (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/EBUS/Vaillant_routines.pl)
LG
Reinhart
Hallo,
nach einigem Probieren hat es jetzt endlich geklappt. Die Zeitprogramme konnte ich doch noch übernehmen. Hatte einen Dreher in den templates.
Was mich ein wenig wundert ist der Rückgabewert für die selected days.
Für den main circuit bekomme ich für Sonntags folgendes zurück:
0;04:00;15:50;16:00;20:00;22:00;22:00;Mo-So
Das macht Sinn, da ich jeden Tag das selbe Programm eingestellt hatte.
Was ich nicht verstehe ist der Rückgabewert für die Zirkulationspumpe, wenn ich Sonntag abfrage:
2;05:50;19:30;22:10;22:10;23:50;23:50;Mo-Fr
Warum wird hier Mo-Fr zurückgegeben?
Als template verwende ich
status;slot;slot;slot;daysel
Wobei Status folgende Werte liefert:
0: Heizkreislauf
1: Warmwasser
2: Zirkulationspumpe
Ist das richtig?
schöne Grüße
Jo
Zitat von: Reinhart am 23 September 2015, 13:23:42
@Jojo11
betreffend der Zeitprogramme für die 470, ich habe die 430 und habe die cfg von amunra genommen, die funktioniert bei mir!
...
LG
Reinhart
Hast Du auch schon heraus gefunden, wie man die Werte schreibt?
In sämtlichen VRC430-Konfigurationen, die ich gefunden habe, fehlen die write-Adressen. Beim Schreiben bin ich lieber vorsichtig mit Ausprobieren :o
schöne Grüße
Jo
@ Jojo11 Woher kommt dieser Status? Ist so nicht in den Original-csv's
r -f -c mc Timer.Sunday liefert: 07:30;08:30;14:00;14:00;20:00;20:00;Sa-So
Als hex-gelesen ebusctl w -h 50b5040108 -> 072d335454787802
Also Länge 07; 2d entspr. 07:30; 33 entspr. 08:30; 54 entspr. 14:00 usw. 2=Sa-So
Wie sieht der csv-Eintrag aus? ebusctl f -f -c mc Timer.Sunday
Edit:
r,mc,Timer.Sunday,Zeitfenster Sonntag,,50,b504,08,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,daysel,s,UCH,0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So,,
Da steht am Anfang nur "r", also nur Lesen
Einen Ausschnitt der csv habe ich angehängt.
Mein Gerät ist nicht das 50er, sondern das 15er. Ich kann nicht mehr genau sagen, wo der status herkommt. Wenn ich "status;" weglasse, bekomme ich eine Fehlermeldung.
ebusctl f -f -c vc470f_cp cpTTMonday
r,vc470f_cp,cpTTMonday,Zirkulationspumpe Zeitfenster Montag,,15,b515,0002,status,s,UCH,,,,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,slot,s,TTM,,,Slot von/bis,to,s,TTM,,,bis,daysel,s,UCH,0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So,,
ebusctl r -f -c vc470f_cp cpTTMonday
2;05:50;19:30;22:10;22:10;23:50;23:50;Mo-Fr
schöne Grüße
Jo
@Jojo11
ich kann dir leider nicht sagen welche Register zum Schreiben vorgesehen sind ich nehme an das B516.
*w,vrc430mcp,,,,15,B516,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Ich habe schon etwas experimentiert, aber erhalte entweder "Input reached" oder "invalid numeric argument". Ich kann hier auch nichts mitloggen wenn ich Zeiten an der Calormatic verstelle, da ist kein Datenverkehr zur bai00 zu sehen.
Vielleicht hat amunra da schon Erfahrungen sammeln können und kann uns hier weiterhelfen. Aber eins scheint klar zu sein, bei der 430 und 470 sind die Register ident zu behandeln.
LG
Reinhart
Ok, dann werde ich mal weiter testen. "status" und "daysel" passt irgendwie nicht. Da muss ich morgen mal genau nachschauen, was ich in der calormatic eingestellt habe. Schreiben werde ich erst testen, wenn das Gelesene Sinn macht.
schöne Grüße
Jo
bin leider kurz angebunden daher meine Erkenntnisse:
Ein Beispiel:
1) wir nehmenr mcTTMonday Heizkreis Zeitfenster Montag 0000setzt sich zusammen aus:
15 B5 15 02 00 002) HEX Befehl:ebusctl write -h 15B515020000bekommen ich bei mir als Result folgendes:
08 || 00 || 00 || 24 || 27 || 8a || 8a || 90 || 01
3) Ich intepretiere es so:08 = Länge || 00h => 0 DEC / 6 =
00:00 || 00h => 0 DEC / 6 =
00:00 || 24h => 36 DEC / 6 =
06:00; || 27h => 39 DEC / 6 = 06:00 Rest 3 =
06:30;|| 8ah => 138 DEC/6 =
23:00 || 8ah => 138 DEC/6 =
23:00 || 90=>144/6=
24:00 || 01=>
Mo-Fr (0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So)
4) Ergebnis verifisziert auf dem 430 Display:01=Mo-Fr
1| 0:00 - 6:00
2| 6:30 - 23:00
3| 23:00 - 24:00PASST!
Mich verwirrt nur das zweite Byte in der Message "00" - manchmal ist der Wert 00 manchmal 02 etc.
Wo ist der Denkfehler?
Aber jo hat glaube ich den richitgen Hinweis geliefert:
Zitat von: Jojo11 am 23 September 2015, 19:38:08
Wobei Status folgende Werte liefert:
0: Heizkreislauf
1: Warmwasser
2: Zirkulationspumpe
Ist das richtig?
@Jo
gibt mal bitte ein:
ebusctl write -h 15B515020602und poste hier das Ergebnis.
oder besser gleich für alle Tage:
ebusctl write -h 15B515020002
ebusctl write -h 15B515020102
ebusctl write -h 15B515020202
ebusctl write -h 15B515020302
ebusctl write -h 15B515020402
ebusctl write -h 15B515020502
ebusctl write -h 15B515020602
@Reinhart
Nein, leider noch nicht - Zeitmangel (das alles hier läuft nur nebenbei) und andere Prios :(
VG Arthur
Zitat von: amunra am 23 September 2015, 21:41:34
...
@Jo
gibt mal bitte ein:
ebusctl write -h 15B515020602
und poste hier das Ergebnis.
...
VG Arthur
Da kommt Folgendes bei raus:
ebusctl write -h 15B515020602
0802237585858f8f01
Welche Zeiten habe ich denn jetzt geändert? :o
schöne Grüße
Jo
Ich habe mein Post editiert bitte alle Tage abfragen.
Write hat nicht wirklich etwas mit "schreiben" also Werte verändern zu tun - also keine Sorge.
VG Arthur
Ok, kann ich aber leider erst morgen testen.
schöne Grüße
Jo
Moin,
für die 470 kannst du die Zirkulationspumpe mit folgender .csv setzten und lesen:
*r,470c,,,,15,B515,,,,,,,
*w,470c,,,,26,B515,,,,,,,
r,,cTTMonday,Zeitfenster Montag,,,,0002,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTTuesday,Zeitfenster Dienstag,,,,0102,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTWednesday,Zeitfenster Mittwoch,,,,0202,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTThursday,Zeitfenster Donnerstag,,,,0302,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTFriday,Zeitfenster Freitrag,,,,0402,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTSaturday,Zeitfenster Samstag,,,,0502,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
r,,cTTSunday,Zeitfenster Sonntag,,,,0602,,,status;slot;slot;slot;daysel2,,,,,,,,,,,
#
w,,cTTMonday,Zeitfenster Montag,,,,0002,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTTuesday,Zeitfenster Dienstag,,,,0102,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTWednesday,Zeitfenster Mittwoch,,,,0202,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTThursday,Zeitfenster Donnerstag,,,,0302,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTFriday,Zeitfenster Freitrag,,,,0402,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTSaturday,Zeitfenster Samstag,,,,0502,,,slot;slot;slot;daysel2,,,,,,,,,,,
w,,cTTSunday,Zeitfenster Sonntag,,,,0602,,,slot;slot;slot;daysel2,,,,,,,,,,,
in der _template.csv brauchst du aber noch folgendes:
daysel2,UCH,0=selected;1=Mo-So;2=Mo-Fr;3=Sa-So,,
Das ist dann das Tagesprogramm (beim Auslesen). Beim Schreiben brauchst du das Tagesprogramm nicht mitgeben. Einfach die Wochentage setzten. Falls Mo-Fr gleich gesetzt sind kommt beim lesen "Mo-Fr" zurück. Unterscheiden sich die Tage, dann "selected".
Grüße
Andy
Danke Andy!
kannst du uns ein Beispiel hier geben wie die Syntax des Schreibbefehles aussehen muss?
ebusctl w -c 470mc mcTTMonday ?????????
LG
Reinhart
klar :-)
andreas@be1:/etc/ebusd$ ebusctl
localhost: r -f -c 470c cTTMonday
2;05:30;05:50;-:-;-:-;-:-;-:-;selected
localhost: w -c 470c cTTMonday "05:30;05:40;24:00;24:00;24:00;24:00;selected"
done
localhost: r -f -c 470c cTTMonday
2;05:30;05:40;-:-;-:-;-:-;-:-;selected
localhost:
Habe zwar eine 620, es klappt mit:
w -c cp Timer.Monday "08:00;08:10;18:00;18:00;22:00;22:00;selected"
done
Toll wäre eine ebusd-Funkion, die wie beim read, statt Lesen, beim write einzelene Felder ersetzt.
r -f -c cp Timer.Monday to.0 --> 08:10
w -f -c cp Timer.Monday to.0 "08:20" (die notwendigen Daten sind im cache)
VG Josef K.
Das wäre aber sehr gefährlich. Man überschreibt nicht ganze Arrays mit Werten, die man nicht kennt - sondern die nur irgendwo im Cache stehen.
LG
pah
Zitat von: amunra am 23 September 2015, 21:41:34
...
oder besser gleich für alle Tage:
ebusctl write -h 15B515020002
ebusctl write -h 15B515020102
ebusctl write -h 15B515020202
ebusctl write -h 15B515020302
ebusctl write -h 15B515020402
ebusctl write -h 15B515020502
ebusctl write -h 15B515020602
...
VG Arthur
Ok, hier ist das immer gleiche Ergebnis:
ebusctl write -h 15B515020002
0802237585858f8f01
ebusctl write -h 15B515020102
0802237585858f8f01
ebusctl write -h 15B515020202
0802237585858f8f01
ebusctl write -h 15B515020302
0802237585858f8f01
ebusctl write -h 15B515020402
0802237585858f8f01
ebusctl write -h 15B515020502
0802237585858f8f01
ebusctl write -h 15B515020602
0802237585858f8f01
schöne Grüße
Jo
Zitat von: jamesgo am 24 September 2015, 05:13:11
Moin,
für die 470 kannst du die Zirkulationspumpe mit folgender .csv setzten und lesen:
...
in der _template.csv brauchst du aber noch folgendes:
daysel2,UCH,0=selected;1=Mo-So;2=Mo-Fr;3=Sa-So,,
Das ist dann das Tagesprogramm (beim Auslesen). Beim Schreiben brauchst du das Tagesprogramm nicht mitgeben. Einfach die Wochentage setzten. Falls Mo-Fr gleich gesetzt sind kommt beim lesen "Mo-Fr" zurück. Unterscheiden sich die Tage, dann "selected".
Grüße
Andy
Danke! Ich denke "daysel2" war der entscheidende Unterschied.
daysel,UCH,0=selected;1=Mo-Fr;2=Sa-So;3=Mo-So,,
daysel2,UCH,0=selected;1=Mo-So;2=Mo-Fr;3=Sa-So,,
Ich bin noch nicht dazu gekommen, die Einstellungen auch an der Heizung zu verifizieren, aber das müsste ja jetzt passen. Damit kann ich wieder ein wenig rumprobieren ;D
schöne Grüße
Jo
Zitat von: amunra am 22 September 2015, 20:36:52
Bei der Generierung der Templates scheint mMn etwas nicht richtig gelaufen zu sein.
Beispiel (430.csv aus dem repo):
(http://up.picr.de/23192412xa.jpg)
Jetzt ist offensichtlich der Kommentartext, der für die Message Definition vorgesehen ist, in das Kommentarfeld des referenzierten Templates/typs gerutscht.
Wenn mich nicht alles täuscht, gibt es in der MDB immer einen Kommentar für eine Nachricht und einen Kommentar für jedes Feld in einer Nachricht. Deshalb sind die auch potentiell unterschiedlich. Ich kann am Wochenende noch mal in meinen Konverter schauen, wie der letzte Stand generiert wurde.
Zitat von: jkriegl am 21 September 2015, 15:16:55
Bei ,,Sparen bis"- Sparfunktion kann man die Zeit an der VRS 620 nur halbstündlich eingeben. Anzuzeigen mit dem Register 26,b509,0d4b00, im Kommentar der csv steht entsprechend: saving function is activated until read value * 1/2 h,to,s,TTM,,,bis
Nun liefert aber TTM: truncated time as "hh:m0" (multiple of 10 minutes, 1 byte). Man bräuchte also einen Base Data Type, bei dem man selbst den Divisor angibt oder eben der Divisor 2 ist. Jetzt muss man das Ergebnis mit 3 multiplizieren. Bei Eingabe von 18:00 ist das Ergebnis 0;06:00.
Ist der Divisor (multible of 10 minutes) fix oder ein ein Default-Wert, den man mit einem eigenen Wert (im Template) überschreiben kann? Habe es nicht ausprobiert (wegen Template-Erweiterung).
Der Faktor kann einfach in einem template oder auch direkt in der Nachricht angepasst werden.
Das ist richtig, die Kommentarfelder sind immer mehrfach vorhanden. Leicht irre, aber da hat wohl jemand bei Vaillant nicht gut genug nachgedacht.
LG
pah
@John, Vielen Dank
klappt leider nicht. Habe to2,TTM,2,,bis /2 in _template.csv hinzugefügt (Muster to,TTM,,,bis).
csv: r,,CleaningLady,Sparfunktion,,,,"4B00",,,cntfuel;to2,,,saving function is activated until read value * 1/2 h
Die Auflösung ist
r,hc,CleaningLady,Sparfunktion,,26,b509,0d4b00,cntfuel,s,BCD,,,saving function is activated until read value * 1/2 h,to2,s,TTM,,,bis /2 (scheinbar wird der individuelle divider nicht übernommen)
hex 050000000023 wird gelesen als 0;05:50 ist aber 17:30
Wenn ich in der solsy.hc.csv einen divider (bzw. 1;2) eingebe, erhalte ich beim reload ERR: invalid argument
Zitat von: john30 am 25 September 2015, 07:42:16
Wenn mich nicht alles täuscht, gibt es in der MDB immer einen Kommentar für eine Nachricht und einen Kommentar für jedes Feld in einer Nachricht. Deshalb sind die auch potentiell unterschiedlich. Ich kann am Wochenende noch mal in meinen Konverter schauen, wie der letzte Stand generiert wurde.
Zitat von: Prof. Dr. Peter Henning am 25 September 2015, 07:49:15
Das ist richtig, die Kommentarfelder sind immer mehrfach vorhanden. Leicht irre, aber da hat wohl jemand bei Vaillant nicht gut genug nachgedacht.
Warum das ganze?
Ok, meine Idee ist es per Command, die Informationen zum Befehl oder per (?=Info) Button (GUI) zum entsprechenden Befehl, erweiterte Informationen (Beschreibung) zu erhalten.
Daraus ergibt sich für mich folgende Frage:
Spricht etwas dagegen (EBUSD, FHEM ....) die Beschreibung (die von der Aussagekraft nahezu dem Befehl/Command entspricht) des Befehls/Commands mit einer aussagekräftigen Beschreibung zu versehen?
Ja, John müsste sein Konverter anpassen (Aufwand) und erstellt die CSV neu => Aufwand! - muss bitte John entscheiden.
@John: hat die Anpassung Auswirkungen auf EBUSD?
Alternative: Ich fische mir die Informationen irgendwie (aktuell etwas heterogen) raus.
Meinungen?
Viele Grüße
Arthur
Man bläst Programme nicht dadurch künstlich auf, dass man sie die Hilfetexte für externe Kommandos mit einlesen lässt. Sondern könnte höchstens versuchen, das Programm bei Bedarf in der Datenbank = CSV-Datei den Hilfetext herausfischen zu lassen. Das würde aber die Performance von ebusd beeinflussen. Also besser: Externes Programm, um den Hilfetext bei Bedarf herauszufischen.
LG
pah
Zitat von: amunra am 26 September 2015, 00:43:50
Ok, meine Idee ist es per Command, die Informationen zum Befehl oder per (?=Info) Button (GUI) zum entsprechenden Befehl, erweiterte Informationen (Beschreibung) zu erhalten.
Wie viel Beschreibung stellst Du Dir denn vor?
Zitat von: amunra am 26 September 2015, 00:43:50
Daraus ergibt sich für mich folgende Frage:
Spricht etwas dagegen (EBUSD, FHEM ....) die Beschreibung (die von der Aussagekraft nahezu dem Befehl/Command entspricht) des Befehls/Commands mit einer aussagekräftigen Beschreibung zu versehen?
Die Kommentare werden beim Einlesen der CSVs ins RAM geladen. Wenn davon also genug zur Verfügung steht, kann man auch nen Roman hinterlegen.
Zitat von: amunra am 26 September 2015, 00:43:50
Ja, John müsste sein Konverter anpassen (Aufwand) und erstellt die CSV neu => Aufwand! - muss bitte John entscheiden.
Die Frage ist nur, wer gerne die Kommentare von über 2000 Einträgen erweitern möchte... Also ich nicht :)
Zitat von: amunra am 26 September 2015, 00:43:50
@John: hat die Anpassung Auswirkungen auf EBUSD?
Dem ebusd ist das egal, wie viel Text da drin steht. Das landet letztlich alles im RAM. Für nen ebusd auf Fritzbox mag das vielleicht nicht so der Brüller sein. Aber man könnte eine Option ala "drop comments" einbauen, dann lassen sich trotzdem die CSVs einheitlich verwenden.
Zitat von: Prof. Dr. Peter Henning am 26 September 2015, 06:45:54
Man bläst Programme nicht dadurch künstlich auf, dass man sie die Hilfetexte für externe Kommandos mit einlesen lässt. Sondern könnte höchstens versuchen, das Programm bei Bedarf in der Datenbank = CSV-Datei den Hilfetext herausfischen zu lassen. Das würde aber die Performance von ebusd beeinflussen. Also besser: Externes Programm, um den Hilfetext bei Bedarf herauszufischen.
Das halte ich jetzt für übertrieben. Und auf die Performance hat das kaum Einfluss, außer beim Laden der CSVs und das darf m.E. auch seine Zeit brauchen.
Zitat von: jkriegl am 25 September 2015, 16:11:47
klappt leider nicht. Habe to2,TTM,2,,bis /2 in _template.csv hinzugefügt (Muster to,TTM,,,bis).
csv: r,,CleaningLady,Sparfunktion,,,,"4B00",,,cntfuel;to2,,,saving function is activated until read value * 1/2 h
Die Auflösung ist
r,hc,CleaningLady,Sparfunktion,,26,b509,0d4b00,cntfuel,s,BCD,,,saving function is activated until read value * 1/2 h,to2,s,TTM,,,bis /2 (scheinbar wird der individuelle divider nicht übernommen)
hex 050000000023 wird gelesen als 0;05:50 ist aber 17:30
Wenn ich in der solsy.hc.csv einen divider (bzw. 1;2) eingebe, erhalte ich beim reload ERR: invalid argument
Ah, TTM ist ein String basiertes Feld und insofern ist der Divider nicht anwendbar (hab grad die Prüfung dafür eingebaut).
In diesem Fall gibts zwei Möglichkeiten:
1. "UCH,-30" als Template nehmen und einfach in Minuten kalkulieren (negativer Divisor wird reziprok gerechnet also als Multiplikator ohne Vorzeichen und nicht als Teiler, ist kryptisch, ich weiß...)
2. tatsächlich einen eigenen Basistyp dafür entwickeln.
Ich persönlich fände Variante 1 naheliegender, auch wenn der Wert dann in Minuten statt in hh:mm anzugeben ist, da es ja kein Zeitpunkt ist, sondern eine Zeitdauer.
Zitat von: amunra am 16 September 2015, 21:47:01
Wenn ich noch ein Wunsch äußern dürfte: Ich würde mir wünschen die Felder, die mit dem Befehl "find -f" zurückgegeben werden zu bestimmen.
Beispiel:
find -r -w -f [type][poll][circuit][comment][spalte n]
ist jetzt implementiert, siehe wiki: https://github.com/john30/ebusd/wiki/3.-Commands#find (https://github.com/john30/ebusd/wiki/3.-Commands#find) oder die Hilfe:
usage: find [-v] [-r] [-w] [-p] [-d] [-i PB] [-f] [-F COL[,COL]*] [-e] [-c CIRCUIT] [NAME]
...
-F COL[,COL]* list messages in the specified format
(COL: type,circuit,name,comment,qq,zz,pbsb,id,fields)
Für die Feldnamen gehen auch Kürzel (erster Buchstabe bzw. für comment die zwei ersten).
Ok, vielleicht ist das ein Missverständnis - ich versuche es anders zu formulieren ;o)
Ich wollte eigentlich nur darauf hinweisen, dass der "TEXT" des Kommentarfeldes des Datentyps sinnvollerweise in das Kommentarfeld des Befehls wandern sollte. Also so:
(http://up.picr.de/23192418oz.jpg)
Vielleicht praktisch: Die Spalte 14 in die Spalte 4 kopieren und fertig ist die Laube. ;o)
Viele Grüße
Arthur
Zitat von: john30 am 26 September 2015, 12:54:20
ist jetzt implementiert, siehe wiki: https://github.com/john30/ebusd/wiki/3.-Commands#find (https://github.com/john30/ebusd/wiki/3.-Commands#find) oder die Hilfe:
usage: find [-v] [-r] [-w] [-p] [-d] [-i PB] [-f] [-F COL[,COL]*] [-e] [-c CIRCUIT] [NAME]
...
-F COL[,COL]* list messages in the specified format
(COL: type,circuit,name,comment,qq,zz,pbsb,id,fields)
Für die Feldnamen gehen auch Kürzel (erster Buchstabe bzw. für comment die zwei ersten).
Hallo John,
super, danke schaue ich mir an.
Viele Grüße
Arthur
@ John, Danke
CleaningLady-Anzeige funktioniert mit Methode 1.
Es wird 0;900 angezeigt was 15:00 entspricht.
Allerdings ist das ein Zeitpunkt, Sparen bis. Gehe auf die Wiesn und möchte bis 22:00 sparen.
Kann damit leben.
Zitat von: jkriegl am 26 September 2015, 13:51:21
@ John, Danke
CleaningLady-Anzeige funktioniert mit Methode 1.
Es wird 0;900 angezeigt was 15:00 entspricht.
Allerdings ist das ein Zeitpunkt, Sparen bis. Gehe auf die Wiesn und möchte bis 22:00 sparen.
Kann damit leben.
Okay, ich hab das als Dauer gelesen bzw. verstanden. Nachdem ich das noch nie benutzt hab, kann das gut falsch sein.
Wenn das wirklich ein Zeitpunkt ist, dann kann ich auch noch nen extra Typ dafür einbauen (ala TTM).
Zitat von: jkriegl am 26 September 2015, 13:51:21
CleaningLady-Anzeige funktioniert mit Methode 1.
Es wird 0;900 angezeigt was 15:00 entspricht.
Allerdings ist das ein Zeitpunkt, Sparen bis. Gehe auf die Wiesn und möchte bis 22:00 sparen.
Hab mal noch den Basistyp "TTH" eingebaut :)
Ach ja: Könntest Du vielleicht rausfinden, auf was das steht, wenn die CleaningLady doch nicht kommt?
Hab jetzt mal 00 angenommen, hätte das aber gern verifiziert.
Auch noch interessant wäre der Maximalwert und ob man "00:00" Uhr eintragen kann.
Zitat von: zentis666 am 27 Juni 2015, 14:31:42
Hallo Sammelbesteller,
die Platinen sind heute eingetroffen, anbei ein paar Bilder. Ich mach die Sendungen am WE fertig und schick sie am Montag raus,
Gruß
Sven
Gesendet von iPhone mit Tapatalk
Hallo,
an der Stelle nochmal herzlichen Dank an pah für den Schaltplan und an zentis666 für den Bausatz. Habe ihn jetzt endlich mal zusammengelötet und er läuft auf Anhieb :)
Habe das heute gemacht, weil ich mit dem ebus-Koppler von eservice immer noch regelmäßig bus/main errors bekommen habe:
2015-09-26 12:15:27.327 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:15:29.365 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:15:35.300 [bus error] ERR: arbitration lost, retry
2015-09-26 12:15:37.381 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:15:39.424 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:15:49.432 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:15:59.698 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:04.199 [bus error] ERR: CRC error, retry
2015-09-26 12:16:04.797 [bus error] ERR: CRC error, retry
2015-09-26 12:16:07.396 [update notice] update broadcast vdatetime QQ=10: 12:16:02;26.09.2015
2015-09-26 12:16:07.805 [bus error] ERR: arbitration lost, retry
2015-09-26 12:16:07.860 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:16:09.350 [bus error] ERR: arbitration lost, retry
2015-09-26 12:16:09.442 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:17.452 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:16:19.449 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:25.479 [update notice] unknown MS cmd: 1008b5110101 / 093f350080ff630100ff
2015-09-26 12:16:27.417 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:16:29.497 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:37.469 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:16:39.508 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:45.510 [update notice] unknown MS cmd: 1008b5110101 / 093e350080ff630100ff
2015-09-26 12:16:49.487 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:16:59.539 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:07.497 [update notice] update broadcast vdatetime QQ=10: 12:17:02;26.09.2015
2015-09-26 12:17:07.733 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:17:09.558 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:15.551 [update notice] unknown MS cmd: 1008b5110101 / 093f370080ff630100ff
2015-09-26 12:17:17.535 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:17:19.534 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:27.513 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:17:29.557 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:37.586 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:17:39.581 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:49.588 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:17:59.604 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:07.657 [update notice] update broadcast vdatetime QQ=10: 12:18:02;26.09.2015
2015-09-26 12:18:07.970 [bus error] ERR: arbitration lost, retry
2015-09-26 12:18:08.025 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:18:08.208 [bus error] ERR: CRC error, retry
2015-09-26 12:18:08.805 [bus error] ERR: CRC error, retry
2015-09-26 12:18:09.404 [bus error] ERR: CRC error, retry
2015-09-26 12:18:09.909 [bus error] ERR: arbitration lost, retry
2015-09-26 12:18:10.002 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:10.188 [bus error] ERR: CRC error
2015-09-26 12:18:10.189 [main error] send message: ERR: CRC error
2015-09-26 12:18:17.619 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:18:19.654 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:27.594 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:18:29.678 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:37.658 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:18:39.656 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:40.840 [bus error] ERR: CRC error, retry
2015-09-26 12:18:41.437 [bus error] ERR: CRC error, retry
2015-09-26 12:18:42.035 [bus error] ERR: CRC error, retry
2015-09-26 12:18:49.676 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:18:55.673 [update notice] unknown MS cmd: 1008b5110101 / 09453b0080ff630100ff
2015-09-26 12:18:59.687 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:05.681 [update notice] unknown MS cmd: 1008b5110101 / 09423b0080ff630000ff
2015-09-26 12:19:07.688 [update notice] update broadcast vdatetime QQ=10: 12:19:02;26.09.2015
2015-09-26 12:19:07.926 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:19:09.708 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:15.704 [update notice] unknown MS cmd: 1008b5110101 / 093d3b0080ff630000ff
2015-09-26 12:19:17.731 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:19:19.727 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:25.723 [update notice] unknown MS cmd: 1008b5110101 / 093c3b0080ff630000ff
2015-09-26 12:19:27.705 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:19:29.749 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:35.754 [update notice] unknown MS cmd: 1008b5110101 / 093b3b0080ff630000ff
2015-09-26 12:19:37.731 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:19:39.772 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:45.769 [update notice] unknown MS cmd: 1008b5110101 / 093b3b0080ff630000ff
2015-09-26 12:19:49.784 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:19:55.785 [update notice] unknown MS cmd: 1008b5110101 / 093b3b0080ff630000ff
2015-09-26 12:19:59.808 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:20:05.804 [update notice] unknown MS cmd: 1008b5110101 / 093c3c0080ff630000ff
2015-09-26 12:20:07.768 [update notice] update broadcast vdatetime QQ=10: 12:20:02;26.09.2015
2015-09-26 12:20:08.002 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:20:09.824 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:20:15.827 [update notice] unknown MS cmd: 1008b5110101 / 093c3b0080ff630000ff
2015-09-26 12:20:20.046 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:20:20.285 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:20:33.199 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:20:35.879 [update notice] unknown MS cmd: 1008b5110101 / 093b3a0080ff630000ff
2015-09-26 12:20:37.862 [update notice] update broadcast outsidetemp QQ=10: 14.500
2015-09-26 12:20:39.902 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:20:45.827 [bus error] ERR: arbitration lost, retry
2015-09-26 12:20:45.914 [update notice] unknown MS cmd: 1008b5110101 / 093a3a0080ff630000ff
2015-09-26 12:20:47.000 [bus notice] max. symbols per second: 136
2015-09-26 12:20:47.942 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 12:20:49.906 [bus error] ERR: arbitration lost, retry
2015-09-26 12:20:49.996 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:20:55.921 [update notice] unknown MS cmd: 1008b5110101 / 093a3a0080ff630000ff
2015-09-26 12:20:59.936 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:21:05.933 [update notice] unknown MS cmd: 1008b5110101 / 093a3a0080ff630000ff
2015-09-26 12:21:09.950 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:21:15.932 [update notice] unknown MS cmd: 1008b5110101 / 093a3a0080ff630000ff
2015-09-26 12:21:17.914 [update notice] update broadcast vdatetime QQ=10: 12:21:12;26.09.2015
2015-09-26 12:21:18.153 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 12:21:19.978 [update notice] unknown MS cmd: 1008b510090000396effff00ff00 / 0101
2015-09-26 12:21:25.960 [update notice] unknown MS cmd: 1008b5110101 / 093a3a0080ff630000ff
Mit dem Eigenbau erhalte ich diese Fehler zwar seltener, aber immer noch:
2015-09-26 18:40:08.766 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 18:40:10.804 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:40:16.801 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:40:18.743 [update notice] update broadcast outsidetemp QQ=10: 15.375
2015-09-26 18:40:20.828 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:40:26.825 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:40:28.800 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 18:40:30.839 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:40:36.836 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:40:40.855 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:40:46.852 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:40:50.874 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:40:56.789 [bus error] ERR: arbitration lost, retry
2015-09-26 18:40:56.879 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:40:58.886 [update notice] update broadcast vdatetime QQ=10: 18:40:58;26.09.2015
2015-09-26 18:40:59.208 [bus error] ERR: arbitration lost, retry
2015-09-26 18:40:59.263 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-09-26 18:41:00.780 [bus error] ERR: arbitration lost, retry
2015-09-26 18:41:00.873 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:06.855 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:08.878 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 18:41:10.876 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:16.873 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:18.854 [update notice] update broadcast outsidetemp QQ=10: 15.375
2015-09-26 18:41:20.897 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:26.906 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:28.889 [update notice] unknown MS cmd: 1008b5110102 / 06033c96468c78
2015-09-26 18:41:30.931 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:32.278 [update notice] unknown MS cmd: 0315070400 / 0ab5463437303001146102
2015-09-26 18:41:36.940 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:40.914 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:46.915 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:50.942 [update notice] unknown MS cmd: 1008b510090000366effff00ff00 / 0101
2015-09-26 18:41:56.936 [update notice] unknown MS cmd: 1008b5110101 / 0934340080ff660000ff
2015-09-26 18:41:58.943 [update notice] update broadcast vdatetime QQ=10: 18:41:58;26.09.2015
2015-09-26 18:41:59.180 [update notice] unknown MS cmd: 1008b512020064 / 00
Was hat denn folgende Meldung zu bedeuten?
2015-09-26 19:04:14.007 [bus notice] max. symbols per second: 128
Sowohl mit dem alten als auch mit dem neuen Adapter habe ich heute Werte zwischen 109 und 136 bekommen. Deutet das auf ein Performance-Problem hin? Oder ist der Bus "überlastet"?
schöne Grüße
Jo
Hm, bei mir tat auch der kommerzielle Adapter ohne Mucken, sonst hätte ich ihn nicht verkauft sondern vom Hersteller Ersatz gefordert.
Hier wäre noch etwas für Dich: Wie setzt man eine bestimmte Vorlauftemperatur - http://forum.fhem.de/index.php/topic,31373.msg337158.html#msg337158
LG
pah
Ist ja bei mir schon ein Austauschgerät. Ich denke es liegt an etwas anderem. Aber es funktioniert ja soweit.
Danke für den Tipp, aber die Diskussion verfolge ich ohnehin schon mit großem Interesse ;)
schöne Grüße
Jo
@John wegen CleaningLady
Man kann bis 24:00 drehen (dann 23:00, ...)
hex 050000000030 also 24:00
r -f -c hc CleaningLady 0;1440 (in min) entspricht 24:00
Z. Zt. ist der hc auf off und der CleaningLady-Wert springt nach ca. 5 min (gefühlt) auf 00 zurück.
ZitatAch ja: Könntest Du vielleicht rausfinden, auf was das steht, wenn die CleaningLady doch nicht kommt?
Ist das damit beantwortet?
Den Basistyp "TTH" zu testen wird wegen Aktualisierung ebusd bei mir (Newbie) etwas dauern.
Zitat von: Jojo11 am 26 September 2015, 19:10:07
Habe das heute gemacht, weil ich mit dem ebus-Koppler von eservice immer noch regelmäßig bus/main errors bekommen habe:
2015-09-26 12:15:35.300 [bus error] ERR: arbitration lost, retry
2015-09-26 12:16:04.199 [bus error] ERR: CRC error, retry
2015-09-26 12:16:04.797 [bus error] ERR: CRC error, retry
2015-09-26 12:16:07.805 [bus error] ERR: arbitration lost, retry
2015-09-26 12:16:09.350 [bus error] ERR: arbitration lost, retry
2015-09-26 12:18:07.970 [bus error] ERR: arbitration lost, retry
2015-09-26 12:18:08.208 [bus error] ERR: CRC error, retry
2015-09-26 12:18:08.805 [bus error] ERR: CRC error, retry
2015-09-26 12:18:09.404 [bus error] ERR: CRC error, retry
2015-09-26 12:18:09.909 [bus error] ERR: arbitration lost, retry
2015-09-26 12:18:10.188 [bus error] ERR: CRC error
2015-09-26 12:18:10.189 [main error] send message: ERR: CRC error
2015-09-26 12:18:40.840 [bus error] ERR: CRC error, retry
2015-09-26 12:18:41.437 [bus error] ERR: CRC error, retry
2015-09-26 12:18:42.035 [bus error] ERR: CRC error, retry
2015-09-26 12:20:45.827 [bus error] ERR: arbitration lost, retry
2015-09-26 12:20:49.906 [bus error] ERR: arbitration lost, retry
Also die arbitration loss Meldungen sind mengenmäßig nicht ungewöhnlich, das ist im Rahmen von Normalität beim Buszugriff.
Die CRC Fehler allerdings sprechen dafür, dass hier das Poti noch nicht gut genug eingestellt ist und unterwegs hin und wieder mal ein Bit verlorenn geht, was sich eben vor allem in der CRC niederschlägt (genau dafür ist die Prüfung ja da).
Zitat von: Jojo11 am 26 September 2015, 19:10:07
Mit dem Eigenbau erhalte ich diese Fehler zwar seltener, aber immer noch:
2015-09-26 18:40:56.789 [bus error] ERR: arbitration lost, retry
2015-09-26 18:40:59.208 [bus error] ERR: arbitration lost, retry
2015-09-26 18:41:00.780 [bus error] ERR: arbitration lost, retry
Das ist im Vergleich zu oben deutlich besser, da wie gesagt arbitration loss relativ normal ist. Scheint also das Poti vom Eigenbau besser getrimmt zu sein als das andere.
Zitat von: Jojo11 am 26 September 2015, 19:10:07
Was hat denn folgende Meldung zu bedeuten?
2015-09-26 19:04:14.007 [bus notice] max. symbols per second: 128
Sowohl mit dem alten als auch mit dem neuen Adapter habe ich heute Werte zwischen 109 und 136 bekommen. Deutet das auf ein Performance-Problem hin? Oder ist der Bus "überlastet"?
Das gibt lediglich einen Hinweis auf die maximale Last auf dem Bus, die bis dahin gemessen wurde. Die hängt ein bisschen von der Menge der Teilnehmer ab und wie gesprächig diese sind. Bei mir z.B. um die 180 bei 5 Mastern (lässt sich neuerdings mit dem Kommando "info" ausgeben).
Zitat von: jkriegl am 26 September 2015, 19:52:29
@John wegen CleaningLady
Man kann bis 24:00 drehen (dann 23:00, ...)
hex 050000000030 also 24:00
r -f -c hc CleaningLady 0;1440 (in min) entspricht 24:00
Z. Zt. ist der hc auf off und der CleaningLady-Wert springt nach ca. 5 min (gefühlt) auf 00 zurück. Ist das damit beantwortet?
Gut, das entspricht den Erwartungen. Danke!
Zitat von: jkriegl am 26 September 2015, 19:52:29
Den Basistyp "TTH" zu testen wird wegen Aktualisierung ebusd bei mir (Newbie) etwas dauern.
Wenn Du mir sagst, was für ein System Du nutzt, kann ich Dir auch ein Binary zur Verfügung stellen.
Hallo Tomy,
ich bin neu hier und bin im Internet auf das Thema BARTL WP und ebusd von John30 auf dieses Forum gestoßen. Du schreibst Du kannst mittlerweile Daten aus Deiner WP lesen. Woher hast Du denn die _template.csv für die Bartl WP? Habe mir letzte Woche einen Raspberry und den USB-EBUS Adapter gekauft und versuche das zum Laufen zu bringen. Als _template verwende ich das Ochsend-Template. Derzeit bekomme ich aber folgende Fehlermeldungen:
2015-09-26 21:06:22.215 [main error] error reading config files: ERR: invalid argument, /etc/ebusd/_template.csv:3
2015-09-26 21:06:22.215 [main notice] found messages: 0 (0 poll, 0 update)
2015-09-26 21:06:22.216 [bus error] unable to open -r: ERR: element not found
2015-09-26 21:06:32.216 [bus error] unable to open -r: ERR: element not found
2015-09-26 21:06:42.216 [bus error] unable to open -r: ERR: element not found
Das sagt mir momentan nichts.
Kann er die _template.csv nicht lesen und was den bus error angeht, habe ich keine Ahnung was das bedeuten soll.
Hat jemand vielleicht die gleichen Fehler schon gehabt und weiss hierfür eine Lösung?
Wäre für jede Hilfe dankbar!
Gruß
Claus
Wieso "kann die... nicht lesen" ?
Einfache Textdatei.
Tipp: In OpenOffice importieren, dort editieren.
LG
pah
Hallo pah,
danke für die Antwort. Bin nun schon ein paar Schritte weiter gekommen. Das liefert mir ebbst mittlerweile.
015-09-26 22:17:04.202 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:05.218 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:08.531 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:08.725 [update notice] unknown BC cmd: 10fe100a0c110300009d21010000203100
2015-09-26 22:17:09.341 [update notice] unknown BC cmd: 10fe100a0e10030000000000000000c2010000
2015-09-26 22:17:09.608 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:11.017 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:11.621 [update notice] unknown BC cmd: 10fe050d0a284545001c1c1c1c1c1c
2015-09-26 22:17:12.207 [update notice] unknown BC cmd: 10fe080108b32c008000009a1c
2015-09-26 22:17:12.815 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:13.030 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:14.046 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:17.359 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:18.469 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:18.662 [update notice] unknown BC cmd: 10fe100a0c11006e000000000000005700
2015-09-26 22:17:19.280 [update notice] unknown BC cmd: 10fe100a0e10005b011e01bf010000de010000
2015-09-26 22:17:19.892 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:20.502 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:21.298 [update notice] unknown MM cmd: 100305010a002e000b000000000000
2015-09-26 22:17:21.750 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:21.986 [update notice] unknown MM cmd: 101305010a0000000b000000000100
2015-09-26 22:17:22.583 [update notice] unknown BC cmd: 10fe0802080000002d00000000
2015-09-26 22:17:22.844 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:26.155 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:27.049 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:27.265 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:28.017 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:28.725 [update notice] unknown BC cmd: 10fe100a0c11016e000000000000005000
2015-09-26 22:17:29.342 [update notice] unknown BC cmd: 10fe100a0e10015b01000000000000de010000
2015-09-26 22:17:30.594 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:31.214 [update notice] unknown MM cmd: 100305020101
2015-09-26 22:17:31.703 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:31.855 [update notice] unknown MM cmd: 101305020101
2015-09-26 22:17:32.446 [update notice] unknown BC cmd: 10fe070009000b06262326090615
2015-09-26 22:17:35.001 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:35.189 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:35.889 [update notice] unknown BC cmd: 10fefe010a53453630202045204f4b
2015-09-26 22:17:36.094 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:36.564 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:38.725 [update notice] unknown BC cmd: 10fe100a0c110200009e21010200213500
2015-09-26 22:17:39.343 [update notice] unknown BC cmd: 10fe100a0e10020000000009010000c201c800
2015-09-26 22:17:39.449 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:40.501 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:41.252 [update notice] unknown MM cmd: 100305010a002e000b000000000000
2015-09-26 22:17:41.862 [update notice] unknown MM cmd: 101305010a0000000b000000000100
2015-09-26 22:17:42.459 [update notice] unknown BC cmd: 10fe080108b32c008000009a1c
2015-09-26 22:17:43.065 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:43.797 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:44.081 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:44.907 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:48.220 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:48.694 [update notice] unknown BC cmd: 10fe100a0c110300009e21010000203100
2015-09-26 22:17:49.375 [update notice] unknown BC cmd: 10fe100a0e10030000000000000000c2010000
2015-09-26 22:17:49.481 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
015-09-26 22:17:04.202 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:05.218 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:08.531 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:08.725 [update notice] unknown BC cmd: 10fe100a0c110300009d21010000203100
2015-09-26 22:17:09.341 [update notice] unknown BC cmd: 10fe100a0e10030000000000000000c2010000
2015-09-26 22:17:09.608 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:11.017 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:11.621 [update notice] unknown BC cmd: 10fe050d0a284545001c1c1c1c1c1c
2015-09-26 22:17:12.207 [update notice] unknown BC cmd: 10fe080108b32c008000009a1c
2015-09-26 22:17:12.815 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:13.030 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:14.046 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:17.359 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:18.469 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:18.662 [update notice] unknown BC cmd: 10fe100a0c11006e000000000000005700
2015-09-26 22:17:19.280 [update notice] unknown BC cmd: 10fe100a0e10005b011e01bf010000de010000
2015-09-26 22:17:19.892 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:20.502 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:21.298 [update notice] unknown MM cmd: 100305010a002e000b000000000000
2015-09-26 22:17:21.750 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007d05
2015-09-26 22:17:21.986 [update notice] unknown MM cmd: 101305010a0000000b000000000100
2015-09-26 22:17:22.583 [update notice] unknown BC cmd: 10fe0802080000002d00000000
2015-09-26 22:17:22.844 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:26.155 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:27.049 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:27.265 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:28.017 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:28.725 [update notice] unknown BC cmd: 10fe100a0c11016e000000000000005000
2015-09-26 22:17:29.342 [update notice] unknown BC cmd: 10fe100a0e10015b01000000000000de010000
2015-09-26 22:17:30.594 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:31.214 [update notice] unknown MM cmd: 100305020101
2015-09-26 22:17:31.703 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:31.855 [update notice] unknown MM cmd: 101305020101
2015-09-26 22:17:32.446 [update notice] unknown BC cmd: 10fe070009000b06262326090615
2015-09-26 22:17:35.001 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:35.189 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:35.889 [update notice] unknown BC cmd: 10fefe010a53453630202045204f4b
2015-09-26 22:17:36.094 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:36.564 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:38.725 [update notice] unknown BC cmd: 10fe100a0c110200009e21010200213500
2015-09-26 22:17:39.343 [update notice] unknown BC cmd: 10fe100a0e10020000000009010000c201c800
2015-09-26 22:17:39.449 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:40.501 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:41.252 [update notice] unknown MM cmd: 100305010a002e000b000000000000
2015-09-26 22:17:41.862 [update notice] unknown MM cmd: 101305010a0000000b000000000100
2015-09-26 22:17:42.459 [update notice] unknown BC cmd: 10fe080108b32c008000009a1c
2015-09-26 22:17:43.065 [update notice] unknown MM cmd: 031005030a01000000451cff3f0000
2015-09-26 22:17:43.797 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:44.081 [update notice] unknown MM cmd: 131005030a011a000045ffff3f4300
2015-09-26 22:17:44.907 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
2015-09-26 22:17:48.220 [update notice] unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500007e05
2015-09-26 22:17:48.694 [update notice] unknown BC cmd: 10fe100a0c110300009e21010000203100
2015-09-26 22:17:49.375 [update notice] unknown BC cmd: 10fe100a0e10030000000000000000c2010000
2015-09-26 22:17:49.481 [update notice] unknown MS cmd: 011506210402c90040 / 0a49c10000060000000500
Der ebusctl scan bringt dies:
06;TEM;MB61 ;0131;0000
08;TEM;WE_1 ;3632;3030
15;TEM;20097;0375;0102
18;TEM;WE_2 ;3632;3030
Jetzt liegt es wohl "NUR" noch an den richtigen CSV-Dateien
LG
Claus
@Jojo11
Na super wenn der Nachbau nun funktioniert. Mit dem bekommst du auch keinen CRC Error mehr, somit ist auch kabeltechnisch alles soweit ok bei dir.
Da ja nicht alle Vaillant Geräte 100% die gleichen Spannungen am eBus liefern, wird vermutlich auch ein erneutes einschicken des Gerätes wenig Erfolg versprechen. Mache es so wie John es vorgeschlagen hat und kalibriere das Gerät direkt an deiner Therme, dann wird auch dieses Gerät wieder funktionieren. Da kann auch die Firma nichts dafür, die stellen halt auf die Busnorm ein was auch richtig ist. Bei größeren Abweichungen geht es dann nicht zu 100%.
Ich bin sicher, wenn ich dir jetzt meinen Konverter geben würde, dann kämen die gleichen Fehler wie bei dir. Unterliegt halt alles einer Streuung, aber dafür ist das Poti ja da um individuelle Anpassungen durchführen zu können. Die Arbitration Error sind normal, aber die CRC nicht. Es ist immer schön, wenn man ein zweites Gerät hat, dann kann man den Fehler schnell eingrenzen und hat eins auf Reserve!
LG
Reinhart
Hallo,
das Teil ist jetzt mal ein paar Stunden durch gelaufen und ich hatte nicht einen CRC-Fehler, was sehr erfreulich ist :)
Bisher wusste ich nicht, dass ich mit dem Poti auch eine Feineinstellung durchführen kann. Ich war davon ausgegangen, dass es "digital" ist (geht oder eben nicht). Daher könnte ich den kommerziellen sicherlich auch wieder zur besseren Zusammenarbeit überreden ;D
Aber so ist es natürlich auch gut. Jetzt brauche ich nur noch ein ordentliches Gehäuse.
schöne Grüße
Jo
Hallo,
mir ist aufgefallen, dass mein Eigenbauadapter ab und zu aussteigt. Der ebusd läuft dann zwar noch, aber als Rückgabe bekommt man nur "ERR: no signal". Habe vorerst mal nichts an der Poti-Trimmung geändert. Ein einfacher Neustart des ebusd reicht, um ihn wieder zum Laufen zu bewegen. Dazu habe ich mir eine kleine Automatik gebastelt, die den ebusd neu startet, wenn z.B. die Aussentemperatur nicht mehr aktualisiert wird:
define ebusd_restart notify ebusd_restart {\
my $tmp='system('.chr(34).'sudo /etc/init.d/ebusd restart'.chr(34).')';;\
fhem("{$tmp}");;\
}
define ebusd_heartbeat notify VC206r:Aussentemperatur:.* {\
fhem("delete at_ebusd_restart") if (Value("at_ebusd_restart") ne "");;\
fhem("define at_ebusd_restart at +00:05:00 trigger ebusd_restart");;\
}
Vielleicht hilft es ja dem einen oder anderen.
schöne Grüße
Jo
Hallo an Alle,
jezt muss ich leider hier auch mal eingrätschen.
Ich sitze nun einige Tage und versuche meine Vaillant Heizung über den selbstbau-ebus Koppler an einem Raspberry PI mit ebusd auszulesen.
Soweit so gut. ebusd läuft, der Rest des Busses (Heizung, Aussenfühler mit DCF77 und VRC 470 ) läuft normal. Leider empfange ich geine gültigen Daten.
Meine Syncronsignale sind nicht "AA" sondern "AB" ???? Was könnte hier der Fehler sein ? Die Signale sehen mit dem Oszi überprüft auf dem BUS genauso wie hinter dem Koppler aus. Scheint, als wird hier ein Bit verschluckt oder dazu erfunden. Ich weiß nicht mehr weiter....
Gruß Mirko
Könnte ein Problem bei der Einstellung des seriellen USB-Ports sein.
LG
pah
Danke für die schnelle Antwort. Aber was kann ich noch einstellen?
Com-Port ist eingestellt auf 2400 Baud, 8n1. Unter Windows am anderen Rechner mit ebusconnector das gleiche Problem. Nur "AB" statt "AA". Was kann ich da noch ändern. Hab am Ende des Ebus-Adapters (Eigenbau) einen Ser->USB wandler mit FT232, kann hier noch ein Fehler liegen?
Hast Du die richtige Spannung am USB-Adapter eingestellt? Manche können zwischen 3,3 V und 5 V "gejumpered" werden.
schöne Grüße
Jo
So... alles umgebaut.
Hab meinn Bastelkoppler in den Müll gehauen, fliegende minimalschaltung auf dem Steckbrett aufgebaut und siehe da, ich bekomme Daten :-)
Leider sehr viele "unknown MS cmd: ....", Außentemp, Zeit usw. kommen aber korrekt an. Welches .csv File passt denn für eine Vaillant VCW 25 ?
Werde mal noch etwas puzzlen, die Schaltung momentan ist um einiges einfacher und läuft jetzt mit einem "normalen" Seriell-USB Wandler RS232-USB.
Gruß Mirko
@SuMiHe
ich habe die VCW 246 mit der Calormatic 430, aber die Grunddaten der Therme sollten von der bai.csv schon passen. Die Calormatic 430 passt auch für die 470.
Ich hänge dir alle meine csv hier an, in der Calormatic sind auch die Zeitprogramme von der 470 drinnen.
Versuche es einfach und schaue wieviele "unknown" dann noch übrig bleiben.
LG
Reinhart
Man das ging schnell.
Erst mal vielen Dank für die schnelle Hilfe hier von allen. Super !!!
Ist schon ein Ende besser. Rest kann ich dann in Ruhe rausfummeln....
Danke !
Gruß Mirko
freut mich wenn es nun so halbwegs passt, bei mir verbleiben mit diesen Konfigs nur 2-3 "unknown" die mir noch fehlen.
Da bis jetzt alles funktioniert was ich benötige, habe ich die noch nie herausgesucht!
2015-10-05 17:31:41.106 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-10-05 17:31:44.897 [update notice] update bc Mode QQ=10: standby
2015-10-05 17:31:48.923 [update notice] update bai StatusTHER QQ=10: 64.0;52.0;15.938;54.0;43.0;2
2015-10-05 17:31:50.926 [update notice] unknown MS cmd: 1008b5040100 / 0a00111019fffffffff00f
2015-10-05 17:31:51.201 [update notice] unknown MS cmd: 1008b5110102 / 05033c8c466c
2015-10-05 17:31:54.948 [update notice] update bc Mode QQ=10: standby
2015-10-05 17:31:58.975 [update notice] update bai StatusTHER QQ=10: 64.0;52.0;15.938;53.0;43.0;2
2015-10-05 17:32:00.957 [update notice] update broadcast outsidetemp QQ=10: 16.438
2015-10-05 17:32:05.023 [update notice] update bc Mode QQ=10: standby
LG
Reinhart
ZitatWerde mal noch etwas puzzlen, die Schaltung momentan ist um einiges einfacher
Äh ja ? Was soll an meinem Schaltungsentwurf noch "einfacher" zu machen sein ? Das würde mich jetzt doch mal interessieren.
LG
pah
Einfacher war falsch formuliert. Ist mit rumliegenden Bauteilen zusammengefrickelt. Hatte kein 4011 o. 7400 mehr und hab mein USB Interface zerschossen. Da musste ich schnell was für ein herkömmliches RS233-USB Adapter zusammensuchen. Mehr durch probieren als wissen
Zitat von: Reinhart am 05 Oktober 2015, 17:39:58
freut mich wenn es nun so halbwegs passt, bei mir verbleiben mit diesen Konfigs nur 2-3 "unknown" die mir noch fehlen.
Da bis jetzt alles funktioniert was ich benötige, habe ich die noch nie herausgesucht!
2015-10-05 17:31:41.106 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-10-05 17:31:44.897 [update notice] update bc Mode QQ=10: standby
2015-10-05 17:31:48.923 [update notice] update bai StatusTHER QQ=10: 64.0;52.0;15.938;54.0;43.0;2
2015-10-05 17:31:50.926 [update notice] unknown MS cmd: 1008b5040100 / 0a00111019fffffffff00f
2015-10-05 17:31:51.201 [update notice] unknown MS cmd: 1008b5110102 / 05033c8c466c
2015-10-05 17:31:54.948 [update notice] update bc Mode QQ=10: standby
2015-10-05 17:31:58.975 [update notice] update bai StatusTHER QQ=10: 64.0;52.0;15.938;53.0;43.0;2
2015-10-05 17:32:00.957 [update notice] update broadcast outsidetemp QQ=10: 16.438
2015-10-05 17:32:05.023 [update notice] update bc Mode QQ=10: standby
LG
Reinhart
wenn Du ein unknown (MS cmd: 1008b5110102 ....) weniger haben mächtest, dann Bitte:
#my Custom DEFS
*myc,myCustom,,,10,08,B511,,,,,,,,,,,,,,,,,,,,,,,,,
myc,,Status02,Mode/maxTemp/ReglerCurrentTEMP/maxTemp/ReglerCurrentTemp,,,,02,,,hwmode;temp0;temp1;temp0;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Das baust Du in die broadcast.csv ein.
Kurze Erklärung:
1008b5110102 /
05033c8c466c05=Länge
03=Status (0=disabled;1=on;2=off;3=auto) *Achtung: !Annahme!
3c=Maximaler Einstellwert der Solltemperatur des Heizungsvorlaufs
8c=Aktuelle Speicherladetemperaturbegrenzung (Vorlaufsolltemperatur im Speicherbetrieb) am Regler der Therme
46=Speicherladetemperaturbegrenzung (Vorlaufsolltemperatur im Speicherbetrieb) Werkseinstellung: 80 °C
6c=Aktueller Einstellwert der Solltemperatur des Heizungsvorlaufs am Regler der Therme
Hier meine broadcast.csv (Dann ist deine Definition:
bai StatusTHER auch obsolet.)
# type (r[1-9];w;u),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment
*b,broadcast,,,,FE,,,,,,,,,,,,,,,,,,,,,,,,,,
b,,datetime,Datum/Uhrzeit,,,0700,,outsidetemp,,temp2,,,,time,,btime,,,,date,,bdate,,,,,,,,,
r;b,broadcast,ident,Identifikation,,,0704,,manufacturer,,UCH,0x06=Dungs;0x0f=FH Ostfalia;0x10=TEM;0x11=Lamberti;0x14=CEB;0x15=Landis-Staefa;0x16=FERRO;0x17=MONDIAL;0x18=Wikon;0x19=Wolf;0x20=RAWE;0x30=Satronic;0x40=ENCON;0x50=Kromschröder;0x60=Eberle;0x65=EBV;0x75=Grässlin;0x85=ebm-papst;0x95=SIG;0xa5=Theben;0xa7=Thermowatt;0xb5=Vaillant;0xc0=Toby;0xc5=Weishaupt,,,,,id,,,Geräte-ID,software,,PIN,,,Software-Version,hardware,,PIN,,,Hardware-Version
w,broadcast,ident,Identifikation,,FE,0704,,,,,,,,,,,,,,,,,,,,,,,,,
b,,error,Fehlernachricht,,,FE01,,error,,STR:10,,,,,,,,,,,,,,,,,,,,,
b,,netresetstate,Reset Netzwerkzustand,,,FF00,,,,,,,,,,,,,,,,,,,,,,,,,
b,,netresetcfg,Reset Netzwerkkonfiguration,,,FF01,,,,,,,,,,,,,,,,,,,,,,,,,
b,,netloss,Ausfall Teilnehmer,,,FF02,,,,,,,,,,,,,,,,,,,,,,,,,
#,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
# Vaillant specific,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
*b,broadcast,,,,FE,B516,,,,,,,,,,,,,,,,,,,,,,,,,
b,,vdatetime,Datum/Uhrzeit,,,,00,time,,BTI,,,,date,,BDA,,,,,,,,,,,,,,,
b,,outsidetemp,Außentemperatur,,,,01,,,temp2,,,,,,,,,,,,,,,,,,,,,
*b,broadcast,,,,FE,B505,,,,,,,,,,,,,,,,,,,,,,,,,
b,,hwStatus,Status Warmwasser,,,,27,,,onoff,,,,VF1,,temp0,,,,,,onoff,,,,,,,,,
#my Custom DEFS
*myc,myCustom,,,10,08,B511,,,,,,,,,,,,,,,,,,,,,,,,,
myc,,Status01,VL/RL/AussenTemp/VLWW/RLWW/Status,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
myc,,Status02,Mode/maxTemp/ReglerCurrentTEMP/maxTemp/ReglerCurrentTemp,,,,02,,,hwmode;temp0;temp1;temp0;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Neu hinzugekommen ist eigentlich nur das:
#my Custom DEFS
*myc,myCustom,,,10,08,B511,,,,,,,,,,,,,,,,,,,,,,,,,
myc,,Status01,VL/RL/AussenTemp/VLWW/RLWW/Status,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
myc,,Status02,Mode/maxTemp/ReglerCurrentTEMP/maxTemp/ReglerCurrentTemp,,,,02,,,hwmode;temp0;temp1;temp0;temp1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Ach ja, sieht dann bei mir so aus:
[update notice] update myCustom Status01: 29.0;28.0;14.500;31.0;33.0;ok
[update notice] update myCustom Status02: auto;60;75.0;80;60.0
Hab jetzt mal schnell meine Schaltung zu Papier gebracht. Läuft mit einem handelsüblichen USB-Seriell Wandler am RasPi.
Nachteil ich brauche eine zusätzliche USB-Buchse zur Spannungsversorgung des Empfangsteils, habe aber an meinem PI nichts weiter dran. Evtl. kann es ja jemand gebrauchen...
Grad noch einen Fehler entdeckt, D5 im Gleichrichter natürlich umgedreht!
@amunra
Danke für deinen Hinweis und deiner Hilfe, aber der Status02 bringt bei mir eine Fehlermeldung.
pi@raspberry2 ~ $ sudo ebusd --checkconfig
2015-10-07 18:32:03.720 [main notice] Performing configuration check...
Error reading "/etc/ebusd/broadcast.csv" line 19 field 14 value "": ERR: element not found
Erroneous item is here:
"myc","","Status02","Mode/maxTemp/ReglerCurrentTEMP/maxTemp/ReglerCurrentTemp","","","","02","","","hwmode;temp0;temp1;temp0;temp1","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
^
aber wie gesagt, mich stört das nicht, da ich diesen Wert nicht benötige.
LG
Ähm ja, sorry - liegt wohl daran, dass ich bei mir in der _template.csv noch foilgende Definition habe (ja, es geht auch anders...):
hwmode,UCH,0=disabled;1=on;2=off;3=auto,,
Wenn du magst, dann einfach in die _template.csv hinzufügen, dann sollte es gehen.
@Sumihe: Soso, eine Schaltung aus 25 Bauteilen ist einfacher, als eine aus 18 Bauteilen.
Ansichtssache 8)
Mir sind darüber hinaus die stabilisierten 5V Spannung auf der EBUS-Seite wichtig, die brauche ich noch an anderer Stelle.
LG
pah
@amunra
Ja das wars, weil ja die neue Variable "hwmode" nicht definiert war.
2015-10-08 10:47:40.049 [update notice] update myCustom Status01: 35.0;34.0;3.750;40.0;43.0;ok
2015-10-08 10:47:42.088 [update notice] unknown MS cmd: 1008b5040100 / 0a00412414ffffffffc003
2015-10-08 10:47:42.359 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-10-08 10:47:44.085 [update notice] update bc Mode QQ=10: standby
Was machst du eigentlich mit diesen maximalen Grenzwerten? Aber hast recht, das Log sieht jetzt besser aus.
Ich habe alle Messwerte die mich interessieren und ich frage die in 2 Gruppen ab, die einen im 15 Minuten (8 Abfragen) Takt und die anderen (wie Druck, Brennerfehler, Zeitprogramme etc. =20 Abfragen.) alle 120 Minuten. Das macht den Bus wesentlich "stabiler". Ich glaube das einige infolge eines zu raschen Abfragezyklus den Bus einfach überfordern und sich dann die Buserrors Aufgrund der Kollisionen häufen.
Jene User, die sich mit der IT schon vor dem Internet befasst haben (80er Jahren), wissen noch wie langsam eine sog. Mailbox mit 2400 Baud funktioniert hat. Um nur einen ganz normalen Druckertreiber zu laden sind schon mal 3-5 Stunden vergangen. Der Postweg war da unter Umständen schneller wenn man 3-4 Versuche brauchte. Der eBus ist ja ebenfalls eine serielle Schnittstelle mit 2400 Baud und das ist einfach sehr langsam und kann mit dem TCP bei weitem nicht verglichen werden. Für die Gerätekommunikation ist das sicherlich ausreichend und die Stärke des eBus liegt ja in der Einfachheit des Bussystems. Was Juhu und John da aus dem eBus geholt haben ist eh schon ein kleines Wunder.
Der GAEBUS ist zwar eine tolle Sache und steigert den Komfort, verleitet aber doch einige viel zu viele Daten abzufragen, die man letztlich dann eh kaum benötigt. Das ist jetzt meiner Ansicht einer der Hauptfehler der vielen Errors über die sich mancher hier beklagt. Weniger ist oft mehr.
LG
Hallo Reinhart,
Zitat von: Reinhart am 08 Oktober 2015, 11:29:25Was machst du eigentlich mit diesen maximalen Grenzwerten? Aber hast recht, das Log sieht jetzt besser aus.
Bisher noch nichts.
Ich habe die Werte irgendwann Anfang des Jahres ermittelt - nach dem Motto Informationen die da sind, und nicht abgefragt werden müssen, entlasten den Bus.
Ferner liegt mein Fokus, sofern es die Zeit zulässt, in Monitoring (z.B. Wasserdruck, Wartung etc.) und Erfassung von Daten (Herzkurve, Vorlauf, Rücklauf, Pumpenstatus etc), um evtl. Optimierungspotenziale zu erkennen/ermitteln und nicht in der Steuerung der Theme.
Zitat von: Reinhart am 08 Oktober 2015, 11:29:25
2015-10-08 10:47:40.049 [update notice] update myCustom Status01: 35.0;34.0;3.750;40.0;43.0;ok
2015-10-08 10:47:42.088 [update notice] unknown MS cmd: 1008b5040100 / 0a00412414ffffffffc003
2015-10-08 10:47:42.359 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-10-08 10:47:44.085 [update notice] update bc Mode QQ=10: standby
2015-10-08 10:47:42.088 [update notice] unknown MS cmd: 1008b5040100 / 0a00412414ffffffffc003Wenn du den Eintrag auch noch aufgelöst haben möchtest, dann kannst du folgende Definition bei dir einbauen:
*myc1,myCustom1,,,10,08,B504,,,,,,,,,,,,,,,,,,,,,,,,,
myc1,,Status11,,,,,00,,,dcfstate;BCD;BCD;BCD;BCD;BCD;days2;BCD;temp2,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Kurze Erklärung:
0a00412414ffffffffc0030a=>Länge
00=>DCF77-Status
41=>Sekunden
24=>Minuten
14=>Stunden
ff=>Tag
ff=>Monat
ff=>Wochentag
ff=>Jahr
c0 und 03=>Aussentemperatur
Bei mir sieht das so aus:
2015-10-09 21:42:58.693 [update notice] update myCustom1 Status11: valid;1;43;21;9;10;Fr;15;12.688Viele Grüße
Arthur
Ach, und wenn wir schon dabei sind.
Das hier:
*myc2,myCustom2,,,10,08,B512,,,,,,,,,,,,,,,,,,,,,,,,,
myc2,,Pumpenstatus,Vaillant: Pumpenstatus,,,,00,,,pumpstate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
kannst Du vielleicht auch noch einbauen ;o)
Sieht bei mir so aus:
2015-10-09 22:10:17.283 [update notice] update myCustom2 Pumpenstatus: ok
VG Arthur
Danke amunra, funktioniert perfekt!
Die _templates habe ich um "days2" erweitern müssen, aber nun habe ich absolut keine "unknown" mehr, der gesamte Broadcast ist nun in Klartext aufgelöst.
update myCustom1 Status11: nosignal;12;37;23;-;-;-;-;10.812
nosignal, weil kein DCF Empfänger angeschlossen ist.
LG
Reinhart
An die EHP Besitzer:
Könntet ihr mir bitte die Ergebnisse folgender Abfragen mitteilen?
ebusctl r -d 08 ident
ebusctl r ApplianceCode
ebusctl r HydraulicScheme
ebusctl r ElectricWiringDiagram
ebusctl r CfgHeatSinkType
Hallo John30,
nach langer Pause bin ich heute mal probeweise von 1.0 auf 1.2 umgestiegen. Mit ziemlich enttäuschendem Resultat - der ebusd meldet permanent im Abstand von jeweils ein paar Sekunden:
2015-10-11 15:38:20.028 [bus error] signal lost
2015-10-11 15:38:23.062 [bus notice] signal acquired
Irgendeine Ahnung, woran das liegen kann ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 11 Oktober 2015, 15:39:58
nach langer Pause bin ich heute mal probeweise von 1.0 auf 1.2 umgestiegen. Mit ziemlich enttäuschendem Resultat - der ebusd meldet permanent im Abstand von jeweils ein paar Sekunden:
2015-10-11 15:38:20.028 [bus error] signal lost
2015-10-11 15:38:23.062 [bus notice] signal acquired
Irgendeine Ahnung, woran das liegen kann ?
Hm, klingt nach einem Timing Problem.
Wie sehen denn die Startparameter von ebusd genau aus?
Und ist das 1.2.0 oder der aktuelle source von github?
Naiverweise dieselben Parameter wie für 1.0 - nur das Device wird gesetzt.
Und ich habe nicht den aktuellen Stand, sondern das Paket vom 25. Mai.
Ich binmir ziemlich sicher, dass das nur eine Einstellfrage ist - werde aber den Versuch jetzt erst einmal ein paar Wochen aufschieben, muss dringend einige Sache fertigstellen.
LG
pah
Hallo pah!
Ich habe am 27.05 um 22:40 Uhr die Version 1.2 ausgecheckt und am Raspi compiliert. Ich hänge dir die ebusd, ebusctl und ebusfeed und compilierter Form hier an wenn du noch was testen willst, zumindest kannst die Filelänge vergleichen. Diese Versionen laufen bei mir fehlerfrei (/usr/bin).
pi@raspberry2 /etc/ebusd $ ebusctl -V
ebusctl of ebusd 1.2.0
pi@raspberry2 /etc/ebusd $ ebusd -V
ebusd 1.2.0
pi@raspberry2 /etc/ebusd $
LG
Reinhart
Hi John30,
die Ergebnisse, ich bin allerdings noch auf version 1.1.0
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl -V
ebusctl of ebusd 1.1.0
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r -d 08 ident
Vaillant;EHP00;0419;7201
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r Appliancecode
38
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r HydraulicScheme
4
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r ElectricWiringDiagram
3
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r CfgHeatSinkType
mixer
l.g. erwin
Zitat von: Prof. Dr. Peter Henning am 11 Oktober 2015, 15:39:58
Hallo John30,
nach langer Pause bin ich heute mal probeweise von 1.0 auf 1.2 umgestiegen. Mit ziemlich enttäuschendem Resultat - der ebusd meldet permanent im Abstand von jeweils ein paar Sekunden:
2015-10-11 15:38:20.028 [bus error] signal lost
2015-10-11 15:38:23.062 [bus notice] signal acquired
Irgendeine Ahnung, woran das liegen kann ?
LG
pah
Hallo Pah,
selbes Problem wie bei mir! Hatte die neue 1.2 am Sonntag direkt aus der Source von John kompiliert. Ich bin bisher auf der 1.1.
Ich konnte FHEM nicht dazu bewegen Daten auszulesen.
Mit ebusctl auf der Konsole konnte ich Daten lesen. Nur mittels ECMD kam nichts an. Das Gaebus-Modul funktioniert mit der 1.2.
FHEM hat das aktuellste Update. Somit hat es irgendwas mit ECMD <--> Ebusd 1.2 zu tun.
Ich bin wieder zurück auf 1.1 dort läuft alles.
Vielleicht helfen ja diese Infos...
Gruß
Matthias
Das ist eine wenig hilfreiche Nebelkerze. ::)
Die "Signal Lost"-Meldungen sind vollkommen unabhängig von ECMD, siehe nächsten Post.
LG
pah
ACHTUNG, EBUS-User mit ECMD-Anbindung:
am 3.10.2015 hat Boris Neubert ein Update des Moduls 66_ECMD.pm committed, bei dem er die Trennzeichen für Mehrfachkommandos flexibel einstellbar gemacht hat.
Die Mehrfachkommandos spielen in meinen ECMD-Klassendefinitionen eine wichtige Rolle - Trennzeichen ist dort jeweils ein \000. Leider funktioniert die neue Version des Moduls aber auch nicht mit korrekt eingestelltem "\000"-Separator für Mehrfachkommandos in Zusammenarbeit mit ebusd - irgendetwas stimmt da noch nicht. Als Folge wird von den Mehrfachkommandos immer nur das erste ausgeführt.
Ich habe deshalb nach längerem Probieren an der Konfiguration die alte Version des ECMD-Moduls wieder hergestellt.
LG
pah
Hallo,
die Ursache habe ich bereits identifiziert, der Fix kommt am Wochenende. Bitte solange auf die Vorversion zurück gehen, wenn 0 als requestSeparator benötigt wird.
Viele Grüße
Boris
OK, Danke.
LG
pah
Zitat von: erwin am 13 Oktober 2015, 08:52:22
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl -V
ebusctl of ebusd 1.1.0
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r -d 08 ident
Vaillant;EHP00;0419;7201
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r Appliancecode
38
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r HydraulicScheme
4
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r ElectricWiringDiagram
3
pi@CL-RPI-1 /opt/ebusd/bin $ ./ebusctl r CfgHeatSinkType
mixer
Ist das eine Luft-Wasser WP?
Zitat von: Prof. Dr. Peter Henning am 11 Oktober 2015, 17:54:48
Naiverweise dieselben Parameter wie für 1.0 - nur das Device wird gesetzt.
Und ich habe nicht den aktuellen Stand, sondern das Paket vom 25. Mai.
Ich binmir ziemlich sicher, dass das nur eine Einstellfrage ist - werde aber den Versuch jetzt erst einmal ein paar Wochen aufschieben, muss dringend einige Sache fertigstellen.
Okay, also den Code vom 25. Mai werd ich jetzt nicht mehr debuggen, seit dem hat sich sehr viel getan.
Bitte bei Gelegenheit versuchen, das mit dem aktuellen git zu reproduzieren.
Verständlich. Muss aber jetzt wieder etwa warten ...
LG
pah
Habe die Sache mit dem requestSeparator gefixt und eingecheckt. Ab sofort im Repo oder ab morgen per update.
Viele Grüße
Boris
ZitatIst das eine Luft-Wasser WP?
Hi John,
ja das ist eine Luft -> Sole -> Wasser WP,
mit 2 Ausseneinheiten und Pufferspeicher.
l.g. erwin
Hallo,
hat jemand von Euch eine Möglichkeit gefunden, die heizungsinterne Zirkulationspumpe außerhalb des einprogrammierten Zeitfensters manuell ein-/auszuschalten? Ich finde dazu nichts, aber praktisch wäre es. Speziell interessiert es mich für eine VC206.
schöne Grüße
Jo
Hallo Forum-Mitglieder,
ich habe von Vaillant ein EcoPower 1.0 Mikro BHKW. Diese Anlage besteht aus einem Wärmespeicher mit Trinkwasserstation vom Typ VPM 20/25, einer Gastherme ecoTec Exklusiv VC DE 146 4-7 und dem Systemregler 1.0. Diese drei Geräte sind mit dem eBus untereinander verbunden.
Der Honda Motor bleibt aussen vor, weil der über einen CAN Bus mit dem Regler ,,redet".
Der Systemregler den Vaillant verbaut kommt von Saia-Burgess.
Jetzt meine Fragen:
Kann man generell einen Systemregler via eBus abfragen und bekommt man alle Informationen ausgelesen oder ist es üblich, dass der eBus nur die Daten liefert die die anderen Komponenten wie Therme, Trinkwasserstation zum Betrieb benötigen?
Der Hintergrund ist der, dass ich einige Daten wie Aussentemperatur, sowie Speichertemperatur auslesen möchte. Aber genau diese Fühler sind direkt auf dem Systemregler aufgelegt. Somit weiß der Regler diese Werte ohne den eBus abzufragen.
Kann es somit sein, dass ich diese Daten nicht über den eBus aus dem Regler abfragen kann?
Ich wollte nicht für 80 Euro einen eBus USB Koppler kaufen um dann nach 100 oder mehr Stunden Revers Engineering festzustellen, dass der Regler diese Daten nicht sendet.
Was ist Eure Einschätzung, bekomme ich über eBus die Daten aus dem Regler?
Mir ist klar, dass Vaillant eine unvorteilhafte eBus Implementierung aus Sicht Hausautomation hat, aber ich würde den steinigen Weg gehen wenn es Erfolg versprechend ist.
Gruß Andreas
Das sollte man jemanden fragen, der dieses Gerät ebenfalls hat. Wobei dafür die vage Bezeichnung "Systemregler 1.0" vermutlich nicht ausreicht. Außerdem ist es eigentlich nicht nötig, gleich auch noch die Implementierung von Vaillant schlecht zu reden - von unserer Arbeit, dem Reverse Engineering, ganz zu schweigen. Kein guter Einstieg.
pah
Zitat von: Prof. Dr. Peter Henning am 19 Oktober 2015, 06:11:31
Außerdem ist es eigentlich nicht nötig, gleich auch noch die Implementierung von Vaillant schlecht zu reden - von unserer Arbeit, dem Reverse Engineering, ganz zu schweigen. Kein guter Einstieg.
pah
ja neee.....hat der herr professor wieder einen losgelassen.......
Hat schon jemand das neu gefixte ECMD Modul von Dr.Boris getestet?
Ich glaube da steckt noch ein Fehler drinnen!
folgende ECMD Definition liefert bei mir einen Fehler:
#HKurve
define HKurve ECMDDevice bai00.class
attr HKurve IODev EBUS
attr HKurve group Vaillant
attr HKurve icon temp_control
attr HKurve room Vaillant
und hier die bai00.class
# Heizkurve lesen
get HKurve cmd {"r -f Hc1HeatCurve\n"}
get HKurve expect "\d+\.\d+\n"
get HKurve postproc { sprintf("%3.1f",$_) }
und hier das Log:
2015.10.19 12:30:13 2: EBUS: first attempt to read timed out, trying to close and open the device.
2015.10.19 12:30:13 3: Opening EBUS device 10.0.0.6:8888
2015.10.19 12:30:13 3: EBUS device opened
2015.10.19 12:30:16 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2015.10.19 12:30:16 1: [EBUS] Recover triggered from notify EBUS.Watchdog, attempt No. 0
2015.10.19 12:30:16 1: EBUS: no answer received (wrote "r -f Hc", expected \d+\.\d+\n)
2015.10.19 12:30:16 1: EBUS: unexpected answer "ERR: element not found\n\n" received (wrote "HeatCurve\n", expected \d+\.\d+\n)
2015.10.19 12:30:37 1: EBUS: unexpected answer "32.0;32.0;8.375;38.0;42.0;0\n\n" received (wrote "read StatusTHER\n", expected .*)
2015.10.19 12:30:41 2: EBUS: first attempt to read timed out, trying to close and open the device.
Die eBus Abfrage läuft in ein Timeout, weil versucht wird den Wert "Hc" abzufragen, der abzufragende Wert lautet aber "Hc1HeatCurve".
So wie ich das sehe, wird vermutlich nach dem ersten Vorkommen eines Numerischen Wertes der String abgebrochen, den andere Datenpunkte ohne Numerischen Inhalt funktionieren.
Vielleicht kann sich das bitte Boris nochmals anschauen.
LG
Reinhart
habe mir die Definition vom ECMD jetzt nochmals genau angesehen und die Änderung im Source verglichen.
Wird der requestSeparator richtig angegeben, dann funktioniert auch der Split korrekt!
attr EBUS requestSeparator 000
Ich hatte in meiner Definition den Seperator 1 angegeben und da dies früher offensichtlich nicht funktioniert hatte ist mir der Fehler in meiner Konfiguration auch nie aufgefallen.
ECMD funkfioniert jetzt perfekt, auch die von pah angesprochenen Mehrfachabfragen.
LG
Reinhart
Hallo Leute,
ich habe einen wasserführenden Hark-Kamin mit dem Speicherladeregler Typ PS 5511 SZ vom Fa. TEM zur Heizungsunterstützung im Einsatz. An diesem TEM-Regler hängt ein selbstgebauter eBus-Serial-Adapter, der bisher nur an der Windoof-Software läuft.
Nuach dem Umstieg auf FHEM bin ich auf diesen tollen Thread zum ebusd aufmerksam geworden und möchte fragen, ob es zum TEM-Regler evtl. Konfigurationsdateien gibt, siehe ggf. passende Beiträge:
@Tomy « Antwort #489 am: 20 Februar 2015, 15:25:34 »
Kannst du deine TEM-Konfig-Dateien als Vorlage zur Verfügung stellen (hoffe mein Regler ist ähnlich)?
@John30 « Antwort #523 am: 23 Februar 2015, 23:00:49 »
Gibt es evtl. schon irgendwo TEM-Konfig-Dateien, die ich nicht gefunden habe?
Anhand einer kleinen Hilfestellung könnte ich mich mal an das Entschlüsseln der TEM-eBus-Telegramme machen ...
Wie scannt am sinnvollsten mit dem ebusd ?
Besten Gruß
Hallo Forum-Mitglieder,
Hallo Herr Prof. Dr. Henning,
kleine Anmerkung von meiner Seite.
Es ist eine Tatsache die nicht bewertend ist, wenn ich schreibe, dass die Vaillant Implementierung des eBus unvorteilhaft ist aus Sicht der Hausautomation. Vaillant bewirbt auf vielen Seiten und Beschreibungen die Verwendung des eBus.
Damit eine BHKW Anlage den maximalen Vorteil erwirtschaften kann erfordert so eine Anlage auch Schnittstellen nach aussen (der eBus ist in meinen Augen so eine Schnittstelle), damit andere im Haus befindlichen Stromverbraucher ggf starten können, wenn der Motor Strom produziert. Es geht beim BHKW eigentlich mehr darum andere Verbraucher zu steuern / starten und nicht andere Brenner oder Warmwasser-Speicher zu betreiben.
Ich kann auch viele Gründe für eine proprietäre Implementierung des eBus finden, wie zum Beispiel geringer Entwicklungsaufwand, schnelle und einfache Anpassung bei betrieblichen Änderungen, geringe Supportkosten weil keine Abstimmungen mit anderen Herstellern notwendig ist und somit geringere Produktkosten, besserer Rentabilität für das Unternehmen usw. All dies sind Vorzüge, nur eben keine aus Sicht der Hausautomation.
In meinen Augen haben Sie Herr Prof. Dr. Henning die Bewertung vorgenommen mit Ihrer Formulierung, nicht ich.
Zitat von: Prof. Dr. Peter Henning am 19 Oktober 2015, 06:11:31
Das sollte man jemanden fragen, der dieses Gerät ebenfalls hat. Wobei dafür die vage Bezeichnung "Systemregler 1.0" vermutlich nicht ausreicht. Außerdem ist es eigentlich nicht nötig, gleich auch noch die Implementierung von Vaillant schlecht zu reden - von unserer Arbeit, dem Reverse Engineering, ganz zu schweigen. Kein guter Einstieg.
pah
Ich habe auch mit keinem Wort dieses Forum schlecht geredet nur meinen eigenen geschätzten Aufwand dargestellt und die geplante Technik beschrieben wie ich ggf an Informationen kommen möchte. In den BHKW Foren wird das Thema eBus nicht diskutiert bzw es gibt dort nur wenig bis kein Fachwissen zum Protokoll und der Vaillant spezifischen Implementierung.
Diese Forum ist in Bezug auf eBus sicherlich eine gute Wahl.
Zurück zur Technik: Der Regler wird von Vaillant als Systemregler 1.0 bezeichnet. Als Betriebssystem wird scheinbar ein Windows CE verwendet. Die Elektronik bzw. das Computer Modul mit Display kommt von Saia-Burgess. Diese Daten sind durch ablesen der Typenschilder gewonnen worden. Ich kann leider nicht mehr liefern.
Zurück zu meiner Kernfrage: Kann man einen Regler/Master über das eBus Protokoll nach allen Daten fragen oder kann immer nur ein Wert nach dem anderen abfragen sofern man das Register kennt wo die Daten abgebildete sind?
Gruß ecopower_andreas
Zitat von: phantom am 20 Oktober 2015, 15:34:16
ich habe einen wasserführenden Hark-Kamin mit dem Speicherladeregler Typ PS 5511 SZ vom Fa. TEM zur Heizungsunterstützung im Einsatz. An diesem TEM-Regler hängt ein selbstgebauter eBus-Serial-Adapter, der bisher nur an der Windoof-Software läuft.
Gibt es evtl. schon irgendwo TEM-Konfig-Dateien, die ich nicht gefunden habe?
Ich selbst habe daran nicht weitergearbeitet, aber zumindest Hilfestellung zu _templates und Datentypen gegeben.
Zitat von: phantom am 20 Oktober 2015, 15:34:16
Wie scannt am sinnvollsten mit dem ebusd ?
Meinst Du jetzt den Scan nach Teilnehmern?
Das ist ja nichts neues: ebusctl scan && sleep 30 && ebusctl scan result
Wenn Du Datenfelder meinst, das ist ne lange Geschichte. Ich hab mal versucht, im Wiki zu beschreiben, wie man vorgehen kann:
https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files (https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files)
Zitat von: ecopower_andreas am 21 Oktober 2015, 06:41:06
Es ist eine Tatsache die nicht bewertend ist, wenn ich schreibe, dass die Vaillant Implementierung des eBus unvorteilhaft ist aus Sicht der Hausautomation. Vaillant bewirbt auf vielen Seiten und Beschreibungen die Verwendung des eBus.
Deine Formulierung ist m.E. ungünstig gewählt. Ich freue mich darüber, dass Vaillant eBUS verwendet und nicht irgendwas völlig proprietäres. Somit haben wir die Chance, an tonnenweise Daten zu kommen, was andernfalls an unmöglich grenzt.
Ich schätze Du meinst eher die fehlende Transparenz bzw. Offenlegeung der abgegebenen Daten seitens Vaillant. Das ist aus Herstellersicht absolut verständlich und mal ganz ehrlich: wir greifen hier nicht toleriert in das interne Bus-System einer Heizungsanlage ein, mit potentiellen Auswirkungen in jeglichen Facetten...
Zitat von: ecopower_andreas am 21 Oktober 2015, 06:41:06
Ich kann auch viele Gründe für eine proprietäre Implementierung des eBus finden, wie zum Beispiel geringer Entwicklungsaufwand, schnelle und einfache Anpassung bei betrieblichen Änderungen, geringe Supportkosten weil keine Abstimmungen mit anderen Herstellern notwendig ist und somit geringere Produktkosten, besserer Rentabilität für das Unternehmen usw. All dies sind Vorzüge, nur eben keine aus Sicht der Hausautomation.
Was genau ist denn an der Verwendung von eBUS proprietär? Hersteller-spezifische Nachrichten zu nutzen ist von der Grundidee von eBUS ausdrücklich gewünscht und auch notwendig. Und es lassen sich halt nun einfach nicht alle Daten in das vorgegebene Minimalschema pressen.
Zitat von: ecopower_andreas am 21 Oktober 2015, 06:41:06
Zurück zu meiner Kernfrage: Kann man einen Regler/Master über das eBus Protokoll nach allen Daten fragen oder kann immer nur ein Wert nach dem anderen abfragen sofern man das Register kennt wo die Daten abgebildete sind?
Nein, man kann einen Regler nicht nach allen Werten auf einmal fragen. Auch das ist vom Protokoll her gar nicht möglich.
Man muss die Adressen kennen und den Datentyp.
ZitatDiese Daten sind durch ablesen der Typenschilder gewonnen worden. Ich kann leider nicht mehr liefern.
Erstens: Wenn ich mir ein solches System installieren lasse, verfüge ich nicht nur über Typenschilder. Sondern in der Regel auch über Installations- und Wartungsanleitungen, die vom Hersteller mitgeliefert werden. Sogar dann, wenn diese unberechtigterweise vom Installateur mitgenommen wurden, kann man sie sich innerhalb von wenigen Minuten über das Netz beschaffen.
Zweitens: Es gibt sehr viel einfachere Möglichkeiten, den Start des Motors festzustellen, als den Anschluss an den EBus. Und ich bin mir ganz sicher, dass in diesem System auch irgendwo ein Hardware-Ausgang (z.B. ein potenzialfreier Relaiskontakt) vorhanden ist, der genau das signalisiert.
Drittens: "Unvorteilhaft aus Sicht der Hausautomation" soll keine Bewertung sein ? Na, da verstehe ich die deutsche Sprache aber etwas anders... Unabhängig davon ist der EBus sogar sehr vorteilhaft aus Sicht derjenigen, die sich
wirklich mit Hausautomation befassen. Er ist nämlich immerhin sogar so transparent, dass seine Benutzung gut gelingt und vielfältige Anbindungsmöglichkeiten bietet. Da gibt es ganz andere Systeme...
ZitatZurück zu meiner Kernfrage: Kann man einen Regler/Master über das eBus Protokoll nach allen Daten fragen oder kann immer nur ein Wert nach dem anderen abfragen sofern man das Register kennt wo die Daten abgebildete sind?
Ich verstehe die Frage immer noch nicht - was soll denn mit "allen Daten" gemeint sein ? Wer diesen Thread hier auch nur in Auszügen gelesen hat, kennt die diversen Kommandos, kennt auch das Prinzip der Broadcasts über den EBus. Und sollte auch wissen, dass die Vaillant-Systeme sehr unterschiedlich sind. Das bedeutet, dass die so genannte "Kernfrage" nur beantwortbar ist von jemandem, der schon einmal einen EBus in einem System mit genau diesem "Systemregler 1.0" belauscht hat.
pah
ach der "Herr Professor" wieder. Hat keinerlei Ahnung von den neueren Technologien (ich sag nur Crossover- damit hat er sich ja so etwas von geoutet), aber hier fette Sprüche loslassen. Wie gesagt, wenn man keine Ahnung hat, einfach mal.........
Was ist das nur für ein "Professor" ? FÜr Kanalisation und Abwasserreinigung, oder warum kommt von daher immer so viel unqualifiziertes Zeug, was IT angeht.
Vielleicht sollte dieser Witzfigur mal jemand klar machen, dass er hier keineswegs anonym ist.
LG
pah
ach.....nun werden wir wie in der pers. E-Mail beleidigend.......
Dies muß mir niemand sagen, ist mir schon bewusst "Herr Professor". Soll ich Ihnen meine Anschrift geben- möchten Sie mich einmal besuchen. Sie hatten in der Vergangeheit ja bereits einem anderen User gedroht. Muß ich nun Angst haben....uaaahhhhhh.
Ok- Witzfigur, einfach mal nicht so frech sein und den Mund halten. Auch du bist nicht anonym unterwegs, dies sollte man einmal im Auge behalten, bevor man frech wird......
Zitat von: dleinic am 22 Oktober 2015, 12:47:40
ach.....nun werden wir wie in der pers. E-Mail beleidigend.......
Dies muß mir niemand sagen, ist mir schon bewusst "Herr Professor". Soll ich Ihnen meine Anschrift geben- möchten Sie mich einmal besuchen. Sie hatten in der Vergangeheit ja bereits einem anderen User gedroht. Muß ich nun Angst haben....uaaahhhhhh.
Ok- Witzfigur, einfach mal nicht so frech sein und den Mund halten. Auch du bist nicht anonym unterwegs, dies sollte man einmal im Auge behalten, bevor man frech wird......
(http://kind.suicideproject.org/wp-content/uploads/2013/10/aaa-300x225.jpg)
Zitat von: john30 am 21 Oktober 2015, 07:23:45
Ich selbst habe daran nicht weitergearbeitet, aber zumindest Hilfestellung zu _templates und Datentypen gegeben.
Meinst Du jetzt den Scan nach Teilnehmern?
Das ist ja nichts neues: ebusctl scan && sleep 30 && ebusctl scan result
Wenn Du Datenfelder meinst, das ist ne lange Geschichte. Ich hab mal versucht, im Wiki zu beschreiben, wie man vorgehen kann:
https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files (https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files)
Hallo John,
OK, dann muß ich wohl selbst die Messages entziffern ...
Ein ebusctl scan .../result oder ebusctl grab .../result bringt leider gar keine Daten, sondern bleibt stumm bis man ihn mit Ctrl-C abwürgt. Ein ebusctl raw bingt ca. alle 5 Min. folgendes:
QQ ZZ PB SB NN DB CRC
f7 9a 10 20 01 22 5a
f7 9b 10 20 01 22 d5
f7 9c 10 20 01 22 4e
f7 9d 10 20 01 22 c1
lt. eBus-Spezifikation:
QQ: F7 = Master 20 Heizungsregler
ZZ: 9A-9D = Fernsteller 11-14
PB: 10 = TEM-AG Herstellerkodierung
NN: 01 = 1 Daten-Byte
DB: 22 = noch zu entschlüsseln ...
In /etc/ebusd stehen bisher nur _template.csv, broadcast.csv, scan.csv aus deinem Vaillant-Config-Verzeichnis. Diese passen wohl nicht zu meinen TEM-Regler, der wohl keine Broadcasts verschickt, aber auf einen scan nach zumindest diesem einzigen Teilnehmer reagieren könnte.
Ich wollte zunächst die grundlegende Message-Konfig korrekt verstanden haben, bevor ich Daten zum TEM-Regler zur gezielten Datenabfrage sende. Oder gibt es passendere Config-Dateien zum Start?
Bitte um kurze Hilfe, wenn es passt.
Dirk
Tja, hoher Trollfaktor ;D ;D - aber immerhin hat er schon 25 Posts im Forum getätigt, muss ein echter Könner sein.
LG
pah
Zitat von: phantom am 22 Oktober 2015, 16:20:27
OK, dann muß ich wohl selbst die Messages entziffern ...
Ein ebusctl scan .../result oder ebusctl grab .../result bringt leider gar keine Daten, sondern bleibt stumm bis man ihn mit Ctrl-C abwürgt. Ein ebusctl raw bingt ca. alle 5 Min. folgendes:
QQ ZZ PB SB NN DB CRC
f7 9a 10 20 01 22 5a
f7 9b 10 20 01 22 d5
f7 9c 10 20 01 22 4e
f7 9d 10 20 01 22 c1
lt. eBus-Spezifikation:
QQ: F7 = Master 20 Heizungsregler
ZZ: 9A-9D = Fernsteller 11-14
PB: 10 = TEM-AG Herstellerkodierung
NN: 01 = 1 Daten-Byte
DB: 22 = noch zu entschlüsseln ...
In /etc/ebusd stehen bisher nur _template.csv, broadcast.csv, scan.csv aus deinem Vaillant-Config-Verzeichnis. Diese passen wohl nicht zu meinen TEM-Regler, der wohl keine Broadcasts verschickt, aber auf einen scan nach zumindest diesem einzigen Teilnehmer reagieren könnte.
Ich wollte zunächst die grundlegende Message-Konfig korrekt verstanden haben, bevor ich Daten zum TEM-Regler zur gezielten Datenabfrage sende. Oder gibt es passendere Config-Dateien zum Start?
Ich schaue morgen mal nach, was da der letzte Stand war.
Richtig, die Vaillant CSVs passen naturgemäß nicht zu TEM, aber sollten jetzt im ersten Schritt auch nicht schaden.
Also wenn ein Scan keinerlei Ergebnis bringt und der Regler alle 5 Minuten Nachrichten verschickt, auf die er keine Antwort bekommt, dann hast Du wohl ein grundsätzliches Problem mit dem Bus. Welches Interface nutzt Du denn?
Ich frage mich auch, was der TEM-Regler denn steuert, welche anderen Geräte also auf dem EBus sitzen. Darüber wissen wir noch gar nichts - und gerade die oben aufgeführten Messages scheinen mir darauf hinzudeuten, dass der TEM komplett autonom arbeitet und irgendetwas ins Vakuum schickt.
LG
pah
Guten Morgen,
@john30
Das Interface ist ein Eigenbau (eine Mischung aus der eBUS-Spec. 1.3.1 aus 2007 und dem Vorschlag von pah aus dem Thread). Es läuft schon seit 2013, aber bisher nur mit der Windows-Service-Software von TEM zum Auslesen einiger Werte.
@pah
Auch richtig, der TEM-Regler arbeitet autonom und steuert die Pumpen und Ventile des Heizkamins mit Pufferspeicher unabhängig von der Heizung (eine Viessmann Vitronic, um die sich der vcontrold kümmert).
Ziel meines Vorhaben ist es diese beiden Regelkreise zunächst mal zu überwachen und dann durch bessere Abstimmung aufeinander zu optimieren. Der vcontrold liefert seine Werte in eine MySQL-DB, der TEM-Regler sollte dies auch mal machen, um so manchem komischen Regelverhalten der Heizung auf die Spur zu kommen. Mangels Zeit ist dieses Projekt leider liegen geblieben. Doch der Einstieg in FHEM und dieses Forum haben es wieder "hervorgekramt".
Mittels des ebusd möchte ich "einfach" die RAM-Daten des Reglers mit dem Ebus-Befehl 09 00 (PB SB) auslesen und anhand eines Vergleichs mit der TEM-Software zuordnen. Dazu muss ich den ebusd wohl zunächst mit einer passenden Grundkonfiguration versehen. Aus den regelmäßen Telegramme an die Fernsteller könnte ich evtl. bereits Temperaturwerte abgreifen...
Vielleicht läßt sich mein recht undokumentierter Regler doch dazu bewegen seine Daten rauszurücken ...
Gruß Dirk
Zur Info: ebusd, vcontrold, mysqld auf Synology-NAS, FHEM auf Raspi2B, mit X10, EnOcean, 1-Wire, Lirc, Viera, Ws2000
Die Ventile und Pumpen haben eigene Ebus-Interfaces ?
LG
pah
Zitat von: phantom am 23 Oktober 2015, 09:57:31
Mittels des ebusd möchte ich "einfach" die RAM-Daten des Reglers mit dem Ebus-Befehl 09 00 (PB SB) auslesen und anhand eines Vergleichs mit der TEM-Software zuordnen. Dazu muss ich den ebusd wohl zunächst mit einer passenden Grundkonfiguration versehen. Aus den regelmäßen Telegramme an die Fernsteller könnte ich evtl. bereits Temperaturwerte abgreifen...
Also im Kontext TEM sind z.B. die Ochsner CSVs entstanden, die auch eine TEM Herstellerkodierung haben. Schau doch einfach mal, ob aus den Dateien etwas zu gebrauchen ist:
https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner)
Aber vermutlich ist das Zeitverschwendung, wenn nicht mal der Scan klappt...
@john30
Es ist wohl so, daß ich den TEM-Regler PS5511 per Polling abfragen muß. Es Mitschnitt des Starts der TEM-Windows-Software mittels "ebusd raw" gibt folgendes aus:
einmalig eine Systemidentifikation:
QQ ZZ PB SB NN DB CRC ACK NN Antwort-Telegramm
ff fc 07 04 01 00 e6 00 0a 10 50 53 35 35 31 31 78 78 78 75 00 00 00 00 00 00 00 00 00 aa 00 aa
10 TEM P S 5 5 1 1 x x x
dann mehrfache Speicherabfragen wie (2 Byte auslesen, hier mal ohne SYN/CRC/ACK dargestellt):
ff fc 09 02 03 f4 d7 02 / 02 bf 01
ff fc 09 02 03 f0 d7 02 / 02 8a 0c
ff fc 09 02 03 ec d7 02 / 02 36 45 ...
(PC=ff sendet an den Regler=fc eine RAM-Abfrage=0902 ab Adresse d7f4 hex mit 2 Byte Länge und bekommt 01bf hex zurück)
Mir fehlt noch etwas Verständnis für die ebusd-config, um mit derartigen Befehlen den Regler auszulesen.
Wie müsste man dies mit minimalen CSV-Konfig-Dateien formulieren?
Der Regler "versteht" wohl die ebus-Befehle 07 04 = Systemabfrage, 09 02 und 09 00 = RAM-Speicherabfragen. Ich würde gerne die RAM-Speicherabfragen mit ebusctl write ... zur weiteren Analyse nutzen.
@pah
Die Ventile und Pumpen, der Kamin- und Puffersteuerung hängen am TEM-Regler. Die Umwälz- und Wasserpumpen an der Viessmann-Heizung. Die Sollwerte und Ausgänge des TEM-Reglers lassen sich mit Speicher-Befehlen 09 01 auch hineinschreiben, womit ich vor hatte die Regelung anzupassen (wenn ich sicher bin die richtigen Adressen zu treffen ...)
Im Winter kommt es öfters vor, daß beide Regler (Heizung und Kamin) "gegeneinander" arbeiten. Wenn der Aufwand mittels ebus-Analyse bzw. Eingriff nicht exorbitant wird, wäre dies ein gangbarer Weg eine "externe" Modifikation der Stellglieder über weitere Elektronik am Regler vorbei zu vermeiden.
Gruß Dirk
Hm, leider beantwortet das die Frage noch nicht. "Hängen" die Stellglieder per EBUs am TEM, oder sind das andere (direkte) Anschlüsse ? Mit welchen anderen Geräten spricht der TEM-Regler per EBus ?
LG
pah
OK, dann mal etwas detaillierter:
Eine Standard-Viessmann-Heizung (Vitronic 200 KW2, überwacht mit vcontold) mit Warmwasserspeicher wird durch einen Kamin über einen Heizwasserpuffer unterstützt. Dazu steuert der TEM-Regler PS-5511-SZ eine Puffer- und eine Speicherpumpe über Triacs und dazu 2 Umschaltventile über Relais an (am ebus hängt niemand außer ebusd).
Wenn es draußen kalt ist und dann der Warmwasserspeicher auch kalt wird (zu lange geduscht...), wird unsinnigerweise erst der Puffer erwärmt anstelle des Speichers. Das dauert dann sehr lange.
Das Regelverhalten wollte ich durch Vorgabe besserer Sollwerte über den ebusd an den TEM-Regler optimieren.
Die RAM-Adressen der Sollwerte habe ich per ebusctl raw schon z.T. herausgefunden.
Das Zurückschreiben von Werten klappt jedoch nicht:
z.B. bringt das Auslesen der Rücklauf-Differenz-Temperatur mittels
ebusctl write -h fc 09 02 03 64 e0 02
nur folgendes, anstelle der korrekten Antwort "/ 02 32 00 Rücklauf_Differenz_Ein 32h=50 5.0 K" :
2015-10-25 13:30:26.632 [bus notice] <aa
2015-10-25 13:30:26.795 [bus notice] <aa
2015-10-25 13:30:26.861 [main notice] hex write cmd: fffc0902030ae002
2015-10-25 13:30:26.977 [bus notice] <aa
2015-10-25 13:30:26.978 [bus notice] >ff
2015-10-25 13:30:27.003 [bus notice] <ff
2015-10-25 13:30:27.104 [bus notice] <aa
2015-10-25 13:30:27.104 [bus notice] >ff
2015-10-25 13:30:27.130 [bus notice] <ff
2015-10-25 13:30:27.253 [bus notice] <aa
Danach bleibt der ebusd in diesem Zustand hängen und ebusctl gibt nichts mehr zurück bis man beide killt. :(
Lese ich diesen Wert mit der Windows-Parametrier-Software, kommt die erwartete Antwort, die ich mit ebusctl raw sehen konnte. Als ebusd-Konfig-Dateien ist bisher nur die _templates.csv in /etc/ebusd, damit der überhaupt läuft.
Ist dies evtl. nicht der richtige Weg, um vom einem ebus-Regler Werte abzufragen, oder muß ich schon dafür CSVs erstellen?
Und wie würde ich dann neue Werte zurückschreiben, oder ist da etwa irgendwo ein Bug?
Gruß Dirk
Ein Nachtrag:
das Auslesen klappt doch, es funktioniert jedoch nur mit einem direkt per USB am ebus-Wandler angeschlossenen Rechner (getestet mit altem, langsamen EEE-PC unter Ubuntu). Nicht funktioniert hat es jedoch aus einer virtuellen Ubuntu-Maschine unter VirtualBox auf Xeon 5480 über einen Ethernet-Serial-Wandler (Moxa-NPort) im Keller.
Es scheint, als gäbe es Timing-Probleme, wenn ebusd über den Ethernet-Serial-Wandler schreiben will; lesen klappt problemlos.
--> Kann man dies evtl. mit den Timing-Parametern von ebusd beheben?
OK, Werte auslesen mit ebusctl write -h fc 09 02 03 80 e0 02 gibt korrekt 02 c8 00 (=20.0 C) zurück.
--> Wie würde man diesen Wert durch zurückschreiben z.B. von 02 2c 01 auf 30.0 C setzen?
Zitat von: phantom am 27 Oktober 2015, 20:39:36
das Auslesen klappt doch, es funktioniert jedoch nur mit einem direkt per USB am ebus-Wandler angeschlossenen Rechner (getestet mit altem, langsamen EEE-PC unter Ubuntu). Nicht funktioniert hat es jedoch aus einer virtuellen Ubuntu-Maschine unter VirtualBox auf Xeon 5480 über einen Ethernet-Serial-Wandler (Moxa-NPort) im Keller.
Es scheint, als gäbe es Timing-Probleme, wenn ebusd über den Ethernet-Serial-Wandler schreiben will; lesen klappt problemlos.
--> Kann man dies evtl. mit den Timing-Parametern von ebusd beheben?
Nur begrenzt. Das Timing auf dem Bus ist ziemlich eng gestrickt, da gibt es wenig bis keinen Spielraum. Schau dir mal die Aufrufparameter von ebusd an, da gibt es zumindest zwei Zeitparameter, die man justieren kann: https://github.com/john30/ebusd/wiki/2.-Run#ebus-options (https://github.com/john30/ebusd/wiki/2.-Run#ebus-options), und zwar acquiretimeout und receivetimeout.
Nach Deinem raw dump zu urteilen würde das aber nicht helfen, da ein Zurücklesen eines einzelnen geschriebenen Bytes mit 25ms schon viel zu lange dauert.
Zitat von: phantom am 27 Oktober 2015, 20:39:36
OK, Werte auslesen mit ebusctl write -h fc 09 02 03 80 e0 02 gibt korrekt 02 c8 00 (=20.0 C) zurück.
--> Wie würde man diesen Wert durch zurückschreiben z.B. von 02 2c 01 auf 30.0 C setzen?
Laut eBUS Spez. wäre das dann -h fc 09 03 04 80 e0 2c 01.
Mit einer entsprechenden Message Definition (CSV) wäre das bequemer. Ich schau mir das am Wochenende mal an.
Hallo zusammen,
ich verfolge den Thread schon eine ganze Weile und bin auch aktuell dabei meinen Vailant an meine Hausystem anzubinden.
Dank des Ebusd und der Schaltung von pah funktioniert das auch schon sehr gut. Danke dafür, gute Arbeit!
Mit den vorhandenen CSV Dateien kann ich auch die ein oder anderen Daten bereits auslesen und in meiner DB speichern.
Soweit so gut.
Aber nun habe ich ein paar Nachrichten die ich gerne noch in die CSV eintragen will. Allerdings komme ich mit den Daten im CSV nicht ganz zurecht.
Irgendwie habe ich es noch nicht genau festellen können wie ich wo und was eintragen muss.
Beispiel:
10ecb5040121 / 050e00003f00
Mir ist klar das es um das Komando ecb5 04 21 geht. Aus dem Dokument "eBUS Specification Application Layer – OSI 7 Vaillant specific extensions V0.6.0"
scheint es der Service "ServiceWaterStorage" zu sein.
Und damit die Daten:
0e --> Collector temperature °C
00 --> immer 00 / unbekannt
00 --> Heizquelle / Off, Solar, Heizer
3f --> SpeicherLevel in %
00 --> Power %
Wie trag ich das nun ein? Gibt es eine Beschreibung der CSV-Files? Wen ja wo?
Ach ja habe eine VRS620 und die Therme VC DE 206 mit Solaranalge.
Danke und Gruß
Stumpf
Die Beschreibung der CSV-Files ist in diesen enthalten. Einfach in OpenOffice importieren, dort bearbeiten und wieder nach CSV exportieren.
LG
pah
Zitat von: phantom am 27 Oktober 2015, 20:39:36
das Auslesen klappt doch, es funktioniert jedoch nur mit einem direkt per USB am ebus-Wandler angeschlossenen Rechner (getestet mit altem, langsamen EEE-PC unter Ubuntu). Nicht funktioniert hat es jedoch aus einer virtuellen Ubuntu-Maschine unter VirtualBox auf Xeon 5480 über einen Ethernet-Serial-Wandler (Moxa-NPort) im Keller.
Du könntest mal schauen, ob an dem Wandler Puffergrößen einstellbar sind. Für ebusd darf nichts gepuffert werden.
Zitat von: phantom am 27 Oktober 2015, 20:39:36
OK, Werte auslesen mit ebusctl write -h fc 09 02 03 80 e0 02 gibt korrekt 02 c8 00 (=20.0 C) zurück.
--> Wie würde man diesen Wert durch zurückschreiben z.B. von 02 2c 01 auf 30.0 C setzen?
Also hex wäre das ja wie gesagt "write -h fc 09 03 04 80 e0 2c 01".
Wenn Du folgende Zeilen in eine neue CSV Datei im ebusd config Verzeichnis legst:
r,ps551,rldiffon,Rücklauf_Differenz_Ein,,FC,0902,64e002,,,IGN:1,,,,tempdiff,,UIN,10,K,Temperaturdifferenz
r,ps551,xtemp,,,FC,0902,80e002,,,IGN:1,,,,temp,,UIN,10,°C,Temperatur
w,ps551,rldiffon,Rücklauf_Differenz_Ein,,FC,0903,64e0,tempdiff,,UIN,10,K,Temperaturdifferenz,,,,,,
w,ps551,xtemp,,,FC,0903,80e0,temp,,UIN,10,°C,Temperatur,,,,,,
dann kannst Du diese Werte auch mit "read -c ps551 rldiffon" bzw. "read -c ps551 xtemp" lesen und analog z.B. mit "write -c ps551 xtemp 30" schreiben.
Zitat von: Stumpf am 30 Oktober 2015, 10:57:58
Gibt es eine Beschreibung der CSV-Files? Wen ja wo?
Hier: https://github.com/john30/ebusd/wiki/4.-Configuration (https://github.com/john30/ebusd/wiki/4.-Configuration)
Und ein kleines HowTo hier: https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files (https://github.com/john30/ebusd/wiki/HowTos#creating-new-message-definition-files)
Alles klar!
Danke
Hast dir echt viel arbeit gemacht! Respekt !!!
Ich habe heute das Interface nach den Plänen von pah an einem Raspberry Pi B+ in Betrieb genommen. Zusammen mit ebusd 1.3.0 und den CSV-Konfigurationen aus dem Repository von john30 hat das Lesen und Schreiben auf Anhieb geklappt. Auch die Integration in FHEM über das GAEBUS-Modul funktioniert. Als weitere Option gibt es außerdem die im Wiki dokumentierte ECMD-Variante von pah.
Ich finde das super und danke allen, die in den letzten Monaten hart dafür gearbeitet haben!
Ich verfolge den Beitrag bereits seit einiger Zeit und habe mich vor einigen Wochen dazu entschlossen meine Gastherme Vaillant Vaillant ecoTEC plus VC AT 126/3-5H mit Regler calorMATIC 470 mit ebusd auszulesen.
Mein ebusd Adapter ist laut der Schaltung von pah (Als "kritische" Bauelemente verwende ich: Transistor: BD645 , Fairchild DC-Optokoppler: CNY171 / 70 V / 50 mA) und dem Print von zenti666 - Danke für eure Mühe. Der USB Adapter ist von ELV. Die Software in der Version 1.3.
Die Hi/Lo Abstimmung der Schaltung habe ich auf 13V abgestimmt und den Adapter wie hier beschrieben mit 20V und einem 1KOhm Widerstand einem Schleifentest unterzogen.
Der Poti der Schaltung ist jedoch fast auf Anschlag (0 kOhm) dadurch R2 testweise auf 500Ohm getauscht !
Als Endllösung möchte ich anstatt des USB Adapters eine TTY-LAN Adapter verwenden und die Schaltung mit 3,3V betreiben.... aber das dauert wohl noch ein wenig.
Und nun zu meinem Problem welches ich nicht in den Griff bekomme:
Der Empfang der Daten dürfte funktionieren -> keine CRC Alarme und ich bekomme sehr wenige "unknown BC cmd"
Ich kann aber anscheinend nichts abfragen, da nach "scan full" bei "scan result" nichts ausgegeben wird und auch eine Temperatur Abfrage keine Antwort ergiebt -> siehe LOG
Den ebus habe ich sowohl direkt, als auch über den Diagnose RJ Stecker getestet
Bitte um Eure Unterstützung
Daniel
ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --logareas=all --loglevel=debug:
root@raspberrypi:~# ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --logareas=all --loglevel=debug
2015-11-01 10:33:13.239 [main notice] ebusd 1.3.0 started
2015-11-01 10:33:13.241 [main info] path to configuration files: /etc/ebusd
2015-11-01 10:33:13.260 [main info] read templates
2015-11-01 10:33:13.262 [main info] reading file /etc/ebusd/470.csv
2015-11-01 10:33:13.331 [main info] reading file /etc/ebusd/bai.csv
2015-11-01 10:33:13.419 [main info] reading file /etc/ebusd/broadcast.csv
2015-11-01 10:33:13.427 [main info] reading file /etc/ebusd/common.csv
2015-11-01 10:33:13.467 [main info] reading file /etc/ebusd/scan.csv
2015-11-01 10:33:13.470 [main info] read config files
2015-11-01 10:33:13.471 [main notice] found messages: 441 (0 conditional on 0 conditions, 0 poll, 11 update)
2015-11-01 10:33:14.321 [bus debug] ERR: SYN received during no signal, switching to ready
2015-11-01 10:33:14.322 [bus notice] signal acquired
2015-11-01 10:33:17.246 [bus notice] new master 10
2015-11-01 10:33:17.247 [update info] update MS cmd: 1008b5110101 / 093a3a1009ff6c0000ff
2015-11-01 10:33:17.248 [bus notice] new master 03
2015-11-01 10:33:17.249 [update notice] unknown MS cmd: 1008b5110101 / 093a3a1009ff6c0000ff
2015-11-01 10:33:18.475 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:33:19.152 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2015-11-01 10:33:19.413 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2015-11-01 10:33:19.674 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2015-11-01 10:33:19.952 [update info] update BC cmd: 10feb516080021331101110715
2015-11-01 10:33:19.954 [update notice] update broadcast vdatetime QQ=10: 11:33:21;01.11.2015
2015-11-01 10:33:20.182 [update info] update BC cmd: 10feb51603046004
2015-11-01 10:33:20.183 [update notice] unknown BC cmd: 10feb51603046004
2015-11-01 10:33:20.439 [update info] update MS cmd: 1008b512020064 / 00
2015-11-01 10:33:20.440 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-11-01 10:33:23.223 [update info] update MS cmd: 1008b510090000416effff000000 / 0101
2015-11-01 10:33:23.225 [update notice] update bc Mode QQ=10: standby
2015-11-01 10:33:27.248 [update info] update MS cmd: 1008b5110101 / 093a3a1009ff6c0000ff
2015-11-01 10:33:27.249 [update notice] unknown MS cmd: 1008b5110101 / 093a3a1009ff6c0000ff
2015-11-01 10:33:29.263 [update info] update MS cmd: 1008b5040100 / 0a03313311011107151009
2015-11-01 10:33:29.264 [update notice] unknown MS cmd: 1008b5040100 / 0a03313311011107151009
2015-11-01 10:33:29.534 [update info] update MS cmd: 1008b5110102 / 05033c6a506e
2015-11-01 10:33:29.535 [update notice] unknown MS cmd: 1008b5110102 / 05033c6a506e
-------------------------------------------------------------------------------------------------
ebusctl scan full
(bei ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --logareas=all --loglevel=debug)
2015-11-01 10:39:19.133 [update notice] update broadcast vdatetime QQ=10: 11:39:20;01.11.2015
2015-11-01 10:39:19.237 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.287 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.325 [bus debug] ERR: arbitration lost during ready, retry
2015-11-01 10:39:19.363 [update info] update BC cmd: 10feb51603046004
2015-11-01 10:39:19.364 [update notice] unknown BC cmd: 10feb51603046004
2015-11-01 10:39:19.473 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.518 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.556 [bus debug] ERR: arbitration lost during ready, retry
2015-11-01 10:39:19.622 [update info] update MS cmd: 1008b512020064 / 00
2015-11-01 10:39:19.623 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-11-01 10:39:19.726 [network debug] dead connection removed - 0
2015-11-01 10:39:19.728 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.773 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.818 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.862 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.907 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:19.957 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.003 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.050 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.094 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.137 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.183 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.229 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.273 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.317 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.362 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:39:20.406 [bus debug] ERR: read timeout during ready, switching to skip
-------------------------------------------------------------------------------------------
ebusctl r RoomTemp
(bei ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --logareas=all --loglevel=debug)
2015-11-01 10:36:17.438 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.481 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.527 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.572 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.620 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.663 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.707 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.745 [bus debug] ERR: arbitration lost during ready, retry
2015-11-01 10:36:17.840 [update info] update MS cmd: 1008b5110101 / 093a3a4009ff6c0000ff
2015-11-01 10:36:17.841 [update notice] unknown MS cmd: 1008b5110101 / 093a3a4009ff6c0000ff
2015-11-01 10:36:17.947 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:17.995 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:18.041 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 10:36:18.088 [bus debug] ERR: read timeout during ready, switching to skip
-----------------------------------------------------------------------------------------
Zitat von: yellowpinky am 01 November 2015, 12:22:05
Ich kann aber anscheinend nichts abfragen, da nach "scan full" bei "scan result" nichts ausgegeben wird und auch eine Temperatur Abfrage keine Antwort ergiebt -> siehe LOG
Mach doch mal bitte das gleiche Log für die Temperaturabfrage, aber inkl. "ebusctl raw" unmittelbar vor der Abfrage (und "ebusctl raw stop" nach so 3 Sekunden). Dann sieht man, was an Bytes über den Bus rausgeht und reinkommt.
@john30
Danke für die schnelle Antwort..
.. habe mit ebusctl r RoomTemp getestet, sieht irgendwie so aus ob am Bus nichts ausgegeben wird ?!
Anbei der LOG.
Hab da noch irgendwo ein konfig Problem ?
Die ebusd.debian in /root/ebusd/contrib/etc/default
hat den Inhalt:
EBUSD_OPTS="--acquiretime 6000 -l All -d /dev/ttyUSB0"
ebusd -f -l ALL -d /dev/ttyUSB0 -p 8888 --logareas=all --logl
level=debug
2015-11-01 14:55:39.411 [main notice] ebusd 1.3.0 started
2015-11-01 14:55:39.413 [main info] path to configuration files: /etc/ebusd
2015-11-01 14:55:39.435 [main info] read templates
2015-11-01 14:55:39.436 [main info] reading file /etc/ebusd/470.csv
2015-11-01 14:55:39.513 [main info] reading file /etc/ebusd/bai.csv
2015-11-01 14:55:39.614 [main info] reading file /etc/ebusd/broadcast.csv
2015-11-01 14:55:39.623 [main info] reading file /etc/ebusd/common.csv
2015-11-01 14:55:39.667 [main info] reading file /etc/ebusd/scan.csv
2015-11-01 14:55:39.671 [main info] read config files
2015-11-01 14:55:39.672 [main notice] found messages: 441 (0 conditional on 0 conditions, 0 poll, 11 update)
2015-11-01 14:55:39.704 [bus debug] ERR: SYN received during no signal, switching to ready
2015-11-01 14:55:39.705 [bus notice] signal acquired
2015-11-01 14:55:40.713 [bus notice] new master 10
2015-11-01 14:55:40.714 [update info] update MS cmd: 1008b5100900003f6effff000000 / 0101
2015-11-01 14:55:40.715 [bus notice] new master 03
2015-11-01 14:55:40.723 [update notice] update bc Mode QQ=10: standby
2015-11-01 14:55:44.540 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:46.356 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:46.595 [update info] update MS cmd: 1008b5110101 / 09463ed00aff760100ff
2015-11-01 14:55:46.596 [update notice] unknown MS cmd: 1008b5110101 / 09463ed00aff760100ff
2015-11-01 14:55:48.610 [update info] update MS cmd: 1008b5040100 / 0a0350551501110715d00a
2015-11-01 14:55:48.611 [update notice] unknown MS cmd: 1008b5040100 / 0a0350551501110715d00a
2015-11-01 14:55:50.764 [update info] update MS cmd: 1008b5100900003f6effff000000 / 0101
2015-11-01 14:55:50.765 [update notice] update bc Mode QQ=10: standby
2015-11-01 14:55:51.391 [network info] [00001] client connection opened 127.0.0.1
2015-11-01 14:55:51.393 [main debug] >>> raw
2015-11-01 14:55:51.394 [main debug] <<< raw output enabled
2015-11-01 14:55:51.395 [network debug] [00001] wait for result
2015-11-01 14:55:51.400 [network info] [00001] connection closed
2015-11-01 14:55:51.407 [bus notice] <aa
2015-11-01 14:55:51.453 [bus notice] <aa
2015-11-01 14:55:51.496 [bus notice] <aa
2015-11-01 14:55:51.542 [bus notice] <aa
2015-11-01 14:55:51.585 [bus notice] <aa
2015-11-01 14:55:51.629 [bus notice] <aa
2015-11-01 14:55:51.674 [bus notice] <aa
2015-11-01 14:55:51.720 [bus notice] <aa
2015-11-01 14:55:51.766 [bus notice] <aa
2015-11-01 14:55:51.810 [bus notice] <aa
2015-11-01 14:55:51.859 [bus notice] <aa
2015-11-01 14:55:51.903 [bus notice] <aa
2015-11-01 14:55:51.951 [bus notice] <aa
2015-11-01 14:55:51.997 [bus notice] <aa
2015-11-01 14:55:52.040 [bus notice] <aa
2015-11-01 14:55:52.084 [bus notice] <aa
2015-11-01 14:55:52.132 [bus notice] <aa
2015-11-01 14:55:52.177 [bus notice] <aa
2015-11-01 14:55:52.221 [bus notice] <aa
2015-11-01 14:55:52.267 [bus notice] <aa
2015-11-01 14:55:52.313 [bus notice] <aa
2015-11-01 14:55:52.358 [bus notice] <aa
2015-11-01 14:55:52.392 [network debug] dead connection removed - 0
2015-11-01 14:55:52.401 [bus notice] <aa
2015-11-01 14:55:52.452 [bus notice] <aa
2015-11-01 14:55:52.496 [bus notice] <aa
2015-11-01 14:55:52.543 [bus notice] <aa
2015-11-01 14:55:52.588 [bus notice] <aa
2015-11-01 14:55:52.633 [bus notice] <aa
2015-11-01 14:55:52.679 [bus notice] <aa
2015-11-01 14:55:52.724 [bus notice] <aa
2015-11-01 14:55:52.769 [bus notice] <aa
2015-11-01 14:55:52.813 [bus notice] <aa
2015-11-01 14:55:52.858 [bus notice] <aa
2015-11-01 14:55:52.902 [bus notice] <aa
2015-11-01 14:55:52.947 [bus notice] <aa
2015-11-01 14:55:52.991 [bus notice] <aa
2015-11-01 14:55:53.036 [bus notice] <aa
2015-11-01 14:55:53.080 [bus notice] <aa
2015-11-01 14:55:53.129 [bus notice] <aa
2015-11-01 14:55:53.172 [bus notice] <aa
2015-11-01 14:55:53.223 [bus notice] <aa
2015-11-01 14:55:53.268 [bus notice] <aa
2015-11-01 14:55:53.317 [bus notice] <aa
2015-11-01 14:55:53.361 [bus notice] <aa
2015-11-01 14:55:53.406 [bus notice] <aa
2015-11-01 14:55:53.450 [bus notice] <aa
2015-11-01 14:55:53.495 [bus notice] <aa
2015-11-01 14:55:53.539 [bus notice] <aa
2015-11-01 14:55:53.582 [bus notice] <aa
2015-11-01 14:55:53.628 [bus notice] <aa
2015-11-01 14:55:53.673 [bus notice] <aa
2015-11-01 14:55:53.717 [bus notice] <aa
2015-11-01 14:55:53.762 [bus notice] <aa
2015-11-01 14:55:53.811 [bus notice] <aa
2015-11-01 14:55:53.856 [bus notice] <aa
2015-11-01 14:55:53.902 [bus notice] <aa
2015-11-01 14:55:53.946 [bus notice] <aa
2015-11-01 14:55:53.992 [bus notice] <aa
2015-11-01 14:55:54.036 [bus notice] <aa
2015-11-01 14:55:54.084 [bus notice] <aa
2015-11-01 14:55:54.130 [bus notice] <aa
2015-11-01 14:55:54.175 [bus notice] <aa
2015-11-01 14:55:54.220 [bus notice] <aa
2015-11-01 14:55:54.266 [bus notice] <aa
2015-11-01 14:55:54.311 [bus notice] <aa
2015-11-01 14:55:54.355 [bus notice] <aa
2015-11-01 14:55:54.400 [bus notice] <aa
2015-11-01 14:55:54.444 [bus notice] <aa
2015-11-01 14:55:54.493 [bus notice] <aa
2015-11-01 14:55:54.536 [bus notice] <aa
2015-11-01 14:55:54.584 [bus notice] <aa
2015-11-01 14:55:54.629 [bus notice] <aa
2015-11-01 14:55:54.674 [bus notice] <aa
2015-11-01 14:55:54.719 [bus notice] <aa
2015-11-01 14:55:54.765 [bus notice] <aa
2015-11-01 14:55:54.810 [bus notice] <aa
2015-11-01 14:55:54.855 [bus notice] <aa
2015-11-01 14:55:54.878 [network info] [00002] client connection opened 127.0.0.1
2015-11-01 14:55:54.880 [main debug] >>> r RoomTemp
2015-11-01 14:55:54.880 [main info] send message: ff15b509030d0000
2015-11-01 14:55:54.881 [network debug] [00002] wait for result
2015-11-01 14:55:54.899 [bus notice] <aa
2015-11-01 14:55:54.901 [bus notice] >ff
2015-11-01 14:55:54.912 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:54.943 [bus notice] <aa
2015-11-01 14:55:54.944 [bus notice] >ff
2015-11-01 14:55:54.955 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:54.988 [bus notice] <aa
2015-11-01 14:55:54.989 [bus notice] >ff
2015-11-01 14:55:54.999 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.033 [bus notice] <aa
2015-11-01 14:55:55.034 [bus notice] >ff
2015-11-01 14:55:55.045 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.080 [bus notice] <aa
2015-11-01 14:55:55.082 [bus notice] >ff
2015-11-01 14:55:55.092 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.124 [bus notice] <aa
2015-11-01 14:55:55.126 [bus notice] >ff
2015-11-01 14:55:55.136 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.174 [bus notice] <aa
2015-11-01 14:55:55.176 [bus notice] >ff
2015-11-01 14:55:55.186 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.218 [bus notice] <aa
2015-11-01 14:55:55.220 [bus notice] >ff
2015-11-01 14:55:55.230 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.266 [bus notice] <aa
2015-11-01 14:55:55.267 [bus notice] >ff
2015-11-01 14:55:55.278 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.310 [bus notice] <aa
2015-11-01 14:55:55.311 [bus notice] >ff
2015-11-01 14:55:55.322 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.359 [bus notice] <aa
2015-11-01 14:55:55.360 [bus notice] >ff
2015-11-01 14:55:55.370 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.403 [bus notice] <aa
2015-11-01 14:55:55.404 [bus notice] >ff
2015-11-01 14:55:55.414 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.448 [bus notice] <aa
2015-11-01 14:55:55.449 [bus notice] >ff
2015-11-01 14:55:55.459 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.492 [bus notice] <aa
2015-11-01 14:55:55.493 [bus notice] >ff
2015-11-01 14:55:55.503 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.539 [bus notice] <aa
2015-11-01 14:55:55.541 [bus notice] >ff
2015-11-01 14:55:55.551 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.583 [bus notice] <aa
2015-11-01 14:55:55.585 [bus notice] >ff
2015-11-01 14:55:55.595 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.628 [bus notice] <aa
2015-11-01 14:55:55.630 [bus notice] >ff
2015-11-01 14:55:55.640 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.673 [bus notice] <aa
2015-11-01 14:55:55.675 [bus notice] >ff
2015-11-01 14:55:55.685 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.717 [bus notice] <aa
2015-11-01 14:55:55.719 [bus notice] >ff
2015-11-01 14:55:55.729 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.761 [bus notice] <aa
2015-11-01 14:55:55.763 [bus notice] >ff
2015-11-01 14:55:55.774 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.805 [bus notice] <aa
2015-11-01 14:55:55.806 [bus notice] >ff
2015-11-01 14:55:55.817 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.853 [bus notice] <aa
2015-11-01 14:55:55.854 [bus notice] >ff
2015-11-01 14:55:55.864 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.897 [bus notice] <aa
2015-11-01 14:55:55.898 [bus notice] >ff
2015-11-01 14:55:55.908 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.943 [bus notice] <aa
2015-11-01 14:55:55.944 [bus notice] >ff
2015-11-01 14:55:55.955 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:55.992 [bus notice] <aa
2015-11-01 14:55:55.993 [bus notice] >ff
2015-11-01 14:55:56.004 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.042 [bus notice] <aa
2015-11-01 14:55:56.043 [bus notice] >ff
2015-11-01 14:55:56.054 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.088 [bus notice] <aa
2015-11-01 14:55:56.090 [bus notice] >ff
2015-11-01 14:55:56.100 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.133 [bus notice] <aa
2015-11-01 14:55:56.135 [bus notice] >ff
2015-11-01 14:55:56.145 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.179 [bus notice] <aa
2015-11-01 14:55:56.180 [bus notice] >ff
2015-11-01 14:55:56.190 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.224 [bus notice] <aa
2015-11-01 14:55:56.225 [bus notice] >ff
2015-11-01 14:55:56.235 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.269 [bus notice] <aa
2015-11-01 14:55:56.270 [bus notice] >ff
2015-11-01 14:55:56.280 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.314 [bus notice] <aa
2015-11-01 14:55:56.315 [bus notice] >ff
2015-11-01 14:55:56.326 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.358 [bus notice] <aa
2015-11-01 14:55:56.359 [bus notice] >ff
2015-11-01 14:55:56.369 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.402 [bus notice] <aa
2015-11-01 14:55:56.403 [bus notice] >ff
2015-11-01 14:55:56.414 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.446 [bus notice] <aa
2015-11-01 14:55:56.447 [bus notice] >ff
2015-11-01 14:55:56.457 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.493 [bus notice] <aa
2015-11-01 14:55:56.495 [bus notice] >ff
2015-11-01 14:55:56.505 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.538 [bus notice] <aa
2015-11-01 14:55:56.540 [bus notice] >ff
2015-11-01 14:55:56.544 [bus notice] <10
2015-11-01 14:55:56.544 [bus debug] ERR: arbitration lost during ready, retry
2015-11-01 14:55:56.547 [bus notice] <08
2015-11-01 14:55:56.553 [bus notice] <b5
2015-11-01 14:55:56.556 [bus notice] <11
2015-11-01 14:55:56.561 [bus notice] <01
2015-11-01 14:55:56.565 [bus notice] <01
2015-11-01 14:55:56.570 [bus notice] <89
2015-11-01 14:55:56.574 [bus notice] <00
2015-11-01 14:55:56.603 [bus notice] <09
2015-11-01 14:55:56.607 [bus notice] <46
2015-11-01 14:55:56.612 [bus notice] <3e
2015-11-01 14:55:56.616 [bus notice] <d0
2015-11-01 14:55:56.620 [bus notice] <0a
2015-11-01 14:55:56.624 [bus notice] <ff
2015-11-01 14:55:56.629 [bus notice] <76
2015-11-01 14:55:56.633 [bus notice] <01
2015-11-01 14:55:56.637 [bus notice] <00
2015-11-01 14:55:56.641 [bus notice] <ff
2015-11-01 14:55:56.645 [bus notice] <fd
2015-11-01 14:55:56.650 [bus notice] <00
2015-11-01 14:55:56.650 [update info] update MS cmd: 1008b5110101 / 09463ed00aff760100ff
2015-11-01 14:55:56.650 [update notice] unknown MS cmd: 1008b5110101 / 09463ed00aff760100ff
2015-11-01 14:55:56.654 [bus notice] <aa
2015-11-01 14:55:56.701 [bus notice] <aa
2015-11-01 14:55:56.745 [bus notice] <aa
2015-11-01 14:55:56.746 [bus notice] >ff
2015-11-01 14:55:56.757 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.790 [bus notice] <aa
2015-11-01 14:55:56.792 [bus notice] >ff
2015-11-01 14:55:56.802 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.835 [bus notice] <aa
2015-11-01 14:55:56.837 [bus notice] >ff
2015-11-01 14:55:56.847 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.881 [bus notice] <aa
2015-11-01 14:55:56.882 [bus notice] >ff
2015-11-01 14:55:56.892 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.924 [bus notice] <aa
2015-11-01 14:55:56.926 [bus notice] >ff
2015-11-01 14:55:56.936 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:56.971 [bus notice] <aa
2015-11-01 14:55:56.972 [bus notice] >ff
2015-11-01 14:55:56.982 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.017 [bus notice] <aa
2015-11-01 14:55:57.018 [bus notice] >ff
2015-11-01 14:55:57.029 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.061 [bus notice] <aa
2015-11-01 14:55:57.062 [bus notice] >ff
2015-11-01 14:55:57.073 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.107 [bus notice] <aa
2015-11-01 14:55:57.109 [bus notice] >ff
2015-11-01 14:55:57.119 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.151 [bus notice] <aa
2015-11-01 14:55:57.152 [bus notice] >ff
2015-11-01 14:55:57.163 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.199 [bus notice] <aa
2015-11-01 14:55:57.200 [bus notice] >ff
2015-11-01 14:55:57.211 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.243 [bus notice] <aa
2015-11-01 14:55:57.244 [bus notice] >ff
2015-11-01 14:55:57.254 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.289 [bus notice] <aa
2015-11-01 14:55:57.290 [bus notice] >ff
2015-11-01 14:55:57.301 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.334 [bus notice] <aa
2015-11-01 14:55:57.336 [bus notice] >ff
2015-11-01 14:55:57.346 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.384 [bus notice] <aa
2015-11-01 14:55:57.386 [bus notice] >ff
^X2015-11-01 14:55:57.396 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.428 [bus notice] <aa
2015-11-01 14:55:57.430 [bus notice] >ff
2015-11-01 14:55:57.440 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.473 [bus notice] <aa
2015-11-01 14:55:57.475 [bus notice] >ff
2015-11-01 14:55:57.485 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.517 [bus notice] <aa
2015-11-01 14:55:57.519 [bus notice] >ff
2015-11-01 14:55:57.529 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.562 [bus notice] <aa
2015-11-01 14:55:57.564 [bus notice] >ff
2015-11-01 14:55:57.574 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.606 [bus notice] <aa
2015-11-01 14:55:57.608 [bus notice] >ff
2015-11-01 14:55:57.618 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.651 [bus notice] <aa
2015-11-01 14:55:57.653 [bus notice] >ff
2015-11-01 14:55:57.663 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.695 [bus notice] <aa
2015-11-01 14:55:57.697 [bus notice] >ff
2015-11-01 14:55:57.707 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.742 [bus notice] <aa
2015-11-01 14:55:57.743 [bus notice] >ff
2015-11-01 14:55:57.753 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.786 [bus notice] <aa
2015-11-01 14:55:57.787 [bus notice] >ff
2015-11-01 14:55:57.797 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.831 [bus notice] <aa
2015-11-01 14:55:57.832 [bus notice] >ff
2015-11-01 14:55:57.842 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.878 [bus notice] <aa
2015-11-01 14:55:57.880 [bus notice] >ff
2015-11-01 14:55:57.890 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.925 [bus notice] <aa
2015-11-01 14:55:57.926 [bus notice] >ff
2015-11-01 14:55:57.936 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:57.974 [bus notice] <aa
2015-11-01 14:55:57.975 [bus notice] >ff
2015-11-01 14:55:57.985 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.019 [bus notice] <aa
2015-11-01 14:55:58.020 [bus notice] >ff
2015-11-01 14:55:58.030 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.069 [bus notice] <aa
2015-11-01 14:55:58.070 [bus notice] >ff
2015-11-01 14:55:58.080 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.114 [bus notice] <aa
2015-11-01 14:55:58.115 [bus notice] >ff
2015-11-01 14:55:58.126 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.158 [bus notice] <aa
2015-11-01 14:55:58.159 [bus notice] >ff
2015-11-01 14:55:58.170 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.203 [bus notice] <aa
2015-11-01 14:55:58.204 [bus notice] >ff
2015-11-01 14:55:58.215 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.247 [bus notice] <aa
2015-11-01 14:55:58.248 [bus notice] >ff
2015-11-01 14:55:58.259 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.292 [bus notice] <aa
2015-11-01 14:55:58.293 [bus notice] >ff
2015-11-01 14:55:58.304 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.336 [bus notice] <aa
2015-11-01 14:55:58.337 [bus notice] >ff
2015-11-01 14:55:58.347 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.381 [bus notice] <aa
2015-11-01 14:55:58.382 [bus notice] >ff
2015-11-01 14:55:58.393 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.425 [bus notice] <aa
2015-11-01 14:55:58.426 [bus notice] >ff
^X2015-11-01 14:55:58.437 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.470 [bus notice] <aa
2015-11-01 14:55:58.471 [bus notice] >ff
2015-11-01 14:55:58.482 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.515 [bus notice] <aa
2015-11-01 14:55:58.516 [bus notice] >ff
2015-11-01 14:55:58.527 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.564 [bus notice] <aa
2015-11-01 14:55:58.565 [bus notice] >ff
2015-11-01 14:55:58.568 [bus notice] <10
2015-11-01 14:55:58.568 [bus debug] ERR: arbitration lost during ready, retry
2015-11-01 14:55:58.573 [bus notice] <08
2015-11-01 14:55:58.577 [bus notice] <b5
2015-11-01 14:55:58.582 [bus notice] <10
2015-11-01 14:55:58.586 [bus notice] <03
2015-11-01 14:55:58.591 [bus notice] <05
2015-11-01 14:55:58.596 [bus notice] <ff
2015-11-01 14:55:58.600 [bus notice] <01
2015-11-01 14:55:58.605 [bus notice] <98
2015-11-01 14:55:58.609 [bus notice] <00
2015-11-01 14:55:58.638 [bus notice] <00
2015-11-01 14:55:58.642 [bus notice] <00
2015-11-01 14:55:58.647 [bus notice] <00
2015-11-01 14:55:58.647 [update info] update MS cmd: 1008b5100305ff01 / 00
2015-11-01 14:55:58.648 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2015-11-01 14:55:58.651 [bus notice] <aa
2015-11-01 14:55:58.696 [bus notice] <aa
2015-11-01 14:55:58.745 [bus notice] <aa
2015-11-01 14:55:58.746 [bus notice] >ff
2015-11-01 14:55:58.757 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.790 [bus notice] <aa
2015-11-01 14:55:58.791 [bus notice] >ff
2015-11-01 14:55:58.802 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.834 [bus notice] <aa
2015-11-01 14:55:58.836 [bus notice] >ff
2015-11-01 14:55:58.847 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.879 [bus notice] <aa
2015-11-01 14:55:58.880 [bus notice] >ff
2015-11-01 14:55:58.891 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.928 [bus notice] <aa
2015-11-01 14:55:58.929 [bus notice] >ff
2015-11-01 14:55:58.940 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:58.973 [bus notice] <aa
2015-11-01 14:55:58.974 [bus notice] >ff
2015-11-01 14:55:58.985 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.021 [bus notice] <aa
2015-11-01 14:55:59.022 [bus notice] >ff
2015-11-01 14:55:59.032 [bus debug] ERR: read timeout during ready, switching to skip
^C2015-11-01 14:55:59.064 [main notice] SIGINT received
2015-11-01 14:55:59.065 [bus notice] <aa
2015-11-01 14:55:59.066 [bus notice] >ff
2015-11-01 14:55:59.077 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.108 [bus notice] <aa
2015-11-01 14:55:59.110 [bus notice] >ff
2015-11-01 14:55:59.120 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.153 [bus notice] <aa
2015-11-01 14:55:59.155 [bus notice] >ff
2015-11-01 14:55:59.165 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.200 [bus notice] <aa
2015-11-01 14:55:59.201 [bus notice] >ff
2015-11-01 14:55:59.212 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.245 [bus notice] <aa
2015-11-01 14:55:59.246 [bus notice] >ff
2015-11-01 14:55:59.257 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.289 [bus notice] <aa
2015-11-01 14:55:59.290 [bus notice] >ff
2015-11-01 14:55:59.301 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.338 [bus notice] <aa
2015-11-01 14:55:59.339 [bus notice] >ff
2015-11-01 14:55:59.349 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.382 [bus notice] <aa
2015-11-01 14:55:59.383 [bus notice] >ff
2015-11-01 14:55:59.393 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.428 [bus notice] <aa
2015-11-01 14:55:59.429 [bus notice] >ff
2015-11-01 14:55:59.440 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.473 [bus notice] <aa
2015-11-01 14:55:59.474 [bus notice] >ff
2015-11-01 14:55:59.485 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.518 [bus notice] <aa
2015-11-01 14:55:59.520 [bus notice] >ff
2015-11-01 14:55:59.530 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.563 [bus notice] <aa
2015-11-01 14:55:59.565 [bus notice] >ff
2015-11-01 14:55:59.575 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.607 [bus notice] <aa
2015-11-01 14:55:59.609 [bus notice] >ff
2015-11-01 14:55:59.619 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.651 [bus notice] <aa
2015-11-01 14:55:59.653 [bus notice] >ff
2015-11-01 14:55:59.663 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.696 [bus notice] <aa
2015-11-01 14:55:59.698 [bus notice] >ff
2015-11-01 14:55:59.708 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.741 [bus notice] <aa
2015-11-01 14:55:59.743 [bus notice] >ff
2015-11-01 14:55:59.753 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.785 [bus notice] <aa
2015-11-01 14:55:59.787 [bus notice] >ff
2015-11-01 14:55:59.797 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.829 [bus notice] <aa
2015-11-01 14:55:59.831 [bus notice] >ff
2015-11-01 14:55:59.841 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.876 [bus notice] <aa
2015-11-01 14:55:59.877 [bus notice] >ff
2015-11-01 14:55:59.887 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.924 [bus notice] <aa
2015-11-01 14:55:59.926 [bus notice] >ff
2015-11-01 14:55:59.936 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:55:59.973 [bus notice] <aa
2015-11-01 14:55:59.975 [bus notice] >ff
2015-11-01 14:55:59.985 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.020 [bus notice] <aa
2015-11-01 14:56:00.021 [bus notice] >ff
2015-11-01 14:56:00.032 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.064 [bus notice] <aa
2015-11-01 14:56:00.065 [bus notice] >ff
2015-11-01 14:56:00.075 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.112 [bus notice] <aa
2015-11-01 14:56:00.114 [bus notice] >ff
2015-11-01 14:56:00.124 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.156 [bus notice] <aa
2015-11-01 14:56:00.158 [bus notice] >ff
2015-11-01 14:56:00.168 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.201 [bus notice] <aa
2015-11-01 14:56:00.203 [bus notice] >ff
2015-11-01 14:56:00.213 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.245 [bus notice] <aa
2015-11-01 14:56:00.247 [bus notice] >ff
2015-11-01 14:56:00.257 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.290 [bus notice] <aa
2015-11-01 14:56:00.292 [bus notice] >ff
2015-11-01 14:56:00.303 [bus debug] ERR: read timeout during ready, switching to skip
2015-11-01 14:56:00.334 [bus notice] <aa
2015-11-01 14:56:00.336 [bus notice] >ff
2015-11-01 14:56:00.347 [bus debug] ERR: read timeout during ready, switching to skip
Zitat von: yellowpinky am 01 November 2015, 16:16:47
.. habe mit ebusctl r RoomTemp getestet, sieht irgendwie so aus ob am Bus nichts ausgegeben wird ?!
Anbei der LOG.
Hab da noch irgendwo ein konfig Problem ?
Die ebusd.debian in /root/ebusd/contrib/etc/default
hat den Inhalt:
EBUSD_OPTS="--acquiretime 6000 -l All -d /dev/ttyUSB0"
Dem Log nach zu urteilen kann Dein Interface nicht auf den Bus schreiben.
Warum ist der acquiretimeout denn runtergesetzt? Wenn dann hilft eher raufsetzen... Default ist 9400. Probier mal Weglassen in OPTS oder erhöhen.
ZitatDem Log nach zu urteilen kann Dein Interface nicht auf den Bus schreiben.
Warum ist der acquiretimeout denn runtergesetzt? Wenn dann hilft eher raufsetzen... Default ist 9400. Probier mal Weglassen in OPTS oder erhöhen.
...weder erhöhen noch weglassen bringt etwas. Den Wert mit 6000 hatte ich aus einem Forum. Gibt es sonst noch Timer oder Parameter?
Vermute ja auch einen Fehler am Adapter, den ich aber leider nicht finde. Beim Schleifentest wie im Forum beschrieben ist ja alles OK !?
@yellowpinky
ich kann mich erinnern, das die fertige Platine einen kleinen Fehler hatte. Beim Spannungsregler war der Ein/Ausgang verkehrt platziert, daher musst den Regler verkehrt (180 Grad) einsetzen. Ich weiß jetzt aber nicht, ob du auch so eine Platine mit diesem Fehler hast.
Wenn ja, dann kannst du nicht senden weil dann der Optokoppler U3 nie durchsteuert.
LG
Reinhart
@ Reinhart
Danke für die Antwort.
Problem der Version 1.3 ist mir bekannt. Der Spannungsregler ist richtig eingebaut.. der Schleifentest mit 20V und einem 1k Widerstand funkioniert ja.
Zitat von: yellowpinky am 01 November 2015, 17:05:29
...weder erhöhen noch weglassen bringt etwas. Den Wert mit 6000 hatte ich aus einem Forum. Gibt es sonst noch Timer oder Parameter?
Vermute ja auch einen Fehler am Adapter, den ich aber leider nicht finde. Beim Schleifentest wie im Forum beschrieben ist ja alles OK !?
Also wenn kein einziges gesendetes Byte vom Bus zurückgelesen werden kann, ist m.E. irgendwas an der Schaltung falsch. Das musst halt rausfinden.
Zitat von: john30 am 31 Oktober 2015, 08:19:54
Du könntest mal schauen, ob an dem Wandler Puffergrößen einstellbar sind. Für ebusd darf nichts gepuffert werden.
Danke erst einmal für den Tip zu Umwandlung von Hex-Befehlen in CSVs; klappt prima.
Mit den Serial-Ethernet-Konverter komme ich nicht weiter. Auch Puffergröße 0 (=sofort) und FIFO=off haben nichts gebracht. Der ebusd bekommt offenbar die Antwort-Bytes auf die gesendete Nachricht nicht rechtzeitig mit und versucht es dann in einer Endlosschleife mit durchlaufenden FF's (=NAK) hin und her ...
Ich werde wohl doch ein langes Serial-Kabel legen müssen oder gibt es dazu noch eine Idee ?
USB-Extender - geht bis zu 20 Metern Länge.
LG
pah
Hallo,
gibt es hier jemanden, der eine gefertigte Platine mit den z.Z. passenden Bauteilen anbietet ?
Wurde aufgrund der Problematik bezgl. der Kommunikationsabbrüche die Hardware angepasst (Bauteile, Werte) ?
Sinnvoll wäre ein eigener Thread zur "Eigenbau-Hardware", da alles ziemlichlich unübersichtlich ist bei 78 Seiten ;-) ....
PS:
Würde sowas auch funktionieren ? anstatt den USBtoTTL-Adapter ?
"HIER KLICKEN" (http://www.amazon.de/module-Ethernet-Serial-Server-Module/dp/B00L1VADUY/ref=pd_sim_sbs_23_1?ie=UTF8&dpID=41vEkLQUqmL&dpSrc=sims&preST=_AC_UL160_SR160%2C160_&refRID=03EDK4MGZ27RN95MH4RN)
Zitat
Sinnvoll wäre ein eigener Thread zur "Eigenbau-Hardware", da alles ziemlichlich unübersichtlich ist bei 78 Seiten
Darauf haben wir schon immer gewartet: dass uns Newcomer erklären, was sinnvoll ist. ::)
Zitat
Würde sowas auch funktionieren ? anstatt den USBtoTTL-Adapter ?
Wer mehr liest, hat mehr vom Leben.
http://www.fhemwiki.de/wiki/1W-IF-ETH
http://www.fhemwiki.de/wiki/1W-IF-WIFI
LG
pah
Erstaunlich, denn ich habe niemanden zum Lesen des "kompletten Forums" aufgefordert.
Die relevanten Dokumentationen stehen auch nicht auf 79 Seiten dieses Threads - sondern sind immer in kompakten Dokumenten für Anfänger und im Wiki verpackt. Und ja: ich fordere in der Tat dazu auf, diese zu lesen. Ist offenbar bisher nicht passiert.
Schließlich: Es steht jedem frei einen neuen Thread aufzumachen - und es besteht absolut kein Grund dafür, dies von anderen zu verlangen.
pah
.. wenn ich wüßte wo der Fehler in meinem Aufbau liegt wäre ich in der Lage einen bestückten Print incl. USB Adapter zu liefern, aber mit meinen momentanen Problemen wäre das nicht ganz fair :-\
.... hat noch jemand einen guten Tipp für mich... mein nächster Schritt wäre eine Messung auf dem ebus mit einem "Oszi".... wenn ich wüßte wo ich welche Werte zu erwarten hätte und diese messen soll ?
ZitatIch verfolge den Beitrag bereits seit einiger Zeit und habe mich vor einigen Wochen dazu entschlossen meine Gastherme Vaillant Vaillant ecoTEC plus VC AT 126/3-5H mit Regler calorMATIC 470 mit ebusd auszulesen.
Mein ebusd Adapter ist laut der Schaltung von pah (Als "kritische" Bauelemente verwende ich: Transistor: BD645 , Fairchild DC-Optokoppler: CNY171 / 70 V / 50 mA) und dem Print von zenti666 - Danke für eure Mühe. Der USB Adapter ist von ELV. Die Software in der Version 1.3.
Die Hi/Lo Abstimmung der Schaltung habe ich auf 13V abgestimmt und den Adapter wie hier beschrieben mit 20V und einem 1KOhm Widerstand einem Schleifentest unterzogen.
Der Poti der Schaltung ist jedoch fast auf Anschlag (0 kOhm) dadurch R2 testweise auf 500Ohm getauscht !
Als Endllösung möchte ich anstatt des USB Adapters eine TTY-LAN Adapter verwenden und die Schaltung mit 3,3V betreiben.... aber das dauert wohl noch ein wenig.
Und nun zu meinem Problem welches ich nicht in den Griff bekomme:
Der Empfang der Daten dürfte funktionieren -> keine CRC Alarme und ich bekomme sehr wenige "unknown BC cmd"
Ich kann aber anscheinend nichts abfragen, da nach "scan full" bei "scan result" nichts ausgegeben wird und auch eine Temperatur Abfrage keine Antwort ergiebt -> siehe LOG
Den ebus habe ich sowohl direkt, als auch über den Diagnose RJ Stecker getestet
Bitte um Eure Unterstützung
Daniel
Zitatgibt es hier jemanden, der eine gefertigte Platine mit den z.Z. passenden Bauteilen anbietet ?
@yellowpinky
Wie das Signal genau aussieht spielt jetzt noch keine große Rolle. Wenn dir ein Oszilloskop zur Verfügung steht ist der Fehler sicher schnell gefunden. Ich schreibe dir hier in Stichworten die Messpunkte und die Vorgangsweise auf wie ich es messen würde.
Den Masseanschluß vom Oszi mit GND verbinden und bei jeder Messung mit eBusd irgendwas senden. Ich würde das mit Putty per SSH durchführen.
beginne an U2-3 Pin8 oder 9 (TxD)
dann sollte an U2-3 Pin 10 dasselbe Signal negiert erscheinen
am Optokoppler an Pin5 muss 5 Volt konstant anliegen
dann am Optokoppler an Pin 4
an der Basis des BD645
ordentlich verstärkt dann am Collector des BD645
wenn du so vorgehst, wird irgendwo das Signal dann fehlen, d.h du hast den Fehler dann zwischen den letzten beiden Messpunkten.
Ich hoffe es hilft dir bei der Fehlereingrenzung weiter.
LG
Reinhart
@ Reinhart
Danke für die Unterstützung werde sobald möglich testen und eine Rückmeldung geben...
ja passt, bin selber schon neugierig was defekt ist.
Könnte mir auch eventuell vorstellen, dass die Zenerdiode verkehrt eingebaut ist oder wo eine kalte Lötstelle ist, aber das ist sicher schnell gefunden.
LG
Sollte sich aber auch alles ohne Oszilloskop messen lassen.Variable Spannung an den EBUS-Eingang und statisch messen, was herauskommt- und umgekehrt.
LG
pah
@ Reinhart & pah
Was ich nicht verstehe ist, dass in der Schleifen Messung (TerminalEmulation -> USB Adapter -> Ebus Adapter -> ebus mit 1kOhm und 20V von einem Netzgerät) die Daten die ich sende retour kommen. Das würde ja heissen, das alles funktioniert.
Habe jetzt so auf die Schnelle am ebus meiner Therme gemessen - die Sendedaten im gesamten Zweig sehen bei "ebusctl r RoomTemp" eher aus wie einzelne Flanken und nicht, wie die Daten der Therme auf der Empfangsseite, wie Bitmuster.
Zum genaueren Messen komme ich leider erst wieder zum Wochenende....
Zitat von: phantom am 02 November 2015, 18:29:24
Danke erst einmal für den Tip zu Umwandlung von Hex-Befehlen in CSVs; klappt prima.
gerne!
Zitat von: phantom am 02 November 2015, 18:29:24
Mit den Serial-Ethernet-Konverter komme ich nicht weiter. Auch Puffergröße 0 (=sofort) und FIFO=off haben nichts gebracht. Der ebusd bekommt offenbar die Antwort-Bytes auf die gesendete Nachricht nicht rechtzeitig mit und versucht es dann in einer Endlosschleife mit durchlaufenden FF's (=NAK) hin und her ...
Die Endlosschleife würde mich noch interessieren. Kannst Du mir da ein Log mit dump zukommen lassen? Auch gern per privater Mitteilung.
Ich habe mir Dein Timing noch einmal angesehen. Also viel Luft ist nicht, aber Du könntest mal versuchen, ebusd mit Paramter "--acquiretimeout=30000" zu starten. Dann sollte zumindest auf ">ff" und "<ff" noch die Adresse des Ziels gesendet werden.
Danach wird dann vermutlich Schluss sein, aber wenn es bis dahin klappt, würde ich noch einen zusätzlichen Parameter zur Änderung des generellen Sende-Timeouts einbauen. Dieser ist derzeit fix auf die doppelte Symboldauer eingestellt (9,4 ms).
Bei Dir kommt ein geschriebenes Symbol anscheinend erst nach 26 ms zurück, was normalerweise für drei Bytes statt nur einem reicht...
Zitat von: john30 am 03 November 2015, 07:05:15
Die Endlosschleife würde mich noch interessieren. Kannst Du mir da ein Log mit dump zukommen lassen?
@john:Ich habe drei Versuche mit dem Ethernet-Serial-Wandler (Moxa-NPort 5110) durchgeführt:
1. im RealCOM-Mode mit tty-driver-Kernel-Modul von Moxa (soll eine echte TTY nachbilden)
Mit ebusd ohne weitere Timing-Parameter (s. ebusraw_endless_loop) führt diese zur besagte Endlosschleife im ebusd :(
ebusd reagiert nicht mehr auf CTRL-C im Vordergrund und läßt sich nur noch abschießen.
2. im RealCOM-Mode mit tty-driver-Kernel-Modul von Moxa
Mit ebusd mit ebusd --acquiretimeout=30000 (s. ebusraw_aq_30000) gibts ein paar Read-Timeouts, aber ohne Endlosschleife :)
3. im TCP-Server-Mode des Wandlers ohne das Kernel-Modul (habe den -d ip:port Startparameter erst jetzt entdeckt :/ )
Damit klappt der ebusd via LAN problemlos, mit und ohne verlängerte aquiretime :D (s. ebusraw_ip)
Danke für deine Unterstützung. Es lag wohl am knappen Timing beim Wechsel von senden zu empfangen.
Die Sache mit der Endlosschleife ließe sich evtl. noch im ebusd optimieren, brauchst du noch mehr Logdaten dazu?
Besten Gruß Dirk
Zitat von: phantom am 03 November 2015, 22:45:29
Die Sache mit der Endlosschleife ließe sich evtl. noch im ebusd optimieren, brauchst du noch mehr Logdaten dazu?
Danke für die Logs, die sollten für eine erste Analyse reichen.
Zitat von: phantom am 03 November 2015, 22:45:29
Die Sache mit der Endlosschleife ließe sich evtl. noch im ebusd optimieren, brauchst du noch mehr Logdaten dazu?
So, ich denke das Problem ist mit commit https://github.com/john30/ebusd/commit/d402325 (https://github.com/john30/ebusd/commit/d402325) gelöst.
Es wär cool, wenn Du das nochmal gegen Deinen ersten Versuch testen könntest (RealCOM-Mode mit tty-driver-Kernel-Modul von Moxa), da sich das nicht so trivial nachstellen lässt.
John
ZitatIch verfolge den Beitrag bereits seit einiger Zeit und habe mich vor einigen Wochen dazu entschlossen meine Gastherme Vaillant Vaillant ecoTEC plus VC AT 126/3-5H mit Regler calorMATIC 470 mit ebusd auszulesen.
Mein ebusd Adapter ist laut der Schaltung von pah (Als "kritische" Bauelemente verwende ich: Transistor: BD645 , Fairchild DC-Optokoppler: CNY171 / 70 V / 50 mA) und dem Print von zenti666 - Danke für eure Mühe. Der USB Adapter ist von ELV. Die Software in der Version 1.3.
Die Hi/Lo Abstimmung der Schaltung habe ich auf 13V abgestimmt und den Adapter wie hier beschrieben mit 20V und einem 1KOhm Widerstand einem Schleifentest unterzogen.
Der Poti der Schaltung ist jedoch fast auf Anschlag (0 kOhm) dadurch R2 testweise auf 500Ohm getauscht !
Als Endllösung möchte ich anstatt des USB Adapters eine TTY-LAN Adapter verwenden und die Schaltung mit 3,3V betreiben.... aber das dauert wohl noch ein wenig.
Und nun zu meinem Problem welches ich nicht in den Griff bekomme:
Der Empfang der Daten dürfte funktionieren -> keine CRC Alarme und ich bekomme sehr wenige "unknown BC cmd"
Ich kann aber anscheinend nichts abfragen, da nach "scan full" bei "scan result" nichts ausgegeben wird und auch eine Temperatur Abfrage keine Antwort ergiebt -> siehe LOG
Den ebus habe ich sowohl direkt, als auch über den Diagnose RJ Stecker getestet
Bitte um Eure Unterstützung
Daniel
Hab jetzt mit dem Oszi einiges gemessen..
Komme mit meiner ebus Schaltung leider nicht weiter, In der Schleifenmessung ist aus meiner Sicht alles OK.
Wenn ich aber auf meine Heizung gehe wird am Bus nichts gesendet. Habe schon viele Stunden Investiert und finde den Fehler leider nicht :-[
Habe Z-Diode & T1 (BD645) auch schon getauscht.
Was ich auch nicht verstehe ist warum bei "ebusctl r RoomTemp" nur ein einzelnes Bit am TTY gesendet wird ?
Anbei einige Plots zu meinen Oszi Messungen.
Bild "Schleifenmessung":
Messung mit simulierten ebus 20VDC Netzgerät mit 1kOhm Widerstand in Serie.
Mit Terminal Hex 0A gesendet .... Bitmuster mit Start & Stop Bit ist OK finde ich.
Blau=ebus, Rot=TTY
Bild "Befehl ebusctl r RoomTemp":
Bei Befehl ebusctl r RoomTemp, Bitbreite 0,44ms
TTY sendet nur Einzelbit, Am ebus kommt nichts an !?
Blau=ebus, Rot=TTY
Bild "Messung Optokoppler Pin4":
Hatte beim Messen leider den falschen GND (vom TTY)
Blau=TTY, Rot=Pin4 Optokoppler
Bild "Messung nach R6":
Hatte beim Messen leider den falschen GND (vom TTY)
Fast kein Signal mehr nach dem Widerstand R6-22kOhm (Basis T1)
Blau=TTY, Rot=Pin4 Optokoppler
@yellowpinky
Schaltungstechnisch sieht es ja bis jetzt nicht so schlecht aus, leider hast du die wichtigste Messung am Collector des BD645 vergessen.
Die Messung nach R6 scheint auch in Ordnung zu sein, denn R6 begrenzt ja den Basis-Emitter Strom, sonst wäre es ja ein Kurzschluß am Transistor. Wenn nun ein Signal am R6 kommt, müsste der Darlingtontransistor durchschalten (und ordentlich Strom verstärken) und die Zenerdiode begrenzt hier den Strom/Spannung auf der Collector-Emitterstrecke. Was dieser BD645 nun letztlich macht ist das was "am eBus ankommt". Nimm bei dieser Messung bitte Pin4 des Gleichrichters als Masse. Du kannst dann auch noch am Pin3 des Gleichrichters messen, auch da muss das Signal dann sichtbar sein, weil auch hier die Spannung einbrechen muss damit am Master des eBus dies dann als Signal erkannt wird.
LG
Reinhart
@Reinhart
Habe zwischen Anode und Kathode der Z-Diode schon einmal gemessen und da hab ich das Signal auch mit den 7,5V gesehen... die fallende Flanke war nur etwas verschliffen.
Werde aber sobald möglich nochmals testen.. bin leider schon wieder unterwegs
Was meinst du mit Pin4 bzw.Pin3 der Gleichrichters ?
LGD
Ok, wenn du das schon gemessen hast, dann sehe ich jetzt in deiner aufgebauten Schaltung keine Fehler.
Mit Pin3 und Pin4 meine ich die Bezeichnung am Gleichrichter. Pah hat die Anschlüsse des Gleichrichters in der Schaltung mit mit 1,2,3,4 bezeichnet. 4 liegt auf Masse und 3 ist der positive Anschluss des eBus.
Was mir allerdings komisch vorkommt, ist das nur ein kurzes High-Signal sichtbar ist, dies ist ja schon am ersten Messpunkt so gewesen. Logischerweise könnte dann nur noch der Seriellwandler beim Sendeweg defekt sein und eben nur eine positive Flanke ausgeben und den Rest "verschlucken".
LG
Reinhart
Der kurze Impuls stört mich auch, vielleicht ist das eine Art Sync Bit das gespiegelt werden muss um dann mit der "echten" Sendung zu beginnen.
Die Bitlänge würde zu 2400 bit/s passen, da das Bit 4,4ms lang ist..
Wie gesagt die Schleifenmessung (siehe Bild Schleifenmessung) funktioniert ja, allerdings statt dem Rasp mit einem Windows PC mit Terminalprogramm .
Darum verstehe ich das Ganze nicht. Bin überzeut dass es ein ganz einfacher Fehler ist.... wenn ich ihn nur finden würde.
Könnte den Rasp noch tauschen und Linux und ebusd neu aufspielen !?
Danke für deine Mühe
LGD
Hm. Sind die vier Dioden der Gleichrichterschaltung richtig eingebaut ? Das kommt mir an der Stelle sehr seltsam vor.
LG
pah
Hab in schon überprüft.
Und die Dioden mit dem Bauteiltester gecheckt
LGD
Zitat von: john30 am 07 November 2015, 15:26:16
So, ich denke das Problem ist mit commit https://github.com/john30/ebusd/commit/d402325 (https://github.com/john30/ebusd/commit/d402325) gelöst.
Es wär cool, wenn Du das nochmal gegen Deinen ersten Versuch testen könntest (RealCOM-Mode mit tty-driver-Kernel-Modul von Moxa), da sich das nicht so trivial nachstellen lässt.
Hallo John,
ich habe den ebusd per git pull komplett aktualisiert (nun ebusd 2.0.0-preview) und alle drei Test nochmal durchgeführt:
1. RealCom / 2. RealCom mit aquiretimeout / 3. an TCP-Server (s. Logfiles)
Im RealCom-Mode (1.+2.) gibt es nun Timeouts anstelle der Endlosschleife -> gut so. Doch diese Betriebsart des NPort-5110 scheint einfach nicht schnell genug zu sein.
Im TCP-Server-Mode klappt es wie gehabt.
Ich denke es macht wenig Sinn, den Weg vom ebusd über die im RealCom-Mode emulierte virtuelle tty-Schnittstelle weiter zu verfolgen.
Der Weg über TCP klappt ja und ist bei den meisten Serial-Ethernet-Wandlern vorhanden (manchmal auch per UDP)
Gruß Dirk
Zitat von: phantom am 09 November 2015, 20:05:19
ich habe den ebusd per git pull komplett aktualisiert (nun ebusd 2.0.0-preview) und alle drei Test nochmal durchgeführt:
1. RealCom / 2. RealCom mit aquiretimeout / 3. an TCP-Server (s. Logfiles)
Im RealCom-Mode (1.+2.) gibt es nun Timeouts anstelle der Endlosschleife -> gut so. Doch diese Betriebsart des NPort-5110 scheint einfach nicht schnell genug zu sein.
Im TCP-Server-Mode klappt es wie gehabt.
Hallo Dirk,
Danke fürs Testen, dann kann ich das abhaken.
John
ZitatSchaltungstechnisch sieht es ja bis jetzt nicht so schlecht aus, leider hast du die wichtigste Messung am Collector des BD645 vergessen.
Die Messung nach R6 scheint auch in Ordnung zu sein, denn R6 begrenzt ja den Basis-Emitter Strom, sonst wäre es ja ein Kurzschluß am Transistor. Wenn nun ein Signal am R6 kommt, müsste der Darlingtontransistor durchschalten (und ordentlich Strom verstärken) und die Zenerdiode begrenzt hier den Strom/Spannung auf der Collector-Emitterstrecke. Was dieser BD645 nun letztlich macht ist das was "am eBus ankommt". Nimm bei dieser Messung bitte Pin4 des Gleichrichters als Masse. Du kannst dann auch noch am Pin3 des Gleichrichters messen, auch da muss das Signal dann sichtbar sein, weil auch hier die Spannung einbrechen muss damit am Master des eBus dies dann als Signal erkannt wird.
Hallo;
Ich war leider die letzen 2 Wochen unterwegs und konnte daher nicht testen.
Nun aber die Messungen zu meinem Schaltungsproblem.
Habe mit dem Oszi direkt an der Z-Diode gemessen (GL-Pin3 zu Collector T1)... siehe Bild.
Dies scheint auch in Ordnung zu sein.
Messe ich aber Gleichrichter Pin 3 zu Pin4 kommt sehe ich mein Signal nicht mehr.
Das würde ja heißen das der Transistor T1 (BD 645) nicht durchschaltet !?
Den hab ich aber auch schon getauscht... oder hab ich da noch ein Potential Problem ?
Hab auch noch ein Foto von meinem bestückten Print beigelegt, sieht aber nach all den Experimenten nicht mehr so Top aus
Bild "Messung Z_Diode":
Blau=Z-Diode, Rot=TTY
Danke Euch
Daniel
Ich kann dir nur sagen, du bist nicht alleine mit dem Fehler. Seit gestern in der Früh bekomme ich ebenfalls nur mehr die Broadcasts durch, der Rest sind in etwa die Fehlermeldungen die du hast. Es hat jetzt alles ein Jahr ohne Probleme funktioniert. Nach einigen Messungen musste ich feststellen, das meine Schaltung (ebenso wie deine) im Prinzip funktioniert aber ich nichts senden kann.
Bei den Messungen habe ich aber gleich noch einen Pulldown Widerstand (TxD mit 10 K gegen Masse) eingelötet weil der Pegel an den Eingängen des Cmos (Pin 8+9) bei Low 1,6 V betrug was nicht sauber ist (oder es zeigt sich hier schon der Fehler). Soweit ich aber bis jetzt beurteilen kann, deutet alles auf einen Defekt des USB Seriell Konverters, da ich keine Impulse an TxD bekomme. Es ist nur ein Impuls kurz beim einstecken, das wars.
Leider habe ich einen Konverter mit Prolific Chip 2303 und für den habe ich noch keinen Windows10 Treiber (der auch funktioniert) gefunden, somit kann ich keinen Loopback Test am PC durchführen. Der neue Seriell Konverter ist schon bestellt, kommt aber erst am Mo oder Di.
Wenn ich mir deine Fehlermeldungen so anschaue, dann haben die große Ähnlichkeiten wie mit meinen jetzt.
LG
Hallo John,
ich habe gestern die aktuelle 2.0 preview installiert und die Option scanconfig gestartet. Dabei werden die meisten csv files geladen. Nur die pmw und pms files werden scheinbar nicht geladen, obwohl diese auch vorhanden sind. Hast du eine Idee hierfür?
pi@raspberrypi /etc/ebusd $ ls
broadcast.csv _templates.csv vaillant
pi@raspberrypi /etc/ebusd $ cd vaillant
pi@raspberrypi /etc/ebusd/vaillant $ ls
05.vd2.csv 05.vl8.csv 08.ehp.csv 15.f47.csv 23.ehp.cc.csv 26.solsy.hc.csv 50.v61.csv broadcast.csv scan.csv
05.vd3.csv 05.vl9.csv 0a.pmw.hwc.csv 15.ui.csv 23.solsy.cc.csv 3c.rcc.5.csv 52.mc2.4.csv e0.omu.csv _templates.csv
05.vd4.csv 06.pms.csv 15.430.csv 15.uih.csv 25.ehp.hwc.csv 50.ehp.mc.csv 53.mc2.5.csv ec.solsy.sc.csv
05.vd6.csv 08.bai.HW7401.csv 15.470.csv 1c.rcc.4.csv 25.solsy.hwc.csv 50.solsy.mc.csv 75.rcc.csv ed.pms.sc.csv
localhost: info
version: ebusd 2.0.0-preview.ce4bc56
signal: acquired
symbol rate: 48
masters: 5
messages: 656
address 01: master #2, seen
address 03: master #3, seen
address 06: slave of 01, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address 08: slave of 03, seen, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 0a: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 10: master #6, seen
address 12: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave of 10, seen, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address f7: master #24, seen
address fc: slave of f7, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
Ich habe meinen Fehler am ebusd Adapter gefunden
Anscheinend hat T1 wirklich nicht durchgesteuert.
Habe nun den R6 von 22k auf 10k geändert und es funktioniert ;D ;D ;D
@Reinhart:
Habe den 10k PullDown bei mir auch eingebaut - kann ja nicht schaden ein definiertes Potential zu haben 8)
DANKE an alle die mich bei der Suche unterstützt haben
LG
Hm. War denn da auch wirklich ein Darlingtontransistor drin ? Der sollte mit 22k problemlos anzusteuern sein - mit dem BD645 geht es jedenfalls problemlos.
LG
pah
@ pah
.. war und ist ein BD645... kann ich mir auch nicht erklären :-\
Sieht man auch auf meinem Bestückungsfoto das ich gepostet habe.
LG
@yellowpinky
Freut mich wenn du denn Fehler endlich gefunden hast!
Wundert mich auch, das der Darlington Transistor bei 22 K Ohm nicht korrekt durchschaltet, aber wie du siehst sind es meist nur Kleinigkeiten. Es gibt hier mehre Typen vom BD648 wie A,B oder C sollte aber hauptsächlich die Spannung betreffen und nicht die Verstärkung.
Auch meine Schaltung funktioniert wieder. Bei mir war die Zenerdiode defekt, aber ich habe gleich ein paar Messpunkte aufgenommen wenn wieder jemand einen Fehler beim Sendebetrieb sucht.
Vorgangsweise bei der Sendemessung:
Ich habe dazu statisch gemessen (nicht am eBus) und mit einem 24 Volt Netzgerät über einen 5 Watt Vorwiderstand von 330 Ohm eingespeist. Den Seriel Wandler habe ich einfach zur Speisung in einen Laptop gesteckt. Sollte der Tx Ausgang nicht auf 0 V liegen, dann Kabel vom Wandler (nur Tx) abziehen und einen Pulldown Widerstand am Eingang (Pin8,9) legen damit hier definiert 0 V zur Messung anliegt. Wir müssen für die Sende Messung nämlich den 4011 zwingen, dass er am Pin10 "High" wird.
Die von mir ermittelten Spannungen können natürlich bei anderen je nach Streuung der Bauteile etwas abweichen. Ich habe zB. eine Zenerdiode mit 8,2 Volt eingebaut.
2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout
so haben die Fehlermeldungen im Log bei einem Sendeversuch ausgesehen (ebusd Version 2.0 Preview vom 28.11.2015). Alle Broadcast Meldungen waren natürlich ok.
LG
@ Reinhart
Die Simulation mit einem Netzgerät hatte ich ja auch gemacht !
Das Schlimme war nur, das hat alles korrekt funktioniert.
Das hat mich etwas auf die falsche "Fährte" gelockt.
.. aber jetzt haben wir es ja geschafft.. DANKE nochmal !!
LG
Zitat von: stinch am 29 November 2015, 05:21:13
ich habe gestern die aktuelle 2.0 preview installiert und die Option scanconfig gestartet. Dabei werden die meisten csv files geladen. Nur die pmw und pms files werden scheinbar nicht geladen, obwohl diese auch vorhanden sind. Hast du eine Idee hierfür?
Sollte mit dem commit https://github.com/john30/ebusd/commit/5f50c99 (https://github.com/john30/ebusd/commit/5f50c99) von gerade eben behoben sein.
Merci fürs Bescheid geben!
John
Hallo zusammen
Vielen Dank @john30 fuer den tollen ebusd! Das erleichtert einiges.
Ich habe leider einen TEM Regler (IT 5711 OGZ), welcher zwei Heizkreise steuert mit je einem FS 5601 (Fernstellregler im Raum - misst Temp, kann die Heizung off/Sonne/Uhr schalten und +/-3 Grad auf den Sollwert erwirken).
Wie andere auch schon festgestellt haben ist der Regler nicht so gespraechig bis auf die BC Telegramme 07/08, welche ich mittels CSV Dateien schoen dargestellt bekomme im Log dank E-Bus Doku. Dann gibt es nur alle paar Stunden noch 10fe10 Telegramme (TEM spezifisch), welche nirgends dokumentiert sind. Da vermute ich Zaehlerstaende. Betriebsstunden ueber 03h abfragen ist anscheinend nicht supported, wie auch alle 05h Befehle nicht gehen.
Mir fehlen aktuell noch folgende Werte: Raumtemperaturen (Soll und Ist), manueller Offset im Raum +3/-3 sowie der Betriebszustand (off/Sonne/Uhr).
Und ich wuerde gerne diese fehlenden Werte setzen sowie die Boilersollwerttemp oder einfach den Boiler on/off schalten.
Da TEM keine Hilfe gibt und auf geheimes geistiges Eigentum verweist, wirds schwierig! Eine Variante waere beim Servicetool mitlauschen. Ich habe aber weder ein Servicetool, noch Windows ::)
Funktionieren wuerde EEPROM und RAM lesen (und vermutlich auch schreiben) beim Regler mit 09h sowie RAM lesen beim Fernsteller FS5601. Es gleicht aber einer Nadel im Heuhaufen zu suchen...?
Etwas vertehe ich noch nicht. Man kann die Unterstuetzten Befehle abfragen mit 07h 03h (07h 05h geht nicht). Dann bekomme ich folgendes:
$ ebusctl write -h 9107030100 (Fernsteller, ..1 bringt das gleiche Resultat)
03010214
$ ebusctl write -h 1507030100 (Regler)
0a010000001f000000000f
$ ebusctl write -h 1507030101 (Regler - alle weitern 3, 4, 5 sehen gleich aus)
0a01000000000000000000
Auch nicht verstehen tue ich, warum ich zwischen dem Regler und den Fernstellern keine Kommunikation sehe auf dem Bus...
Zitat von: john30 am 01 Dezember 2015, 07:29:39
Sollte mit dem commit https://github.com/john30/ebusd/commit/5f50c99 (https://github.com/john30/ebusd/commit/5f50c99) von gerade eben behoben sein.
Merci fürs Bescheid geben!
John
Hallo,
vielen Dank für das Update.
Allerdings scheint weiterhin irgendwo ein kleiner Fehler zu bestehen. Wie unten zu sehen werden ein'ge Dateien noch nicht geladen, obwohl diese vorhanden sind.
pi@raspberrypi /etc/ebusd/vaillant $ ls
05.vd2.csv 05.vl8.csv 08.ehp.csv 15.f47.csv 23.ehp.cc.csv 26.solsy.hc.csv 50.v61.csv broadcast.csv scan.csv
05.vd3.csv 05.vl9.csv 0a.pmw.hwc.csv 15.ui.csv 23.solsy.cc.csv 3c.rcc.5.csv 52.mc2.4.csv e0.omu.csv _templates.csv
05.vd4.csv 06.pms.csv 15.430.csv 15.uih.csv 25.ehp.hwc.csv 50.ehp.mc.csv 53.mc2.5.csv ec.solsy.sc.csv
05.vd6.csv 08.bai.HW7401.csv 15.470.csv 1c.rcc.4.csv 25.solsy.hwc.csv 50.solsy.mc.csv 75.rcc.csv ed.pms.sc.csv
pi@raspberrypi /etc/ebusd/vaillant $ ebusctl
localhost: i
version: ebusd 2.0.0-preview.5f50c99
signal: acquired
symbol rate: 41
masters: 5
messages: 824
address 01: master #2, seen
address 03: master #3, seen
address 06: slave of 01, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave of 03, seen, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 0a: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #6, seen
address 12: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave of 10, seen, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address f7: master #24, seen
address fc: slave of f7, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"Existieren die Dateien "fc.pmw...." Und "12.pmw..."?
Viele Grüße und danke
David
Zitat von: stinch am 02 Dezember 2015, 19:59:41
Allerdings scheint weiterhin irgendwo ein kleiner Fehler zu bestehen. Wie unten zu sehen werden ein'ge Dateien noch nicht geladen, obwohl diese vorhanden sind.
welche meinst du denn?
ich sehe keine mehr, die vorhanden sind und nicht geladen werden.
Zitat von: stinch am 02 Dezember 2015, 19:59:41
Existieren die Dateien "fc.pmw...." Und "12.pmw..."?
Mangels irgendwelcher Erkenntnisse darüber: nein.
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
Ich habe leider einen TEM Regler (IT 5711 OGZ), welcher zwei Heizkreise steuert mit je einem FS 5601 (Fernstellregler im Raum - misst Temp, kann die Heizung off/Sonne/Uhr schalten und +/-3 Grad auf den Sollwert erwirken).
Damit bist Du dann meines Wissens der vierte TEM Benutzer im Bunde. Wollkommen! :-)
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
Mir fehlen aktuell noch folgende Werte: Raumtemperaturen (Soll und Ist), manueller Offset im Raum +3/-3 sowie der Betriebszustand (off/Sonne/Uhr).
Und ich wuerde gerne diese fehlenden Werte setzen sowie die Boilersollwerttemp oder einfach den Boiler on/off schalten.
Vielleicht sollte ich mal ein eigenes Forum für TEM öffnen, wo man diese Details besprechen kann.
Hast Du mal die https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv (https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv) und "read heating room" bzw. "roomnominal" probiert?
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
Etwas vertehe ich noch nicht. Man kann die Unterstuetzten Befehle abfragen mit 07h 03h (07h 05h geht nicht). Dann bekomme ich folgendes:
$ ebusctl write -h 9107030100 (Fernsteller, ..1 bringt das gleiche Resultat)
03010214
das müsste laut eBUS Spezifikation bedeuten: unterstützte PBSB sind 0502, 0504
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
$ ebusctl write -h 1507030100 (Regler)
0a010000001f000000000f
das müsste bedeuten: unterstützte PBSB sind 0700-0704, 0C00-0C03
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
$ ebusctl write -h 1507030101 (Regler - alle weitern 3, 4, 5 sehen gleich aus)
0a01000000000000000000
das müsste bedeuten: gar keine unterstützten PBSB
Zitat von: thomhug am 02 Dezember 2015, 17:49:59
Auch nicht verstehen tue ich, warum ich zwischen dem Regler und den Fernstellern keine Kommunikation sehe auf dem Bus...
Ist Dein Fernsteller denn auf "Raumaufschaltung" eingestellt? Andernfalls gibt es ja nichts, was der Fernsteller dem Controller sagen müsste, es sei denn Du verstellst die gewünschte Rumatemperatur.
Zitat von: john30 am 03 Dezember 2015, 07:45:52
Damit bist Du dann meines Wissens der vierte TEM Benutzer im Bunde. Wollkommen! :-)
Besser als alleine!
Zitat von: john30 am 03 Dezember 2015, 07:45:52
Vielleicht sollte ich mal ein eigenes Forum für TEM öffnen, wo man diese Details besprechen kann.
Bin dabei meine Erkenntnisse zu teilen!
Zitat von: john30 am 03 Dezember 2015, 07:45:52
Hast Du mal die https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv (https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv) und "read heating room" bzw. "roomnominal" probiert?
Ja hatte ich, leider ohne Erfolg.
Zitat von: john30 am 03 Dezember 2015, 07:45:52
das müsste laut eBUS Spezifikation bedeuten: unterstützte PBSB sind 0502, 0504
Da mag der FS aber nicht antworten...
Zitat von: john30 am 03 Dezember 2015, 07:45:52
das müsste bedeuten: unterstützte PBSB sind 0700-0704, 0C00-0C03
0C00 - 0C03 ist spannend, was ist das? Das finde ich nicht in meiner Doku (spec_prot_7_v1_6_3_d).
Zitat von: john30 am 03 Dezember 2015, 07:45:52
Ist Dein Fernsteller denn auf "Raumaufschaltung" eingestellt? Andernfalls gibt es ja nichts, was der Fernsteller dem Controller sagen müsste, es sei denn Du verstellst die gewünschte Rumatemperatur.
Was ist Raumaufschaltung? Ich habe jetzt den ebusd auf raw gestellt und da gibt es tatsaechlich eine Kommunikation zwischen Regler und FS alle 5.5 Stunden! Die Telegramme werden aber vom ebusd ignoriert?
Habe folgendes mal aufbereitet aus "raw" und jeweils zwischen "aa" geschnitten. "ff" waere NACK? Was ist "fe" am Schluss? Muesste da nicht ein "00" fuer ACK sein statt ff/fe? Warum der Regler an die FS Telegramme schickt und nicht umgekehrt, leuchtet mir auch nicht ein.
Gemaess Doku haben Einstellungen am FS Vorrang, d.h. wenn ich an der Heizung etwas verstelle, wird das nach ein paar Minuten wieder umgestellt. Deshalb wuerde ich erwarten, dass da regelmaessig Telegramme vom FS kommen muessten - ausser der Regler speichere das.
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec ff
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec ff
10 91 10 0a 0e d1 15 09 03 03 03 04 03 02 03 02 03 01 ff 1f ff
10 91 10 0a 0e d1 15 09 03 03 03 04 03 02 03 02 03 01 ff 1f ff
10 90 10 0a 02 00 04 88 fe
10 90 10 0a 02 00 04 88 fe
10 91 10 0a 02 00 05 6c ff
10 91 10 0a 02 00 05 6c ff
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec fe
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec ff
10 91 10 0a 0e d1 15 09 03 03 03 04 03 02 03 02 03 01 ff 1f ff
10 91 10 0a 0e d1 15 09 03 03 03 04 03 02 03 02 03 01 ff 1f ff
10 90 10 0a 02 00 04 88 fe
10 90 10 0a 02 00 04 88 ff
10 91 10 0a 02 00 05 6c ff
10 91 10 0a 02 00 05 6c ff
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec fe
^^^^^ Temp?
@zentis666
Zitat von: zentis666 am 30 Mai 2015, 14:06:53
Falls irgendjemand im Nachgang noch eine Sammelbestellung machen will kann er gerne die Produktionsdaten und die Stüli bekommen.
Hallo Sven, ich würde gerne eine neuerliche Sammelbestellung von Platinen durchführen und möchte gerne auf dein Angebot zurück kommen. Kannst du mir bitte die Produktionsdaten zukommen lassen?
LG
Reinhart
Zitat von: john30 am 03 Dezember 2015, 07:11:42
welche meinst du denn?
ich sehe keine mehr, die vorhanden sind und nicht geladen werden.
Mangels irgendwelcher Erkenntnisse darüber: nein.
Hi
25.solsy und es.pms werden nicht geladen. Oder ist das eine nicht kompatible Datei, die vorhanden ist?
Viele Grüße
David
Sammelbestellung eBus Platinen!
Zentis666 war so freundlich und hat mir seinen Platinenfiles für den eBus Konverter (nach Schaltung pah) und die Bestelldaten zur Verfügung gestellt. Ich möchte daher eine erneute Sammelbestellung durchführen und bei Interesse bitte diesen Link benutzen: http://forum.fhem.de/index.php/topic,45127.0.html (http://forum.fhem.de/index.php/topic,45127.0.html)
LG
Reinhart
Hallo zusammen,
ich lese hier auch schon länger mit, habe nun den gesamten Thread durch :) und melde mich nun auch mal.
Habe vor einigen Tagen endlich den eBus-Koppler USB von eService erhalten. Ziel ist es, meine Vaillant (ecoTEC plus 146/5) über den Rasperry (FHEM) abzufragen.
Leider bekomme ich - wie schon andere vor mir - über den Bus hauptsächlich die "signal acquired"/"signal lost" Meldungen, aber auch "max. symbols per second"!?
pi@raspberrypi ~ $ /usr/bin/ebusd -f -l ALL -d /dev/ttyUSB0
2015-12-03 22:49:26.682 [main notice] ebusd 2.0.0-preview.5f50c99 started
2015-12-03 22:49:26.690 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2015-12-03 22:52:48.711 [bus notice] signal acquired
2015-12-03 22:52:57.002 [bus error] signal lost
...
2015-12-03 22:53:02.600 [bus notice] signal acquired
2015-12-03 22:53:04.021 [bus notice] max. symbols per second: 147
2015-12-03 22:53:06.031 [bus error] signal lost
...
2015-12-03 22:53:32.049 [bus notice] signal acquired
2015-12-03 22:53:33.000 [bus notice] max. symbols per second: 265
2015-12-03 22:53:34.000 [bus notice] max. symbols per second: 961
2015-12-03 22:54:12.001 [bus notice] max. symbols per second: 962
Auch über --lograwdata bekomme ich, egal bei welcher Poti-Einstellung, keine sauberen Daten rein. Zudem werden,sobald ich ebusd starte die Daten vom Außentemperatur-Fühler und dem Zeitgeber nicht mehr auf der Calormatic (470) angezeigt!?
Jetzt bin ich auf der Fehlersuche:
- Netzteil nicht stabil genug? zentis666 hatte ein ähnliches Problem.
- Kann es an der neuen 2.0.0-preview Version liegen?
- Hardware/Software?
Hat jemand von euch eine Idee? Ich wäre dankbar für jeden Tipp.
LG
Ben
Hi Ben,
bei mir war es am Ende ein Problem mit dem Linux Kernel und FTDI Treiber.
Wenn Du noch ein anderes Linux Gerät hast probier mal das, vielleicht ist das Problem dann weg.
Ich hatte dieses Verhalten mit einem Raspberry Pi, mit einem Netbook mit Ubuntu war das Problem weg.
Ein anderes Netzteil hat zwar bewirkt, dass der Fehler seltener auftritt, weg war er aber damit nicht.
Gruß
Sven
Danke Sven, für die schnelle Antwort.
Ich aktualisiere jetzt erst mal die Firmware des Raspberry. Wenn das nicht hilft, kann ich natürlich testweise Mal Ubuntu parallel auf meinem Win-PC installieren und damit testen.
Schönen Gruß
Ben
Zitat von: thomhug am 03 Dezember 2015, 12:19:30
0C00 - 0C03 ist spannend, was ist das? Das finde ich nicht in meiner Doku (spec_prot_7_v1_6_3_d).
das weiß ich auch nicht, aber wenn man der Spez. glauben schenkt, dann ist das die Bedeutung.
Zitat von: thomhug am 03 Dezember 2015, 12:19:30
Was ist Raumaufschaltung?
Das ist, wenn man den Raumregler so einstellt, dass die Differenz zwischen gemessener Raumtemperatur und Soll-Raumtemperatur die Regelung der Vorlauftemperatur beeinflusst.
Zitat von: thomhug am 03 Dezember 2015, 12:19:30
Ich habe jetzt den ebusd auf raw gestellt und da gibt es tatsaechlich eine Kommunikation zwischen Regler und FS alle 5.5 Stunden! Die Telegramme werden aber vom ebusd ignoriert?
Das hat einen Grund, siehe unten.
Zitat von: thomhug am 03 Dezember 2015, 12:19:30
Habe folgendes mal aufbereitet aus "raw" und jeweils zwischen "aa" geschnitten. "ff" waere NACK? Was ist "fe" am Schluss? Muesste da nicht ein "00" fuer ACK sein statt ff/fe? Warum der Regler an die FS Telegramme schickt und nicht umgekehrt, leuchtet mir auch nicht ein.
Ja, FF bedeutet NACK, also die Antwort vom adressierten Gerät, dass die CRC falsch ist.
Zitat von: thomhug am 03 Dezember 2015, 12:19:30
10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff ec ff
Hier wäre die richtige CRC z.B. "93" (statt EC). Folgerichtig kommt ein NACK.
Somit hast Du also einigermaßen gravierende Probleme mit Deiner Busleitung, die Du schleunigst beheben solltest. Kann natürlich gut sein, dass der Anschluß des ebus Interfaces das negativ beeinflusst. Wie sind denn deine Leitungslängen?
[/code]
Bitte zur Vermeidung einer Begriffsverwirrung nicht von Firmware schreiben, wenn das Betriebssystem eines Universalrechners gemeint ist.
LG
pah
Zitat von: stinch am 03 Dezember 2015, 18:02:34
25.solsy und es.pms werden nicht geladen. Oder ist das eine nicht kompatible Datei, die vorhanden ist?
Ah, jetzt weiß ich was Du meinst.
Das liegt wohl daran, dass Du schon eine WW Instanz hast (0a.pmw). Damit überschneiden sich die Definitionen.
Wenn Du die Datei "25.solsy.hwc.csv" umbenennst nach "25.solsy.2.hwc.csv", dann klappt es.
Damit taucht die zweite WW Instanz dann mit circuit "hwc.2" auf.
Ist das denn eine zweite Warmwasser-Station?
Zitat von: beni.s am 05 Dezember 2015, 00:10:34
Habe vor einigen Tagen endlich den eBus-Koppler USB von eService erhalten. Ziel ist es, meine Vaillant (ecoTEC plus 146/5) über den Rasperry (FHEM) abzufragen.
Leider bekomme ich - wie schon andere vor mir - über den Bus hauptsächlich die "signal acquired"/"signal lost" Meldungen, aber auch "max. symbols per second"!?
2015-12-03 22:53:02.600 [bus notice] signal acquired
2015-12-03 22:53:04.021 [bus notice] max. symbols per second: 147
2015-12-03 22:53:06.031 [bus error] signal lost
...
2015-12-03 22:53:32.049 [bus notice] signal acquired
2015-12-03 22:53:33.000 [bus notice] max. symbols per second: 265
2015-12-03 22:53:34.000 [bus notice] max. symbols per second: 961
2015-12-03 22:54:12.001 [bus notice] max. symbols per second: 962
- Netzteil nicht stabil genug? zentis666 hatte ein ähnliches Problem.
- Kann es an der neuen 2.0.0-preview Version liegen?
- Hardware/Software?
Über 960 Symbole/Sekunde klingt nach einem Zeitproblem. Läuft da ein NTP drauf?
Um die 2.0 Version als Fehlerquelle auszuschließen kannst ja einfach mal eine ältere aus den https://github.com/john30/ebusd/releases (https://github.com/john30/ebusd/releases) probieren.
Zitat von: john30 am 05 Dezember 2015, 11:35:56
Ah, jetzt weiß ich was Du meinst.
Das liegt wohl daran, dass Du schon eine WW Instanz hast (0a.pmw). Damit überschneiden sich die Definitionen.
Wenn Du die Datei "25.solsy.hwc.csv" umbenennst nach "25.solsy.2.hwc.csv", dann klappt es.
Damit taucht die zweite WW Instanz dann mit circuit "hwc.2" auf.
Ist das denn eine zweite Warmwasser-Station?
hi,
ok, werde ich heute nachmittag probieren. nein, ich habe nur eine warmwasserstation. meine anlage besteht aus einem Brenner, einer warmwasserstation, einer solarstation, einer vrs620 sowie einem Speicher.
Viele Grüße
Zitat von: john30 am 05 Dezember 2015, 10:15:46
das weiß ich auch nicht, aber wenn man der Spez. glauben schenkt, dann ist das die Bedeutung.
Du hast gesagt ich sei der 4. TEM Benutzer. Hast du evtl. Infos zu den Erkenntnissen der ersten drei? Telegramme entschluesseln ist ja das eine aber wenn es darum geht, RAM Speicheradressen oder nicht dokumentierte Abfragekommandos zu benutzen, wirds sehr schwierig.
Zitat von: john30 am 05 Dezember 2015, 10:15:46
Das ist, wenn man den Raumregler so einstellt, dass die Differenz zwischen gemessener Raumtemperatur und Soll-Raumtemperatur die Regelung der Vorlauftemperatur beeinflusst.
Wie es genau funktioniert weiss ich nicht. Gemaess Dokumentation kann der FS die Temperatur messen. Ob diese zur Regelung verwendet wird, ist mir nicht bekannt. So wie es aktuell aussieht, wird die nicht verwendet.
Zitat von: john30 am 05 Dezember 2015, 10:15:46
Ja, FF bedeutet NACK, also die Antwort vom adressierten Gerät, dass die CRC falsch ist.
Hier wäre die richtige CRC z.B. "93" (statt EC). Folgerichtig kommt ein NACK.
Hmm. Also ich habe diese C-Programm aus dem Mikrokontroller Forum genommen und damit die CRC ueberprueft. Bei 10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff bekomme ich aber ec als CRC, wie auf dem Bus mitgesnifft. Die 10 90 Telegramme sind auch immer genau gleich mit dem selben CRC. Kann es sein, dass der ebusd die ignoriert wegen dem NACK?
Bei den 10 FE 10 Telegrammen (welche auch im Abstand von ca. 5.5h zusammen mit 10 9X kommen) erkennt ebusd diejenigen mit korrekter CRC und die mit falscher werden ignoriert. Da muessten jeweils 24 kommen und im Extremfall sind 16 mit falscher CRC, manchmal auch nur 4. 10 9X sind aber immer korrekt und die bekannten 07 xx und 08 xx habe ich noch nie falsch gesehen.
Zitat von: john30 am 05 Dezember 2015, 10:15:46
Somit hast Du also einigermaßen gravierende Probleme mit Deiner Busleitung, die Du schleunigst beheben solltest. Kann natürlich gut sein, dass der Anschluß des ebus Interfaces das negativ beeinflusst. Wie sind denn deine Leitungslängen?
Ich glaube da ist etwas anderes nicht richtig. Bei einem Problem auf dem Bus wuerde ich ein anderes Fehlerpattern erwarten. Ich koennte aber natuerlich mal probieren an einem anderen Ort anzudocken.
Leitungen mit geschaetzten 2mm Draehten vielleicht 5m zum 90 FS und einen Stock hoeher zum 91 FS vielleicht 10m. Mein ebusd sitzt mit einem 1m Kabel direkt am Regler. Allerdings habe ich nur 0.5mm Querschnitt genommen.
Momentan stoert mich das weniger.
Bin immer noch interessiert, die Heizung zu beeinflussen. Bisher habe ich noch folgendes rausgefunden:
Die 10 FE 10 0A Telegramme (TEM spezifisch) kommen in 8 Varianten vor. Das erkennt man an den ersten zwei Bytes nach der Telegrammlaenge: 10 00, 10 01, 10 02, 10 03, 11 00, 11 01, 11 02, 11 03. Wie ich in Dumps von anderen Reglern gesehen habe, haengt die Anzahl Varianten von den Anzahl Heizkreisen ab. Ich habe zwei Heizkreise und bei den 10 XX Telegrammen bezieht sich 10 00 auf den ersten, 10 01 auf den zweiten, 10 02 wieder auf den ersten Heizkreis, usw. Darin kommen vermutlich einige Einstellungen und u.a. Boilertemp, Vorlauf Soll, Vorlauf Ist, Kesseltemp und ein paar andere vor. Ich habe es aber noch nicht 100% verifiziert.
Ich habe schon mal probiert, die Telegramme von 10 an 90, welche immer mit NACK quittiert werden selber an 90 zu senden. Bei den langen bekomme ich 00 als Bestaetigung und bei den kurzen spannenderweise folgendes:
$ ebusctl write -h 90100a020004
051004a50001
$ ebusctl write -h 91100a020005
051005be0001
Das habe ich nun schon oft probiert und veraendern tut sich nur das dritte Byte (a5 oder a4, resp be oder etwas zwischen ba und c2). Das koennten Raumtemperaturen/10 sein. Wenn ich das letzte Byte vertausche, kommt das vertauscht an zweiter Stelle zurueck, bringt also nichts - es kommt also das zurueck was ich eingebe. Am vermuteten Temperaturbyte aendert sich nichts.
Als naechstes muss ich vor Ort Werte verstellen und schauen wie sich die Telegramme veraendern. Ebenfalls bin ich daran RAM und EEPROM auszulesen und zu schauen was sich da veraendert. Allerdings mit bisher maessigem Erfolg...
Wenn alles nicht hilft, bleibt wohl nur noch das Servicetool von TEM zu besorgen (oder auszuleihen - anyone?) und dann auf dem Bus zu schauen was passiert wenn man Werte veraendert...
Freue mich auf Inputs von anderen TEMlern...
Zitat von: thomhug am 06 Dezember 2015, 11:30:29
Du hast gesagt ich sei der 4. TEM Benutzer. Hast du evtl. Infos zu den Erkenntnissen der ersten drei? Telegramme entschluesseln ist ja das eine aber wenn es darum geht, RAM Speicheradressen oder nicht dokumentierte Abfragekommandos zu benutzen, wirds sehr schwierig.
Ein Ergebnis daraus liegt hier (noch auf 2.0 hochgezogen): https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner)
Da wird vermutlich in nächster Zeit noch einiges passieren.
Zitat von: thomhug am 06 Dezember 2015, 11:30:29
Hmm. Also ich habe diese C-Programm aus dem Mikrokontroller Forum genommen und damit die CRC ueberprueft. Bei 10 90 10 0a 0e d1 14 09 03 02 03 02 03 03 03 01 ff 01 ff bekomme ich aber ec als CRC, wie auf dem Bus mitgesnifft. Die 10 90 Telegramme sind auch immer genau gleich mit dem selben CRC. Kann es sein, dass der ebusd die ignoriert wegen dem NACK?
stimmt, hab mich in der Zeile vertan. ec ist richtig. dann weiß ich auch nicht, warum der Adressat mit NACK antwortet.
Diese Nachrichten werden von ebusd in der Tat verworfen.
Zitat von: thomhug am 06 Dezember 2015, 11:30:29
Bei den 10 FE 10 Telegrammen (welche auch im Abstand von ca. 5.5h zusammen mit 10 9X kommen) erkennt ebusd diejenigen mit korrekter CRC und die mit falscher werden ignoriert. Da muessten jeweils 24 kommen und im Extremfall sind 16 mit falscher CRC, manchmal auch nur 4. 10 9X sind aber immer korrekt und die bekannten 07 xx und 08 xx habe ich noch nie falsch gesehen.
Das ist aber schon eine ganz schön hohe Fehlerquote. Dass als NACK auch öfter mal "fe" da steht ist auch merkwürdig. Ist eigentlich nicht erlaubt...
Zitat von: ecopower_andreas am 18 Oktober 2015, 21:03:51
ich habe von Vaillant ein EcoPower 1.0 Mikro BHKW... Systemregler 1.0. ... eBus ... CAN Bus.
Kann man generell einen Systemregler via eBus abfragen und bekommt man alle Informationen ausgelesen...?
...Daten wie Aussentemperatur, sowie Speichertemperatur auslesen möchte. Aber genau diese Fühler sind direkt auf dem Systemregler aufgelegt. ... Kann es somit sein, dass ich diese Daten nicht über den eBus aus dem Regler abfragen kann?
...aber ich würde den steinigen Weg gehen wenn es Erfolg versprechend ist.
weiß nicht ob das hilft oder überhaupt noch gelesen wird, falls aber: ich habe seit 2012 ebenfalls ein ecoPower 1.0 in Betrieb. Damals gab es die eBus-Anbindung noch nicht. Habe das daher damals etwas anders gelöst (s.u.) und so läuft das heute noch. Ich bezweifle, dass eBus bei der Anlage zum Erfolg führt, denn die Anbindung nach außen macht der Systemregler über diese unsichere Java-Applikation, die munter die Passworte rausposaunt. Damit hat es Vaillant seinerzeit ja in die c't geschafft. Vorteil der Java-Anwendung ist, dass man darüber mit dem richtigen Passwort auch Daten über die Gemischaufbereitung, Motortemperaturen, Nadelventilposition und ähnliche Dinge bekommt, die man zwar nicht täglich braucht aber die manchmal helfen. So hab ich z.B. festgestellt, dass der Installateur mein BHKW auf die falsche Gassorte (E-Gas) eingestellt hat, obwohl wir hier LL-Gas haben.
Diese Werte gehen nicht über eBus - und die von Dir gewünschten Werte Außentemperatur und Speichertemperatur kannst Du anders u.U. einfacher erfassen, nämlich über dedizierte Temperaturfühler. So mache ich das seit 2012, nur mal als Beispiel:
- Außentemperatur bespreche ich nicht weiter, hat jeder irgendwo her
- Puffertemperaturen unten/mitte/oben: In 3 Fühlerröhren stecken PTC-Sensoren, mein Puffer (800L, 2m hoch) hat weitere leere Röhren, dort habe ich 1-wire Temperaturfühler platziert. Würden notfalls auch noch mit in die Originalröhren passen, falls es keine Extraröhren gibt
- Ich habe damals weitere 1-wire-Sensoren verbaut am BHKW-Vor-/Rücklauf etc., nach persönlichem Belieben
- Eine Sache muss ich auch fernsteuern, weil ich sie nicht parametrisieren konnte: Wenn die Hausbatterie voll ist, soll das BHKW abschalten, weil ich den Strom nicht einspeisen möchte. Bei 85% SOC darf es wieder einschalten, wenn Wärmebedarf vorliegt. Realisiert über einen potentialfreien 1-wire-Schalter und einen Widerstand, der geschaltet der Anlage 76°C Puffertemperatur unten signalisiert. Bei 75°C unten geht das BHKW nämlich von einem geladenen Wärmespeicher aus und schaltet ab. Die Heizung/Warmwasser etc. bleiben unbeeinträchtigt, die achten nur auf die Puffertemperaturen mitte / oben. Wenn die Batterie wieder aufnahmefähig ist, bekommt der Regler die echte Puffertemperatur unten zurück. Noch ein Grund, weshalb mein eigener Temperatursensor am Puffer hilfreich ist ;)
- Mit der Steuerung passe ich den häuslichen Strommix auch an, wenn z.B. die PV absehbar längerfristig viel liefert (bekomme Direktverbrauch für Haus oder zum Laden des Autos noch gut vergütet und treibe ihn an, überschüssige PV geht bei mir aber nicht in die Hausbatterie, sondern wegen der Speicherkosten ins Netz) - SMA und Vaillant sprechen sonst auch völlig verschiedene Sprachen leider.
- Den Spitzenlastkessel (und nur den) lasse ich über einen anderen 1-wire Schalter an S.31 auf Sommerbetrieb, solange nicht Räume über zu weit geöffnete Ventile signalisieren, dass die vom BHKW bereitgestellte Wärme deutlich nicht reicht.
Lieber wäre mir natürlich auch eine elegantere Steuerungsmöglichkeit z.B. über eBus. Bei der Anlage müsste man für ein einigermaßen vollständiges Bild aber über die LAN-Schnittstelle und diese dusselige Java-Applikation gehen. Dafür reichen meine Kenntnisse nicht. Läuft aber auch so seit 2012 zuverlässig für das, was ich täglich brauche. Und die sonstigen Daten lese/steuere ich halt im Bedarfsfall über mein VPN per Browser. Der Systemregler sendet mir auch eine Mail, wenn es ein Zipperlein hat.
Die genannten Daten gehen mit hoher Wahrscheinlichkeit als broadcast über den eBus.
LG
pah
Zitat von: john30 am 06 Dezember 2015, 12:35:10
Ein Ergebnis daraus liegt hier (noch auf 2.0 hochgezogen): https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner)
Da wird vermutlich in nächster Zeit noch einiges passieren.
Mit diesen Ochsner Daten kann ich nichts anfangen. Ich scheine da einen anderen Regler zu haben. Ich habe einen "TEM IT 5710 MX - 1 CTC". Baujahr 2000 :o
Zitat von: john30 am 06 Dezember 2015, 12:35:10
Das ist aber schon eine ganz schön hohe Fehlerquote. Dass als NACK auch öfter mal "fe" da steht ist auch merkwürdig. Ist eigentlich nicht erlaubt...
Irgendwas scheint nicht so zu funktionieren wie es soll. Gehe dem noch auf den Grund.
Zitat von: Prof. Dr. Peter Henning am 07 Dezember 2015, 17:00:25
Die genannten Daten gehen mit hoher Wahrscheinlichkeit als broadcast über den eBus.
Habe daraufhin mal weiter gesucht in der Tat kann ein anderer Betreiber des Systems diese Daten über den eBus Broadcast lesen. Er kann allerdings den Motor nicht steuern, was nahe liegt (CAN-Bus). Wem also die Heizungsseite reicht, der sollte ruhig die Anbindung über eBus auch beim EcoPower versuchen.
Zitat von: thomhug am 07 Dezember 2015, 17:05:54
Mit diesen Ochsner Daten kann ich nichts anfangen. Ich scheine da einen anderen Regler zu haben. Ich habe einen "TEM IT 5710 MX - 1 CTC". Baujahr 2000 :o
Irgendwas scheint nicht so zu funktionieren wie es soll. Gehe dem noch auf den Grund.
So, ich habe jetzt zwischen 0xf000 und 0xffff im EEPROM und im RAM so ziemlich viele Werte gefunden! Sehr spannend. Ich hoffe jetzt mal die RAM Adressen sind statisch und die aendern sich nicht wenn man die Heizung "neu bootet" :) Wobei RAM waere nicht so schlimm wie EEPROM, da dort die Settings sind.
Nun ist mir nicht klar, warum die Werte immer mehrfach vorkommen. Im EEPROM ist alles doppelt (z.B. 2 Heizkreise, 2 Sollwerte = 4 Eintraege). Im RAM ist es dann noch schlimmer, die Kesseltemperatur kommt da doch sage und schreibe 7x vor!! Ich habe alle Eintraege verfolgt, die werden brav alle aktualisiert.
Wenn jetzt eine Solltemperatur nur 1x vorgekommen waere im EEPROM, dann haette ich die mal ueberschreiben und geschaut was passiert. Bei doppelten Werten bin ich aber unsicher. Ich will da nicht noch eine Racecondition produzieren auf der Heizung :-\ Wie sind da eure Erfahrungen?
Zitat von: thomhug am 08 Dezember 2015, 22:20:56
Nun ist mir nicht klar, warum die Werte immer mehrfach vorkommen. Im EEPROM ist alles doppelt (z.B. 2 Heizkreise, 2 Sollwerte = 4 Eintraege). Im RAM ist es dann noch schlimmer, die Kesseltemperatur kommt da doch sage und schreibe 7x vor!! Ich habe alle Eintraege verfolgt, die werden brav alle aktualisiert.
Wenn jetzt eine Solltemperatur nur 1x vorgekommen waere im EEPROM, dann haette ich die mal ueberschreiben und geschaut was passiert. Bei doppelten Werten bin ich aber unsicher. Ich will da nicht noch eine Racecondition produzieren auf der Heizung :-\ Wie sind da eure Erfahrungen?
Also, das Mysterium ist geloest: Anscheinend gibt es nur 2kB EEPROM, d.h. 0xf000 ist das gleiche wie 0xe000 und sogar gleich 0xf800. So habe ich mal probiert, einen Wert zu setzen und es hat geklappt!!! Raumtemperatur im EEPROM geaendert: Wert im RAM hat sich geaendert und die Solltemperatur vom Heizkreis hat sich auch geaendert! JUHEEE!
Wo sich der Heizungsstatus versteckt, habe ich noch nicht rausbekommen ohne vor Ort zu gehen. Dafuer kann man mit EEPROM write etwas mehr riskieren, da man nicht gleich erfriert wenn die Heizung crasht 8)
# Raumsolltemperatur Heizkreis rot: (UIN/10 d2 00 = 21.00 Grad)
$ eeprom-read.sh 70f3
02d200
21.00
# Solltemperatur Heizkreis rot
$ ram-read.sh 2af6
02a601
42.20
# Register 70f3 (also 0xf370) mit (96 00) ueberschreiben (UIN/10 = 15.00)
$ ebusctl write -h 1509030470f39600
00
# Schreibvorgang hat geklappt
$ eeprom-read.sh 70f3
029600
15.00
# Der Regler hats auch gemerkt, Solltemperatur ist sofort tiefer
$ ram-read.sh 2af6
022901
29.70
ram-read.sh und eeprom-read.sh machen nichts anderes als ebusctl write -h 15090003${1}02 und mir den UIN/10 Wert berechnen.
Hallo John,
auf dem Cubietruck habe ich den ebusd V1.2 und jetzt möchte ich die version V1.3 instalieren.
Muss ich vorher V1.2 deinstalieren?, wenn ja, wie? oder vird V1.2 von V1.3 ersetzt?
Danke, Gerhard
Zitat von: Gerhard am 10 Dezember 2015, 18:49:58
auf dem Cubietruck habe ich den ebusd V1.2 und jetzt möchte ich die version V1.3 instalieren.
Muss ich vorher V1.2 deinstalieren?, wenn ja, wie? oder vird V1.2 von V1.3 ersetzt?
Cubietruck kenn ich jetzt nicht. Wenn Du das Debian Package genommen hast, dann einfach dpkg -i mit neuem Paket ausführen.
Zitat von: john30 am 05 Dezember 2015, 11:39:50
Über 960 Symbole/Sekunde klingt nach einem Zeitproblem. Läuft da ein NTP drauf?
Um die 2.0 Version als Fehlerquelle auszuschließen kannst ja einfach mal eine ältere aus den https://github.com/john30/ebusd/releases (https://github.com/john30/ebusd/releases) probieren.
Kurze Rückmeldung - hat etwas länger gedauert:
Habe den Raspberry Pi aktualisiert und bin jetzt wieder auf ebusd 1.3.0 - keine Veränderung, es gibt weiterhin die "signal lost"-Meldungen, zu viele Symbole/Sekunde und kein brauchbares Log.
Um mal eine Alternative auszuprobieren, habe ich Ubuntu auf einem Laptop installiert - damit läuft alles und ebusd liefert ein ordentliches Log, es werden 3 Master erkannt und Abfragen funktionieren. Somit weiß ich schon mal, dass der Koppler läuft.
Jetzt frage ich mich nur, was ich am Raspberry ändern muss, damit es auch darauf sauber läuft. Bei anderen läuft das ja auch!?
- Betriebssystem ist derzeit Raspian. Wechseln? Arch Linux?
- NTP läuft darauf per default.
- Kann es ggf. an der Spannungsversorgung des ebus-Kopplers (eservice) liegen? Der hängt derzeit direkt am USB des Raspberry Pi 2.
@beni.s
also ich betreibe den eBus schon über einem Jahr auf dem Raspi mit Debian, Fhem 5.7 und eBus 1.2 (werde aber demnächst auf 1.3 wechseln) ohne Probleme.
Ich habe aber auch schon in anderen Foren gelesen, dass einige User Probleme mit den Netzgeräten des Raspi haben, speziell bei dir wenn hier noch die Stromversorgung des eBus Kopplers drauf hängt. Wenn es dir möglich ist, dann versuceh doch einfach ein anderes Netzgerät bevor du großartig umstellst. Ich verwende am Raspi nur Netzteile mit mindestens 2 A, doch es ist auch bei diesen Angaben nicht gesagt ob das auch wirklich stimmt.
LG
Reinhart
@Reinhart
Danke für die Antwort.
Okay, werde es mal mit einem anderen Netzteil ausprobieren. Verwende zwar extra für diese Anwendung eins mit 2,1A, aber vielleicht stimmen wirklich einfach die Angaben nicht.
Gruß
Benjamin
Hallo zusammen,
hat evtl. schon einer die Adresse für D.29 herausgefunden ? Das ist der Volumenstrom, der tatsächlich grad im Umlauf ist. Ich würde den gerne nutzen um die tatsächlich abgegebene Leistung berechnen zu können.... Alle Versuche (auch mit Johns Hilfe) sind bislang leider nicht erfolgreich gewesen...
Hat's schon jemand raus ?
Grüße
Christian
Was ist denn gemeint mit "Volumenstrom, der gerade im Umlauf ist" ? Wo sollte der Volumenstrom denn sonst sein ?
Vaillant nennt dies die Umlaufwassermenge, und es ist unklar, ob das tatsächlich die direkte Auslesung des internen Vortex-Sensors ist (und welche Einheiten das sind, und wie genau die Messung ist...). Wenn das der Fall wäre, könnte man einfacherweise mit der hier angegebenen Rechnung
http://www.fhemwiki.de/wiki/Ertragsmessung_Solarthermie
(allerdings ohne die Spezialitäten von Tyfocor) die Leistungsmessung druchführen.
LG
pah
Zitat von: beni.s am 12 Dezember 2015, 22:03:40
...
Jetzt frage ich mich nur, was ich am Raspberry ändern muss, damit es auch darauf sauber läuft. Bei anderen läuft das ja auch!?
- Betriebssystem ist derzeit Raspian. Wechseln? Arch Linux?
- NTP läuft darauf per default.
- Kann es ggf. an der Spannungsversorgung des ebus-Kopplers (eservice) liegen? Der hängt derzeit direkt am USB des Raspberry Pi 2.
Habe es jetzt getestet. Andere Netzgeräte ergaben das gleiche Ergebnis.
Dennoch läuft es jetzt auf dem Raspberry. Die Lösung derzeit ist: Erst ebusd laufen lassen, dann Fhem starten.
Die Ursache ist mir noch nicht ganz klar. Folgende Zeilen im Fhem-Logfile machten mich stutzig:
2015.12.15 20:29:20 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2015.12.15 20:29:25 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2015.12.15 20:29:25 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)
2015.12.15 20:29:26 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP2_0)
2015.12.15 20:29:31 3: Setting TCM_ESP2_0 serial parameters to 9600,8,N,1
2015.12.15 20:29:31 1: /dev/ttyUSB0 reappeared (TCM_ESP2_0)Gruß
Benjamin
Hallo Benjamin!
immerhin hast du den Fehler ja schon gefunden, liegt offensichtlich bei der seriellen Kommunikation die ständig abbricht und ein Reconnect versucht wird.
Was ist denn das überhaupt für eine Device der "TCM_ESP2_0" ? Ist das der eBus Koppler? Mach sonst einmal ein "lsusb" am Raspi und poste das. Eventuell kannst du ja Fhem einmal stoppen und schauen ob diese Fehlermeldung dann auch noch kommt und ob dies einen Einfluss auf die Fehlermeldungen des eBuslog hat.
Wie hast du den Koppler angeschlossen, ist der nahe dem Raspi oder näher dem eBus der Therme. Das eBuskabel ist von der Länge her eher unkritisch (20 Meter sollten auch nichts machen), aber das USB Kabel würde ich von der Länge als kritischer sehen und möglichst kurz halten und könnte ohne weiteres die Ursache der Reconnects sein. Der "reappeared" kommt ja dann wenn nach einem Timeout keine Antwort kommt, dann versucht er es einfach wieder und wieder.....
Was mich noch wundert, die Baudrate wird hier mit 9600 ausgegeben, aber laut Doku des Kopplers soll der auf 2400 eingestellt sein. Aber ich kenne diesen Koppler nicht und kann daher auch nicht genau sagen ob das passen sollte, lies hier vielleicht in deiner Doku noch einmal genau nach. Aber vielleicht ist dieser Device ja nicht dein Koppler, das wissen wir erst nach "lsusb" genauer. Oder es meldet sich jemand der diesen Koppler hat und schaut nach wie der sich bei ihm anmeldet.
LG
Reinhart
Hallo Reinhart,
das "TCM_ESP"-Gerät besitze ich gar nicht - ist wohl ein EnOcean-Gateway.
Laut FHEM-HowTo wird beim Start von FHEM standardmäßig nach angeschlossenen USB-Gräten gesucht (initialUsbCheck) und ggf. automatisch in die fhem.cfg geschrieben.
Mein Koppler (eService) wurde wahrscheinlich falsch erkannt und erzeugte damit folgende Zeile in der cfg:
define TCM_ESP2_0 TCM ESP2 /dev/ttyUSB0@9600
daher auch die 9600 Baud.
Ich habe den initialUsbCheck auskommentiert und daher läuft es nun.
Danke für den Support!
Gruß
Benjamin
Hallo Benjamin!
Freut mich wenn das nun zur Lösung deines Fehlers beigetragen hat und nun fehlerfrei läuft.
Diese Art von Fehler kannte ich nicht, da ich einen eigenen Raspi (b+) habe auf dem der eBus läuft. Auf diesem Raspi läuft keine Fhem Instanz und die Kommunikation erfolgt einfach via ECMD und die serielle USB Schnittstelle steht alleine für den FTDI Adapter zur Verfügung.
Das hat zusätzlich den Vorteil, dass ich am eBus basteln und testen kann ohne FHEM weiter zu beeinflussen. Der Nachteil ist halt der doppelte Stromverbrauch des Raspi, aber davon habe ich schon 3 Stück in Betrieb weil ich einen Raspi2 noch zusätzlich im Stromverteiler eingebaut habe um 3 x S0 Zähler direkt über GPIOs zu erfassen. Mir persönlich ist eine klare Trennung der unterschiedlichen "Module" lieber, aber das muss jeder für sich selbst entscheiden wie es besser ins Gesamtkonzept passt.
LG
Reinhart
Hallo PAH,
ich gehe mal davon aus, daß mit D.29 der Volumenstrom gemeint ist, den die Pumpe aktuell durch das System drückt. Die Einheit dürfte m³/h sein, denn wenn ich Warmwasser bereite, dann liegt das bei ca. 1, mein Wärmemengenzähler am Speicher zeigt dann auch ca. 1m³/h mit Einheit an. Die Berechnung der Momentanleistung, die gerade vom Gesamtsystem abgenommen wird, wäre also kein Problem über Delta T (Vorlauf-Rücklauf). Für den Warmwasserkreis habe ich so eine Schätzung, weil ich dort 1m³/h "annehme", weil der Speicherkreis ja konstanten Durchfluss haben sollte (es ändert sich ja dort nichts während der Bereitung). Für den Heizkreis kann ich das ohne den D.29 nicht schätzen, weil die Pumpe auch bei fest eingestellten 50% und Energiespar an trotzdem immernoch ein wenig regelt. Außerdem ändert sich ja auch ständig was an den Thermostatventilen. Hundertprozentig genau müßte das ja garnicht mal sein. Also: Wäre schön, wenn man den D.29 auslesen könnte :-) John hatte mir im Mikrocontroler-Forum auch schon den Tip mit Grab/grab result gegeben, aber bei mir und einem anderen aus dem Forum hat das leider nicht so geklappt, deshalb hatte ich die Hoffnung, im FHEM-Kreis hätte es schon einer heraus gefunden.
Schöne Grüße
Christian
Zitat von: cs-online am 13 Dezember 2015, 19:54:52
hat evtl. schon einer die Adresse für D.29 herausgefunden ? Das ist der Volumenstrom, der tatsächlich grad im Umlauf ist. Ich würde den gerne nutzen um die tatsächlich abgegebene Leistung berechnen zu können.... Alle Versuche (auch mit Johns Hilfe) sind bislang leider nicht erfolgreich gewesen...
Versuch mal "w -h 08b509030dfb00" und teile das Ergebnis durch 100.
Wenn da sowas ähnliches wie der angezeigte d.29 Wert rauskommt, wäre mal Dein scan result interessant :-)
VG John
Zitat von: cs-online am 19 Dezember 2015, 09:16:48
Hallo PAH,
ich gehe mal davon aus, daß mit D.29 der Volumenstrom gemeint ist, den die Pumpe aktuell durch das System drückt. Die Einheit dürfte m³/h sein, denn wenn ich Warmwasser bereite, dann liegt das bei ca. 1, mein Wärmemengenzähler am Speicher zeigt dann auch ca. 1m³/h mit Einheit an.
Gemäß "Installations- und Wartungsanleitung auroCompact" steht bei mir in der Tabelle "d.29 - Messwert des Durchflusssensors - in m 3 /h"
Hallo,
@ John: bei D.29 = 1.02 kommt mit "w -h 08b509030dfb00" -> 02bf06, wenn sich der Rechner nicht vertut, müßte das 179974 Dez entsprechen, also 1799,74, passt also leider nicht... schade. Der Wert schwankte auch bei mehrmaligem Abfragen ein wenig, aber im Display blieb es (sprang einmal kurz nach 0.96 und zurück) konstant.
@MS_9:Messwert des Durchflusssensors - in m 3 /h, ist bei meiner EcoTec Exclusiv auch so, würde ich deshalb doch wohl meinen, daß das ein Volumenstrom ist. Wenn ich Warmwasser bereiten lasse, dann liegt der bei ca. 1m³/h, was sich mit dem Wärmemengenmesser deckt. Bei Heizbetrieb schwankt das meist deutlich drunter.
Grüße
Christian
Zitat von: cs-online am 20 Dezember 2015, 13:57:03
@ John: bei D.29 = 1.02 kommt mit "w -h 08b509030dfb00" -> 02bf06, wenn sich der Rechner nicht vertut, müßte das 179974 Dez entsprechen, also 1799,74, passt also leider nicht... schade. Der Wert schwankte auch bei mehrmaligem Abfragen ein wenig, aber im Display blieb es (sprang einmal kurz nach 0.96 und zurück) konstant.
nicht ganz, denn das erste Byte der Antwort "02" ist die Länge und der Rest sollte in UIN codiert sein. Damit wäre der Wert 1727, was aber immer noch nichts mit dem realen Wert zu tun haben scheint.
Der Punkt ist: es gibt von der BAI mindestens 6 verschieden Varianten, die sich in den Messages teilweise deutlich unterscheiden. Ausschlaggebend für die Auswahl der richtigen Variante ist das Scan Result und hier insbesondere die HW Version. Schau doch mal nach, was Deine BAI so dazu sagt, dann kommen wir dem Ziel vielleicht etwas näher.
In zwei der 6 BAI Varianten gibt es den Wert d.29 und dieser ist ein Mal als UIN definiert mit Einheit "l/h" und ein Mal als UIN geteilt durch 100 ohne Einheit.
1727 durch 100 ist scheint aber auch noch nichts mit 1.02 zu tun zu haben. Es sei denn, das UI gibt noch einen Faktor drauf und der UIN Wert ist lediglich eine Darstellung der Rohdaten...
VG John
Hi John,
hier der Scan / Scan result:
localhost: scan result
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002
Grüße
Christian
Zitat von: cs-online am 21 Dezember 2015, 20:21:58
hier der Scan / Scan result:
localhost: scan result
08;Vaillant;BAI00;0703;7401
Tja, damit sind die potentiellen d.29 Messages für HW Version 6701 und 0902 definitiv nicht passend.
Du kannst ja mal ein bisschen beobachten, ob es einen Zusammenhang zwischen dem angezeigten d.29 Wert und dem Ergebnis von "w -h 08b509030dfb00" gibt. Vielleicht lässt sich so ein Faktor determinieren, der vom UI auf den Wert angewendet wird.
Schöne Weihnachten an alle,
John
Hallo zusammen,
und frohe Weihnachten!
Vielleicht kann mir jemand einen Tipp geben. Ich habe einen ebus-Koppler vom Weihnachtsmann bekommen ;D
Ich bin dann gleich dem Wiki von FHEM und John30 gefolgt.
Habe soweit ebusd auf einem raspi per .deb Packet in der Version 1.3.0 installiert und soweit wie ich es verstanden habe konfiguriert. Im Ordner /etc/ebusd/ liegen folgende Files:
- 430.csv
- bai.csv
- broadcast.csv
- common.csv
- scan.csv
- _templates.csv
diese Dateien habe ich alle aus dem git 1.x.x "Verzeichnis" geladen (nicht verändert).
Welche ich nehmen musste, habe ich anhand des scans ermittelt.
Meine Heizung ist eine auroCompact VSC S 196/3-5 200 mit calorMatic 430. Außerdem sind zwei Solarpanels auf dem Dach für Warmwasser.
Wenn ich nun den ebusd laufen lasse "ebusd -f -l All -d /dev/ttyUSB0" erhalte ich folgende Ausgaben (siehe Anhang).
Kann mir jemand erklären was das für ein Error ist? Oder was der unknow BC ist?
Ich kann über ebusctl Daten auslesen und auch schreiben. Wie z.B. die Heizkurve ändern und den Status des Heizkreises auf "Aus", "Auto" und "Manuel" ändern.
Vielen Dank im Voraus.
Zitat von: rufus999 am 25 Dezember 2015, 11:46:37
Wenn ich nun den ebusd laufen lasse "ebusd -f -l All -d /dev/ttyUSB0" erhalte ich folgende Ausgaben (siehe Anhang).
Kann mir jemand erklären was das für ein Error ist?
Also "ERR: element not found" beim Dekodieren des Status01 liegt daran, dass der Wert 4 für den Pumpenstatus noch nicht definiert ist. Kannst Du mal vielleicht im Handbuch nachschauen, ob es da irgendeinen Spezialwert gibt? Vielleicht Frostschutz oder sowas?
Werde mal einbauen, dass unbekannte Werte einfach als Zahl ausgegeben werden, dann passiert sowas künftig nicht mehr.
Zitat von: rufus999 am 25 Dezember 2015, 11:46:37
Oder was der unknow BC ist?
Die "unknown" Einträge im Log sind schlicht Nachrichten, die noch nicht dekodiert werden, weil sich a) noch keiner die Mühe gemacht hat oder b) der Inhalt unbekannt ist. Für a) gibt es das Ticket https://github.com/john30/ebusd-configuration/issues/3 (https://github.com/john30/ebusd-configuration/issues/3) um die ganzen unbekannten und gesehene Werte zu sammeln.
Zitat von: rufus999 am 25 Dezember 2015, 11:46:37
Ich kann über ebusctl Daten auslesen und auch schreiben. Wie z.B. die Heizkurve ändern und den Status des Heizkreises auf "Aus", "Auto" und "Manuel" ändern.
Das ist eine Frage, oder?
Die Heizkurve kannst Du z.B. mit "ebusctl write -c 430 Hc1HeatCurve 0.25" einstellen, Heizkreis mit "ebusctl write -c 430 Hc1OPMode off" ausschalten (respektive "manual" oder "auto").
Hallo John30,
vielen Dank für deine schnelle Antwort.
Okay verstehe. Ich werde mal in der Anleitung nach sehen. Das Ändern der Heizkurve und Heizkreis funktioniert.
Danke
ZitatWelche ich nehmen musste, habe ich anhand des scans ermittelt.
Wie lautet der Aufruf für einen Scan ?
Kann die Platine parallel zu "der Heizung mit dem Regler" angeschlossen werden ?
Zitat von: RainerS am 25 Dezember 2015, 18:52:58
Wie lautet der Aufruf für einen Scan ?
Kann die Platine parallel zu "der Heizung mit dem Regler" angeschlossen werden ?
ebusctl scan full
danach
ebusctl scan resultund ja, die Platine kann dazu parallel angeschlossen werden. Das Bussystem ist Multimasterfähig mit bis zu max. 25 Mastern und 228 Slaves, also insgesamt maximal 253 Teilnehmern.
Hallo zusammen und Frohe Weihnachten.
Wollte einfach alle hier nochmal grüßen und mich für die Hilfe vor genau einem Jahr bedanken.
Genau an Weihnachten hatte ich die Zeit genutzt, meine Heizung in FHEM einzubinden.
Bei mir läuft die ebusd-Heizungssteurung seit 1 Jahr produktiv und stabil mit einer Vaillant ecotec plus, Calormatic 470, einem ebusd-Adapter von eservice-online und einem Raspi B :-)
Dem schließe ich mich an. Läuft bei mir auch sehr stabil mit dem Selbstbau-Adapter. Daher bin ich gerade auch nicht mehr viel am experimentieren.
schöne Grüße
Jo
Hallo zusammen,
ich wünsche Euch allen wunderschöne Weihnachten und möchte mich auf diesem Wege bei allen bedanken, die uns alle und mich im Speziellen immer so toll unterstützen !!!
@John:
Wenn die Heizung in die Nachtabsenkung geht und die Pumpe dann ganz ausgeschaltet ist (also 0,0m³/h), kommt mit Deinem Befehl:
EBUS raw => 020000
Grüße
Christian
PS: Ich verwende EBUSD V1.1.0, falls das wichtig ist
Vielen Dank an alle, die beigetragen haben, dieses Projekt voranzutreiben.
Läuft stabil mit ebusd sowie
auroMatic 620, ecoTECplus, VPS S Solarstation, (Trinkwasserstation leider ohne ebus), eservice-Koppler auf einem raspberry via ECMD und weiteren FHEM-Modulen u. Komponenten (HM).
Habe in diesem Zusammenhang sehr viel über meine Anlage gelernt (sowie FHEM, Perl u. Linux).
Wünsche alles Gute und hoffe, dass es so weitergeht.
Servus aus München
Hallo Leute,
hat mal Jemand von Euch eBusd auf Android kompiliert/installiert? Kennt Ihr vielleicht eine Stelle, woher ich ein Install-Paket auf Android herunterladen kann?
Vielen Dank im Voraus, und ein frohes Fest noch!
LG, Adam
Hallo und ebenfalls frohe Weihnachten,
ich starte gerade mit meinem EBUS Projekt und habe ebenfalls wie Jojo und Heikoh eine Vaillant Ecotec Plus, könnte vll. irgendwer von euch das WIKI soweit ergänzen, dass man hier im Thread nicht alle 84 Threadseiten durchackern muss oder kurz und bündig ein kleines How-To schreiben?
Mein Plan bzw. meine Einkaufsliste:
USB-TTL - RPi2 - EBUS-Platine mit Bauteile - USB WLAN Dongle
Fragen:
Kann für FHEM und Heizungssteuerung der gleiche RPi verwendet werden? Ich möchte nur Temperatur auslesen und festlegen bzw. sagen welcher Stellantrieb beim Heizverteiler zumacht und welcher nicht.
Wie heikel ist der Bus, ich habe für Stromversorgungszwecke in jeder Steckdose ein Cat6E Kabel liegen, das derzeit 12V, 5V etc. bereitstellt, die sind aber überall zusammengelötet. Könnte ich hier zwei Litzen verwenden oder ist das zu "russisch"...
Brauche in jedem Raum noch Temperaturfühler, hätte hier 1-Wire oder Funk Hygro-Thermofühler genommen, hat von euch wer Erfahrung was da zurzeit am besten läuft, bzw. mich aufschlauen was ihr so einsetzt? Würde für 1-Wire ebenfalls das Cat6 nutzen.
Vielen Dank schonmal, freue mich schon ;D
Es zählt immer zu meinen schönsten Erlebnissen, wenn ein Neuling als erstes verlangt, dass man ihm "kurz und bündig ein kleines How-To" schreibt. Mein Tipp: Selbst schreiben.
Antworten, kurz und bündig:
Ja
Ja,nein
Ja.
1-Wire Fragen bitte im richtigen Forum stellen.
LG
pah
Hallo zusammen,
ich möchte bei meiner Wolf CGB-2-20 auch den Ebus abfragen, um von der Heizung Werte zu erhalten. Da ich Neuling in der Thematik bin, wollte ich mal Fragen wie ich die Daten am besten an eine SPS senden kann (Wago 750-881). Versteh ich das richtig, dass das separat laufende Raspberry wo ebusd drauf läuft, alle Daten empfängt und diese dann aufbereitet weiterleitet an FHEM? Oder wird die Auswertung in FHEM durchgeführt? Am liebsten wäre es mir wenn ich die Daten aufbereitet zur SPS geschickt bekomme.
Hat jemand hier schon Erfahrungen? Wie kann man dies am geschicktesten lösen?
Danke für Eure Unterstützung
Gruß
Benno
Kann man natürlich auf dem Raspberry machen - einfaches Shell-Skript mit ein paar awks und seds.
LG
pah
;D hab mit so einer Antwort schon gerechnet, versuchen kann man es ja ;). Werd mich dahinter setzen, sobald alle Einzelteile da sind.
Dein ja,nein bezieht sich auf ebus/1-wire oder?
Lg
Die Entwickler entwickeln sich die Finger blutig, um die Sachen ans Laufen zu bekommen. Da wäre es doch nur angemessen, wenn diejenigen, die hinterher davon profitieren wollen, sich um die Verbesserung der Dokumentation kümmern. Korrigiert mich, wenn das falsch sein sollte.
Auch weiß ich nicht, was eine "funktionierende Anleitung" sein soll. Immerhin haben es nach meiner Kurzanleitung diverse Leute geschafft, die Einbindung in FHEM (nicht die Anleitung ...) zum Laufen zu bekommen.
@e3xtreme: 3 Fragen, 3 Antworten. 2 Frage war:
ZitatKönnte ich hier zwei Litzen verwenden oder ist das zu "russisch"...
=> Ja/Nein
LG
pah
Achso das war die Antwort auf russisch ;D, danke
meine Antwort von vorhin war für dich gedacht Peter, Rainer war da schneller am tippen.
Wie gesagt, sobald ich Fortschritte mache werd ich berichten und ein How-To schreiben, wenn ich was zusammen bringe.
Habe erst gestern die Einzelteile bestellt und die Ebus Platine zu löten wird auch noch ein Spaß... also wird noch dauern
hmmm....
da wir beim Thema EBUS(D) doch überwiegend John zu verdanken haben, daß wir überhaupt etwas mit unseren Vailant-Thermen machen können, will ich mal kurz auf seine Seite verweisen, dort ist ein EBUS-Wiki und es wird dort auch alles recht gut erklärt.
Zu finden hier:
https://github.com/john30/ebusd/wiki/
Dann hat PAH auf der ersten Seite dieses Threats beschrieben, wie man EBUS und EBUSD in FHEM hineinbekommt.
Da sowohl FHEM als auch EBUSD unheimlich umfangreiche Möglichkeiten bieten und das alles eben nicht "Standard" ist, können wir hier nicht alle Möglichkeiten abbilden, aber ich habe die Erfahrungen gemacht, daß auch dann hier nette Antworten von den Fachleutchen kommen, wenn die selbe Frage schon öfters da war aber trotzdem (weil man eben nicht alle zig Seiten aufmerksam durchlesen kann) von newbies nochmals gestellt wird.
Und, ja, es hat sich schon einer daran gesetzt, alles aufzuschreiben:
http://forum.fhem.de/index.php/topic,46098.0.html
Grüße
Christian
Zitat von: e3xtreme am 28 Dezember 2015, 16:25:34
Achso das war die Antwort auf russisch ;D, danke
meine Antwort von vorhin war für dich gedacht Peter, Rainer war da schneller am tippen.
Wie gesagt, sobald ich Fortschritte mache werd ich berichten und ein How-To schreiben, wenn ich was zusammen bringe.
Habe erst gestern die Einzelteile bestellt und die Ebus Platine zu löten wird auch noch ein Spaß... also wird noch dauern
Hallo und guten Abend,
wenn alles so einfach wäre wie eine Platine löten, hätte ich schon alles am laufen. Ich versuche mich auch schon einige Zeit an dem Projekt "ebus".
Als nicht IT´ler habe ich diverse Probleme alle Zusammenhänge zu verstehen. Ich habe auf einem Raspi ebusd installiert, oder hoffe zumindest, dass ich das geschafft habe. Wenn ich ebusd starte kann ich in einem andere Fenster mit telnet und anschließend mit listen sehen, dass sich einige Daten ändern bzw. angezeigt werden. Ich kann auch mit dem read-Befehl gezielt Werte abrufen. Was aber ein scan oder auch andere Sachen machen verstehe ich nicht. Mein Ziel ist es die Daten die ich lesen kann in eine Datenbank abzulegen und auszuwerten. Habe aber keine Ahnung wie das geht. Auch habe ich viele Meldungen "unknown MS cmd" . Ich denke das liegt an den .csv Dateien die ich im etc/ebusd Verzeichnis haben muss. Aber wie gesagt als IT-Neandertaler ist dass alle schwer zu verstehen, da baue ich mir lieber wieder eine neue Heizung, weil mit Sauerstoff und Gas kann ich hervorragend Rohre löten und habe bei der Erneuerung meiner Heizungsanlage keinen Handwerker gebraucht. Jetzt will ich aber die Steuerung verstehen und will die Daten, die mir die Vaillantsteuerung ausspuckt aus- bzw. verwerten. In den Anhängen habe ich mal ein paar Sachen reingepackt, die ich leider nicht richtig verstehe. Vielleicht kann ich ja ein paar Platine löten und bekommen einen Crashkurs in Informationstechnologie. Lach!!
Mein Problem ist es, wie kann ich die Daten auslesen und so speichern, dass ich sie auswerten kann. Also Datenbank! Ich bin ja schon absolut fasziniert, wenn ich per telnet mit entsprechenden read Befehlen tatsächlich Werte auslese, die ich erwarte. Was mir fehlt ist ein Automatismus die Werte die ich haben möchte zu speichern und dann in einer Tabelle darzustellen. Ein Highlight wäre es diese ganzen Daten dann in einer Visualisierung darzustellen.
VG Roland
Hallo Rainer,
davon darfst Du dich nicht entmutigen lassen, wie bei PAH schon am Namen zu erkennen ist, ist der gute von Beruf Professor, die müssen von Haus aus so reagieren ;-) Und manchmal sind einige eben wichtiger als andere (wenn wir alle unsere Berufsbezeichnungen im Namen hätten, würde der Kollege auch staunen). Also: das wird nicht so heiss gegessen, wie gekocht, nimm was Du brauchen kannst, ignoriere was Dich ärgert. Wichtig ist doch, daß hier die richtigen Kracks mitlesen und die richtigen Tips geben. Alle waren mal Newbies und nur durch Lektüre und probieren voran gekommen.
Und alle, die hier sind, weil sie helfen möchten, geben auch keine blöden Kommentare :-)
Grüße
Christian
@RainerS: Irgendwie scheinen wir aneinander vorbei zu reden.
ZitatIch habe bisher auch keine annähernd funktionierende Anleitung gefunden, um das Projekt hier vernünftig in FHEM einbinden zu können.
Soso. Meine Anleitung ist etwas kurz, aber korrekt. Und die Behauptung, sie würde nicht annähernd funktionieren und keine vernünftige Einbindung gestatten, ist reichlich missraten.
ZitatDen Entwicklern hier sollte doch daran gelegen sein...
Mich stört die Vokabel
sollte - auf so einen Führungskräftetonfall reagiere ich ziemlich allergisch.
LG
pah
Hallo Roland,
ich würde Dir mal das Projekt VWMON empfehlen, das ist außerhalb von FHEM und arbeitet mit einer Datenbank zum sammeln der Daten (wenn Du das denn so machen möchtest und es eine Datenbank sein soll... Generell geht das alles auch mit FHEM)
Findest Du z.B. hier:
http://baublog.ozerov.de/waermepumpe/vwmon-datenlogger-fuer-die-vaillant-waermepumpe/
https://github.com/john30/vwmon
Zu deinen Logs: Du scheinst CSVs einzubinden, bei denen dieselben Definitionen von Registern mehrmals vorkommen, also in der einen und in einer anderen, evtl. mal nach und nach die CSVs wieder raus nehmen, bis die Fehler aufhören. Wahrscheinlich eine Heizungs-Steuerung und noch eine Solarsteuerung (vielleicht muss John da mal drauf schauen) oder sowas...
Grüße
Christian
Zitat von: Prof. Dr. Peter Henning am 28 Dezember 2015, 21:14:41
@RainerS: Irgendwie scheinen wir aneinander vorbei zu reden.
Soso. Meine Anleitung ist etwas kurz, aber korrekt. Und die Behauptung, sie würde nicht annähernd funktionieren und keine vernünftige Einbindung gestatten, ist reichlich missraten.
Mich stört die Vokabel sollte - auf so einen Führungskräftetonfall reagiere ich ziemlich allergisch.
LG
pah
Ich fühle mich als Verfasser der Bitte um ein How-To jetzt schuldig, da ich nicht möchte, dass sich jetzt irgendjemand angegriffen fühlt, das WIKI ist super und eine sehr gute Basis für das ganze Projekt, jedoch ist es auf einem sehr hohen technischem Niveau. Es ist oft schwer für Laien und Newbies sofort das ganze Drumherum zu verstehen und richtig umzusetzen, ich bin fachkundig aber dennoch neu in der Materie und tu mir auch noch schwer, gebe aber zu, dass ich nicht die Zeit habe mich sehr intensiv damit zu beschäftigen.
Es sind oft die subtilen Dinge, die unklar sind, ob ein zusätzlicher Rechner (RPi) benötigt wird für die Heizung oder ob es vom FHEM RPi im Parallelbetrieb klappt etc.
Darum ist von vielen Newbies die erste Frage ob es ein Tutorial gibt, das alles Schritt für Schritt erklärt, bevor man stundenlang weiterliest. Dafür ist das Forum ja da, aber es ist jedem selbst überlassen ob und wem man wie hilft und was man antwortet. Jeder sieht das aus einer anderen Perspektive und keiner braucht in diesem Forum Angst davor haben angeschnauzt zu werden, und wenn es mal passiert ist das nicht böse gemeint und schön gar nicht persönlich.
@m8haben: Ich halte das mit der Datenbank für eine eher schlechte Idee - das sind nämlich sehr schnell ganze Megabytes an Daten, die niemand mehr ansieht. Solche Datenmassen müssen abstrahiert und auf wenige Werte heruntergekocht werden. Und zwar sowohl für den IT-Experten, als auch für denjenigen, der damit nicht so viele Erfahrungen hat (könnte man schon hier mit dem Begriff "Data Mining" bezeichnen).
Mein Tipp: eBus zum Laufen bringen. In FHEM einbinden. Dort die Daten definieren, die man haben möchte. Archivierung durch automatisch erzeugte Bilder (z.B. Tagesverlauf der Kurven Vorlauf/Rücklauf/sonstige Temperaturen). Ergänzen um sonstige Sensordaten (z.B. Wasserverbrauch, Gasverbrauch).
Ach ja, und für den Heizungsbauer habe ich noch ein Bonbon (zumindest mein Installateur war ganz heiß darauf...):
(http://sh_0514.png)
Erstellt mit FLOORPLAN, Live-Display auf einem an der Wand hängenden Tablet.
LG
pah
Zum Thema Langzeitauswertung:
Dafür nutze ich schon seit langem Munin (http://munin-monitoring.org (http://munin-monitoring.org)) und das ebusd Plugin dazu (https://github.com/john30/ebusd-munin (https://github.com/john30/ebusd-munin)).
Das liefert derzeit schöne Grafiken zu Temperatur, Druck, und Lesitung bzw. Ertrag und das in Tages-, Wochen-, Monats- und Jahresgrafik (alles basierend auf rrd). Siehe angehängte Screenshots.
Man braucht dazu im Wesentlichen munin, ebusd und apache.
Das schöne ist, dass man in den Graphen ganz leicht zoomen kann, wenn etwas besonderes zu sehen ist.
Das Plugin könnte man auch noch ausbauen, denn es wirft derzeit viele Temperaturen in eine Grafik, die man evtl. lieber getrennt sehen möchte.
Zitat von: RainerS am 28 Dezember 2015, 14:45:49
Den Entwicklern hier sollte doch daran gelegen sein, die csv-Dateien für viele unterschiedliche Systeme aufarbeiten zu können. Das geht doch eigentlich nur, wenn
viele ein funktionierendes System haben und so zusätzlich Unterstützung leisten können ...
Mit solchen Äußerungen macht man sich halt nicht unbedingt beliebt.
Also ich als Entwickler bin sehr damit beschäftigt, Features in ebusd einzubauen, die Dokumentation aktuell zu halten, zu testen, Leuten mit CSV zu helfen, Plugins zu schreiben, Foren lesen, und und und. Ich weiß nicht, wie viele Wochenende ich inzwischen komplett an ebusd "vergeuded" habe, aber es waren viele, fast alle in diesem Herbst wenn ich mich recht entsinne.
Da enttäuscht so eine vorwurfsvolle Message schon sehr und man möchte gern mal alles einfach hinschmeißen.
Zum Glück weiß ich, dass es genügend andere Leute gibt, die eine bessere Einstellung haben.
Zitat von: m8haben am 28 Dezember 2015, 19:55:20
Was aber ein scan oder auch andere Sachen machen verstehe ich nicht.
Ein Scan fragt alle Geräte nach Ihrer Identifikation ab. Somit kann man rausfinden, welche Devices am Bus hängen.
Bei Dir z.B. PMS, PMW, BAI, UI, SOLSY. Zusätzlich liefert der Scan auch die Software und Hardware Version ab, was Auffschluss darüber gibt, welchen Nachrichten das Gerät empfängt und sendet.
Darauf basiert dann die Auswahl der richtigen CSV Dateien.
Die nächste große Version von ebusd (2.0) steht schon in den Startlöchern. Es gibt ja schon seit geraumer Zeit eine preview dazu.
Mit dieser Version kann ebusd die CSVs selbständig aus dem Konfigurationsverzeichnis auswählen. Eben genau abhängig von den Scan Ergebnissen.
Dazu benötigt man dann die Startoption "--scanconfig" (siehe https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options)) und nimmt bspw. https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de) also Basis für die Konfiguration.
Zitat von: m8haben am 28 Dezember 2015, 19:55:20
Mein Ziel ist es die Daten die ich lesen kann in eine Datenbank abzulegen und auszuwerten. Habe aber keine Ahnung wie das geht.
Wurde oben schon beantwortet.
Zitat von: m8haben am 28 Dezember 2015, 19:55:20
Auch habe ich viele Meldungen "unknown MS cmd" . Ich denke das liegt an den .csv Dateien die ich im etc/ebusd Verzeichnis haben muss.
Richtig. Es wurden auch noch nicht alle Nachrichten entschlüsselt, so dass das ganz normal ist.
Zitat von: m8haben am 28 Dezember 2015, 19:55:20
Mein Problem ist es, wie kann ich die Daten auslesen und so speichern, dass ich sie auswerten kann. Also Datenbank!
Siehe mein Beitrag von 8:34.
vwmon geht natürlich auch. Ich persönlich nutze es gar nicht, weil mir die Visualisierung mit Munin viel schneller Auskunft gibt, ob ein Bild schief hängt :-)
Hallo, kann ich an meine Junkers Therme diesen eBus nutzen? Ich habe eine ZWR 18-7 KE. Laut Anleitung hat er ein Heatronic 3 Bus und ein Anschluss: Klemme 1-2-4.
Gesendet von iPhone mit Tapatalk
Heatronic 3 Interface siehe hier:
http://forum.fhem.de/index.php?topic=24675.0
LG
pah
Was ich bei dem Heatronic Module noch nicht weiß, ist ob dieser auf dem Bus Schreiben kann. Da ich den Raumregler gegen FHEM tauschen möchte. Danke
Gesendet von iPhone mit Tapatalk
Zitat von: john30 am 29 Dezember 2015, 08:41:48
Ich weiß nicht, wie viele Wochenende ich inzwischen komplett an ebusd "vergeuded" habe,
...die Frage kann ich Dir ganz einfach beantworten: KEIN EINZIGES ! Denn, wenn Du dir nicht so viel Mühe gegeben hättest, würden wir alle heute immer noch in den Keller rennen um zu schauen, was denn da los ist, deshalb ist die Zeit nicht "vergeudet", für uns war das sehr gut investierte Zeit ! :D
Zitat
Da enttäuscht so eine vorwurfsvolle Message schon sehr und man möchte gern mal alles einfach hinschmeißen.
Mach das bloss nicht ! :)
Grüße
Christian
@cs-online: So, und wenn Du jetzt noch das unsinnige Geschwätz zurücknimmst, dass man mit meinem Beruf so reagieren müsse, stufe ich Dich wieder als Mensch ein.
pah
Zitat von: Prof. Dr. Peter Henning am 29 Dezember 2015, 10:20:43
@cs-online: So, und wenn Du jetzt noch das unsinnige Geschwätz zurücknimmst, dass man mit meinem Beruf so reagieren müsse, stufe ich Dich wieder als Mensch ein.
pah
Lach, das ist lieb von Dir :D
Es ist doch so, je tiefer man in einer Materie drin steckt, umso trivialer kommt einem das doch vor, was für andere einfach nicht zu begreifen ist. Geht mir in meinem Fachgebiet doch auch so.
@ Alle: das ist natürlich nicht böse von mir gemeint gewesen, mit dem Beruf unseres lieben PAHs, ich schätze ihn und seine Arbeit sehr !!!
Lieben Gruß
Christian
OK, Einstufung als Mensch bestätigt 8)
LG
pah
Juchu, Tag ist gerettet ;D
@John: Bei mir läuft ja noch EBUSD 1.1.0, das läuft super stabil und ich bin eigentlich ja super zufrieden und bislang bin ich der Devise "never touch a running System" gefolgt, aber ich bin neugierig geworden auf die 2.0.
Frage: sind die einzelnen "Befehle" in den CSVs so geblieben, oder muss ich in meinen Abfragefunktionen größere Änderungen durchführen ? Und kann ich beide Versionen parallel installieren und dann jeweils über den Startaufruf selektieren ? Ich würde das erstmal auf einem Testsystem (Clone meines Produktivsystems) ziehen.
Grüße
Christian
Zitat von: john30 am 29 Dezember 2015, 08:57:29
Ein Scan fragt alle Geräte nach Ihrer Identifikation ab. Somit kann man rausfinden, welche Devices am Bus hängen.
Bei Dir z.B. PMS, PMW, BAI, UI, SOLSY. Zusätzlich liefert der Scan auch die Software und Hardware Version ab, was Auffschluss darüber gibt, welchen Nachrichten das Gerät empfängt und sendet.
Darauf basiert dann die Auswahl der richtigen CSV Dateien.
Die nächste große Version von ebusd (2.0) steht schon in den Startlöchern. Es gibt ja schon seit geraumer Zeit eine preview dazu.
Mit dieser Version kann ebusd die CSVs selbständig aus dem Konfigurationsverzeichnis auswählen. Eben genau abhängig von den Scan Ergebnissen.
Dazu benötigt man dann die Startoption "--scanconfig" (siehe https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options)) und nimmt bspw. https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de) also Basis für die Konfiguration.
Wurde oben schon beantwortet.
Richtig. Es wurden auch noch nicht alle Nachrichten entschlüsselt, so dass das ganz normal ist.
Siehe mein Beitrag von 8:34.
vwmon geht natürlich auch. Ich persönlich nutze es gar nicht, weil mir die Visualisierung mit Munin viel schneller Auskunft gibt, ob ein Bild schief hängt :-)
Hallo John,
meine Heizungsanlage besteht aus:
VRS 620/3
ecoVIT VKK226
VPM S 20
VPM W
AllStore 800/2
Heizkörper alles Radiatoren gesteuert über Rohrgruppe mit Mischer
Irgendwie habe ich es geschafft ebusd zu installieren und es läuft auch soweit. Das mit den csv´en denke ich auch jetzt etwas mehr verstanden zu haben. Sehe ich es richtig, dass ich jetzt die csv´en immer mehr mit # ausdünne, bis ich keine Fehlermeldungen mehr bekomme?
Das mit der Startoption --scanconfig verstehe ich nicht. Ich habe auch mal alle csv´en aus deinem Repository in das ebusd Verzeichniss gepackt, was dann aber ein riesen Chaos beim Starten von ebusd gebracht hat. Fehlermeldungen ohne ende, und kaum Daten die ich interpretieren konnte. Jetzt habe ich die csv´en etwas abgespeckt und sehe Daten die ich verstehe. Mit telnet einzeln abgefragt, meine ich auch fast immer das richtige lesen zu können. Jetzt geht es um das Auswerten bzw. grafische Darstellung.
vwmon habe ich noch nie zum Laufen gebracht. Alle schreiben es ist einfach so vorzugehen wie auf der WEB-Seite beschrieben, ich schaffe es nicht. Vielleicht zu banal. Lach!! Eben nichts für mich. Liegt das Problem in der Userverwaltung? Macht es einen Unterschied ob ich mich als root oder als user "pi" anmelde?
Noch eine absolute Anfängerfrage. In den csv´en sind in den Zeilen mehr oder weniger viele Kommas vorhanden und an verschiedenen Stellen. Wie muss ich das verstehen? Ich würde gerne die ganzen csv´en abstrippen um nur die Zeilen zu haben deren Werte ich auslesen bzw.verwerten kann und möchte.
Noch was. Schreiben habe ich mich bis jetzt noch nicht getraut, aber die eine oder andere Sache würde ich gerne auch mal im Betrieb ändern. z.B. In unserem Haus betreiben wir einen Kaminofen, welcher die Hauptheizung fast übernimmt. Nur die Räume die zu weit entfernt sind werden mit der Gasheizung geheizt. Den Kessel habe ich also auf 6Kw begrenzt. Ich möchte aber remote in der Lage sein wenn ich sehe, dass die 6Kw nicht mehr ausreichen diese Begrenzung anzuheben. Geht das?
So erstmal genug Fragen, damit ich auch die Antworten verstehe und verarbeiten kann.
Vielen Dank für alles.
VG
Roland
@Roland:
Zitat
Ich möchte aber remote in der Lage sein wenn ich sehe, dass die 6Kw nicht mehr ausreichen diese Begrenzung anzuheben. Geht das?
Jawoll, das geht, mache ich bei mir auch, habe aber festgestellt, daß die Therme da nicht immer direkt drauf reagiert und eine "Denkpause", die mitunter einen halben Tag dauerte, eingelegt hat. Wenn ich das an der Therme einstelle, wird es gleich übernommen. Den Befehl dazu nimmst Du aus der CSV (bei mir die zur Therme gehörende, "PartloadHcKW" - Parameter auf D.0).
Die CSVs brauchst Du nicht auf "das Nötigste" absttrippen, weil die sind sozusagen nur die "Übersetzung" dessen, was der Ebus ausgibt in das, was man lesen können will. Nur doppelte Einträge, also in zwei oder mehr CSVs vorkommende Befehle, die dann also nicht mehr eindeutig sind, solltest Du bereinigen, damit EBUSD nicht durcheinander kommt und Fehlermeldungen gibt.
Grüße
Christian
Hallo Christian,
das lese ich:
r PartloadHcKW
104
vrs620 PartloadHcKW = 104
BC DateTimeBC = 12:45:03;29.12.2015
BC DateTimeBC2 = 12:45:03;29.12.2015
bei eingestellten 6 Kw
wie sieht der Befehl für das Schreiben z.B. für 10 Kw aus?
VG
Roland
Hi John,
Neues zum Thema D.29 von mir:
Bei 0,9m³/h (die Einheit gibt die Therme auf dem Display mit aus) kommt (schwankend um) 021b06 als Antwort. Was mir aufgefallen ist, es fängt immer mit 0 an und endet immer mit 6. Wenn ich also dazwischen die 0x 21b0 nehme, dann sind das 8624 dez. Durch 10000 geteilt gibt das 0,8624 oder gerundet 0,9... hmmm.... wenn die Therme aber z.B. 1,02 anzeigt, komme ich mit der Umrechnung auf ca. 1,1 , was mir ein wenig stark abweichend vorkommt...
Es bleibt spannend, werde bei Gelegenheit mal eine Reihe mit verschiedenen Pumpenstufen aufnehmen, vielleicht bringt das etwas Klarheit
Grüße
Christian
Hi Roland,
das irritiert mich etwas, bei mir wird ein Dezimalwert, der tatsächlich der Leistung entspricht, ausgegeben und ich kann den dann mit "w bai#install PartloadHcKW 10" die Leistung auf 10KW setzen.
Liest Du mit EBUSCTL aus oder über Terminal ?
Grüße
Christian
Zitat von: cs-online am 29 Dezember 2015, 12:57:13
Hi Roland,
das irritiert mich etwas, bei mir wird ein Dezimalwert, der tatsächlich der Leistung entspricht, ausgegeben und ich kann den dann mit "w bai#install PartloadHcKW 10" die Leistung auf 10KW setzen.
Liest Du mit EBUSCTL aus oder über Terminal ?
Grüße
Christian
Hallo Christian,
ich mache das alles mit einem Terminalfenster und telnet auf einem Windows PC. Mein Raspi ist im Keller und ich gehe mit ssh über putty rein.
Gruß
Roland
P.S. Mache ich grundsätzlich was falsch?
Hi Roland:
die vrs620 ist eine Steuerung mit Solarunterstützung... Vermute der Parameter, den Du da ausliest ist nicht die Teillast der Therme. Solltest mal mit "find part" schauen, was EBUSCTL da ausgibt, evtl. gibt's es mehr als ein Partloadhckw. Du müßtest mal in die CSV zur ecoVIT VKK226 (das ist doch die Therme oder ? Ist die CSV auch die BAI ?) schauen, evtl. heisst der Parameter bei Dir auch geringfügig anders.
Ich habe bei meinem Raspi einen VNC-Server installiert, dann auf dem Windows-PC einen VNC-Viewer, damit ist das, als ob Du direkt am Raspi sitzt, dann kann man dort direkt den EBUSCTL laufen lassen... Aber prinzipiell müßte auch über Putty das gleiche bei raus kommen.
Grüße
Christian
Hallo Christian,
ecovit exklusiv ist ein Kessel mit modulierenden Brenner von ca. 6 bis 22kw.
Ein weiteren Parameter mit partloadhckw finde ich nicht.
Gruß
Roland
Nachdem ich meinBuchprojekt endlich abgeschlossen habe, werde ich meinen EBUS auch mal wieder angehen.
Vor einem Jahr habe ich mir die EBUS-Dokumentation von Siegmund Schreiber vorgenommen und diverse Änderungen (Verbesserungen, hoffe ich...) darin vorgenommen. Ich hänge den letzten Stand mal hier an.
LG
pah
Ich habe nun wie versprochen begonnen alles feinstens zu dokumentieren und möchte zu allererst mit dem korrekten Verkabeln an der Therme beginnen. Es ist eigentlich recht trivial und unkompliziert, man kann es auch sehr gut so machen wie in diesem Video: https://www.youtube.com/watch?v=TnhT8KUCA_g
Kurz und bündig:
Benötigtes Werkzeug und Material:
- Stanley-Messer oder scharfes Küchenmesser
- Schlitz-Schraubendreher mittelgroß
- 1m-2m 2-poliges Kabel 0,2 mm - 1,5 mm
- Therme ausschalten und abstecken ;)
- Mittig sitzende Schraube unter der Therme lösen
- Thermendeckel abnehmen
- Elektronikpanel um 90° nach vorne klappen
- Kunststoffklemmen lösen und somit Elektronik freilegen
- Rote Buchse mit Aufschrift BUS herausziehen
- Kabeldurchführungen bis nach draußen ausschneiden und 2-polige Leitung bis zur BUS-Buchse legen
- Zugentlastungen festschrauben, Klemme anschließen und wieder hineinstecken
- Leitungen auf der Außenseite isolieren, um einen Kurzschluss der Busleitungen zu vermeiden
- In umgekehrter Reihenfolge wieder zusammenbauen
Anbei noch einige Fotos als ZIP
Gutes Gelingen
Zitat von: ahollik am 26 Dezember 2015, 01:27:25
hat mal Jemand von Euch eBusd auf Android kompiliert/installiert? Kennt Ihr vielleicht eine Stelle, woher ich ein Install-Paket auf Android herunterladen kann?
bis dato gibt es noch kein Build für Android und nachdem Du bis jetzt der einzige User auf Android bist, wird das so schnell auch nicht in reguläre Releases mit aufgenommen werden.
Was nutzt Du denn für eine Plattform?
Zitat von: cs-online am 29 Dezember 2015, 10:09:06
...die Frage kann ich Dir ganz einfach beantworten: KEIN EINZIGES ! Denn, wenn Du dir nicht so viel Mühe gegeben hättest, würden wir alle heute immer noch in den Keller rennen um zu schauen, was denn da los ist, deshalb ist die Zeit nicht "vergeudet", für uns war das sehr gut investierte Zeit ! :D
Danke für die Blumen! :-)
Zitat von: cs-online am 29 Dezember 2015, 10:55:43
Frage: sind die einzelnen "Befehle" in den CSVs so geblieben, oder muss ich in meinen Abfragefunktionen größere Änderungen durchführen ? Und kann ich beide Versionen parallel installieren und dann jeweils über den Startaufruf selektieren ? Ich würde das erstmal auf einem Testsystem (Clone meines Produktivsystems) ziehen.
Mit Version 2.0 gibt es ein paar neue Features, die die CSVs betreffen:
- Default Circuit Name: wird aus dem Dateinamen gezogen
- "--scanconfig" Option: zur automatischen Selektion der richtigen CSVs. Damit auch Einschränkung einer CSV Datei auf bestimmte Hardware- und/oder Software-Version eines Geräts.
- Templates Vererbung: die _templates.csv im Config Verzeichnis gelten global, die in Unterverzeichnissen jeweils nur für das Verzeichnis.
- Bedingte Messages: da es für viele Geräte Nachrichten gibt, die bspw. nur in einer speziellen Software Version des Geräts verfügbar sind, gibt es Bedingungen auf Message Ebene, d.h. eine so deklarierte Message ist nur gültig, wenn die Bedingungen erfüllt sind.
- Verkettete Messages (noch im Beta Stadium)
Die Messages selbst sind im Wesentlichen identisch, aber mit Bedingungen kommt ebusd 1.x z.B. nicht zurecht und gibt dann entsprechende Fehlermeldungen aus.
Meine Empfehlung:
- ebusd 1.x zusammen mit CSVs aus ebusd-1.x.x verwenden
- ebusd 2.x mit CSVs aus ebusd-2.x.x und mit Startoption "--scanconfig" verwenden
Zitat von: m8haben am 29 Dezember 2015, 11:37:01
Irgendwie habe ich es geschafft ebusd zu installieren und es läuft auch soweit. Das mit den csv´en denke ich auch jetzt etwas mehr verstanden zu haben. Sehe ich es richtig, dass ich jetzt die csv´en immer mehr mit # ausdünne, bis ich keine Fehlermeldungen mehr bekomme?
Nein, so ist das nicht gedacht. Siehe auch mein Beitrag von vorhin.
Grundsätzlich muss man hier zwischen ebusd 1.x und 2.x unterscheiden. Wenn Du 2.x nutzt, kannst Du auch die ebusd-2.x.x CSVs verwenden, andernfalls unbedingt die ebusd-1.x.x nehmen.
Wenn Du ebusd 2.x nutzt, dann empfehle ich die Kommandozeilenoption "--scanconfig" an ebusd zu übergeben (bei Debian z.b. in /etc/default/ebusd an den Wert von "EBUSD_OPTS" anhängen). Damit sucht sich ebusd dann die passenden CSVs selbst aus.
Wenn Du das nicht möchtest, dann solltest Du nach dem alten Schema verfahren und zunächst mit einem leeren Verzeichnis /etc/ebusd beginnen (bzw. mit dem was nach der Installation da schon drin liegt).
Dann scannst Du Deinen Bus mit "ebusctl scan", wartest ne halbe Minute und lässt Dir dann das Ergebnis ausgeben mit "ebusctl scan result". Dann siehst Du, welche Geräte am bus hängen und mit welcher ID sie sich präsentieren. Diese nimmst Du dann her, um passende CSVs rauszusuchen und in das /etc/ebusd Verzeichnis zu kopieren. Nach einem "ebusctl reload" werden diese dann eingelesen und können verwendet werden.
Zitat von: cs-online am 29 Dezember 2015, 12:50:05
Bei 0,9m³/h (die Einheit gibt die Therme auf dem Display mit aus) kommt (schwankend um) 021b06 als Antwort. Was mir aufgefallen ist, es fängt immer mit 0 an und endet immer mit 6. Wenn ich also dazwischen die 0x 21b0 nehme, dann sind das 8624 dez. Durch 10000 geteilt gibt das 0,8624 oder gerundet 0,9... hmmm.... wenn die Therme aber z.B. 1,02 anzeigt, komme ich mit der Umrechnung auf ca. 1,1 , was mir ein wenig stark abweichend vorkommt...
Bitte poste doch mal eine Liste von abgelesenen Werten und das zugehörige Hex Ergebnis dazu, sonst kommen wir hier nicht weiter.
Nochmal zur Hex Antwort: 021b06 setzt sich zusammen aus einem Längen Byte (02=2 bytes) und einem darauf folgenden Wert. Die zwei Bytes des Werts sind bei Vaillant üblicherweise mit Low Byte zuerst kodiert, also entspricht 02b106 dem Wert 0x06b1 oder dezimal 1713.
Zitat von: RainerS am 29 Dezember 2015, 21:15:45
Die Hauptakteure im Bereich eBus haben doch bestimmt ein großes Interesse daran (was ich den Entwicklern auch unterstelle), die csv-Dateien weiter zu vervollständigen.
Du solltest nicht vergessen, dass das hier alles ein Freizeit Projekt ist ohne kommerziellen Hintergrund. Weshalb also sollte sich ein Entwickler freiwillig mit tausenden von CSV Definitionen und hunderten von Anlagenvarianten quälen?
"Entwickler" bezieht sich auf Software und nicht auf CSVs...
Zitat von: RainerS am 29 Dezember 2015, 21:15:45
Das geht aber nur, wenn auch der Nicht-Entwickler Zugang zur Heizung erlagen kann, was aber leider nur mit einer verständlichen Anleitung möglich ist.
Mein Tipp: Dokumentation lesen unter https://github.com/john30/ebusd/wiki/4.-Configuration (https://github.com/john30/ebusd/wiki/4.-Configuration)
Zitat von: RainerS am 29 Dezember 2015, 21:15:45
Wenn es viele User schaffen, das System in Betrieb zunehmen, desto eher können auch die Entwickler von neuen Heizungsanlagen-Regler-Kombinationen profitieren
Was genau wäre denn der "Profit" dabei für einen Entwickler???
Zitat von: ReinhardDas Logfile solltest du in /etc/logrotate.d/ebusd konfigurieren. Ich habe es so eingestellt. Die Datei editieren und diesen Eintrag hinzufügen.
Code: [Auswählen]
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
D.h: alle 7 Tage wird überschrieben, die Files werden dann komprimiert (außer dem aktuellen File) und das Ganze wird täglich ausgeführt.
Ist die log-Datei nach einer Inbetriebnahme zwingend notwendig ?
Ein loggen mit dem Parameter
Zitatlog level LEVEL
The possible LEVEL values are (similar to syslog):
error: only error messages
würde ausreichen ?
Hallo Rainer,
da ein Log in der Regel nur zur Fehlersuche benötigt wird, ist es nicht zwingend notwendig, das kommt darauf an, welche Informationen für Dich wichtig sind.
Grüße Christian
Ach ja, und für den Heizungsbauer habe ich noch ein Bonbon (zumindest mein Installateur war ganz heiß darauf...):
(http://sh_0514.png)
Erstellt mit FLOORPLAN, Live-Display auf einem an der Wand hängenden Tablet.
LG
pah
[/quote]
Moin pah,
du machst mich ganz neidisch!
Genauso stelle ich mir dann die Darstellung von Livedaten vor. Ich denke den ebus habe ich jetzt soweit, dass ich die Daten die ich sehen will auslesen kann. Zumindest direkt im Telnetfenster. Meinst du man kann einem IT-Neandertaler die Grundlagen beibringen so was mit FLOORPLAN zu machen. Da ist alles drauf was ich gerne auch Live sehen würde. Zu der Auswertung: Ich möchte nur manchmal sehen und verstehen welche Werte warum so geregelt werden. z.B. ich habe an meinem Speicher eine Wasserstation (VPM W) von Vaillant an der ich eine Brauchwassertemperatur von 53° C eingestellt habe. Meine Frau will das Wasser so heiß haben, weil sie gerne fettiges gut vorspülen möchte. Der Kessel bzw. die Steuerung VRS 620 heizt jedesmal wenn die Programmzeit für die Warmwassererzeugung ansteht den Pufferspeicher auf 74° C und das im gesamten oberen Drittel auf. Ich versteh aber nicht warum. Solche Aufzeichnungen würde ich gerne mal Vaillant präsentieren und um eine Antwort bitten. Ich finde es nicht notwendig den Speicher bis auf 74°C zu heizen um maximal 53°C zu bekommen. Habe mal von einem Bekannten eine HomeMatic für ein paar Tage gehabt und die Speichertemperatur aufgezeichnet. (siehe Anhang)
Gruß Roland
Hallo Roland,
ich habe mal zwei Screenshots angehängt, wie ich das angelegt habe:
Der eine zeigt in den Gruppe "Aktuelle Werte" mit Dummys angelegt die Werte, die von der Heizung kommen, in der Gruppen "Befehle" habe ich dann das drin, was ich einstellen möchte, also z.B. eine Speicherladung mit 45°C für Duschen oder mit 60°C für eine Wannenfüllung oder auch von Sommer- auf Winterschaltung umstellen.
Der zweite zeigt einen Teil der Diagramme, die mit den geloggten Daten erzeugt werden.
Grüße Christian
Um Himmels willen, warum denn dummies ?
Per Zugang mit ECMD kann man sich doch genau die devices zusammenbauen, die man braucht. Das ist eine Frage der classdef, die eben das ECMD-Device aus der telnet-Abfrage des ebusd mit Daten füllt. Ich habe genau drei solche Devices: Heizungsanlage global, Warmwasserberitung und Solarthermie.
Zusätzlich habe ich rund um die Heizung aber noch ein halbes Dutzend andere Sensoren - zur Temperaturmessung etc.
Um das nun alles für den Floorplan zu vereinzeln, werden mehrere readingsproxy benötigt..
Also erster Schritt: ECMD zum Laufen bekommen. Irgendwann einmal sollte das viel einfacher mit GAEBUS gehen, ist aber im Moment noch nicht ganz so reif.
LG
pah
Hallo pah,
ich habe im Hintergrund eine Klasse "Heizungsfunktionen" laufen, in der Funktionen (z.B. Druck als Anlagendruck) aus dem ECMD die Werte aus dem EBUSD auslesen, also je Wert eine Funktion. Hab das in den ersten Gehversuchen analog zu Deinem Post angelegt.
Mit
my $Druck=ReadingsVal("Heizungsfunktionen","Druck","0");;\
fhem("set Heizungsdruck $Druck");;;;\
in einem Notify, das die Daten per Knopfdruck oder über einen Timer aktualisieren soll, werden die Daten (in diesem Fall der Anlagendruck) dann in die Dummys geschrieben. Dummys finde ich in der Darstellung so als Liste gar nicht schlecht. )Ist aber ein wenig umständlich, wenns da was leichter zu handlen gäbe, würde ich mich auch über Anregungen freuen.
Grüße
Christian
PAH, Du bist ein Genie !
Mit dem "readingsProxy" kann ich das ja viiiiiiel einfacher machen, da brauche ich also nur noch die Klasse (z.B. "Heizungsfunktionen") mit den Funktionen zum Auslesen aus EBUSD und das "readingsProxy" aktualisiert dann immer aus dem Reading (also den einzelnen Funktionswerten) dann die Anzeige ;D
Seeeehr cooool !
Muss ich denn die Funktionen dann alle einzeln einmal aufrufen oder kann ich die ganze Klasse auf einmal aktualisieren ?
Grüße
Christian
Anbei (ohne Garantie, Support und Erläuterung ...) eine meiner Klassendefinitionen für ECMD, die Datei mit den Perl-Funktionen für die Heizung und die FHEM-Konfigurationsdatei.
LG
pah
r;w,,HwcTempDesired,gewünschte Temperatur Warmwasserkreis,,,,"4400",,,temp1,,,setpoint of domestic hot water circuit,,,
r,,HwcActualTempDesired,Aktuelle Temperatur Soll Warmwasserkreis,,,,"8600",,,temp1,,,current domestic hot water setpoint,,,
Die Daten sind aus der Vaillant "470.csv". Kennt jemand den Unterschied zwischen der "gewünschten" Temperatur und der "Soll"-Temperatur ?
Zitat von: john30 am 30 Dezember 2015, 08:00:51
bis dato gibt es noch kein Build für Android und nachdem Du bis jetzt der einzige User auf Android bist, wird das so schnell auch nicht in reguläre Releases mit aufgenommen werden.
Was nutzt Du denn für eine Plattform?
Hallo John30, und danke für deine Antwort! Also, ich bin gerade dran, einen Android-Tablet (nämlich einen Acer A1-810 mit Android 4.4.2 drauf) in die Wand meines Wohnzimmers einzubauen, um damit meinen Fhem-Server über TabletUI/WebViewControl steuern zu können. Und ich wollte diesen Tablet zwar genau auf der Stelle platzieren, wo gerade mein alter Heizungs-Thermostat hängt, und dachte mir dabei, ich kann dort einen RasPi ersparen, wenn bereits ein leistungsstarker "Rechner" auf der Stelle vorhanden wird.
Ich habe das Gerät schon gerootet, und kämpfe gerade mit dem autogen, bin aber leider kein Linux-guru, also, ist mir nicht einfach. Vielleicht greife ich dann doch nach einen RPi..
Hallo und ein frohes neues noch an alle,
ich bin auch ein Neuling und habe mal eine kurze Frage:
Ich habe ebusd 2.0 auf einen Raspi installiert und dieser hängt mit dem USB Modul von eservice-online an meinem Vailland Bus.
Beim letzten Befehl der Installation bekomme ich folgende Meldung:
sudo update-rc.d ebusd defaults
update-rc.d: error: initscript does not exist: etc/init.d/ebusd
Ich habe nachgeschaut und es existiert tatsächlich nicht.
Wie kann ich dieses Script bekommen bzw. nachinstallieren?
Gruß Frank
Ich rate dringend davon ab, ein webviewcontrol auf derselben Kiste laufen zu lassen, die den eBus bedient. Darüber hinaus hat ein Tablet in der Regel einen USB-Client und keinen USB-Host - kann also gar nicht mit dem eBus-Interface sprechen. Wenn man wenig Ahnung von Linux hat, sollte man solche Klimmzüge eher vermeiden.
LG
pah
Hallo zusammen,
ein frohes und gesundes neues Jahr wünsche ich Euch!
Über die Feiertage hat sich wohl der Akku meines Funk-Aussensensors VR 21 verabschiedet. Der Effekt ist, dass die letzte gemessene Aussentemperatur nun zur Regelung herangezogen wird (zur Zeit ein paar Grad zu hoch). Die Reparatur dauert noch ein paar Tage. Nun dachte ich mir, dass man den Wert evtl. auch anhand anderer in FHEM verfügbarer Aussensensoren schreiben könnte.
Im BAI00 kann ich die Aussentemperatur mit dem Register 7600 auslesen. In der Calormatic VC470F mit dem Register 6200. Letzteres habe ich versucht zu beschreiben, allerdings ohne Erfolg (time out). Hat dies schon einmal jemand erfolgreich probiert? Spricht etwas dagegen (bei vollständig deaktiviertem Aussensensor)?
schöne Grüße
Jo
Hallo Jojo,
bei der 470 gibt es die Möglichkeit, den als Raumregelung (also abhängig von der Raumtemperatur und nicht abhängig von der Aussentemperatur) laufen zu lassen, damit kannst Du (je nachdem in welchem Raum die hängt) die Zeit bis zur Reparatur überbrücken. Ansonsten, wenn der letzte Aussenwert noch drin ist, kannst Du einen Offset auf den Aussenfühlerwert legen, dann meint die Regelung, es sei kälter. Dann gibt es auch noch die Möglichkeit, über die Wunschtemperatur und die Heizkurve die Vorlauftemperaturen hoch zu bekommen. Alles nur Notlösungen, bis der Aussensensor wieder läuft...
Grüße
Christian
Zitat von: cs-online am 03 Januar 2016, 11:29:01
Hallo Jojo,
bei der 470 gibt es die Möglichkeit, den als Raumregelung (also abhängig von der Raumtemperatur und nicht abhängig von der Aussentemperatur) laufen zu lassen, damit kannst Du (je nachdem in welchem Raum die hängt) die Zeit bis zur Reparatur überbrücken. Ansonsten, wenn der letzte Aussenwert noch drin ist, kannst Du einen Offset auf den Aussenfühlerwert legen, dann meint die Regelung, es sei kälter. Dann gibt es auch noch die Möglichkeit, über die Wunschtemperatur und die Heizkurve die Vorlauftemperaturen hoch zu bekommen. Alles nur Notlösungen, bis der Aussensensor wieder läuft...
Grüße
Christian
Hallo Christian,
danke, diese Optionen sind mir schon bekannt. Es ist nicht so, dass ich friere ;) Aufgrund der von mir gewählten Heizkurve hat die Aussentemperatur ohnehin nur einen relativ geringen Einfluss auf die Regelung. Ich dachte nur, dass es eventuell relativ problemlos möglich sei, diesen Sensor durch ohnehin vorhandene Alternativen zu "ersetzen" (zumindest zeitweise).
schöne Grüße
Jo
Hallo!
Ich würde gerne die Zirkulationspumpe meiner Vaillant Anlage auf Knopfdruck für 2-3 Minuten auslösen, um auch ausserhalb der programmierten Zeiten
mal kurz warmes Wasser zu haben.
Ich hatte gedacht dies durch Auslösen einer Speicherladung zu lösen, wenn ich an der 470 diese Option auswähle springt die Pumpe an.
Nun habe ich folgendes Problem:
HwcOPMode (Modus WW-Kreis) steht normalerweise auf 2 (Auto), wenn man eine Speicherladung an der 470er anwählt springt das Reading auf 6.
Wenn ich den Parameter per ebus von 2 auf 6 setze ebusctl w -c 470#install HwcOPMode 6, dann zeigt das Display der 470 kurz die Speicherladung an und geht dann wieder aus.
Umgekehrt genauso, wenn die Speicherladung per 470 aktiv ist und ich setze HwcOPMode 2 geht im Display der 470 die Speicherladung aus
und nach weniger als 1 Sekunde wieder an.
Ich vermute also ich setze den falschen Parameter, kann mir da jemand helfen?
Oder gibt es eine andere Möglichkeit die Zirkulationspumpe für 2-3 Minuten zu starten ohne gleich die Timer Programmierung zu ändern?
Ich hab mal mitgeloggt (ca. 10s nach Start Log hab ich die Speicherladung aktiviert, eine Minute später wieder deaktiviert)
2016-01-03 11:48:06.825 [main notice] ebusd 1.3.0 started
2016-01-03 11:48:07.022 [main notice] found messages: 384 (0 conditional on 0 conditions, 0 poll, 16 update)
2016-01-03 11:48:07.939 [bus notice] signal acquired
2016-01-03 11:48:07.969 [bus notice] new master 10
2016-01-03 11:48:07.969 [bus notice] new master 03
2016-01-03 11:48:07.969 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:48:11.559 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:48:13.557 [update notice] update myCustom1 Status11: valid;14;48;12;3;1;7;16;3.250
2016-01-03 11:48:13.816 [update notice] update myCustom Status02: auto;60;75.0;70;65.0
2016-01-03 11:48:17.578 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:48:21.638 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:48:33.329 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:48:33.595 [update notice] unknown MS cmd: 1008b5110100 / 0819031151040f0081
2016-01-03 11:48:33.866 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:48:34.085 [update notice] update broadcast outsidetemp QQ=10: 3.250
2016-01-03 11:48:34.341 [update notice] update myCustom Status02: auto;60;75.0;70;65.0
2016-01-03 11:48:37.456 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:48:41.432 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:48:43.513 [update notice] update myCustom1 Status11: valid;44;48;12;3;1;7;16;3.250
2016-01-03 11:48:47.538 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:48:51.599 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:48:53.567 [update notice] unknown MS cmd: 1008b5100305ff01 / 0101
2016-01-03 11:48:57.718 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:49:01.778 [update notice] update myCustom Status01: 49.5;39.0;3.250;44.5;53.5;on
2016-01-03 11:49:04.714 [update notice] update broadcast vdatetime QQ=10: 12:49:03;03.01.2016
2016-01-03 11:49:04.995 [update notice] unknown BC cmd: 10feb51603049002
2016-01-03 11:49:05.292 [update notice] update myCustom2 Pumpenstatus: off
2016-01-03 11:49:07.864 [update notice] update bc Mode QQ=10: standby
2016-01-03 11:49:08.678 [main notice] SIGINT received
2016-01-03 11:49:08.789 [main notice] ebusd stopped
Gruß
Sven
ZitatHwcOPMode (Modus WW-Kreis) steht normalerweise auf 2 (Auto), wenn man eine Speicherladung an der 470er anwählt springt das Reading auf 6.
Wenn ich den Parameter per ebus von 2 auf 6 setze
In meiner 15.470.csv steht allerdings nur was von lesen "r", und bei Dir ?
EDIT:
Ist hier ein Übertragungsfehler enthalten, da das Schreiben in der 430 erlaubt ist und in der 470 nicht ?
Oder hat das evt. mit der Anzahl der Parameter zu tun, welche bei der 470 umfangreicher sind ?
ebusd-2.x.x/
DE/15.430.csv
r;w,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,0=off;1=manual;2=auto,,operation mode of the domestic hot water circuit,,,ebusd-2.x.x/
DE/15.470.csv
r,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,,,"operation mode of the domestic hot water circuit set implicitly (0 = off, 1 = on, 2 = auto, 3 = auto sunday, 4 = party, 6 = one time tank loading, 7 = holiday)",,,ebusd-2.x.x/
EN/15.430.csv
r;w,,HwcOPMode,DHW_OPMode,,,,"4200",,,UCH,0=off;1=manual;2=auto,,operation mode of the domestic hot water circuit,,,ebusd-2.x.x/
EN/15.470.csv
r,,HwcOPMode,DHW_OPMode,,,,"4200",,,UCH,,,"operation mode of the domestic hot water circuit set implicitly (0 = off, 1 = on, 2 = auto, 3 = auto sunday, 4 = party, 6 = one time tank loading, 7 = holiday)",,,
Zitat von: ms_9 am 03 Januar 2016, 13:56:48
In meiner 15.470.csv steht allerdings nur was von lesen "r", und bei Dir ?
Ich hab das im csv von r auf r;wi geändert.
Bei mir läuft ebus v1.3. Die entsprechende Zeile in der 470.csv lautet
r;wi,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,,,"0 = off, 1 = on, 2 = auto, 3 = auto sunday, 4 = party, 6 = one time tank loading, 7 = holiday"Gruß
Sven
das kann ich bestätigen, das "HwcOPMode" läuft bei mir auch schon einige Monate stabil im r;wi, also auch schreibend. Super in Kombination mit dem Setzen des Sollwertes auf 45°C zum Duschen und 60°C für eine Wannenfüllung ;)
Allerdings: Mir ist auch aufgefallen, daß wenn ich dann gleich danach über EBUSD mit "r HwcOPMode" abfrage, dann steht da noch der alte Wert, vermutlich, weil der neue noch nicht wieder von der 470 gelesen wurde. Wenn ich dann aber (Tip von John) mit "r -f HwcOPMode" abfrage, dann kommt auch der gesetzte Wert zurück,
Grüße
Christian
@Jojo:
doch, das geht (aber nur) indirekt (also nicht, daß man die Solltemperatur für den Vorlauf in Abhängigkeit eines anderen Sensors direkt überschreiben würde), indem Du z.B. über ein Notify auf einen Sensorwert z.B. eines Funkaussenthermosensors, über den Du die Aussentemperatur abfragen würdest, die Wunschtempertur mit "w 470#install Hc1DayTemp " rauf oder runter korrigierst, damit zieht er dann gemäß der Heizkurven-45°-Verschiebung die Vorlaufsolltemperatur mit.
Alternativ mit einem Funksensor z.B. im Wohnzimmer schaffe ich es (allerdings aktuell noch mit von Hand angepasster Wunschtemperatur) in meinem Wohnzimmer die gewünschten 20°C zu erreichen,
Grüße
Christian
Zitat von: cs-online am 03 Januar 2016, 21:17:12
das kann ich bestätigen, das "HwcOPMode" läuft bei mir auch schon einige Monate stabil im r;wi, also auch schreibend. Super in Kombination mit dem Setzen des Sollwertes auf 45°C zum Duschen und 60°C für eine Wannenfüllung ;)
Allerdings: Mir ist auch aufgefallen, daß wenn ich dann gleich danach über EBUSD mit "r HwcOPMode" abfrage, dann steht da noch der alte Wert, vermutlich, weil der neue noch nicht wieder von der 470 gelesen wurde. Wenn ich dann aber (Tip von John) mit "r -f HwcOPMode" abfrage, dann kommt auch der gesetzte Wert zurück,
Ich hab noch ein bischen probiert, leider funktioniert das bei mir nicht, in der Kommandozeile kommt
pi@raspberrypi:~# ebusctl w -c 470#install HwcOPMode 6
done
pi@raspberrypi:~# ebusctl r -f -c 470 HwcOPMode
6
pi@raspberrypi:~# ebusctl r -f -c 470 HwcOPMode
2Ich hab die Befehle direkt hintereinander eingegeben, der HwcOPMode ist kurz 6 und wird dann wieder auf 2 gesetzt.
Hab den ebusd mal mit --lograwdata gestartet und die Befehle abgesetzt, Datei hängt an.
Wäre super wenn jemand von Euch Wissenden mal bei Gelegenheit drüber schauen könnte,
Danke und Gruß
Sven
Guten Morgen Zusammen,
ich hab heute nacht die 08.bai.HW7401.csv um ein paar Abfragen für das Solarsystem meiner Vaillant auroCOMPACT erweitert. Vielleicht kann es ja jemand brauchen:
# Solarsystem auroCOMPACT VSC S 126/3-C 180 H (d.93 Gerätekennung = 73)
# Softwareversion: 18.01 Softwareversion Al: 0174.05.18 Artikelnummer: 0010009351
*r,aur,,,,,"B509","0D",,,,,,,,,
r,,SpeicherbodenTemperatur_DK,d.42 Speicherbodentemperatur,,,,"0600",,,tempsensor,,,aktuelle Speicherbodentemperatur WW Speicher,,,
r,,WPPumpspeedSetpoint_DK,d.14 Pumpe Leistungsstufe,,,,"0A04",,,BCD,00=Auto;01=53%;02=60%;03=70%;04=80%;05=100%,,PWM-Leistungsstufe der Heizungspumpe,,,
r,,WPPwm_DK,d.15 Pumpendrehzahl Istwert in %,,,,"7300",,,percent0,,,Output of PWM pump,,,
r,,SolarRL_DK,d.39 Solarertragsensor,,,,"6800",,,tempsensor,,,Solarertragsensor Temperatursensor im Kollektorrücklauf und Fühlerstatus,,,
r,,SolarErtragkWh_DK,d.59 Solarertrag,,,,"7200",,,energy,,,berechneter gesamter Solarertrag,,,
r,,SolarKollektorTemperatur_DK,d.38 Kollektortemperatur,,,,"7800",,,tempsensor,,,Thermosolarkollektor-Temperatur und Fühlerstatus,,,
r,,SolarPumpePwm_DK,PWM-Solarpumpe,,,,"7D00",,,percent0,,,PWM-Leistungsstufe der Solarpumpe,,,
r,,SolarVolumenstrom_DK,d.57 Volumenstrom Solarpumpe,,,,"6A00",,,UCH,10,l/min,Volumenstrom Solarpumpe in Liter pro Minute,,,
Zum Testen nach dem Anfügen in der Konsole:
root@rasp-gi:~# ebusctl reload
done
root@rasp-gi:~# /etc/init.d/ebusd restart
[ ok ] Stopping ebusd: ebusd.
[ ok ] Starting ebusd: ebusd.
root@rasp-gi:~# ebusctl find DK
470 CalculatedKickStopTime = no data stored
aur SolarErtragkWh_DK = 8534
aur SolarKollektorTemperatur_DK = 4.44;ok
aur SolarPumpePwm_DK = 0
aur SolarRL_DK = 18.75;ok
aur SolarVolumenstrom_DK = 3.5
aur SpeicherbodenTemperatur_DK = 18.75;ok
aur WPPumpspeedSetpoint_DK = 53%
aur WPPwm_DK = 53
Gruß aus Lünen,
Andreas.
Hallo zentis666,
wenn Du an der Steuerung selber einstellst, dann bleibt die Steuerung im Display auch bei der Eingabe oder verschwindet das dann auch gleich wieder ?
Grüße
Christian
Hi Christian,
wenn ich an der 470 Steuerung schalte dann bleibt der Status wie eingestellt, das funktioniert also wie es soll.
Wenn ich per ebusd schalte dann schaltet er gleich (nach < 1 Sekunde) zurück auf den vorherigen Status (2 oder 6).
Deswegen hab ich vermutet, dass da noch irgendein anderer Parameter geändert werden muss der dann HwcOPMode verändert.
Was mir heute aufgefallen ist: wenn ich Hc1SFMode von 0 (auto) auf 2 (Ein Tag zu Hause) schalte, ändert sich HwcOPMode von 2 (auto) auf 3 (auto sunday).
Und im Hc1SFMode gibt es 9 = _SFLoadOnceDHW
Wenn ich den setzte springt er gleich wieder auf 0 um, und HwcOPMode auf 2.
Gruß
Sven
Hi Sven,
ich hab bei mir nochmal nachgesehen, ich habe in der 470er CSV (Ebus 1.1.0) doch nur r;w (statt wie geschrieben r;wi) ergänzt.
Im FHEM habe ich das als ECMD mit Namen "EBUS" angelegt. Wenn ich nun in der Befehlszeile im FHEM folgendes eingebe, dann schaltet sich die Speicherladung ein.
get EBUS raw 'w 470 hwcopmode 6'
Wird quittiert mit
EBUS raw => done
Das macht die Steuerung aber nur, wenn auch nachgeladen werden kann, d.h. Ist von Soll mindestens mit der Schalthysterese abweicht (7°C ?), also kalt genug ist, sonst geht das gleich wieder aus.
Auslesen dann testweise mit
get EBUS raw 'r -f hwcopmode'
ergibt
EBUS raw => 6
Grüße
Christian
Hallo,
hat sich erledigt.
Ich hatte alles im /home ausgecheckt
- habe die ebusd.debian nun nach /etc/init.d kopiert und es läuft
Gruß Frank
Zitat von: cs-online am 04 Januar 2016, 20:11:59
Hi Sven,
ich hab bei mir nochmal nachgesehen, ich habe in der 470er CSV (Ebus 1.1.0) doch nur r;w (statt wie geschrieben r;wi) ergänzt.
Im FHEM habe ich das als ECMD mit Namen "EBUS" angelegt. Wenn ich nun in der Befehlszeile im FHEM folgendes eingebe, dann schaltet sich die Speicherladung ein.
get EBUS raw 'w 470 hwcopmode 6'
Wird quittiert mit
EBUS raw => done
Das macht die Steuerung aber nur, wenn auch nachgeladen werden kann, d.h. Ist von Soll mindestens mit der Schalthysterese abweicht (7°C ?), also kalt genug ist, sonst geht das gleich wieder aus.
Auslesen dann testweise mit
get EBUS raw 'r -f hwcopmode'
ergibt
EBUS raw => 6
Grüße
Christian
Hi Christian,
danke fürs nachschauen.
Dann verhalten sich unsere 470er wohl unterschiedlich.
An der Temperaturdifferenz kann es bei mir auch nicht liegen, hab letztens bei einer Speichertemp. von 20° getestet
und wenn ich an der 470er direkt schalte geht es ja.
Gruß
Sven
Welche Version der Firmware liegt bei diesen 470ern jeweils vor ?
LG
pah
Edit: Das 470er Info-Menü sagt mir VRC470/4,
der Bus-Scan gibt mir
15;Vaillant;47000;0420;1403
26;Vaillant;47000;0420;1403
Wenn ich das richtig verstehe hab ich Software-Version 420
und Hardware-Version 1403 ?!
Gruß
Sven
In der "08.bai.HW7401.csv" gibt es den Parameter d.72
r;wi HwcPostrunTime d.72 WW Pumpnenachlaufzeit 1104 UCH -10 s Pumpennachlaufzeit nach Speicherladung
Direkt an meiner VSC 196 gibt es diesen Parameter nicht.
Abfragen kann ich diesen aber mit "ebusctl r HwcPostrunTimed".
Ist ein Schreiben des Parameters d.72 trotzdem möglich ? Besteht dabei das Risiko einen anderen Speicherbereich zu beschreiben ?
Hallo,
Wenn Du den Wert ausliest, kommt dann was plsusibles heraus ?
gruss Christian
Zitat von: fz69412 am 03 Januar 2016, 01:15:00
update-rc.d: error: initscript does not exist: etc/init.d/ebusd
Ich habe nachgeschaut und es existiert tatsächlich nicht.
Wie kann ich dieses Script bekommen bzw. nachinstallieren?
Das Skript liegt (mit Stand heute) unter https://github.com/john30/ebusd/tree/master/contrib/debian/init.d (https://github.com/john30/ebusd/tree/master/contrib/debian/init.d). Du kannst es einfach in /etc/init.d kopieren, oder Du nimmst die seit gestern verfügbare Release 2.0 und installierst die einfach, dann wird das Skript auch angelegt:
https://github.com/john30/ebusd/releases/tag/v2.0 (https://github.com/john30/ebusd/releases/tag/v2.0)
VG John
Zitat von: ms_9 am 03 Januar 2016, 13:56:48
In meiner 15.470.csv steht allerdings nur was von lesen "r", und bei Dir ?
Ist hier ein Übertragungsfehler enthalten, da das Schreiben in der 430 erlaubt ist und in der 470 nicht ?
Das steht so in der Vaillant DB drin, aber ich kann nochmal nachschauen, ob da nicht wieder ein 1001. Sonderfall greift...
Zitat von: R2D2_ am 06 Januar 2016, 19:48:38
In der "08.bai.HW7401.csv" gibt es den Parameter d.72
r;wi HwcPostrunTime d.72 WW Pumpnenachlaufzeit 1104 UCH -10 s Pumpennachlaufzeit nach Speicherladung
Direkt an meiner VSC 196 gibt es diesen Parameter nicht.
Abfragen kann ich diesen aber mit "ebusctl r HwcPostrunTimed".
Zitat von: cs-online am 07 Januar 2016, 07:56:58
Hallo,
Wenn Du den Wert ausliest, kommt dann was plsusibles heraus ?
gruss Christian
Ja, da kommt "80" bei raus. Sollten also 80s sein, werde das mal direkt an der Therme prüfen.
@cs-online:hänge noch an meinem hwcopmode Problem, kannst Du bitte nochmal die Firmware Version Deiner 470 posten?
Das ist ja merkwürdig, in meiner Installationsanleitung zur ecotecExclusiv steht auch, d.72 Werkseinstellung 80s
musst mal messen und dann ggf. Mal auf anderen Wert setzen und schauen was passiert.
gruss Christian
@john30
vielen Dank für Deine Arbeit , habe die neue Version schon registriert ;-)
und installiert.
Gruß Frank
Für alle Einsteiger gibt es jetzt passend zur ebusd 2.0 Release auch die config Files (CSV) als Debian Paket zum installieren:
https://github.com/john30/ebusd-configuration/releases (https://github.com/john30/ebusd-configuration/releases)
Dort steht auch, wie man das installiert.
VG John
@zentis666
localhost: scan result
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002
Grüße
Christian
@John wegen Test CleaningLady u. TTH (Ende Sept.)
endlich bin ich auf einem aktuellen ebusd (2.0).
ebusctl r -h 50b509030d4b00 -> 051f1f001f1f
ebusctl r -h 26b509030d4b00 -> 051f1f001f1f
mit TTH erhalte ich einen korrekten Wert
ebusctl r -c hc CleaningLady -> 15:30
Zitat von: cs-online am 09 Januar 2016, 15:04:19
@zentis666
localhost: scan result
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002
Grüße
Christian
Danke Christian,
dann haben wir auf jeden Fall schon mal unterschiedliche Soft- und Hardware-Versionen,
hier noch die Daten meiner BAI00
08;Vaillant;BAI00;0113;9602
15;Vaillant;47000;0420;1403Hat zufällig noch jemand eine dieser Kombinationen und könnte mal den hwcopmode auf 6 setzen und kurz rückmelden ob das bei ihm geht?
Grüsse
Sven
Zitat von: jkriegl am 09 Januar 2016, 15:09:25
@John wegen Test CleaningLady u. TTH (Ende Sept.)
endlich bin ich auf einem aktuellen ebusd (2.0).
ebusctl r -h 50b509030d4b00 -> 051f1f001f1f
ebusctl r -h 26b509030d4b00 -> 051f1f001f1f
mit TTH erhalte ich einen korrekten Wert
ebusctl r -c hc CleaningLady -> 15:30
Hilf mir bitte auf die Sprünge: was war das Problem bzw. ist das jetzt gelöst?
Zitat von: cs-online am 07 Januar 2016, 10:32:06
Das ist ja merkwürdig, in meiner Installationsanleitung zur ecotecExclusiv steht auch, d.72 Werkseinstellung 80s
musst mal messen und dann ggf. Mal auf anderen Wert setzen und schauen was passiert.
gruss Christian
@cs-online: Hast Du schon was erreicht ?
@John
kein Problem, ich wollte nur den gewünschten Test nachliefern.
Alles ok.
Zitat von: zentis666 am 09 Januar 2016, 15:30:49
Danke Christian,
dann haben wir auf jeden Fall schon mal unterschiedliche Soft- und Hardware-Versionen,
hier noch die Daten meiner BAI00
08;Vaillant;BAI00;0113;9602
15;Vaillant;47000;0420;1403
Hat zufällig noch jemand eine dieser Kombinationen und könnte mal den hwcopmode auf 6 setzen und kurz rückmelden ob das bei ihm geht?
Grüsse
Sven
Wie lautet nochmal der Aufruf für den scan ?
Mit
ebusctl scan resultbekomme ich nur die Adressen der Bus-Teilnehmer OHNE weitere Daten
Hi,
also bei Version 1.3 und 2.0 zeigt er mit ebusctl scan full und später dann ebusctl scan result die Soft- und Hardware-Version an.
Zitat von: zentis666 am 09 Januar 2016, 15:30:49
Hat zufällig noch jemand eine dieser Kombinationen und könnte mal den hwcopmode auf 6 setzen und kurz rückmelden ob das bei ihm geht?
Wenn es nur um eine einmalige Speicherladung geht, dann könnte mal jemand probieren ob das mit "write -h 08b505020601" funktioniert oder evtl. sogar mit "write -h 15b505020601". Das aktiviert zumindest bei einer EHP (allerdings auf einer anderen Zieladresse) eine einmalige Speicherladung.
Nach Absetzen des Befehls sollte höchstens eine Minute später der ladevorgang beginnen und im Controller erkenntlich sein.
Ach so, Antwort auf den Request ist zumindest bei mir einfach nur "00".
@John wegen einmalige Speicherladung, habe allerdings eine 620
ebusctl write -h 15b505020601 -> ERR: read timeout
ebusctl write -h 08b505020601 -> 00
es passiert nichts, allerdings ist SpeicherIst sehr nahe bei SpeicherSoll.
Hab es auch mit einem höheren SpeicherSoll versucht.
Wie ist quick.csv zu verstehen, da wäre der Wert
*b,quick,,,,FE,B505,,,,,,
*w,quick,,,,50,B505,,,,,,
w;b,,load,Quick - WW Speicherladung,,,,06,,,onoff,,
Zitat von: john30 am 10 Januar 2016, 16:55:42
Wenn es nur um eine einmalige Speicherladung geht, dann könnte mal jemand probieren ob das mit "write -h 08b505020601" funktioniert oder evtl. sogar mit "write -h 15b505020601". Das aktiviert zumindest bei einer EHP (allerdings auf einer anderen Zieladresse) eine einmalige Speicherladung.
Nach Absetzen des Befehls sollte höchstens eine Minute später der ladevorgang beginnen und im Controller erkenntlich sein.
Ach so, Antwort auf den Request ist zumindest bei mir einfach nur "00".
Hi John,
danke für die Info. Die Befehle werden bei mir beide mit 00 quittiert, im Controller hat er allerdings nichts angezeigt, muss ich aber nochmal in Ruhe testen,
es wurde gerade geduscht und das Gerät hat sowieso nachgeladen. Bei hwcopmode 6 springt im Display "1x Speicherladung" ja kurz an und dann wieder aus.
Kennst Du eine Möglichkeit ohne Änderung der Zeitprogramme die Warmwasser-Zirkulationspumpe einzuschalten?
Das war eigentlich das was ich wollte, um auch ausserhalb der programmierten Zeiten mal kurz warmes Wasser zu haben. Wobei ich die Speicherladung auch gut gebrauchen kann :D
Ich hab noch ne Frage: am WE hab ich die ebusd 2.0 und neuen Configs installiert, vielen Dank dafür!
Da ist die 08.bai.HW7401.csv drin, aufgrund meiner BAI Version (08;Vaillant;BAI00;0113;9602)
steuert er damit mein BAI nicht. Habe den String HW7401 im Dateinamen entfernt und damit nimmt er nun auch die csv Datei und
alles was ich getestet habe geht soweit auch mit meinem Gerät.
Das hatte ja sicherlich einen Grund, dass Du diese HW Version angegeben hast, was braucht es denn noch an Infos damit man
für andere HW Versionen noch entsprechende Dateien bereitstellen kann? Würde da gerne unterstützen nur weiss nicht genau wie,
Gruß
Sven
Es geht ja nicht nur darum, di eZirkulationspumpe mal außer der Reihe anzuschalten, sondern auch darum, sie abzuschalten, wenn sie nicht gebraucht wird. Darum steckt bei mir zwischen der Heizungssteuerung und der Pumpe noch dieses Teil hier:
http://www.fhemwiki.de/wiki/1W-WPump
Damit wird tagsüber die Pumpe ausgeschaltet, wenn genügend heißes Wasser in der Leitung ist. Und außerhalb der zeitgesteuerten Laufzeit die Pumpe eingeschaltet, wenn man heißes Wasser benötigt.
LG
pah
Zitat von: jkriegl am 11 Januar 2016, 12:05:47
@John wegen einmalige Speicherladung, habe allerdings eine 620
ebusctl write -h 15b505020601 -> ERR: read timeout
ebusctl write -h 08b505020601 -> 00
es passiert nichts, allerdings ist SpeicherIst sehr nahe bei SpeicherSoll.
Hab es auch mit einem höheren SpeicherSoll versucht.
Wie ist quick.csv zu verstehen, da wäre der Wert
*b,quick,,,,FE,B505,,,,,,
*w,quick,,,,50,B505,,,,,,
w;b,,load,Quick - WW Speicherladung,,,,06,,,onoff,,
Das Ergebnis von "write -c quick load" ist das gleiche wie "write -h 50b505020601". Das wäre auch noch einen Versuch Wert, also als Zieladresse den Mischen zu nehmen (0x50). Bei meiner EHP geht das (sinnvollerweise) über den Mischer und nicht über diw WW Einheit oder die heat circuit.
Zitat von: zentis666 am 11 Januar 2016, 21:16:14
Kennst Du eine Möglichkeit ohne Änderung der Zeitprogramme die Warmwasser-Zirkulationspumpe einzuschalten?
Neine, die kenne ich nicht. Da musst Du einfach die von Deiner Anlage verwendeten CSVs durchforsten.
Vielleicht gibt es auch so einen Spezialbefehl wie die einmalige Speicherladung für die ZP, aber den kenne ich auch nicht.
Zitat von: zentis666 am 11 Januar 2016, 21:16:14
Ich hab noch ne Frage: am WE hab ich die ebusd 2.0 und neuen Configs installiert, vielen Dank dafür!
Da ist die 08.bai.HW7401.csv drin, aufgrund meiner BAI Version (08;Vaillant;BAI00;0113;9602)
steuert er damit mein BAI nicht. Habe den String HW7401 im Dateinamen entfernt und damit nimmt er nun auch die csv Datei und
alles was ich getestet habe geht soweit auch mit meinem Gerät.
Das hatte ja sicherlich einen Grund, dass Du diese HW Version angegeben hast, was braucht es denn noch an Infos damit man
für andere HW Versionen noch entsprechende Dateien bereitstellen kann? Würde da gerne unterstützen nur weiss nicht genau wie,
Für alle sich mit "BAI00" identifizierenden Geräte auf Slave Adresse 0x08 gibt es in der DB 6 sehr unterschiedliche Varianten, die anhand der HW Version unterschieden werden.
Momentan ist auf github nur die eine HW eingecheckt, weil ich noch keinen User kenne, der eine der anderen Varianten besitzt.
Die Varianten unterscheiden sich ziemlich stark in den Nachrichtendefinitionen, aber ich hatte noch keine Zeit, genau nachzusehen, was da genau dahinter steckt.
Ein gutes Beispiel sind die viel diskutierten Werte d.14, d.15, d.17, d.18, d.19, d.20. Diese sind z.B. für eine andere HW Version definiert, nicht aber für die 7401.
@John leider tut sich damit nichts
ebusctl write -h 50b505020601 -> 00
In meiner csv gibt es
hc IsInStorageFilling = no und mc IsInStorageFilling = no
Soll ich mal versuchen darauf zu schreiben. Ist jetzt nur
r,hc,IsInStorageFilling,Speicherladung aktiv,,26,b509,0d4700,yesno,s,UCH,0=no;1=yes,,burner circuit is locked because of ongoing tank loading
Oder besteht eine Gefahr.
ZitatZitat von: john30 am 12 Januar 2016, 07:49:25
...
Momentan ist auf github nur die eine HW eingecheckt, weil ich noch keinen User kenne, der eine der anderen Varianten besitzt.
Die Varianten unterscheiden sich ziemlich stark in den Nachrichtendefinitionen, aber ich hatte noch keine Zeit, genau nachzusehen, was da genau dahinter steckt.
Ein gutes Beispiel sind die viel diskutierten Werte d.14, d.15, d.17, d.18, d.19, d.20. Diese sind z.B. für eine andere HW Version definiert, nicht aber für die 7401.
Also in meiner HW7401 sind d.14, d.15, d.17, d.18, d.19, d.20 vorhanden. Siehe Anhang.
mit meiner HW7401 kann ich d.15 bestätigen.
uchar status mcPumpPower Aktuelle Heizpumpenleistung in % 0 01009b 7300 0D7300 d.15 01 %
siehe auch hier (http://forum.fhem.de/index.php/topic,29737.msg243551.html#msg243551) - Werte sind auch verifiziert (vor ca. einem Jahr - kann aber gerne vor dem "pull request" erneut prüfen).
Ich prüfe mal meine bai und 430 und sende dir ein "pull request" (heute getestet => Ergebnis: funktioniert) - ich hoffe ich komme diese Woche dazu.
Viele Grüße
Arthur
siehe auch hier (http://forum.fhem.de/index.php/topic,29737.msg384353.html#msg384353).
getestet mit vrdialog.
Dann schaue ich mal ob ich einen pullrequest hin bekomme.
Beste Grüße,
Andreas.
Ja. Das Eine ist die höfliche Form des Anderen. 8)
LG
pah
ich kann die Pumpenleistung in % unter Adresse 7300 ebenfalls bestätigen bei der ectoTec exclusiv mit 25KW
der Scan unter EBUSD 1.1.0:
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002
Grüße
Christian
Zitat von: R2D2_ am 13 Januar 2016, 20:01:24
Die Abfrage der Parameter ergibt die gleichen Werte.
bei mir nicht
(http://up.picr.de/24273091cz.png)
Viele Grüße
Arthur
die hier (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de/vaillant)
Meine HW:
slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0516;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
Viele Grüße
Arthur
Zitat von: john30 am 12 Januar 2016, 07:49:25
Neine, die kenne ich nicht. Da musst Du einfach die von Deiner Anlage verwendeten CSVs durchforsten.
Vielleicht gibt es auch so einen Spezialbefehl wie die einmalige Speicherladung für die ZP, aber den kenne ich auch nicht.
Für alle sich mit "BAI00" identifizierenden Geräte auf Slave Adresse 0x08 gibt es in der DB 6 sehr unterschiedliche Varianten, die anhand der HW Version unterschieden werden.
Momentan ist auf github nur die eine HW eingecheckt, weil ich noch keinen User kenne, der eine der anderen Varianten besitzt.
Die Varianten unterscheiden sich ziemlich stark in den Nachrichtendefinitionen, aber ich hatte noch keine Zeit, genau nachzusehen, was da genau dahinter steckt.
Ein gutes Beispiel sind die viel diskutierten Werte d.14, d.15, d.17, d.18, d.19, d.20. Diese sind z.B. für eine andere HW Version definiert, nicht aber für die 7401.
Hallo @all und 3x Daumen hoch für die Entwickler, Tester und Anleitungschreiber!
Meine Anlage, eine auroCompact mit verbautem VSC S 126/3-5 und VRC 470, meldet sich wie folgt:
root@Jt-Raspi-02-ebusd:~# ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;12;22;0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
root@Jt-Raspi-02-ebusd:~# ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 8
masters: 3
messages: 454
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002", loaded "vaillant/15.470.csv"
address 26: slave, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002"
root@Jt-Raspi-02-ebusd:~# ebusctl grab result
1008b5110100 / 086b0212001f300000
1008b512020000 / 00
1008b512020064 / 00
1008b513030600ff / 0101
1008b513030664ff / 0101
10feb505022900
... also offensichtlich eine nicht zur aktuellen 08.bai.HW7401.csv passende Variante. Viele Abfragen liefern ERR: element not found
Ich kenne die DB nicht. Gibt es dazu Anpaßmöglichkeiten oder kennt jemand eine "halbwegs" passende Variante der 08.BAI00 ?
Beste Grüße,
D.
Zitat von: de.jt am 15 Januar 2016, 13:32:24
Viele Abfragen liefern ERR: element not found
Das ist kein Fehler in der Abfrage, sondern eher ein Hinweis für ein (Syntax)fehler im Commando.
Poste doch mal wie dein Commando aussieht.
Hallo amunra,
habe inzwischen bemerkt, daß das kein Problem der BAI00 ist. Ich habe das Beispiel von Reinhart zur EBUS-FHEM-Anbindung via ECMD ausprobiert. Es läuft, bis auf das Setzten der Heizkurve.
=> HeizkurveSchreiben ERR: element not found
15.470.csv
r;wi Hc1HeatCurve Heizkurve Heizkreis 1
vaillant.cfg
define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
bai00.class
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
In Konsole direkt eingegeben: root@Jt-Raspi-02-ebusd:~# ebusctl w Hc1HeatCurve 1.2
ERR: element not found
... ja, das hatte ich bereits ebenfalls probiert => negativ.
root@Jt-Raspi-02-ebusd:~# ebusctl w 470 Hc1HeatCurve 1.2
ERR: element not found
schau doch mal nach was ind den csv's vorhanden ist
z.B. mit ebusctl f -f Curve
wenn du eine 470 hast
Zitat von: de.jt am 15 Januar 2016, 19:15:49
15.470.csv
r;wi Hc1HeatCurve Heizkurve Heizkreis 1
wieso nimmst du dann eine 430
Zitat von: de.jt am 15 Januar 2016, 19:15:49
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
EDIT: Siehe commando im nachfolgenden Beitrag von cs-online
und hier noch ein Syntaxfehler:Zitat von: de.jt am 15 Januar 2016, 19:15:49
In Konsole direkt eingegeben: root@Jt-Raspi-02-ebusd:~# ebusctl w Hc1HeatCurve 1.2
ERR: element not found
probier mal so:ebusctl wi -c 470 Hc1HeatCurve 1.2Viele Grüße
Arthur
EDIT: w -> wi angepasst
kommt bei
r -f Hc1HeatCurve
was sinnvolles bei raus ?
wenn ja, mal das probieren
ebusctl w 470#install Hc1HeatCurve 1.2
probiert ? Das müßte bei r;wi eigentlich passen
@ amunra
430 ist natürlich Quatsch. Kommt vom hin und her spielen. Der Originalquelltext von Reinhart bezog sich auf eine 430. Hatte ich in meinen Versuchen schon einmal auf 470 umgestellt - mit dem geposteten ERR...
Dein Tip:
root@Jt-Raspi-02-ebusd:~# ebusctl wi -c 470 Hc1HeatCurve 1.2
ERR: command not found
@cs-online
Dein Tip hat das Problem erst einmal gelöst, auch wenn mir vorerst die Logik nicht klar erscheint. Muß ich wohl noch viel nachlesen....
root@Jt-Raspi-02-ebusd:~# ebusctl r -f Hc1HeatCurve
0.80
root@Jt-Raspi-02-ebusd:~# ebusctl w 470#install Hc1HeatCurve 1.2
done
root@Jt-Raspi-02-ebusd:~# ebusctl r -f Hc1HeatCurve
1.20
Besten Dank für Eure Hilfe,
Gruß,
D.
Hat jemand eine Deutung für
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8.
Eine CSV scheint es dafür nicht zu geben.
Vielleicht hängen die undefinierten Kommandos
1008b5110100 / 086b0212001f300000
1008b512020000 / 00
1008b512020064 / 00
1008b513030600ff / 0101
1008b513030664ff / 0101
10feb505022900
damit zusammen?
D.
Hallo de.jt
super das es mit dem commando
ebusctl w 470#install Hc1HeatCurve 1.2
funktioniert.
Ich habe mal in der 470er nachgeschaut (ich selbst habe die 430) und bin mir aber sicher, dass etwas mit der Syntax nicht stimmt:
Laut 470er Definition:
*wi #install B509 0E
r;wi Hc1HeatCurve Heizkurve Heizkreis 1 3100
müsste der Aufruf mMn wie folgt lauten:
ebusctl wi 470#install Hc1HeatCurve 1.2
Könntest Du bitte folgende Ausgabe hier posten:
ebusctl find -w -f Hc1HeatCurve
Danke.
Viele Grüße
Arthur
@de.jt
meinen letzten Post einfach ignorieren.
w => write und nicht wi!
wi ist nur die Definition für den calss suffix #install => 470#install
heißt => alles ok
Viele Grüße
Arthur
Zitat von: de.jt am 15 Januar 2016, 22:13:14
Hat jemand eine Deutung für
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8.
Eine CSV scheint es dafür nicht zu geben.
in der Version 2.x heißt sie: 15.470.csv
in der Version 1.x heißt sie: 470.csv
Zitat
Vielleicht hängen die undefinierten Kommandos
1008b5110100 / 086b0212001f300000
1008b512020000 / 00
1008b512020064 / 00
1008b513030600ff / 0101
1008b513030664ff / 0101
10feb505022900
damit zusammen?
das sind ja nur Broadcast, die wirst du nicht brauchen außer du wertest die aus. Die sind in der _broadcast.csv definiert (und dort fehlen sie noch) und nicht in der 470!
LG
ok, hab ich verstanden.
root@Jt-Raspi-02-ebusd:~# ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;12;22;0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
ebusctl info liefert u.a.
address 15: slave #6, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002", loaded "vaillant/15.470.csv"
address 26: slave, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002"
=> warum wird für
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8 die 15.470.csv geladen und für
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860; keine?
Gruß,
D.
Zitat von: jkriegl am 12 Januar 2016, 12:32:30
In meiner csv gibt es
hc IsInStorageFilling = no und mc IsInStorageFilling = no
Soll ich mal versuchen darauf zu schreiben. Ist jetzt nur
r,hc,IsInStorageFilling,Speicherladung aktiv,,26,b509,0d4700,yesno,s,UCH,0=no;1=yes,,burner circuit is locked because of ongoing tank loading
Oder besteht eine Gefahr.
Dieses Register sieht mir eher wie ein Status aus, also würde es nichts bringen, darauf zu schreiben.
Kannst Du denn an der Steuerung eine einmalige Speicherladung aktivieren?
Fall ja, einfach mal ebusd mit protokollieren lassen, was dann auf dem Bus so passiert.
Falls nein, gehe ich davon aus, dass das der Controller nicht beherrscht.
Zitat von: RobertG am 12 Januar 2016, 22:31:25
Also in meiner HW7401 sind d.14, d.15, d.17, d.18, d.19, d.20 vorhanden. Siehe Anhang.
Das ist ein sehr wertvoller Hinweis! Danke dafür!
Jetzt kann ich das mal konkret mit vrdialog über ebusd austesten :-)
Könntest Du mir noch Dein Scan Ergebnis posten bitte (oder "ebusctl info")?
Zitat von: de.jt am 15 Januar 2016, 19:15:49
15.470.csv
r;wi Hc1HeatCurve Heizkurve Heizkreis 1
In Konsole direkt eingegeben: root@Jt-Raspi-02-ebusd:~# ebusctl w Hc1HeatCurve 1.2
ERR: element not found
Das liegt schlicht daran, dass beim "write" Kommando
immer die anzusprechende Circuit angegeben werden muss.
Vielleicht sollte ich das optionale "-c" beim write in der nächsten Version rauswerfen, das führt immer wieder zu Durcheinander und Missverständnissen.
Also richtig wäre das Kommando wie folgt:
ebusctl w -c 470#install Hc1HeatCurve 1.2Mit Deinem Aufruf von oben versteht das ebusd als Anfrage, an die Circuit "Hc1HeatCurve" die Message mit dem Namen "1.2" zu senden. Und die gibt es so nicht in Deinen CSVs...
Zitat von: john30 am 16 Januar 2016, 09:38:39
Vielleicht sollte ich das optionale "-c" beim write in der nächsten Version rauswerfen, das führt immer wieder zu Durcheinander und Missverständnissen.
Das "-c" ist beim read nicht optional. Ich gebe deshalb bei "r" und "w" immer das "-c" mit.
Viele Grüße
Arthur
Zitat von: de.jt am 15 Januar 2016, 22:13:14
Hat jemand eine Deutung für
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8.
Eine CSV scheint es dafür nicht zu geben.
Laut Vaillant DB gibt es dazu nichts spezielles. Wird also alles über die Adresse 15 und damti mit den Definitionen der 15.470.csv geregelt.
Zitat von: amunra am 16 Januar 2016, 09:49:51
Das "-c" ist beim read nicht optional. Ich gebe deshalb bei "r" und "w" immer das "-c" mit.
Doch ist es schon, aber dann wird die erste Definition mit dem angegeben Namen verwendet. Sofern alle Nachrichten unterschiedliche Namen haben, ist das egal.
Besser ist auf jeden Fall, die circuit mit "-c ..." anzugeben. Sowohl beim read wie auch beim write.
Hallo John,
ja, stimmt.
Will sagen, ich würde das "-c" bei write lassen ;o)
Viele Grüße
Arthur
@John
ich glaube die Arbeit kannst du dir sparen, man weiss es ja jetzt und die Heizkurve ist ein Sonderfall.
Nur soweit ich mitbekommen habe, ist ja bei der 430 alles ok (weil kein #install) und bei der CSV der 470 ist die Definition als #install und genau das funktioniert nicht. Die User müssen daher das "wi" in der csv entfernen und dann klappt es.
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write -c 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
# OutsideTempOffset
get OutsideTempOffset cmd {"write -c 430#install OutsideTempOffset ".Value("OutsideTempOffset")."\n"}
get OutsideTempOffset expect ".*\n\n"
get OutsideTempOffset postproc { $_ }
hier ein Beispiel wie ich es definiert habe, das klappt. Der Temperaturoffset funktioniert auch tadellos mit #install, nur bei der Heizkurve gibt es ein Problem. Seltsam auch, das die 430 ohne #install und bei der 470 es mit #install definiert ist. Dürfte wohl so aus der DB kommen.
LG
Zitat von: Reinhart am 16 Januar 2016, 10:31:09
Seltsam auch, das die 430 ohne #install und bei der 470 es mit #install definiert ist. Dürfte wohl so aus der DB kommen.
Ja, das ist so ziemlich sinnbefreit in der DB drin. Bei 430 darf das der user ändern und bei 470 nur der Installateur.. schlau gemacht :)
Bei dem 430er, also am Raumthermostat, muss man auch nicht in die codedegeschütze Menüebene - vielleicht ist das bei dem 470 anders?
bei der 470er muss man eine Pin eingeben (bzw. zu bestätigen), um in die Fachhandwerkerebene zu kommen. Ist voreingestellt auf 0000
Grüße
Christian
Zitat von: amunra am 16 Januar 2016, 11:39:53
Bei dem 430er, also am Raumthermostat, muss man auch nicht in die codedegeschütze Menüebene - vielleicht ist das bei dem 470 anders?
da sieht man wieder die Unterschiede, an meiner 430 muss ich den Code 1000 eingeben (zB: Heizkurve). Ich habe aber die 430 in die Therme eingebaut.
LG
Hallo Reinhart,
ja, interessent - meine 430 hat die Software Version 2.15, wenn ich mich richtig entsinne, dann hat deine die gleiche. Bei mir ist es jedoch nicht in die Therme eingebaut - dürften aber an der Therem gleich angeschlossen sein. Es scheint also, als würde die Therme das steuern? Das auch noch womöglich abhängig von der Version der Software evtl. sogar auch noch landesabhängig?
Viele Grüße
Arthur
Da der Einbau ja auch nur in einem eBus Steckkontakt führt, wird es vermutlich das AT an der Therme sein.
Ist ja überhaupt verwunderlich, das AT und De verschiedene Ausführungen sind. Wir haben das gleiche Gas und sprechen die selbe Sprache (schreiben zumindest).
LG
vielleicht habe ich auch ein Heimvorteil - der Hauptsitz ist grade mal 6 km von mir entfernt ;o)
Viele Grüße
Arthur
Hat irgendwer das TeleSwitch Feature im Einsatz?
Es muss eine Nachricht geben, die der Switch absetzt, um im entsprechenden Gerät den TeleSwitch Modus zu aktivieren.
Der würde mich zum Missbrauch für völlig andere Zwecke interessieren :-)
VG John
@pah:
Wer zeichnet denn für http://fhemwiki.de/wiki/EBUS verantwortlich?
Könnte man das mal aktualisieren? Dort sind noch sehr alte und längst nicht mehr gültige Sachen drin, z.B. Link auf ebusd Repository.
VG John
Zitat von: john30 am 16 Januar 2016, 08:34:07
Das ist ein sehr wertvoller Hinweis! Danke dafür!
Jetzt kann ich das mal konkret mit vrdialog über ebusd austesten :-)
Könntest Du mir noch Dein Scan Ergebnis posten bitte (oder "ebusctl info")?
gerne, hier isses (Adresse ff / master #25 ist offenbar der vrdialog-Adapter):
ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;13;21;0010009351;3100;005509;N0
15;Vaillant;47000;0231;6002;21;12;41;0020108127;0082;041770;N4
26;Vaillant;47000;0231;6002;21;12;41;0020108127;0082;041770;N4
ebusctl info
version: ebusd 2.0.p20160109
signal: acquired
symbol rate: 22
masters: 4
messages: 504
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=47000;SW=0231;HW=6002", loaded "vaillant/15.470.csv"
address 26: slave, scanned "MF=Vaillant;ID=47000;SW=0231;HW=6002"
address ff: master #25 Hier noch ein paar weitere Zeitprogramme für die 15.470.csv mit vrdialog gegengetestet:
# Zeitprogramme Kühlen,,,,,,,,,,,,,,,,
*r,,,,,,"B515",,,,IGN:1,,,,,,
*w,,,,,,"B515",,,,,,,,,,
r;w,,hccTimer.Monday,Zeitfenster Montag,,,,0003,,,timer,,,,,,
r;w,,hccTimer.Tuesday,Zeitfenster Dienstag,,,,0103,,,timer,,,,,,
r;w,,hccTimer.Wednesday,Zeitfenster Mittwoch,,,,0203,,,timer,,,,,,
r;w,,hccTimer.Thursday,Zeitfenster Donnerstag,,,,0303,,,timer,,,,,,
r;w,,hccTimer.Friday,Zeitfenster Freitag,,,,0403,,,timer,,,,,,
r;w,,hccTimer.Saturday,Zeitfenster Samstag,,,,0503,,,timer,,,,,,
r;w,,hccTimer.Sunday,Zeitfenster Sonntag,,,,0603,,,timer,,,,,,
# Zeitprogramme Tarif Perioden,,,,,,,,,,,,,,,,
*r,,,,,,"B515",,,,IGN:1,,,,,,
*w,,,,,,"B515",,,,,,,,,,
r;w,,hctTimer.Monday,Zeitfenster Montag,,,,0004,,,timer,,,,,,
r;w,,hctTimer.Tuesday,Zeitfenster Dienstag,,,,0104,,,timer,,,,,,
r;w,,hctTimer.Wednesday,Zeitfenster Mittwoch,,,,0204,,,timer,,,,,,
r;w,,hctTimer.Thursday,Zeitfenster Donnerstag,,,,0304,,,timer,,,,,,
r;w,,hctTimer.Friday,Zeitfenster Freitag,,,,0404,,,timer,,,,,,
r;w,,hctTimer.Saturday,Zeitfenster Samstag,,,,0504,,,timer,,,,,,
r;w,,hctTimer.Sunday,Zeitfenster Sonntag,,,,0604,,,timer,,,,,,
# Zeitprogramme Geräuschreduktion,,,,,,,,,,,,,,,,
*r,,,,,,"B515",,,,IGN:1,,,,,,
*w,,,,,,"B515",,,,,,,,,,
r;w,,hcnTimer.Monday,Zeitfenster Montag,,,,0005,,,timer,,,,,,
r;w,,hcnTimer.Tuesday,Zeitfenster Dienstag,,,,0105,,,timer,,,,,,
r;w,,hcnTimer.Wednesday,Zeitfenster Mittwoch,,,,0205,,,timer,,,,,,
r;w,,hcnTimer.Thursday,Zeitfenster Donnerstag,,,,0305,,,timer,,,,,,
r;w,,hcnTimer.Friday,Zeitfenster Freitag,,,,0405,,,timer,,,,,,
r;w,,hcnTimer.Saturday,Zeitfenster Samstag,,,,0505,,,timer,,,,,,
r;w,,hcnTimer.Sunday,Zeitfenster Sonntag,,,,0605,,,timer,,,,,,Die decodierten Abfragen für den Solarkreis hatte ich ja schon beschrieben.
Beste Grüße,
Andreas.
Zitat von: Prof. Dr. Peter Henning am 05 Januar 2016, 15:47:11
Welche Version der Firmware liegt bei diesen 470ern jeweils vor ?
LG
pah
Ergebnis:
08;Vaillant;BAI00;0518;7401
15;Vaillant;47000;0126;6002Vielleicht hilft's ja jemandem ...
@cs-online,john30:
Was ist aus "d.29 - Durchfluss" geworden ?
Zitat von: R2D2_ am 17 Januar 2016, 11:37:58
...gibts nen Absturz.
Welche Version setzt Du denn ein?
Sorry, hatte den Beitrag gekürzt :-[
Hier die Version, welche ich updaten möchte, aber nicht weis, wie.
version: ebusd 2.0.0-preview.79cbd56
Den Absturz (hängen) gab's nach ca. 1-2min mit
ebusctl scan result
EDIT:
"Update": OK, hab's gesehen im Nachbarthread
Keine Sorge ich bin ein biss(883chen a1q vzz
Gesendet von iPhone mit Tapatalk
Hallo
Ich möchte meine Vaillant FlexoTherm vwf117 in meinem KNX Bus einbinden,
nun ist mir die von vaillant vorgesehene Variante zu teuer (ISE Gateway 700€)
Weiß jemand ob ebusd mit der Flexotherm zusammenarbeitet?
PS hat jemand eine Bauteilliste für den busankoppler?
Ich habe leider etwas schwierigkeiten die korrekten Bauteile der Zeichnung zu entnehmen.
Gruß
Michael
Hallo,
ich kann den Koppler hier empfehlen, der Kollege fast ganz unten hat noch Platinen, evtl. hat der darüber auch noch komplette Koppler
https://www.mikrocontroller.net/topic/346833#4406454
(https://www.mikrocontroller.net/topic/346833#4406454)
Kosten ca. 10Euro + Platine (bei Horst 2Euro plus Porto)
Gruß Christian
@R2D2:
D.29, das mußte ich leider aus Zeitgründen aufschieben, aber steht noch auf dem Zettel
Grüße
Christian
Zitat von: Jensmaier2 am 17 Januar 2016, 18:20:50
PS hat jemand eine Bauteilliste für den busankoppler?
Ich habe leider etwas schwierigkeiten die korrekten Bauteile der Zeichnung zu entnehmen.
Reinhart hat hier (http://forum.fhem.de/index.php/topic,45127.0.html) auch noch eine Sammelbestellung laufen - kann ich ebenfalls empfehlen.
Zitat von: Jensmaier2 am 17 Januar 2016, 18:20:50
Ich möchte meine Vaillant FlexoTherm vwf117 in meinem KNX Bus einbinden,
Schau mal ins Installationshandbuch, ob das Teil einen eBus Anschluss hat.
Falls ja, bleibt nur noch die Schwierigkeit, die Telegramme zu entschlüsseln. Vermutlich kann man sich bei anderen Thermen "bedienen", aber garantiert ist das natürlich nicht...
VG John
Zitat von: john30 am 17 Januar 2016, 09:47:00
@pah:
Wer zeichnet denn für http://fhemwiki.de/wiki/EBUS verantwortlich?
Könnte man das mal aktualisieren? Dort sind noch sehr alte und längst nicht mehr gültige Sachen drin, z.B. Link auf ebusd Repository.
VG John
Hallo John, Hallo pah,
ich habe den wiki EBUSD Eintrag dahingehend angepasst, dass der ebusd Link und der default ebusd service Aufruf passt.
Ich finde, dass die Beiträge von Reinhart aus dem Forum Bereich "eBus Schaltung in Betrieb nehmen" dort ebenfalls integriert werden sollten.
Das ist auch der Grund warum ich das nur minimalistisch angepasst habe.
Viele Grüße
Arthur
P.S. Wir könnten das Inhaltsverzeichnis abstimmen (Inhalte gibt es – siehe Thread von Reinhart) und die Beiträge aus dem Thread in das Wiki übertragen - dann geht es etwas einfacher, wenn man auf das Wiki verweisen kann. Ja, pflegen muss das auch jemand :-\. Ich kann gerne einen ersten Wurf für ein Inhaltsverzeichnis (Zusammenfassung der letzten 1-2 Monate) hier platzieren.
EDIT:
P.S.: Ich würde natürlich die Unterstützung von Reinhart sehr begrüßen :)
Tja, das mit dem Pflegen ist immer so eine Sache. Ich habe so viele Neuentwicklungen in Arbeit (getriggert durch DAS BUCH), dass ich kaum dazu komme. Ihr macht das aber schon ganz gut...
LG
pah
Zitat von: amunra am 18 Januar 2016, 22:21:24
P.S.: Ich würde natürlich die Unterstützung von Reinhart sehr begrüßen :)
Ich möchte dich natürlich nicht hängen lassen und werde dich bei der Arbeit im Fhemwiki unterstützen soweit ich kann.
Es ist natürlich ein großer Unterschied ob man ein Posting mit ein paar bunten Bildern macht oder in der Mediawiki einen Beitrag erstellt. Ich habe ja beruflich einige Jahre mit der Mediwiki gearbeitet und weiß wie schnell man da was ramponieren kann. Ich werde Anfangs die Sandbox benutzen bevor ich die Beiträge scharf mache!
Über den Inhalt können wir uns natürlich abstimmen, speziell dein Vorschlag über das Inhaltsverzeichnis!
PS: angemeldet bin schon.
LG
Danke Reinhart - ich melde mich.
Viele Grüße
Arthur
@amunra
Ich habe mich heute einmal etwas in die Mediawiki eingearbeitet, dazu habe ich einfach das Mediawiki auf meinem Server installiert und habe somit die ideale Entwicklungsumgebung.
Ich habe einmal einen ersten Entwurf in die Sandbox (http://www.fhemwiki.de/wiki/FHEMWiki:Sandbox) gestellt!
Wir müssen halt dann diskutieren wie du dir das so genau mit dem Inhalt vorstellst. Kann auch per PN erfolgen, damit wir den Thread hier nicht zumüllen!
LG
Reinhart
Dann setzt mich auf CC, dann kann ich auch noch (ein wenig) mitmischen.
LG
pah
Super Reinhart - ich schicke nachher mal ein FreeMind-File rum.
@pah: ok
Viele Grüße
Arthur
Hallo John,
mir ist ein unschönes Verhalten aufgefallen und zwar, wenn der Service läuft und man das EBUS Interface (USB) abzieht, dann geht die CPU Last auf 99%. Auch wenn ich das EBUS Interface wieder anschließe bleibt die CPU Last bei 99%. Ein edusd restart hilft. Das kann ich, zumindest bei mir, immer wieder reproduzieren. Kann man dagegen etwas tun (Ausser Watchdog etc.). Hast Du dieses Verhalten bei dir auch?
Danke und Viele Grüße
Arthur
Zitat von: amunra am 23 Januar 2016, 13:40:31
mir ist ein unschönes Verhalten aufgefallen und zwar, wenn der Service läuft und man das EBUS Interface (USB) abzieht, dann geht die CPU Last auf 99%. Auch wenn ich das EBUS Interface wieder anschließe bleibt die CPU Last bei 99%. Ein edusd restart hilft. Das kann ich, zumindest bei mir, immer wieder reproduzieren. Kann man dagegen etwas tun (Ausser Watchdog etc.). Hast Du dieses Verhalten bei dir auch?
Hallo Arthur,
das habe ich jetzt noch nicht gehabt. Werd mal versuchen, das zu reproduzieren.
Auf was für einer Umgebung läuft bei Dir ebusd und welche Version?
VG John
Hallo John,
HW:
Cubietruck
SW:
Distributor ID: Debian
Description: Debian GNU/Linux 8.2 (jessie)
Release: 8.2
Codename: jessie
eBusd:
version: ebusd 2.0.f5e218e
Viele Grüße
Arthur
P.S: Auf meinem Raspberry Pi (Modell B) habe ich das gleiche Verhalten.
Zitat von: amunra am 23 Januar 2016, 16:36:57
P.S: Auf meinem Raspberry Pi (Modell B) habe ich das gleiche Verhalten.
Also auf dem RPi kann ich das nicht nachvollziehen. ebusd produziert mit beliebig oft Abstecken/Anstecken immer noch die gleiche CPU Last.
Welcher Prozess macht denn dann bei Dir die 100% CPU?
Zitat von: Reinhart am 27 März 2015, 17:29:39
@john30
was mir beim Testen noch aufgefallen ist, in der bai00.csv fehlt noch d.14, d.15, d.17, d.18, d.19, d.20.
Oder wurden die vielleicht in eine andere Datei ausgelagert?
r,,PumpPowerDesired,d.14 => Leistung Heizungspumpe Soll,,,,0A04,,,UCH,0=auto;1=53;2=60;3=70;4=85;5=100,%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpPower,d.15 => Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,RegulationMode,d.17 => Regelungsmodus,,,,0C04,,,UCH,0=flow;1=return,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode,d.18 => Pumpenbetriebsart,,,,4904,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode2,d.19 => Pumpenbetriebsart 2. Pumpe,,,,0B04,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,StorageTempSetMax,d.20 => Maximale Speichersolltemperatur,,,,4304,,,temp,, °C,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
LG
Reinhart
Sobald ich die 08.bai.HW7401.csv damit erweitere, ist der Parameter "PrEnergySumHc1" nicht mehr lesbar.
Gibt's eine bestimmte Vorgehensweise für eine Erweiterung ? Ich nutze Notepad++
Zitat von: john30 am 23 Januar 2016, 16:49:42
Welcher Prozess macht denn dann bei Dir die 100% CPU?
(http://up.picr.de/24370866gj.jpg)
Man muss allerdings min. 4-5 Sekunden warten, dann geht die CPU hoch.
Viele Grüße
Arthur
Hallo Robert. Mir scheint, wir haben ziemlich ähnliche Anlagen. Ich habe Deine Erweiterung der 08.bai.HW7401 um die Solarabfragen übernommen. Und doch liefert die Kontrollabfrage andere Ergebnisse. Bedeutet das, daß bei meiner Anlage die Komponenten zur Meßwerterfassung / Auswertung nicht auf dem Bus verfügbar sind?
root@Jt-Raspi-02-ebusd:~# ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;12;22;0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
root@Jt-Raspi-02-ebusd:~# ebusctl find DK
470 CalculatedKickStopTime = no data stored
aur SolarErtragkWh_DK = no data stored
aur SolarKollektorTemperatur_DK = no data stored
aur SolarPumpePwm_DK = no data stored
aur SolarRL_DK = no data stored
aur SolarVolumenstrom_DK = no data stored
aur SpeicherbodenTemperatur_DK = no data stored
aur WPPumpspeedSetpoint_DK = no data stored
aur WPPwm_DK = no data stored
Zitat von: de.jt am 23 Januar 2016, 21:43:58
Hallo Robert. Mir scheint, wir haben ziemlich ähnliche Anlagen. Ich habe Deine Erweiterung der 470 um die Solarabfragen übernommen. Und doch liefert die Kontrollabfrage andere Ergebnisse. Bedeutet das, daß bei meiner Anlage die Komponenten zur Meßwerterfassung / Auswertung nicht auf dem Bus verfügbar sind?
root@Jt-Raspi-02-ebusd:~# ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;12;22;0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
root@Jt-Raspi-02-ebusd:~# ebusctl find DK
470 CalculatedKickStopTime = no data stored
aur SpeicherbodenTemperatur_DK = no data stored
aur WPPumpspeedSetpoint_DK = no data stored
Hallo,
ich bin zwar nicht RobertG, aber versuchs doch mal mit:
ebusctl find -f DKViele Grüße
Arthur
@ amunra:
root@Jt-Raspi-02-ebusd:~# ebusctl find -f DK
r,470,CalculatedKickStopTime,CalculatedKickStopTime,,15,b509,0d8c00,minutes0,s,UCH,,min,calculated time in between two pump kicks during frostprotection (time depends on outside temperature)
r,aur,SolarErtragkWh_DK,d.59 Solarertrag,,08,b509,0d7200,energy,s,UIN,,kWh,berechneter gesamter Solarertrag
r,aur,SolarKollektorTemperatur_DK,d.38 Kollektortemperatur,,08,b509,0d7800,temp,s,D2C,,°C,Thermosolarkollektor-Temperatur und Fühlerstatus,sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
r,aur,SolarPumpePwm_DK,PWM-Solarpumpe,,08,b509,0d7d00,percent0,s,UCH,,%,PWM-Leistungsstufe der Solarpumpe
r,aur,SolarRL_DK,d.39 Solarertragsensor,,08,b509,0d6800,temp,s,D2C,,°C,Solarertragsensor Temperatursensor im Kollektorrücklauf und Fühlerstatus,sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
r,aur,SolarVolumenstrom_DK,d.57 Volumenstrom Solarpumpe,,08,b509,0d6a00,,s,UCH,10,,l/min,Volumenstrom Solarpumpe in Liter pro Minute
r,aur,SpeicherbodenTemperatur_DK,d.42 Speicherbodentemperatur,,08,b509,0d0600,temp,s,D2C,,°C,aktuelle Speicherbodentemperatur WW Speicher,sensor,s,UCH,0=ok;85=circuit;170=cutoff,,Fühlerstatus
r,aur,WPPumpspeedSetpoint_DK,d.14 Pumpe Leistungsstufe,,08,b509,0d0a04,,s,BCD,0=Auto;1=53%;2=60%;3=70%;4=80%;5=100%,,PWM-Leistungsstufe der Heizungspumpe
r,aur,WPPwm_DK,d.15 Pumpendrehzahl Istwert in %,,08,b509,0d7300,percent0,s,UCH,,%,Output of PWM pump
Das sind jetzt alle Definitionen die ein "DK" beinhalten und Du die per ebusd abfragen kannst.
Willst du das?
Dann geht das z.B. so:
ebusctl r -c aur SolarErtragkWh_DK
oder
ebusctl r -c aur SolarKollektorTemperatur_DK
Viele Grüße
Arthur
Zitat von: amunra am 23 Januar 2016, 17:05:18
Man muss allerdings min. 4-5 Sekunden warten, dann geht die CPU hoch.
Das hab ich schon probiert, aber bringt nix.
Wär es möglich, eine session zu machen, wo ich da mal reindebuggen kann?
Hallo John,
ich müsste einiges umbauen und freischalten.
Es kommt ja selten vor, dass man das Interface abzieht, zumindest ist es bei mir so, daher finde ich das jetzt auch nicht ganz so kritisch.
Wenn dieses Verhalten nur bei mir auftritt, dann möchte ich eher kein Aufwand deinerseits generieren.
Viele Grüße
Arthur
P.S: Zur Not kann ich mit einem Watchdog entgegenwirken - zwar nicht schön, würde aber helfen.
Zitat von: RobertG am 17 Januar 2016, 10:38:48
gerne, hier isses (Adresse ff / master #25 ist offenbar der vrdialog-Adapter):
Könntest Du mir bitte die Ausgabe folgender Kommandos schicken:
ebusctl w -h 08b5090124
ebusctl w -h 08b5090127
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl w -h 08b509022802
ebusctl w -h 08b509022803
ebusctl w -h 08b5090124
ebusctl w -h 08b5090125
ebusctl w -h 08b5090125
ebusctl w -h 08b5090127
Damit wird die genaue Version der BAI abgefragt.
Ich habe nach einer Erweiterung von der 08.bai.HW7401.csv folgendes Problem:
Ausgabe von ebusctl -info mit original-csv
pi@raspberrypi /etc/ebusd/vaillant $ ebusctl info
version: ebusd 2.0.0-preview.79cbd56
signal: acquired
symbol rate: 41
masters: 3
messages: 449
address 03: master #3, seen
address 08: slave of 03, seen, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6, seen
address 15: slave of 10, seen, scanned "MF=Vaillant;ID=47000;SW=0126;HW=6002", loaded "vaillant/15.470.csv"
Nach einigen Änderungen an der 08.bai.HW7401.csv (hinzufügen von Parametern):
pi@raspberrypi /etc/ebusd/vaillant $ ebusctl info
version: ebusd 2.0.0-preview.79cbd56
signal: acquired
symbol rate: 22
masters: 3
messages: 363
address 03: master #3, seen
address 08: slave of 03, seen, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401"
address 10: master #6, seen
address 15: slave of 10, seen, scanned "MF=Vaillant;ID=47000;SW=0126;HW=6002", loaded "vaillant/15.470.csv"
Warum wird jetzt die 08.bai.HW7401.csv nicht als geladen angegeben ? :-[
Zitat von: R2D2_ am 24 Januar 2016, 12:17:02
Ich habe nach einer Erweiterung von der 08.bai.HW7401.csv folgendes Problem:
Warum wird jetzt die 08.bai.HW7401.csv nicht als geladen angegeben ? :-[
Da wird das Laden wohl schief gegangen sein. Schau mal ins Log File (/var/log/ebusd.log), da sollte was dazu stehen.
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl w -h 08b509022802
ebusctl w -h 08b509022803
ebusctl w -h 08b5090124
ebusctl w -h 08b5090125
ebusctl w -h 08b5090125 (doppelt)
ebusctl w -h 08b5090127
Damit wird die genaue Version der BAI abgefragt.
Hi john,
0402a70c0c
0403ae0510
09003231303834333030
09313030303338363333
09313030303338363333 (doppelt)
094e3500000000000000address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0516;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
Viele Grüße
Arthur
Das hier ... "duplicate entry" ? :-\ Habe an der "broadcast.csv" nix geändert ...
2016-01-24 12:12:18.868 [main notice] ebusd 2.0.0-preview.79cbd56 started
2016-01-24 12:12:18.928 [main notice] found messages: 13 (0 conditional on 0 conditions, 0 poll, 13 update)
2016-01-24 12:12:18.974 [bus notice] signal acquired
2016-01-24 12:12:20.159 [bus notice] new master 10, master count 2
2016-01-24 12:12:20.160 [bus notice] new master 03, master count 3
2016-01-24 12:12:20.160 [update notice] update myCustom Status01: 26.0;25.0;5.125;43.0;54.0;off
2016-01-24 12:12:24.390 [update notice] unknown MS cmd: 1008b5100900002e6affff00ff00 / 0101
2016-01-24 12:12:24.547 [main notice] read common config file /etc/ebusd/vaillant/scan.csv for scan bai00
2016-01-24 12:12:24.548 [main error] error reading common config file /etc/ebusd/vaillant/broadcast.csv for scan bai00: ERR: duplicate entry
2016-01-24 12:12:24.607 [main error] error reading config file /etc/ebusd/vaillant/08.bai.HW7401.csv for scan bai00: ERR: duplicate entry
2016-01-24 12:12:26.911 [main notice] read config file /etc/ebusd/vaillant/15.470.csv for scan 47000
2016-01-24 12:12:26.911 [main notice] found messages: 363 (0 conditional on 1 conditions, 0 poll, 13 update)
Zitat von: R2D2_ am 24 Januar 2016, 12:24:47
Das hier ... "duplicate entry" ? :-\ Habe an der "broadcast.csv" nix geändert ...
Naja irgendwas ist geändert. Wahrscheinlich hast Du in die bai Dinge eingetragen, die in der broadcast schon drin sind.
Prüfe mal die CSVs genau mit folgendem Aufruf an ebusd:
ebusd --checkconfig --scanconfig -c /etc/ebusd "ff08070400/0ab5424149303005187401"
@john:
habe ein Duplikat in der 08.bai.HW7401.csv gefunden und dann wie vorgeschlagen den Aufruf eingegeben, Ergebnis:
pi@raspberrypi /etc/ebusd/vaillant $ ebusd --checkconfig --scanconfig -c /etc/ebusd "ff08070400/0ab5424149303005187401"
2016-01-24 12:43:59.334 [main notice] Performing configuration check...
2016-01-24 12:43:59.370 [main notice] found messages: 13 (0 conditional on 0 conditions, 0 poll, 13 update)
2016-01-24 12:43:59.403 [main notice] read common config file /etc/ebusd/vaillant/scan.csv for scan bai00
2016-01-24 12:43:59.407 [main error] error reading common config file /etc/ebusd/vaillant/broadcast.csv for scan bai00: ERR: duplicate entry
2016-01-24 12:43:59.520 [main notice] read config file /etc/ebusd/vaillant/08.bai.HW7401.csv for scan bai00
2016-01-24 12:43:59.522 [main notice] found messages: 212 (3 conditional on 1 conditions, 0 poll, 13 update)
Doppelter Eintag in der broadcast finde ich keine weiteren, die anderen habe ich auskommentiert:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment
*b,broadcast,,,,FE,B516,,,,,,,,,,,,,,,,,,,
#b,,vdatetime,Datum/Uhrzeit,,,,00,time,,BTI,,,,date,,BDA,,,,,,,,,
#b,,outsidetemp,Außentemperatur,,,,01,,,temp2,,,,,,,,,,,,,,,
#*b,broadcast,,,,FE,B505,,,,,,,,,,,,,,,,,,,
b,,hwcStatus,Status Warmwasser,,,,27,,,onoff,,,,VF1,,temp0,,,,,,onoff,,,
b,,load,Quick - WW Speicherladung,,,,06,,,onoff,,,,,,,,,
EDIT:
Habe 3 Zeile auskommentiert, dann geht's. "vdatetime" steht definitiv nicht in der 08.bai.HW7401.csv und muss trotzdem auskommentiert werden, Warum ?
Falls noch weitere Ausgaben benötigt werden:
ebusctl w -h 08b509022802
0402a71100
ebusctl w -h 08b509022803
0403ae0512
ebusctl w -h 08b5090124
09003231313232323030
ebusctl w -h 08b5090125
09313030303933353133
ebusctl w -h 08b5090126
09313030303035363736
ebusctl w -h 08b5090127
094e333c3c3c3c3c3c3c
Moin,
seit kurzem versuche ich mich auch an der Entschlüsselung von eBus in Verbindung mit Vaillant. Allerdings fehlt mir der richtige Ansatz. Mittlerweile habe ich etwa 1/3 dieses Threads durchgekämpft und probiert - scheitere jedoch leider an grundlegenden Dingen.
Installiert und in Betrieb sind:
- Vaillant flexoCOMPACT exclusive VWF 88/4
- Vaillant multiMATIC VRC 700
- Kompakt-Pufferspeicher VWZ MPS 40
Demnächst kommt noch folgendes Lüftungsgerät dazu:
- Vaillant reco VAR 360/4E - ebenfalls am eBus angeschlossen
Gerade die statistischen Funktionen sind in der WP/Steuerung, freundlich ausgedrückt, zu kurz gekommen, so dass ich mir meine eigenen Statistiken bauen möchte.
Am Bus hängen diese Geräte:
scan result
08;Vaillant;HMU00;0206;0403
15;Vaillant;70000;0110;2103
76;Vaillant;VWZ00;0206;0403
ec;Vaillant;70000;0110;2103
Ich denke, dass diese Reihenfolge der Aufstellung oben entspricht.
Gegen die Register/Statusabfragen scheint die Steuerung jedoch irgendwie "immun" zu sein:
write -h 15B509030D0100
00
write -h 15B509030D0200
00
write -h 15B509030D0300
00
write -h 15B509030D0400
00
etc.
write -h 15B5040100
00
write -h 15B5040101
00
write -h 15B5040102
00
write -h 15B5040103
00
etc
Das einzige was ich dem ganzen Kram bislang aktiv entlocken konnte war
write -h 08B5110101
092a40b004ff4e0400ff
Die sich daraus ergebenden Temperaturen für Vor-/Rücklauf etc passen.
Das Problem ist nun, dass ich Heizung und Steuerung bereits alle möglichen Anfragen an den Kopf geworfen habe, jedoch immer nur ein "00" zurückbekomme.
Ein grab hab ich bereits angeworfen und da ist sogar Aktion auf dem Bus. Hauptsächlich Broadcasts, aber nicht nur:
10feb516080059461223010616
10feb516080059511223010616
10feb516080059541223010616
10feb516080059541722010516
10feb516080059551324010716
10feb516080059551722010516
10feb516080059561722010516
10feb516080059571722010516
10feb516080059581722010516
10feb516080059591823010616
1008b516081000ffff02002120 / 0b0000ff0200372060c8564a
1008b516081002ffff0200811f / 0b0201ff0200811fc0216249
1076b51009000000ffffff010000 / 0101
1076b5110101 / 09ff51f004ff4f0000ff
1076b512030f0001 / 07b5020100801201
1076b512030f0201 / 0784020100801201
1076b512030f0202 / 077c020100801201
1076b51303040d00 / 02ffff
Die Steuerung scheint in der ganzen Kommunikation gar nicht aufzutauchen. Oder ist 1008 Kommunikation von der Steuerung an die Heizung? Denn im Status erscheint nicht nur die #15, sondern direkt davor auch die #10
info
version: ebusd 2.0.f5e218e
signal: acquired
symbol rate: 83
masters: 4
messages: 427
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=HMU00;SW=0206;HW=0403", loaded "vaillant/08.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0110;HW=2103", loaded "vaillant/15.70000.csv"
address 71: master #17
address 76: slave #17, scanned "MF=Vaillant;ID=VWZ00;SW=0206;HW=0403", loaded "vaillant/76.csv"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0110;HW=2103"
Wenn jemand eine gute Idee hat wo ich ansetzen kann meiner Steuerung/Heizung ein paar Werte zu entlocken, so helfe ich gern dabei eine passende CSV-Datei zu zimmern. Wenn das klappt im Anschluss gern auch für die Lüftung (wenn die läuft und jemand Interesse daran hat).
So long,
Thomas
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
Hallo John, hier bitte von meiner.
pi@raspberry2 ~ $ ebusctl w -h 08b509022802
0402a70b03
pi@raspberry2 ~ $ ebusctl w -h 08b509022803
0403ae0512
pi@raspberry2 ~ $ ebusctl w -h 08b5090124
09003231303931333030
pi@raspberry2 ~ $ ebusctl w -h 08b5090125
09313030303433343030
pi@raspberry2 ~ $ ebusctl w -h 08b5090126
09303031303035303536
pi@raspberry2 ~ $ ebusctl w -h 08b5090127
094e303c3c3c3c3c3c3c
LG
Reinhart
Die Systematik der Vaillant-Variante des EBUS sollte unabhängig vom ebusd dokumentiert werden. In dem anliegenden Dokument habe ich vor mehr als einem Jahr eine ganze Menge Änderungen vorgenommen, daran sollte man weiter arbeiten.
LG
pah
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl w -h 08b509022802
ebusctl w -h 08b509022803
ebusctl w -h 08b5090124
ebusctl w -h 08b5090125
ebusctl w -h 08b5090125
ebusctl w -h 08b5090127
Damit wird die genaue Version der BAI abgefragt.
Hi John,
hier meine Daten:
ebusctl scan result zeigt
08;Vaillant;BAI00;0113;9602;21;15;04;0010015596;3100;005190;N9Deine Befehle:
ebusctl w -h 08b509022802
060200010d2801
ebusctl w -h 08b509022803
0c030001003601004149424d55
ebusctl w -h 08b5090124
09003231313530343030
ebusctl w -h 08b5090125
09313030313535393633
ebusctl w -h 08b5090126
09313030303035313930
ebusctl w -h 08b5090127
094e393c3c3c3c3c3c3c
Gruß
Sven
Zitat von: R2D2_ am 24 Januar 2016, 12:46:51
Habe 3 Zeile auskommentiert, dann geht's. "vdatetime" steht definitiv nicht in der 08.bai.HW7401.csv und muss trotzdem auskommentiert werden, Warum ?
Ich kann nur vermuten, dass in dem /etc/ebusd Verzeichnis noch eine Datei liegt, die bereits entsprechende Definitionen enthält.
Schick mir doch bitte mal all Deine CSVs. Am besten zusammenpacken mit "tar czf ~/csvs.tgz /etc/ebusd".
Zitat von: Prof. Dr. Peter Henning am 24 Januar 2016, 14:49:34
Die Systematik der Vaillant-Variante des EBUS sollte unabhängig vom ebusd dokumentiert werden. In dem anliegenden Dokument habe ich vor mehr als einem Jahr eine ganze Menge Änderungen vorgenommen, daran sollte man weiter arbeiten.
Wenn ich das Prinzip der MDB richtig verstanden habe, dann gibt es für alle BAIs abhängig vom Ergebnis einer weiteren Abfrage (b509022802) noch deutlich detailliertere Nachrichten. Ich versuche zunächst mal, das rauszukitzeln.
Danach sollte einer Ergänzung der CSVs u.a. durch Deine Findings nichts mehr ím Wege stehen (ich meine, das ein oder andere ist davon auch schon berücksichtigt).
VG John
Zitat von: Pierce am 24 Januar 2016, 14:28:41
Das Problem ist nun, dass ich Heizung und Steuerung bereits alle möglichen Anfragen an den Kopf geworfen habe, jedoch immer nur ein "00" zurückbekomme.
Der Punkt ist, dass für die 700 noch gar nichts geklärt ist. Keine der CSVs passt dazu und insofern hilft hier nichts als probieren...
Ich meine für die HMU noch eine CSV zur Verfügung stellen zu können, muss ich mal nachschauen (es nicht alle CSVs sind im repository eingecheckt).
Zitat von: Pierce am 24 Januar 2016, 14:28:41
Die Steuerung scheint in der ganzen Kommunikation gar nicht aufzutauchen. Oder ist 1008 Kommunikation von der Steuerung an die Heizung? Denn im Status erscheint nicht nur die #15, sondern direkt davor auch die #10.
Lies mal hier: https://github.com/john30/ebusd/wiki/eBUS-background#addresses (https://github.com/john30/ebusd/wiki/eBUS-background#addresses)
Zitat von: Pierce am 24 Januar 2016, 14:28:41
Wenn jemand eine gute Idee hat wo ich ansetzen kann meiner Steuerung/Heizung ein paar Werte zu entlocken, so helfe ich gern dabei eine passende CSV-Datei zu zimmern. Wenn das klappt im Anschluss gern auch für die Lüftung (wenn die läuft und jemand Interesse daran hat).
Solltest Du das VR 900 haben, dann käme man vermutlich schneller vorwärts.
Ansonsten würde ich den Bus Traffic beobachten und dann im UI gezielt einzelne Werte manipulieren. Dann solltest Du recht gut erkennen können, was der Effekt davon auf dem Bus ist.
VG John
@amunra,de.jt,Reinhart,zentis666
Danke für Euer Feedback!
Zitat von: zentis666 am 24 Januar 2016, 19:51:07
ebusctl scan result zeigt
08;Vaillant;BAI00;0113;9602;21;15;04;0010015596;3100;005190;N9
ebusctl w -h 08b509022802
060200010d2801
ebusctl w -h 08b509022803
0c030001003601004149424d55
Gratulation zu dieser jungen Anlage! :-)
Da ist natürlich wieder alles ganz anders als bei den älteren... zum Durchdrehen!!
ZitatDa ist natürlich wieder alles ganz anders als bei den älteren... zum Durchdrehen!!
Wenn Vaillant so weiter macht, manövrieren die sich damit in eine in der Software nicht mehr wartbare Anlagenvielfalt.
LG
pah
Vielen Dank John, die Hintergrundinfos zum eBus bringen schonmal ein wenig mehr Licht ins Dunkel.
Ein VR 900 habe ich. Hatte ich auch schon angeschlossen und die Vaillant-App drauf losgelassen. Diese App war dann der Meinung, dass an dem Bus keinerlei Gerät hängen würde. Ebusd sagt mir da aber was anderes. Und die Kommunikation aller Geräte untereinander funktioniert ja auch. Ich werde das VR 900 nochmal ranhängen und schauen was passiert.
Über die CSV zur HMU würde ich mich freuen. Jede Art von Denkanstoß würde mir helfen. Derzeit habe ich ausschliesslich Interesse daran Daten auszulesen. Und die nehme ich lieber aus der Heizung als aus der Steuerung. Mindestens was den Stromverbrauch angeht lügt mich die Steuerung an (0 kWh zusätzlicher Verbrauch innerhalb von 24 Stunden, obwohl die Heizung nachweislich lief). Andere Werte (zB aktuelle Rücklauftemperatur) habe ich in der Steuerung nirgends gefunden, in der Heizung schon.
Parallel dazu werde ich meinen Vaillant-Regions-Verkaufsberater mal anquatschen, der die Heizung auch mit in Betrieb genommen hat. Vielleicht kann er mir irgendwas besorgen. Ich denke die Protokoll-Spezifikation für das 700 wird er mir nicht geben (können). Aber vielleicht was anderes. Gibt es etwas, was helfen könnte und wonach ich ihn direkt fragen kann?
Zitat von: john30 am 25 Januar 2016, 08:21:45
Ansonsten würde ich den Bus Traffic beobachten und dann im UI gezielt einzelne Werte manipulieren. Dann solltest Du recht gut erkennen können, was der Effekt davon auf dem Bus ist.
Mit beobachten meinst du grab/ grab result? Hab da schon viele "B511"er - "B516"er gesehen. Bin mir nur nicht ganz sicher wie ich mit den Infos weiter vorgehen sollte. Ich möchte verhindern irgendwas zu zerschiessen. Und zwischen lesen und schreiben liegt ja nur ein bit (0D vs 0E).
Ein paar Schleifen laufen zu lassen, den Bus zu penetrieren um das Ergebnis auszuwerten sollte ich hinbekommen. Hab auf diese Art und Weise vor vielen Jahren die ASN.1-Kodierung entschlüsselt und einen Encoder/Decoder geschrieben - bevor ich das RFC und die M$-DLL dazu gefunden habe :/
Thnx
Thomas
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl w -h 08b509022802
ebusctl w -h 08b509022803
ebusctl w -h 08b5090124
ebusctl w -h 08b5090125
ebusctl w -h 08b5090125
ebusctl w -h 08b5090127
Damit wird die genaue Version der BAI abgefragt.
Hallo John,
folgend mein Ergebnis:
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
localhost: w -h 08b509022802
0402d10304
localhost: w -h 08b509022803
0403ae0703
localhost: w -h 08b5090124
09003231313334323030
localhost: w -h 08b5090125
09313030303431323130
localhost: w -h 08b5090127
094e3300000000000000
Zitat von: Pierce am 25 Januar 2016, 12:32:58
Ein VR 900 habe ich. Hatte ich auch schon angeschlossen und die Vaillant-App drauf losgelassen. Diese App war dann der Meinung, dass an dem Bus keinerlei Gerät hängen würde. Ebusd sagt mir da aber was anderes. Und die Kommunikation aller Geräte untereinander funktioniert ja auch. Ich werde das VR 900 nochmal ranhängen und schauen was passiert.
Also wenn Du den VR 900 anschließt, solltest Du unbedingt darauf achten, nicht die gleiche Adresse im ebusd zu verwenden. Das führt nämlich dazu, dass beide nicht mehr so richtig funktionieren, weil sie sich um den Buszugriff streiten und jeder denkt, er wäre jetzt an der Reihe.
Du kannst ebusd einfach mit "-a QQ" eine andere Master-Addresse zuweisen, bspw. "-a F7", siehe https://github.com/john30/ebusd/wiki/2.-Run#ebus-options (https://github.com/john30/ebusd/wiki/2.-Run#ebus-options). Wenn Du danach den VR 900 nochmal startest, sollte er wieder die Geräte finden.
Zitat von: Pierce am 25 Januar 2016, 12:32:58
Über die CSV zur HMU würde ich mich freuen. Jede Art von Denkanstoß würde mir helfen. Derzeit habe ich ausschliesslich Interesse daran Daten auszulesen. Und die nehme ich lieber aus der Heizung als aus der Steuerung. Mindestens was den Stromverbrauch angeht lügt mich die Steuerung an (0 kWh zusätzlicher Verbrauch innerhalb von 24 Stunden, obwohl die Heizung nachweislich lief). Andere Werte (zB aktuelle Rücklauftemperatur) habe ich in der Steuerung nirgends gefunden, in der Heizung schon.
Dann schick mir doch mal Deine Mail Adresse per PN. Komme aber erst am WE dazu.
Zitat von: Pierce am 25 Januar 2016, 12:32:58
Parallel dazu werde ich meinen Vaillant-Regions-Verkaufsberater mal anquatschen, der die Heizung auch mit in Betrieb genommen hat. Vielleicht kann er mir irgendwas besorgen. Ich denke die Protokoll-Spezifikation für das 700 wird er mir nicht geben (können). Aber vielleicht was anderes. Gibt es etwas, was helfen könnte und wonach ich ihn direkt fragen kann?
Den würd ich an Deiner Stelle lieber mal nicht zu sehr damit behelligen, denn es ist davon auszugehen, dass der Hersteller jegliche Garantieleistungen verweigert, wenn er den Anschluss eines unbekannten Geräts an den Bus entdeckt...
Zitat von: Pierce am 25 Januar 2016, 12:32:58
Mit beobachten meinst du grab/ grab result? Hab da schon viele "B511"er - "B516"er gesehen. Bin mir nur nicht ganz sicher wie ich mit den Infos weiter vorgehen sollte. Ich möchte verhindern irgendwas zu zerschiessen. Und zwischen lesen und schreiben liegt ja nur ein bit (0D vs 0E).
Ich habe mir immer den exakten Zeitpunkt der Änderung am controller notiert und dann im ebusd Log geschaut, was da so vorbei gepurzelt kam.
VG John
Zitat von: john30 am 25 Januar 2016, 08:28:31
@amunra,de.jt,Reinhart,zentis666
Danke für Euer Feedback!
Gratulation zu dieser jungen Anlage! :-)
Da ist natürlich wieder alles ganz anders als bei den älteren... zum Durchdrehen!!
Danke. Die Anlage wurde im Juni verbaut, hat auch schon ein Firmware Update
hinter sich nachdem die Anlage angefangen hat zu spinnen
und irgendwelche Sensorfehler angezeigt hat.
Das csv, was Du mit dem config-Paket auslieferst, funktioniert schon recht gut,
die ganzen Standard-Temperaturen, Druck, Heizkurve geht alles,
nur das setzen mancher Parameter wie "Speicher laden" funzt nicht so wie bei den älteren,
hatten wir ja schon weiter oben.
Wenn Du noch Infos brauchst oder was getestet haben willst sag einfach Bescheid,
Gruß
Sven
Hallo john30,
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl....
Damit wird die genaue Version der BAI abgefragt.
ist das noch für Dich (und damit ja dann für uns, danke Dir :-) ) wichtig?
Hier meine Daten:
ebusctl scan result:
08;Vaillant;BAI00;0113;9602;21;15;04;0010015600;3100;005192;N4
15;Vaillant;47000;0420;1403;21;14;51;0020171280;0082;063419;N4
26;Vaillant;47000;0420;1403;21;14;51;0020171280;0082;063419;N4
ebusctl w -h 08b509022802
060200010d2801
ebusctl w -h 08b509022803
0c030001003601004149424d55
ebusctl w -h 08b5090124
09003231313530343030
ebusctl w -h 08b5090125
09313030313536303033
ebusctl w -h 08b5090126
09313030303035313932
ebusctl w -h 08b5090127
094e343c3c3c3c3c3c3c
VG,
sua
Hi John
hier meine Antworten:
der Scan unter EBUSD 1.1.0:
08;Vaillant;BAI00;0703;7401
15;Vaillant;47000;0126;6002
ebusctl w -h 08b509022802
0402d10304
ebusctl w -h 08b509022803
0403ae0703
ebusctl w -h 08b5090124
09003231313133393030
ebusctl w -h 08b5090125
09313030303431323330
ebusctl w -h 08b5090126
09303036303035373136
ebusctl w -h 08b5090127
094e3500000000000000
[/code}
Grüße
Christsian
Hey John,
das VR 900 tut mittlerweile seinen Dienst. Keine Ahnung warum es damals nicht funktioniert hatte. Auf dem eBus taucht es als COM00 auf.
Mittlerweile scheine ich auf einen Zweig in der Steuerung gestoßen zu sein, der durch Verändern eines bestimmten Bytes in der Abfrage (15b52406020003000100) immer neue Werte ausspuckt:
write -h 15b52406020003000100
06020301000100
write -h 15b52406020003000200
08020302000000c041
write -h 15b52406020003000300
070303030001010f
Hier werde ich nun einmal ein Schleifchen drüber laufen lassen, hier und da in der Steuerung was ändern und schauen was ich aus den Antworten so rauslesen kann.
Bis dahin
Thomas
Zitat von: Pierce am 26 Januar 2016, 00:29:22
das VR 900 tut mittlerweile seinen Dienst. Keine Ahnung warum es damals nicht funktioniert hatte. Auf dem eBus taucht es als COM00 auf.
Trotzdem bitte ebusd nicht auf Adresse ff laufen lassen, die kommen sich sonst permanent ins Gehege!
Ich werde in der nächsten Version die default Adresse von ebusd auf etwas anderes setzen, da vrdialog immer auf ff (master) und 04 (slave) liegt.
Zitat von: Pierce am 26 Januar 2016, 00:29:22
Mittlerweile scheine ich auf einen Zweig in der Steuerung gestoßen zu sein, der durch Verändern eines bestimmten Bytes in der Abfrage (15b52406020003000100) immer neue Werte ausspuckt:
Ja, mit dem neuen Controller hat sich der Hersteller mal wieder ein neues Format zur Übertragung ausgedacht. Clever, was? :-\
Zitat von: R2D2_ am 25 Januar 2016, 17:46:20
Im Anhang die Dateien ... PN folgt ;)
In Deiner broadcast.csv (in /etc/ebusd) sind halt Einträge drin, die da nicht reingehören (vaillant spezifisch).
Ich weiß jetzt nicht, was das für ein Mischmasch an CSVs ist und hab nicht die Zeit, das im Detail rauszufinden.
Bitte entweder den Stand aus dem ebusd-configuration repository nutzen oder ansonsten schweigen ;-)
Zitat von: R2D2_ am 26 Januar 2016, 19:28:13
@john: welche broadcast.csv ist wichtig ?
- die in /etc/ebusd ?
- die in /etc/ebusd/vaillant ?
Die CSVs in den Verzeichnissen sind hierarchisch aufgebaut, d.h. alles in /etc/ebusd direkt wird beim Starten von ebusd sofort eingelesen und hat sozusagen globale Gültigkeit.
Deshalb ist es ungünstig, in die /etc/ebusd/broadcast.csv Hersteller spezifische Sachen einzubauen.
Diese sollten dann besser im entsprechenden Unterverzeichnis abgelegt werden, also hier /etc/ebusd/vaillant/broadcast.csv.
@R2D2: das klingt plausibel und nachvollziehbar und irgendwie genial ;) , ich komme aber leider erst am Wochenende dazu, mal bei mir zu schauen, melde mich dann
Grüße
Christian
Zitat von: john30 am 24 Januar 2016, 11:49:13
Könntest Du mir bitte die Ausgabe folgender Kommandos schicken:
ebusctl w -h 08b5090124
ebusctl w -h 08b5090127
...die Ausgaben:
ebusctl w -h 08b5090124
09003231313332313030
ebusctl w -h 08b5090125
09313030303933353133
ebusctl w -h 08b5090127
094e303c3c3c3c3c3c3c
ebusctl w -h 08b509022802
0402a71201
ebusctl w -h 08b509022803
0403ae0512
Beste Grüße,
Andreas.
@R2D2: Beobachte die Zähler PrEnergyCount, PrEnergySum.
Bei meiner Anlage zählt der Hc1, wenn geheizt wird und der Hwc1, wenn der Puffer geladen wird (gelegentlich auch geringfügig, wenn die Therme zum Heizen startet).
Der Verbrauch lässt sich in Relation zum Gaszähler wie folgt grob ermitteln.
Man notiert die entsprechenden Zähler (Hc_a, Hwc_a, Gasz_a) und bildet nach einer ausreichenden Zeit die Differenz.
x*Hc _d + y*Hwc_d = Verbrauch_d.
Da 2 Variable zu bestimmen sind, wäre jeweils eine Messung mit nur einem Verbraucher notwendig (ist erst im Sommer für Hwc möglich). (Oder bekommt man den Verbrauch über die aktuelle Leistung heraus? Habe ich bei meiner Therme nicht gefunden.)
Bei PrEnergyCount weichen x und y sehr stark von einander ab.
Bei PrEnergySum scheinen x und y fast gleich zu sein. Ich habe mir daher aus der Messung einen Faktor ermittelt und zeige den Zählerstand, Verbrauch in einem reading an.
@jkriegl
ZitatOder bekommt man den Verbrauch über die aktuelle Leistung heraus?
Das ist genau das Problem, welches wir versuchen über D.29 (tatsächlicher Volumenstrom) herauszubekommen, denn die Therme misst die Leistung nicht direkt. Aber aus der Differenz von Vor- und Rücklauf und dem Volumenstrom könnten wir die tatsächlich aktuell abgegebene Leistung berechnen. Daher ist der Wert so interessant für uns. Den Verbrauch messe ich ganz einfach über einen Reedkontakt, der am Gaszähler an der dafür vorgesehenen Stelle unter dem Zählwerk angebracht wird und an die GPIOs angeschlossen wird und in FHEM geloggt wird.
Grüße
Christian
Vorsicht, der Wirkungsgrad kann sehr stark von der Primärleistung abhängen - insbesondere bei Brennwertgeräten. Das Ziel einer Energieeinsparung ohne Komfortverlust liegt eben nicht in der Minimierung des Brennstoffverbrauchs - sondern in der Maximierung des Wirkungsgrades.
Nachdem ich eine ziemlich zeitintensive Aufgabe erledigt habe, werde ich hier jetzt auch wieder richtig einsteigen.
LG
pah
Guten Abend!
Ich bin die Marie, bin neu hier und bräuchte bitte eure Hilfe.
Ausgangslage: Vaillant Gastherme, Rasperry mit aktuellem ebusd sowie original vr-dialog koppler.
Wie bekomme ich den original Koppler von Vaillant mit dem ebusd verheiratet? TTYUSB* wird nicht erzeugt.
lsusb:
Bus 001 Device 006: ID 1482:1005 Vaillant VRD PC-Interface
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Brauche ich hier noch irgendeinen zus. Treiber? Wenn ich ein FTDI Interface ranhänge, wird das sofort erkannt.
Habt ihr eine Idee? Ich wäre euch unendlich dankbar :-)
Marie :P
Zitat von: john30 am 24 Januar 2016, 12:00:14
Es wär cool, wenn mir ein Besitzer einer BAI die Ausgabe folgender Befehle zukommen lassen könnte:
ebusctl w -h 08b509022802
ebusctl w -h 08b509022803
ebusctl w -h 08b5090124
ebusctl w -h 08b5090125
ebusctl w -h 08b5090125
ebusctl w -h 08b5090127
Damit wird die genaue Version der BAI abgefragt.
Hallo John,
etwas verspätet aber evtl. kannst Du es ja auch noch gebrauchen.
pi@raspberrypi:~ $ ebusctl w -h 08b509022802
0402ff0604
pi@raspberrypi:~ $ ebusctl w -h 08b509022803
0c030003020101004149424d55
pi@raspberrypi:~ $ ebusctl w -h 08b5090124
09003231313434303030
pi@raspberrypi:~ $ ebusctl w -h 08b5090125
09313030313136343230
pi@raspberrypi:~ $ ebusctl w -h 08b5090125
09313030313136343230
pi@raspberrypi:~ $ ebusctl w -h 08b5090127
094e313c3c3c3c3c3c3c
Gruß Frank
Zitat von: Marie01 am 31 Januar 2016, 19:13:10
Wie bekomme ich den original Koppler von Vaillant mit dem ebusd verheiratet? TTYUSB* wird nicht erzeugt.
Hallo Marie,
da müsstest Du einen Treiber schreiben, so dass das Gerät als serielle Schnittstelle auftaucht.
Also eher ein größeres Unterfangen...
VG John
Hallo John!
Vielen lieben Dank für deine Antwort :-*
Das heisst, ich kann das vr-dialog mit ebusd nicht betreiben? Oder kannst du mir vielleicht einen Treiber schreiben? *ganzliebschau*
Danke.
Marie
Zitat von: Marie01 am 01 Februar 2016, 09:30:03
Das heisst, ich kann das vr-dialog mit ebusd nicht betreiben? Oder kannst du mir vielleicht einen Treiber schreiben? *ganzliebschau*
genau, dieses Interface geht adhoc nicht mit ebusd.
Treiber schreiben ist nichts, was man mal schnell erledigen kann. Dafür hab ich keine Zeit...
VG John
Ok, trotzdem danke.
Also muss ich doch mit dem eBus Ethernet Koppler von E-Service arbeiten :o
Zitat von: Marie01 am 01 Februar 2016, 09:39:43
Also muss ich doch mit dem eBus Ethernet Koppler von E-Service arbeiten :o
Oder Du lässt Dir ein Selbstbauinterface von jemand löten, siehe hier: http://forum.fhem.de/index.php?topic=45127 (http://forum.fhem.de/index.php?topic=45127)
Das habe ich erst gesehen, als ich den Ebus Koppler schon zuhause hatte :(
Ich werde heute Abend versuchen den Koppler anzuschließen. Kann ich einfach die 2 Drähte die von der Therme zum Bedienteil gehen "anzapfen"?
Zitat von: Marie01 am 01 Februar 2016, 09:59:17
Das habe ich erst gesehen, als ich den Ebus Koppler schon zuhause hatte :(
Ich werde heute Abend versuchen den Koppler anzuschließen. Kann ich einfach die 2 Drähte die von der Therme zum Bedienteil gehen "anzapfen"?
Hallo Marie,
so wird es gemacht. Die Klemmen sind mit Bus bezeichnet.
Gruß Frank
Halli Hallo!
Hab ich genauso gemacht - danke :-)
Also habe ich jetzt den Ebus Koppler Ethernet mit Strom versorgt, mit dem Ebus verbunden und auch richtig konfiguiert als TCP/IP Server mit einer fixen IP-Adresse.
Wenn ich jetzt via SSH auf den Raspberry gehe und folgenden Command eingebe:
ebusd -f -l ALL -d 192.168.178.31:5000 -p 8888
Bekomme ich immer:
2016-02-01 20:18:00.865 [main notice] ebusd 2.0.0ea7efc started
2016-02-01 20:18:00.869 [main notice] found messages: 8 (0 conditional on 0 conditions, 0 poll, 6 update)
2016-02-01 20:16:19.069 [bus error] unable to open 192.168.178.31:5000: ERR: generic I/O error
Ich weiß nicht, was hier falsch läuft. Habt ihr eine Idee?
Danke
:-*
Edit:
Was mir noch aufgefallen ist, am Koppler blinkt/leuchtet die gelbe Data LED nicht. Die oberen LEDs (Ebus angeschlossen) leuchten aber.
Liegt es vielleicht an en angeschlossenen Kabeln? Die haben einen dickeren Querschnitt als die Kabel die zum Bedienteil gehen.
Kann es daran liegen, dass ich mich direkt zwischen Bedienteil und Platine geklemmt habe?
Ich habe noch so einen Verbindungsadapter von einem ComDialog Plus hier rumliegen gehabt. Das wird genau zwischen dem Bedienteil eingeklemmt.
Diese 2 Litzen habe ich jetzt direkt an den Koppler angeschlossen. Beim ersten Kontakt blinkt die Data LED kurz aber dann macht sie nichts mehr :(
@Marie01: Bitte für diese Fragen einen eigenen Thread aufmachen - das ist eine komplett andere Hardware.
LG
pah
Zitat von: Marie01 am 01 Februar 2016, 22:22:26
Kann es daran liegen, dass ich mich direkt zwischen Bedienteil und Platine geklemmt habe?
Ich habe noch so einen Verbindungsadapter von einem ComDialog Plus hier rumliegen gehabt. Das wird genau zwischen dem Bedienteil eingeklemmt.
Diese 2 Litzen habe ich jetzt direkt an den Koppler angeschlossen. Beim ersten Kontakt blinkt die Data LED kurz aber dann macht sie nichts mehr :(
Hallo Marie,
geh mal in den Thread ebus Schaltung in Betrieb nehmen.
Dort findest Du alles was Du jetzt noch benötigst.
Und hier im Wiki : http://www.fhemwiki.de/wiki/EBUS#Software
Gruß Frank
Ich möchte das Logging abstellen. Bisher steht in /etc/init.d/ebusd:
EBUSD_OPTS="-d /dev/ttyUSB0 --scanconfig"
Einfch erweitern mit
log level error
also ?
EBUSD_OPTS="log level error -d /dev/ttyUSB0 --scanconfig"
Zitat von: R2D2_ am 02 Februar 2016, 19:57:07
Ich möchte das Logging abstellen. Bisher steht in /etc/init.d/ebusd:
EBUSD_OPTS="-d /dev/ttyUSB0 --scanconfig"
Einfch erweitern mit
log level error
also ?
EBUSD_OPTS="log level error -d /dev/ttyUSB0 --scanconfig"
warum nicht einfach lesen (https://github.com/john30/ebusd/wiki/2.-Run#log-options) und ausprobieren -> sollte nicht allzu schwierig sein.
--loglevel=LEVEL
... hatte ich nicht gesehen, lediglich die anderen Parameter.
Zitat von: R2D2_ am 02 Februar 2016, 19:57:07
Ich möchte das Logging abstellen. Bisher steht in /etc/init.d/ebusd:
warum in aller Welt willst du das Log abstellen, das hilft dir doch bei einer Fehlersuche/Diagnose?
Wenn du Logrotate richtig konfigurierst wird das auch nicht anwachsen!
LG
Ich hatte vor einiger Zeit was über d.29 rausgefunden. Keiner hier unterwegws der daran Interesse hat ? und das mal nachprüfen kann ?
Zitat von: john30 am 19 Dezember 2015, 14:10:51
Versuch mal "w -h 08b509030dfb00" und teile das Ergebnis durch 100.
Wenn da sowas ähnliches wie der angezeigte d.29 Wert rauskommt, wäre mal Dein scan result interessant :-)
VG John
Folgendes habe ich rausgefunden:
Max. Durchfluss bei WW-Erzeugung an meiner Therme 1,02 m³/h, passende Hex-Werte von 0x0720 - 0x72E entspricht (1824 - 1838)dez.
Ausgehend vom max. Wert des Durchflusses (1,02) und dem Mittelwert der dazu ausgelesenen ebus-Daten (1830) resultiert:
1,02 - (((1830-X) / 2) / 1000) = akt. Durchfluss
X entspricht dem Mittelwert der ausgelesenen ebus-Daten (d.29) des Heizkreises , je nach Ventilöffnungen.
0,84 m³/h, passende Hex-Werte von 0x05AC - 0x05BE entspricht (1452-1470)dez.
0,78 m³/h, passende Hex-Werte von 0x0532 - 0x0539 entspricht (1330-1337)dez.
Meine Rechnung für 0,84 m³/h und 0,78m³/h:
1,02 - (((1830 - 1460) / 2) / 1000 ) = 0,835 --> Anzeige 0,84
1,02 - (((1830 - 1335) / 2) / 1000 ) = 0,772 --> Anzeige 0,78
Vielleicht kann das mal jemand testen, hatte noch keine Zeit für weitere Durchflussmengen einzustellen.
sorry, hab das letztes WE nicht gepackt, habs mir für morgen vorgenommen, mal ein paar Einstellungen zu probieren. Melde mich, wenn ich was hab
Grüße
Christian
@christian: Du wirst doch nicht der einzige sein hier ?
Vielleicht können sich diejenigen mal melden, die das schon sein Monaten am Laufen haben ...
Hi R2D2,
hier meine Werte. Ich kann leider nur über D.14 die Solleistung rauf und runter drehen, dabei ändert sich der Volumenstrom aber nicht so doll, wie erwartet. Wir bräuchten jemanden, der über eine Drossel weiter runter drosseln kann...
D.29 / EBUSD:
0,90 /02f705
0,90 / 02f305
0,90 / 02f505
0,96 / 029506
0,96 / 028c09
1,02 / 020607
1,02 / 020307
1,02 / 020c07
und bei Heisswasserbereitung
1,08 / 024a07
bin nur noch nicht dazu gekommen, die hex in dez zu wandeln.
Kannst Du da was mit anfangen ?
Grüße
Christian
Nimm für jeden Durchfluss mind. 10 Werte und rechne doch einfach mit vorheriger Formel nach.
TIPP in Excel:=HEXINDEZ()
Hast Du keine Heizkörper ? Wenn Du die nacheinander zudrehst gibt's weitere Werte. ;)
Hallo,
das passt nicht, egal wie ich die hex auflöse, es ist immer so, dass sich bei D.29 sortiert keine Sortierung bei den Ebusd-Werten ergeben, sondern die sind durcheinander... Sorry
Zitat von: cs-online am 09 Februar 2016, 08:45:33
das passt nicht, egal wie ich die hex auflöse, es ist immer so, dass sich bei D.29 sortiert keine Sortierung bei den Ebusd-Werten ergeben, sondern die sind durcheinander... Sorry
Moment... die von Dir oben geposteten Werte stimmen doch grob mit R2D2s Beobachtungen?!
Zur Erinnerung: die 02 ist die Länge der Antwort, die beiden Bytes in umgekehrter Reihenfolge:
0,90 / 02f305 --> 0x05f3 = 1523
1,08 / 024a07 --> 0x074a = 1866
(bei "0,96 / 028c09" vermute ich einen Schreibfehler, war es evtl. "0,96 / 028c06"?)
Zitat von: R2D2_ am 06 Februar 2016, 19:12:58
0,84 m³/h, passende Hex-Werte von 0x05AC - 0x05BE entspricht (1452-1470)dez.
0,78 m³/h, passende Hex-Werte von 0x0532 - 0x0539 entspricht (1330-1337)dez.
Meine Rechnung für 0,84 m³/h und 0,78m³/h:
1,02 - (((1830 - 1460) / 2) / 1000 ) = 0,835 --> Anzeige 0,84
1,02 - (((1830 - 1335) / 2) / 1000 ) = 0,772 --> Anzeige 0,78
Also irgendein Zusammenhang besteht hier offensichtlich - aber Faktor und Offset scheint anders zu sein. Und/oder geräteabhängig.
Auch bei Christians Werten habe ich nicht sofort etwas passendes gefunden. Sowohl mit Divisor 2000 als auch 2048 kommt man zwar auf "ungefähr" richtige Werte - aber schon bei Deinem Beispiel ist unklar, warum die in beiden Fällen aufgerundet wird. UND: Bei Christian scheint der Maximalwert nicht 1,02 zu sein...
Bei meiner Ölheizung bekomme ich nur 020000 als Antwort und es gibt auch (soweit ich mich erinnere) kein D.29. Daher reine Vermutung: wenn es um den Durchfluss geht - wird evtl. die Temperatur mit berücksichtigt??
Zitat von: Sven77Bei Christian scheint der Maximalwert nicht 1,02 zu sein...
Der Wert ist auch "1,08" während der WW-Erzeugung an seiner Heizung.
Zitat von: Sven77Divisor 2000 als auch 2048
Das hat nix dem binärsystem zu tun.
/1000 -> Umrechnung im m³
/2 -> war mir aufgefallen, da immer die Hälfte der Differenz zwischen dem ersten gemessenen Wert und einem zweiten Wert den Unterschied ausmacht
Zitat von: Sven77UND: Bei Christian scheint der Maximalwert nicht 1,02 zu sein...
Daher hatte ich auch geschrieben:
Zitat von: R2D2_Ausgehend vom max. Wert des Durchflusses (1,02) und dem Mittelwert der dazu ausgelesenen ebus-Daten (1830) resultiert:
1,02 - (((1830-X) / 2) / 1000) = akt. Durchfluss
X entspricht dem Mittelwert der ausgelesenen ebus-Daten (d.29) des Heizkreises , je nach Ventilöffnungen.
Zitat von: Sven77warum die in beiden Fällen aufgerundet wird
Das sind in meinem Beispiel 5 Liter/h bzw. 8Liter/h von im Schnitt durchlaufenden 780-840 Litern/h, also gerade mal 1%
@christian:
Die Werte passen, würden aber genauer, wenn mehr Werte für einen Durchschnitt zu bilden vorhanden wären.
Ich habe mit seinen Werten:
Anzeige - Berechnet
0,90 - 0,9095
0,96 - 0,987
1,02 - 1,015
Wer das nachprüfen möchte, bitte mind. 10 Werte auf dem eBus lesen; jeweils pro eingestelltem, konstanten Duchfluss an den Heizkreisverteilern oder Heizkörpern.
So, dank Reinharts tatkräftiger Unterstützung (nochmals Danke an ihn!) kann ich jetzt auch mit meiner Gas-Therme kommunizieren.
Es handelt sich um eine CGB-2-14 von Wolf mit BM2-Bedienmodul am ebus. Das System scheint überaus geschwätzig zu sein und zahlreiche Messages sind wohl noch nicht in den csv-Files übersetzt; es gibt aber auch zahlreiche Klartext-Meldungen, an deren Auswertung ich mich die Tage machen will.
Beim Filtern des ebus-Logfiles auf Fehlermeldungen ist mir aber schon aufgefallen, dass die Therme (oder wer auch immer) in regelmäßigen Abständen "update broadcast error"-Nachrichten sendet. Hier ein Auszug aus dem Log (mit grep -i error):
2016-02-09 18:18:31.841 [update notice] update broadcast error QQ=03: E000 18:17
2016-02-09 18:23:32.281 [update notice] update broadcast error QQ=03: E000 18:22
2016-02-09 18:28:32.848 [update notice] update broadcast error QQ=03: E000 18:27
2016-02-09 18:33:33.301 [update notice] update broadcast error QQ=03: E000 18:32
2016-02-09 18:38:33.838 [update notice] update broadcast error QQ=03: E000 18:37
Ist schon jemand dahinter gekommen, was das bedeuten mag?
Gruß
alpha1974
@R2D2:
so ganz hab ich noch nicht geblickt, wie Du von der Hex auf die berechneten Werte kommst, hab gestern da rauf und runter mit allen möglichen Zerlegungen und Additionen / Multiplikationen etc. und nie kam da was sinnvolles bei rum...
Muss das die Tage nochmal mit mehr Werten machen, aber vor dem Wochenende komm ich da sicher nicht zu.
Die kleine Ungenauigkeit wäre für mich OK, ich will halt nur die ca. Momentanleistung berechnen und loggen können um z.B. die max Leistung besser einstellen zu können und weil ich einfach neugierig bin ;)
Es bleibt spannend :)
Grüße
Christian
Zitat von: R2D2_ am 09 Februar 2016, 18:27:15Das hat nix dem binärsystem zu tun.
/1000 -> Umrechnung im m³
/2 -> war mir aufgefallen, da immer die Hälfte der Differenz zwischen dem ersten gemessenen Wert und einem zweiten Wert den Unterschied ausmacht
Nun, das ist schon klar - wenn man sich aber die in ebusd eingebauten Datentypen ansieht, stellt man fest dass sowohl 2 (dann eben für dm³) oder 2048 gängige Divisoren sind.
Letztlich wollte ich auch nur davor warnen, zu schnell eine Formel zu entwickeln, die dann ggf. von noch unbekannten Faktoren abhängt und somit der Fehler irgendwann größer wird. Für eine simple Grafik, wann Leistungsspitzen oder Ruhephase auftreten, dürfte es wohl hinreichend genau sein, ja...
@christian:
0x05F5 = 1525 (Mittelwert aus den 3 Werten 0x05F3 - 0x05F5 - 0x05F7 --> 0x05F5, für 0,90)
0x074A = 1855 (für 1,08)
1,08 - (((1866 - 1525) / 2 ) / 1000 ) = 1,08 - 0,1705 = 0,9095
Möglicherweise ist der Ansatz mit dem Mittelwert noch zu ungenau (betrifft jetzt zufällig nicht o.g. Rechnung), da die Werte sehr schwanken (+- 8 Liter/h). Eine Berechnung der Normalverteilung könnte den Fehler nochmal
minimieren. Aber da gibt's bestimmt Spezialisten hier ;)
Nix Normalverteilung, das ist doch keine Zufallsgröße !
Gefragt ist hier ein gleitender Mittelwert, siehe dazu meinen Beitrag im Fhemwiki.
LG
pah
hallo,
würde mich PAH anschliessen. Und muss mich leider auch korrigieren, denn zum einen hab ich tatsachlich bei dem einen Wert von 0,96 eine 6 am Ende auf dem Zettel gehabt und zum zweiten: wenn ich meine 1,02 als Basis nehme, dann passen die Werte bis auf die 2. Nachkommastelle ! Nur die 1,08 weicht etwas ab...
Sehr cool und Super Leistung lieber R2D2 !!!
Werde die Tage noch weitere Messreihen aufnehmen, dazu werde ich erstmal besser drosseln müssen, um eine grössere Spreizung zu bekommen. Denke wir sind auf einem guten Weg, danke !!!
Grüsse Christian
ZitatGefragt ist hier ein gleitender Mittelwert,
äh, ja :-[ ... wäre ein Ansatz ... ;) :D
Ja, vermutlich wird die Therme das intern über einen gleitenden Mittelwert über n Messungen gleitend darstellen. Wahrscheinlich müßte man bei den Aufnahmen dann auch den Median nehmen, weil der weniger ausreissergefährtet ist. Aber die Ungenauigkeiten in Summe werden für unsere Zwecke mehr als genau sein. Nur: Je weiter wir Richtung Null kommen, umso ungenauer wird das. Mit der Formel von Dir bekomme ich bei Null Volumenstrom (weil auf Nachtabsenkung ist die Pumpe aus) 0.121 m³/h... Evtl. brauchen wir da noch einen Korrekturfaktor / Offset. Aber im oberen Bereich trifft die recht gut.
Grüße
Christian
Ab nächsten Dienstag habe ich endlich wieder etwas Zeit, dann werde ich endlich von der Uralt-Version des ebusd auf eine der neueren umstellen. Natürlich erst an einem 2. Buskoppler...
Dann sehe ich mir das Thema mal an.
Meine Vermutung ist, dass diese Datenlage auch mit der Art der Messung zu tun hat - nämlich über einen Vortex-Sensor. Schaut Euch mal dessen Messprinzip an.
LG
pah
Guten Morgen!
Ich muss mich hier noch einmal zu Wort melden und brauch von euch Experten Hilfe :'(
Ausgangslage:
- VWL 102/3 s
- Raspberry mit Jessie
- neueste ebusd Version samt Configuration
- eBus Koppler Ethernet von E-Service
Meine Wärmepumpe von Vaillant besteht aus folg. Komponenten:
- Innengerät mit integrierten WW-Speicher
- Bedienteil
- Außengerät mit Wärmetauscher und Lüfter
Mittlerweile funktioniert mein ebusd. Ich kann Werte lesen und schreibe. Einziges Problem, ich bekomme das Außengerät (Busadresse 0xE0) nicht gescannt.
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 45
masters: 3
messages: 632
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
Was habe ich in der Zwischenzeit schon verändert/probiert:
- Poti mehrmals justiert (feinjustiert) mit der Hoffnung, dass 0xE0 dann gescannt wird
- ebusd Verkabelung direkt auf die Reglerplatine (Ebus-Klemme) geklemmt
- Aktive Meldungen vom Bedienteil an das Außengerät geschickt und mit ebusctl scan full und dann ebusctl scan result kontrolliert ob der Busteilnehmer vorkommt
Habt ihr noch eine Idee was ich machen kann?
Danke.
Marie
Zitat von: cs-onlineMit der Formel von Dir bekomme ich bei Null Volumenstrom (weil auf Nachtabsenkung ist die Pumpe aus) 0.121 m³/h... Evtl. brauchen wir da noch einen Korrekturfaktor / Offset. Aber im oberen Bereich trifft die recht gut.
Wenn die Pumpe aus ist, gibt's eigentlich auch keinen Wert, zumindest hatte ich keinen gemessen bzw. er war Null (0x020000)
Da trotz Nachtabsenkung ein Wert vorhanden war, prüfe bitte ob die Pumpe nicht doch läuft. Wenn ja, wäre das der Wert des Durchflusses für das Übertrömventil, welches zum Schutz der Pumpe verbaut ist und bei komplett geschlossenen Heizkreisen zum Rücklauf überbrückt und damit einen geringen Durchfluss verursacht.
Ich wusste von diesem Ventil und hatte daher das System von der anderen Seite her betrachtet (max. Durchfluss) und damit bei einem geschlossenen Überströmventil.
Hallo zusammen,
nachdem R2D2 super Vorarbeit geleistet hat, und ich gestern beim ,,ins FHEM basteln" festgestellt hatte, daß die Ungenauigkeit Richgung Null immer größer wurde, habe ich heute morgen nochmal gehirnt und dann fiel es mir wie Schuppen aus den Haaren: Es muss doch eine lineare Abhängigkeit zwischen den D.29 und den hex-Werten geben ! Damit muss die Gleichung die Form Y=m*X+b haben.
Nehme ich den obersten Punkt mit X=1866 und Y=1,08 und als zweiten Punkt X=0 und Y=0, dann ergibt sich die Gleichung sinngemäß (bei meinen Werten) mit Vpunkt=(1,08/1866)*X mit X dem dezimalen Wert für die hex-Werte, also zusammengesetzt aus 5.-6. Stelle und 3.-4. Stelle. Rein geexecelt habe ich so eine max. Abweichung von 0,01m³/h, also 10 Liter pro Stunde, das sollte genau genug sein, um damit auch die Leistung über (Vorlauf-Rücklauf)*Volumenstrom zu berechnen.
Könnt Ihr das mal mit Euren Werten gegenchecken ?
Übrigens kommt bei Nachtabsenkung (da ist meine Pumpe wirklich aus) bei mir 020000, also 0m³/h raus :)
Grüße Christian
Hi Marie,
du könntest mal mit "ebusctl grab" probieren, dann direkt danach Befehl über die Bedieneinheit an die Ausseneinheit schicken, dann "ebusctl grab result", dann müsste er alle unbekannten Nachrichten ausgeben, dann müsstest Du anhand des Anfangs der Nachricht, wo die Sender- bzw. Empfängeradresse dran ist sehen können, wie die miteinander reden...
Hi Christian!
Das werde ich mal probieren, danke für den Input.
Ich habe mir heut die ebusd.log genauer angeschaut und hier taucht die 0xE0 (=Außeneinheit, OMU) auf, jedoch mit:
[bus error] scan e0 failed (25 slaves left): ERR: ACK error
Hast du eine Ahnung was diese Fehlermeldung bedeuted?
@cs-online: wer lesen kann ... ;habe jetzt bemerkt, dass "Null" bei Deiner Berechnung rausgekommen ist :-[ und nicht vom eBus gelesen wurde.
Was wir jetzt nicht feststellen können, welcher Anteil des Volumenstroms (je nach Ventilstellungen am Heizkreisverteiler) durch das Überströmventil direkt wieder zum Rücklauf geführt wird und somit nicht zum Aufheizen genutzt wurde.
@R2D2:
Die Heizung war in die Nachtabsenkung gegangen, die Therme zeigte bei D.29 Null an, kein Rauschen mehr in den Rohren, Ebusd zeigte "200000", also auch hier Null in Dezimal. Also ist der untere Punkt sozusagen mit den Koordinaten (0:0), bei den oberen Punkten habe ich ein wenig experimentiert, am genauesten wurde die Geradengleichung mit dem (1,02:1798), da passen alle anderen Messungen bis auf max 0,02 m³/h, also auf 20 Liter pro Stunde, drauf. Das ist glaube ich gar nicht schlecht.
Grüße
Christian
Hallo miteinander,
ich versuche gerade, den ebusd über FHEM auszulesen, was dank des hervorragenden Wikis auch schon gangt gut klappt. Allerdings läuft die im Wiki beschriebene Systemüberwachung unter FHEM (http://www.fhemwiki.de/wiki/EBUS#Mithilfe_von_FHEM) nicht ganz rund. Das dort beschriebene Perl-Programm für 99_myUtils.pm (sub EBUSrecover($$)...) liefert bei mir folgende Logmeldung:
2016.02.12 16:42:50 1: [EBUS] Recover triggered from EBUSrecover, attempt No. 1
2016.02.12 16:42:50 3: define EBUSrecoverdly at +00:00:05
{EBUSrecover('EBUSrecover',2)} : EBUSrecoverdly already defined, delete it first
2016.02.12 16:42:50 3: EBUSrecoverdly: EBUSrecoverdly already defined, delete it firstIn einem älteren Post von pah (http://forum.fhem.de/index.php/topic,29737.msg251930.html#msg251930) ist der Perl-Code auch etwas anders, er enthält zusätzlich noch ein delete device:
Zitat von: Prof. Dr. Peter Henning am 26 Januar 2015, 05:45:15
fhem("delete EBUSrecoverdly")
if($defs{"EBUSrecoverdly"});
Muss der Wiki-Code noch entsprechend ergänzt werden?
Danke und Gruß
alpha1974
Hallo alpha1974,
danke für den Hinweis, ich habes es angepasst.
Viele Grüße
Arthur
Werte ebusd-Freunde,
leider sind die CSV-Dateien für meine Therme (Wolf CGB-2-14) noch etwas unvollständig, weshalb ich mich wild entschlossen daran machen wollte, das zu ändern. Problem: Ich bin wohl zu blöd dafür! :(
Um es langsam angehen zu lassen, will ich folgende Nachricht in eine CSV-Zeile "übersetzen":
2016-02-13 16:21:41.804 [update notice] unknown MS cmd: 3008502203cc0d00 / 029c01
2016-02-13 16:22:43.124 [update notice] unknown MS cmd: 3008502203cc0d00 / 029c01
2016-02-13 16:23:43.733 [update notice] unknown MS cmd: 3008502203cc0d00 / 029c01
2016-02-13 16:24:44.693 [update notice] unknown MS cmd: 3008502203cc0d00 / 029b01
2016-02-13 16:25:47.484 [update notice] unknown MS cmd: 3008502203cc0d00 / 029b01
2016-02-13 16:26:46.648 [update notice] unknown MS cmd: 3008502203cc0d00 / 029a01
2016-02-13 16:27:47.636 [update notice] unknown MS cmd: 3008502203cc0d00 / 029b01
2016-02-13 16:28:48.567 [update notice] unknown MS cmd: 3008502203cc0d00 / 029e01
2016-02-13 16:29:49.548 [update notice] unknown MS cmd: 3008502203cc0d00 / 02a601
2016-02-13 16:30:52.501 [update notice] unknown MS cmd: 3008502203cc0d00 / 02a901
2016-02-13 16:31:51.514 [update notice] unknown MS cmd: 3008502203cc0d00 / 02ad01
2016-02-13 16:32:52.405 [update notice] unknown MS cmd: 3008502203cc0d00 / 02b801
Dank openhab bilde ich mir ein, dass es sich um ein Kommando des Reglers an die Therme zur Abfrage der Kesseltemperatur handelt. Denn unter diesem Link (https://github.com/csowada/openhab-bindings/blob/master/org.openhab.binding.ebus/src/META-INF/wolf-configuration.json) liest man u.a. Folgendes:
"comment": "<Regler> Kromschröder/Wolf: Kessel-Temperatur IST",
"device": "Wolf CSZ-2 > CGB-2 > HCM-2/GBC-e, FW: 1.6",
"id": "temp_vessel",
"class": "heating_kw",
"command": "50 22",
"data": "CC 0D 00",
"values": {
"temp_vessel": {"type": "word", "pos": 12, "label": "Kessel Ist", "factor": 0.1, "min": 1, "max": 100 }
Wenn ich die Nachricht "3008502203cc0d00 / 029c01" damit vergleiche, bedeutet das wohl(?): "30 schickt an 08 des Herstellers 50 (Wolf) den Befehl 22 mit 03 Bit-Länge und Inhalt CC 0D 00." Die Antwort "029c01" könnte dann die Kesseltemperatur sein, wozu auch passen könnte, dass sich der Wert ändert.
Wie komme ich jetzt mit diesen Erkenntnissen (sofern sie zutreffen) zu einer CSV-Zeile, die die Nachricht übersetzt?
Grübelnde und für jeden Denkanstoß dankbare Grüße
alpha1974
Soweit schon fast richtig! :)
Die 50 für den Hersteller ist aber schon das Primary Byte des Befehls, die 22 das Secondary Byte. Da es eine "custom" Nachricht ist, hat sich aber offenbar eingespielt, dass die Hersteller ihre Herstellernummer als PB nutzen - bei Vaillant analog B5.
Die 02 aus der Antwort entspricht der Länge der Antwort und wird von ebusd automatisch gehandhabt, ebenso wie die 03 als Länge der Informationen (ID) zur PBSB-Nachricht.
Die einfachste CSV-Zeile dazu wäre dann wohl:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment,,,
r,,Kesseltemp,,,08,5022,CC0D00,,,UIN,8,°C,,,,
Den Datentyp müsstest Du mal prüfen, vor allem mit zu den Hexwerten bekannten Temperaturen. Ich habe jetzt mal die 0x019C..0x01B8 durch 8 geteilt, was Temperaturen von 51,5-55,0°C enspräche. Eventuell gehört ja auch nur das erste Byte zur Temperatur (durch 2 geteilt dann 78-92°C) und das zweite ist ein Status (01=an?) - die openhab-Definitionen kenne ich nicht und habe es deshalb mal ignoriert. Wenn das zweite Byte eine andere Bedeutung hat, dann einfach die Datentypen hintereinander schreiben (hier auch gleich benannt, um sie einzeln auszulesen):
r,,KesseltempStatus,,,08,5022,CC0D00,Temp,,UCH,8,°C,,Status,,UCH,,,,,,
Zitat von: Sven77 am 13 Februar 2016, 22:30:48
Die 50 für den Hersteller ist aber schon das Primary Byte des Befehls, die 22 das Secondary Byte. Da es eine "custom" Nachricht ist, hat sich aber offenbar eingespielt, dass die Hersteller ihre Herstellernummer als PB nutzen - bei Vaillant analog B5.
Die 02 aus der Antwort entspricht der Länge der Antwort und wird von ebusd automatisch gehandhabt, ebenso wie die 03 als Länge der Informationen (ID) zur PBSB-Nachricht.
Super, vielen Dank! Deine Erläuterungen und die von dir vorgeschlagenen CSV-Zeilen bringen mich schon weiter.
Die ausgelesene Kesseltemp (nur das erste Byte geteilt durch 4) liegt zwar 2,5 Grad über derjenigen, die über die schon vorhandenen CSV-Dateien via broadcast ausgelesen werden. Aber die müssen nicht unbedingt stimmen, zumal das Bedienmodul der Therme nochmals andere (leicht abweichende) Werte anzeigt. Da muss ich vielleicht nochmal etwas an den CSV-Dateien "nachjustieren", aber das ist sicher einfacher, wenn die Therme nicht im Betrieb ist und sich die Temperaturen nicht ständig ändern.
Wenn das klappt, wage ich mich einmal an die anderen noch unbekannten Befehle, soweit ich dazu im Netz nähere Informationen finde (openhab hat ja schon ein paar Befehle "entziffert").
Gruß
alpha1974
EDIT:So ergibt es die richtige Kesseltemperatur (=diejenige, die auch am Bedienmodul BM-2 angezeigt wird):
r,,temp_burner,Kesseltemperatur (30->08),,08,5022,CC0D00,,,UIN,10,°C,,,,,,,,,,
@R2D2: Hast Du inzwischen überprüfen können, ob das bei Dir auch passt ?
@John: Wie kann ich das denn evtl. in die bai.CSV V1.X.X hineinbekommen ? Für den Anfang würde mir reichen, wenn ich den hex-Wert in den find-d-Werten mit drin hätte.
Und noch ein Wunsch: gibt es schon eine Möglichkeit D.14 zu setzen ?
Grüße Christian
Zitat von: cs-online am 15 Februar 2016, 20:22:17
@John: Wie kann ich das denn evtl. in die bai.CSV V1.X.X hineinbekommen ? Für den Anfang würde mir reichen, wenn ich den hex-Wert in den find-d-Werten mit drin hätte.
na klar geht das. sollte auch einfach durch einfügen der zeile klappen
Zitat von: john30 am 16 Februar 2016, 07:45:51
auch einfach durch einfügen der zeile klappen
Hi John,
ich fragte, weil das ja mit write abgefragt wird und ich da nicht sicher war, wie ich das dann in die CSV umsetzen muss... Kannst Du mir da aufs Pferd helfen ?
Grüße
Christian
Zitat von: cs-online am 15 Februar 2016, 20:22:17
Und noch ein Wunsch: gibt es schon eine Möglichkeit D.14 zu setzen ?
Ja, einfach in die 08.bai.xxxx eintragen (bei Version 2.x), ich hab es mit "w" gemacht statt "wi".
r;w,,PumpPowerDesired,d.14 Leistung Heizungspumpe Soll,,,,0A04,,,UCH,0=auto;1=53;2=60;3=70;4=85;5=100,%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpPower,d.15 Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,RegulationMode,d.17 Regelungsmodus,,,,0C04,,,UCH,0=flow;1=return,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode,d.18 Pumpenbetriebsart,,,,4904,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpMode2,d.19 Pumpenbetriebsart 2. Pumpe,,,,0B04,,,UCH,0=aftertime;1=continous;2=winter;3=intermittent,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,StorageTempSetMax,d.20 Maximale Speichersolltemperatur,,,,4304,,,temp,, °C,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
hier sind noch ein paar die dir vermutlich fehlen!
pi@raspberry2 /etc/init.d $ ebusctl w -c bai pumppowerdesired 1
done
pi@raspberry2 /etc/init.d $ ebusctl r -f pumppowerdesired
53
pi@raspberry2 /etc/init.d $ ebusctl w -c bai pumppowerdesired 0
done
pi@raspberry2 /etc/init.d $ ebusctl r -f pumppowerdesired
auto
Test den d.14 zu schreiben!
LG
Reinhart
Hi Reinhart,
das mit d.14 ist richtig cool, das fehlte mir noch und ich habs auch für EBUSD 1.1.0 hinbekommen (einfach das % und die überzähligen Komata gelöscht und voila...)
aber wie bekomme ich nun "w -h 08b509030dfb00" in eine CSV-Zeile ?
Grüße
Christian
Hallo und guten Abend,
ich bin neu hier in dem ganzen Thema und habe mir ( dank den Platinen von Helmut aus dem Mikrocontroller-Forum und der Hilfe eines Freundes ) 3 Platinen für den Ebus zusammen gelötet.
Es sind bei mir eine geoTHERM VWL 9C mit einem VR60 Mischermodul als Erweiterung und noch 2 VR90 Fernbediengeräte an einem Ebuskoppler angeschlossen.
An dem zweiten Ebuskoppler ist eine auroMATIC 620 angebunden welche nur noch die Solarsteuerung übernimmt.
Als Nummer drei ist noch ein recoVAIR Wohnraumlüftungsgerät verbaut ( dafür habe ich noch keine passende CSV-Datei ).
Alle Geräte sind von Vaillant und hängen an ttyUSB0-2 eines RasPi. Ich habe FHEM auf dem RasPi aufgesetzt und kann auch schon ein paar Werte auslesen, aber leider habe ich keine Ahnung wie ich dem ebusd beibringe 3 Instanzen zu starten mit z.B. Telnet-Port 6666 / 7777 und 8888 so dass ich alle drei Geräte ansprechen kann.
Ich wäre da für einen Tip sehr dankbar ;D
hier noch ein paar Infos zu meiner Configuration:
Vaillant geoTHERM VWL 9C:
ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 51
masters: 5
messages: 857
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=EHP00;SW=0341;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UIH00;SW=0226;HW=6901", loaded "vaillant/15.uih.csv"
address 17: master #9
address 1c: slave #9, scanned "MF=Vaillant;ID=RC C ;SW=0321;HW=6201", loaded "vaillant/1c.rcc.4.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0341;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0341;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 37: master #14
address 3c: slave #14, scanned "MF=Vaillant;ID=RC C ;SW=0321;HW=6201", loaded "vaillant/3c.rcc.5.csv"
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0341;HW=7201", loaded "vaillant/50.ehp.mc.csv"
address 52: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/52.mc2.4.csv"
address 53: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/53.mc2.5.csv"
auroMATIC 620:
ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 39
masters: 3
messages: 491
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 3f: master #15
address 44: slave #15, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
recoVAIR:
ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 72
masters: 2
messages: 13
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=VAI00;SW=0124;HW=8901"
address c0: slave, scanned "MF=Vaillant;ID=WTW04;SW=0123;HW=9001"
Grüße
Thomas
Zitat von: hasenhirn am 16 Februar 2016, 20:12:30
Alle Geräte sind von Vaillant und hängen an ttyUSB0-2 eines RasPi. Ich habe FHEM auf dem RasPi aufgesetzt und kann auch schon ein paar Werte auslesen, aber leider habe ich keine Ahnung wie ich dem ebusd beibringe 3 Instanzen zu starten mit z.B. Telnet-Port 6666 / 7777 und 8888 so dass ich alle drei Geräte ansprechen kann.
Hast Du wirklich 3 separate Busse? Dann interpretiere ich "Ebuskoppler" wohl falsch... Müssen sich die Geräte nicht untereinander unterhalten??
Aber wie auch immer, Du kannst ebusd als Startparameter wohl das Device, als auch den Port mitgeben. Damit es auch 3x richtig startet, würde ich das Startskript einfach kopieren (aber Vorsicht: bin nicht sicher, ob das die eleganteste Lösung wäre):
# cp -p /etc/init.d/ebusd /etc/init.d/ebusd1
# cp -p /etc/init.d/ebusd /etc/init.d/ebusd2
# update-rc.d ebusd1 defaults
# update-rc.d ebusd2 defaultsUnd natürlich in den kopierten Skripten das PIDFILE ändern in "ebusd1.pid" bzw. "ebusd2.pid" und am Ende der Start-Zeile hinter "-- $EBUSD_OPTS" anfügen: " -d /dev/ttyUSB1 -p 7777" bzw. " -d /dev/ttyUSB2 -p 6666".
HTH, Sven
Hallo Sven,
danke für deine schnelle Antwort.
Ich werde das morgen mal ausprobieren und dann hier das Ergebnis einstellen.
Gruß
Thomas
ich habe da dieselbe Idee wie Sven77 gehabt und das schon ausprobiert, geht aber bei mir nicht (ebusd2 startet nicht). Ich glaube da hat John einmal in der Binary was eingebaut das ebusd nicht 2 x startet, bin mir aber nicht sicher.
Was mir aber komisch vorkommt, das deine Geräte nicht untereinander mit dem eBus verbunden sind. Das ist ja der Sinn und Zweck von einem gemeinsamen Datenbus um eben miteinander zu kommunizieren. Oder hat der Installateur das schlicht vergessen oder weiß er das es nicht funktioniert? Doch Auromatic 620 haben ja einige hier im Forum.
LG
Reinhart
Hallo Reinhard,
machen die Geräte das mit der Busspannung unter sich aus?
Was soll die Solaranlagensteuerung der Lüftung sagen?
Prinzipiell hast Du natürlich recht, das war aber alles separat als ich es übernommenen habe.
Gruß
Thomas
Selbstverständlich ist der ebus multimasterfähig. Es geht auch nicht darum, dass die Solaranlagensteuerung etwas zur Lüftung "sagt". Sondern eben genau darum, dass alle Signale auf einem gemeinsamen Bus zur Verfügung stehen.
LG
pah
Ja absolut, es sind ja bis zu max. 25 Mastern und 228 Slaves möglich.
Nur weiß ich halt nicht ob Vaillant das auch berücksichtigt hat und dann nur noch ein Gerät die Busspannung zur Verfügung stellt.
Ich frage halt lieber mal nach bevor ich hier einfach alles zusammen drösele und es fängt an einer Ecke an zu qualmen ;D
Daher hatte ich mich auch entschlossen mit 3 Platinen zu starten und habe mir damit ein anderes Problem "gebastelt" ::)
Hat jemand schon mal mehrere Steuerungen zusammen verdrahtet? Ich meine damit natürlich nicht eine Steuerung und eine VR60 / VR90 oder sowas, sondern z.B. eine VWL und eine auroMATIC oder so.
Gruß
Thomas
Zitat von: Reinhart am 16 Februar 2016, 22:46:24
ich habe da dieselbe Idee wie Sven77 gehabt und das schon ausprobiert, geht aber bei mir nicht (ebusd2 startet nicht). Ich glaube da hat John einmal in der Binary was eingebaut das ebusd nicht 2 x startet, bin mir aber nicht sicher.
Japp, stimmt. Auch scheint ebusd das PID-File selbst anzulegen. Und bei der Log würden sie sich wohl auch in die Quere kommen. Was aber definitiv aus der Shell funktioniert ist das hier:
/usr/bin/ebusd -f --scanconfig -d /dev/ttyUSB1 -p 7777 >/var/log/ebusd1.log &
/usr/bin/ebusd -f --scanconfig -d /dev/ttyUSB2 -p 6666 >/var/log/ebusd2.log &Daraus ein schickes Startscirpt mit "--background --make-pidfile ..." und der Ausgabeumleitung in die Logdatei zu basteln, überlasse ich jetzt aber jemand anderem. :)
Ich versuche es heute Mittag mal.
Wollte nur vorher mal fragen ob es schon eine Lösung gibt bevor ich was bastel ;D
Gruß
Thomas
Zitat von: Reinhart am 16 Februar 2016, 22:46:24
ich habe da dieselbe Idee wie Sven77 gehabt und das schon ausprobiert, geht aber bei mir nicht (ebusd2 startet nicht). Ich glaube da hat John einmal in der Binary was eingebaut das ebusd nicht 2 x startet, bin mir aber nicht sicher.
das sollte eigentlich schon klappen. gibts irgendeine meldung für den grund? musst natürlich das logfile entsprechend verbiegen, also z.B. Parameter "-l /var/log/ebusd2.log".
Zitat von: Reinhart am 16 Februar 2016, 22:46:24
Was mir aber komisch vorkommt, das deine Geräte nicht untereinander mit dem eBus verbunden sind. Das ist ja der Sinn und Zweck von einem gemeinsamen Datenbus um eben miteinander zu kommunizieren. Oder hat der Installateur das schlicht vergessen oder weiß er das es nicht funktioniert? Doch Auromatic 620 haben ja einige hier im Forum.
Leider hat Vaillant da nicht zu Ende gedacht.
Wie man in den einzelnen scan Ergebnissen von hasenhirn sehen kann, ist auf jedem Bus die Adresse 0x10 genutzt, was üblicherweise die Steuerungseinheit ist.
Sobald das der Fall ist, kann man die Busleitungen nicht zusammenlegen. Würde man das tun, gäbs gravierende Kommunikationsprobleme.
Zudem müssten man die Betriebsspannung der zugeschalteten Busse deaktivieren, was nicht bei jedem Gerät funktioniert bzw. bei den wenigsten.
Zitat von: cs-online am 16 Februar 2016, 19:52:43
das mit d.14 ist richtig cool, das fehlte mir noch und ich habs auch für EBUSD 1.1.0 hinbekommen (einfach das % und die überzähligen Komata gelöscht und voila...)
aber wie bekomme ich nun "w -h 08b509030dfb00" in eine CSV-Zeile ?
Das ist mit dem "r;w" in der ersten Spalte schon erledigt.
Zitat von: hasenhirn am 17 Februar 2016, 08:44:46
Ich versuche es heute Mittag mal.
Wollte nur vorher mal fragen ob es schon eine Lösung gibt bevor ich was bastel ;D
ich kann dir nur empfehlen, den Versuch sein zu lassen.
Habe eine ähnliche Situation mit Solarregler, Lüftung und WP und werde die drei definitiv separat lassen, also mit jeweils eigenem interface ansteuern.
Hallo John,
ich meinte auch den Startscript bearbeiten ;)
Wie startest Du die 3 Instanzen?
Gruß
Thomas
PS: ich möchte mich noch für deine super Arbeit bedanken! Ebusd ist ein tolles Programm :)
I stand corrected - die ausschließliche Verwendung der Adresse 0x10 ist ein Killerargument.
Allerdings sollte man mal probieren, ob die Kisten sich nicht doch automatisch so konfigurieren, dass sie einander nicht stören (andere Adresse, automatische Abschaltung Bussapnnung ?). Wäre eine Anfrage an Vaillant wert.
LG
pah
Zitat von: cs-online am 16 Februar 2016, 19:52:43
aber wie bekomme ich nun "w -h 08b509030dfb00" in eine CSV-Zeile ?
versuche es mal mit:
r,,flowrate,Durchfluss,,,,FB00,,,UIN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,Viele Grüße
Arthur
Zitat von: john30 am 17 Februar 2016, 09:14:21
Leider hat Vaillant da nicht zu Ende gedacht.
Wie man in den einzelnen scan Ergebnissen von hasenhirn sehen kann, ist auf jedem Bus die Adresse 0x10 genutzt, was üblicherweise die Steuerungseinheit ist.
Sobald das der Fall ist, kann man die Busleitungen nicht zusammenlegen. Würde man das tun, gäbs gravierende Kommunikationsprobleme.
Zudem müssten man die Betriebsspannung der zugeschalteten Busse deaktivieren, was nicht bei jedem Gerät funktioniert bzw. bei den wenigsten.
Das ist eigentlich sehr schade, Vaillant baut ansonsten sehr gute Geräte.
Wozu sind eigentlich die Buskoppler da, könnte man die da nicht für diesen Zweck verwenden? https://www.vaillant.at/downloads/installationsanleitungen/regelung-1/i-vr32-0020095092-00-360433.pdf (https://www.vaillant.at/downloads/installationsanleitungen/regelung-1/i-vr32-0020095092-00-360433.pdf)
Hiermit lässt sich laut Beschreibung ja für jedes Gerät eine eigene Adresse vergeben. Wäre zwar etwas zweckentfremdet und ist natürlich auch eine Kostenfrage bei knapp 100.- €, wenn man bedenkt ein Raspberry kostet um die 35.- € plus den eBus Koppler.
ZitatDer Buskoppler verbindet bis zu 16 Heizgeräte mit eBUS-Schnittstelle über den eBUS. Durch
den Adressschalter kann jedem Gerät eine eigene Adresse zugewiesen werden. Eine andere oder darüber hinausgehende Benutzung
gilt als nicht bestimmungsgemäß.
Auszug aus dem Dokument von Vaillant.
Schade eigentlich das Vaillant nicht jedem Device einen Adressschalter mit wahlweiser Spannungsversorgung spendiert, dann wäre fast alles zusammenschaltbar.
LG
Da kann ich ja wieder nur den Kopf schütteln >:(
Unser Heizungsbauer hatte sich damals extra Verstärkung von Vaillant besorgt und da standen dann insgesammt 3 "Heizungsexperten" bei mir im Keller, da die Wärmepumpe und die Auromatic nur so nebeneinander her liefen und keine Verbindung miteinander hatten. Die beste Idee die sie hatten war, die Wärmepumpe "voll aufzudrehen" und sie dann über über einen schaltenden Buskoppler Vaillant VR 31 mittels EVU-Freigabe ein bzw. aus zu schalten. Zwischenzeitlich habe ich den ganzen Käse umgeklemmt und die Wärmepumpe übernimmt die Steuerung von 3 Heizkreisen. Die Auromatic wurde zu Solarsteuerung degradiert was glaube ich auch Perlen vor die Säue ist ::)
Mit dem VR32 hätte das Ganze ohne viel Bastelei und EVU-Freigabe funktioniert >:(
Gruß
Thomas
wenn du jetzt den VR31 noch hast, kannst ihn ja noch einmal einbauen und schauen was eBusd dann daraus machen kann. Die Adresse kannst ja am VR31 auf einen andere einstellen als 0x10, somit wären 2 Geräte schon erfasst.
LG
Es sollte problemlos möglich sein, einen solchen Buskoppler durch eine Lösung mit 2x EBUS Interface und einem Raspberry Pi in der Mitte zu ersetzen.
Wäre eine schöne Erweiterung für den ebusd: Ein Echo-Mode mit Address Translation.
LG
pah
ich denke der VR31 ist ein Slave-Gerät und kann wie ein VR60 oder VR90 ohne Probleme an eine Steuerung angeschlossen werden.
Mit der Auromatic kann man damit z.B. ein Heizgerät einschalten. Das Teil nennt sich zwar Buskoppler, schaltet aber im Prinzip nur per Bus ein Relais.
http://diplotop.de/314.php?k=e01614d56fdacc7630b2b6ddea2a4507&ID=3353008&q=VAILLANT%20VR%2031 (http://diplotop.de/314.php?k=e01614d56fdacc7630b2b6ddea2a4507&ID=3353008&q=VAILLANT%20VR%2031)
Gruß
Thomas
Zitat von: amunra am 17 Februar 2016, 10:33:13
versuche es mal mit:
r,,flowrate,Durchfluss,,,,FB00,,,UIN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Viele Grüße
Arthur
Hi Arthur,
das funktioniert prima !!! Hab vielen Dank !
Grüße
Christian
ich bekomme keine 2te Instanz zum laufen :(
Den ebusd habe ich als ebusd1 und ebusd2 kopiert und dann damit gestartet:
sudo /usr/bin/ebusd1 --scanconfig -d /dev/ttyUSB1 -p 7777 -l /var/log/ebusd1.log
sudo /usr/bin/ebusd2 --scanconfig -d /dev/ttyUSB2 -p 8888 -l /var/log/ebusd2.log
das Ergebnis in /var/log/ebusd2.log ist
2016-02-17 19:13:18.708 [main error] can't open pidfile: /var/run/ebusd.pid
hat da jemand eine Idee wie man das pid-File auf ebusd1 usw. umbiegen kann?
Gruß
Thomas
Hallo Thomas,
lt. Vaillaint ist der VR32-Buskoppler immer dann einzubauen, wenn man mehr als ein Gerät an den Bus anschliessen möchte - wenn also nicht nur die Heizung sondern z.B. auch die Lüftung am Bus laufen sollen. Die Heizung wird direkt auf den Bus geklemmt - ohne ein VR32. In der Lüftung und jedem weiteren zu steuernden Gerät wird dann ein VR32 eingebaut. Bei mir steht in der Installationsanleitung sogar drin, auf was ich den VR32 einzustellen habe. Die Steuerung (bei mir eine VRC700) wird ebenfalls einfach direkt auf den Bus geklemmt.
Schau einfach ins Kleingedruckte des Gerätes welches du zusätzlich zur Heizung an den Bus anschliessen möchtest, ob du ein VR31 oder ein VR32 benötigst. Die recoVAIR 260|360/4(E) benötigt zb den VR32.
Einen dedizierten Kommandozeilenparameter zur Übergabe des pid-Files habe ich in der aktuellen ebusd Version nicht gefunden. Früher gab es das mal ;-)
Da kann John ggf. etwas zu sagen.
Thomas
Zitat von: hasenhirn am 17 Februar 2016, 19:22:08
ich bekomme keine 2te Instanz zum laufen :(
Den ebusd habe ich als ebusd1 und ebusd2 kopiert und dann damit gestartet:
sudo /usr/bin/ebusd1 --scanconfig -d /dev/ttyUSB1 -p 7777 -l /var/log/ebusd1.log
sudo /usr/bin/ebusd2 --scanconfig -d /dev/ttyUSB2 -p 8888 -l /var/log/ebusd2.log
Also das Binary musst Du gar nicht kopieren! Wenn überhaupt, rate ich dringend zu einem Symlink - sonst geht bei einem Update alles durcheinander. Aber wie gesagt: muss gar nicht!
Ich würde es anfangs einfach mit "-f" und statt "-l" die Ausgabe umleiten mit " > /var/log/ebusd1.log" und halt mit "&" am Ende im Hintergrund ausführen.
Ich habe in die Quellen gesehen und es ist tatsächlich so, dass im Hintergrundmodus starr das PIDFILE gesetzt wird. Nicht konfigurierbar. Und es wird eben auch während der Ausführung gelockt, was einen erneuten Start verhindert...
Mich würde an dieser Stelle in der Tat auch interessieren, wie John mehrere Instanzen startet? Oder gönnt man sich dann auch 3 Raspis? :)
Hi,
ich hatte ein ganz ähnliches Problem mit der Calormatic 560 parallel zu meiner 470er und John schrieb dazu im Mikrokontroller-Forum:
ZitatEinfach zwei Konfigurationsverzeichnisse anlegen, jeweils die passenden
CSVs reinlegen, ein Mal ebusd mit dem einen Verzeichnis starten und ein
Mal mit dem anderen, z.B.:
ebusd -c /etc/ebusd -d /dev/ttyUSB0
ebusd -c /etc/ebusd2 -d /dev/ttyUSB1
Nicht wirklich kompliziert, oder?
also nur 1x EBUSD installieren, zwei Verzeichnisse (/etc/ebusd und /etc/ebusd2) mit den jeweiligen CSVs und dann über den Start von oben nacheinander starten. Der Pfad zu den CSVs zu der jeweiligen Instanz wird über -c /etc/ebusd... übergeben und die EBUS-Adapter werden dann alle an einen Raspi angeschlossen.
Weil nur 1x EBUSD existiert, braucht man auch keine zwei PID-Dateien ;-)
Hab ich aber selber noch nicht getestet ;D
Grüße
Christian
Hallo Thomas,
ich finde es immer wieder lustig, dass man sich als Laie überall einlesen muss.
Wenn man sich im Internet etwas informiert weiß man oft mehr als die "Profis" die eine Menge Geld dafür bekommen dass sie es wissen sollten >:(
Der Installateur hatte alle 3 Heizkreise an die Auromatic angeklemmt und die Wärmepumpe regelte die Speichertemperatur wohl nach dem aktuellen Wasserstand der Mosel ::)
Der Außenfühler lag hinter der Heizung usw.
Da ich kein Heizungsbauer bin musste ich mich erst mal mit dem ganzen Krempel beschäftigen.
Zwischenzeitlich habe ich das Ganze so wie ich denke dass es gut ist umgeklemmt ( so wie oben beschrieben )
Der VR31 Buskoppler ist bei der Aktion raus geflogen und darf nicht mehr mitspielen ;D
@cs-online
weißt du zufällig ob das mit der aktuellen Version funktioniert oder ist das eventuell eine ältere?
Gruß
Thomas
PS: zZt. bastele ich an der init-Datei und versuche das Problem zu lösen. Wenn ich was finde, poste ich es hier ;-)
ZitatWenn man sich im Internet etwas informiert weiß man oft mehr als die "Profis" die eine Menge Geld dafür bekommen dass sie es wissen sollte
Nana, mal verbal etwas abrüsten. >:(
Ich habe vor drei Wochen in einem Vortrag vor Delegierten der süddeutschen Handwerkskammern
http://www.learntec.de/de/fachmesse_2/parallelveranstaltungen/itb_vh_veranstaltertreffen/itb_vh_veranstaltertreffen_1.jsp
auch über den Beruf des Heizungsbauers etwas erzählt. Der hat nämlich nur noch wenig mit dem zu tun, was die Herren vor 20 Jahren gelernt haben - und erst langsam setzt sich die Erkenntnis durch, dass auch das mittelständige Handwerk dringend Weiterbildungsprogramme braucht.
LG
pah
@hasenhirn
mit der 2.x geht es zumindest bei mir nicht, weil ebusd immer wieder versucht das Pidfile in /var/run/ebusd.pid anzulegen obwohl dort schon eines angelegt ist.
Ich habe auch die Startscripte schon alle doppelt angelegt, aber ebusd scheint mir die /etc/default/ebusd2 mit dem neuen Pfad der Pid zu ignorieren.
if test -f /etc/default/ebusd2; then
. /etc/default/ebusd2
fi
. /lib/lsb/init-functions
DAEMON=/usr/bin/ebusd2
PIDFILE=/var/run/ebusd2.pid
[main error] can't open pidfile: /var/run/ebusd.pid
Fehlermeldung weil Pidfile schon angelegt ist.
ebusd meldet zwar brav er sei gestartet worden, läuft aber nur einmal. Es ist übrigens egal ob ich per Script starte oder die Binary direkt so wie oben empfohlen.
LG
hallo pah,
ich möchte hier niemanden angreifen und auch nicht verbal entgleisen.
Es ist nur die Erfahrung die ich gemacht habe. Unser Heizungsbauer ( der die Anlage auch nicht zusammen gebaut hat ) fühlte sich nicht sicher und hatte sich Verstärkung direkt von Vaillant besorgt.
Das finde ich schon mal gut, dass jemand zugibt sich nicht sicher zu sein und sich Unterstützung bei den Leuten holt die es wissen müssten. Leider hat das auch nicht funktioniert.
Ich behaupte einfach mal so wie ich es jetzt angeschlossen habe funktioniert es einwandfrei und das nur durch Umklemmen und ohne zusätzliche Komponenten. Auf die Idee ist aber niemand von den anwesenden gekommen. Ich habe vor über 30 Jahren mal Schlosser gelernt und mit einem Lochstreifen brauche ich heute auch an keine Maschine mehr zu gehen. Das man immer dazu lernen muss und die Entwicklungszyklen immer kürzer werden ist nichts neues.
Gruß
Thomas
@Reinhart
das habe ich auch so ausprobiert und bin natürlich auch zum gleichen Ergebnis gekommen :(
Soweit ich das sehe, ist das im Programm fest "verdrahtet" und es ist keine Variable deklariert die auf der Kommandozeile manipuliert werden kann.
aus der ebusd/src/ebusd/main.cpp :
/** the path and name of the PID file. */
#ifdef PACKAGE_PIDFILE
#define PID_FILE_NAME PACKAGE_PIDFILE
#else
#define PID_FILE_NAME "/var/run/ebusd.pid"
#endif
Leider kann ich nicht programmieren und komme da wohl nicht weiter :-[
Vielleicht gibt es ja noch einen Trick aber ich habe im Moment keine Idee. Eventuell hat John ja noch was in der Hinterhand ::)
Gruß
Thomas
Meine Güte, man kommt ja mit dem Lesen kaum noch hinterher ;)
Zitat von: hasenhirn am 18 Februar 2016, 07:19:21
das habe ich auch so ausprobiert und bin natürlich auch zum gleichen Ergebnis gekommen :(
ja, das PID File ist in der Tat fest verdrahtet. Werde mit der nächsten Version einen Kommandozeilenparameter o.ä. dafür einbauen.
Dass ich mehrere ebusd starten kann, liegt schlicht daran, dass ich die in einem screen immer im Vordergrund laufen lasse, also nicht als Dienst im Hintergrund. Nur für den Dienst wird das PID File benötigt.
Das mit dem PID File lässt sich grundsätzlich auch anders regeln, nämlich über die init Scripts des Systems, die i.d.R. auch schon Support für PID des gestarteten Prozesses nehmen und in PID File schreiben haben.
Wahrscheinlich wird es darauf in der nächsten Version von ebusd hinauslaufen, denn dass der Prozess selbst das PID File schreibt war mir eh schon immer ein Dorn im Auge.
Wer also eine schnelle Lösung möchte, kommentiert in der src/ebusd/main.c die Zeilen 415 bis 430 aus und ist erstmal glücklich. Damit kann man aber bis zur Anpassung des init scripts nicht mehr sauber den entsprechenden ebusd Dienst beenden (weil ja dann kein PID File mehr angelegt wird).
EDIT: Lösung ist ganz banal:
Im contrib/debian/init.d/ebusd in zeile 26 noch "--make-pidfile" als weiteren Paramter eintragen und dann sollte es so funktionieren.
Hallo John,
danke für die Info und die Tipps.
Gibt es schon einen Terminplan für die neue Version ( ohne Dich festnageln zu wollen ;) )
Noch was anderes: Hast du eine CSV-DATEI für deine Lüftungsanlage? Dazu hat der ebusd in der Version 2.0 nichts gefunden.
Gruß
Thomas
Werte Profis,
durch trial-and-error (und dank fleißigen Lesens hier und im openhab-Source....) ist es mir inzwischen gelungen, zahlreiche Wolf-Telegramme auszuwerten, die über diverse Parameter der Therme (CGB-2 mit BM-2) Auskunft geben, z.B. Kesseltemperatur, Rücklauftemperatur, Abgas-Temperatur, Brennerleistung, Pumpenleistung etc. Meine bisherigen Erkenntnisse in Form einer CSV-Datei, die man vermutlich noch optimieren könnte, habe ich angehängt.
Nun gilt es, die nächste Evolutionsstufe zu erreichen, nämlich ein Heizprogramm auszuwählen. Das Heizprogramm kann man manuell am Bedienmodul BM-2 auswählen, das wohl dann auch die Regelung der Therme übernimmt.
Daher war meine Überlegung: Man muss dem BM-2 den passenden Befehl schicken, damit es in ein anderes Heizprogramm wechselt. Das BM-2 scheint Master 30 und Slave 35 zu sein.Wieder mit der Hilfe von openhab (siehe hier (https://github.com/openhab/openhab/blob/b6a502fc5b3a03b2d9bc3b56f1351ff31d0617dd/bundles/binding/org.openhab.binding.ebus/src/main/resources/wolf-cgb2-configuration.json)) - bin ich schon etwas weitergekommen und das geht schon:
Abfragen des eingestellten Heizprogramms am BM-2:
ebusctl w -h 35502203ff7427
020100
020100 für Auto, 02000 für Standby usw.
Heizprogramm Auto setzen:
ebusctl w -h 3550230900742701005D010010
ERR: read timeout
Trotz ERR wird das Heizprogramm am BM-2 auf Auto gesetzt.
Heizprogramm Standby:
ebusctl w -h 3550230900742700005D010010
(gibt ebenfalls den o.g. ERR, Heizprogramm am BM-2 geht aber auf Standby)
Umschalten auf Sparbetrieb, Dauerheizen, Partymodus etc. geht auch, wenn man das vierte Daten-Byte (3550230900742700005D010010) ändert.
Aber: Wie bekomme ich das in eine CSV-Zeile?
Besten Dank vorab für Denkanstöße,
alpha1974
Hallo John,
ich habe das nach deiner Anleitung gemacht und es hat funktioniert :D
pi@raspberrypi:~/Downloads/ebusd-test/ebusd $ ebusd -p 6666 -d /dev/ttyUSB0 -l /var/log/ebusd0
pi@raspberrypi:~/Downloads/ebusd-test/ebusd $ ebusd -p 7777 -d /dev/ttyUSB1 -l /var/log/ebusd1
pi@raspberrypi:~/Downloads/ebusd-test/ebusd $ ebusd -p 8888 -d /dev/ttyUSB2 -l /var/log/ebusd2
pi@raspberrypi:~/Downloads/ebusd-test/ebusd $ sudo ps -A | grep ebus
30862 ? 00:00:00 ebusd
30867 ? 00:00:00 ebusd
30873 ? 00:00:00 ebusd
Das mit dem Startscript habe ich noch nicht hin bekommen.
Ich habe aber gestern beim probieren vermutliche etwas zerschossen und es kann sein dass es daran liegt ::)
Gruß
Thomas
Mal eine Frage an die Vaillant-User hier:
Bei meiner multiMATIC VRC700 gibt es (genau wie bei der calorMATIC VRC470) die Möglichkeit, die Raumluftfeuchte und den daraus errechneten Taupunkt abzulesen. Ungeachtet meiner Bedenken, wie genau diese Anzeige ist - gibt es jemanden, der weiß ob/wie man diese Werte über eBus abfragen kann?
Ich habe bei der VRC700 schon einiges gefunden und in eine CSV gebaut - darunter leider auch noch viele unbekannte Werte, aber nichts was auch nur ansatzweise der Luftfeuchte entsprechen würde...
Sven
Zitat von: hasenhirn am 18 Februar 2016, 10:20:50
Gibt es schon einen Terminplan für die neue Version ( ohne Dich festnageln zu wollen ;) )
Dieses Wochenende komme ich mal wieder dazu, etwas an ebusd machen zu können. Muss mal auf meine todo Liste schauen, was in die nächste Version unbedingt rein sollte.
Ich gehe mal davon aus, dass es dieses WE noch kein neues Release geben wird.
Zitat von: hasenhirn am 18 Februar 2016, 10:20:50
Noch was anderes: Hast du eine CSV-DATEI für deine Lüftungsanlage? Dazu hat der ebusd in der Version 2.0 nichts gefunden.
Leider ist die recovair nicht in der Vaillant DB, deshalb gibt es auch kein CSV dafür. D.h. also Telegramme grabben, Struktur erkennen, daraus CSV generieren. Eher ein länger fristiges Projekt...
Kleiner Tipp am Rande: Falls Deine recovair Steuerung irgendwann keine Stromversorgung mehr über bekommt, dann bewirkt ein Tausch der beiden Kondensatoren auf der Reglerplatine in der Lüftung wahre Wunder. Die sind aufgrund Ihres Temperaturbereichs nämlich nur für einige Jahre Dauerbetrieb geeignet und geben einigermaßen pünktlich den Geist auf... Genial gemacht, was? :-)
Zitat von: alpha1974 am 18 Februar 2016, 17:37:00
Heizprogramm Auto setzen:
ebusctl w -h 3550230900742701005D010010
ERR: read timeout
Trotz ERR wird das Heizprogramm am BM-2 auf Auto gesetzt.
Bzgl. Timeout könntest Du mal mit den Timing-Paramters spielen (sprich erhöhen), siehe
https://github.com/john30/ebusd/wiki/2.-Run#ebus-options (https://github.com/john30/ebusd/wiki/2.-Run#ebus-options)
Zitat von: alpha1974 am 18 Februar 2016, 17:37:00
Umschalten auf Sparbetrieb, Dauerheizen, Partymodus etc. geht auch, wenn man das vierte Daten-Byte (3550230900742700005D010010) ändert.
Aber: Wie bekomme ich das in eine CSV-Zeile?
Hier wäre zunächst mal rauszufinden, was der Rest der Datenbytes für eine Bedeutung hat.
Am besten Du änderst mal über den regulären Weg den Modus an mehreren Tagen hintereinander und schaust, was in dem Telegramm dann so drin steht.
Vorher macht es eigentlich wenig Sinn, das in CSV zu packen.
Moin John,
danke für die Info. Leider komme ich im Moment auch immer nur sporadisch an meinen Rechner mit ebus / FHEM :-\
Wenn ich das so halbwegs am laufen habe, werde ich mich mal mit der recoVair beschäftige.
Danke für den Tipp mit den Kondensatoren :D
Zum Glück läuft das Gerät seit ca.7 Jahren ohne Probleme aber das kann sich ja schnell ändern :o
An das Display der VWL musste ich schon mit dem Lötkolben ran, sonst hätte mich der Spaß bei Vaillant ca. 800€ gekostet >:(
Mir tun die Leute Leid die sich da nicht selbst helfen können :-\
Gruß
Thomas
Hallo John,
vielen Dank für die Antwort!
Zitat von: john30 am 19 Februar 2016, 06:53:03
Am besten Du änderst mal über den regulären Weg den Modus an mehreren Tagen hintereinander und schaust, was in dem Telegramm dann so drin steht.
Vorher macht es eigentlich wenig Sinn, das in CSV zu packen.
Das habe ich schon versucht, bin aber leider nicht weitergekommen. Noch nicht...
Ich vermute (und meine, es auch in einem alten Thread im mikrokontroller.net gelesen zu haben), dass das Heizprogramm nur im Bedienmodul (BM-2) eingestellt wird und dass von dort aus die Therme gesteuert wird, ohne dass ihr mitgeteilt wird, welches Heizprogramm eingestellt ist. Wenn ich am BM-2 das Heizprogramm ändere, geht kein eindeutig zuzuordnendes Telegramm raus (habe das schon einmal einen halben Tag lang ausprobiert und mir jeweils die Telegramme angesehen). Jedenfalls konnte ich kein Muster in dem Sinne erkennen, dass nach einer manuellen Änderung des Heizprogramms am BM-2 eines oder mehrere jeweils gleichlautende (oder zumindest ähnliche) Telegramme rausgehen. Es gibt zwar regelmäßige Broadcasts, in denen wohl auch das Heizprogramm als Status enthalten ist (ändert sich, wenn man manuell das Heizprogramm ändert). Aber diese Telegramme laufen dauernd über den Ebus und nicht nur, wenn man das Heizprogramm umstellt.
Dabei ist meine Konfiguration so ziemlich das simpelste, was es gibt: Nur die Gas-Therme, an ihr ein Anzeigemodul (AM) und im Wohnzimmer das Bedienmodul (BM-2). Nur raumtemperaturgesteuerte Heizung, kein Außenfühler, keine Warmwasserversorgung, kein Solar, kein Garnichts.... Es gibt allerdings noch zahlreiche Telegramme vom BM-2, die ich noch nicht entschlüsseln konnte (im Grunde "quatscht" das Ding im Sekundentakt).
Naja, die grundlegende Funktion, über FHEM die Heizung in Standby zu schalten, wenn z.B. ein Fenster geöffnet wird, und danach wieder in Auto, könnte ich ja schon mit meinen o.g. Erkenntnissen auch ohne CSV umsetzen. Schöner wäre es natürlich mit passenden CSV-Einträgen.
da habe ich mich wohl zu früh gefreut :-\
bei FHEM kommen keine Werte an und wenn ich mich per telnet verbinde kommen bei allen 3 Ports :
r -f outsidetemp
ERR: invalid position in decode
ich bin mir nicht sicher ob der Fehler bei mir / meinem System liegt, oder ob es so nicht funktioniert.
Was mir noch aufgefallen ist, die Logfiles werden auch nicht geschrieben.
Ich werde das System wohl einfach mal neu aufsetzen :-[
Gruß
Thomas
Zitat von: hasenhirn am 19 Februar 2016, 15:20:06
da habe ich mich wohl zu früh gefreut :-\
bei FHEM kommen keine Werte an und wenn ich mich per telnet verbinde kommen bei allen 3 Ports :
r -f outsidetemp
ERR: invalid position in decode
Nur Systeme mit einem externen Temperatursensor sollten da etwas liefern. Und da käme es dann darauf an, was du für eine CSV geladen hast. was sagt denn jeweils
info
?
Und hat der User als der du den ebusd startest Schreibrechte im /var/log?
Gruß
Thomas
Hallo Thomas,
danke für den Tipp.
Die CSV-Datei passt, der Außenfühler ist angeschlossen und das Abfragen hat auch die ganze Zeit funktioniert.
Das Ganz hat ja auch schon mehr oder weniger funktioniert, aber ich konnte mich halt immer nur mit der Heizung der Solaranlage oder der Lüftung verbinden.
In FHEM sollen alle Werte zusammengefasst werden und da ist im Moment die Herausforderung ;)
Ich bin da aber sehr optimistisch :D
Gruß
Thomas
Ich hatte das auch anfangs... bzw. dann irgendwann. Ich vermute mal, dass für irgendeinen Circuit in dessen CSV eine "outsidetemp" definiert wurde, die eben aus welchen Gründen auch immer nicht passt.
Da mir dann auffiel, dass meine multiMATIC ohnehin sehr gesprächig ist, was Außentemperatur und Datum/Uhrzeit angeht, lese ich jetzt explizit nur die Broadcast-Daten aus.
Im ebusd.log steht immer wieder:
[update notice] update broadcast outsidetemp QQ=10: 1.062
Also lese ich explizit:
ebusctl r -c broadcast outsidetemp
Zitat von: hasenhirn am 19 Februar 2016, 15:20:06
bei FHEM kommen keine Werte an und wenn ich mich per telnet verbinde kommen bei allen 3 Ports :
r -f outsidetemp
ERR: invalid position in decode
Dann scheint die Antwort nicht dem erwarteten Format zu entsprechen.
Mach mal die Abfrage in hex und poste das Ergebnis, also:
ebusctl w -h 08b509030d0600
034f0000
Die Zieladresse "08" musst halt durch die richtige ersetzen (falls nötig).
EDIT: In lesbarer Form seht das so aus:
ebusctl r -f outsidetemp
4.94;ok
VG John
Zu spät ;D
Ich habe gestern Abend alles platt gemacht und neu aufgesetzt.
Jetzt habe ich es der Einfachheit halber alle 3 Instanzen separat gestartet.
Heute Abend geht es weiter.
Gruß Thomas
Also PID file kann man mit dem aktuellen git Stand z.B. mit "--pidfile /var/run/ebusd1.pid" umlenken.
Super - DANKE :D
Zitat von: RobertG am 12 Januar 2016, 22:31:25
Also in meiner HW7401 sind d.14, d.15, d.17, d.18, d.19, d.20 vorhanden. Siehe Anhang.
Zitat von: john30 am 16 Januar 2016, 08:34:07
Das ist ein sehr wertvoller Hinweis! Danke dafür!
Jetzt kann ich das mal konkret mit vrdialog über ebusd austesten :-)
So langsam kommt Licht ins Dunkel der BAIs!
Das unerfreuliche: Mit einer BAI ist alles wieder gaaanz anders :(
Hier hängt die CSV nicht nur von ID, HW und SW aus dem Ident Telegramm ab, sondern zusätzlich auch noch von der Produktnummer sowie einer zweiten Softwareversion.
Das macht die Angelegenheit sehr eklig und ich überlege noch, wie ich das am besten in die CSVs einkippen kann.
Andererseits gibt es noch eine erfreuliche Nachricht: aus der MDB lassen sich mit dieser Erkenntnis 12 verschiedene CSVs für jeweils unterschiedliche BAIs extrahieren :)
So ganz 100%ig sicher bin ich aber noch nicht, ob das alles stimmt. Es ist z.B. unklar, ob wirklich nur die 12 unterstützt werden, oder alle mit gleicher zweiter Softwareversion. Dazu wird es evtl. mal eine Versuchsreihe geben müssen.
I'll keep you posted!
VG John
Hallo John,
nach langer Abstinenz bin ich auch wieder an der Heizung, und zwar auch an der bai00.
Auf einem weiteren Raspberry mit Buskoppler ziehe ich meine Installation auf ebusd 2.0, fein, läuft soweit.
Allerdings finde ich in den Konfigurationsdateien aus dem Github ein paar Inkonsistenzen.
Beispiel: In der bai00 HW7401 steht überall als Datentyp temp, in der _templates hingegen temps
Beispiel: In der _templates selber wird mal temps, mal temp als Datentyp verwendet.
Das ist sicher eine Folge der bei den bai00 überbordenden Modellvielfalt. Wie bekommen wir es hin, ohne Doppelarbeit und gut abgestimmt solche Fehler zu beheben ? Es steht immer noch mein Angebot im Raum, dafür eine extern bedienbare Datenbank zur Verfügung zu stellen.
Außerdem sind die Namensgebungen der Kommandos manchmal etwas optimierbar - ist das jeweils Deine Formulierung, oder kommt das aus der Vaillant-DB ??
Beispiel: Die Solltemperatur wird immer als ...Desired... bezeichnet, die Solldrehzahl allerdings mit ...Target...
Beispiel: Bei IonisationVoltageLevel ist die Bezeichnung verdoppelt (Eine Spannung ist immer ein Wert, das "Level" ist überflüssig), hingegen sollte es z.B. statt CirPump besser CircPumpStatus heißen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Allerdings finde ich in den Konfigurationsdateien aus dem Github ein paar Inkonsistenzen.
Beispiel: In der bai00 HW7401 steht überall als Datentyp temp, in der _templates hingegen temps
Beispiel: In der _templates selber wird mal temps, mal temp als Datentyp verwendet.
das liegt schlicht daran, dass derzeit der Name des Templates als Feldname übernommen wird. Somit wird also ein "temps", was natürlich eine Temperatur darstellt, auch also solche bezeichnet.
Seit Mitte letzten Jahres unterstützt die _templates.csv die Angabe des Namens, wie er dann in der Nachricht verwendet werden soll (z.B. so: "temps:temp,SCH,,°C,Temperatur"). Somit könnte man das relativ einfach gerade ziehen.
Das würde ich auch übernehmen, wenn keiner was dagegen hat.
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Außerdem sind die Namensgebungen der Kommandos manchmal etwas optimierbar - ist das jeweils Deine Formulierung, oder kommt das aus der Vaillant-DB ??
Die Namen werden aus der MDB genommen und durchlaufen eine umfangreiche Transformation zur Vereinheitlichung, die derzeit aus rund 150 Regeln besteht. Somit wird bspw. aus dem Suffix "TopTemp" ein "TempTop" usw.
Nachdem mir aber die Zeit fehlt, alle 36 CSVs mit fast 3000 Definitionen dahingehend zu überpüfen, bin ich hier auf Feedback angewiesen.
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Beispiel: Die Solltemperatur wird immer als ...Desired... bezeichnet, die Solldrehzahl allerdings mit ...Target...
Hierfür kann ich problemlos eine neue Transformationsregel einführen
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 10:45:20
Beispiel: Bei IonisationVoltageLevel ist die Bezeichnung verdoppelt (Eine Spannung ist immer ein Wert, das "Level" ist überflüssig), hingegen sollte es z.B. statt CirPump besser CircPumpStatus heißen.
Ersteres ist auch kein Problem.
Die "CirPump" heißt urspr. "CirculationPump_DK" und wird derzeit durch die Regeln ("_DK" verwerfen, "Circulation" kürzen auf "Cir") in "CirPump" umgesetzt. Da noch einen "Status" (oder "State"?) anzuhängen ist auch machbar. dann muss ich nur prüfen, ob es auch einen "Pump" Suffix gibt, der keinen Status darstellt.
ZitatHierfür kann ich problemlos eine neue Transformationsregel einführen
Prima, das vereinfacht die Arbeit. Folgender Vorschlag zur Systematisierung:
Name =
[Wenn nötig, Name des Kreislaufs = Hc,Hc1..n,Hwc,Mc,Sc,Sc1..n][Gerät = Burner,Storage,Pump,Fan,Gasvalve etc.oder (logischer )Ort = Flow,Return,Outside][Option Prozess, z.B. Postrun][Was wird gemessen/gesetzt = Temp,Pow(er),Rate,Freq(uency)/Speed,Faults,Time][Optional Art der Messung/Festlegung = Desired,Max,Min,Av(erage),Switch]
LG
pah
Zitat von: john30 am 20 Februar 2016, 14:54:00
Hier hängt die CSV nicht nur von ID, HW und SW aus dem Ident Telegramm ab, sondern zusätzlich auch noch von der Produktnummer sowie einer zweiten Softwareversion.
Das macht die Angelegenheit sehr eklig und ich überlege noch, wie ich das am besten in die CSVs einkippen kann.
Ich weiß jetzt nicht, ob Du alles aus der MDB extrahieren kannst. Aber falls Du hier Rückmeldung brauchst, hier ausdrücklich meine Bereitschaft dazu (falls Du nicht auch eine icoVIT156/3-7 hast):
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
Hallo John,
interessanter Effekt. In der csv-Datei steht
Zitat
*hwc,hwc,,,,25,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
hwc,,Mode,SP1.TagesTemp/Mode,,,,01,,,temp0;hwcmode;IGN:3;HEX;IGN;onoff;IGN,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Die entsprechende Nachricht geht auch sauber als 1025b5040101 heraus und wird ordentlich mit 1+9 Byte 09370300000283000100 beantwortet. Allerdings spuckt ebusd eine Fehlermeldung aus:
Zitat2016-02-22 19:42:22.865 [update error] unable to parse hwc Mode from 1025b5040101 / 09370300000283000100: ERR: invalid position
Aus irgendeinem Grund wird das 2. Byte (0x37 = 55) nicht richtig gelesen. Nimmt man aus der Konfigurationsdatei alles außer dem temp0 heraus (ist als UCH definiert), also
Zitat
*hwc,hwc,,,,25,B504,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
hwc,,Mode,SP1.TagesTemp/Mode,,,,01,,,temp0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
gibt es zwar keine Fehlermeldung, aber bekommt man als Wert 210 statt 55 angezeigt.
Edit: Klar, es ist das "w" in der Abkürzung "hwc" - das wird eben nicht mehr als default "r" interpretiert. OK, war ein Versuch.
LG
pah
Eine kleine Umfrage...
Ich versuche gerade mit FHEM warm zu werden - bisher nutz(t)e ich CCU.io, was mir aber zu RAM-hungrig ist.
Die ebusd-Anbindung kann ja über ECMD oder GAEBUS erfolgen - welches nutzt ihr so, oder gibt es noch weitere?
Bei ECMD ist mir irgendwie zu viel Handarbeit nötig... (mind. 4 Konfig-Zeilen *pro* Wert, mindestens 3 Zeilen in externer Class-Datei allein zum Lesen), außerdem landen die Werte nicht in meinem DbLog!
GAEBUS läuft fast unverändert mit den normalen CSVs und lässt sich zusammenklicken, aber ermöglicht keine Abfrage von kombinierten Werten ("22.5°C;ok") und kann die Werte nicht einzeln im WebGUI darstellen?!
Gibt es irgendeine gute Möglichkeit, die alles kombiniert?
- (selektives) Hinzufügen aller definierten ebusd-Werte
- Festlegen des Zahlenformates (Anz. Nachkommastellen)
- Logging der Änderung (!) von Werten ins DbLog
Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei?
@Sven77
eigentlich hast du dir schon alles selbst beantwortet und die Vor- und Nachteile beider Methoden richtig erkannt.
GAEBUS ist einfach aber nicht so flexibel. Ich verwende hauptsächlich ECMD wegen deiner erwähnten Vorteile, außerdem steuere ich die Abfragen mit 2 Timern, weil es ja nicht so wichtige Datenpunkte gibt die ich nicht so oft brauche (Druck und irgendwelche Errorcounter etc.).
Beim GAEBUS kommst du schnell in Versuchung zu viel zu erfassen dann ist halt der eBus ständig damit beschäftigt diese abzufragen.
Die Arbeit bei ECMD hält sich in Grenzen (Copy und Paste eines bestehenden Define mit ein paar spezifischen Anpassungen) und wenn du mit GAEBUS weiter auswerten oder verarbeiten willst ist es fast mehr Aufwand.
Mir ist schon aufgefallen das gerade Einsteiger mit ECMD besser zurecht kommen als mit GAEBUS, aber das muss ohnehin jeder selbst wissen was er bevorzugt und das kann man erst sagen wenn man beides probiert hat.
In der Praxis ändere ich an den einmal definierten Werten nichts mehr wenn alles stabil läuft.
zu deinen Fragen:
Gibt es irgendeine gute Möglichkeit, die alles kombiniert?- ja beide System gleichzeitig anwenden
- (selektives) Hinzufügen aller definierten ebusd-Werte - nur bei GAEBUS
- Festlegen des Zahlenformates (Anz. Nachkommastellen)- nur bei ECMD gut handelbar
- Logging der Änderung (!) von Werten ins DbLog- bei ECMD normales (Db)Filelogging unter Fhem, braucht man ja zur Anzeige der Plots
Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei? - außer dem Installer (http://forum.fhem.de/index.php/topic,46098.msg405704.html#msg405704) ist mir nichts bekannt
LG
Reinhart
Hallo Seven77,
ich habe genau das gleich Problem da ich ja auch blutiger Anfänger bin.
Den Ebusd am laufen zu haben und erste Werte mit FHEM abfragen zu können ist schon mal ein Erfolg ;D
Hier bin auch total dankbar für die super Unterstützung hier aus dem Forum und vor allem von John :)
Zur Zeit lese ich mich in Perl ein um die ECMD-Abfragen etwas nach meinem Geschmack anpassen zu können.
Ebusd, FHEM und Perl zu erlernen ist im Moment jede Menge Stoff auf einmal :P
Zu allem überfluss hatte ich Zeit als ich auf die Teile und die Platinen für den ebus gewartet habe und jetzt wo die Platinen laufen, komme ich kaum noch dazu :(
Na ja, ich kämpfe mich so durch und suche mir hier im Forum dies und das zusammen.
Reinhart macht mit seinen Anleitungen auch eine super Arbeit und das bringt mich auch gut vorran ( auch hier mal danke an der Stelle ;) )
Gruß
Thomas
@hasenhirn
Danke fürs Lob!
wenn du dich mit ECMD und den vielen Möglichkeiten näher befassen willst, dann sieh dir die Beispiele von pah im Wiki genauer an (ECMD Classdefinition Heizkreis), da kannst du am meisten davon lernen welche Varianten hier machbar sind. Die Commands stimmen zwar in der Zwischenzeit nicht mehr ganz und müssen noch überarbeitet werden, aber von der Programmiertechnik kann man sich einiges abschauen und lernen.
LG
Zitat von: Reinhart am 23 Februar 2016, 10:29:41Oder gibt es eine Art Wizard zur Konfiguration von ECMD mit der Class-Datei? - außer dem Installer (http://forum.fhem.de/index.php/topic,46098.msg405704.html#msg405704) ist mir nichts bekannt
Ohh - vielen Dank!!
Ich war von den anderen Punkten so enttäuscht (ja - copy&paste geht, aber gerade zum Warmwerden klicke ich gern erstmal etwas zusammen), dass ich den Link glatt übersehen hatte!
Das sieht ja sehr vielversprechend aus, das probiere ich unbedingt mal aus - dank Dir!
Sven
Hallo zusammen,
ich habe eine Frage zum ebusd:
Der Empfang klappt, ich kann aber nichts senden, er empfängt immer nur Fehler:
2016-02-25 23:02:23.271 [bus notice] <aa
2016-02-25 23:02:23.317 [bus notice] <aa
2016-02-25 23:02:23.317 [bus notice] >ff
2016-02-25 23:02:23.338 [bus notice] <ff
2016-02-25 23:02:23.338 [bus notice] >08
2016-02-25 23:02:23.348 [bus error] send to 08: ERR: read timeout, retry
2016-02-25 23:02:23.363 [bus notice] <08
2016-02-25 23:02:23.363 [bus notice] <f5
2016-02-25 23:02:23.946 [bus notice] <aa
2016-02-25 23:02:23.946 [bus notice] >ff
2016-02-25 23:02:23.967 [bus notice] <ff
2016-02-25 23:02:23.967 [bus notice] >08
2016-02-25 23:02:23.977 [bus error] send to 08: ERR: read timeout, retry
2016-02-25 23:02:23.992 [bus notice] <08
2016-02-25 23:02:23.992 [bus notice] <f5
2016-02-25 23:02:24.576 [bus notice] <aa
2016-02-25 23:02:24.576 [bus notice] >ff
2016-02-25 23:02:24.597 [bus notice] <ff
2016-02-25 23:02:24.597 [bus notice] >08
2016-02-25 23:02:24.607 [bus error] send to 08: ERR: read timeout
2016-02-25 23:02:24.607 [main error] hex read scan.08 ident: ERR: read timeout
2016-02-25 23:02:24.622 [bus notice] <08
2016-02-25 23:02:24.623 [bus notice] <f5
2016-02-25 23:02:25.206 [bus notice] <aa
2016-02-25 23:02:25.207 [bus info] poll cmd: ffecb509030d0100
2016-02-25 23:02:25.207 [bus notice] >ff
2016-02-25 23:02:25.228 [bus notice] <ff
2016-02-25 23:02:25.228 [bus notice] >ec
2016-02-25 23:02:25.237 [bus error] poll sc WS1 failed: ERR: read timeout
2016-02-25 23:02:25.253 [bus notice] <2c
2016-02-25 23:02:25.253 [bus notice] <f5
Mein eBus-Adapter hängt am Standard COM1-Port. :-)
Gibt es evtl. sowas wie eine "brute foce" Methode beim Schreiben?
Lesen klappt ohne Probleme.
Gruß
Maik
@istler
Ja da scheint deine Hardware defekt zu sein. Ist so wie hier dargestellt (http://forum.fhem.de/index.php/topic,46098.msg378798.html#msg378798). Kommt jetzt darauf an was du für einen eBus Adapter benutzt, bei einem Fertiggerät bleibt dir eh nichts anderes übrig als es einzusenden, bei Eigenbau musst du den Fehler suchen, kann aber nicht viel sein weil die Schaltung ja sehr einfach aufgebaut ist (kommt jetzt drauf an welche Schaltung du verwendest).
Da ja bei dir der Empfang tadellos funktioniert aber nach dem Senden keine Antwort kommt (Timeout), kann man davon ausgehen das dein Sendesignal nicht weg geht.
Bei dem oben verlinkten Beispiel war die Zenerdiode defekt (bei Schaltung pah)!
LG
@Reinhart: Danke! Der eBus-Adapter läuft inzwischen, die Hardware ist i. O. Der COM-Port vom Motherboard hat Probleme (UART-Buffer?) gemacht. Ich habe den eBus-Adapter jetzt an einen USB/RS232-Adapter gehängt und nun klappt auch das senden! :-)
Nun kommt aber meine nächste Frage:
Wie bekomme ich die JSON-Dateien über die HTTP-Schnittstelle des ebusd heraus? Der Daemon läuft bei mir mit folgenden Parametern:
root 4774 0.4 0.0 320340 1948 ? Ssl 11:27 0:07 ebusd -s --device=/dev/ttyUSB1 --loglevel=info --httpport=8020 --htmlpath=/var/lib/ebusd/html
Das Verzweichnis /var/lib/ebusd/hml ist leer!? Wenn ich eine Verbindung mit dem Browser auf den ebusd-http-Port machen. Erhalte ich nur eine leer Seite!?
Im Log steht dazu nur dies:
2016-02-26 11:52:57.287 [network info] [00001] HTTP connection opened 192.168.1.63
2016-02-26 11:52:57.288 [network info] [00001] connection closed
2016-02-26 11:52:58.291 [network info] [00002] HTTP connection opened 192.168.1.63
2016-02-26 11:52:58.292 [network info] [00002] connection closed
2016-02-26 11:52:59.139 [network info] [00003] HTTP connection opened 192.168.1.63
2016-02-26 11:52:59.140 [network info] [00003] connection closed
Decodieren tut der ebusd aber:
2016-02-26 12:00:18.155 [bus notice] poll sc WS1: 26.12;ok
2016-02-26 12:00:20.646 [update notice] update bai Mode QQ=10: standby
2016-02-26 12:00:22.107 [update notice] update hc SumFlowSensor QQ=10: 26.12;ok
2016-02-26 12:00:23.697 [update notice] update bai Status01 QQ=10: 27.0;26.0;-;-;-;off
2016-02-26 12:00:28.745 [update notice] update hc DateTime QQ=10: ok;12:00:15;26.02.2016;4.938
2016-02-26 12:00:30.203 [bus notice] poll sc TempWaterStorage: 39.44;27.88;-;-;-
2016-02-26 12:00:30.786 [update notice] update bai Mode QQ=10: standby
2016-02-26 12:00:32.246 [update notice] update hc SumFlowSensor QQ=10: 26.12;ok
2016-02-26 12:00:32.596 [update notice] update sc swStatus QQ=10: 0;off;-;0
2016-02-26 12:00:33.813 [update notice] update bai Status01 QQ=10: 27.0;26.0;-;-;-;off
2016-02-26 12:00:35.276 [update notice] update sc Status QQ=10: 30;00;off;45;0
Das Info-Kommando auf der Telnet-Schnittstelle liefert dies:
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 34
masters: 3
messages: 685
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0706;HW=7401", loaded "vaillant/08.bai.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.csv"
Hat jemand eine Idee? Hab ich was falsch konfiguriert?
Gruß
Maik
das ist klar, wenn die Com Schnittstelle nicht funktioniert hast du den selben Effekt!
Warum willst du über httpmod die JsonDaten filtern, das wäre ja äußerst umständlich?
Wenn du den HTTP Modus (die IP wo der ebusd läuft eingeben + Port) nutzen willst, dann erhältst du ja nur eine grafische Ausgabe (siehe Bild).
Ich glaube du solltest in erster Linie einmal diesen Thread hier lesen (http://forum.fhem.de/index.php?topic=46098.0), dann wird dir vieles klarer was du jetzt mit den Daten anfangen kannst. Außerdem gibt es hier noch einen Installer (http://forum.fhem.de/index.php/topic,46098.msg405704.html#msg405704) der dir einige Arbeit abnehmen kann. Um Daten abzufragen auszuwerten gibt es ECMD und GAEBUS, beides ist im obigen Link beschrieben und einfach zu konfigurieren.
LG
Reinhart
Hallo Reinhart,
also eigentlich ist JSON gar nicht schlecht und schon gar nicht umständlich. :-) Ich möchte ja auch nicht mit fhem daran.
Laut edusd Doku (https://github.com/john30/ebusd/wiki) liefert der Daemon über die http-Schnittstelle die JSON-Datei:
ZitatIn addition to the command line style client interface, ebusd also supports an HTTP port serving the data in JSON format.
Gruß
Maik
Hallo Maik,
ein paar Beispiele findest Du hier (https://github.com/john30/ebusd/tree/master/contrib/html) (Den Inhalt einfach in das Verzeichnis: /var/lib/ebusd/html kopieren).
Viele Grüße
Arthur
Zitat von: istler am 26 Februar 2016, 13:54:44
also eigentlich ist JSON gar nicht schlecht und schon gar nicht umständlich. :-) Ich möchte ja auch nicht mit fhem daran.
Laut edusd Doku (https://github.com/john30/ebusd/wiki) liefert der Daemon über die http-Schnittstelle die JSON-Datei:
der HTTP Port im ebusd ist noch eher als experimentell zu bezeichnen. Bisher bin ich nur dazu gekommen, damit meine WP und zwei Heizkreise zu visualisieren, die dynamische Färbung der verbundenen Rohre ist im jetzigen Stand irgendwann wieder verloren gegangen. Ich komme leider nicht dazu, das Interface zu vervollständigen.
Hallo John,
danke für die Rückmeldung. Eigentlich war ich nur an den JSON-Output interessiert. ABER der Visualisierung finde ich auch sehr spannend! :)
Was mir auf gefallen ist beim ebusd 2.0:
Einige Variablen sind jetzt vollständig mit Namen versehen, z.B.:
"broadcast": {
"datetime":
{
"lastup": 1456588814,
"zz": "fe",
"fields":
{
"outsidetemp":
{
"value": 4.938
},
"time":
{
"value": "17:00:00"
},
"date":
{
"value": "27.02.2016"
}
},
"passive": true,
"write": false
}
},
Da sind in der JSON-Struktur nun keine Zahlen mehr in den Fields-Bezeichnern vorhanden sondern die Namen, deshalb läuft dein HTML bzw. JS-Script ins leere. In der Zeile wo du nun die Werte abholst um sie zu aktualisieren und die "parts" überprüfst (ab Zeile 253 in der index.html):
var buildText = function(parts, fields) {
var ret = '';
if (parts) {
parts = parts.split(' ');
for (var i=0; i<parts.length; i++) {
if (ret.length>0) ret += ', ';
if (isNaN(parts[i])) {
if (parts[i]=='\\n')
ret += "<br>";
else
ret += parts[i];
} else if (fields && fields.hasOwnProperty(parts[i])){
var field = fields[parts[i]];
ret += field.hasOwnProperty('value')&&field.value!=null?field.value:'?';
if (field.unit) {
ret += ' '+field.unit;
}
} else {
ret += '?';
}
}
} else if (fields) {
for (var i=0; i<fields.length; i++) {
if (ret.length>0) ret += ', ';
var field = fields[i];
ret += field.hasOwnProperty('value')&&field.value!=null?field.value:'?';
if (field && field.unit) {
ret += ' '+field.unit;
}
}
} else {
ret += '?';
}
return ret;
Nun wird statt der Zahlen die eigentlichen Feld-Namen angezeigt....
Evtl. klappt ja deswegen einigen Sachen nicht mehr z. B. DCF-Empfänger / Außenfühler.
Gruß
Maik
Hallo John,
ich kämpfe mit einem komplett neuen Ansatz zum Holen der Werte aus ebusd. Habe aber ein Problem bei telnet-Verbindungen, die FHEM aufmacht.
Eine manuelle telnet-Verbindung und Absetzen des Kommandos "read FlowTemp" geht problemlos.
Ebenso das Auslesen mit ebusct und dem Kommando "read FlowTemp". Also wird der Bus prinzipiell ordentlich gelesen und geschrieben.
Wenn ich aber aus dem perl-Programm mit telnet auf den betreffenden Port gehe, bekomme ich regelmäßig ein
Zitat2016-02-28 17:16:26.269 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-02-28 17:16:28.296 [bus debug] ERR: read timeout during receive command ACK, switching to skip
Hast Du irgendeinen Vorschlag, den ich noch ausprobieren kann ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 28 Februar 2016, 17:26:58
Wenn ich aber aus dem perl-Programm mit telnet auf den betreffenden Port gehe, bekomme ich regelmäßig ein
Hast Du irgendeinen Vorschlag, den ich noch ausprobieren kann ?
Hm, das klingt so, als würdest Du den Empfänger überlasten. Es sei denn er versteht die Anfrage grundsätzlich nicht.
Bist Du sicher, dass das manuell initiierte Kommando genau dem über Perl initiierten entspricht?
Es sieht tatsächlich so aus, als ob über die perl-telnet-Verbindung irgendetwas gefressen wird.
Ich habe es jetzt noch einmal mit der Angabe des Circuit versucht. Zuerst manuell:
Zitatebusctl read -c bai00 FlowTemp
50.38;ok
gibt das richtige Resultat. Über ECMD/ECMDDevice hingegen:
Zitat2016.02.29 13:11:59 5: ECMDDevice: Analyze command >{"read -c bai00 FlowTemp\n\000read -c bai00 FillPressure"}<
2016.02.29 13:11:59 5: EBUS: command split into 2 parts.
2016.02.29 13:11:59 5: EBUS: sending command "read -c bai00 FlowTemp\n"
2016.02.29 13:11:59 5: SW: 72656164202d6320626169303020466c6f7754656d700a
2016.02.29 13:11:59 1: EBUS: unexpected answer "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n or: read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n -f force reading from the bus (same as '-m 0')\n -m SECONDS only return cached value if age is less than SECONDS [300]\n -c CIRCUIT limit to messages of CIRCUIT\n -d ZZ override destination address ZZ\n -p PRIO set the message poll priority (1-9)\n -v be verbose (include circuit, name, field names, units, and comments)\n -n use numeric value of value=name pairs\n -i VALUE read additional message parameters from VALUE\n NAME the NAME of the message to send\n FIELD only retrieve the field named FIELD\n N only retrieve the N'th field named FIELD (0-based)\n -h send hex read message (or answer from cache):\n ZZ destination address\n PB SB primary/secondary command byte\n NN number of following data bytes\n Dx the data byte(s) to send\n\n" received (wrote "read -c bai00 FlowTemp\n", expected .*\n*)
2016.02.29 13:11:59 5: EBUS: received answer "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n or: read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n -f force reading from the bus (same as '-m 0')\n -m SECONDS only return cached value if age is less than SECONDS [300]\n -c CIRCUIT limit to messages of CIRCUIT\n -d ZZ override destination address ZZ\n -p PRIO set the message poll priority (1-9)\n -v be verbose (include circuit, name, field names, units, and comments)\n -n use numeric value of value=name pairs\n -i VALUE read additional message parameters from VALUE\n NAME the NAME of the message to send\n FIELD only retrieve the field named FIELD\n N only retrieve the N'th field named FIELD (0-based)\n -h send hex read message (or answer from cache):\n ZZ destination address\n PB SB primary/secondary command byte\n NN number of following data bytes\n Dx the data byte(s) to send\n\n"
2016.02.29 13:11:59 5: EBUS: sending command "read -c bai00 FillPressure"
2016.02.29 13:11:59 5: SW: 72656164202d632062616930302046696c6c5072657373757265
2016.02.29 13:12:04 2: EBUS: first attempt to read timed out, trying to close and open the device.
2016.02.29 13:12:04 3: Opening EBUS device 192.168.0.195:8888
2016.02.29 13:12:04 3: EBUS device opened
2016.02.29 13:12:04 5: SW: 72656164202d632062616930302046696c6c5072657373757265
2016.02.29 13:12:09 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2016.02.29 13:12:09 1: EBUS: no answer received (wrote "read -c bai00 FillPressure", expected .*\n*)
2016.02.29 13:12:09 5: EBUS: received answer ""
2016.02.29 13:12:09 5: Postprocessing "usage: read [-f] [-m SECONDS] [-c CIRCUIT] [-d ZZ] [-p PRIO] [-v] [-n] [-i VALUE[;VALUE]*] NAME [FIELD[.N]]\n or: read [-f] [-m SECONDS] [-c CIRCUIT] -h ZZPBSBNNDx\n Read value(s) or hex message.\n -f force reading from the bus (same as '-m 0')\n -m SECONDS only return cached value if age is less than SECONDS [300]\n -c CIRCUIT limit to messages of CIRCUIT\n -d ZZ override destination address ZZ\n -p PRIO set the message poll priority (1-9)\n -v be verbose (include circuit, name, field names, units, and comments)\n -n use numeric value of value=name pairs\n -i VALUE read additional message parameters from VALUE\n NAME the NAME of the message to send\n FIELD only retrieve the field named FIELD\n N only retrieve the N'th field named FIELD (0-based)\n -h send hex read message (or answer from cache):\n ZZ destination address\n PB SB primary/secondary command byte\n NN number of following data bytes\n Dx the data byte(s) to send\n\n" with perl command { Vaillant_HC_stateboiler_postproc("HK.Hz",$_) }.
2016.02.29 13:12:09 1: PERL WARNING: Argument "usage:" isn't numeric in sprintf at /opt/fhem/FHEM/99_myUtils.pm line 107.
2016.02.29 13:12:09 1: PERL WARNING: Argument "[-m" isn't numeric in sprintf at /opt/fhem/FHEM/99_myUtils.pm line 108.
2016.02.29 13:12:09 5: Postprocessed value is "VL.T 0.00 °C, p 0.00 bar".
LG
pah
Es werden 2 reads aufgerufen. Beim 2. fehlt scheinbar ein \n am Ende.
Bei mir funktioniert:
get T.PrECount cmd {"read -f -c bai PrEnergyCountHc1\n\000read -f -c bai PrEnergyCountHwc1\n"}
ZitatEs werden 2 reads aufgerufen. Beim 2. fehlt scheinbar ein \n am Ende.
Bei mir funktioniert:
get T.PrECount cmd {"read -f -c bai PrEnergyCountHc1\n\000read -f -c bai PrEnergyCountHwc1\n"}
Ich nehme das mal witzig - schon mal nachgesehen, wer diesem Thread initiiert und die Ankopplung mit ECMD realisiert hat ?
Im Übrigen ist die Antwort auch nicht richtig.
LG
pah
@pah
ich habe gerade versucht so eine durch Seperator getrennte Abfrage durchzuführen und das funktioniert bei mir soweit ohne Fehlermeldung.
Allerdings kann ich mit deinen exakten Parametern nicht testen.
Verwendest du eine modifizierte bai00.csv in deinen Configs? Den in der 08.bai.x von John gibt es ja keinen "FillPressure", John hat den nun "Waterpressure" getauft und mit dem habe ich es getestet.
EBUS: no answer received (wrote "read -c bai00 FillPressure", expected .*\n*)
für mich sieht das in deiner Abfrage so aus als wäre der "FillPressure" tatsächlich nicht vorhanden, kann mich aber auch täuschen, denn wenn ich Fillpressure einsetze dann bekomme ich etwas andere Fehlermeldungen.
LG
Natürlich benutze ich einen anderen Satz von CSV-Dateien - von Hand getunt bezüglich der Bezeichnungen. Daran liegt es aber nicht, wie man an der korrekten Abfrage (auch von FillPressure, und auch von kombinierten Kommandos) im direkten telnet sieht.
Auch nicht daran, dass dies ein zweiter Raspberry ist, der mit einem zweiten EBUS-Interface mit unterschiedlicher Adresse auf denselben eBus wie mein Hauptinterface lauscht.
Sondern der Fehler steckt irgendwo im Zusammenspiel von einer zweiten FHEM -Installation mit neuem Perl mit dem neuen Jessie-Betriebssystem als Client und dem Raspberry Pi mit neuem Jessie-Betriebssystem und EBUS-Interface als Server.
LG
pah
Edit: Habe es gelöst. War ein Problem der Timeouts auf einem wesentlich schnelleren Rechner. Danke für die Anteilnahme
Hallo und guten Abend,
ich habe mich durch FHEM so weit durchgekämpft dass das Ganze läuft und schon mal so ungefähr aussieht wie ich es gerne hätte :D
Einen Screenshot meiner FHEM-Oberfläche habe ich mal angehängt.
Auf der linken Seite soll die Beschreibung ( das habe ich hin bekommen ) und auf der rechten Seite möchte ich nur die Temperatur / den Wert stehen haben und das bekomme ich nicht hin. Die Variable wird immer mit angezeigt :(
Dass nur noch eine Kommastelle und "°C" nach der Temperatur angezeigt wird habe ich schon hinbekommen ;D
Ich habe schon viel gegooglet und gelesen komme aber nicht dahinter wie ich das hin bekomme oder ob es eventuell überhaupt nicht geht.
Für einen Tipp oder die Info dass es nicht geht wäre ich dankbar.
LG
Thomas
#!/usr/bin/perl
# Aussentemperatur
get AT cmd {"r -f outsidetemp temp\n"}
get AT expect ".*\n*"
get AT postproc {sprintf("%.1f °C",$_) }
#
# vorlauftemperatur
get VT cmd {"r -f HcFlowTemp temp\n"}
get VT expect "\d+\.\d+\n\n"
get VT postproc { sprintf("%.1f °C",$_) }
#
# Ruecklauftemperatur
get RT cmd {"r -f HcReturnTemp temp\n"}
get RT expect "\d+\.\d+\n\n"
get RT postproc { sprintf("%.1f °C",$_) }
#
# Speichertemperatur_oben
get SO cmd {"r -f StorageTempTop\n"}
get SO expect "\d+\n\n"
get SO postproc { sprintf("%.1f °C",$_) }
#
Hi Thomas,
ich hab auch immer mit den expects und postprocs gekämpft, aber ich habe das (sicher nicht ganz stilgerecht, aber funktionierend) mit substr(_$,Anfang,Anzahl Zeichen) hinbekommen...
Aber bestimmt hat hier jemand eine Idee, wie das stilgerecht geht,
Grüße
Christian
Es ist viel zu kompliziert, das in der *.cfg Datei zu warten.
Der Trick besteht also darin, im postproc nur eine Perl-Routine zu rufen, die den Ergebnisstring mit split komplett zerlegt und dann auf einzelne readings verteilt.
Ein älteres Beispiel von mir dazu findet sich in contrib/EBUS, bzw. hier: https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/EBUS/Vaillant_routines.pl.
In meiner aktuell laufenden Installation habe ich das deutlich weiter entwickelt, es dauert aber noch etwas, bis ich das allgemein zur Verfügung stelle.
LG
pah
Zitat von: hasenhirn am 01 März 2016, 22:10:52
Auf der linken Seite soll die Beschreibung ( das habe ich hin bekommen ) und auf der rechten Seite möchte ich nur die Temperatur / den Wert stehen haben und das bekomme ich nicht hin. Die Variable wird immer mit angezeigt :(
Du kannst mit stateFormat arbeiten.
Beispiel für Aussentemperatur (einfach in FHEMWEB-command eingeben):
attr AT stateFormat {sprintf("%.1f °C", ReadingsVal($name,"AT",0))}Viele Grüße
Arthur
Danke für eure Antworten :)
Wenn ich heute Abend nach Hause komme werde ich es mal ausprobieren.
Gruß
Thomas
da du ja schon die Zahl formatiert hast, einfach stateformat auf das Reading "Aussentemp", dann wird dieses Reading in "state" gesetzt.
Amunra hat es dir mit Formatierung gepostet, dann kannst die Formatierung in der bai00.cfg weglassen, es gibt immer viele Wege die zum Ziel führen.
#AussenTemp.
define Aussentemp ECMDDevice bai00.class
attr Aussentemp IODev EBUS
attr Aussentemp group Vaillant
attr Aussentemp icon temp_outside
attr Aussentemp room Vaillant
attr Aussentemp stateFormat Aussentemp
hier ein Beispiel mit der Aussentemperatur
LG
Hallo Reinhart,
vielen Dank! Das habe ich sogar auf dem Handy hin bekommen ;D
Es ist halt manchmal ganz einfach wenn man weiß wie ;)
Ich habe mehrere Tage gegooglet und im Forum gesucht aber nichts passendes gefunden :o
Naja, dabei habe ich aber viele neue Ideen und Anregungen für mein FHEM gefunden.
Gruß
Thomas
wow interessantes Projekt
ich suche schon seit ein paar Jahren eine Möglichkeit meine vailad Heizung vkk2264 zu überwachen und einzustellen.
jetzt habe ich schon einen teil des Beitrags gelesen und auch die Wiki.
kann man die Platine bei einem von euch bestellen?
rennt das ganze bei euch stabil?
im voraus danke für eure Infos
Gruß Frank
Hallo Frank,
willkommen an Bord.
Ich stehe zwar auch noch am Anfang aber der ebusd läuft bei mir sehr stabil.
Meine Platine habe ich von "Helmut H. (der_andere)" aus dem mikrocontroller-Forum https://www.mikrocontroller.net/topic/346833 (https://www.mikrocontroller.net/topic/346833) und die Teile von Reichelt.
Das Löten des SMD-Bausteins war für mich zu schwierig und zum Glück hatte ich einen Freund der das für mich erledigt hat ;D
Björn hatte auch noch fertige Platinen, war mir aber zu teuer da ich 3 Stück brauchte :D
Es gibt im Netz auch noch Platinen mit anderem Layout bei denen der USB/Serial-Chip mit einer fertigen Platine ( ca. 5€ bei ebay usw. ) angebunden wird.
Ich hoffe ich konnte dir etwas weiter helfen ;)
Gruß
Thomas
danke Thomas,
das hilft mir schon viel weiter.
ich hab von vailand nichts vernünftiges gefunden.
Grunsätzlich will ich nur sehn was die Heizung treibt, wie hoch der druck ist und eventuell wärmer oder kälter stellen
Zitat von: klenn am 08 März 2016, 11:35:08
kann man die Platine bei einem von euch bestellen?
hier (https://forum.fhem.de/index.php/topic,49744.0.html) läuft noch eine Sammelbestellung.
danke für die info
habe ihm gleich schon geschrieben:-)
Zitat von: john30 am 20 Februar 2016, 14:54:00
So langsam kommt Licht ins Dunkel der BAIs!
Das unerfreuliche: Mit einer BAI ist alles wieder gaaanz anders :(
Hier hängt die CSV nicht nur von ID, HW und SW aus dem Ident Telegramm ab, sondern zusätzlich auch noch von der Produktnummer sowie einer zweiten Softwareversion.
Das macht die Angelegenheit sehr eklig und ich überlege noch, wie ich das am besten in die CSVs einkippen kann.
Andererseits gibt es noch eine erfreuliche Nachricht: aus der MDB lassen sich mit dieser Erkenntnis 12 verschiedene CSVs für jeweils unterschiedliche BAIs extrahieren :)
So ganz 100%ig sicher bin ich aber noch nicht, ob das alles stimmt. Es ist z.B. unklar, ob wirklich nur die 12 unterstützt werden, oder alle mit gleicher zweiter Softwareversion. Dazu wird es evtl. mal eine Versuchsreihe geben müssen.
I'll keep you posted!
Hat ein bisschen gedauert, aber jetzt kann ebusd das, was für eine automatische Konfiguration der BAI notwendig ist.
Unter https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant) gibt es eine experimentelle Version der neuen produktspezifischen scanconfig, die mit dem letzten commit https://github.com/john30/ebusd/commit/6e6e05c (https://github.com/john30/ebusd/commit/6e6e05c) in ebusd funktioniert (nicht mit älteren Versionen!).
Jetzt bräuchte es nur noch Versuchskaninchen, die das mal ausprobieren möchten.
Kurz zur Erklärung: Der Trick beim Laden der CSV ist, dass mit den ebusd-2.1.x CSVs nur eine generische "08.bai.csv" geladen wird, die dann anghängig vom Produktcode aus dem Vaillant-spezifischen Scan die richtige "<produktid>.inc" nachlädt.
Ach ja, mir fällt gerade auf, dass die "*.inc" noch nicht final sind, weil die Abfrage der SW Version noch nicht stimmt. Aber zum Testen des Grundprinzips sollten sie schon einge gute Basis bilden.
VG John
Hallo John!
Danke für die neue (Test)Version!
Ich habe sie mir geladen und compiliert, auch die neuen Configs für 2.1.
Mir fällt soweit nichts negatives auf, außer im Log kommen beim "poll scan 08." ein paar Buserrors. Meine Geräte (Therme und Calormatic 430) hat er alle richtig gefunden.
Der Rest scheint alles zu funktionieren und ich musste in Fhem keine Änderungen in der Parametrierung durchführen.
hier das Log eines Neustarts des eBusd.
2016-03-14 10:27:27.548 [main notice] ebusd 2.0.6e6e05c started
2016-03-14 10:27:27.583 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2016-03-14 10:27:27.626 [bus notice] signal acquired
2016-03-14 10:27:30.988 [bus notice] new master 10, master count 2
2016-03-14 10:27:31.027 [bus notice] new master 03, master count 3
2016-03-14 10:27:31.027 [update notice] unknown MS cmd: 1008b51009000066ffffff04ff00 / 0101
2016-03-14 10:27:35.059 [update notice] unknown MS cmd: 1008b5110101 / 096456400466640100ff
2016-03-14 10:27:37.043 [update notice] unknown MS cmd: 1008b5110102 / 05033c8c466a
2016-03-14 10:27:37.877 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2016-03-14 10:27:37.908 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-03-14 10:27:37.942 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2016-03-14 10:27:38.465 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:27:38.483 [main notice] found messages: 209 (3 conditional on 15 conditions, 1 poll, 8 update)
2016-03-14 10:27:40.914 [main notice] read scan config file /etc/ebusd/vaillant/15.430.csv for ID "43000", SW0215, HW2002
2016-03-14 10:27:40.915 [main notice] found messages: 426 (17 conditional on 21 conditions, 1 poll, 8 update)
2016-03-14 10:27:41.089 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:27:43.728 [bus notice] poll scan.08 id:
2016-03-14 10:27:45.109 [update notice] update bai Status01 QQ=10: 51.0;43.0;4.250;51.0;50.0;on
2016-03-14 10:27:47.150 [update notice] update bai DateTime QQ=10: nosignal;22:32:15;-.-.-;4.250
2016-03-14 10:27:47.366 [update notice] unknown BC cmd: 10feb505020400
2016-03-14 10:27:49.832 [bus notice] poll scan.08 id:
2016-03-14 10:27:51.171 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:27:55.771 [bus notice] poll scan.08 id:
2016-03-14 10:27:56.004 [bus notice] max. symbols per second: 111
2016-03-14 10:27:59.239 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:28:01.735 [bus notice] poll scan.08 id:
2016-03-14 10:28:05.279 [update notice] update bai Status01 QQ=10: 51.0;43.0;4.250;51.0;50.0;on
2016-03-14 10:28:08.519 [bus notice] poll scan.08 id:
2016-03-14 10:28:09.299 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:28:13.719 [bus notice] poll scan.08 id:
2016-03-14 10:28:15.369 [update notice] update bai Status01 QQ=10: 54.0;42.0;4.250;42.0;50.0;overrun
2016-03-14 10:28:20.066 [bus notice] poll scan.08 id:
2016-03-14 10:28:20.310 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:28:20.551 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-03-14 10:28:26.247 [bus notice] poll scan.08 id:
2016-03-14 10:28:30.339 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:28:31.700 [bus notice] poll scan.08 id:
2016-03-14 10:28:35.461 [update notice] update bai Status01 QQ=10: 53.0;51.0;4.250;44.0;48.0;off
2016-03-14 10:28:37.740 [bus notice] poll scan.08 id:
2016-03-14 10:28:39.477 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:28:43.789 [bus notice] poll scan.08 id:
2016-03-14 10:28:44.027 [bus notice] max. symbols per second: 112
2016-03-14 10:28:45.469 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:28:49.797 [bus notice] poll scan.08 id:
2016-03-14 10:28:53.491 [update notice] update bai Status01 QQ=10: 50.0;41.0;4.250;44.0;48.0;off
2016-03-14 10:28:54.469 [bus error] send to 15: ERR: ACK error, retry
2016-03-14 10:28:55.865 [bus notice] poll scan.08 id:
2016-03-14 10:28:57.969 [update notice] update bai DateTime QQ=10: nosignal;22:33:28;-.-.-;4.250
2016-03-14 10:28:58.181 [update notice] unknown BC cmd: 10feb505020400
2016-03-14 10:28:59.999 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:01.736 [bus notice] poll scan.08 id:
2016-03-14 10:29:03.969 [update notice] update bai Status01 QQ=10: 43.0;41.0;4.500;44.0;48.0;off
2016-03-14 10:29:07.756 [bus notice] poll scan.08 id:
2016-03-14 10:29:08.005 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:13.720 [bus notice] poll scan.08 id:
2016-03-14 10:29:13.969 [update notice] update bai Status01 QQ=10: 42.0;41.0;4.250;44.0;47.0;off
2016-03-14 10:29:15.975 [update notice] update broadcast vdatetime QQ=10: 10:22:39;14.03.2016
2016-03-14 10:29:16.226 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-03-14 10:29:18.030 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:19.049 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:29:24.013 [update notice] update bai Status01 QQ=10: 43.0;41.0;4.250;44.0;47.0;on
2016-03-14 10:29:25.711 [bus notice] poll scan.08 id:
2016-03-14 10:29:26.019 [update notice] update bai DateTime QQ=10: nosignal;22:33:57;-.-.-;4.250
2016-03-14 10:29:26.281 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:29:28.009 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:31.071 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:29:34.012 [update notice] update bai Status01 QQ=10: 51.0;41.0;4.250;44.0;47.0;on
2016-03-14 10:29:35.951 [update notice] update broadcast outsidetemp QQ=10: 2.250
2016-03-14 10:29:37.741 [bus notice] poll scan.08 id:
2016-03-14 10:29:38.034 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:43.073 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:29:44.059 [update notice] update bai Status01 QQ=10: 53.0;42.0;4.250;44.0;47.0;on
2016-03-14 10:29:46.029 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:29:48.029 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:29:49.732 [bus notice] poll scan.08 id:
2016-03-14 10:29:54.049 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:29:55.739 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:29:56.452 [update notice] update bai DateTime QQ=10: nosignal;22:34:28;-.-.-;4.250
2016-03-14 10:29:56.655 [update notice] unknown BC cmd: 10feb505020400
2016-03-14 10:29:58.039 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:01.709 [bus notice] poll scan.08 id:
2016-03-14 10:30:02.059 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:07.744 [bus notice] poll scan.08 id:
2016-03-14 10:30:08.060 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:12.079 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:13.135 [bus error] poll scan.08 id failed: ERR: read timeout
2016-03-14 10:30:14.192 [update notice] update broadcast vdatetime QQ=10: 10:23:37;14.03.2016
2016-03-14 10:30:14.448 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-03-14 10:30:18.079 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:19.730 [bus notice] poll scan.08 id:
2016-03-14 10:30:22.102 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:24.369 [update notice] update bai DateTime QQ=10: nosignal;22:34:57;-.-.-;4.250
2016-03-14 10:30:24.630 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:30:25.744 [bus notice] poll scan.08 id:
2016-03-14 10:30:28.079 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:31.737 [bus notice] poll scan.08 id:
2016-03-14 10:30:32.078 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:34.020 [update notice] update broadcast outsidetemp QQ=10: 2.250
2016-03-14 10:30:37.733 [bus notice] poll scan.08 id:
2016-03-14 10:30:38.089 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:42.109 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:43.697 [bus notice] poll scan.08 id:
2016-03-14 10:30:44.120 [update notice] update bai Status02 QQ=10: auto;60;70.0;70;53.0
2016-03-14 10:30:46.108 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:30:49.740 [bus notice] poll scan.08 id:
2016-03-14 10:30:52.109 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:30:54.866 [update notice] update bai DateTime QQ=10: nosignal;22:35:28;-.-.-;4.250
2016-03-14 10:30:55.171 [update notice] unknown BC cmd: 10feb505020400
2016-03-14 10:30:55.887 [bus notice] poll scan.08 id:
2016-03-14 10:30:56.145 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:31:01.715 [bus notice] poll scan.08 id:
2016-03-14 10:31:02.159 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:31:06.149 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:31:07.741 [bus notice] poll scan.08 id:
2016-03-14 10:31:12.155 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;44.0;47.0;on
2016-03-14 10:31:13.042 [bus error] poll scan.08 id failed: ERR: invalid argument
2016-03-14 10:31:14.145 [update notice] update broadcast vdatetime QQ=10: 10:24:37;14.03.2016
2016-03-14 10:31:14.393 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-03-14 10:31:16.179 [update notice] update bai Mode QQ=10: standby
2016-03-14 10:31:19.877 [bus notice] poll scan.08 id:
2016-03-14 10:31:24.653 [update notice] update bai Status01 QQ=10: 53.0;43.0;4.250;43.0;47.0;on
2016-03-14 10:31:24.941 [update notice] update bai DateTime QQ=10: nosignal;22:35:59;-.-.-;4.250
2016-03-14 10:31:25.073 [bus error] poll scan.08 id failed: ERR: invalid argument
und hier die Info:
pi@raspberry2 /etc/ebusd/vaillant $ ebusctl info
version: ebusd 2.0.6e6e05c
signal: acquired
symbol rate: 22
masters: 3
messages: 426
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
scanresult
pi@raspberry2 ~ $ ebusctl scan result
1 scan(s) still running
08;Vaillant;BAI00;0518;7401;21;09;13;0010004340;0001;005056;N0
15;Vaillant;43000;0215;2002;21;11;09;0020028515;0907;006374;N5
26;Vaillant;43000;0215;2002
Ich werde die Version so einfach laufen lassen und weiter beobachten.
Soll ich noch irgendwelche Tests durchführen?
LG
Reinhart
Hallo und guten Abend,
ich habe mal wieder einen kleinen "Hänger".
Da ich gerne von verschiedenen Werten einen Graphen / SVGplott erstellen möchte, habe ich einfach mal ein Logfile mit der Außentemperatur gefüttert.
Das habe ich auch soweit hinbekommen und konnte auch den SVGplott erstellen. Beim stöbern in den Anleitungen und im Netz bin ich auf das Kommando "event-on-change-reading" gestoßen und wollte damit die Datenmenge reduzieren. Leider funktioniert das nicht und ich komme da nicht weiter :(
Eventuell kann ja mal jemand ein Auge auf meinen Durcheinander werfen und mir da weiter helfen. :o
Ich muss aber auch zugeben, dass ich bei den ganzen Befehlen noch nicht so richtig durchsteige wie das alles zusammen hängt und wie die Daten da genau von FHEM verarbeitet werden.
Beim einlesen der fhem.cfg kommt immer der Fehler:
FileLog_ATemp: unknown attribute event-on-update-reading. Type 'attr FileLog_ATemp ?' for a detailed list.
Hier mal die Abschnitte aus der fhem.cfg:
define Aussentemp ECMDDevice hzg00.class
attr Aussentemp IODev EBUS_H
attr Aussentemp alias Aussentemperatur
attr Aussentemp group Vaillant
attr Aussentemp icon temp_outside
attr Aussentemp room Vaillant
attr Aussentemp sortby 1
attr Aussentemp stateFormat AT
define EBUS_H.Timer at +*00:05:00 get Aussentemp AT;;get Vorlauf VT;;get Ruecklauf RT;;get Speicheroben SO;;get Speicherunten SU
attr EBUS_H.Timer group Vaillant_Kontrol
attr EBUS_H.Timer icon time_timer
attr EBUS_H.Timer room Vaillant
attr EBUS_H.Timer verbose 3
define ATemp dummy
define ATemperatur at +*00:01:00 { my $d=ReadingsVal ("Aussentemp","AT",0);; fhem("set ATemp $d")}
define FileLog_ATemp FileLog ./log/ATemp-%Y-%m-%d.log Aussentemp
attr FileLog_ATemp room Unsorted
attr FileLog_ATemp event-on-update-reading -*
define SVG_FileLog_ATemp_1 SVG FileLog_ATemp:SVG_FileLog_ATemp_1:CURRENT
attr SVG_FileLog_ATemp_1 label Aussentemperatur
attr SVG_FileLog_ATemp_1 room Vaillant
define SVG_FileLog_ATemp_2 SVG FileLog_ATemp:SVG_FileLog_ATemp_2:CURRENT
attr SVG_FileLog_ATemp_2 label Aussentemperatur
attr SVG_FileLog_ATemp_2 title 1
Ich hoffe es ist nicht all zu schlimm was ich da verbockt habe, aber es funktioniert so weit ;D
Gruß
Thomas
Das Wort "Durcheinander" stammt nicht von mir, aber ich kann mich dem nur anschließen...
1. Leerzeilen und Kommentare in der Konfigurationsdatei = Freund und Helfer
2. Attribut event-on-change-reading muss zu dem Device, dessen Werte eben die Events auslösen sollen (oder auch nicht).
3. Wenn überhaupt ein separates Reading erstellt werden soll, dann Readingsproxy statt Dummy.
4. Braucht es aber gar nicht, denn das FileLog kann direkt auf die Events des ECMDDevice lauschen.
Also bitte noch einmal die Anfängerdoku lesen (Unterschied Events/Attribute/Kommandos verstehen), Dann etwas über Reguläre Ausdrücke nachlesen.
Und diese dann mit dem Event-Monitor ausprobieren.
LG
pah
Guten Morgen ,
danke für die Info. Jetzt weiß ich wenigstens dass es funktioniert und ich nur einen Fehler ( ok, mehrere ;D ) gemacht habe.
Ich werde mir die Doku noch mal durchlesen.
Wie schon geschrieben brauche ich noch etwas bis ich die Zusammenhänge richtig verstehe.
LG
Thomas
@hasenhirn
Wie ich aus deinem Post entnehme, willst du die doppelten Logeinträge vermeiden. Dann finde ich es nicht gerade den richtigen Weg die im nachhinein irgendwie versuchen rauszuhauen. Besser wäre es meiner Meinung die Logeinträge gleich selektiert zu schreiben.
define FileLog_ATemp FileLog ./log/ATemp-%Y-%m-%d.log Aussentemp
du schreibst alle Readings inkl. state in das Log
define FileLog_ATemp FileLog ./log/ATemp-%Y-%m-%d.log Aussentemp:(AT).*
so kannst du nur das Reading "AT" ins Log schreiben, das spart schon 50%.
define FileLog_FHT80b FileLog ./log/fhem-WzFb-%Y.log FHT80b:(measured-temp|desired-temp|actuator).*
ebenso kann man selektiert mehre Readings gezielt ins Log schreiben. Das "|" bedeutet "oder", somit kannst beliebig verknüpfen.
Du könntest auch alle Temperaturen (Aussentemp, Vorlauf, Rücklauf) in nur ein Logfile schreiben wenn du die dann ohnehin in einem Plot darstellen willst (spart Logfiles). Natürlich musst du dann die ECMD Abfragen (nach Muster pah Vaillant) abändern, dann hast du gleich mehrere Readings in einem Define, das ist aber eine andere Baustelle die ich dir jetzt nicht unbedingt zumuten möchte.
LG
Reinhart
Hallo Reinhart,
danke für deine Unterstützung.
pah hat natürlich recht, ich muss mir die Anleitung nochmal durchlesen und genau verstehen was ich da mache.
Ich habe aus verschiedenen Beiträgen aus dem Netz zusammen kopiert und dann so abgeändert dass es irgendwie läuft.
Als ich die Anleitung am Anfang gelesen habe, habe ich natürlich vieles nicht verstanden. Jetzt habe ich schon ein paar Erfahrungen gesammelt und sollte etwas mehr verstehen ;)
Im Nachhinein denke ich mir, dass ich mit meinem Anliegen hier auch im falschen Thread bin. Das gehört wohl eher ins Anfängerforum.
LG
Thomas
@John
das einzige was mir jetzt noch in der 2.1 aufgefallen ist, ich musste in der "bai.308523.inc" d.14 und d.15 hineinkopieren, weil ich keine Daten über die PumpPower bekommen habe da die in der Datei fehlten.
r,,PumpPowerDesired,d.14 => Leistung Heizungspumpe Soll,,,,0A04,,,UCH,0=auto;1=53;2=60;3=70;4=85;5=100,%,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,,PumpPower,d.15 => Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
LG
Reinhart
Hallo zusammen,
kann mir jemand die Conditions auf dem ebusd erklären?
Im Detail geht es um die TEV-Eintrittstemperatur meiner Wärmepumpe am EHP Curcuit:
Zitat[brinetowater]r;u,,CondensorTemp,TEV-Eintritt,,,,"0D00",,,tempsensor,,,TEV-Eintritt: Temperatur am Eintritt des thermischen Expansionsventils,,,
[watertowater]r;u,,CondensorTemp,TEV-Eintritt,,,,"0D00",,,tempsensor,,,TEV-Eintritt: Temperatur am Eintritt des thermischen Expansionsventils,,,
[airtobrinetowater]r;u,,CondensorTemp,TEV-Eintritt,,,,"0D00",,,tempsensor,,,TEV-Eintritt: Temperatur am Eintritt des thermischen Expansionsventils,,,
Zitat
ebusctl r -f -c ehp CondensorTemp
Liefert immer ERR not found!
Ich habe mir bereits den Wiki-Beitrag von John durchgelesen. Leider für mich nicht schlüssig :(
https://github.com/john30/ebusd/wiki/4.5.-Conditions (https://github.com/john30/ebusd/wiki/4.5.-Conditions)
Wie muss ich den Command zusammenbauen/absetzen, damit ich hier einen validen Wert vom Bus bekomme?
Danke.
Marie
Meine EBUS Adapter Platinen werden wohl diese Woche geliefert (aus einer anderen Sammelbestellung).
Dazu meine Frage, wie sieht es denn mit EBUS WLAN Anbindung mittlerweile aus?
Über ESP8266 oder Hi-link HLK-RM04 oder garnicht?
Ein Tipp in Richtung Anleitung oder schau mal dort wäre nicht schlecht.
Das ESP8266 Forum hier gibt in dieser Richtung leider nichts her und im net hatte ich Richtung EBUS auch nichts wirklich hilfreiches gefunden.
Schnitzelbrain
Zitat von: Marie01 am 22 März 2016, 15:22:24
kann mir jemand die Conditions auf dem ebusd erklären?
Im Detail geht es um die TEV-Eintrittstemperatur meiner Wärmepumpe am EHP Curcuit:
Liefert immer ERR not found!
Ich habe mir bereits den Wiki-Beitrag von John durchgelesen. Leider für mich nicht schlüssig :(
https://github.com/john30/ebusd/wiki/4.5.-Conditions (https://github.com/john30/ebusd/wiki/4.5.-Conditions)
Wie muss ich den Command zusammenbauen/absetzen, damit ich hier einen validen Wert vom Bus bekomme?
Die Messages sind nur dann für das Gerät gültig, wenn die in eckigen Klammern vorangestelleten Bedingungen erfüllt sind.
Deine EHP muss also entweder eine brinetowater, einer watertowater oder eine airtobrinetowater sein.
Diese drei Bedingungen hängen, wie weiter oben in der CSV definiert, vom Wert des ApplianceCode ab.
Mach doch mal ein "ebusctl read -c ehp ApplianceCode".
Wenn das Ergebnis nicht zwischen 4 und 10,16 und 22, oder 35 und 39 liegt, dann erfüllt Deine Anlage keine der Bedigungen und somit ist die Nachricht CondensorTemp bei Dir nicht verfügbar.
Zitat von: schnitzelbrain am 22 März 2016, 19:42:00
Meine EBUS Adapter Platinen werden wohl diese Woche geliefert (aus einer anderen Sammelbestellung).
Dazu meine Frage, wie sieht es denn mit EBUS WLAN Anbindung mittlerweile aus?
Kurze Antwort: es gibt keine, weil man dafür einach den richtigen Adapter nimmt.
Lange Antwort: wenn Du einen Adapter WLAN zu serial hast, könnte es funktionieren.
Wenn Du den so konfigurieren kannst, dass einfach ein TCP Port auf der IP-Adresse des Adapters offen ist, dann kann sich ebusd mit Option "-d IP:PORT" direkt damit verbinden.
Habe mir gerade selbst zwei LAN zu serial Adapter bestellt, die im Prinzip das gleiche leisten sollten.
Ob WLAN oder LAN macht also keinen rieisigen Unterschied.
Allerdings gibt es in beiden Varianten Latenzprobleme, die zu Kommunikationsfehlern führen können.
Servus John!
ApplianceCode 42
Mit vrDialog bekomm ich den TEV Eintritt angezeigt.
https://www.dropbox.com/s/jw4z28amlho2uh5/Messwerte%20Schalter%20und%20Informationen.PNG?dl=0
Marie
Zitat von: john30 am 22 März 2016, 20:33:38
Kurze Antwort: es gibt keine, weil man dafür einach den richtigen Adapter nimmt.
Lange Antwort: wenn Du einen Adapter WLAN zu serial hast, könnte es funktionieren.
Wenn Du den so konfigurieren kannst, dass einfach ein TCP Port auf der IP-Adresse des Adapters offen ist, dann kann sich ebusd mit Option "-d IP:PORT" direkt damit verbinden.
Habe mir gerade selbst zwei LAN zu serial Adapter bestellt, die im Prinzip das gleiche leisten sollten.
Ob WLAN oder LAN macht also keinen rieisigen Unterschied.
Allerdings gibt es in beiden Varianten Latenzprobleme, die zu Kommunikationsfehlern führen können.
Mit meiner Frage
"Über ESP8266 oder Hi-link HLK-RM04 oder garnicht?"
meinte ich ja den EBUS Adapter um die Fähigkeit Lan/WLAN zu erweitern.
Ich könnte natürlich auch, wie vorgeschlagen, fertige Wandler/Adapter bestellen.
Aber das ist mir dann doch zu teuer.
Da pah in dem Thread auf die Möglichkeit mit dem ESP8266 hingewiesen hatte und ich weitergehend nix gefunden habe wollte ich eben Nachfragen.
Grüße
Schnitzelbrain
Ich glaube ehrlich gesagt kein Wort.
Unter dem Suchbegriff "ESP8266 Serial" gibt es 448.000 Hits bei Google - und ein erklecklicher Anteil davon befasst sich mit der Frage, wie man mithilfe des ESP8266 eine WLAN-Serial-Bridge betreiben kann.
Also sollte "schnitzelbrain" mal sein Schnitzel re-animieren (sofern möglich) und sich im Netz umschauen.
Ich werde das jedenfalls nicht weiter verfolgen, weil ich es nicht für sinnvoll halte. Der eBus produziert so viel Traffic, dass man den erst durch den ebusd abfangen sollte - und damit ist die Anordnung eines eigenen Raspberry Pi direkt neben Heizung und Adapter der sinnvolle Weg.
LG
pah
Ich liebe einfach den Umgangston mit dem man hier auf eine Frage Antwort bekommt.
Der zweite Teil hätte genügt der erste Teil ist Polemik.
Aber so ist das eben wenn man die Götter erzürnt. Ich neige mein Haupt und gelobe nie wieder eine Frage zu stellen.
Übrigens sitzt hier kein kleiner Junge . Wenn mir die Suche über Google trotz meiner 50 Jahre vielleicht nicht die Antwort gibt mit der ich etwas anfangen kann und dazu noch ein Kommentar im Forum steht, dann erlaube ich mir einfach zu fragen.
Wenn ihr das nicht wollt macht das Forum zu.
Danke für die Info!
Liebe FHEM`ler,
nach rd. 1 Woche probieren, üben und nachlesen möchte ich heute einige Fragen stellen die ich mir nicht beantworten kann.
Nach längerer Zeit habe ich nun mein Device (E-Service USB ) am laufen. Erste Probleme habe ich gelöst (Netzteil raspberry zu schwach ebus Leitungen vertrauscht). Es scheint, dass jetzt der Abgleich mit meiner Wolf Therme (CBG K 20) kommt. Hier versuche ich jedoch seit Sonntag ein Lösung zu finden.
Die Daten scheinen (wenn auch mit dem ein oder anderen Fehler) sauber einzutreffen
2016-03-23 08:51:32.062 [update notice] update feuerung betrd QQ=10: Brauchwasser_Heizen;Kesselpumpean;64.12;-;-;55.0;-
2016-03-23 08:51:32.355 [update notice] update broadcast betrd QQ=f1: 1;30;-;71.0;-;65;5
2016-03-23 08:51:37.064 [update notice] update feuerung sollw QQ=10: 64.102;5.000;-;03;55.000
2016-03-23 08:51:37.356 [update notice] update broadcast sollw QQ=f1: 64.102;5.000;0;a0;55.000
2016-03-23 08:51:39.275 [update notice] update solar regler QQ=30: 03;26.250;14.0;0.0
2016-03-23 08:51:42.348 [update notice] update broadcast betrd QQ=f1: 1;30;-;71.0;-;65;5
2016-03-23 08:51:47.018 [update notice] update feuerung sollw QQ=10: 64.102;5.000;-;03;55.000
2016-03-23 08:51:47.310 [update notice] update broadcast sollw QQ=f1: 64.102;5.000;0;a0;55.000
und jetzt kommen meine Probleme.
1. Das Gerät (Wolf) wird nicht richtig erkannt, sondern nach dem Befehl ebusctl info wird mein Gerät falsch erkannt (Anhang).
das könnte ja nicht so schlimm sein, aber jetzt kommt mein 2. Problem.
Die Wolf Dateien sind ja im github abgelegt . Ich habe jedoch ein architektonisches Problem und leider keine Lösung dafür gefunden.
2. Wo lege ich die csv´s ab und wie werden diese übersetzt. gibt es hierzu eine Anleitung? Ich habe leider nichts gefunden und ich habe alle 107 Seiten durchgelesen :-)
Danke für Eure Hilfe
Gerd
@schnitzelbrain: Wer versucht, sich der einfachsten Aufgaben - nämlich einer Google-Suche - zu entledigen, darf sich über patzige Antworten nicht wundern. Geholfen wird dem, der sich selbst engagiert. Im Übrigen klingt die Wahl des Nickname nicht nach einem "gestandenen 50-jährigen".
@Gerd.Ternes: Da wird gar nichts übersetzt, diese Dateien stehen so wie sie sind in /etc/ebusd. Mein Tipp: Niemals die CSV-Dateien manuell bearbeiten. Sondern in Open Office oder Excel importieren, und von dort wieder als CSV exportieren. Beispiel-Dateien mit den entsprechenden Makros habe ich gepostet.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 23 März 2016, 09:30:01
@schnitzelbrain: Wer versucht, sich der einfachsten Aufgaben - nämlich einer Google-Suche - zu entledigen, darf sich über patzige Antworten nicht wundern. Geholfen wird dem, der sich selbst engagiert. Im Übrigen klingt die Wahl des Nickname nicht nach einem "gestandenen 50-jährigen".
pah
1. Mein Nick tut hier nix zur Sache (oder doch?. Vielleicht noch mein Wohnort, Beruf usw.) Im ernst jetzt Leute?
2.
ZitatDazu meine Frage, wie sieht es denn mit EBUS WLAN Anbindung mittlerweile aus?
Über ESP8266 oder Hi-link HLK-RM04 oder gar nicht?
Ein Tipp in Richtung Anleitung oder schau mal dort wäre nicht schlecht.
Das ESP8266 Forum hier gibt in dieser Richtung leider nichts her und im net hatte ich Richtung EBUS auch nichts wirklich hilfreiches gefunden.
Mich im ESP8266 Forum schlau gemacht, erledigt.
In Google gesucht (EBUS in Verbindung mit ESP8266) mmmh, wie ich erklärt bekommen habe gibt es 448000 Hits für ESP8266 und Serial. Ich meine auf Seite 2816 war auch eine Bemerkung betreffend EBUS konnte diese leider nicht lesen war weder Englisch noch Deutsch. Der Chip wandelt Serial zu WLAN das wusste ich vorher. Welche Software muss drauf damit das mit dem EBUS funktioniert? Wie spreche ich den Chip richtig an AT Befehle, wie geht das mit FHEM zusammen? Alternative Chips gesucht, gefunden. Weitere Information betreffend EBUS Anbindung so als HowTo, Fehlanzeige.
3. Auf eine Bemerkung von pah gestoßen und demnach eine Frage gestellt.
4. Jetzt weiß ich es. Ich hab nicht bestätigt das ich das Einsteiger PDF gelesen hab. Sorry, ich mach mich gleich dran.
IMAHO gingen die Antworten am Thema und der eigentlich gestellten Frage vorbei.
Das hier hätte vollkommen genügt.
ZitatIch werde das jedenfalls nicht weiter verfolgen, weil ich es nicht für sinnvoll halte. Der eBus produziert so viel Traffic, dass man den erst durch den ebusd abfangen sollte - und damit ist die Anordnung eines eigenen Raspberry Pi direkt neben Heizung und Adapter der sinnvolle Weg.
Das hatte ich nämlich so nicht gesehen, damit kann ich dann auch weiter planen.
Schnitzelbrain
@ Peter: Danke für den Tip, so langsam komme ich (so hoffe ich) hinter die Struktur.
Wenn ich das ganze dann richtig verstanden habe, werden die Daten des ebus dann "übersetzt" ins logfile geschrieben. Das ganze geschieht dann mit Hilfe der *.csv Dateien im Verzeichnis /etc/ebusd .
Die entsprechenden "Übersetzungen" (in meinem Falle von der Wolf Heizung) müsste ich dann aus dem Verzeichnis /etc/ebusd/Wolf ins Verzeichnis /etc/ebusd kopieren.
Daraus entstehen dann die lesbaren Werte:
2016-03-23 12:59:43.116 [update notice] update broadcast betrd QQ=03: 0;40;0;63.0;61;63;7
2016-03-23 12:59:46.944 [update notice] update feuerung sollw QQ=10: 60.699;7.000;-;03;55.000
2016-03-23 12:59:47.236 [update notice] update broadcast sollw QQ=f1: 60.699;7.000;0;a0;55.000
2016-03-23 12:59:51.969 [update notice] update feuerung betrd QQ=10: Brauchwasser_Heizen;6;60.69;-;-;55.0;-
Hier gibt es dann noch einige Werte für die noch keine *.csv Datei angelegt wurde.
2016-03-23 13:05:19.312 [update notice] unknown BC cmd: 30fe502309440f0104005d010000
2016-03-23 13:05:19.651 [update notice] unknown BC cmd: 30fe0700090080101413ffff03ff
2016-03-23 13:05:03.074 [update notice] unknown MM cmd: 03f1080008003c000780000037.
Richtig verstanden?
Dann müsste ich (bzw. jemand der es kann), jetzt für die u.a. Werte eine *.csv Datei erstellen?
.... noch ein kurzer Nachtrag: Was bedeuten denn diese Zeilen?
2016-03-23 13:30:38.108 [main error] unable to load scan config 08: list files in /etc/ebusd/kromschroeder ERR: element not found
2016-03-23 13:30:40.226 [main error] unable to load scan config 15: list files in /etc/ebusd/kromschroeder ERR: element not found
2016-03-23 13:30:42.382 [main error] unable to load scan config 35: list files in /etc/ebusd/kromschroeder ERR: element not found
2016-03-23 13:30:44.526 [main error] unable to load scan config 75: list files in /etc/ebusd/kromschroeder ERR: element not found
Hallo Gerd,
ein klares jein.
Die CSV-Dateien für deine Wolf-Heizung (firmenspezifische Daten) bleiben in dem Unterordner Wolf. Die Definitionsdateien für Vaillant-Heizungen liegen im Unterordner Vaillant. Nur was Firmen unabhängig ist, bleibt im Ordner /etc/ebusd/.
Die Beschreibung wie sich der ebusd verhält ist hier zu finden:https://github.com/john30/ebusd/wiki/4.7.-Automatic-configuration (https://github.com/john30/ebusd/wiki/4.7.-Automatic-configuration)
Da die meisten Kommandos bei den Heizungen firmenspezifisch sind, gibt es dazu auch keine offizielle Dokumentation. Deshalb sind auch nicht alle Befehle bekannt. Was in deinem Log als "unknown" - unbekannt . auf taucht, dessen Bedeutung muss noch von dir (?) heraus gefunden werden. Die dafür die CSV-Dateien auf gebaut sind findest du hier:
https://github.com/john30/ebusd/wiki/4.1.-Message-definition (https://github.com/john30/ebusd/wiki/4.1.-Message-definition)
Allgemeine Infos zum Ebus gibt es hier: http://ebus-wiki.org (http://ebus-wiki.org)
Gruß
Maik
Ein klares Ja, doch.
Die Unterverzeichnisse Wolf und Vaillant sind nett für die automatische Konfiguration - wenn diese aber nochnicht möglich ist, kann man sie auch komplett weglassen und mit ganz wenigen .CSV (steht für "Comma Separated Value") Dateien anfangen.
_templates ist wichtig, stellt die Abkürzungen für Datentypen bereit. Wobei diese allerdings manchmal etwas kryptisch sind, am Besten beginnt man mit gang wenigen elementaren Typen wie UCH = unsigned Character
Dann Datenströme mitschneiden, und Byte für Byte auseinanderfieseln.
In der anliegenden Datei - bitte die "hinteren" Tabellen ansehen - ist das für Vaillant vorgeführt.
Ist eine Untermenge meiner eigenen Arbeitsdatei und sieht eben wie ein Schreibtisch aus...
LG
pah
Hallo Peter, hallo istler,
vielen Dank für die Rückmeldung. Da hätte ich mich wohl erher am Anfang des Winters hinsetzen müssen.
Noch eine kurze Frage zur "Schritt für Schritt" Methode.
Ist die Bezeichnung der Dateien willkürlich?
VG
Gerd
Ja, es werden einfach alle .CSV-Dateien in /etc/ebusd geladen (John möge mich eines Besseren belehren, wenn er das geändert hat).
LG
pah
@Gerd: Was für eine Steuerung hängt denn an deiner Wolf-Therme?
Das Mitschneiden der Datenströme ist nämlich z.B. bei einem Wolf BM-2 als Regler gar nicht so trivial, weil bestimmte Einstellungen, die man manuell ändert, scheinbar nicht über den Ebus kommuniziert werden, sondern über eine Nachricht an den BM-2 abgefragt werden müssen (geht bei mir inzwischen zumindest für das eingestellte Heizprogramm). Jedenfalls konnte ich bei meinen Tests durch Mitschneiden der Nachrichten keine eindeutig zuzuordnenden Nachrichten identifizieren, wenn man z.B. das Heizprogramm manuell am Regler ändert.
@alpha1974
Ich habe eine Wolf Therme mit einer BM-2 als Regler. Den ebus greife ich bei dem BM Teil ab. Ich habe schon einmal einen ebus von Wolf (ISM 1) daran gehabt, aber der war ziemlich umständlich.
Mit den jetztigen Dateien kann ich schon einmal einige Daten abgreifen, wenn mir auch der import in fhem einige Probleme macht.
VG
Gerd
Ich vermute mal, dass nicht das Heizprogramm abgefragt wird. Sondern die Solltemperatur für den Vorlauf.
Mit anderen Worten: Das Heizprogramm wird im Regler gefahren, und die Therme erfährt auf Nachfrage (=pull, oder per Anweisung=push) nur, welchen Wert sie für die Vorlauftemperatur einstellen soll.
LG
pah
Das Heizprogramm wird tatsächlich im Regler gefahren und die Therme erfährt per push, was sie machen soll (allerdings ohne zu erfahren, welches Heizprogramm sie gerade bedient). Davon unabhängig kann man aber vom Regler das eingestellte Heizprogramm abfragen.
Reichlich unschön, weil noch nicht in CSV umgesetzt, sieht das in meiner Classdefs-Datei für das ECMD-Device so aus (35 ist der BM-2 Regler, das ECMD-Device ist eingerichtet nach der Anleitung aus dem FHEM-ebus-Wiki) ):
# Heizprogramm BM-2 abfragen
get Heizprogramm cmd {"w -h 35502203ff7427\n"}
get Heizprogramm expect "020[0-9]00\n\n"
get Heizprogramm postproc { sprintf("%s",$_) }
# Heizprogramme BM-2 setzen
set Heizprogramm_Automatik cmd {"w -h 3550230900742701005D010010\n"}
set Heizprogramm_Standby cmd {"w -h 3550230900742700005D010010\n"}
set Heizprogramm_Sparbetrieb cmd {"w -h 3550230900742703005D010010\n"}
set Heizprogramm_Dauerheizen cmd {"w -h 3550230900742702005D010010\n"}
Die vom BM-2 gesendete Antwort auf die Abfrage des Heizprogramms wird dann - noch unschöner - über ein Stateformat im
ECMDDevice formatiert:
{if (ReadingsVal("Heizprogramm","Heizprogramm",0) == "020100") {"Automatik"}
elsif (ReadingsVal("Heizprogramm","Heizprogramm",0) == "020300") {"Sparbetrieb"}
elsif (ReadingsVal("Heizprogramm","Heizprogramm",0) == "020000") {"Standby"}
elsif (ReadingsVal("Heizprogramm","Heizprogramm",0) == "020200") {"Dauerheizen"}}
Kann man vermutlich (wahrscheinlich sogar sicherlich :)) eleganter umsetzen über eine ebus-CSV. Leider kann ICH das nicht. Aber für meinen Anwendungsfall (Auslesen und Änderung des Heizprogramms am Regler) reicht mir meine Gefrickel-Lösung - weil sie läuft.
Für Gerd: Ich habe noch meine äußerst experimentelle CSV angehängt, die einige ebus-Nachrichten meiner Therme (Wolf CGB-2-14) "entschlüsselt". Weiter bin ich noch nicht gekommen, so richtig funktionieren auch nur die Einträge unterhalb von betrd_bm2. Wie ich dem Regler die von ihm gemessene Raumtemperatur entlocke, habe ich auch noch nicht herausgefunden.
Vlt. doch mal probieren - ist echt einfach, wenn man eine OpenOffice Calc-Datei (von mir aus auch Excel) anlegt und die Daten schrittweise einträgt. Man kann sehr leicht verfolgen, was der ebusd tatsächlich abschickt.
Außerdem würde ich empfeheln, die ganze Auswerterei aus dem ECMD heraus in ein Modul 99_HeatingUtils zu verlagern. Sehr viel besser zu handhaben.
LG
pah
alpha1974, Peter,
danke erst einmal für die Infos. Ich werde mich am Freitag wohl erst damit beschäftigen können. Aber das Ganze sieht doch schon sehr vielversprechend aus.
Gerd
Hallo Peter,
das ganze lässte mir doch keine Ruhe und ich möchte mich heute noch einmal versuchen. Gibt es eine Beschreibung für die csv files?
VG
Gerd
Zitat von: istler am 27 Februar 2016, 17:38:28
Einige Variablen sind jetzt vollständig mit Namen versehen, z.B.:
Da sind in der JSON-Struktur nun keine Zahlen mehr in den Fields-Bezeichnern vorhanden sondern die Namen, deshalb läuft dein HTML bzw. JS-Script ins leere. In der Zeile wo du nun die Werte abholst um sie zu aktualisieren und die "parts" überprüfst (ab Zeile 253 in der index.html):
Evtl. klappt ja deswegen einigen Sachen nicht mehr z. B. DCF-Empfänger / Außenfühler.
So, das ist jetzt im aktuellen git code gefixt. Hatte schon länger dran gearbeitet, aber es nicht fertig bekommen...
Zitat von: Marie01 am 22 März 2016, 20:54:27
ApplianceCode 42
Mit vrDialog bekomm ich den TEV Eintritt angezeigt.
Kannst Du mir mal schreiben, was "ebusctl w -h 08b509030d7601" für ein Ergebnis bringt?
Zitat von: Gerd.Ternes am 24 März 2016, 11:27:33
das ganze lässte mir doch keine Ruhe und ich möchte mich heute noch einmal versuchen. Gibt es eine Beschreibung für die csv files?
Guckst Du hier:
https://github.com/john30/ebusd/wiki/4.-Configuration (https://github.com/john30/ebusd/wiki/4.-Configuration)
Zitat von: john30 am 25 März 2016, 10:14:04
Kannst Du mir mal schreiben, was "ebusctl w -h 08b509030d7601" für ein Ergebnis bringt?
ebusctl w -h 08b509030d7601liefert
0105
Zunächst einmal ein großes "Dankeschön" an alle die so viel Geduld mit mir hatten, bzw. haben.
Ich habe mich gestern einmal an den Files für die Wolf Heizung versucht und ich denke der Ansatz von pah ist in Ordnung, das Ganze step by step zu machen.
das erste file das ich mir ausgesucht habe lautet:
f1fe0800089a3a000600000037
ich habe hieraus einfach einmal die Werte auf wert(Wolf _templates) gesetzt und erhalte als Daten:
154;58;6.000;0.000;10.000 (vorderer Teil ist gekürzt).
beim längeren log sehe ich, dass sich die Werte verändern. Um 22:00 Uhr (Nachtabsenkung) erhalte ich folgende Daten
0;55;6.000;0.000;10.000
nach kurzer Zeit ändern sich die Werte in
102;56;5.000;0.000;10.000,
wenn die Heizung dann wieder anläuft (4:00 Uhr morgens) sehe ich:
26;60;5.000;0.000;55.000,
Auch sehe ich, dass sich die Werte beim Programmwechsel verändern (s. Anlage).
Mir fehlt jetzt der Stups in eine Richtung wie ich daraus Info´s erhalten kann, die ich nachher auch auswerte (Welch infos sind das, welche Maßeinheiten usw.).
Danke im Voraus.
gerd
@John:
ich hab' das 08.ehp.csv manuel editiert und den Appliance Code bis 42 erweitert.
Kann die CondensorTemp und weiter felder nun auslesen.
Danke für deine Unterstützung.
Zitat von: Marie01 am 25 März 2016, 12:21:46
ich hab' das 08.ehp.csv manuel editiert und den Appliance Code bis 42 erweitert.
Kann die CondensorTemp und weiter felder nun auslesen.
das tuts natürlich auch. habe aber festgestellt dass vrdialog die abfrage anders durchführt. die CSVs in ebusd-2.x.x spiegeln das jetzt wieder.
Hallo,
wie bzw wo erhalte ich die Daten als json-File?
Vg
David
Hallo David,
die JSON-Daten vom ebusd erhälst du, im dem ebus-Daemon mit der Option --httpport=PORT startest und folgende URL aufrust:
<ip-Addr_ebusd>:<PORT>/data/?verbose
Teildaten, z. B. von der Gastherme (bai), erhälst du mit:
<ip-Addr_ebusd>:<PORT>/data/bai/?verbose
Und alle Daten einer Komponente, die xyz enthalten mit:
<ip-Addr_ebusd>:<PORT>/data/bai/xyz?verbose
Neben verbose gibt es noch numeric, das liefert dann alle Werte als Zahlen, also auch die Werte, wo Zustand, z. B. on / off definiert sind. Wenn man verbose und numeric kombinieren will, dann schreibt man ein & zwischen die Argumente:
<ip-Addr_ebusd>:<PORT>/data/bai/xyz?verbose&numeric
Gruß
Maik
@Gerd: Diese Art von Meldungen konnte ich bislang auch noch nicht entziffern.
Nach meinen Vermutungen handelt es sich nicht um Meldungen zum Heizprogramm, sondern um Betriebsdaten der Therme, die sich entsprechend ändern, wenn der Regler (BM2) das Programm wechselt und eine Wärmeanforderung an die Therme schickt.
Ich fand es daher einfacher, die Meldungen des BM2 zu übersetzen, wobei sich meine Leistung darauf beschränkte, die Parameter, die man bei openhab schon entschlüsselt hatte, in ein CSV umzusetzen.
Bin derzeit im Urlaub, mehr dann nach den Ferien. Vielleicht sollten wir dann einen eigenen Wolf-CGB-BM-ebus Thread aufmachen...
Frohes Osterfest,
alpha1974
hallo alpha:
ich denke das macht sinn. hast du es schon einmal direkt bei Wolf versucht?
Zitat von: istler am 25 März 2016, 20:48:23
die JSON-Daten vom ebusd erhälst du, im dem ebus-Daemon mit der Option --httpport=PORT startest und folgende URL aufrust:
<ip-Addr_ebusd>:<PORT>/data/?verbose
Hallo,
danke für die Antwort. funktioniert wunderbar.
viele Grüße
David
Hi,
mein Name ist Chris und ich habe die letzten 3h versucht mich zu belesen und mein ebus Interface an den Start zu bekommen, leider scheitere ich an dieser Stelle.
2016-03-27 23:49:53.962 [main error] unable to load scan config 08: no file from /etc/ebusd/vaillant with prefix 08. matches ID "hmu00", SW0211, HW0403
2016-03-27 23:49:56.092 [main error] unable to load scan config 15: no file from /etc/ebusd/vaillant with prefix 15. matches ID "70000", SW0110, HW2103
2016-03-27 23:49:58.222 [main error] unable to load scan config 76: no file from /etc/ebusd/vaillant with prefix 76. found
Infos:
address 08: slave #3, scanned "MF=Vaillant;ID=HMU00;SW=0211;HW=0403"
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0110;HW=2103"
address 76: slave #17, scanned "MF=Vaillant;ID=VWZ00;SW=0211;HW=0403"
Es handelt sich um eine : VWF 58/4
Wie bekommt man diese benötigten CSV Files selber erstellt, gibt es dazu eine Anleitung oder kann mir jemand helfen?
Ist dies Topic das richtige oder wie geht man am besten vor?
Danke euch und Gruß
Chris
Zitat von: fox-octi am 28 März 2016, 00:50:01
address 08: slave #3, scanned "MF=Vaillant;ID=HMU00;SW=0211;HW=0403"
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0110;HW=2103"
address 76: slave #17, scanned "MF=Vaillant;ID=VWZ00;SW=0211;HW=0403"
Es handelt sich um eine : VWF 58/4
für diese Geräte gibt es noch keine CSVs.
Da hilft nur sehr viel Geduld und versuchen, alles selbst zu entschlüsseln.
Der User @Pierce hatte hier auch schon mal die Frage für eine ähnliche Konfiguration gestellt. Hier meine Antwort dazu:
https://forum.fhem.de/index.php/topic,29737.msg397864.html#msg397864 (https://forum.fhem.de/index.php/topic,29737.msg397864.html#msg397864)
Hallo Zusammen,
nachdem mein ebus nun seit Monaten super lief, hat sich über Ostern meine Netzverbindung zur Heizung verabschiedet (DLAN).
Also DLAN Adapter neu gestartet und dann den RasPi.
Seit dem kamen einige Werte nicht mehr an (HK1Mode, Aussentemp, HKurve, RaumSoll, WWMode und CirPump).
Ich habe dann mal einen checkconfig gemacht und bekam nur Fehler.
Also habe ich mal im ebus Wiki geschaut und die neuste Version installiert.
Leider immer noch die Fehler und fehlenden Werte
pi@eBus ~ $ ebusd -V
ebusd 2.0.0ea7efc
pi@eBus ~ $ ebusctl r -m 10 outsidetemp
ERR: no data stored
pi@eBus ~ $ ebusctl r -f hc1Timer.Tuesday
ERR: element not found
pi@eBus ~ $ ebusd --checkconfig
2016-03-28 17:43:15.259 Performing configuration check...
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 12 field 3 value "IsInHoliday": ERR: duplicate name
Erroneous item is here:
r,,IsInHoliday,Ferienprogramm aktiv,,,,0B00,,,yesno,,,TRUE if holiday is active,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 18 field 8 value "0F00": ERR: duplicate entry
Erroneous item is here:
r,,OperatingMode470,OperatingMode470,,,,0F00,,,UCH,,,"Operating mode of solar DHW circuit for 470 (1 = auto, 3 = off, 4 = on)",,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 37 field 3 value "Mode": ERR: duplicate name
Erroneous item is here:
r,,Mode,Betriebsart,,,,01,,,temp0;hwcmode;IGN:2;HEX;IGN;onoff;IGN,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 38 field 3 value "Status": ERR: duplicate name
Erroneous item is here:
r,,Status,Status,,,,0D,,,temp0;onoff;temp;temp0,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 42 field 3 value "Timer.Monday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Monday,Zeitfenster Montag,,,,02,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 43 field 3 value "Timer.Tuesday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Tuesday,Zeitfenster Dienstag,,,,03,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 44 field 3 value "Timer.Wednesday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Wednesday,Zeitfenster Mittwoch,,,,04,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 45 field 3 value "Timer.Thursday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Thursday,Zeitfenster Donnerstag,,,,05,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 46 field 3 value "Timer.Friday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Friday,Zeitfenster Freitag,,,,06,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 47 field 3 value "Timer.Saturday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Saturday,Zeitfenster Samstag,,,,07,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 48 field 3 value "Timer.Sunday": ERR: duplicate name
Erroneous item is here:
r,,Timer.Sunday,Zeitfenster Sonntag,,,,08,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 49 field 3 value "Timer.Monday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Monday,Zeitfenster Montag,,,,01,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 50 field 3 value "Timer.Tuesday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Tuesday,Zeitfenster Dienstag,,,,02,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 51 field 3 value "Timer.Wednesday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Wednesday,Zeitfenster Mittwoch,,,,03,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 52 field 3 value "Timer.Thursday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Thursday,Zeitfenster Donnerstag,,,,04,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 53 field 3 value "Timer.Friday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Friday,Zeitfenster Freitag,,,,05,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 54 field 3 value "Timer.Saturday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Saturday,Zeitfenster Samstag,,,,06,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 55 field 3 value "Timer.Sunday": ERR: duplicate name
Erroneous item is here:
w,,Timer.Sunday,Zeitfenster Sonntag,,,,07,,,timer,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 58 field 3 value "currenterror": ERR: duplicate name
Erroneous item is here:
r,,currenterror,Aktuelle Fehler,,,,01,,,errors,,,,,,
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 62 field 3 value "errorhistory": ERR: duplicate name
Erroneous item is here:
r,,errorhistory,Fehlerhistorie,,,,01,index,m,UCH,,,,,,errorhistory
^
Error reading "/etc/ebusd/vaillant/a0.sol.hwc.csv" line 63 field 3 value "clearerrorhistory": ERR: duplicate name
Erroneous item is here:
wi,,clearerrorhistory,Fehlerhistorie: löschen,,,,01,cleared,s,yesno,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 9 field 8 value "0000": ERR: duplicate entry
Erroneous item is here:
r,,resvdStorage1Sensor,,,,,0000,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 11 field 8 value "0200": ERR: duplicate entry
Erroneous item is here:
r,,resvdStorage3Sensor,,,,,0200,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 20 field 8 value "0B00": ERR: duplicate entry
Erroneous item is here:
r,,CirPump,,,,,0B00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 23 field 8 value "0E00": ERR: duplicate entry
Erroneous item is here:
r,,BypassValve,,,,,0E00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 24 field 8 value "0F00": ERR: duplicate entry
Erroneous item is here:
r,,RoomTemp,Aktuelle Raumtemperatur,,,,0F00,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 26 field 8 value "1100": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempOffset,,,,,1100,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 27 field 8 value "1200": ERR: duplicate entry
Erroneous item is here:
r,,OutsideTemp,Außentemperatur [°C],,,,1200,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 30 field 8 value "1500": ERR: duplicate entry
Erroneous item is here:
r,,OperatingMode,,,,,1500,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 32 field 8 value "1700": ERR: duplicate entry
Erroneous item is here:
r,,Time,,,,,1700,,,time,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 35 field 8 value "1A00": ERR: duplicate entry
Erroneous item is here:
r,,TeleSwOperatingMode,,,,,1A00,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 51 field 8 value "2A00": ERR: duplicate entry
Erroneous item is here:
r,,IsInSingleHwcLoadingMode,,,,,2A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 55 field 8 value "2E00": ERR: duplicate entry
Erroneous item is here:
r,,SwitchOffParty,,,,,2E00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 56 field 8 value "2F00": ERR: duplicate entry
Erroneous item is here:
r,,IsInTeleSwitch,,,,,2F00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 57 field 8 value "3000": ERR: duplicate entry
Erroneous item is here:
r,,IsInFloorPavingDrying,,,,,3000,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 58 field 8 value "3100": ERR: duplicate entry
Erroneous item is here:
r,,IsInQuickVeto,,,,,3100,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 59 field 8 value "3200": ERR: duplicate entry
Erroneous item is here:
r,,QuickVetoTemp,,,,,3200,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 61 field 8 value "3400": ERR: duplicate entry
Erroneous item is here:
r,,StackMainTaskMax,,,,,3400,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 62 field 8 value "3500": ERR: duplicate entry
Erroneous item is here:
r,,StackLifeCheckTaskMax,,,,,3500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 65 field 8 value "3800": ERR: duplicate entry
Erroneous item is here:
r,,eBUSCRC,,,,,3800,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 67 field 8 value "3A00": ERR: duplicate entry
Erroneous item is here:
r,,ComfTempEnabled,,,,,3A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 68 field 8 value "3B00": ERR: duplicate entry
Erroneous item is here:
r,,ComfTempDesired,,,,,3B00,,,temp;temp;temp;temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 69 field 8 value "3C00": ERR: duplicate entry
Erroneous item is here:
r,,FrostProtectDelay,,,,,3C00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 70 field 8 value "3D00": ERR: duplicate entry
Erroneous item is here:
r,,HydraulicScheme,,,,,3D00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 71 field 8 value "3E00": ERR: duplicate entry
Erroneous item is here:
r,,SolHwcMaxLoadTemp,,,,,3E00,,,HEX:2,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 72 field 8 value "3F00": ERR: duplicate entry
Erroneous item is here:
r,,DON,,,,,3F00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 73 field 8 value "4000": ERR: duplicate entry
Erroneous item is here:
r,,DOff,,,,,4000,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 75 field 8 value "4200": ERR: duplicate entry
Erroneous item is here:
r,,FillmodeStartTime,,,,,4200,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 76 field 8 value "4300": ERR: duplicate entry
Erroneous item is here:
r,,OperatingmodeStartTime,,,,,4300,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 77 field 8 value "4400": ERR: duplicate entry
Erroneous item is here:
r,,NumCollPanels,,,,,4400,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 78 field 8 value "4500": ERR: duplicate entry
Erroneous item is here:
r,,SolarPumpBlockingTime,,,,,4500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 79 field 8 value "4600": ERR: duplicate entry
Erroneous item is here:
r,,LoadingDelayEnabled,,,,,4600,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 80 field 8 value "4700": ERR: duplicate entry
Erroneous item is here:
r,,SolarFlowRate,Volumenstrom Solarkreis [l/h],,,,4700,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 81 field 8 value "4800": ERR: duplicate entry
Erroneous item is here:
r,,EDControlEnabled,,,,,4800,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 82 field 8 value "4900": ERR: duplicate entry
Erroneous item is here:
r,,ResetSolarYieldkWh,,,,,4900,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 83 field 8 value "4A00": ERR: duplicate entry
Erroneous item is here:
r,,ResetOperatingTimes,,,,,4A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 84 field 8 value "4B00": ERR: duplicate entry
Erroneous item is here:
r,,PumpPower,,,,,4B00,,,power,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 85 field 8 value "4C00": ERR: duplicate entry
Erroneous item is here:
r,,StartCircuitAeration,,,,,4C00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 86 field 8 value "4D00": ERR: duplicate entry
Erroneous item is here:
r,,HeatingCurve,,,,,4D00,,,curve,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 88 field 8 value "4F00": ERR: duplicate entry
Erroneous item is here:
r,,OtShutdownLimit,,,,,4F00,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 89 field 8 value "5000": ERR: duplicate entry
Erroneous item is here:
r,,FlowTempMin,,,,,5000,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 90 field 8 value "5100": ERR: duplicate entry
Erroneous item is here:
r,,DisableAutoSync,,,,,5100,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 91 field 8 value "5200": ERR: duplicate entry
Erroneous item is here:
r,,DONMIN,,,,,5200,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 92 field 8 value "5300": ERR: duplicate entry
Erroneous item is here:
r,,DONMAX,,,,,5300,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 93 field 8 value "5400": ERR: duplicate entry
Erroneous item is here:
r,,HydraulicMixer,,,,,5400,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 94 field 8 value "5500": ERR: duplicate entry
Erroneous item is here:
r,,eBUSFifoDiffCntMax,,,,,5500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 96 field 8 value "5700": ERR: duplicate entry
Erroneous item is here:
r,,ActualRoomTempDesired,Aktueller Raumsollwert[°C],,,,5700,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 97 field 8 value "5800": ERR: duplicate entry
Erroneous item is here:
r,,WeekDayProgSwitch,,,,,5800,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 98 field 8 value "5900": ERR: duplicate entry
Erroneous item is here:
r,,OperatingModeHwc,,,,,5900,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 99 field 8 value "5A00": ERR: duplicate entry
Erroneous item is here:
r,,RTCAdjustment,,,,,5A00,,,SIN,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 104 field 8 value "5F00": ERR: duplicate entry
Erroneous item is here:
r,,CMResetCnt,,,,,5F00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 105 field 8 value "6000": ERR: duplicate entry
Erroneous item is here:
r,,COMErrorCnt,,,,,6000,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.360.csv" line 106 field 8 value "6100": ERR: duplicate entry
Erroneous item is here:
r,,VariantDKRefreshCnt,,,,,6100,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/common.csv" line 14 field 8 value "01": ERR: duplicate entry
Erroneous item is here:
rw,,Mode,Betriebsart,,,,01,,,temp0;hwcmode;IGN:2;HEX;IGN;onoff;IGN,,,
^
Error reading "/etc/ebusd/vaillant/common.csv" line 15 field 3 value "Mode": ERR: duplicate name
Erroneous item is here:
rm,,Mode,Betriebsart,,,,01,,,temp0;mcmode;IGN:2;HEX;IGN;onoff;IGN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 9 field 8 value "0000": ERR: duplicate entry
Erroneous item is here:
r,,resvdStorage1Sensor,,,,,0000,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 10 field 8 value "0100": ERR: duplicate entry
Erroneous item is here:
r,,resvdStorage2Sensor,,,,,0100,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 11 field 8 value "0200": ERR: duplicate entry
Erroneous item is here:
r,,resvdStorage3Sensor,,,,,0200,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 12 field 8 value "0300": ERR: duplicate entry
Erroneous item is here:
r,,resvdColl1Sensor,,,,,0300,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 13 field 8 value "0400": ERR: duplicate entry
Erroneous item is here:
r,,resvdColl2Sensor,,,,,0400,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 14 field 8 value "0500": ERR: duplicate entry
Erroneous item is here:
r,,YieldSensor,,,,,0500,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 15 field 8 value "0600": ERR: duplicate entry
Erroneous item is here:
r,,resvdCollPump1,,,,,0600,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 16 field 8 value "0700": ERR: duplicate entry
Erroneous item is here:
r,,ActualPumpPower,,,,,0700,,,HEX:2,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 17 field 8 value "0800": ERR: duplicate entry
Erroneous item is here:
r,,resvdCollPump2,,,,,0800,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 18 field 8 value "0900": ERR: duplicate entry
Erroneous item is here:
r,,UV1State,,,,,0900,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 19 field 8 value "0A00": ERR: duplicate entry
Erroneous item is here:
r,,LegioPump,,,,,0A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 20 field 8 value "0B00": ERR: duplicate entry
Erroneous item is here:
r,,CirPump,,,,,0B00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 21 field 8 value "0C00": ERR: duplicate entry
Erroneous item is here:
r,,ElectronicCartridge,,,,,0C00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 22 field 8 value "0D00": ERR: duplicate entry
Erroneous item is here:
r,,C1C2State,,,,,0D00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 23 field 8 value "0E00": ERR: duplicate entry
Erroneous item is here:
r,,BypassValve,,,,,0E00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 24 field 8 value "0F00": ERR: duplicate entry
Erroneous item is here:
r,,RoomTemp,Aktuelle Raumtemperatur,,,,0F00,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 25 field 8 value "1000": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempOffsetSelfWarming,,,,,1000,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 26 field 8 value "1100": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempOffset,,,,,1100,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 27 field 8 value "1200": ERR: duplicate entry
Erroneous item is here:
r,,OutsideTemp,Außentemperatur [°C],,,,1200,,,tempsensor,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 28 field 8 value "1300": ERR: duplicate entry
Erroneous item is here:
r,,OutsideTempOffset,,,,,1300,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 29 field 8 value "1400": ERR: duplicate entry
Erroneous item is here:
r,,ActualTempDesired,,,,,1400,,,temp0,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 30 field 8 value "1500": ERR: duplicate entry
Erroneous item is here:
r,,OperatingMode,,,,,1500,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 31 field 8 value "1600": ERR: duplicate entry
Erroneous item is here:
r,,ActualWeekday,,,,,1600,,,bday,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 32 field 8 value "1700": ERR: duplicate entry
Erroneous item is here:
r,,Time,,,,,1700,,,time,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 33 field 8 value "1800": ERR: duplicate entry
Erroneous item is here:
r,,ReducedNightTemp,,,,,1800,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 34 field 8 value "1900": ERR: duplicate entry
Erroneous item is here:
r,,PrevOperatingMode,,,,,1900,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 35 field 8 value "1A00": ERR: duplicate entry
Erroneous item is here:
r,,TeleSwOperatingMode,,,,,1A00,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 36 field 8 value "1B00": ERR: duplicate entry
Erroneous item is here:
r,,HwcState,,,,,1B00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 37 field 8 value "1C00": ERR: duplicate entry
Erroneous item is here:
r,,YearCalendarActive,,,,,1C00,,,UCH,0=off;7=on,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 38 field 8 value "1D00": ERR: duplicate entry
Erroneous item is here:
r,,ClockSwitchSummerWinterDone,,,,,1D00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 39 field 8 value "1E00": ERR: duplicate entry
Erroneous item is here:
r,,SolarYieldkWh,,,,,1E00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 40 field 8 value "1F00": ERR: duplicate entry
Erroneous item is here:
r,,CollPumpHRuntime,,,,,1F00,,,UIN;UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 41 field 8 value "2000": ERR: duplicate entry
Erroneous item is here:
r,,Date,,,,,2000,,,date,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 42 field 8 value "2100": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempSwitchOn,,,,,2100,,,UCH,0=off;1=modulating;2=thermostat,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 43 field 8 value "2200": ERR: duplicate entry
Erroneous item is here:
r,,ROCRoomSet,,,,,2200,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 44 field 8 value "2300": ERR: duplicate entry
Erroneous item is here:
r,,OffsetDesTemp,,,,,2300,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 45 field 8 value "2400": ERR: duplicate entry
Erroneous item is here:
r,,StateOfRoomCon,,,,,2400,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 46 field 8 value "2500": ERR: duplicate entry
Erroneous item is here:
r,,LegioProtectionState,,,,,2500,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 47 field 8 value "2600": ERR: duplicate entry
Erroneous item is here:
r,,StatusDcf,,,,,2600,,,dcfstate,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 48 field 8 value "2700": ERR: duplicate entry
Erroneous item is here:
r,,DcfDaten,,,,,2700,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 49 field 8 value "2800": ERR: duplicate entry
Erroneous item is here:
r,,IsInHoliday,,,,,2800,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 50 field 8 value "2900": ERR: duplicate entry
Erroneous item is here:
r,,IsInParty,,,,,2900,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 51 field 8 value "2A00": ERR: duplicate entry
Erroneous item is here:
r,,IsInSingleHwcLoadingMode,,,,,2A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 52 field 8 value "2B00": ERR: duplicate entry
Erroneous item is here:
r,,RestoreOpModeAfterHoliday,,,,,2B00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 53 field 8 value "2C00": ERR: duplicate entry
Erroneous item is here:
r,,IsInSavingsFunction,,,,,2C00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 54 field 8 value "2D00": ERR: duplicate entry
Erroneous item is here:
r,,SavingsFunctionTime,,,,,2D00,,,time;onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 55 field 8 value "2E00": ERR: duplicate entry
Erroneous item is here:
r,,SwitchOffParty,,,,,2E00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 56 field 8 value "2F00": ERR: duplicate entry
Erroneous item is here:
r,,IsInTeleSwitch,,,,,2F00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 57 field 8 value "3000": ERR: duplicate entry
Erroneous item is here:
r,,IsInFloorPavingDrying,,,,,3000,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 58 field 8 value "3100": ERR: duplicate entry
Erroneous item is here:
r,,IsInQuickVeto,,,,,3100,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 59 field 8 value "3200": ERR: duplicate entry
Erroneous item is here:
r,,QuickVetoTemp,,,,,3200,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 60 field 8 value "3300": ERR: duplicate entry
Erroneous item is here:
r,,StackeBUSTaskMax,,,,,3300,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 61 field 8 value "3400": ERR: duplicate entry
Erroneous item is here:
r,,StackMainTaskMax,,,,,3400,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 62 field 8 value "3500": ERR: duplicate entry
Erroneous item is here:
r,,StackLifeCheckTaskMax,,,,,3500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 63 field 8 value "3600": ERR: duplicate entry
Erroneous item is here:
r,,Variant,,,,,3600,,,ULG,0x0FF0F00F=VRT 350;0x33CCCC33=VRT 360;0x3CC3C33C=SD 17;0x66999966=SD 37;0x69969669=VRT 360+,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 64 field 8 value "3700": ERR: duplicate entry
Erroneous item is here:
r,,TimeWindows,,,,,3700,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 65 field 8 value "3800": ERR: duplicate entry
Erroneous item is here:
r,,eBUSCRC,,,,,3800,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 66 field 8 value "3900": ERR: duplicate entry
Erroneous item is here:
r,,HwcTempDesired,,,,,3900,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 67 field 8 value "3A00": ERR: duplicate entry
Erroneous item is here:
r,,ComfTempEnabled,,,,,3A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 68 field 8 value "3B00": ERR: duplicate entry
Erroneous item is here:
r,,ComfTempDesired,,,,,3B00,,,temp;temp;temp;temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 69 field 8 value "3C00": ERR: duplicate entry
Erroneous item is here:
r,,FrostProtectDelay,,,,,3C00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 70 field 8 value "3D00": ERR: duplicate entry
Erroneous item is here:
r,,HydraulicScheme,,,,,3D00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 71 field 8 value "3E00": ERR: duplicate entry
Erroneous item is here:
r,,SolHwcMaxLoadTemp,,,,,3E00,,,HEX:2,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 72 field 8 value "3F00": ERR: duplicate entry
Erroneous item is here:
r,,DON,,,,,3F00,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 73 field 8 value "4000": ERR: duplicate entry
Erroneous item is here:
r,,DOff,,,,,4000,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 74 field 8 value "4100": ERR: duplicate entry
Erroneous item is here:
r,,LegioProtectionEnabled,,,,,4100,,,yesno,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 75 field 8 value "4200": ERR: duplicate entry
Erroneous item is here:
r,,FillmodeStartTime,,,,,4200,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 76 field 8 value "4300": ERR: duplicate entry
Erroneous item is here:
r,,OperatingmodeStartTime,,,,,4300,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 77 field 8 value "4400": ERR: duplicate entry
Erroneous item is here:
r,,NumCollPanels,,,,,4400,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 78 field 8 value "4500": ERR: duplicate entry
Erroneous item is here:
r,,SolarPumpBlockingTime,,,,,4500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 79 field 8 value "4600": ERR: duplicate entry
Erroneous item is here:
r,,LoadingDelayEnabled,,,,,4600,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 80 field 8 value "4700": ERR: duplicate entry
Erroneous item is here:
r,,SolarFlowRate,Volumenstrom Solarkreis [l/h],,,,4700,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 81 field 8 value "4800": ERR: duplicate entry
Erroneous item is here:
r,,EDControlEnabled,,,,,4800,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 82 field 8 value "4900": ERR: duplicate entry
Erroneous item is here:
r,,ResetSolarYieldkWh,,,,,4900,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 83 field 8 value "4A00": ERR: duplicate entry
Erroneous item is here:
r,,ResetOperatingTimes,,,,,4A00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 84 field 8 value "4B00": ERR: duplicate entry
Erroneous item is here:
r,,PumpPower,,,,,4B00,,,power,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 85 field 8 value "4C00": ERR: duplicate entry
Erroneous item is here:
r,,StartCircuitAeration,,,,,4C00,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 86 field 8 value "4D00": ERR: duplicate entry
Erroneous item is here:
r,,HeatingCurve,,,,,4D00,,,curve,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 87 field 8 value "4E00": ERR: duplicate entry
Erroneous item is here:
r,,ControlMode,,,,,4E00,,,SCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 88 field 8 value "4F00": ERR: duplicate entry
Erroneous item is here:
r,,OtShutdownLimit,,,,,4F00,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 89 field 8 value "5000": ERR: duplicate entry
Erroneous item is here:
r,,FlowTempMin,,,,,5000,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 90 field 8 value "5100": ERR: duplicate entry
Erroneous item is here:
r,,DisableAutoSync,,,,,5100,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 91 field 8 value "5200": ERR: duplicate entry
Erroneous item is here:
r,,DONMIN,,,,,5200,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 92 field 8 value "5300": ERR: duplicate entry
Erroneous item is here:
r,,DONMAX,,,,,5300,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 93 field 8 value "5400": ERR: duplicate entry
Erroneous item is here:
r,,HydraulicMixer,,,,,5400,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 94 field 8 value "5500": ERR: duplicate entry
Erroneous item is here:
r,,eBUSFifoDiffCntMax,,,,,5500,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 95 field 8 value "5600": ERR: duplicate entry
Erroneous item is here:
r,,ZweipunktAnalogSlct,,,,,5600,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 96 field 8 value "5700": ERR: duplicate entry
Erroneous item is here:
r,,ActualRoomTempDesired,Aktueller Raumsollwert[°C],,,,5700,,,temp,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 97 field 8 value "5800": ERR: duplicate entry
Erroneous item is here:
r,,WeekDayProgSwitch,,,,,5800,,,onoff,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 98 field 8 value "5900": ERR: duplicate entry
Erroneous item is here:
r,,OperatingModeHwc,,,,,5900,,,mcmode,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 99 field 8 value "5A00": ERR: duplicate entry
Erroneous item is here:
r,,RTCAdjustment,,,,,5A00,,,SIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 100 field 8 value "5B00": ERR: duplicate entry
Erroneous item is here:
r,,EEpromMaxInkonsCnt,,,,,5B00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 101 field 8 value "5C00": ERR: duplicate entry
Erroneous item is here:
r,,POCResetCnt,,,,,5C00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 102 field 8 value "5D00": ERR: duplicate entry
Erroneous item is here:
r,,WDResetCnt,,,,,5D00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 103 field 8 value "5E00": ERR: duplicate entry
Erroneous item is here:
r,,LVResetCnt,,,,,5E00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 104 field 8 value "5F00": ERR: duplicate entry
Erroneous item is here:
r,,CMResetCnt,,,,,5F00,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 105 field 8 value "6000": ERR: duplicate entry
Erroneous item is here:
r,,COMErrorCnt,,,,,6000,,,UIN,,,
^
Error reading "/etc/ebusd/vaillant/15.140.csv" line 106 field 8 value "6100": ERR: duplicate entry
Erroneous item is here:
r,,VariantDKRefreshCnt,,,,,6100,,,UCH,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 7 field 8 value "0100": ERR: duplicate entry
Erroneous item is here:
r,,OutsideTemp,Aussentemperatur,,,,0100,,,tempsensor,,,Außentemperatur,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 8 field 8 value "0200": ERR: duplicate entry
Erroneous item is here:
r,,FlowTemp,Vorlauftemp. IST,,,,0200,,,tempsensor,,,Systemtemperatur in der hydraulischen Weiche oder am gemeinsamen Vorlauf (VF1),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 9 field 8 value "8C00": ERR: duplicate entry
Erroneous item is here:
r,,SystemTempGradient,SystemTempGradient,,,,8C00,,,temp,,,gradient of the system temperature (VF1),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 10 field 8 value "0500": ERR: duplicate entry
Erroneous item is here:
r,,FlowTempDesired,Vorlauftemp. SOLL,,,,0500,,,temp,,,Ermittelte Vorlaufsolltemperatur für das System,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 11 field 8 value "4B00": ERR: duplicate entry
Erroneous item is here:
r,,StateEM,Status Energiemanger,,,,4B00,,,UCH,0=off;1=heat;2=water;3=wateroverrun,,Status des Energiemanagers,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 12 field 8 value "1E00": ERR: duplicate entry
Erroneous item is here:
r,,HydraulicMap,Hydraulikplan,,,,1E00,,,UCH,,,Hydraulikplan. Dies ist nor eine Kopie des Wertes von der Grundleiterplatte. Bitte den Wert bei der Grundleiterplatte ändern. Ein Neustart des Systems muß danach erfolgen damit dieser Wert aktualisiert wird.,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 13 field 8 value "2D00": ERR: duplicate entry
Erroneous item is here:
r,,PreShutDownTime,Vorabschaltzeit,,,,2D00,,,minutes0,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 14 field 8 value "2E00": ERR: duplicate entry
Erroneous item is here:
r,,FrostOverRideTime,Frostschutz-Verzögerung,,,,2E00,,,hours,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 15 field 8 value "2F00": ERR: duplicate entry
Erroneous item is here:
r,,TempIncrease,Temperaturüberhöhung,,,,2F00,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 18 field 8 value "1800": ERR: duplicate entry
Erroneous item is here:
r,,MixerDetected,Erkannte VR60,,,,1800,,,UCH,,,detected VR60 (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 19 field 8 value "1900": ERR: duplicate entry
Erroneous item is here:
r,,BoilerDetected,Entdeckte Buskoppler,,,,1900,,,UCH,,,"detected bus coppler e.g. VR30,31,32 (bit counted)",,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 20 field 8 value "1A00": ERR: duplicate entry
Erroneous item is here:
r,,RemoteDetected,Erkannte Fernbediengeräte,,,,1A00,,,UCH,,,detected VR80 or VR90 (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 21 field 8 value "5A00": ERR: duplicate entry
Erroneous item is here:
r,,ActoStorModulDetected,ActoStorModulDetected,,,,5A00,,,UCH,,,detected VLR (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 22 field 8 value "7F00": ERR: duplicate entry
Erroneous item is here:
r,,AscBigModulDetected,AscBigModulDetected,,,,7F00,,,UCH,,,detected VPM-S (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 23 field 8 value "8000": ERR: duplicate entry
Erroneous item is here:
r,,AscSmallModulDetected,AscSmallModulDetected,,,,8000,,,UCH,,,detected VMS (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 24 field 8 value "8100": ERR: duplicate entry
Erroneous item is here:
r,,WaterstationModulDetected,FwsModulDetected,,,,8100,,,UCH,,,detected VPM-W (bit counted),,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 25 field 8 value "1C00": ERR: duplicate entry
Erroneous item is here:
r,,BoilerCount,Anzahl Heizgeräte,,,,1C00,,,UCH,,,active boiler in the system,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 26 field 8 value "3500": ERR: duplicate entry
Erroneous item is here:
r,,BoilerSwitchSteps,Kesselstufen,,,,3500,,,UCH,,,Eingestellte Anzahl von Kesselstufen,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 27 field 8 value "4E00": ERR: duplicate entry
Erroneous item is here:
r,,SourceType,SourceType,,,,4E00,,,UCH,0=noSystem;1=SSR;2=VRC;3=eSys;4=mixedSys,,"noSystem=0, SSR=1, VRC=2, eSys=3, mixedSys=4",,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 29 field 8 value "0000": ERR: duplicate entry
Erroneous item is here:
r,,RoomTemp,Raumisttemp,,,,0000,,,tempsensor,,,Raumtemperatur,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 30 field 8 value "1F00": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempOffset,Raumisttemp. Korrekturwert,,,,1F00,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 31 field 8 value "2000": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempOffsetSelfWarming,Offset Eigenerwärmung,,,,2000,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 32 field 8 value "2100": ERR: duplicate entry
Erroneous item is here:
r,,OutsideTempOffset,Außentemperatur-Abgleich,,,,2100,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 33 field 8 value "2200": ERR: duplicate entry
Erroneous item is here:
r,,RoomTempHoliday,Raumsollwert im Ferienbetrieb,,,,2200,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 34 field 8 value "4300": ERR: duplicate entry
Erroneous item is here:
r,,HolidayPeriod,Ferienzeitraum,,,,4300,,,hfrom;hto;hfrom;hto,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 35 field 8 value "2B00": ERR: duplicate entry
Erroneous item is here:
r,,ServicePeriod,Wartung,,,,2B00,,,date,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 36 field 8 value "4200": ERR: duplicate entry
Erroneous item is here:
r,,PhoneNumberPart1,Telefonnummer Teil 1,,,,4200,,,STR:9,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 38 field 8 value "2C00": ERR: duplicate entry
Erroneous item is here:
r,,KeyCodeforConfigMenu,Passwort für das Konfigurationsmenü,,,,2C00,,,HEX:4,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 39 field 8 value "3300": ERR: duplicate entry
Erroneous item is here:
r,,TempFailDetectTime,Temperaturfehlererkennung nach,,,,3300,,,temp0,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 40 field 8 value "3600": ERR: duplicate entry
Erroneous item is here:
r,,LcdContrastPwmValue,LCD Kontrast,,,,3600,,,UCH,,,Displaykontrast,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 41 field 8 value "5F00": ERR: duplicate entry
Erroneous item is here:
r,,Time,Uhrzeit,,,,5F00,,,time,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 42 field 8 value "6000": ERR: duplicate entry
Erroneous item is here:
r,,Day,Wochentag,,,,6000,,,bday,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 43 field 8 value "6100": ERR: duplicate entry
Erroneous item is here:
r,,Date,Datum,,,,6100,,,date,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 44 field 8 value "6700": ERR: duplicate entry
Erroneous item is here:
r,,SummerWinterTimeAdjust,Sommer/Winterzeit Umstellung,,,,6700,,,onoff,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 45 field 8 value "6800": ERR: duplicate entry
Erroneous item is here:
r,,ClockSwitchSummerWinterDone,Umschaltung Sommer-Winterzeit erfolgt,,,,6800,,,onoff,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 47 field 8 value "8D00": ERR: duplicate entry
Erroneous item is here:
r,,DisplayType,DisplayTyp,,,,8D00,,,UCH,,,"display misubishi=0x07, mtek=0x70",,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 48 field 8 value "8400": ERR: duplicate entry
Erroneous item is here:
r,,ScanPrevention,ScanPrevention,,,,8400,,,onoff,,,cyclic scan are started,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 50 field 8 value "2300": ERR: duplicate entry
Erroneous item is here:
r,,BoilerSwitchHyster,Kesselschalthysterese,,,,2300,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 51 field 8 value "2400": ERR: duplicate entry
Erroneous item is here:
r,,BoilerTempMax,Maximaltemperatur Wärmeerzeuger,,,,2400,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 52 field 8 value "2500": ERR: duplicate entry
Erroneous item is here:
r,,BoilerTempMin,Minimaltemperatur Wärmeerzeuger,,,,2500,,,temp,,,,,,
^
Error reading "/etc/ebusd/vaillant/15.ui.csv" line 53 field 8 value "2800": ERR: duplicate entry
Erroneous item is here:
r,,StartPowerVantag
Zitat von: Mitch am 28 März 2016, 17:47:54
nachdem mein ebus nun seit Monaten super lief, hat sich über Ostern meine Netzverbindung zur Heizung verabschiedet (DLAN).
Also DLAN Adapter neu gestartet und dann den RasPi.
Seit dem kamen einige Werte nicht mehr an (HK1Mode, Aussentemp, HKurve, RaumSoll, WWMode und CirPump).
Ich habe dann mal einen checkconfig gemacht und bekam nur Fehler.
Also habe ich mal im ebus Wiki geschaut und die neuste Version installiert.
Leider immer noch die Fehler und fehlenden Werte
Also irgendwas musst Du an der Konfiguration geändert haben. Kann ja nicht sein, dass es Monatelang lief und dann "plötzlich" nicht mehr.
Schau doch mal ins normale Logfile /var/log/ebusd.log
Zitat von: john30 am 28 März 2016, 11:00:00
für diese Geräte gibt es noch keine CSVs.
Da hilft nur sehr viel Geduld und versuchen, alles selbst zu entschlüsseln.
Der User @Pierce hatte hier auch schon mal die Frage für eine ähnliche Konfiguration gestellt. Hier meine Antwort dazu:
https://forum.fhem.de/index.php/topic,29737.msg397864.html#msg397864 (https://forum.fhem.de/index.php/topic,29737.msg397864.html#msg397864)
Hi, danke für deine Antwort...
Die Wahrscheinlichkeit, dass eine CSV von den anderen passt schätzt du eher gering ein oder ? :( ...
Bin eher ungeübt in sowas, daher die Frage, gibt es kleines HOWTO wie man da ran geht?
Freue mich über jede Unterstützung.
Gruß
Chris
Siehe Antwort #1607 hier im Thread
LG
pah
Zitat von: john30 am 28 März 2016, 18:33:50
Also irgendwas musst Du an der Konfiguration geändert haben. Kann ja nicht sein, dass es Monatelang lief und dann "plötzlich" nicht mehr.
Schau doch mal ins normale Logfile /var/log/ebusd.log
So sieht es da aus:
2016-03-28 17:29:35.612 [main notice] ebusd 2.0.0ea7efc started
2016-03-28 17:29:35.652 [main notice] found messages: 12 (0 conditional on 0 conditions, 0 poll, 6 update)
2016-03-28 17:29:35.675 [bus notice] signal acquired
2016-03-28 17:30:53.497 [bus notice] new master 03, master count 2
2016-03-28 17:30:58.373 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2016-03-28 17:30:58.380 [main notice] read common config file /etc/ebusd/vaillant/common.csv
2016-03-28 17:30:58.386 [main notice] read common config file /etc/ebusd/vaillant/error.csv
2016-03-28 17:30:58.388 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-03-28 17:30:58.498 [main notice] read common config file /etc/ebusd/vaillant/bai.csv
2016-03-28 17:30:58.504 [main error] error reading scan config file /etc/ebusd/vaillant/08.bai.HW7401.csv for ID "bai00", $
2016-03-28 17:30:58.834 [bus error] send to 08: ERR: read timeout, retry
2016-03-28 17:31:01.006 [bus notice] max. symbols per second: 104
2016-03-28 17:31:01.529 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:31:02.089 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:31:02.651 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:31:03.211 [bus error] send to 23: ERR: read timeout
2016-03-28 17:31:03.211 [main error] send message part 0: ERR: read timeout
2016-03-28 17:32:53.885 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:32:54.440 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:32:54.998 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:32:55.558 [bus error] send to 23: ERR: read timeout
2016-03-28 17:32:55.559 [main error] send message part 0: ERR: read timeout
2016-03-28 17:32:55.719 [main error] read cp Mode cached: ERR: invalid position
2016-03-28 17:42:59.138 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:42:59.695 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:43:00.253 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:43:00.808 [bus error] send to 23: ERR: read timeout
2016-03-28 17:43:00.808 [main error] send message part 0: ERR: read timeout
2016-03-28 17:58:00.076 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:58:00.632 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:58:01.180 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 17:58:01.742 [bus error] send to 23: ERR: read timeout
2016-03-28 17:58:01.742 [main error] send message part 0: ERR: read timeout
2016-03-28 18:12:59.160 [bus error] send to 23: ERR: read timeout, retry
2016-03-28 18:12:59.713 [bus error] send to 23: ERR: read timeout, retryDavor habe ich immer schön aa
Was kann denn das sein?
Das Poti kann sich ja nicht von allein verstellen?
Also irgendwie stimmt da einiges nicht mehr.
Heute früh festgestellt, dass der Vorlauf bei 75 Grad liegt, obwohl die HK auf 1.4 steht und es bei dieser Außentemperatur eigentlich nur bei ca. 52 Grad sein sollte.
Kann das ebus Modul hier Blödsinn machen?
Hi Mitch,
kann sein, dass du ein Update von fhem gemacht hast und dort die "Auto-USB-DETECTION" zu geschlagen hat und den ebus-Adapter geöffnet hat?
Ich hatte dies Problem. Der ebusd konnte den Adapter zwar öffnen, aber wohl nicht richtig konfigurieren. Somit hat der ebusd nur Mist gelesen und folglich auch geschrieben.
Gruß
Maik
@istler: Bitte keine Nebelkerzen zünden. Erstens schaltet ein Update von FHEM nicht die automatische USB-Erkennung einfach so ein. Und zweitens:
ZitatDer ebusd konnte den Adapter zwar öffnen, aber wohl nicht richtig konfigurieren
gibt es auch so nicht.
LG
pah
@pah:
ZitatZitatDer ebusd konnte den Adapter zwar öffnen, aber wohl nicht richtig konfigurieren
gibt es auch so nicht.
Dem muss ich widersprechen.
Bei mir war das so, dass nach einem Reboot meines System, die automatische USB-Erkennung vom FEHM aktive war und für meinen EBUS-USB-Adapter ein eigenes Device etc. angelegt hat. FEHM muss den Port irgendwie auch geöffnet haben. Auf jeden Fall habe ich nur Müll per ebusd empfangen, solange FEHM lief. FEHM gestoppt; ebusd neu gestartet => Empfang wieder perfekt. Im ebusd war kein Fehler / Warnung bezüglich des öffnen oder benutzen des seriellen Portes im Log zu finden. Was nun genau das Problem war, darum habe ich mich nicht mehr gekümmert, aber der Zusammenhang FEHM <-> ebusd war eindeutig und reproduzierbar.
Das Verhalten ist auch anderen schon aufgefallen: https://www.mikrocontroller.net/topic/346833#4522443 (https://www.mikrocontroller.net/topic/346833#4522443)
Gruß
Maik
Auf meinem ebus RasPi läuft kein fhem.
Aber ich habe das Problem gefunden. Es war nicht ebus oder der RasPi, sondern die Therme selber.
Als ich heute heim kam, hatten die Heizungen ca. 90 Grad und waren nicht anfassbar.
Ich habe dann die Therme komplet neu gebootet und siehe da, die Werte wurden wieder richtig abgerufen und der Vorlauf stimmte auch wieder.
Anscheinend hatte sich die gute Vailant aufgehängt (wahrscheinlich läuft da Windows im Hintergund ;D )
ZitatDem muss ich widersprechen.
Macht nichts, stimmt trotzdem nicht - da liegt eindeutig ein Konfigurationsfehler vor, und kein Fehler von FHEM.
Ach ja: Es heißt wirklich "FHEM", und nicht "FEHM".
pah
Hallo zusammen!
Wie kann ich die "Einmalige Speicherladung" bei meiner Vaillant realisieren?
ebusctl find -w
mc load = no data stored
Welchen Wert muss ich übergeben? On bzw. 1 hat leider nicht funktioniert. Wird zwar mit done quittiert, aber es passiert nichts.
ebusctl w -c mc load on
ebusctl w -c mc load 1
Danke!
Ok, folgendes klappt:
Einmalige Speicherladung Ein
write -h 08b505020601
Einmalige Speicherladung Aus
write -h 08b505020600
Aber wie lautet der nicht hex Command dazu?
Huch - wie kommst du auf "b505" ?
Auf jeden Fall schickst du den Hex an 08 (BAI) und vorher hast du es an "mc" geschickt...
Servus Sven.
John hat diesen Hex-Code (einige Seiten zuvor) gepostet.
08 ist bei mir EHP und nicht BAI.
Über den Curcuit MC klappt es leider nicht. Via 08 hervorragend :-)
Mich würde nur interessieren, wie der nicht-hex Cmd dazu lautet!
08 ist die Therme ("Burner"), und B505 steht für Burner Operational Data, 02 ist die Datenlänge, 06 bezieht sich auf die Speicherladung und 00/01 ist der Wert.
Steht wörtlich so in Zeile 47/48 der Untertabelle "B505" der hier schon mehrfach von mir geposteten Datei Vaillant_kurz.ods.ZitatAber wie lautet der nicht hex Command dazu?
Wie immer man möchte. Dazu einfach eine entsprechende Zeile in bai00.csv einfügen.
LG
pah
Hallo zusammen,
ich habe mal eine paar Frage zum Anschluss der eBus-Platine an den eBus.
Der eBus der Gasheizung ist in meine Wohnung gelegt und an eine Vaillant calorMATIC 350 angeschlossen (siehe Foto), wo und wie verbinde ich jetzt am besten die Platine?
Parallel an die grüne Klemme oder an das Debug-Interface der Vaillant calorMATIC 350?
Das Debug-Interface der Vaillant calorMATIC 350 hat jedoch ein komischen Stecker (jr11, rj12 passen nicht).
Welches Kabel (Querschnitt 0,75 mm2, 1,5 mm2 oder einfach Telefonkabel) verwende ich am besten und wie lang darf das Kabel es sein (bräuchte so 5m) ?
Hab schon die verschiedenen eBus Beiträge durchsucht aber nichts konkretes gefunden.
Hallo Christian,
in der Spezifikation ( http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_12_v1_3_1.pdf) steht:
"Das Übertragungsmedium ist eine verdrillte Zweidrahtleitung mit mindestens 0,6mm Durchmesser"
Ich habe das Kabel parallel zum Bus angeklemmt und über meine Cat6 Hausverkabelung in mein Arbeitszimmer geleitet. Die Kabellänge ist hier mindestens 20m und das funktioniert ohne weitere Probleme.
In der Spezifikation werden je nach Querschnitt Kabellängen von 200-1200 m aufgeführt, also sollten 5m kein Problem sein.
@Christian1982: Das ist kein "komischer Stecker", sondern ein Modularstecker RJ10, siehe beiliegende Datei für die Belegung.
@henry22:: "Verdrillte Zweidrahtleitung" kann einfacher Klingeldraht sein. Ich empfehle 4-adriges geschirmtes Telefonkabel.
LG
pah
Hallo pah,
danke für den Hinweis.
Die im Anhang erwähnte URL "http://ebus.webhop.org" ist jedoch nicht mehr aktiv. Das EBus Wiki ist jetzt unter "http://ebus-wiki.org" erreichbar.
Grüße
henry22
Nachtrag: Anscheinend ist die alte URL noch aktiv und wird auf die neue URL umgeleitet. Zeitweise funktionierte die alte URL nicht. Besser ist aber trotzdem die neue URL zu kommunizieren.
Zitat von: Marie01 am 31 März 2016, 11:48:29
John hat diesen Hex-Code (einige Seiten zuvor) gepostet.
Über den Curcuit MC klappt es leider nicht. Via 08 hervorragend :-)
Mich würde nur interessieren, wie der nicht-hex Cmd dazu lautet!
Eigentlich sollte "ebusctl w -c mc load on" genau das tun. Kann höchstens sein, dass es etwas dauert (greift nicht sofort).
Wenn es bei Dir nur via ehp klappt und nicht auf der mc, dann hast Du wieder mal eine Spezialversion, die das anders macht als bisherige EHPs...
Hallo hab ja anscheinend die Bestellung verpasst.Aber falls noch mal eine raus geht würde ich auch eine Platine mit allen Teilen nehmen.
Gruß euer
Tobi
Gesendet von iPad mit Tapatalk
Hallo Tobias,
aus dem Thread "3.Sammelbestellung eBus Platinen (https://forum.fhem.de/index.php/topic,49744.0.html3.Sammelbestellung%20eBus%20Platinen)" sind bei Christian laut dem Status noch Platinen zu haben. Das Verfahren zur Bestellung ist von Christian im ersten post beschrieben.
Die Bauteile muss jeder selbst bestellen, ist aber mit Hilfe der hinterlegten Bestellliste ganz einfach.
Gruss
henry22
Hey Danke schön, werd mich da gleich mal melden.
Gesendet von meinem GT-I9195 mit Tapatalk
Immer wenn keine Verbindung mehr zum 2ten Raspi besteht (auf welchem EBUSD läuft) , kommen diese Fehlermeldungen:
2016.04.05 11:44:09 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 124551) line 1.
2016.04.05 11:44:09 3: eval: { sprintf("%5.1f",$_) }
Die Verbindungsabrüche kommen NICHT vom 2ten Raspi, da ich dort beim Ausfall der WLAN-Verbindung eine log-Datei beschreibe und diese LEER ist.
EDIT:
zu den jeweiligen Zeitpunkten ist auch kein error-Eintrag in der ebusd.log - Sporadisch tauchen lediglich "read-timeout" auf.
Wie kann ich die Ursache für einen Verbindungsabbruch zu EBUSD unter FHEM herausfinden ? Jemand eine Idee ? :-[
Diese Abbrüche haben in der Regel nichts mit FHEM zu tun, sondern sind eine Frage des WLAN ==> besseren Adapter verwenden, timeout hochsetzen oder Watchdog entsprechend programmieren
Außerdem ist offenbar die Auswertung mit ECMDDevice etwas zu primitiv für diese Situation. Natürlich muss Perl eine Warnungsmeldung ausspucken, wenn in { sprintf("%5.1f",$_) } das Argument leer ist ==> ordentliches Perl-Programm rufen, das diesen Fall abfängt. Siehe meine Beispiele in http://www.fhemwiki.de/wiki/EBUS
LG
pah
Hallo Zusammen,
ich suche mir gerade einen Wolf.
Habe eBus an einer Vaillant Calormatic 430.
Läuft alles so weit.
Jetzt sind ja im Moment die Außentemperaturen ziemlich gestiegen, weswegen die Therme die Vorlauftemperatur runter regelt (was ja grundsätzlich Sinn macht).
Dies hat aber immer den Nachteil, dass z.B. der Keller kalt bleibt.
Was ich nun gerne machen würde, ist das über FHEM automatisch anpassen.
Bin nicht so fit, was das Thema Therme angeht, und habe mir mit meinem laienhaften Verständnis folgendes überlegt:
1. Heizkurve anheben
2. RaumSoll erhöhen
3. Außentemperatur "verfälschen"
Nun bin ich mir nicht sicher, was genau geht und was Sinn macht.
Heizkurve kann ich per FHEM ändern, RaumSoll nicht.
Außentemperatur kann man wohl über "OutsideTempOffset" ändern? aber keine AHnung wie genau und was Werte bedeuten (z.B. Außen 15 Grad, Offset auf 5 => 15 - 5 = 10 Grad Außentemperatur für die Therme?
Oder kann man den Vorlauf manuell anheben über eBus?
Was ich nicht will, die Therme auf manuell stellen und mit der "ManualOPRoomTempDesired" zu arbeiten.
Sie sollte schon im Auto Modus laufen.
Schonmal vielen Dank für eure Ideen und Input :)
Siehe hier. http://www.dpunkt.de/buecher/5540/9783960090120-smart-home-hacks-12387.html
LG
pah
Danke pah, Du hattest mir ja schonmal eine Seite aus Deinem Buch geschickt.
Habe es auch in meiner Amazon Wunschliste, aber dort ist es noch nicht verfügbar.
Wenn ich Dein Buch richtig deute, dann haben ich folgendes Szenario:
Winter: gerade richtig
Herbst/Frühling: zu kalt
Lösung: Heizkurve flacher wählen und parallel anheben
Verstehe ich aber nicht ganz. Heizkurve flacher heißt doch, das auch die Vorlauftemp geringer wird?
Und die nächste "Herausforderung", ich kann mit eBus die RaumSoll Temperatur nicht verstellen.
Buch kaufen oder einfach hier im Forum fragen...
"Heizkurve flacher" muss dann gleichzeitig mit "RaumSoll höher" gewählt werden, dass die Vorlauftemperatur im Winter wieder passt. Jedenfalls hat eine flachere HK weniger Aussentemperatureinfluss.
Den AT-Offset würde ich jetzt nicht nach Jahreszeit anpassen... Der ist eher als Anpassung für schlecht platzierte Fühler gedacht und wirkt sich auch direkt auf die Anzeige im Display aus.
Dann schon eher das RaumSoll. Ich habe leider keine 430, also kann ich nicht testen. Der TagSollWert scheint aber in der CSV in der Tat zu fehlen. Wenn hier nicht jemand mit Wissen nachhelfen kann, müsste man einfach mal die umliegenden Abfragen und mit dem eingestellten Wert vergleichen.
Bester Tipp wäre wohl, die Zeile von der 470 zu klauen, weil die NightTemp usw. dort gleich ist:
r;w,,Hc1DayTemp,HC1_DaySetTemp,,,,"2700",,,temp1,,,day setpoint,,,
LG, Sven
Danke Sven.
Hc1DayTemp finde ich übrigens weder im 430 CSV noch im 470?
Ich habe drei mögliche Dinge gefunden:
r ActualRoomTempDesiredHc1 Raumsolltemp. HK1 6300
r;wi RoomTempCorrection Raumtemperatur-Abgleich 5700
r ActualRoomTempDesiredHc1 Raumsolltemp. HK1 6300
Wobei nur RoomTempCorrection ein w für write hat.
Was genau könnte ich mit dem RoomTempCorrection machen?
Ist das wieder so eine Rechnung: RaumSoll 15 Grad - RoomTempCorrection 5 Grad = 10 Grad für die Therme?
Bei meiner 620 gibt es Zeitprogramme für Heizen und Absenken mit Solltemperaturen dazu.
Um einer möglichst optimalen Temperatureinstellung nahe zu kommen, ermittle ich nach dem Vorschlag von Reinhart (hier ca. Jan) mit VALVES einen (gewichteten) Heizbedarf. Werden bestimmte Werte über/unterschritten regle ich nach.
@Mitch:
Welche Version der Konfig hast du denn? Funktioniert die von mir gepostete Zeile?
Meine VRC700 hat einen Raumtemp-Offset. Dieser korrigiert einfach wie beim AT-Offset den angezeigten Wert, wenn bspw. der Fühler zu dicht an der Heizung oder am Fenster ist. Ich denke, dass das diese "RoomTempCorrection" bei dir ist.
Die Frage ist immer, welchen Aufwand man für eine Einsparung im einstelligen Prozentbereich treiben möchte.
LG
pah
@jkriegl: benutze bereits basierend auf dem HCS und Heating_Control Modul eine gute Steuerung, die will ich nicht ändern. Will ja "nur" die Therme in der Übergangszeit "anpassen"
@ Sven77: habe ebusd-2.x.x.
Habe Deine Zeile eingefügt:
ebusctl r -m 10 Hc1DayTemp
0.0
Habe jetzt mal einfach 24 geschrieben:
ebusctl w -c 430 Hc1DayTemp 24
done
RaumSoll zeigt immer aber immer noch 22 Grad?
Werde mal den Vorlauf beobachten, ob sich der verändert.
BTW, was ist eigentlich Hc1QuickVetoTemp?
Juhu, ich habe eine Möglichkeit gefunden:
es geht mit Hc1QuickVetoTemp und Hc1QuickVetoActive.
Man muß erst Hc1QuickVetoActive auf ja setzten, danach kann man die Hc1QuickVetoTemp verändern.
Allerdings fehlt im CSV das write, muss erst noch geändert werden:
r[b];w[/b],,Hc1QuickVetoTemp,Quick Veto Temperatur Heizkreis 1,,,,"3C00",,,temp1,,,manual override setpoint of the first heating circuit,,,
r[b];w[/b],,Hc1QuickVetoActive,Quick Veto Aktiv Heizkreis 1,,,,"3D00",,,yesno,,,manual override of the first heating circuit enabled,,,
Jetzt muss ich mir nur noch einen Script schrieben, der in einem bestimmten Außentemperaturbereich die HK nach unten legt, Hc1QuickVetoActive einschaltet und Hc1QuickVetoTemp nach oben setzten.
Gibt es denn einen Erfahrungswert für HK und RaumSoll, also Parallelverschiebung, wie am bestens? z.B.HK 1.0 und RaumSoll 25?
Moment...
Ich würde nicht HK und RaumSoll (QuickVeto = einmaliges überschreiben für 1 Tag) nach AT ändern!
Stelle die HK flacher ein und dafür RaumSoll nach oben (beides am Regler), dass der Vorlauf im Winter in etwa gleich bleibt. Vielleicht hilft der AT-Offset dabei? Aber der ist glaube ich nur für wenige Kelvin möglich. Es soll ja aber demnächst nochmal kälter werden...
Und wenn das soweit stimmt, beobachte wie sich der Vorlauf in der Übergangszeit verhält. Notfalls weiter nachbessern.
Es gibt bei den Vaillants übrigens ein Problem, was ich bisher auch noch nicht lösen konnte:
Bei niedriger Heizkurve ist der Vorlauf evtl. immer zu klein, vor allem für herkömmliche Heizkörper. Denn trotz aller Modifikationsmöglichkeiten wird ein RaumSoll von max. 30°C zur Berechnung benutzt. Aber du solltest erstmal im Rahmen der Möglichkeiten prüfen, ob das nicht vollkommen ausreicht bei dir.
Ach ja - hat die 430 eine adaptive Heizkurve?
Diese sollte man bei allen Experimenten beim Einstellen der Kurve erstmal deaktivieren, weil diese (angeblich) selbstlernend ist!
Zitat von: Sven77 am 07 April 2016, 19:45:11
Moment...
Ich würde nicht HK und RaumSoll (QuickVeto = einmaliges überschreiben für 1 Tag) nach AT ändern!
Stelle die HK flacher ein und dafür RaumSoll nach oben (beides am Regler), dass der Vorlauf im Winter in etwa gleich bleibt. Vielleicht hilft der AT-Offset dabei? Aber der ist glaube ich nur für wenige Kelvin möglich. Es soll ja aber demnächst nochmal kälter werden...
RaumSoll geht ja nicht per eBus, das ist ja das Problem, deswegen der Workaround mit QuickVeto.
Und der Vorlauf im Winter ist ja damit auch wieder richtig, stelle ja immer wieder zurück, bzw. geht das von selber, wenn ich Deine Aussage zu QuickVeto richtig deute.
Ich teste gerade folgende Funktion:
DOIF ([Aussentemp:Aussensensor] > 9.9 and [HCAutomatik] eq "on") (set Hc1QuickVetoActiveEinstellen yes,set Hc1QuickVetoTempEinstellen 24)
DOELSEIF ([Aussentemp:Aussensensor] > 14.9 and [HCAutomatik] eq "on") (set Hc1QuickVetoActiveEinstellen yes,set Hc1QuickVetoTempEinstellen 26)
DOELSEIF ([Aussentemp:Aussensensor] < 10 and [HCAutomatik] eq "on") (set Hc1QuickVetoTempEinstellen 22,set Hc1QuickVetoActiveEinstellen no)Zitat von: Sven77 am 07 April 2016, 19:45:11
Ach ja - hat die 430 eine adaptive Heizkurve?
Diese sollte man bei allen Experimenten beim Einstellen der Kurve erstmal deaktivieren, weil diese (angeblich) selbstlernend ist!
Nicht das ich wüsste
Hallo,
zugegebenermaßen habe ich meinen ebusd schon ewig nicht mehr aktualisiert, weil das System jetzt sehr stabil läuft.
Beim Umschalten auf Sommerbetrieb habe ich jetzt doch noch ein ERR: element not found entdeckt. Und zwar bei der Calormatic 470f, mcOperatingMode (zumindest hieß der damals so), Register 2F00.
Als template nehme ich:
hwmode2 UCH 0=off;1=manual;2=auto
Dort scheint es noch mehr Optionen zu geben (mindestens noch "Sommer"). Hat dies schon jemand herausgefunden und könnte mir die fehlenden Werte nennen?
Vielen Dank!
Spricht etwas dafür, auf die neuste Version des ebusd zu wechseln (verwende 1.2.0)?
schöne Grüße
Jo
Nachtrag:
5 scheint Sommerbetrieb zu sein.
Zitat von: Jojo11 am 13 April 2016, 19:58:28
...bei der Calormatic 470f, mcOperatingMode (zumindest hieß der damals so), Register 2F00.
hwmode2 UCH 0=off;1=manual;2=auto
...
Nachtrag:
5 scheint Sommerbetrieb zu sein.
Hallo,
in meiner 15.470.csv steht dazu:
r;w,,Hc1OPMode,Betriebsart Heizkreis 1,,,,"2F00",,,UCH,2=auto;3=on;4=night;5=summer,,operation mode of the first heating circuit,,,
Das könnte dann zu:
0=off;1=manual;2=auto;3=on;4=night;5=summer
zusammenwachsen...
LG,
sua
Danke!
schöne Grüße
Jo
Gesendet von meinem Nokia 8210
Hallo,
ich versuche gerade vom rein lesenden Betrieb zum schreibenden Betrieb zu wechseln.
Als erstes habe ich mir den WW Mode ausgesucht, klappt aber leider nicht.
Device:
localhost: info
version: ebusd 2.0.3b6f385
signal: acquired
symbol rate: 74
masters: 3
messages: 493
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI ;SW=0307;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 3f: master #15
address 44: slave #15, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0302;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
ebusctl command:
localhost: read -c hwc OperatingMode2
auto
localhost: write -c hwc OperatingMode2 off
done
localhost: read -c hwc OperatingMode2
auto
im Log sehe ich folgendes:
...
2016-04-26 18:31:50.325 [main debug] >>> write -c hwc OperatingMode2 off
2016-04-26 18:31:50.325 [bus info] send message: 3125b509040e2b0002
2016-04-26 18:31:50.326 [network debug] [00002] wait for result
2016-04-26 18:31:50.337 [bus debug] switching from ready to send command
2016-04-26 18:31:50.400 [bus debug] switching from send command to receive command ACK
2016-04-26 18:31:50.405 [bus debug] switching from receive command ACK to receive response
2016-04-26 18:31:50.413 [bus debug] switching from receive response to send response ACK
2016-04-26 18:31:50.420 [bus debug] notify request: done
2016-04-26 18:31:50.420 [bus debug] read res: 00
2016-04-26 18:31:50.423 [main info] write hwc OperatingMode2: decode done
2016-04-26 18:31:50.424 [main debug] <<< done
2016-04-26 18:31:50.424 [bus debug] switching from send response ACK to send SYN
...
Die ebusd Daten sehen für mich ok aus, leider wird der Wert nicht gesetzt.
Mach ich irgendetwas falsch oder hab ich einen Wert erwischt, den man nicht schreiben kann?
Falls ja, über welchen Parameter kann man denn den WW Mode setzen?
Gruss,
Wolle
edit:
Ich hab mal den vollständigen Scan eingefügt oben.
Muss ich den WW Mode evtl nicht im hwc (adr 25h) sondern im Mischer mc (adr 50h) setzten?
Sinn und Zweck des Mischers habe ich bisher nicht verstanden.
Der Mischer steuert, wie der Name schon sagt, eine Mischereinheit.
http://www.miti24.de/Heizung/Wandgeraete-Kleinkessel/Installationszubehoer/Vaillant-Rohrgruppe-mit-3-Wege-Mischer-R-3-4-0020191813::300298.html
Wird beispielsweise eingesetzt, wenn ein Heizkreis geringere Temperatur erfordert - z.B. Fußbodenheizung. Ist aber nicht immer nötig oder vorhanden.
LG
pah
Danke für die Antwort.
Bei mir wird die Therme zur Heizung und Aufladung eines Warmwasserspeicher verwendet.
Der Vorlauf wird mit einem 3-Wege Ventil umgeschaltet über einen reinen Schaltausgang.
Demnach wird dafür der Mischerkreis verwendet.
Kann ich eigentlich ein Hardware Problem ausschliessen bei dem Problem mit dem Schreiben
(wurde ja schon öfter hier im Thread diskutiert)
Ich hab den e-services Adapter seit Monaten zum reinen Lesen in Betrieb. Soweit ich verstehe beinhaltet auch das Lesen von Werten vom ebus Bus Schreiboperationen, diese funktionieren ja zuverlässig.
=> Hardwareproblem ausgeschlossen
Oder bin ich da zu optimistisch?
Gruss,
Wolle
Hallo Wolle,
also bei mir funktioniert dies. Aber meine Geräte haben wohl eine neuere (?) Software:
ddress 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0706;HW=7401", loaded "vaillant/08.bai.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=UI ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.csv"
evtl. verhält sich deine SW anders.
Gruß
Maik
@ wollet42
Prüfe, ob hinter 2b00 durch hex-Lesen nicht der Modus von mehreren circuits steckt.
Falls ja, die ganze Liste schreiben.
@jkriegl
leider verstehe ich nicht genau was ich prüfen soll
@all
Ich hab mal etwas weiter Debuginfos gesammelt
der Befehl
write -c hwc OperatingMode2 off
bewirkt folgendes auf dem Bus:
2016-04-27 16:06:57.182 [bus notice] <aa
2016-04-27 16:06:57.222 [bus notice] <aa
2016-04-27 16:06:57.262 [bus notice] <aa
2016-04-27 16:06:57.281 [network debug] [00001] wait for result
2016-04-27 16:06:57.281 [main debug]>>> write -c hwc OperatingMode2 off
2016-04-27 16:06:57.282 [bus info] send message: 3125b509040e2b0002
2016-04-27 16:06:57.302 [bus notice] <aa
2016-04-27 16:06:57.303 [bus notice]>31
2016-04-27 16:06:57.309 [bus notice] <31
2016-04-27 16:06:57.309 [bus debug] switching from ready to send command
2016-04-27 16:06:57.310 [bus notice]>25
2016-04-27 16:06:57.316 [bus notice] <25
2016-04-27 16:06:57.316 [bus notice]>b5
2016-04-27 16:06:57.323 [bus notice] <b5
2016-04-27 16:06:57.324 [bus notice]>09
2016-04-27 16:06:57.330 [bus notice] <09
2016-04-27 16:06:57.331 [bus notice]>04
2016-04-27 16:06:57.337 [bus notice] <04
2016-04-27 16:06:57.338 [bus notice]>0e
2016-04-27 16:06:57.344 [bus notice] <0e
2016-04-27 16:06:57.345 [bus notice]>2b
2016-04-27 16:06:57.351 [bus notice] <2b
2016-04-27 16:06:57.352 [bus notice]>00
2016-04-27 16:06:57.358 [bus notice] <00
2016-04-27 16:06:57.359 [bus notice]>02
2016-04-27 16:06:57.365 [bus notice] <02
2016-04-27 16:06:57.366 [bus notice]>cf
2016-04-27 16:06:57.372 [bus notice] <cf
2016-04-27 16:06:57.372 [bus debug] switching from send command to receive command ACK
2016-04-27 16:06:57.376 [bus notice] <00
2016-04-27 16:06:57.376 [bus debug] switching from receive command ACK to receive response
2016-04-27 16:06:57.380 [bus notice] <00
2016-04-27 16:06:57.385 [bus notice] <00
2016-04-27 16:06:57.385 [bus debug] switching from receive response to send response ACK
2016-04-27 16:06:57.386 [bus notice]>00
2016-04-27 16:06:57.392 [bus notice] <00
2016-04-27 16:06:57.392 [bus debug] notify request: done
2016-04-27 16:06:57.392 [bus debug] read res: 00
2016-04-27 16:06:57.392 [bus debug] switching from send response ACK to send SYN
2016-04-27 16:06:57.393 [bus notice]>aa
2016-04-27 16:06:57.395 [main info] write hwc OperatingMode2: decode done
2016-04-27 16:06:57.395 [main debug] <<<done
2016-04-27 16:06:57.399 [bus notice] <aa
2016-04-27 16:06:57.439 [bus notice] <aa
2016-04-27 16:06:57.479 [bus notice] <aa
2016-04-27 16:06:57.519 [bus notice] <aa
2016-04-27 16:06:57.559 [bus notice] <aa
2016-04-27 16:06:57.599 [bus notice] <aa
Sieht für mich soweit richtig aus ich kann jedoch keine Werte erfolgreich schreiben.
Erfolglos getestet habe ich mittlerweile OperatingMode und DesiredTemp jeweils für hc und hwc (done kommt zurück aber kein Wert wird gesetzt)
Ein anderer Ansatz:
Bisher versuche ich im B5h 09h Register ueber die B5h 09h Operation auf dem Bus zu lesen (funktioniert) und zu schreiben (funktioniert nicht).
Was ist eigentlich der Unterschied zwischen B5h 09h und B5h 05h bzw B5h 04h?
Viele Parameter findet man ja in beiden Registern.
Viele Parameter kann man ja ueber beide OPerationen adressieren.
Ich hab das so verstanden, dass das B5h 09h im Wesentlichen von VrDialog verwendet wird und auch hier in den meisten configs auftaucht.
Das B5h 04h (read) bzw B5h 05h (write) wird zwischen VRSxxx und den verschiedenen Geräten verwendet.
Deshalb hatte ich mich da bisher zurückgehalten.
Schreibt jemand Werte in diese Register (B5h 05h) um die Heizung zu steuern?
Gruss,
Wolle
Das ist leider grottenfalsch. Zum gefühlt hundertsten Mal hänge ich die immerhin halb fertige Protokolldokumentation an.
B5 steht für Vaillant
Das Byte danach charakterisiert die Operation.
LG
pah
da hatte ich das ja her (Kapitel 3.1, 3.2 und 3.4)
edit ich meine die Operationen 04h und 05h hab ich aus dem pdf /edit
In den Vailant csv files, die für meine Geräte sind z.B.
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/vaillant/25.solsy.hwc.csv
wird vornehmlich die 09h Operation verwendet für diverse Parameter, die laut Deinem pdf auch via 04h/05h gelesen bzw geschrieben werden können z.B.
OperatingMode2 (2B00) oder TempDesired2 (3200) lassen sich beide auch über 04h/05h adressieren (01h: SetTargetTemperature, 02h: SetOperationMode)
Was ist denn der richtige Weg?
Gruss,
Wolle
Habe folgendes (benutze erweiterte csvs noch von 1.x):
ebusctl r -f OperatingMode2 -> auto
ebusctl r -h 25b509030d2b00 -> 050303020303, also mehrere Infos
bei mir mit ebusctl r -f OperatingMode übersetzt -> auto;auto;off;auto;auto
Jetzt musst Du herausfinden wer für was zuständig ist.
Bei mir ist "off" der nicht benutzte HK1, dann HK2 und Solarkreis
Edit: Hab den HK2 via fhem auf eco gesetzt. Ergebnis der Abfrage:
ebusctl r -f OperatingMode -> auto;auto;off;eco;auto
ok, interessant.
Das würde auch erklären, warum ich für die Abfrage des Mode bei allen Zieladressen (hc, mc, hwc) jeweils immer den Wert für den Warmwasser (hwc) Mode sehe.
Da muss ich wohl etwas tiefer suchen und die csv Dateien üeberarbeiten.
Danke für den Hinweis.
Gruss,
Wolle
edit
Ich hab das mal schnell getestet und siehe da:
localhost: r -f -h 26b509030d2b00
050101020303
Bedeutet:
05 - Länge
01 - Modus hwc oder mc auf 01=on
01 - Modus hwc oder mc auf 01=on
02 - Modus hc (HK1) auf 02=off
03 - HK2?
03 - ??
Modus für hwc und mc ändern immer synchron, welcher was ist weiss ich nicht.
HK2 hat jkriegl ja schon entschlüsselt, kann ich nicht prüfen.
Den letzten Wert kann ich nicht verändern/entschlüsseln. Leider ist es nicht der Solar Mode
Bleibt die Frage was der beste Weg ist die Parameter zu setzen über 09h wie hier oder über das Kommando 05h.
Kann mir jemand eine Empfehlung geben?
Danke.
Gruss,
Wolle
edit2
@jkriegl
Wenn Du den Mode über fhem setzt, welchen ebus Parameter schreibst Du denn dann? Den oben von Dir genannten?
Ja
set H.mode cmd { "w -c hc OperatingMode %temp\n" }
Zitat von: Prof. Dr. Peter Henning am 21 Februar 2016, 14:24:21
Folgender Vorschlag zur Systematisierung:
Name =
[Wenn nötig, Name des Kreislaufs = Hc,Hc1..n,Hwc,Mc,Sc,Sc1..n]
[Gerät = Burner,Storage,Pump,Fan,Gasvalve etc.oder (logischer )Ort = Flow,Return,Outside]
[Option Prozess, z.B. Postrun]
[Was wird gemessen/gesetzt = Temp,Pow(er),Rate,Freq(uency)/Speed,Faults,Time]
[Optional Art der Messung/Festlegung = Desired,Max,Min,Av(erage),Switch]
inzwischen habe ich mal versucht, mir einen Überblick zu verschaffen. Das wird kein einfaches Unterfangen, da der Hersteller m.E. Studenten ohne den nötigen Background für die Pflege der DB eingesetzt hat.
Mein Ansatz wäre nun, als erstes die einzelnen Teile der verwendeten Bezeichnungen aus der DB durch entsprechende Kategorien-Kennzeichner zu ersetzen, um damit für jeden Eintrag die Teile den Kategorien zuordnen zu können. Dann müssten für diejenigen Einträge, die eine Kategorie mehrfach enthalten, entschieden werden, was stattdessen daraus gemacht werden soll.
Aus Deinem Vorschlag hätten wir also folgende Teile, optionales dabei in eckigen Klammern:
[Kreislauf,]Gerät,[Prozess,]Was[,Art]
Hier mal ein Beispiel für einen Wert aus der BAI:
PrEnergyCountHwc1
Darin wären also:
- PrEnergy=Was (Primärenergie)
- Count=Was (Anzahl)
- Hwc1=Kreislauf
Da gehts also schon im kleinen los
- Energy=Was oder PrEnergy=Was? Oder wäre Pr dann schon ein Gerät? Man könnte ja auch Environment als Gerät bezeichnen und Pr wäre dann... tja was eigentlich?
- EnergyCount=Was oder Count=Art? Im ersten Fall wäre 2x Was enthalten.
- Es gibt auch PrEnergySumHwc1, also wäre Sum/Count doch eher eine Art, richtig?
Nach der Umstellung und Vereinheitlichung könnte also aus PrEnergyCountHwc1 bspw. ein Hwc1PrimaryEnergyCount werden, wobei ich nicht weiß, was Count und Sum hier für einen Sinn haben. Vielleicht könnte ein BAi Besitzer die Werte mal auslesen und Licht ins Dunkel bringen?
Öh - ja, aber Heizung ist jetzt im Sommerbetrieb. Mal sehen, ich schreibe es auf meine Liste. Bin aber aktuell gerade sehr mit anderen Sachen zu Gange.
LG
pah
Zitat von: john30 am 07 Mai 2016, 09:39:43
Nach der Umstellung und Vereinheitlichung könnte also aus PrEnergyCountHwc1 bspw. ein Hwc1PrimaryEnergyCount werden, wobei ich nicht weiß, was Count und Sum hier für einen Sinn haben.
Sum liefert bei mir irre hohe Werte, die ungefähr durch 85.000 geteilt kWh ergeben. Ähnlich zu einem Gaszähler wird dieser Wert nur größer.
Count hab ich noch nicht geprüft.
Hallo
ich benötige Hilfe beim einrichten von ebusd am Raspberry
akuteller Projekstand:
Platine + USB2TTL Adapter hängen schon am ebus eines
Wolf SM1ebusd debian packages erfolgreich installiert und über
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0sowie
ebusctl rawrieseln die regelmäßigen Sync-Werte (<aa) ein
zwischendurch kommt dann sowas wie
71 fe 50 17 10 01 01 80 02 1b 00 00 00 00was ja perfekt passen würde, da der Service 5017 den Solardaten entspricht.
als csv habe ich nur
ebusd-configuration/ebusd-2.x.x/de/wolf/50.csvhergenommen und unter "type" alle "w" durch ein "u" für update ersetzt.
Zusammen mit "broadcast.csv", "memory.csv" und "_templates.csv" befinden sich diese im ordner /etc/ebusd
Nun zum Problem: durch
ebusctl read -c solar temp erhalte ich immer Fehlermeldungen "no data" und mit
ebusctl find -c solar temp ebenfalls "no data stored"
Dabei sollten sich die Werte doch selbstständig updaten?
Bitte um Hilfe :)
Hallo!
Ich bin durch Probleme in der Kommunikation zwischen meiner Vaillant auromatic 620 und meiner Therme ecoTec plus VC 196 3/5 auf diese Seite gestossen.
Sehr interessant!
Mein Problem ist, dass die vom Regler angezeigte Vorlauftemperatur nicht mit der empfangenen Vorlauftemperatur in der Therme übereinstimmt. (ebus Kommunikation).
Um nun etwas genauer zu sehen was da übermittelt wird, wäre es prima wenn ich den Datenverkehr schnüffeln könnte.
Ich verstehe es so, dass ich hierzu einen entsprechenden Adapter benötige und die passenden Dateien für die o.g. Geräte, richtig?
Entschuldigt bitte, dass ich nicht so im Thema stecke, aber vielleicht kann mir einer der Experten das in Kürze beschreiben?
Viele Grüße
Martin
Hallo Martin
ist alles beschrieben in eBus Schaltung in Betrieb nehmen (https://forum.fhem.de/index.php/topic,46098.0.html)
gruss
Henry22
Zitat von: flash91 am 17 Mai 2016, 17:07:40
als csv habe ich nur
ebusd-configuration/ebusd-2.x.x/de/wolf/50.csv
hergenommen und unter "type" alle "w" durch ein "u" für update ersetzt.
Zusammen mit "broadcast.csv", "memory.csv" und "_templates.csv" befinden sich diese im ordner /etc/ebusd
Werte (aus)lesen kann man mit "r" (Du hast dich für "u" entschieden) und wenn das zyklisch passieren soll, dann hängt man eine Zahl an den Aktionstyp dran. Mögliche Werte für ein Zyklus sind "1-9".
Das aber gerne auch hier (https://github.com/john30/ebusd/wiki/4.1.-Message-definition) zum nachlesen.
Zitat von: henry22 am 18 Mai 2016, 15:06:39
Hallo Martin
ist alles beschrieben in eBus Schaltung in Betrieb nehmen (https://forum.fhem.de/index.php/topic,46098.0.html)
gruss
Henry22
Hallo Henry,
vielen Dank für den Link!
Habe derzeit aber leider gar nicht die Zeit mir den Adapter zu löten. Sonst immer gerne.
Gibt es auch fertige Adapter, die mit der Vaillant Peripherie funken?
Oder gibt es hier im Forum jemanden, der mir seinen evtl. leihen kann (gegen Leihgebühr versteht sich!)
Grüße
Martin
Zitat von: theotherhalf am 18 Mai 2016, 15:57:56
Gibt es auch fertige Adapter, die mit der Vaillant Peripherie funken?
Siehe hier (https://github.com/john30/ebusd/wiki/6.-Hardware)
Zitat von: amunra am 18 Mai 2016, 15:26:37
Werte (aus)lesen kann man mit "r" (Du hast dich für "u" entschieden) und wenn das zyklisch passieren soll, dann hängt man eine Zahl an den Aktionstyp dran. Mögliche Werte für ein Zyklus sind "1-9".
Das aber gerne auch hier (https://github.com/john30/ebusd/wiki/4.1.-Message-definition) zum nachlesen.
Hmm, das Wiki hab ich gelesen und mich extra für "u" entschieden weil es dann folgendes gilt
Zitata passive message that ebusd will listen to in order to recognize updates of field values
Ich würde das so übersetzen, dass ebusd dadurch nur am Bus lauscht und falls mal eben sowas wie
71 fe 50 17 10 01 01 80 02 1b 00 00 00 00kommt versteht ebusd, dass es sich um eine Broadcastmeldung vom SM1 handelt, in dem die Solartemperaturen enthalten sind und updated die entsprechenden "field values" unter der Klasse "solar" mit dem Namen "temp".
Wie bereits gesagt funktioniert das leider nicht.
Nebenbeibemerkt ich starte ebusd mit
--readonly, da ich vorerst nur lesen möchte.
Falls ich das "u" durch "r1" ersetze erhalte ich
ERR: invalid address(wenn ich das richtig verstanden habe dürfte poll aber gar nicht funktionieren weil ja nur --readonly)
Falls ich das "u" durch "r" ersetze erhalte ich
pi@raspberry:~ $ ebusctl read -c solar temp
ERR: invalid numeric argumentebusd --checkconfigliefert mir auch keine Fehlermeldungen
Bitte um Hilfe.. :-\
Edit:
habe auch für QQ=71 und für ZZ=fe eingetragen
Dein ebusctl read -c solar temp hat doch schon mal besser funktioniert s.o. nur waren keine Daten im cache.
Also versuch es mit ebusctl read -f -c solar temp
Um alle temp csv-Eintragungen herauszubekommen versuch es mit
ebusctl find -f -c solar temp
Zitat von: jkriegl am 19 Mai 2016, 20:27:14
Dein ebusctl read -c solar temp hat doch schon mal besser funktioniert s.o. nur waren keine Daten im cache.
Also versuch es mit ebusctl read -f -c solar temp
Um alle temp csv-Eintragungen herauszubekommen versuch es mit
ebusctl find -f -c solar temp
pi@raspberry:~ $ ebusctl read -f -c solar temp
ERR: element not foundpi@raspberry:~ $ ebusctl find -f -c solar temp
u,solar,temp,,71,fe,5017,,pumpe,m,UCH,188=off;189=on,,SolarPumpe,,m,IGN:1,,,,kollektortemp,m,D2C,,°C,Kollektortemperatur,wwsolartemp,m,D2C,,°C,WW Solartemperatur
versteh ich nicht ganz...
Edit:
pi@raspberry:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 20
masters: 1
messages: 14
address 31: master #8, ebusd
address 36: slave #8
Interessant ist, dass hier der master 71 nicht registriert ist
hatte bisher erst einmal die Meldung, dass er einen zusätzlichen master erkannt hat der dann unter ebusctl info mit der Adresse 71 aufgetaucht ist
Habe zuerst vermutet, dass der Broadcast zu selten kommt und ich zu früh mit read abfrage, aber habe mich im raw modus davon überzeugt dass der Broadcast min. jede 30 sek zu sehen ist.
Edit Edit:
Habs noch eine halbe Stunde laufen lassen, bis master 71 endlich registriert war.
pi@raspberry:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 20
masters: 2
messages: 14
address 31: master #8, ebusd
address 36: slave #8
address 71: master #9
Allerdings trotzdem die Meldung:
pi@raspberry:~ $ ebusctl find -v -c solar temp
solar temp = no data stored [ZZ=fe, passive read]
Zitat von: flash91 am 19 Mai 2016, 20:32:52
pi@raspberry:~ $ ebusctl read -f -c solar temp
ERR: element not found
pi@raspberry:~ $ ebusctl find -f -c solar temp
u,solar,temp,,71,fe,5017,,pumpe,m,UCH,188=off;189=on,,SolarPumpe,,m,IGN:1,,,,kollektortemp,m,D2C,,°C,Kollektortemperatur,wwsolartemp,m,D2C,,°C,WW Solartemperatur
versteh ich nicht ganz...
hier habt ihr ziemlich gut aneinander vorbei geschrieben.
also, wenn --readonly aktiviert ist, dann kann ebusd damit keine aktiven Abfragen auf den Bus geben, ergo kannst Du mit ebusctl read wiederum nur noch Daten aus dem ebusd cache abrufen.
Dabei wird ohne Verwendung von "-f" oder "-m ..." ein cache timeout von 5 Minuten zugrunde gelegt.
"ebusctl read -f -c solar temp" geht dann natürlich nicht mehr, weil "-f" ja die Nutzung des cache verhindert.
Zitat von: flash91 am 19 Mai 2016, 20:32:52
Interessant ist, dass hier der master 71 nicht registriert ist
das ist in der Tat merkwürdig. Man müsste mal schauen, ob die CRC bei dem Broadcast stimmt. Wenn die nicht stimmt, wird die Nachricht als ungültig angesehen und der Sender auch nicht in die Liste aufgenommen.
Siehst Du denn im Logging von ebusd die Einträge mit "[update notice] update solar temp"?
VG John
Okay ich dachte mit "read -f" wird auch ein passiver read über den bus geforced (um eben nicht aus dem cache zu lesen)
Wenn ich das richtig verstanden habe, wird ein logfile nur über den Dämon erstellt.
Bis jetzt hatte ich immer den service deaktiviert und separat "ebusd -f --readonly" gestartet
Mit "service ebusd start" wird /var/log/ebusd.log erstellt in dem steht:
2016-05-20 11:21:46.367 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:21:46.379 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:21:47.029 [bus notice] signal acquired
Was ich noch nicht verstanden habe:
wenn ich ebusd über "service ebusd start" starte, konfiguriert man dann den Dämon nachträglich über den befehl "ebusd" also z.B. "ebusd --readonly" oder kann das nur beim start durch "service ebusd start --readonly" mitgegeben werden?
"service ebusd start -d /dev/ttyUSB0" liefert bei mir: (ich weiß ttyUSB0 ist eh default)
2016-05-20 11:33:52.425 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:33:52.438 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:33:52.440 [bus error] unable to open /dev/ttyUSB0: ERR: generic device error
2016-05-20 11:34:02.441 [bus error] unable to open /dev/ttyUSB0: ERR: generic device error
2016-05-20 11:35:42.128 [main notice] SIGTERM received
2016-05-20 11:35:42.230 [main notice] ebusd stopped
danach nochmal gestartet erhielt ich
2016-05-20 11:35:47.114 [bus notice] new master 71, master count 2
2016-05-20 11:35:56.582 [bus error] send to 76: ERR: read timeout, retry
2016-05-20 11:35:56.715 [bus error] send to 76: ERR: CRC error, retry
2016-05-20 11:35:56.864 [bus error] send to 76: ERR: CRC error, retry
2016-05-20 11:35:57.026 [bus error] send to 76: ERR: CRC error
2016-05-20 11:35:57.026 [main error] scan config 76 message: ERR: CRC error
seltsam dass jetzt "[main notice] ebusd 2.1.28b50d2 started" fehlt...
und warum zu 76 gesendet wird...
danach nochmal service ebusd neugestartet erhielt ich nur noch
ERR: generic device error
also sudo reboot und
"service ebusd start -d /dev/ttyUSB1" pobiert. lieferte ebenfalls
2016-05-20 12:00:42.722 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 12:00:42.732 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 12:00:42.760 [bus notice] signal acquired
obwohl ttyUSB1 nichts zugewiesen ist, schätze mal die parameter nach service ebusd start werden verworfen
auch nach 15 min laufzeit steht nicht mehr info im logfile vorhanden
Edit:
und nein leider taucht nirgendwo "[update notice] update solar temp" auf :(
Zitat von: flash91 am 20 Mai 2016, 12:10:50
Okay ich dachte mit "read -f" wird auch ein passiver read über den bus geforced (um eben nicht aus dem cache zu lesen)
Wenn ich das richtig verstanden habe, wird ein logfile nur über den Dämon erstellt.
Bis jetzt hatte ich immer den service deaktiviert und separat "ebusd -f --readonly" gestartet
Mit "service ebusd start" wird /var/log/ebusd.log erstellt in dem steht:
2016-05-20 11:21:46.367 [main notice] ebusd 2.1.28b50d2 started
2016-05-20 11:21:46.379 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-05-20 11:21:47.029 [bus notice] signal acquired
Was ich noch nicht verstanden habe:
wenn ich ebusd über "service ebusd start" starte, konfiguriert man dann den Dämon nachträglich über den befehl "ebusd" also z.B. "ebusd --readonly" oder kann das nur beim start durch "service ebusd start --readonly" mitgegeben werden?
oha, da fehlts ja wohl noch an ein paar grundlegenden Kenntnissen zum Thema Linux / Services... Vielleicht magst du dich damit erst einmal vertraut machen?
kurz gesagt: ebusd ist ein Dienst, der im Hintergrund läuft. Auf einem Interface (ttyUSB*) kann natürlich nur einer gleichzeitig sinnvoll zugreifen. Wenn Du also ebusd im Vordergrund startest "-f" und gleichzeitig durch das System als Dienst starten lässt, kann das schlecht funktionieren.
Ja bin ein relativer Frischling was Linux betrifft. (und ja etwas peinlich dass ich Dämon statt Daemon geschrieben habe ;D)
Aber ich hab ja auch geschrieben, dass ich den Dienst bisher immer deaktiviert habe bevor ich ebusd im Vordergrund ausgeführt habe.
Ich denke den Unterschied zwischen "ebusd -f" und "service ebusd start" habe ich verstanden.
(im Terminalfenster auf Abarbeitung des Programms gewartet und als Hintergrundprozess ausgeführt)
Mich wunderte warum "service ebusd start -d /dev/ttyUSB1" funktionierte, da ich dachte einem Hintergrundprozess werden die Parameter auf die gleiche Weise übergeben wie einem Prozess im Vordergrund.
Dennoch:
glaube ich das meine Linuxschwäche vorerst nichts mit dem jetzt bestehenden Problem zu tun hat ::)
(kein field value update)
Worauf ich nach dem erfolgreichen auslesen des Ebus hinaus wollte:
Ich habe zwei seperate Wolf SM1 Module, würde gerne über das Interface ttyUSB0 das 1. Modul durch einen ebusd Prozess auslesen und über ttyUSB1 das 2. Modul und dann die Prozesse so konfigurieren, dass sie auf unterschiedlichen Ports lauschen, um sie getrennt in einem python skript mit telnet anzusprechen und die jeweiligen Werte auszulesen.
Für Vordergrundprozesse ist es mir klar:
zwei Terminalfenster öffnen, im 1. "ebusd -f -d /dev/ttyUSB0 -p 8888" und im 2. "ebusd -f -d /dev/ttyUSB1 -p 8889"
Erst jetzt kommt erst meine Linuxschwäche zu tragen, da ich nicht weiß wie ich Linux erkläre im Hintergrund denselben Prozess zweimal mit unterschiedlichen Parametern zu starten.
Ich würde mich natürlich riesig freuen wenn du mir bei beiden Problemen behilflich sein kannst :)
Hallo flash91,
ein sytemdienst wird durch ein start/stop script definert. Für den ebusd ist das /etc/init.d/ebusd.
Dieses Script liest /etc/default/ebusd um parameter für den ebusd zu bekommen.
Wenn du also zwei ebus adapter an zwei unterschiedlichen Heizungssystemen hast, dann musst du z.B. einen ebusd2 systemdienst erstellen.
(/etc/init.d/ebusd2 erstellen; /etc/default/ebusd2 erstellen, mit dem Befehl "update-rc.d ebusd2 enable" den systemdienst ebusd2 erstellen und starten)
Du solltest dir dann aber auch über regeln für udev gedanken machen da linux evlt. auch mal die devicenamen für deine adpater verdreht.
Grüße
Andy
Zitat von: jamesgo am 22 Mai 2016, 16:27:11
Hallo flash91,
ein sytemdienst wird durch ein start/stop script definert. Für den ebusd ist das /etc/init.d/ebusd.
Dieses Script liest /etc/default/ebusd um parameter für den ebusd zu bekommen.
Wenn du also zwei ebus adapter an zwei unterschiedlichen Heizungssystemen hast, dann musst du z.B. einen ebusd2 systemdienst erstellen.
(/etc/init.d/ebusd2 erstellen; /etc/default/ebusd2 erstellen, mit dem Befehl "update-rc.d ebusd2 enable" den systemdienst ebusd2 erstellen und starten)
Du solltest dir dann aber auch über regeln für udev gedanken machen da linux evlt. auch mal die devicenamen für deine adpater verdreht.
Grüße
Andy
Hallo Andy, danke für die Erklärung :D
scheint keine große Sache zu sein, wenn man weiß wie.
ja das mit den Regeln für udev hab ich mir angesehen, sollte ich schon hinkriegen.
Python Script hab ich auch schon.
Fehlt nur noch, dass das field value update funktioniert. :)
Hallo John,
ich versuche "version: ebusd 2.1.681e988" auf einem odroid c2 zum laufen zu bekommen.
Der Adapter ist von eservice-online und hat mit der ebusd Version 2.1 auf einem Beaglebone problemlos funktioniert.
Beim Übersetzten gabe es keine Fehlermeldungen oder Warnings.
Ich bekomme immer wieder "read timeout" Meldungen. D.h. "read -f Flow1Sensor" funktioniert nur manchmal.
Nachdem justieren die Situation nicht verbessert ist mir folgendes aufgefallen:
<code>
(ebusd -f -d /dev/ttyEbus --scanconfig --logarea=bus --loglevel=info; und dann im ebusctl raw gesetzt)
2016-05-22 18:21:26.038 [bus notice] <aa
2016-05-22 18:21:26.039 [bus info] poll cmd: 3108b5090124
2016-05-22 18:21:26.039 [bus notice] >31
2016-05-22 18:21:26.050 [bus error] poll scan.08 id failed: ERR: read timeout
2016-05-22 18:21:26.088 [bus notice] <aa
2016-05-22 18:21:26.091 [bus notice] <10
2016-05-22 18:21:26.096 [bus notice] <50
2016-05-22 18:21:26.101 [bus notice] <b5
</code>
Nun meine Frage: Ist es richtig, dass ich von dem Befehl "3108b5090124" nur die ">31" sehe?
Grüße
Andy
PS: jetzt habe ich den Beaglebone nochmal reanimiert. Dort habe ich keine read timeouts. Doch ein Problem wg. 64-bit?
Hallo,
ich glaube ich habe eine Spur. Der odroid Kernel scheint keine highres timer zu unterstützen:
auf dem odroid c2
cat /proc/timer_list | grep resolution
.resolution: 10000000 nsecs
auf dem beagle
cat /proc/timer_list | grep resolution
.resolution: 1 nsecs
Grüße
Andy
Ich will Dich nicht enttäuschen, aber auf meiner Dockstar läuft seit Monaten eBus und nebenbei OWFS problemlos...
# cat /proc/timer_list | grep resolution
.resolution: 10000000 nsecs
.resolution: 10000000 nsecs
.resolution: 10000000 nsecs
Hey John,
gute Neuigkeiten, habe die debian packages deinstalliert und mir deine aktuellste Version von git gezogen. Jetzt läufts :D
An dieser Stelle möchte ich vorallem dir und Reinhart meinen Dank aussprechen! Ohne euch, hätte ich mein Projekt nur schwer realisieren können.
VG,
PhiL
Zitat von: jamesgo am 22 Mai 2016, 18:30:29
ich versuche "version: ebusd 2.1.681e988" auf einem odroid c2 zum laufen zu bekommen.
Der Adapter ist von eservice-online und hat mit der ebusd Version 2.1 auf einem Beaglebone problemlos funktioniert.
Beim Übersetzten gabe es keine Fehlermeldungen oder Warnings.
Ich bekomme immer wieder "read timeout" Meldungen. D.h. "read -f Flow1Sensor" funktioniert nur manchmal.
Nachdem justieren die Situation nicht verbessert ist mir folgendes aufgefallen:
<code>
(ebusd -f -d /dev/ttyEbus --scanconfig --logarea=bus --loglevel=info; und dann im ebusctl raw gesetzt)
2016-05-22 18:21:26.038 [bus notice] <aa
2016-05-22 18:21:26.039 [bus info] poll cmd: 3108b5090124
2016-05-22 18:21:26.039 [bus notice] >31
2016-05-22 18:21:26.050 [bus error] poll scan.08 id failed: ERR: read timeout
2016-05-22 18:21:26.088 [bus notice] <aa
2016-05-22 18:21:26.091 [bus notice] <10
2016-05-22 18:21:26.096 [bus notice] <50
2016-05-22 18:21:26.101 [bus notice] <b5
</code>
Nun meine Frage: Ist es richtig, dass ich von dem Befehl "3108b5090124" nur die ">31" sehe?
Also mit dem highres timer hat das m.E. nichts zu tun, auch wenn 10ms schon recht grob sind. Nach dem Log sieht es einfach so aus, als ob vom bus innerhalb von 12 ms das gesendete Byte (sprich die Quelladdresse 0x31) nicht zurück kommt. Du kannst mal mit den ebusd Aufrufparametern (timeouts siehe https://github.com/john30/ebusd/wiki/2.-Run#ebus-options) bzw. dem latency Wert versuchen (siehe https://github.com/john30/ebusd/wiki/2.-Run#device-options), etwas mehr Zeit einzuräumen.
Zitat von: jamesgo am 22 Mai 2016, 16:27:11
Hallo flash91,
ein sytemdienst wird durch ein start/stop script definert. Für den ebusd ist das /etc/init.d/ebusd.
Dieses Script liest /etc/default/ebusd um parameter für den ebusd zu bekommen.
Wenn du also zwei ebus adapter an zwei unterschiedlichen Heizungssystemen hast, dann musst du z.B. einen ebusd2 systemdienst erstellen.
(/etc/init.d/ebusd2 erstellen; /etc/default/ebusd2 erstellen, mit dem Befehl "update-rc.d ebusd2 enable" den systemdienst ebusd2 erstellen und starten)
Du solltest dir dann aber auch über regeln für udev gedanken machen da linux evlt. auch mal die devicenamen für deine adpater verdreht.
Grüße
Andy
Leider war ich bei dem Vorhaben nicht ganz erfolgreich..
Die durchgeführten Schritte:ich habe "/etc/init.d/ebusd2" erstellt mit
sudo cp /etc/init.d/ebusd /etc/init.d/ebusd2in /etc/init.d/ebusd2
. /lib/lsb/init-functions
[ -r /etc/default/ebusd ] && . /etc/default/ebusd
zu
. /lib/lsb/init-functions
[ -r /etc/default/ebusd2 ] && . /etc/default/ebusd2
geändert
und mit
sudo cp /etc/default/ebusd /etc/default/ebusd2"/etc/default/ebusd2" erstellt und dort "--port=8889" gesetzt.
danach: "update-rc.d ebusd2 enable"
update-rc.d: error: no runlevel symlinks to modify, aborting!
dacht mir egal, einfach mal reboot ausprobieren.
So,
folgendes Problem jetzt:
die Services lassen sich getrennt problemlos starten, laden die richtigen Konfigurationen (richtigen Port), aber sobald ich beide starte erhalte ich bei "service ebusd(2) status" dass einer von beiden "
active (exited)" ist.
Warum beendet sich ein Service sobald der zweite gestartet wird?
Was habe ich vergessen?
habe auch schon probiert in /etc/init.d/ebusd2
DAEMON=/usr/bin/ebusd
PIDFILE=/var/run/ebusd.pidauf
DAEMON=/usr/bin/ebusd2
PIDFILE=/var/run/ebusd2.pidabzuändern und natürlich auch
sudo cp /usr/bin/ebusd /usr/bin/ebusd2durchgeführt. Änderte nichts an dem Problem.
Bitte um Hilfe :)
Grüße,
PhiL
Hi,
versuch mal "update-rc.d ebusd2 defaults".
systemctl | grep ebusd
sollte beide services anzeigen.
Grüße
Andy
Zitat von: jamesgo am 28 Mai 2016, 09:35:27
Hi,
versuch mal "update-rc.d ebusd2 defaults".
systemctl | grep ebusd
sollte beide services anzeigen.
Grüße
Andy
Hi, danke für die schnelle Antwort (:
pi@raspberry:~ $ sudo update-rc.d ebusd2 defaults
insserv: script ebusd: service ebusd already provided!
pi@raspberry:~ $ systemctl | grep ebusd
ebusd.service loaded active running LSB: controls ebusd, the daemon for communication with eBUS heating systems.
ebusd2.service loaded active exited LSB: controls ebusd, the daemon for communication with eBUS heating systems.
pi@raspberry:~ $ ebusctl -p 8888 read -c solar temp
0;54.88;60.12
pi@raspberry:~ $ ebusctl -p 8889 read -c solar temp
error connecting to localhost:8889
Falls ich aber die Services "ebusd" und "ebusd2" stoppe und dann nur "ebusd2" starte so funktionierts
pi@raspberry:~ $ systemctl | grep ebusd
ebusd2.service loaded active running LSB: controls ebusd, the daemon for communication with eBUS heating systems.
pi@raspberry:~ $ ebusctl -p 8889 read -c solar temp
0;68.19;51.62
BG,
PhiL
Hi PhiL,
ich gehe mal davon aus, dass "systemctl stop ebusd.serivce" bzw "systemctl stop ebusd2.service" (und auch start) funktionieren.
D.h. die service sind nun richtig aufgesetzt.
Wie sehen denn deine /etc/default/ebusd und /etc/default/ebusd2 aus?
Grüße
Andy
Zitat von: jamesgo am 29 Mai 2016, 08:16:24
Hi PhiL,
ich gehe mal davon aus, dass "systemctl stop ebusd.serivce" bzw "systemctl stop ebusd2.service" (und auch start) funktionieren.
D.h. die service sind nun richtig aufgesetzt.
Wie sehen denn deine /etc/default/ebusd und /etc/default/ebusd2 aus?
Grüße
Andy
Morgen Andy,
vielen Dank!! :D es liegt wohl daran wie die Services gestartet werden.
Bisher habe ich immer über
service ebusd start
service ebusd2 start gestartet
aber mit
systemctl start ebusd
systemctl start ebusd2sind jetzt beide "active running" und ich kann auch beide über ebusctl ansprechen!!
Nochmals danke & vG,
PhiL
klingt super.
Der Unterschied könnte noch an folgedem Eintrag in /etc/init.d/ebusd liegen:
PIDFILE=/var/run/ebusd.pid
Zitat von: jamesgo am 29 Mai 2016, 09:27:32
klingt super.
Der Unterschied könnte noch an folgedem Eintrag in /etc/init.d/ebusd liegen:
PIDFILE=/var/run/ebusd.pid
Den hatte und habe ich eh auf "PIDFILE=/var/run/ebusd2.pid" abgeändert
Zitat von: flash91 am 29 Mai 2016, 16:47:14
Den hatte und habe ich eh auf "PIDFILE=/var/run/ebusd2.pid" abgeändert
Mit dem jüngsten commit 086dea5 (https://github.com/john30/ebusd/commit/086dea50604aba44fe4b789fb525a7a7a984af23) lassen sich jetzt auch ganz einfach mehrere ebusd Instanzen starten, indem mehrere EBUSD_OPTS in /etc/default/ebusd eingetragen werden.
Hallo Liste,
mein ebusd läuft nun wirklich schon über Jahre stabil - aber jetzt gibt es Macken.
Kommandos, die - direkt mit ebusctl abgesetzt, ohne Netzwerk oder gar FHEM dazwischen - noch vor wenigen Tagen problemlos gelaufen sind, ergeben plötzlich
ERR: arbitration lost oder
ERR: invalid argument oder
ERR: invalid position oder
sie funktionieren eben. Manchmal.
Schlussfolgerung: irgendetwas im EBUS-Adapter ist gestorben, oder hat sich zumindest verändert.
Denn an keiner Stelle der Software habe ich auch nur ein Bit verändert.
Kennt irgendjemand diese Symptome ?
LG
pah
Hallo,
das kommt mir im Zusammenhang mit dem eservice Adapter bekannt vor. Dort war der sendende Teil wohl defekt. Mit dem Eigenbau funktioniert seitdem alles bestens.
schöne Grüße
Jo
Gesendet von meinem Nokia 8210
@pah
obwohl deine Schaltung eigentlich sehr gut funktioniert, hatte ich das auch schon einmal live verfolgen können. Bei mir war damals die Zenerdiode im Sendeweg defekt. So ähnlich war es auch bei meinem Log und wurde immer ärger bis es gar nicht mehr funktionierte.
Die Broadcast sind damals noch durchgekommen, aber Abfragen nur nach Zufall.
Hat ja jetzt nichts mit der zuverlässigen Schaltung direkt zu tun, war einfach ein defekter Bauteil der langsam seine Funktion einstellte.
Ich hoffe du hast jetzt noch eine Reserveplatine, aber wie ich dich kenne hast den Fehler ohnehin schnell gefunden.
LG
OK, kann ich hiermit bestätigen, es war die Zenerdiode.
Womit sich mir die Frage stellt, ob wir auf dem EBus eine Überspannungsschutzschaltung brauchen.
LG
pah
Hallo Zusammen,
ich habe folgende Konfiguration die ich mit Hilfe vom ECMD auslese:
bai00.cfg
# Speichertemp Warmwasser
get Speichertemp cmd {"r hwctemp temp\n"}
get Speichertemp expect ".*\n*"
get Speichertemp postproc { $_ }
define Speichertemp ECMDDevice bai00.class
attr Speichertemp IODev EBUS
attr Speichertemp group Vaillant
attr Speichertemp icon sani_supply_temp
attr Speichertemp room Vaillant
Im State vom Reading steht jetzt:
STATE Speichertemp 47.38
Jetzt möchte ich aber im State nur die Temperatur haben und nicht zusätzlich den String Speichertemp.
Wie mache ich das am besten?
Gruß
@lewej
hänge noch stateFormat dran, so etwa:
define Speichertemp ECMDDevice bai00.class
attr Speichertemp IODev EBUS
attr Speichertemp group Vaillant
attr Speichertemp icon sani_supply_temp
attr Speichertemp room Vaillant
attr Speichertemp stateFormat Speichertemp
dann hast du im STATE nur den Wert stehen.
LG
Zitat von: Prof. Dr. Peter Henning am 12 Juli 2016, 11:38:31
OK, kann ich hiermit bestätigen, es war die Zenerdiode.
Womit sich mir die Frage stellt, ob wir auf dem EBus eine Überspannungsschutzschaltung brauchen.
LG
pah
Hallo Pah!
ich hatte damals auch überlegt warum gerade die Zenerdiode defekt wurde.
Der Darlingtontransistor selbst hält ja genug Strom aus und die eigentliche Strombegrenzung im Sendeweg erfolgt ja nur durch eine der Dioden im Brückengleichrichter, der Z-Diode und der Emitter - Collectorstrecke. Es müsste eigentlich genügen einen Leistungswiderstand (von etwa 47 Ohm/2Watt) der Z-Diode vorschalten oder einfach die nächst höhere Leistungsklasse der Z-Diode einzubauen. Es muss halt nur 100% gewährleistet sein, das dann der erzeugte Spannungshub noch zum Senden ausreicht. Diese Korrekturen könnten ohne Änderung an der Platine erfolgen.
Das ist jetzt nix berechnet, sondern einfach von mir mal geschätzt.
An was hättest du sonst bei der Überspannungsschaltung gedacht?
Hallo Miteinander,
bin seit kurzem Besitzer einer Vaillant EcoCompact VCS206 mit dem VR900 Kommunikationsmodul.
Über die Smartphone APP "multiMATIC" funktioniert alles. Da mir der Funktionsumfang dort jedoch zu wenig ist hatte ich alle Hoffnungen nun auf FHEM gesetzt.
Habe ebusd lt. Forumbeschreibung zum laufen gebracht (opened), bekomme aber keine Info vom VR900 (über "ebusctl info" erhalte ich
version: ebusd 2.0.0ea7efc
signal: no signal
masters: 1
messages: 12)
Ich bekomme auch keine Schnittstelle geöffnet/angezeigt über lsusb, d.h. kein Zugriff auf EBUS-Daten. Ein USB-Kabel ist zw. VR900 u. RaspberryPi3 angeschlossen. Bin schon fast am verzweifeln.
Hat von Euch eventuell einer einen Tip wie man da weiterkommt und hoffe auf Euren Erfahrungsschatz?
Danke im Voraus.
LG
Torsten
Klar, ohne Schnittstelle nichts im ebusd.
Macht das "Kommunikationsmodul" denn überhaupt eine solche auf ? Oder wird das als HI-Device eingebunden ?
Wirklich gar keine Info über lsusb ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 05 August 2016, 06:54:14
Klar, ohne Schnittstelle nichts im ebusd.
Macht das "Kommunikationsmodul" denn überhaupt eine solche auf ? Oder wird das als HI-Device eingebunden ?
Wirklich gar keine Info über lsusb ?
LG
pah
Vielen Dank für die schnelle Antwort.
Über lsusb erhalte ich folgende Rückmeldung:
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Offensichtlich wird kein zusätzliches Device/Schnittstelle vom VR900 erkannt und geöffnet.
Kann da auch ein Zusammenhang mit dem Pi3 bestehen, vielleicht durch einen fehlenden Treiber?
Schließe ich probehalber am Pi3 mal zusätzlich eine Wechselfestplatte über USB an wird auch ein DEVICE 004 mit einer ID erkannt.
Vielleicht ist ja jemand schon auf ähnliche Probleme gestoßen.
Über einen Kommentar dazu würde ich mich freuen.
LG
Torsten
Hallo Thorsten,
wenn ich Deinen ersten post richtig gelesen habe, hast Du die USB Schnittstelle des Pi mit der USB Schnittstelle des VR900 verbunden. Wenn das so ist kann das natürlich nicht funktionieren.
der ebusd erwartet den Datenstrom vom eBUS, der über den eBUS adapter und einem USB/V24 adapter zugeführt wird. Eine Platine für den ebus-Adapter kann Du hier https://forum.fhem.de/index.php/topic,49744.msg414611.html#msg414611 (https://forum.fhem.de/index.php/topic,49744.msg414611.html#msg414611) bestellen ( wenn noch welche vorhanden sind). Die Beschreibung der Schaltung etc findest Du hier http://www.fhemwiki.de/wiki/EBUS.
LG
Heinrich
Die USB-Schnittstelle des VR900 ist nur dazu da, einen WLAN-Dongle anzuschließen!
Man braucht schon einen eigenen eBus-Adapter für FHEM... (eigentlich ziemlich dumm das VR900) ::)
okay.
Kann man denn am EBUS neben dem VR900 einen weiteren EBUS-Koppler gefahrlos anschließen???
LG
Torsten
...prinzipiell ja, siehe https://github.com/john30/ebusd/wiki/eBUS-background (https://github.com/john30/ebusd/wiki/eBUS-background)
im Einzelfall kommst drauf an ob sich die Masteradressen so einstellen lassen das es keine Überschneidung gibt. Kommt natürlich auch drauf an, was Du mit dem ebusd und darauf aufsetzenden Programmen machst. Da können sich Einstellungen natürlich ins Gehege kommen.
Ich würde es einfach mal probieren und mit dem ebusd und den entsprechenden Hardwarekomponenten zunächst nur lesend arbeiten und sehen was auf dem bus passiert.
VR900 nutzt die Masteradresse 00 und ist somit problemlos parallel zu betreiben.
Danke für die Infos. :D :D :D
EBUS Koppler ist bestellt. Mal schauen wie es dann damit aussieht.
LG an alle
Hallo zusammen,
dank eurer Unterstützung habe ich meine Vaillant Gastherme (VC 146/5-5 Exklusiv) mit RaspberryPi0 und USB ebus Koppler erfolgreich in Betrieb genommen. Dafür schonmal vielen Dank!
Meine Anlage hat noch Solarunterstüzung mit einem 300L Speicher (VIHS300). Geregelt wird das Solarmodul mit dem Vaillant Modul VR70. Als Regler in der Therme kommt der VR700 zu Einsatz, was wohl der Nachfolger vom VR470 ist (irgendwo mal aufgeschnappt).
Es läuft schon gut. Es wird sauber über den Bus
gelesen (mehr möchte ich auch erstmal nicht!).
Über FHEM (eBus Modul) und über den Bus kann ich folgendes Auslesen (siehe auch Bild im Anhang):
Vorlauf / Rücklauf / Außentemperatur
Zeit der Funkuhr aus dem Außensensor
Einen Pumpenstatus (Normalerweise immer off, wenn aber die Therme anspringt um Wasser aufzuheizen geht der State in overrun)
ebus info liefert das:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0608;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
address 31: master #8, ebusd
address 36: slave #8
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
Ich sehe ja das nur die 08.bai csv geladen wurde, die anderen Teile meiner Anlage sind wohl noch zu neu.
Da ich schon gerne z.B. die Kollektortemp. und noch weitere Werte auslesen möchte, wie würde ich da weiter vorgehen? Dazu fehlt mir irgendwie der nächste Ansatz. Ich will halt nix kaputt machen...
Wenn ich mir nun die Busmeldungen anschaue, werden mir doch nur Meldungen angezeigt welche über die 08.csv "übersetzt" werden, oder?
Es wäre nett wenn mir kurz erläutert werden könnte, wie ich hier nun weiter machen kann.
Vielen Dank nochmals.
Gruß der Manolo
Hi manolo,
ich habe inzwischen eine recht umfangreiche CSV zur VRC700. Die VR70 ist selbst nur passiv, hier lese ich nur eine einzige Nachricht mit bzw. habe auch nur den notwendigen Eintrag für diese eine.
Gerade in Sachen Solar fehlt aber noch ziemlich viel in der VRC, momentan ist erstmal nur der Solar-Gesamtertrag bekannt und auslesbar. Schicke mir bitte Deine Mailadresse als PN, dann bekommst Du einen Link zur CSV.
Ich bitte vorerst um Verständnis, dass ich diese nicht ganz frei veröffentliche, weil ich so einen besseren Überblick behalte wer welche Konfiguration hat, um Änderungen gezielt testen zu lassen!
LG, Sven
Hallo Sven,
habe inzwischen auch einen ebus-Koppler an meiner VRC700 am laufen, bekomme aber keine readings zurück, weil ich sicher nicht die richtige "CSV-Datei" in meinem ebusd-Verzeichnis habe.
Unter ebusctl info erhalte ich folgende Rückmeldung:
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 23
masters: 3
messages: 14
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
Kannst du mir bitte mal auf die Sprünge helfen, wie man da weiterkommt. ;) ;) ;)
Ich möchte vorerst mal nur im Lesemodus mit der VRC700 arbeiten.
LG
Torsten
Hi Leute,
habe da mal ein Problem mit dem schreiben der Heizkurve in den calorMatic470.
in der bai00.cfg steht
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"w -c 470 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
#
als Fehler in FHEM kommt als state
HeizkurveSchreiben usage: write [-d ZZ] -c CIRCUIT NAME [VALUE[;VALUE]*]
or: write [-c CIRCUIT] -h ZZPBSBNNDx
Write value(s) or hex message.
-d ZZ override destination address ZZ
-c CIRCUIT CIRCUIT of the message to send
NAME NAME of the message to send
VALUE a single field VALUE
-h send hex write message:
ZZ destination address
PB SB primary/secondary command byte
NN number of following data bytes
Dx data byte(s) to send
woran liegt das?
Dann noch ne Frage wegen dem Auslesen des Wasserdruck's
in bai00.cfg
# Wasserdruck
get Wasserdruck cmd {"r -f WaterPressure\n"}
get Wasserdruck expect "\d+\n\n"
get Wasserdruck postproc { sprintf("%5.1f",$_) }
die Ausgabe in FHEM
???
mfg maik
versuche mal beim Wasserduck folgende Syntax (pressure klein geschrieben), denn da hat sich bei den CSV Files was geändert.:
# Anlagendruck
get Wasserdruck cmd {"r -f Waterpressure press.0\n"}
get Wasserdruck expect ".*\n*"
get Wasserdruck postproc { sprintf("%5.1f",$_) }
und beim Heizkurve schreiben würde ich einmal testen was den der Befehl in der Konsole sagt, eventuell brauchst du da noch #install!
pi@raspberry2 ~ $ ebusctl w -c 470 Hc1HeatCurve 0.90
done
pi@raspberry2 ~ $ ebusctl w -c 470#install Hc1HeatCurve 0.90
LG
@John
ich habe leider Pech gehabt und in meiner Vaillant Therme (VCW) ist der Zündtrafo defekt geworden. Den gibt es nicht als Ersatzteil, so musste ich die komplette Steuerplatine tauschen.
Leider wird nun bei einem "scan" zwar der slave 08 richtig erkannt, aber keine ID, HW und SW ausgelesen. Kannst du dir vorstellen, ob ich diese Information noch wo eingeben/aktivieren muss?
Die Steuerplatine ist richtig eingestellt, habe ich nochmals kontrolliert bzw. richtig gesetzt, also
d.97 mit Passwort "17" aktiviert, dann auf d.93 und d.76 die Gerätekennung "37" laut Teilenummer eingetragen.
Die Teilenummer steht zwar nirgends, habe ich aus der Liste der Gerätekennung für Brennwertgeräte aber ermittelt. Der Techniker hat mir das so erklärt, dass es zwar immer dieselbe Platine ist, aber für die unterschiedlichen Länder unterschiedliche Codes eingetragen sein müssen weil das der Gesetzgeber so vorschreibt. Ich habe ein AT Gerät, daher die "37", bei DE wäre es "30".
alte Platine hat tadellos funktioniert
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 57
masters: 3
messages: 209
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002"
Austausch der Platine und nun fehlen MF, ID, HW, SW
version: ebusd 2.0.3b6f385
signal: acquired
symbol rate: 23
masters: 3
messages: 235
address 03: master #3
address 08: slave #3, scanned
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 26: slave, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002"
logischerweise wird nun die 08.bai nicht mehr geladen und somit kann ich nur mehr mit der 430 sprechen.
pi@raspberry2 ~ $ ebusctl scan result
26;Vaillant;43000;0215;2002;21;11;09;0020028515;0907;006374;N5
Hast du einen Rat für mich wie ich die "08.bai" wieder laden kann ohne auf die "Automatik" zu verzichten?
LG
Reinhart
Dein Scan zeigt nur noch das Gerät 26 (warum ist der 430 überhaupt auf einmal 26?), weder 08 noch 15...
Bist du sicher, dass der eBus elektrisch richtig angeschlossen ist?!
Da allerdings die anderen Geräte noch im "info" stehen - wurde ebusd schonmal neu gestartet?
ich habe nun noch versucht die alte 1.2 zu installieren, hier kann ich die Configs ja händisch laden und es funktioniert soweit das ich auch die Broadcast über die CSV als Klartext erhalte. Aber es funktionieren nur die Broadcast und die 430, aber von der 08.bai kann ich nichts abfragen!
Bin nun wieder zurück zur letzten eBusd Version 2.1 und erhalte im Prinzip dieselben Ergebnisse nur das hier die Broadcast nicht übers CSV übersetzt werden. Es sieht so aus, als wäre die Hauptplatine zum Schreiben gesperrt, daher auch keine Scan Info. Mit der Calormatic die ja am selben eBus hängt funktioniert alles wie gehabt, schreiben und lesen und es kommen auch im Raw Modus alle Broadcast fehlerfrei an.
Ich werde im September ohnehin noch eine Wartung durchführen lassen, da werde ich den Techniker nochmals befragen was da auf der neuen Platine nun anders sein soll (sofern die Techniker darüber überhaupt informiert werden).
2016-08-26 11:29:39.537 [main notice] ebusd 2.1.422b8d6 started
2016-08-26 11:29:39.983 [main error] error reading config files: ERR: duplicate entry, /etc/ebusd/vaillant/15.140.csv:9
2016-08-26 11:29:39.984 [main notice] found messages: 364 (16 conditional on 9 conditions, 0 poll, 6 update)
2016-08-26 11:29:40.010 [bus notice] signal acquired
2016-08-26 11:29:41.072 [bus notice] new master 10, master count 2
2016-08-26 11:29:41.105 [bus notice] new master 03, master count 3
2016-08-26 11:29:41.106 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:29:47.115 [update notice] unknown MS cmd: 1008b5110101 / 09706e401960620000ff
2016-08-26 11:29:51.143 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:29:57.155 [update notice] unknown MS cmd: 1008b5110101 / 09706e401960620000ff
2016-08-26 11:29:59.117 [update notice] unknown BC cmd: 10feb516080039171126080516
2016-08-26 11:29:59.375 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-08-26 11:30:01.156 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:05.145 [update notice] unknown MS cmd: 1008b5110101 / 09706e401960620000ff
2016-08-26 11:30:07.145 [update notice] unknown MS cmd: 1008b5040100 / 0a00172508ffffffff4019
2016-08-26 11:30:07.420 [update notice] unknown MS cmd: 1008b5110102 / 05033c78466e
2016-08-26 11:30:11.172 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:15.164 [update notice] unknown MS cmd: 1008b5110101 / 096e6e40195a620000ff
2016-08-26 11:30:17.100 [update notice] unknown BC cmd: 10feb51603014017
2016-08-26 11:30:21.170 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:25.163 [update notice] unknown MS cmd: 1008b5110101 / 096e6e401944620000ff
2016-08-26 11:30:27.149 [update notice] unknown MS cmd: 1008b5110102 / 05033c78466e
2016-08-26 11:30:31.177 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:35.209 [update notice] unknown MS cmd: 1008b5110101 / 096e6e401938620000ff
2016-08-26 11:30:37.215 [update notice] unknown MS cmd: 1008b5040100 / 0a00482508ffffffff4019
2016-08-26 11:30:37.435 [update notice] unknown BC cmd: 10feb505020400
2016-08-26 11:30:41.194 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:45.189 [update notice] unknown MS cmd: 1008b5110101 / 096e6e401934600000ff
2016-08-26 11:30:49.220 [update notice] unknown MS cmd: 1008b51009000000ffffff05ff00 / 0101
2016-08-26 11:30:53.497 [bus notice] scan 02 timed out (227 slaves left)
2016-08-26 11:30:54.056 [bus notice] scan 04 timed out (226 slaves left)
2016-08-26 11:30:54.615 [bus notice] scan 05 timed out (225 slaves left)
2016-08-26 11:30:55.806 [bus notice] scan 06 timed out (224 slaves left)
2016-08-26 11:30:56.968 [update notice] unknown MS cmd: 1008b5110101 / 096e6e4019325e0000ff
2016-08-26 11:30:57.044 [bus error] scan 08 failed (223 slaves left): ERR: ACK error
2016-08-26 11:30:57.684 [bus notice] scan 09 timed out (222 slaves left)
2016-08-26 11:30:58.241 [bus notice] scan 0a timed out (221 slaves left)
2016-08-26 11:30:58.796 [bus notice] scan 0b timed out (220 slaves left)
2016-08-26 11:30:59.509 [bus notice] scan 0c timed out (219 slaves left)
2016-08-26 11:31:00.068 [bus notice] scan 0d timed out (218 slaves left)
man sieht hier aber schön, das beim scan auf 08 (beim Schreibversuch um das Scan Kommando abzusetzen) ein ACK error kommt. Die Broadcast von der selben Platine kommen aber gleichzeitig schön herein, die müssen ja nicht extra angestoßen werden. Entweder verhalten sich die Pegel der Hauptplatine anders oder es ist wirklich ein kleiner Fehler bei der Abstimmung.
Ich werde aber trotzdem noch einen neuen eBus Konverter testen um alle Hardwarefehler auszuschließen.
LG
so, mein Problem hat sich erledigt.
Ich weiß zwar jetzt nicht genau was es war, weil ich 2 Dinge auf einmal durchgeführt habe. Ich habe die Steuerplatine komplett zurück gesetzt und den eBus Koppler getauscht, der war noch eine Lochrasterplatine.
Nun wird die "bai" wieder sauber erkannt und kann nun auch wieder beschrieben werden. Die Platine war zwar original verpackt und wurde vor meinen Augen geöffnet, aber nach dem Reset funktioniert der eBus wieder zu 100%.
version: ebusd 2.1.422b8d6
signal: acquired
symbol rate: 93
masters: 3
messages: 426
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401",loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8
LG
Zitat von: Reinhart am 26 August 2016, 18:24:45
so, mein Problem hat sich erledigt.
Ich weiß zwar jetzt nicht genau was es war, weil ich 2 Dinge auf einmal durchgeführt habe. Ich habe die Steuerplatine komplett zurück gesetzt und den eBus Koppler getauscht, der war noch eine Lochrasterplatine.
Nun wird die "bai" wieder sauber erkannt und kann nun auch wieder beschrieben werden. Die Platine war zwar original verpackt und wurde vor meinen Augen geöffnet, aber nach dem Reset funktioniert der eBus wieder zu 100%.
version: ebusd 2.1.422b8d6
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401",loaded "bai.308523.inc", "vaillant/08.bai.csv"
Ist das das erwartete Scan Ergebnis? Oder bräuchtest Du eines der anderen BAI inc Files?
VG John
Danke John, mir ist noch nichts aufgefallen was nicht funktionieren würde, deshalb bin ich mit den CSV Files zufrieden, habe auch die letzten 2.1 vom Github geladen. Aber Fehler war das schon ein komischer, an die Calormatic kann geschrieben und gelesen werden, Broadcast sind auch da aber bei einem Schreibversuch in die BAI00 ist es aus und bei der alten Steuerplatine hat es tadellos funktioniert.
Bei der Installation der CSV Files (nach deinem Wiki im Github) ist mir aufgefallen, dass er behauptet das die Version 2.1 zu alt sei, weil er der Meinung ist es handelt sich um 2.0. Habe es dann händisch installiert.
pi@raspberry2 ~ $ ebusd -V
ebusd 2.1.422b8d6
pi@raspberry2 ~ $ sudo dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
(Lese Datenbank ... 70363 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von ebusd-configuration 2.1.b143f39-de (durch ebusd-configuration-2.1.b143f39-de_all.deb) ...
Ersatz für ebusd-configuration wird entpackt ...
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 von ebusd-configuration (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
ebusd-configuration
pi@raspberry2 ~ $
hier die Fehlermeldung, der vermeintlichen Version 2.0
LG
Reinhart
Zitat von: Reinhart am 27 August 2016, 13:19:06
Bei der Installation der CSV Files (nach deinem Wiki im Github) ist mir aufgefallen, dass er behauptet das die Version 2.1 zu alt sei, weil er der Meinung ist es handelt sich um 2.0. Habe es dann händisch installiert.
pi@raspberry2 ~ $ ebusd -V
ebusd 2.1.422b8d6
Kann es sein, dass Du den ebusd nicht mit dem .deb package installiert, sondern nochmal selbst compiliert hast? 422b8d6 ist nämlich vom 24. Juli und somit wesentlich neuer als das 2.1 Release...
VG John
Hi,
So nachdem die Therme und der Raumregler integriert sind (Vaillant VC126 & CalorMatic470/4)
würde ich gerne noch die RecoVair (Vaillant Lüftung) abfragen und fernsteuern.
Die RecoVair hängt an einem Buskoppler "V32"
hier ebusctl info
pi@ospi ~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 40
masters: 4
messages: 448
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "b
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "va
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8
address 38: slave #13, scanned "MF=Vaillant;ID=V32 ;SW=0117;HW=9802"
ganz unten ist der Buskoppler an dem die Lüftung hängt.
Theoretisch könnte ich die Lüftung im Groben über den VRC470 auslesen, da ich diese über diesen auch lesen und steuern kann. Nur leider sind in der 15.470.csv dafür keine Einträge.
Nun meine Bitte,
wie muss ich vorgehen um eine eigene *.csv dafür zu erstellen?
wo muss ich anfangen, oder hat bereits jemand eine Vaillant Lüftung integriert??
mfg maik
Zitat von: john30 am 27 August 2016, 13:27:53
Kann es sein, dass Du den ebusd nicht mit dem .deb package installiert, sondern nochmal selbst compiliert hast? 422b8d6 ist nämlich vom 24. Juli und somit wesentlich neuer als das 2.1 Release...
VG John
ja genau, habe es selber compiliert!
Müsste aber bei einem Numerischen Vergleich >= ja auch funktionieren, oder?
LG
Und noch ein Problem,
und zwar mit der hcmode.inc
dort steht
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
dieser liefert immer "standby"
pi@ospi ~ $ ebusctl r -c bai Mode
Standby
nun habe ich mal gegrab't :D
hier was ich mitlesen konnte
pi@ospi ~ $ ebusctl grab result
1008b5100900000066ffff050000 / 0101 = bai Mode
66 = standby / 05 = Frostschutz(System aus)
1008b510090000008cffff050000 / 0101 = bai Mode
8c = WW / 05 = Frostschutz(System aus)
1008b5100900000066ffff010000 / 0101 = bai Mode
66 = standby / 01 = Normalbetrieb
1008b5100900000068ffff010000 / 0101 = bai Mode
68 = unbekannt vermutlich Pumpennachlauf (WWbereitung)?
den Staus Heizbetrieb konnte ich noch nicht testeten , Aussentemp > 34°C :)
in wie weit muss ich die hcmode.inc abändern damit ich den Status richtig auswerten kann??
So,
zu der Message ist mir etwas aufgefallen!
1008b5100900000050ffff010000 / 0101 = bai Mode
1008b5100900000064ffff010000 / 0101 = bai Mode
1008b5100900000068ffff010000 / 0101 = bai Mode
die beiden Werte vor "ffff010000", also die 50,64,68 ist die WW _Solltemp
Hex 50 = Dez 80 / 2 = 40°C Soll
Hex 64 = Dez 100 / 2 = 50°C Soll
usw....
Dieser Wert ändert sich immer wenn ich die WWSolltemp ändere!
das heist, in dieser message wird nicht der Status " standby, Heizbetrieb, WW Betrieb " übertragen. lediglich ob das Gerät im "normalen" oder "frostschutzbetrieb" ist.
mfg maik
Zitat von: TiPpFeHlEr am 27 August 2016, 15:36:48
Hi
....
würde ich gerne noch die RecoVair (Vaillant Lüftung) abfragen und fernsteuern
...
Theoretisch könnte ich die Lüftung im Groben über den VRC470 auslesen, da ich diese über diesen auch lesen und steuern kann. Nur leider sind in der 15.470.csv dafür keine Einträge.
Nun meine Bitte,
wie muss ich vorgehen um eine eigene *.csv dafür zu erstellen?
wo muss ich anfangen, oder hat bereits jemand eine Vaillant Lüftung integriert??
mfg maik
Maik .. Ich bin dabei !
Würde meine recovair auch gerne über ebus steuern, finde aber keinerlei Infos.
VG ak323
Hallo Zusammen,
habe jetzt mein EBUSD Daemon mal auf den neusten GIT Stand gebracht.
War vorher noch mit der Version 1 unterwegs.
Erkennen scheint er erstmal ziemlich viel:
version: ebusd 2.1.acae7c3
signal: acquired
symbol rate: 33
masters: 3
messages: 745
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"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0118;HW=5202", loaded "vaillant/e0.omu.csv"
aber ich habe zwischen drin immer noch ein Gerät was er nicht zuordnern oder noch keine Daten für gibt:
2016-08-31 21:21:03.075 [update notice] unknown MS cmd: 1008b509040ed10001 / 00
2016-08-31 21:21:04.927 [update notice] update cc Mode QQ=10: 30;auto;00;off
2016-08-31 21:21:05.094 [update notice] update cc Status QQ=10: 0;off;-;0
2016-08-31 21:21:05.275 [update notice] unknown MS cmd: 1023b5040132 / 0a000000000000b0110000
2016-08-31 21:21:05.426 [update notice] unknown MS cmd: 1023b5040131 / 020000
2016-08-31 21:21:05.593 [update notice] update ehp SourcePumpStatus QQ=10: 0
2016-08-31 21:21:05.777 [update notice] update ehp errorhistory QQ=10: 2;2;22:34;30.08.2016;580
2016-08-31 21:21:08.030 [bus error] poll mc CfgHeatSinkType failed: ERR: read timeout
2016-08-31 21:21:08.899 [update notice] update broadcast hwcStatus QQ=10: off;31;off
2016-08-31 21:21:09.072 [update notice] unknown BC cmd: 10feb505034a0100
2016-08-31 21:21:09.724 [update notice] update ehp VWLSBadWeatherOMU2 QQ=10: no
2016-08-31 21:21:09.895 [update notice] update ehp SourceTempInput QQ=10: 21.06;ok
2016-08-31 21:21:10.059 [update notice] update ehp ActualEnvironmentPowerPercentage QQ=10: 0
2016-08-31 21:21:10.221 [update notice] update ehp ActualEnvironmentPower QQ=10: 0
2016-08-31 21:21:10.638 [update notice] update broadcast vdatetime QQ=10: 21:21:04;31.08.2016
2016-08-31 21:21:10.948 [update notice] update broadcast outsidetemp QQ=10: 15.312
2016-08-31 21:21:11.149 [update notice] update broadcast datetime QQ=10: 15.312;21:21:04;31.08.2016
2016-08-31 21:21:11.631 [update notice] unknown BC cmd: 10feb5160304b011
2016-08-31 21:21:12.152 [update notice] unknown MS cmd: 1023b505072b000100000000 / 00
2016-08-31 21:21:14.554 [update notice] unknown MS cmd: 1025b50903290000 / 050000060300
2016-08-31 21:21:15.154 [update notice] unknown MS cmd: 1008b509040ed10001 / 00
2016-08-31 21:21:16.101 [update notice] unknown MS cmd: 1050b5040133 / 02b011
2016-08-31 21:21:16.557 [update notice] unknown MS cmd: 03e0b5210500020b00e7 / 0900020f01f900070000
2016-08-31 21:21:17.499 [update notice] unknown MS cmd: 03e0b509040e3a0000 / 00
2016-08-31 21:21:18.486 [update notice] unknown MS cmd: 03e0b509040e480000 / 00
2016-08-31 21:21:19.105 [update notice] unknown MS cmd: 1050b5040132 / 0a002806030101b0110100
2016-08-31 21:21:19.256 [update notice] unknown MS cmd: 1050b5040131 / 020001
2016-08-31 21:21:21.233 [update notice] unknown BC cmd: 10feb505034a0100
2016-08-31 21:21:23.028 [update notice] unknown MS cmd: 1050b505072b000100000000 / 00
2016-08-31 21:21:25.069 [update notice] unknown MS cmd: 1008b5130304cd01 / 0acd010100000001000100
2016-08-31 21:21:27.353 [update notice] unknown MS cmd: 1008b509040ed10001 / 00
2016-08-31 21:21:29.424 [update notice] unknown MS cmd: 1025b5040132 / 0a000000000000b0110000
2016-08-31 21:21:29.574 [update notice] unknown MS cmd: 1025b5040131 / 020000
Hat jemand eine Idee was das "MS" noch sein kann?
Danke und Gruß
Denny
MS = master-slave
BC = broadcast
Das erste Byte ist immer die Masteradresse, das zweite die Slaveadresse bzw. FE bei Broadcasts.
Dein EHP und die Steuerung schicken also offenbar reichlich Nachrichten, deren Sinn (noch) unbekannt ist. Im Grunde bleiben dir 2 Möglichkeiten:
a) (Hex-)Inhalte beobachten und erraten, um was es sich handelt - danach dann eine CSV-Zeile hinzufügen und John weiterleiten
b) einen Dummy-Eintrag für jede unbekannte Nachricht erstellen, um das "unknown" aus dem Log zu bekommen - da die Nachrichten aber eh verschickt werden, wird dann aus dem "unknown MS cmd" nur ein "update ... ..."
Zitat von: Sven77 am 01 September 2016, 07:34:30
a) (Hex-)Inhalte beobachten und erraten, um was es sich handelt - danach dann eine CSV-Zeile hinzufügen und John weiterleiten
Wenn ich etwas mehr Zeit habe, werde ich das mal beobachten!
Danke und Gruß
Denny
Zitat von: TiPpFeHlEr am 27 August 2016, 15:36:48
Die RecoVair hängt an einem Buskoppler "V32"
Theoretisch könnte ich die Lüftung im Groben über den VRC470 auslesen, da ich diese über diesen auch lesen und steuern kann. Nur leider sind in der 15.470.csv dafür keine Einträge.
Hallo Maik,
ich bin seit einigen Tagen auch in der Lage, meine recovair auszulesen und werde in den nächsten Wochen versuchen, dafür eine csv zu entwerfen.
Mit dem Buskoppler kann man meines Wissens lediglich die Betriebsart steuern und ein paar Statuswerte auslesen und sonst nichts.
Was kannst Du denn über die VRC470 alles in der Lüftung verändern bzw. auslesen? Das wäre schon mal hilfreich zu wissen, dann könnte man den Buskoppler auch so langsam besser unterstützen.
VG John
Zitat von: Reinhart am 27 August 2016, 18:03:12
ja genau, habe es selber compiliert!
Müsste aber bei einem Numerischen Vergleich >= ja auch funktionieren, oder?
das ist ja das Paketmanagement vom System, das den Fehler produziert, weil dort eben nicht ebusd 2.1 als installiert bekannt ist, sondern ebusd 2.0.
die ebusd-conf hat aber eine Abhängigkeit auf ebusd 2.1 und fragt bei der Installation nicht beim ebusd die Version nach, sondern nur im Paketmanagement, und somit passt das nicht zusammen.
VG John
Hi John,
erstmal Top das du auch eine RecoVair hast :D
also im Moment kann ich mit dem 470/4 nur die Lüfterstufen 1-6 Tag/Nacht, und den Modus Tag /Nacht auslesen bzw steuern.
seltsam ist, wenn ich die Lüfterstufen ändere, wird kein befehl vom 470 an den Buskoppler geschickt (ebusctl listen/ ebusctl grab)
mfg maik
p.s. ein Kunde von uns hat einen VR900 mit der MultiMatic App, er ist total entäuscht! es lassen sich lediglich Tag/Nacht/WW/Aussen - Temp auslesen und ändern, und eigentlich alle Schaltzeiten, dies geht aber nicht da die App defekt ist. Auch beim auslesen der SollTemp's gibt es grosse Probleme, wir werden das mal mit Vaillant besprechen. Der Kunde hatte erwartet wesentlich mehrt Informationen / Funktionen damit abdecken zu können.
Zitat von: john30 am 17 September 2016, 08:59:32
Mit dem Buskoppler kann man meines Wissens lediglich die Betriebsart steuern und ein paar Statuswerte auslesen und sonst nichts.
Das würde aber keinen Sinn machen!
Da der Buskoppler VR32 dafür gedacht ist Kaskaden (mehrere Heizgeräte) in den EBUS zu integrienen.
also auch 2-x Thermen, dafür müsste also der Buskoppler alle nötigen Daten übertragen / empfangen können.
Der Grund für den Buskoppler bei mir ist das Die Therme und die Lüftung je ein Heizgerät im EBUS darstellt. die Therme hat die Adresse 1, auch das Lüftungsgerät hätte die 1, da dies zum Konflikt führen würde, benutzt man den Buskoppler und gibt der Lüftung die 2.
mfg maik
Zitat von: TiPpFeHlEr am 17 September 2016, 13:32:18
Das würde aber keinen Sinn machen!
Da der Buskoppler VR32 dafür gedacht ist Kaskaden (mehrere Heizgeräte) in den EBUS zu integrienen.
also auch 2-x Thermen, dafür müsste also der Buskoppler alle nötigen Daten übertragen / empfangen können.
ja ich weiß. ich vermute, dass der VR32 lediglich die b504/b505 Kommandos an das Heizgerät weiterleitet, aber nicht die Konfigurationsänderungen. Es wäre interessant, das herauszufinden, aber ich selbst habe halt keinen VR32, insofern für mich schwierig.
Zitat von: TiPpFeHlEr am 17 September 2016, 13:32:18
Der Grund für den Buskoppler bei mir ist das Die Therme und die Lüftung je ein Heizgerät im EBUS darstellt. die Therme hat die Adresse 1, auch das Lüftungsgerät hätte die 1, da dies zum Konflikt führen würde, benutzt man den Buskoppler und gibt der Lüftung die 2.
Ich habe das über getrennte eBus Interfaces + jeweils einen eigenen ebusd gelöst. Funktioniert auch :-)
Im Prinzip könnte man sogar irgendwann so weit gehen, dass ebusd auch als Buskoppler arbeitet. Aber dafür müsste man erstmal rauskitzeln, was der VR32 so treibt...
Hi John,
1. wenn du die RecoVair an einem eigenen EBUSD hängen hast, kannst du die Lüftung noch über deinen 470 steuern??
2. wie soll ich vorgehen um den VR32 auszutesten?
3. hast du mal hex beispiele die ich an den VR32 senden kann?
Ich hatte schon mehrere versucht, es kommt aber immer "element not found"
mfg maik
Zitat von: TiPpFeHlEr am 17 September 2016, 16:52:28
1. wenn du die RecoVair an einem eigenen EBUSD hängen hast, kannst du die Lüftung noch über deinen 470 steuern??
Ich hab keinen 470, nur ne EHP mit zugehörigem UIH.
Zitat von: TiPpFeHlEr am 17 September 2016, 16:52:28
2. wie soll ich vorgehen um den VR32 auszutesten?
Du könntest erstmal einen scan initiieren ("ebusctl scan"), eine halbe Minute warten und dann das Ergebnis posten ("ebusctl scan result").
Zitat von: TiPpFeHlEr am 17 September 2016, 16:52:28
3. hast du mal hex beispiele die ich an den VR32 senden kann?
Du könntest mal mit "ebusctl hex 38b509030d000" (bzw. "ebusctl w -h 38b509030d000" für ebusd 2.1) anfangen, das sollte dann evtl. die Raumtemperatur sein.
@ John
1. achso :)
2. pi@ospi ~ $ ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;11;32;0010004276;0001;007809;N3
15;Vaillant;47000;0420;1403;21;14;32;0020171280;0082;031167;N9
38;Vaillant;V32 ;0117;9802
3. nein kommt nix
pi@ospi ~ $ ebusctl w -h 38b509030d000
ERR: invalid numeric argument
pi@ospi ~ $ ebusctl w -h 38b509030d0000
ERR: element not found
mfg maik
Zitat von: TiPpFeHlEr am 17 September 2016, 17:21:18
3. nein kommt nix
pi@ospi ~ $ ebusctl w -h 38b509030d000
ERR: invalid numeric argument
pi@ospi ~ $ ebusctl w -h 38b509030d0000
ERR: element not found
hm, sehr übersichtlich...
probier mal "ebusctl w -h 38b5090124"
pi@ospi ~ $ ebusctl w -h 38b5090124
ERR: element not found
@ John
kann es sein das der write befehl nicht funtioniert?
ebusctl w -h 38b509030d0000
mein 470er reagiert nur auf ein "read"
pi@ospi ~ $ ebusctl w -h 15b509030d0000
ERR: element not found
pi@ospi ~ $ ebusctl r -h 15b509030d0000
038b0100
habe dann mal gleich als read getestet ---> nichts :(
pi@ospi ~ $ ebusctl r -h 38b509030d0000
ERR: element not found
ebusctl info
pi@ospi ~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 22
masters: 4
messages: 449
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8
address 38: slave #13, scanned "MF=Vaillant;ID=V32 ;SW=0117;HW=9802"
mfg maik
Zitat von: TiPpFeHlEr am 17 September 2016, 19:36:20
ebusctl info
pi@ospi ~ $ ebusctl info
version: ebusd 2.1.28b50d2
Ah, Du hast ebusd 2.1, dann musst Du natürlich das "hex" Kommando benutzen, also:
ebusctl hex 38b509030d0000
ebusctl hex 38b5090124
Damit das auch klappt, muss ebusd mit "--enablehex" gestartet werden, sonst sind beliebige hex Kommandos gar nicht erlaubt.
so,
ebusd läuft jetze mit --enablehex
folgendes kommt nun zurück.
pi@ospi /etc/default $ ebusctl hex 38b509030d0000
ERR: read timeout
pi@ospi /etc/default $ ebusctl hex 38b509030d0000
ERR: read timeout
pi@ospi /etc/default $ ebusctl hex 15b509030d0000
03830100
pi@ospi /etc/default $ ebusctl hex 08b509030d0000
0100
pi@ospi /etc/default $ ebusctl hex 38b5090124
ERR: arbitration lost
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 07:43:32
pi@ospi /etc/default $ ebusctl hex 38b509030d0000
ERR: read timeout
Tja, also die Raumtemperatur bekommt man über den Koppler schon manl nicht auf regulärem Weg...
Zitat von: TiPpFeHlEr am 18 September 2016, 07:43:32
pi@ospi /etc/default $ ebusctl hex 38b509030d0000
pi@ospi /etc/default $ ebusctl hex 38b5090124
ERR: arbitration lost
Diesen Befehl könntest Du einfach nochmal wiederholen, da hat wer anders dazwischen gefunkt. Ich gehe aber davon aus, dass das auch keine Erleuchtung sein wird.
Dann versuchen wir mal B504:
ebusctl hex 38b5040100
ebusctl hex 38b5040101
ebusctl hex 38b504010d
ebusctl hex 38b5040116
Was kannst Du denn eigentlich über den 470 alles in der gekoppelten Lüftung einstellen?
Hi,
pi@ospi ~ $ ebusctl hex 38b5040100
ERR: read timeout
pi@ospi ~ $ ebusctl hex 38b5040101
ERR: read timeout
pi@ospi ~ $ ebusctl hex 38b504010d
ERR: read timeout
pi@ospi ~ $ ebusctl hex 38b5040116
ERR: read timeout
wie oben schon gesagt:
1. die MaxLüfterstufen 1-6 für Tag / Nacht
2. die Betriebsart Auto/Tag/Nacht
diese müssten also in einem noch unbekannten Speicherbereich des 470 liegen.
Offtopic: warum kann ich mit ebusctl grab all + ebusctl grab result, eigentlich nicht die von mir abgesetzten Befehele sehen?
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 09:11:05
wie oben schon gesagt:
1. die MaxLüfterstufen 1-6 für Tag / Nacht
2. die Betriebsart Auto/Tag/Nacht
Okay, so kommen wir nicht vorwärts. Kannst Du mal grab result abholen & speichern, dann via 470 die von der Lüftung einstellbaren Werte verändern, danach wieder grab result abholen & speichern und die Differenz posten?
Zitat von: TiPpFeHlEr am 18 September 2016, 09:11:05
Offtopic: warum kann ich mit ebusctl grab all + ebusctl grab result, eigentlich nicht die von mir abgesetzten Befehele sehen?
Weil die ja bis jetzt alle nicht beantwortet wurden.
@John
gibt es kein script, das einfach alle möglichen hex sendet und die Antwort in eine Datei speichert?
und wenns durchgelaufen ist-->einfach nachschauen ob irgendwo was zurück kam?
des würde die Arbeit doch erleichtern. :)
und nein ich kann dieses script nicht selber erstellen, dafür reicht meine Kenntnis dann doch nicht aus.
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 09:17:57
gibt es kein script, das einfach alle möglichen hex sendet und die Antwort in eine Datei speichert?
klar, so etwas hab ich natürlich, aber das hilft hier auch nichts, weil zumindest die Register 0-4 Temperaturen liefern sollten. Nachdem da aber keine Antwort kommt, geht das offensichtlich grundsätzlich ganz anders über den VR32. Und das gilt es erstmal herauszufinden, was nur auf einer Anlage klappt, in der ein solcher VR32 verbaut ist, sprich: nicht bei mir...
so hier "grab all result"
1. vorher
pi@ospi ~ $ ebusctl grab result
1008070400 / 0ab5424149303005187401 = scan.08 ident
1008b5040100 / 0a0316170918090716500d = bai DateTime
1008b5100305ff01 / 00
1008b5100900000064ffff010000 / 0101 = bai Mode
1008b5110100 / 08a00213001f100080 = bai Status
1008b5110101 / 095456500dff5e0000ff = bai Status01
1008b5110102 / 05033c6e5082 = bai Status02
1008b512020064 / 00
1008b513020508 / 00
1033b5170408070400
10feb505022900
10feb5050362411e
10feb5050362421f
10feb5050362431f
10feb5160301100d = broadcast outsidetemp
10feb5160301400c = broadcast outsidetemp
10feb5160301500d = broadcast outsidetemp
10feb5160301800c = broadcast outsidetemp
10feb5160301b00c = broadcast outsidetemp
10feb5160301e00c = broadcast outsidetemp
10feb51603040010
10feb51603042010
10feb516080007160918090716 = broadcast vdatetime
10feb516080008010918090716 = broadcast vdatetime
10feb516080008020918090716 = broadcast vdatetime
10feb516080008030918090716 = broadcast vdatetime
10feb516080008090918090716 = broadcast vdatetime
10feb516080008100918090716 = broadcast vdatetime
10feb516080008470818090716 = broadcast vdatetime
10feb516080008550818090716 = broadcast vdatetime
10feb516080009040918090716 = broadcast vdatetime
10feb516080009320818090716 = broadcast vdatetime
10feb516080009330818090716 = broadcast vdatetime
10feb516080009410818090716 = broadcast vdatetime
10feb516080009480818090716 = broadcast vdatetime
10feb516080009500818090716 = broadcast vdatetime
10feb516080009510818090716 = broadcast vdatetime
10feb516080009560818090716 = broadcast vdatetime
10feb516080009570818090716 = broadcast vdatetime
10feb516080009580818090716 = broadcast vdatetime
10feb516080009590818090716 = broadcast vdatetime
10feb516080010000918090716 = broadcast vdatetime
10feb516080010170818090716 = broadcast vdatetime
10feb516080010180818090716 = broadcast vdatetime
10feb516080010240818090716 = broadcast vdatetime
10feb516080010250818090716 = broadcast vdatetime
10feb516080010260818090716 = broadcast vdatetime
10feb516080010270818090716 = broadcast vdatetime
10feb516080010280818090716 = broadcast vdatetime
10feb516080010340818090716 = broadcast vdatetime
10feb516080010350818090716 = broadcast vdatetime
10feb516080010360818090716 = broadcast vdatetime
10feb516080010370818090716 = broadcast vdatetime
10feb516080010420818090716 = broadcast vdatetime
10feb516080010430818090716 = broadcast vdatetime
10feb516080010440818090716 = broadcast vdatetime
10feb516080010460818090716 = broadcast vdatetime
10feb516080010520818090716 = broadcast vdatetime
10feb516080010530818090716 = broadcast vdatetime
10feb516080011030818090716 = broadcast vdatetime
10feb516080011040818090716 = broadcast vdatetime
10feb516080011100818090716 = broadcast vdatetime
10feb516080011110818090716 = broadcast vdatetime
10feb516080011120818090716 = broadcast vdatetime
10feb516080011130818090716 = broadcast vdatetime
10feb516080011190818090716 = broadcast vdatetime
10feb516080011200818090716 = broadcast vdatetime
10feb516080011210818090716 = broadcast vdatetime
10feb516080011220818090716 = broadcast vdatetime
10feb516080011290818090716 = broadcast vdatetime
10feb516080011300818090716 = broadcast vdatetime
10feb516080011310818090716 = broadcast vdatetime
10feb516080011380818090716 = broadcast vdatetime
10feb516080012000818090716 = broadcast vdatetime
10feb516080012050818090716 = broadcast vdatetime
10feb516080012060818090716 = broadcast vdatetime
10feb516080012070818090716 = broadcast vdatetime
10feb516080012080818090716 = broadcast vdatetime
10feb516080012090818090716 = broadcast vdatetime
10feb516080012140818090716 = broadcast vdatetime
10feb516080012150818090716 = broadcast vdatetime
10feb516080012160818090716 = broadcast vdatetime
10feb516080012230818090716 = broadcast vdatetime
10feb516080012570718090716 = broadcast vdatetime
10feb516080012580718090716 = broadcast vdatetime
10feb516080012590718090716 = broadcast vdatetime
10feb516080013010818090716 = broadcast vdatetime
10feb516080013020818090716 = broadcast vdatetime
10feb516080013050918090716 = broadcast vdatetime
10feb516080013530718090716 = broadcast vdatetime
10feb516080013540718090716 = broadcast vdatetime
10feb516080013550718090716 = broadcast vdatetime
10feb516080018450818090716 = broadcast vdatetime
3310b5180ab57265636f5602170203
2. nacher
pi@ospi ~ $ ebusctl grab result
1008070400 / 0ab5424149303005187401 = scan.08 ident
1008b5040100 / 0a0316190918090716500d = bai DateTime
1008b5100305ff01 / 00
1008b5100900000064ffff010000 / 0101 = bai Mode
1008b5110100 / 08a00213001f100080 = bai Status
1008b5110101 / 095456500dff5e0000ff = bai Status01
1008b5110102 / 05033c6e5082 = bai Status02
1008b512020064 / 00
1008b513020508 / 00
1033b5170408070400
10feb505022900
10feb5050362411e
10feb5050362421f
10feb5050362431f
10feb5160301100d = broadcast outsidetemp
10feb5160301400c = broadcast outsidetemp
10feb5160301500d = broadcast outsidetemp
10feb5160301800c = broadcast outsidetemp
10feb5160301b00c = broadcast outsidetemp
10feb5160301e00c = broadcast outsidetemp
10feb51603040010
10feb51603042010
10feb516080007160918090716 = broadcast vdatetime
10feb516080008010918090716 = broadcast vdatetime
10feb516080008020918090716 = broadcast vdatetime
10feb516080008030918090716 = broadcast vdatetime
10feb516080008090918090716 = broadcast vdatetime
10feb516080008100918090716 = broadcast vdatetime
10feb516080008470818090716 = broadcast vdatetime
10feb516080008550818090716 = broadcast vdatetime
10feb516080009040918090716 = broadcast vdatetime
10feb516080009320818090716 = broadcast vdatetime
10feb516080009330818090716 = broadcast vdatetime
10feb516080009410818090716 = broadcast vdatetime
10feb516080009480818090716 = broadcast vdatetime
10feb516080009500818090716 = broadcast vdatetime
10feb516080009510818090716 = broadcast vdatetime
10feb516080009560818090716 = broadcast vdatetime
10feb516080009570818090716 = broadcast vdatetime
10feb516080009580818090716 = broadcast vdatetime
10feb516080009590818090716 = broadcast vdatetime
10feb516080010000918090716 = broadcast vdatetime
10feb516080010170818090716 = broadcast vdatetime
10feb516080010180818090716 = broadcast vdatetime
10feb516080010240818090716 = broadcast vdatetime
10feb516080010250818090716 = broadcast vdatetime
10feb516080010260818090716 = broadcast vdatetime
10feb516080010270818090716 = broadcast vdatetime
10feb516080010280818090716 = broadcast vdatetime
10feb516080010340818090716 = broadcast vdatetime
10feb516080010350818090716 = broadcast vdatetime
10feb516080010360818090716 = broadcast vdatetime
10feb516080010370818090716 = broadcast vdatetime
10feb516080010420818090716 = broadcast vdatetime
10feb516080010430818090716 = broadcast vdatetime
10feb516080010440818090716 = broadcast vdatetime
10feb516080010460818090716 = broadcast vdatetime
10feb516080010520818090716 = broadcast vdatetime
10feb516080010530818090716 = broadcast vdatetime
10feb516080011030818090716 = broadcast vdatetime
10feb516080011040818090716 = broadcast vdatetime
10feb516080011100818090716 = broadcast vdatetime
10feb516080011110818090716 = broadcast vdatetime
10feb516080011120818090716 = broadcast vdatetime
10feb516080011130818090716 = broadcast vdatetime
10feb516080011190818090716 = broadcast vdatetime
10feb516080011200818090716 = broadcast vdatetime
10feb516080011210818090716 = broadcast vdatetime
10feb516080011220818090716 = broadcast vdatetime
10feb516080011290818090716 = broadcast vdatetime
10feb516080011300818090716 = broadcast vdatetime
10feb516080011310818090716 = broadcast vdatetime
10feb516080011380818090716 = broadcast vdatetime
10feb516080012000818090716 = broadcast vdatetime
10feb516080012050818090716 = broadcast vdatetime
10feb516080012060818090716 = broadcast vdatetime
10feb516080012070818090716 = broadcast vdatetime
10feb516080012080818090716 = broadcast vdatetime
10feb516080012090818090716 = broadcast vdatetime
10feb516080012140818090716 = broadcast vdatetime
10feb516080012150818090716 = broadcast vdatetime
10feb516080012160818090716 = broadcast vdatetime
10feb516080012230818090716 = broadcast vdatetime
10feb516080012570718090716 = broadcast vdatetime
10feb516080012580718090716 = broadcast vdatetime
10feb516080012590718090716 = broadcast vdatetime
10feb516080013010818090716 = broadcast vdatetime
10feb516080013020818090716 = broadcast vdatetime
10feb516080013050918090716 = broadcast vdatetime
10feb516080013530718090716 = broadcast vdatetime
10feb516080013540718090716 = broadcast vdatetime
10feb516080013550718090716 = broadcast vdatetime
10feb516080018450818090716 = broadcast vdatetime
3310b5180ab57265636f5602170203
keine Änderung
das seltsame ist ja das es keinerlei nachricht vom 470 an die Lüftung gibt
Ausser
1033b5170408070400
und evtl. die Antwort
3310b5180ab57265636f5602170203
Ich denke dies ist eine ident abfrage des 470 und die Antwort der Lüftung/VR32 darauf
diese werden regelmässig (ca. 5Min) automatisch abgesetzt und sind immer gleich, daher taucht sie auch nur 1mal auf
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 09:23:33
das seltsame ist ja das es keinerlei nachricht vom 470 an die Lüftung gibt
Ausser
1033b5170408070400
und evtl. die Antwort
3310b5180ab57265636f5602170203
Ich denke dies ist eine ident abfrage des 470 und die Antwort der Lüftung/VR32 darauf
Puh, das ist ja sehr eklig. Dann ist das über den VR32 eine völlig andere Kommunikation als zu allen anderen Geräten, weil das Ding nicht transparent Nachrichten durchleitet, sondern nur explizit auf Anfrage.
Probier mal:
ebusctl hex 33b5170508b5040100
Da sollte dann im Log kurz danach eine unknown MM vorbeikommen, die auch im grab result zu finden sein sollte.
pi@ospi /var/log $ ebusctl hex 33b5170508b5040100
done
2016-09-18 09:39:09.486 [main notice] hex cmd: 3133b5170508b5040100
2016-09-18 09:39:13.168 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:39:16.714 [bus notice] poll scan.08 id:
2016-09-18 09:39:16.945 [update notice] update bai Status02 QQ=10: auto;60;55.0;80;65.0
2016-09-18 09:39:17.964 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:39:20.678 [bus notice] poll scan.08 id:
2016-09-18 09:39:23.186 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:39:25.541 [update notice] update broadcast outsidetemp QQ=10: 13.688
2016-09-18 09:39:27.233 [bus notice] poll scan.08 id:
2016-09-18 09:39:32.661 [bus notice] poll scan.08 id:
2016-09-18 09:39:33.219 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:39:37.273 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:39:38.654 [bus notice] poll scan.08 id:
2016-09-18 09:39:43.351 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:39:45.002 [bus notice] poll scan.08 id:
2016-09-18 09:39:47.287 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:39:50.685 [bus notice] poll scan.08 id:
2016-09-18 09:39:53.320 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:39:57.026 [bus notice] poll scan.08 id:
2016-09-18 09:39:57.319 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:40:02.689 [bus notice] poll scan.08 id:
2016-09-18 09:40:03.341 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:40:07.001 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-09-18 09:40:07.475 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:40:08.896 [bus notice] poll scan.08 id:
2016-09-18 09:40:13.396 [update notice] update bai Status01 QQ=10: 39.0;40.0;13.688;-;46.0;off
2016-09-18 09:40:14.845 [bus notice] poll scan.08 id:
2016-09-18 09:40:16.742 [update notice] update bai DateTime QQ=10: valid;09:40:17;18.09.2016;13.688
2016-09-18 09:40:19.911 [update notice] update bai Mode QQ=10: Standby
2016-09-18 09:40:20.646 [bus notice] poll scan.08 id:
pi@ospi /var/log $
keine Antwort :(
Zitat von: TiPpFeHlEr am 18 September 2016, 09:41:55
pi@ospi /var/log $ ebusctl hex 33b5170508b5040100
done
Äh ja, mein Fehler. Bitte nochmal damit:
ebusctl hex 33b5170708b509030d0000
jetze :)
2016-09-18 09:47:48.583 [main notice] hex cmd: 3133b5170708b509030d0000
2016-09-18 09:47:49.235 [update notice] unknown MM cmd: 3310b51800
Zitat von: TiPpFeHlEr am 18 September 2016, 09:51:44
jetze :)
2016-09-18 09:47:48.583 [main notice] hex cmd: 3133b5170708b509030d0000
2016-09-18 09:47:49.235 [update notice] unknown MM cmd: 3310b51800
unglaublich, da hat sich der Hersteller ja wieder mal was total grandioses ausgedacht...
Dafür Unterstützung in ebusd einzubauen ist ne harte Nuss und echt widerlich. Ich weiß noch nicht, ob ich mir das antue.
Es wäre deutlich einfacher, wenn du dir noch ein zweites eBus Interface besorgst und den ebusd zwei Mal laufen lässt, für jeden Bus separat.
Erschwerend hinzu kommt, dass deine Lüftung deutlich jünger ist als meine und deshalb wieder eine eigene csv braucht, sprich es hilft Dir eigentlich nichts, was ich derzeit für die recovair 275 heraus finde.
Noch Fragen? :-/
hmmm.....
das bedeutet aber, ich kann die Lüftung dann nicht mehr mit dem 470er steuern?
kannst du wenigstens noch sagen was dein befehl und ggf. die Antwort bedeutet?
Wenn ich mir ein 2tes EBUS IF zulege bräuchte ich natürlich hilfe beim einrichten :)
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 10:15:35
das bedeutet aber, ich kann die Lüftung dann nicht mehr mit dem 470er steuern?
Doch, der VR32 kann ja ganz regulär drin bleiben, also von der Steuerung her ändert sich am 470 nichts.
Zitat von: TiPpFeHlEr am 18 September 2016, 10:15:35
kannst du wenigstens noch sagen was dein befehl und ggf. die Antwort bedeutet?
gesendet wurde: 3133b5170708b509030d0000, was beduetet:
31=QQ Quelladressse=ebusd
33=ZZ Zieladresse=VR32
b517=PBSB Kommando (Vaillant spezifisch 17=Nachricht an gekoppelten Bus senden)
07=NN Anzahl Datenbytes
08b509030d0000=7xDD
Hier steckt widerum das Kommando drin, das wir gerne auf dem gekoppelten Bus senden möchten:
08=ZZ Zieladresse 08
b509=PBSB Kommando (Vaillant spezifisch 09)
03=NN Anzahl Datenbytes
0d=DD Vaillant Subkommando Register lesen
0000=DD Registernummer 0
Die Antwort ist wieder ein bisschen fraglich: 3310b51800
33=QQ Quelladresse VR32
10=ZZ Zieladresse 10=470 (da hätte ich eigentlich die ebusd Masteradresse 31 erwartet anstelle des 470)
b518=PBSB Kommando (Vaillant spezifisch 18=Nachricht vom gekoppelten Bus erhalten)
00=NN Anzahl Datenbytes=0, also keine lesbare Antwort bekommen
Zitat von: TiPpFeHlEr am 18 September 2016, 10:15:35
Wenn ich mir ein 2tes EBUS IF zulege bräuchte ich natürlich hilfe beim einrichten :)
Das ist eine leichte Übung :-)
ok,
also den EBUS Koppler in den EBUS zwischen VR32 & Lüftungsebus?
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 10:36:39
also den EBUS Koppler in den EBUS zwischen VR32 & Lüftungsebus?
genau. Also eigentlich nicht "zwischen", sondern zusätzlich dran hängen, sprich die beiden Leitungen an den bestehenden Bus anklemmen und keinesfalls irgendwie "dazwischen".
JA
parallel an den originalen EBUS der lüftung mit dem VR32.
also nochmal Geld ausgeben :D
Zitat von: TiPpFeHlEr am 18 September 2016, 10:42:26
also nochmal Geld ausgeben :D
richtig, etwa 10-20 Euro z.B. für das hier: http://www.fhemwiki.de/wiki/EBUS#Platine (http://www.fhemwiki.de/wiki/EBUS#Platine)
siehe auch https://github.com/john30/ebusd/wiki/6.-Hardware (https://github.com/john30/ebusd/wiki/6.-Hardware)
naja,
ich setze lieber auf die fertige Lösung.
Die Platine kann ich nicht selber herstellen, und ich will mir nicht durch einen Fehler beim löten, mein EBUS zeschiessen ;)
Und ich brauche des in nem Hutschienen Gehäuse :)
mfg maik
aber ich kann ja mal zum testen den Koppler an die Lüftung hängen und sehen ob ich die Lüftung direkt lesen kann.
ps. mit welcher Master/Slave ADresse meldet sich deine RecoVair ? 03/08 ?
Zitat von: TiPpFeHlEr am 18 September 2016, 11:13:21
ps. mit welcher Master/Slave ADresse meldet sich deine RecoVair ? 03/08 ?
mit c0 bzw. 15
So John,
es gibt einen Erfolg ;)
ich habe mal auf raw umgestellt, und am 470er die Lüfterstufen verstellt.
nun konnte ich im log folgendes lesen.
2016-09-18 18:54:03.928 [bus notice] <10
2016-09-18 18:54:03.933 [bus notice] <38
2016-09-18 18:54:03.937 [bus notice] <b5
2016-09-18 18:54:03.941 [bus notice] <09
2016-09-18 18:54:03.946 [bus notice] <04
2016-09-18 18:54:03.951 [bus notice] <0e
2016-09-18 18:54:03.955 [bus notice] <8a
2016-09-18 18:54:03.959 [bus notice] <03
2016-09-18 18:54:03.965 [bus notice] <04
2016-09-18 18:54:03.969 [bus notice] <d5
2016-09-18 18:54:03.973 [bus notice] <00
2016-09-18 18:54:04.063 [bus notice] <00
2016-09-18 18:54:04.067 [bus notice] <00
2016-09-18 18:54:04.072 [bus notice] <00
2016-09-18 18:54:04.260 [bus notice] <10
2016-09-18 18:54:04.265 [bus notice] <38
2016-09-18 18:54:04.269 [bus notice] <b5
2016-09-18 18:54:04.275 [bus notice] <09
2016-09-18 18:54:04.279 [bus notice] <04
2016-09-18 18:54:04.283 [bus notice] <0e
2016-09-18 18:54:04.288 [bus notice] <8a
2016-09-18 18:54:04.292 [bus notice] <03
2016-09-18 18:54:04.298 [bus notice] <01
2016-09-18 18:54:04.302 [bus notice] <d0
2016-09-18 18:54:04.306 [bus notice] <00
2016-09-18 18:54:04.393 [bus notice] <00
2016-09-18 18:54:04.398 [bus notice] <00
2016-09-18 18:54:04.403 [bus notice] <00
2016-09-18 18:54:04.592 [bus notice] <10
2016-09-18 18:54:04.596 [bus notice] <38
2016-09-18 18:54:04.600 [bus notice] <b5
2016-09-18 18:54:04.605 [bus notice] <09
2016-09-18 18:54:04.610 [bus notice] <04
2016-09-18 18:54:04.615 [bus notice] <0e
2016-09-18 18:54:04.619 [bus notice] <8a
2016-09-18 18:54:04.623 [bus notice] <03
2016-09-18 18:54:04.627 [bus notice] <01
2016-09-18 18:54:04.633 [bus notice] <d0
2016-09-18 18:54:04.637 [bus notice] <00
2016-09-18 18:54:04.729 [bus notice] <00
2016-09-18 18:54:04.733 [bus notice] <00
2016-09-18 18:54:04.737 [bus notice] <00
2016-09-18 18:54:04.930 [bus notice] <10
2016-09-18 18:54:04.934 [bus notice] <38
2016-09-18 18:54:04.940 [bus notice] <b5
2016-09-18 18:54:04.944 [bus notice] <09
2016-09-18 18:54:04.948 [bus notice] <04
2016-09-18 18:54:04.952 [bus notice] <0e
2016-09-18 18:54:04.957 [bus notice] <8a
2016-09-18 18:54:04.962 [bus notice] <03
2016-09-18 18:54:04.966 [bus notice] <01
2016-09-18 18:54:04.970 [bus notice] <d0
2016-09-18 18:54:04.976 [bus notice] <00
2016-09-18 18:54:05.059 [bus notice] <00
2016-09-18 18:54:05.064 [bus notice] <00
2016-09-18 18:54:05.069 [bus notice] <00
also endlich eine Nachricht vom 470er an den VR32
dabei stellte ich fest das der 4te wert die Lüfterstufe ist 01 - 06 8)
also gleichmal diesen Befehl gesendet
pi@ospi /var/log $ ebusctl hex 38b509040e8a0306
ERR: read timeout
pi@ospi /var/log $ ebusctl hex 38b509040e8a0301
ERR: read timeout
pi@ospi /var/log $ ebusctl hex 38b509040e8a0306
ERR: read timeout
pi@ospi /var/log $ ebusctl hex 38b509040e8a0301
ERR: read timeout
pi@ospi /var/log $ ebusctl hex 38b509040e8a0303
ERR: read timeout
allerdings werden die Werte trotzdem übernommen und geändert!
Ich kann also die Lüfterstufen ändern!
Woraus ich schliesse, der VR32 gibt die Werte weiter aber bestätigt dies nicht.
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 19:09:15
ich habe mal auf raw umgestellt, und am 470er die Lüfterstufen verstellt.
nun konnte ich im log folgendes lesen.
also endlich eine Nachricht vom 470er an den VR32
pi@ospi /var/log $ ebusctl hex 38b509040e8a0303
ERR: read timeout
Nachdem der VR32 den Befehl erstmal verarbeiten muss, ist es einigermaßen logisch, dass die Antwort mehr als doppelt so spät als sonst zurück kommt. Deshalb müsstest Du den tolerierten Timeout dafür erhöhen, indem Du ebusd mit "--receivetimeout=100000" startest.
Allerdings ist es merkwürdig, dass jetzt der VR32 auf einmal normale Messages durchleitet, was vorher nicht passiert ist. Hast Du sonst noch was geändert?
so weiter gehts
Lüfterstufen Tag
38b509040e8a0301 = Stufe 1
38b509040e8a0302 = Stufe 2
38b509040e8a0303 = Stufe 3
38b509040e8a0304 = Stufe 4
38b509040e8a0305 = Stufe 5
38b509040e8a0306 = Stufe 6
Lüfterstufen Nacht
38b509040e8b0301 = Stufe 1
38b509040e8b0302 = Stufe 2
38b509040e8b0303 = Stufe 3
38b509040e8b0304 = Stufe 4
38b509040e8b0305 = Stufe 5
38b509040e8b0306 = Stufe 6
werde nun noch die Betriebsarten auslesen.
mfg maik
Zitat von: john30 am 18 September 2016, 20:12:13
Nachdem der VR32 den Befehl erstmal verarbeiten muss, ist es einigermaßen logisch, dass die Antwort mehr als doppelt so spät als sonst zurück kommt. Deshalb müsstest Du den tolerierten Timeout dafür erhöhen, indem Du ebusd mit "--receivetimeout=100000" startest.
Allerdings ist es merkwürdig, dass jetzt der VR32 auf einmal normale Messages durchleitet, was vorher nicht passiert ist. Hast Du sonst noch was geändert?
werde ich mal probieren!
naja wir bekamen ja immer ein err timeout! also kann es sein das er geantwortet hat, dieses aber ignoriert wurde weil die Zeit abgelaufen war?
das er die message durchleitet habe ich nur bemerkt als die Lüftung hoch und runter fuhr.
um diese Befehle rauszufinden, die vom 470 an die Lüftung gesendet werden musste ich erstmal auf "raw" umstellen, und die Nachrichten mitlesen und im log suchen! dann bemerkte ich das die Werte die ich an den VR32 gesendet habe, auch die Werte im 470 ändern (zeitverzögert).
allerdings konnte ich keine message vom VR32 an den 470 entdecken!?
mfg maik
ich konnte beim testen zudem noch folgende message abfangen
1038b51303048a03
da weiss ich aber noch nicht was das ist, Betriebsart ist es nicht.
mfg maik
so
habe nun mal den ebusd mit
"--receivetimeout=100000"
EBUSD_OPTS="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
gestartet,
wie lang ist 100000 in Sekunden? 100000 msec ?
es kommt immernoch nach ca 3 Sekunden ERR: read timeout
mfg maik
Zitat von: TiPpFeHlEr am 18 September 2016, 20:50:34
"--receivetimeout=100000"
wie lang ist 100000 in Sekunden? 100000 msec ?
das sind 100 millis
Zitat von: TiPpFeHlEr am 18 September 2016, 20:50:34
es kommt immernoch nach ca 3 Sekunden ERR: read timeout
Auf welche Anfrage denn?
Hallo!
Eigentlich sollte mein erstes Projekt mit FHEM anders aussehen, aber nach einem Umbau meiner Vaillant Heizung im Sommer (neuer Hydraulikplan) und den nun sinkenden Temperaturen muss ich mich in den Datenverkehr zwischen Therme und Regler einklinken...
Meine Anlage besteht aus einer Vaillant ecotec plus 196-3/5 und der Vaillant Auromatic 620.
Beide habe ich über ebus verbunden.
Die Heizungsregelung an sich läuft gut und ich möchte die auch dem Regler weiterhin überlassen. Allerdings hängt mein Warmwasserspeicher nicht mehr am Regler sondern wird gleich von der Therme bedient. Meinen Hydraulikplan gibt es nämlich im Regler nicht. Der Regler weiss das aber nicht und schreibt munter 0 Grad Sollwert in das Warmwasserregister der Therme, die dann nicht mehr Brauchwasser erwärmt.
Ist es möglich die direkte Verbindung zwischen Therme und Regler zu kappen, einen Raspi mit beiden über USB Adapter zu verbinden (quasi als Brücke), aus dem Regler den Sollwert sowie benötigte Steuerbefehle für die Thermensteuerung auszulesen und ausschlisslich diese dann an die Heizung weiterzureichen?
Quasi als Filter, sodass die Warmwassergeschichte nicht vom Regler überschrieben wird?
Ich wollte mich mit einer Visualisierung der Heizung eigentlich anders einarbeiten, aber vllt. könnt ihr mir hier erste Hilfestellung leisten? Wäre super!
Danke an euch im Voraus!
Zitat von: theotherhalf am 22 September 2016, 20:37:43
Ist es möglich die direkte Verbindung zwischen Therme und Regler zu kappen, einen Raspi mit beiden über USB Adapter zu verbinden (quasi als Brücke), aus dem Regler den Sollwert sowie benötigte Steuerbefehle für die Thermensteuerung auszulesen und ausschlisslich diese dann an die Heizung weiterzureichen?
Quasi als Filter, sodass die Warmwassergeschichte nicht vom Regler überschrieben wird?
Na da hast Du ja mal was echt spezielles vor :)
out-of-the-box geht das nicht so direkt, aber man könnte die beiden kreise tatsächlich trennen und mit zwei eBus Interfaces und zwei ebusd Instanzen bspw. per Shell Skrip so etwas realisieren.
VG John
Hm, eigentlich ist der EBUS multi-master-fähig. Man müsste nur dafür sorgen, dass der Adressat auf den "richtigen" Master hört.
LG
pah
Zitat von: R2D2_ am 25 September 2016, 13:24:37
Die Datei "08.bai.HW7401.csv" gibt es nicht mehr und die "08.bai.csv" ist wesentlich kleiner geworden, ebenso gibt es mehrere "bai's" ...
Wie bekomme ich mit der alten Version die Product-ID der Therme raus, damit ich mir die neue "bai" ansehen kann ?
Das steht im scan result drin, also "ebusctl scan", ne Minute warten, "ebusctl scan result". Dann bekommst Du bspw. sowas:
08;Vaillant;EHP00;0327;7201;21;07;45;0010002779;0000;000000;N8Der Produktcode steht in der 9. Spalte, also z.B. hier "0010002779" (dieses Beispiel ist allerdings kein BAI Produktcode!).
Diesen kannst Du dann einfach in der 08.bai.csv suchen gehen und in der Spalte hinter dem "!load" steht dann, welche Include Datei für dieses Produkt von ebusd geommen werden muss. Sollte das Produkt nicht dabei stehen, gibt es ein Fallback je nach HW Variante laut Scan.
VG John
Hi John,
so 2ter EBUS Cpoupler ist installiert und in der /etc/default/ebusd mit folgendem code gestartet
EBUSD_OPTS2="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"
in der ebusd2.log erschein nun folgendes
2016-09-30 11:33:54.471 [main notice] ebusd 2.1.28b50d2 started
2016-09-30 11:33:54.480 [main notice] found messages: 5 (0 conditional on 0 conditions, 0 poll, 0 update)
2016-09-30 11:33:54.489 [bus notice] signal acquired
2016-09-30 11:34:37.034 [bus notice] max. symbols per second: 138
2016-09-30 11:34:44.985 [bus notice] new master 10, master count 2
2016-09-30 11:34:44.985 [update notice] unknown BC cmd: 10feb516080045341130090516
2016-09-30 11:34:45.289 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:34:49.077 [bus error] send to 15: ERR: read timeout, retry
2016-09-30 11:34:49.621 [bus error] send to 15: ERR: read timeout, retry
2016-09-30 11:34:50.165 [bus error] send to 15: ERR: read timeout, retry
2016-09-30 11:34:50.708 [bus error] send to 15: ERR: read timeout
2016-09-30 11:34:50.709 [main error] scan config 15 message: ERR: read timeout
2016-09-30 11:34:56.633 [bus notice] new master 03, master count 3
2016-09-30 11:34:56.633 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:34:58.381 [main error] unable to load scan config 08: no file from /etc/ebusd/vaillant with prefix 08. matches ID "recov", SW0217, HW0203
2016-09-30 11:35:02.350 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:35:05.182 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:35:28.264 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:35:45.946 [update notice] unknown BC cmd: 10feb516080045351130090516
2016-09-30 11:35:46.164 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:35:55.059 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:35:57.118 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:36:05.393 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:36:22.261 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:36:46.162 [update notice] unknown BC cmd: 10feb516080045361130090516
2016-09-30 11:36:46.381 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:36:48.036 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:36:59.348 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:37:05.693 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:37:14.075 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:37:39.985 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:37:46.525 [update notice] unknown BC cmd: 10feb516080046371130090516
2016-09-30 11:37:47.002 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:37:56.171 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:38:05.902 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:38:06.269 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:38:31.965 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:38:44.632 [update notice] unknown BC cmd: 10feb516080044381130090516
2016-09-30 11:38:44.849 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:38:54.451 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:38:57.864 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:39:04.124 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:39:23.905 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030100010006000400
2016-09-30 11:39:40.182 [update notice] unknown MS cmd: 1008b509040e8a0303 / 00
2016-09-30 11:39:44.396 [update notice] unknown MS cmd: 1008b5090124 / 09003231313434343030
2016-09-30 11:39:53.682 [update notice] unknown BC cmd: 10feb516080050391130090516
2016-09-30 11:39:53.941 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:39:59.554 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:40:02.883 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:40:05.714 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:40:30.080 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:40:47.979 [update notice] unknown BC cmd: 10feb516080044401130090516
2016-09-30 11:40:58.133 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:40:59.701 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:41:28.486 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:41:47.193 [update notice] unknown BC cmd: 10feb516080044411130090516
2016-09-30 11:42:00.975 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:42:01.943 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:42:06.617 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:42:27.982 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:42:47.077 [update notice] unknown BC cmd: 10feb516080045421130090516
2016-09-30 11:42:47.424 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:42:54.175 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:42:56.440 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:43:05.144 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:43:20.169 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:43:45.076 [update notice] update scan.08 ident QQ=10: Vaillant;recoV;0217;0203
2016-09-30 11:43:45.317 [update notice] unknown BC cmd: 10feb516080045431130090516
2016-09-30 11:43:45.533 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:43:46.116 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
2016-09-30 11:43:55.545 [update notice] unknown BC cmd: 10feb5050362441d
2016-09-30 11:43:57.168 [update notice] unknown MS cmd: 1008b522050002002802 / 0100
2016-09-30 11:44:05.443 [update notice] unknown BC cmd: 10feb51603013012
2016-09-30 11:44:12.027 [update notice] unknown MS cmd: 1008b51303048a03 / 0a8a030300010006000400
allerdings gibt es nun ein problem mit dem anderen coupler
ebusd.log
2016-09-30 11:37:27.414 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:37:28.641 [bus notice] poll scan.08 id:
2016-09-30 11:37:29.178 [main notice] hex cmd: 3110b509030d0000
2016-09-30 11:37:33.440 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:37:34.808 [bus notice] poll scan.08 id:
2016-09-30 11:37:35.435 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2016-09-30 11:37:37.578 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:37:40.077 [bus error] send to 15: ERR: read timeout, retry
2016-09-30 11:37:41.778 [bus notice] poll scan.08 id:
2016-09-30 11:37:43.484 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:37:46.447 [update notice] update broadcast vdatetime QQ=10: 11:37: 46;30.09.2016
2016-09-30 11:37:46.859 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:37:47.682 [bus notice] poll scan.08 id:
2016-09-30 11:37:47.931 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:37:52.646 [bus notice] poll scan.08 id:
2016-09-30 11:37:53.666 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:37:55.577 [update notice] update bai DateTime QQ=10: valid;11:37:5 7;30.09.2016;18.188
2016-09-30 11:37:55.844 [update notice] update bai Status02 QQ=10: auto;60;55.0; 80;60.0
2016-09-30 11:37:56.184 [update notice] unknown MS cmd: 1038b522050002002802 / 0 100
2016-09-30 11:37:57.563 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:37:58.696 [bus notice] poll scan.08 id:
2016-09-30 11:38:03.623 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:04.678 [bus notice] poll scan.08 id:
2016-09-30 11:38:05.595 [update error] unable to parse bai Status from 1008b5110 100 / 08cd01130008000003: ERR: invalid position
2016-09-30 11:38:05.823 [update notice] update broadcast outsidetemp QQ=10: 18.1 88
2016-09-30 11:38:07.614 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:38:10.676 [bus notice] poll scan.08 id:
2016-09-30 11:38:13.632 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:15.616 [update notice] update bai Status02 QQ=10: auto;60;55.0; 80;60.0
2016-09-30 11:38:16.671 [bus notice] poll scan.08 id:
2016-09-30 11:38:22.643 [bus notice] poll scan.08 id:
2016-09-30 11:38:23.708 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:25.799 [update notice] update bai DateTime QQ=10: valid;11:38:2 7;30.09.2016;18.188
2016-09-30 11:38:27.730 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:38:28.688 [bus notice] poll scan.08 id:
2016-09-30 11:38:33.844 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:34.186 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2016-09-30 11:38:36.148 [bus notice] poll scan.08 id:
2016-09-30 11:38:37.752 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:38:41.720 [bus notice] poll scan.08 id:
2016-09-30 11:38:41.877 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:44.200 [bus error] invalid self-addressed message from 00
2016-09-30 11:38:44.741 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:38:44.994 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-09-30 11:38:47.679 [bus notice] poll scan.08 id:
2016-09-30 11:38:51.846 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:38:53.667 [bus notice] poll scan.08 id:
2016-09-30 11:38:53.826 [update notice] update bai DateTime QQ=10: valid;11:38:5 5;30.09.2016;18.188
2016-09-30 11:38:54.098 [update notice] update bai Status02 QQ=10: auto;60;55.0; 80;60.0
2016-09-30 11:38:58.211 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:39:01.690 [bus notice] poll scan.08 id:
2016-09-30 11:39:01.890 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;43.0;off
2016-09-30 11:39:03.843 [update error] unable to parse bai Status from 1008b5110 100 / 08cd01130008000003: ERR: invalid position
2016-09-30 11:39:04.065 [update notice] update broadcast outsidetemp QQ=10: 18.1 88
2016-09-30 11:39:04.295 [bus error] invalid self-addressed message from 00
2016-09-30 11:39:07.649 [bus notice] poll scan.08 id:
2016-09-30 11:39:07.894 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:39:08.306 [bus notice] scan 02 timed out (227 slaves left)
2016-09-30 11:39:08.858 [bus notice] scan 04 timed out (226 slaves left)
2016-09-30 11:39:09.412 [bus notice] scan 05 timed out (225 slaves left)
2016-09-30 11:39:10.116 [bus notice] scan 06 timed out (224 slaves left)
2016-09-30 11:39:12.000 [bus notice] max. symbols per second: 137
2016-09-30 11:39:12.090 [bus notice] scan 08 timed out (223 slaves left)
2016-09-30 11:39:12.090 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2016-09-30 11:39:12.873 [bus notice] scan 09 timed out (222 slaves left)
2016-09-30 11:39:13.586 [bus notice] scan 0a timed out (221 slaves left)
2016-09-30 11:39:14.403 [bus notice] scan 0b timed out (220 slaves left)
2016-09-30 11:39:15.092 [bus notice] scan 0c timed out (219 slaves left)
2016-09-30 11:39:15.796 [bus notice] scan 0d timed out (218 slaves left)
2016-09-30 11:39:16.507 [bus notice] scan 0e timed out (217 slaves left)
2016-09-30 11:39:17.194 [bus notice] scan 12 timed out (216 slaves left)
2016-09-30 11:39:17.886 [bus notice] scan 14 timed out (215 slaves left)
2016-09-30 11:39:20.573 [bus notice] scan 15 completed (214 slaves left)
2016-09-30 11:39:20.574 [bus notice] scan 15: ;Vaillant;47000;0420;1403;21;14;32 ;0020171280;0082;031167;N9
2016-09-30 11:39:20.934 [bus notice] scan 16 timed out (213 slaves left)
2016-09-30 11:39:21.632 [bus notice] scan 18 timed out (212 slaves left)
2016-09-30 11:39:22.466 [bus notice] scan 19 timed out (211 slaves left)
2016-09-30 11:39:23.157 [bus notice] scan 1a timed out (210 slaves left)
2016-09-30 11:39:24.109 [bus notice] scan 1b timed out (209 slaves left)
2016-09-30 11:39:24.801 [bus notice] scan 1c timed out (208 slaves left)
2016-09-30 11:39:26.074 [bus notice] scan 1d timed out (207 slaves left)
2016-09-30 11:39:26.676 [update notice] update bai DateTime QQ=10: valid;11:39:2 7;30.09.2016;18.188
2016-09-30 11:39:26.913 [bus notice] scan 1e timed out (206 slaves left)
2016-09-30 11:39:27.610 [bus notice] scan 20 timed out (205 slaves left)
2016-09-30 11:39:28.919 [bus notice] scan 21 timed out (204 slaves left)
2016-09-30 11:39:29.762 [bus notice] scan 22 timed out (203 slaves left)
2016-09-30 11:39:30.478 [bus notice] scan 23 timed out (202 slaves left)
2016-09-30 11:39:31.186 [bus notice] scan 24 timed out (201 slaves left)
2016-09-30 11:39:31.871 [bus notice] scan 25 timed out (200 slaves left)
2016-09-30 11:39:33.911 [bus notice] scan 26 completed (199 slaves left)
2016-09-30 11:39:33.912 [bus notice] scan 26: ;Vaillant;47000;0420;1403;21;14;32 ;0020171280;0082;031167;N9
2016-09-30 11:39:34.003 [bus notice] max. symbols per second: 143
2016-09-30 11:39:34.139 [bus notice] scan 27 timed out (198 slaves left)
2016-09-30 11:39:34.738 [bus notice] scan 28 timed out (197 slaves left)
2016-09-30 11:39:35.287 [bus notice] scan 29 timed out (196 slaves left)
2016-09-30 11:39:35.842 [bus notice] scan 2a timed out (195 slaves left)
2016-09-30 11:39:36.388 [bus notice] scan 2b timed out (194 slaves left)
2016-09-30 11:39:36.932 [bus notice] scan 2c timed out (193 slaves left)
2016-09-30 11:39:38.212 [bus notice] scan 2d timed out (192 slaves left)
2016-09-30 11:39:39.500 [bus notice] scan 2e timed out (191 slaves left)
2016-09-30 11:39:40.436 [bus notice] scan 2f timed out (190 slaves left)
2016-09-30 11:39:41.206 [bus notice] scan 32 timed out (189 slaves left)
2016-09-30 11:39:41.918 [bus notice] scan 34 timed out (188 slaves left)
2016-09-30 11:39:42.466 [main error] unable to load scan config 26: no file from /etc/ebusd/vaillant with prefix 26. matches ID "47000", SW0420, HW1403
2016-09-30 11:39:42.647 [bus notice] scan 35 timed out (187 slaves left)
2016-09-30 11:39:43.337 [bus notice] scan 36 timed out (186 slaves left)
2016-09-30 11:39:44.378 [bus notice] scan 38 timed out (185 slaves left)
2016-09-30 11:39:44.378 [bus notice] scan 38: ;Vaillant;V32 ;0117;9802
2016-09-30 11:39:45.232 [bus notice] scan 39 timed out (184 slaves left)
2016-09-30 11:39:45.938 [bus notice] scan 3a timed out (183 slaves left)
2016-09-30 11:39:46.626 [bus notice] scan 3b timed out (182 slaves left)
2016-09-30 11:39:47.324 [bus notice] scan 3c timed out (181 slaves left)
2016-09-30 11:39:48.021 [bus notice] scan 3d timed out (180 slaves left)
2016-09-30 11:39:48.713 [bus notice] scan 3e timed out (179 slaves left)
2016-09-30 11:39:49.398 [bus notice] scan 40 timed out (178 slaves left)
2016-09-30 11:39:50.140 [bus notice] scan 41 timed out (177 slaves left)
2016-09-30 11:39:50.848 [bus notice] scan 42 timed out (176 slaves left)
2016-09-30 11:39:52.146 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:39:52.521 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;42.0;off
2016-09-30 11:39:53.074 [bus notice] scan 43 timed out (175 slaves left)
2016-09-30 11:39:53.860 [update notice] unknown BC cmd: 10feb5160304a011
2016-09-30 11:39:54.658 [bus notice] scan 44 timed out (174 slaves left)
2016-09-30 11:39:55.356 [bus notice] scan 45 timed out (173 slaves left)
2016-09-30 11:39:56.620 [bus notice] scan 46 timed out (172 slaves left)
2016-09-30 11:39:57.225 [update notice] update bai DateTime QQ=10: valid;11:39:5 8;30.09.2016;18.188
2016-09-30 11:39:57.465 [bus notice] scan 47 timed out (171 slaves left)
2016-09-30 11:39:58.221 [bus notice] scan 48 timed out (170 slaves left)
2016-09-30 11:39:58.901 [bus notice] scan 49 timed out (169 slaves left)
2016-09-30 11:39:59.804 [bus notice] scan 4a timed out (168 slaves left)
2016-09-30 11:40:00.569 [bus notice] scan 4b timed out (167 slaves left)
2016-09-30 11:40:01.272 [bus notice] scan 4c timed out (166 slaves left)
2016-09-30 11:40:03.716 [bus notice] scan 4d timed out (165 slaves left)
2016-09-30 11:40:04.307 [update error] unable to parse bai Status from 1008b5110 100 / 08cb01130008000003: ERR: invalid position
2016-09-30 11:40:04.543 [bus notice] scan 4e timed out (164 slaves left)
2016-09-30 11:40:05.096 [bus notice] scan 4f timed out (163 slaves left)
2016-09-30 11:40:05.631 [update notice] update broadcast outsidetemp QQ=10: 18.1 88
2016-09-30 11:40:05.867 [bus notice] scan 50 timed out (162 slaves left)
2016-09-30 11:40:06.414 [bus notice] scan 51 timed out (161 slaves left)
2016-09-30 11:40:06.962 [bus notice] scan 52 timed out (160 slaves left)
2016-09-30 11:40:07.504 [bus notice] scan 53 timed out (159 slaves left)
2016-09-30 11:40:08.286 [bus notice] scan 54 timed out (158 slaves left)
2016-09-30 11:40:08.886 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:40:09.121 [bus notice] scan 55 timed out (157 slaves left)
2016-09-30 11:40:09.834 [bus notice] scan 56 timed out (156 slaves left)
2016-09-30 11:40:10.543 [bus notice] scan 57 timed out (155 slaves left)
2016-09-30 11:40:11.261 [bus notice] scan 58 timed out (154 slaves left)
2016-09-30 11:40:11.955 [bus notice] scan 59 timed out (153 slaves left)
2016-09-30 11:40:12.807 [bus notice] scan 5a timed out (152 slaves left)
2016-09-30 11:40:13.521 [bus notice] scan 5b timed out (151 slaves left)
2016-09-30 11:40:13.980 [bus error] send to 15: ERR: read timeout, retry
2016-09-30 11:40:14.626 [bus notice] scan 5c timed out (150 slaves left)
2016-09-30 11:40:15.203 [update notice] update bai Status02 QQ=10: auto;60;55.0; 80;60.0
2016-09-30 11:40:15.440 [bus notice] scan 5d timed out (149 slaves left)
2016-09-30 11:40:16.140 [bus notice] scan 5e timed out (148 slaves left)
2016-09-30 11:40:16.833 [bus notice] scan 5f timed out (147 slaves left)
2016-09-30 11:40:17.541 [bus notice] scan 60 timed out (146 slaves left)
2016-09-30 11:40:18.376 [bus notice] scan 61 timed out (145 slaves left)
2016-09-30 11:40:19.068 [bus notice] scan 62 timed out (144 slaves left)
2016-09-30 11:40:19.773 [bus notice] scan 63 timed out (143 slaves left)
2016-09-30 11:40:20.479 [bus notice] scan 64 timed out (142 slaves left)
2016-09-30 11:40:21.164 [bus notice] scan 65 timed out (141 slaves left)
2016-09-30 11:40:21.852 [bus notice] scan 66 timed out (140 slaves left)
2016-09-30 11:40:22.628 [bus notice] scan 67 timed out (139 slaves left)
2016-09-30 11:40:23.224 [update notice] update bai Status01 QQ=10: 28.0;28.0;18. 188;-;42.0;off
2016-09-30 11:40:23.462 [bus notice] scan 68 timed out (138 slaves left)
2016-09-30 11:40:24.241 [bus notice] scan 69 timed out (137 slaves left)
2016-09-30 11:40:24.943 [bus notice] scan 6a timed out (136 slaves left)
2016-09-30 11:40:25.665 [bus notice] scan 6b timed out (135 slaves left)
2016-09-30 11:40:26.367 [bus notice] scan 6c timed out (134 slaves left)
2016-09-30 11:40:27.082 [bus notice] scan 6d timed out (133 slaves left)
2016-09-30 11:40:27.786 [bus notice] scan 6e timed out (132 slaves left)
2016-09-30 11:40:28.560 [bus notice] scan 6f timed out (131 slaves left)
2016-09-30 11:40:29.172 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:40:29.410 [bus notice] scan 72 timed out (130 slaves left)
2016-09-30 11:40:30.284 [bus notice] scan 74 timed out (129 slaves left)
2016-09-30 11:40:30.993 [bus notice] scan 75 timed out (128 slaves left)
2016-09-30 11:40:31.683 [bus notice] scan 76 timed out (127 slaves left)
2016-09-30 11:40:32.953 [bus notice] scan 78 timed out (126 slaves left)
2016-09-30 11:40:34.218 [bus notice] scan 79 timed out (125 slaves left)
2016-09-30 11:40:35.488 [bus notice] scan 7a timed out (124 slaves left)
2016-09-30 11:40:35.896 [bus error] send to 08: ERR: arbitration lost, retry
2016-09-30 11:40:36.061 [update notice] unknown MS cmd: 1008b5100305ff01 / 00
2016-09-30 11:40:36.299 [bus notice] scan 7b timed out (123 slaves left)
2016-09-30 11:40:36.999 [bus notice] scan 7c timed out (122 slaves left)
2016-09-30 11:40:37.696 [bus notice] scan 7d timed out (121 slaves left)
2016-09-30 11:40:38.470 [bus notice] scan 7e timed out (120 slaves left)
2016-09-30 11:40:39.769 [bus notice] scan 80 timed out (119 slaves left)
2016-09-30 11:40:40.371 [update notice] update bai Mode QQ=10: Standby
2016-09-30 11:40:40.607 [bus notice] scan 81 timed out (118 slaves left)
2016-09-30 11:40:41.306 [bus notice] scan 82 timed out (117 slaves left)
pi@ospi ~ $
mfg maik
so,
ebusd & ebusd2 laufen, und lassen sich separat ansprechen! ;D
habe also gleichmal ein paar b509 versucht.
leider ohne Erfolg.
es kommt immer ein "00" von der RecoVair zurück.
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d6100
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d6000
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d2000
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d1000
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d4000
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0000
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0001
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0002
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0003
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0016
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030db400
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d5900
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0704
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0100
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0200
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0300
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d0400
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d2500
00
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d1000
00
das setzen der Lüfterstufe ist Analog zu dem Befehl über dem VR32
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509040e8a0306
00
auch hier wird ein "00" zurückgegeben
das Auslesen der Lüfterstufe klappt dann auch mit
pi@ospi /etc/init.d $ ebusctl -p 8889 hex 08b509030d8a03
0106
;)
nun weiss ich auch warum ich den VR32 einsetzen musste , die RecoVair hat die gleiche EBUS Adresse wie meine Therme 08/03.
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 24
masters: 3
messages: 7
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203"
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8
@John
hattest du schon Erfolg mit dem auslesen deiner RecoVair??
hattest du nicht ein script mit dem ich alle möglichen Speicherbereiche automatisch ansprechen kann, und dann schauen bei welchem etwas zurück kam?
Es ist doch sehr mühselig alle von Hand durchzutesten ::)
Bis jetzt ohne Erfolg. :'(
hi R2D2
warum sind deine beiden Befehle nicht gleich?
ebusctl r CollTemp
ebusctl read StorageTemp
r & read !
hast du mal ein
ebusctl read CollTemp
versucht??
ebenso kannst du mal direkt versuchen den Wert zu lesen.
ebusctl r -h 08b509030d7800
oder mit HEX enabled
ebusctl hex 08b509030d7800
mfg maik
kannst du mal ein
ebusctl info
geben?
mfg maik
OK ;)
du hast also eine VC126 / 3-5 ???
und einen CalorMatic VRC 470
weil meine ist
pi@ospi ~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 95
masters: 4
messages: 448
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8
address 38: slave #13, scanned "MF=Vaillant;ID=V32 ;SW=0117;HW=9802"
also muss er die bai.308523.inc laden.
warum willst du dort die CollTemp auslesen??
mfg maik
OK :-\
deine Hard und Software-Versionen sind also die gleichen wie meine !? cool
starte mal den ebusd mit hex. also
in der Datei /etc/default/ebusd
fügst du "--enablehex" hinzu
EBUSD_OPTS="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /va$
dann den ebusd stoppen und wieder starten
sudo service ebusd stop
sudo service ebusd start
dann nochmal
ebusctl hex 08b509030d7800
mfg maik
mfg maik
genau
das ist es laut deine alten BAI.
du must also ggf noch andere, noch nicht vorhande, in die bai.308523.inc aus deiner alten bai.0010003886.inc. hinzufügen.
warum aber nun die bai.30...... geladen wird weiss ich auch nicht.
mfg maik
AHA
deine ProdID 0010002779 existiert nicht, also geht er auf fallback der HW 7401, also soll er
[HW=7401]!load,bai.308523.inc,,,
laden.
du könntest auch die 08.bai.csv anpassen. und bei
[PROD='0010003882';'0010003883';'0010003886';'0010003887';'0010009351';'0010009352';'167']!load,bai.0010003886.inc,,,
deine ProdID 0010002779 hinzufügen. dann müsste er wieder die bai.0010003886.inc laden.
mfg maik
funzt ... 8)
hi,
schau mal bitte in deine /etc/default/ebusd ob dort etwas in dieser Form als Parameter mit drinn steht?
--pollinterval=SEC
Poll for data every SEC seconds (0=disable) [5]
mfg maik
OK,
keine Ahnung was der error bedeutet.
War nur ein versuch, war das einzige was ich zu "poll" gefunden habe.
mfg maik
mal sehen was John dazu sagt :D
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
# In order to run multiple ebusd instances, simply define several EBUSD_OPTS
# with a unique suffix for each.
# Recommended is using a number as suffix for all EBUSD_OPTS settings.
# That number can then be used as additional "instance" parameter to the init.d
# script in order to start/stop an individual ebusd instance instead of all
# instances.
# Example (uncomment the EBUSD_OPTS above):
EBUSD_OPTS="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
EBUSD_OPTS2="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"
ich verwende 2 ebus koppler darum auch 2 instanzen!
ebenso wähle ich die USB Geräte "by-id" somit könnte ich den USB-Port wechseln.
@R2D2
naja damit wird der poll deaktiviert, ob das Gut ist weiss ich nicht. ----> warten wir mal auf John
@John
bin mit meine RecoVair etwas weiter
hatte Erfolg beim setzen des Modus Wärmerückgewinnung 8)
pi@ospi ~ $ ebusctl -p 8889 hex 08b509040e8c0300
00
pi@ospi ~ $ ebusctl -p 8889 hex 08b509030d8c03
0100
#########################################################################
Wärmerückgewinnung MOdus
#########################################################################
00 = Auto; 01 = Aktivieren; 02 = Aus
setzen = ebusctl -p 8888 hex 38b509040e8c03[00-02]
ebusctl -p 8889 hex 08b509040e8c03[00-02]
lesen = ebusctl -p 8888 hex 38b509030d8c03
ebusctl -p 8889 hex 08b509030d8c03
#########################################################################
mfg maik
hi R2D2,
habe ich schon gelesen ;)
leider besitzt meine keinen DurchflussSensor > schon ausgelesen > 020000
also immer 0000
leider.
weist du zufällig wie der 4 stellige hex Wert umgerechnet wird?
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030dc500
04afde307e
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030dc600
047fef5700
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030df500
04feffffff
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030df600
04294d5e01
wie man sieht ist mein PrEnergySumHc1,PrEnergySumCH1_DK fast am Ende angelangt 8) 04feffffff
hi R2D2,
hmmm....
interessant ist das sich der Wert nicht ändert (seit gestern) obwohl die Heizung lief.
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030df500
04feffffff
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030df600
04294d5e01
bei Warmwasser allerdings hat sich der Wert geändert
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030dc500
04bea8357e
pi@ospi ~ $ ebusctl -p 8888 hex 08b509030dc600
0437f25700
mfg maik
Zitat von: TiPpFeHlEr am 30 September 2016, 16:37:49
ebusd & ebusd2 laufen, und lassen sich separat ansprechen! ;D
Das klingt gut!
Du könntest jetzt noch den zweiten ebusd auf eine freie Masteradresse setzen, dann würden sich die zwei nicht mehr gegenseitig unterbrechen (Arbitrierung). Dazu in der /etc/default/ebusd in einer der beiden Zeilen ein "-a ff" eintragen. Oder hast Du noch ein vrnetdialog im System?
Zitat von: TiPpFeHlEr am 30 September 2016, 16:37:49
nun weiss ich auch warum ich den VR32 einsetzen musste , die RecoVair hat die gleiche EBUS Adresse wie meine Therme 08/03.
Korrekt. Genau das ist ja der Sinn und Zweck eines VR32: entkoppeln :-)
Zitat von: TiPpFeHlEr am 30 September 2016, 16:37:49
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 24
masters: 3
messages: 7
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203"
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8
Ah, der Slave 15 zum master #2 ist noch nicht idenfiziert. Wie sieht der denn aus?
Zitat von: TiPpFeHlEr am 30 September 2016, 16:37:49
hattest du schon Erfolg mit dem auslesen deiner RecoVair??
Bin noch nicht sehr weit gekommen. Bis jetzt nur den Ertrag und ein paar Temperaturen identifiziert. work in progress :-)
Zitat von: TiPpFeHlEr am 30 September 2016, 16:37:49
hattest du nicht ein script mit dem ich alle möglichen Speicherbereiche automatisch ansprechen kann, und dann schauen bei welchem etwas zurück kam?
Es ist doch sehr mühselig alle von Hand durchzutesten ::)
Ja das ist es. Anbei das Skript. Aufruf z.B. mit "./allregisters.sh -p 8889 -a 08", womit die erste 512 Vaillant Register auf ebusd mit Port 8889 und dem Slave mit Adresse 0x08 ausgelesen werden. Ergebnis z.B. wie folgt:
0 = 038c0100
1 = 03e40000
2 = 03de0000
3 = 03600100
4 = 03b30100
5 = 0200c8
6 = 0200c8
...
Das sind jetzt z.B. die Temperaturfühler meiner recovair. Ich habe übrigens ein deutlich älteres Modell, weshalb die beiden sich vermutlich in der CSV stark unterscheiden werden...
VG John
Zitat von: R2D2_ am 30 September 2016, 20:55:46
pi@jessie:~ $ ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;11;39;0010009352;3100;006295;N3
15;Vaillant;47000;0126;6002;21;11;27;0020108127;0082;013965;N9
Dein scan result passt nicht zu dem, was ebusd an CSV gelesen hat.
Kannst Du mir mal bitte Deine ebusd.log sowie alle Dateien aus /etc/ebusd per PN zukommen lassen?
Das mit dem Polling ist auch merkwürdig und so nicht gedacht.
VG John
Zitat von: TiPpFeHlEr am 01 Oktober 2016, 11:19:19
deine Hard und Software-Versionen sind also die gleichen wie meine !? cool
das heißt bei den BAIs leider überhaupt nichts. Hier gibt es einen zweiten Level von Softwareversion, der eigentlich relevant ist. Nachdem vrdialog das über den Produktcode zuordnet, macht das ebusd genauso.
VG John
Zitat von: R2D2_ am 02 Oktober 2016, 13:04:14
@john: benötige noch Deine email-Adresse per PN ... oder falls jemand diese hat, mir bitte per PN mitteilen ...
Hast Du inzwischen.
Zitat von: R2D2_ am 02 Oktober 2016, 13:04:14
Mir ist aufgefallen, dass der Duchfluss-Sensor / die Abfrage desselben nicht immer den aktuellen Wert zurückliefert, sondern "020000" = 0
ebusctl r -h 08b509030dfb00
oder
ebusctl r PrimaryCircuitFlowRate
Nach längerer Laufzeit der Pumpe ist dann eine Abfrage möglich. Kann einer was dazu sagen ?
Sind das zufällig etwa 5 Minuten?
Dann solltest Du das caching im ebusd beim read ausschalten mit "read -f ...".
Hintergrund ist, dass ebusd alles, was aus dem cache beantwortet werden kann, per default mit einem Maximalalter von 5 Minuten daraus zieht, um den Bus nicht unnötig zu belasten.
Zitat von: R2D2_ am 30 September 2016, 20:55:46
pi@jessie:~ $ ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;11;39;0010009352;3100;006295;N3
15;Vaillant;47000;0126;6002;21;11;27;0020108127;0082;013965;N9
ZitatDein scan result passt nicht zu dem, was ebusd an CSV gelesen hat.
Kannst Du mir mal bitte Deine ebusd.log sowie alle Dateien aus /etc/ebusd per PN zukommen lassen?
Das mit dem Polling ist auch merkwürdig und so nicht gedacht.
So, Rätsel gelöst: das war ein kleiner feiner Bug, den ich vor 14 Tagen eingebaut habe. Mit aktuellem git code sollte es jetzt wieder regulär klappen und Deine Änderung an der 08.bai.csv damit auch wieder hinfällig sein. Allerdings musst Du das Polling aktiv lassen, sonst kann ebusd den Produktcode nicht rausfinden...
Zitat von: R2D2_ am 02 Oktober 2016, 14:16:49
Warum kann der nachfolgende Wert nicht mehr geschrieben werden ?
r,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,,,"operation mode of the domestic hot water circuit set implicitly (0 = off, 1 = on, 2 = auto, 3 = auto sunday, 4 = party, 6 = one time tank loading, 7 = holiday)"
Das darfst Du mich nicht fragen, so stehts halt in der MDB drin, also ein nur-Lesen Wert. Du kannst das zum Probieren auch auf "r;w" erweitern, aber ich würde mal schätzen, dass das nicht die richtige Stellschraube ist. Das suggeriert zumindest auch der Kommentar "...set implicitly". Ich schätze, die Enstellung müsstest Du woanders tätigen, also entweder direkt an der BAI oder in einem anderen Register der 470. Vermutlich sogar über die Timer (woraus dann auto/auto sunday kommen könnte) bzw. über die quick commands party/load/save (für party/one time tank loading) und 470/HwcCircuitActive (für off/on).
hi John,
ZitatDu könntest jetzt noch den zweiten ebusd auf eine freie Masteradresse setzen, dann würden sich die zwei nicht mehr gegenseitig unterbrechen (Arbitrierung). Dazu in der /etc/default/ebusd in einer der beiden Zeilen ein "-a ff" eintragen. Oder hast Du noch ein vrnetdialog im System?
hab ich gemacht ;)
ZitatAh, der Slave 15 zum master #2 ist noch nicht idenfiziert. Wie sieht der denn aus?
es gibt an diesem ebus keinen!
habe mal zum Test einen weiteren VRC 470 an diesen ebus angeschlossen.
######################################################
################### mit VRC 470 ######################
######################################################
pi@ospi ~ $ ebusctl -p 8889 scan full
done
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 39
masters: 4
messages: 257
address 03: master #11
address 04: slave #25
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002", loaded "vaillant/15.470.csv"
address 33: master #13
address 38: slave #13, scanned "MF=Vaillant;ID=V32 ;SW=0117;HW=9802"
address ff: master #25, ebusd
pi@ospi ~ $ ebusctl -p 8889 scan result
08;Vaillant;recoV;0217;0203;21;14;44;0010016040;0006;005637;N0
15;Vaillant;47000;0128;6002;21;11;39;0020108127;0082;021111;N1
38;Vaillant;V32 ;0117;9802;21;14;25;0020139895;0082;007745;N1
########################################################
#################### ohne VRC 470 ######################
########################################################
pi@ospi ~ $ ebusctl -p 8889 scan full
done
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 23
masters: 4
messages: 8
address 03: master #11
address 04: slave #25
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203"
address 10: master #2
address 33: master #13
address 38: slave #13, scanned "MF=Vaillant;ID=V32 ;SW=0117;HW=9802"
address ff: master #25, ebusd
pi@ospi ~ $ ebusctl -p 8889 scan result
08;Vaillant;recoV;0217;0203;21;14;44;0010016040;0006;005637;N0
38;Vaillant;V32 ;0117;9802;21;14;25;0020139895;0082;007745;N1
########################################################ZitatBin noch nicht sehr weit gekommen. Bis jetzt nur den Ertrag und ein paar Temperaturen identifiziert. work in progress :-)
;D
ZitatJa das ist es. Anbei das Skript. Aufruf z.B. mit "./allregisters.sh -p 8889 -a 08", womit die erste 512 Vaillant Register auf ebusd mit Port 8889 und dem Slave mit Adresse 0x08 ausgelesen werden. Ergebnis z.B. wie folgt:
DANKE ;)
werde es gleich mal durchlaufen lassen!!!!
FEHLER
pi@ospi ~ $ sudo sh ebusregister.sh
ebusregister.sh: 14: ebusregister.sh: Syntax error: Bad for loop variable
mfg maik
so,
script musste ich ändern
#!/bin/sh
port=8889
if [ "x$1" = "x-p" ]; then
shift
port=$1
shift
fi
addr=08
if [ "x$1" = "x-a" ]; then
shift
addr=$1
shift
fi
for i in $(seq 0 1024)
do
h=`printf "%4.4X" $i`
ret=`echo "hex ${addr}b509030d${h##??}${h%%??}"|nc localhost $port|head -n 1`
echo $i "=" $ret
done
damit gehts!
Ergebniss bis jetzt
901 = 023504
902 = 020080
903 = 020080
904 = 020080
905 = 02b004
906 = 0101
907 = 0101
908 = 0100
sonst alles 00 (0-1024)
@John
wieviele Register gibt es eigentlich?? lasse grade mal von 0-9999 durchlaufen, :o
da kommt doch ne ganze menge zurück, ob die Daten dann auch brauchbar sind.... mal sehen
wenns fertig ist, bräuchte man nur noch nan script das alle register abfragt die nicht mit "00" beantwortet wurden. Also die, die Daten lieferten. damit das suchen nach Änderungen wesentlich schneller geht.
mfg maik
Zitat von: TiPpFeHlEr am 02 Oktober 2016, 18:20:22
wieviele Register gibt es eigentlich?? lasse grade mal von 0-9999 durchlaufen, :o
ich würde sagen, primäre Register liegen im Bereich 0x0000-0x07ff, weil bei vielen Geräten 0x08xx/0x10xx/0x18xx etc. die gleichen Infos wie im primären Register liegen aber für nen anderen Heizkreis oder eine andere Periode. Mehr als 0x78xx hab ich bisher nirgends gesehen, also hat sich der Hersteller vermutlich das oberste Bit für die Zukunft reserviert.
Zitat von: TiPpFeHlEr am 02 Oktober 2016, 18:20:22
wenns fertig ist, bräuchte man nur noch nan script das alle register abfragt die nicht mit "00" beantwortet wurden. Also die, die Daten lieferten. damit das suchen nach Änderungen wesentlich schneller geht.
sowas lässt sich ganz banal mit grep lösen, z.B.
./allregister.sh|egrep -v "ERR: read timeout|= 00$"
Zitat von: john30 am 03 Oktober 2016, 10:18:12
sowas lässt sich ganz banal mit grep lösen, z.B. ./allregister.sh|egrep -v "ERR: read timeout|= 00$"
das bedeutet er fragt das register ab, und prüft ob etwas anderes zurück kommt als "ERR: read timeout|= 00$", dies bedeutet aber er muss das register trotzdem abfragen. dies führt wieder zu sehr langen abfrage zeiten.
schöner wäre das er aus einer Liste die Register nimmt die er nur abragen soll.
habe jetze mal 2x die Register zu verschiedenen Zeiten abgefragt, und mögliche Temp's gefunden
zb.
EA0D 02902b 02b91b
EB0D 02432d 02d015
leider habe ich es noch nicht geschaft diese in Temp umzurechnen.
ich hänge mal eine ods an in der mann die Auslesungen sehen und vergleichen kann.
A= Werte die sich geändert haben (x=Änderung)
B= Registernummer (DEZ)
C= Register (HEX)
D= Wert von gestern
E= Wert von heute
mfg maik
Zitat von: TiPpFeHlEr am 03 Oktober 2016, 11:07:37
habe jetze mal 2x die Register zu verschiedenen Zeiten abgefragt, und mögliche Temp's gefunden
EA0D 02902b 02b91b
EB0D 02432d 02d015
leider habe ich es noch nicht geschaft diese in Temp umzurechnen.
In welcher Größenordnung liegen denn realistische Werte? Was zeigt das UI an?
mögliche Umrechnungsfaktoren:
2b09:256=43°
1b09:256=27*
2d43:256=45°
15d0:256=21°
schau mal, ob Register 1514/0x05ea was ähnliches liefert.
Zitat von: TiPpFeHlEr am 03 Oktober 2016, 11:07:37
ich hänge mal eine ods an in der mann die Auslesungen sehen und vergleichen kann.
A= Werte die sich geändert haben (x=Änderung)
B= Registernummer (DEZ)
C= Register (HEX)
D= Wert von gestern
E= Wert von heute
kann es sein, dass die Spalten gestern/heute vertauscht sind?
ZitatIn welcher Größenordnung liegen denn realistische Werte? Was zeigt das UI an?
mögliche Umrechnungsfaktoren:
2b09:256=43°
1b09:256=27*
2d43:256=45°
15d0:256=21°
schau mal, ob Register 1514/0x05ea was ähnliches liefert.
Register 1514 liefert 00
nein die sind definitiv nicht vertauscht! warum??
Zitat
2b09:256=43°
1b09:256=27*
müsste das nicht
Zitat
2b90:256=43,5625
1bb9:256=27,72265625
heissen?
also die einzig realistische wäre
15d0:256=21°mfg maik
also,
habe mal drüber geschaut.
alle hex Werte die zb. 02xx14 - 02xx16 kommen.
könnten Temperaturwerte sein, da sie sich im Bereich 20-22°C bewegen sollten.
alle anderen sind keine Temp Werte.
ich werde die betreffenden mal umrechnen und vergleichen.
mfg maik
Zitat von: TiPpFeHlEr am 03 Oktober 2016, 11:52:22
nein die sind definitiv nicht vertauscht! warum??
es kam mir nur komisch vor, weil bei vielen Werten mit 4 bytes die hintere Spalte kleinere Werte enthält als die vordere.
Zitat von: TiPpFeHlEr am 03 Oktober 2016, 11:52:22
müsste das nicht
2b90:256=43,5625
1bb9:256=27,72265625
heissen?
es ging nur um die Größenordnung, nicht um die 8. Nachkommastelle ;)
@John
ich meinte eher die HEX Werte nicht das Ergebniss
2b90 &1bb9
@R2D2
wenn ich die Logik hinter den Hexwerten richtig deute
müsste aus der empfangenden ANtwort
02d015
02=Anzahl der byte's
d0=erstes byte
15=zweites byte
beim ausrechnen hatte John folgendes geschrieben
15d0:256=21°
also:
byte2byte1:256=21
also kommt das 2te byte nach vorne gefolgt vom 1ten byte.
wenn ich also nun meinen hex->dez converter füttere
1400->5120/256=20.00000000
1500->5376/256=21.00000000
1600->5632/256=22.00000000
die werte des byte1 (00) bilden dann nur noch die Nachkommerstellen.
160d->5645/256=22,05078125
da nun aller zu erwartenen IstTemperaturen im Bereich von 20 - 22 liegen, kann ich die Suche stark eingrenzen.
mfg maik
Zitates kam mir nur komisch vor, weil bei vielen Werten mit 4 bytes die hintere Spalte kleinere Werte enthält als die vordere.
das ist mir auch aufgefallen.
das könnte der counter für den Filterwechsel sein!!!! juhu ;D
mfg maik
HA,
2 counter gefunden.
350e = Tage bis Filterwechsel
021e00 = 001e =30 Tage
026d01 = 016d =365 Tage
360e = Tage bis Wartung
8)
Schaut mal hier bei pah nach, #350 (LSB)
Zitat von: R2D2_ am 03 Oktober 2016, 16:38:21
Wie soll dann -1.312 aussehen ? ???
signed, also oberstes Bit=1, hier 0x8150 und in reverse aus der Antwort auf dem Bus also 5081.
OK
so hab mich mal neben meine Lüftung gesetzt :o
und ein paar Werte verglichen, dabei konnte ich 99% der Fachhandwerkerebene auswerten.
leider habe ich noch keinen Erfolg mit den Temp und Luftfeuchte Werten.
die die in Frage kommen, ergeben halt nicht die reellen Temp Werte!
Ich glaube Vaillant hat hier wieder einen "selfwarmingcorrection" Wert mit eingebaut.
dieser ist bei meinem 470er 1.81.
mit diesem Wert ergeben die Temps aber trotzdem keinen Sinn.
mfg maik
im Anhang der jetzige STand der RecoVair
Hi,
hab grade noch die Energie Monitor Daten für die Wärmerückgewinnung gefunden.
sehr tricky.... Vaillant nimmt hier teilweise den devisor 10.
Ertrag Heute kwh /10 3670 560E 0421000000
Ertrag Vortag kwh /10 3671 570E 0433000000
Ertrag Monat kwh /10 3672 580E 0454000000
Ertrag Jahr kwh 3673 590E 0476000000
Ertrag Gesamt kwh 3674 5A0E 040b040000
mfg maik
Hallo zusammen,
ich habe hier im Thread schon einige Nutzer gesehen, die auch die Kombination auroMatic VRS 620/3 und VPS S Solarstation haben. Am Display der VRS kann ich ja die Grafik mit den monatlichen Solarerträgen des aktuellen und des vergangenen Jahres abrufen. Hat jemand schon mal geschafft diese Werte auch per ebusd auszulesen?
In der ec.sol.sc.csv sind die Werte SolarYieldThisYear_1 bis SolarYieldThisYear_12 und SolarYieldLastYear_1 bis SolarYieldLastYear_12 auch drin, aber leider nicht in der CSV für die VRS 620/3...
Hat jemand da Ideen / Lösungen?
Danke schon mal...
Ja, die lese ich durchaus. Die sind aber voillkommener Mist, weil das Messverfahren von Vaillant fehlerhaft ist.
SIehe hier http://www.fhemwiki.de/wiki/Ertragsmessung_Solarthermie, eine genaue Erläuterung findet man auch in den SmartHome Hacks
Die korrekt gerechneten Werte differieren von den falschen Vaillant-Ergebnissen durchaus mal um einen Faktor 2-4, siehe das Beispielbild vom 24.9 (die beiden blauen Kurven).
LG
pah
Hallo pah,
danke für den Hinweis zur falschen Berechnung von Vaillant - Erklärung was die falsch machen steht in Deinem Buch? ;-)
Ich frage deshalb weil ich mich mit denen schon seit Monaten wegen eines (aus meiner Sicht) anderen Bugs in der VRS Firmware rumstreite. Die Zirkulationspumpe läuft nur, wenn Gastherme Warmwasser machen darf. Selbst bei voll geladenem Pufferspeicher läuft die Zirkulationspumpe außerhalb der WW Zeiten der Therme nicht, weil Vaillant da eine unsinnige Zwangskopplung von Zirkulationspumpe und Gastherme drin hat. Aber das ist natürlich überhaupt kein Fehler, wenn ich morgens das WW mit Gas aufheizen muss, damit die Zirkupumpe läuft und dann wenn ein paar Stunden später die Sonne scheint, ist der Pufferspeicher leider schon geladen und der Solarertrag verpufft. Tolle Logik von Vaillant... *grrrr*
Wäre schön wenn ich da noch andere belegbare Fehler (wie Berechnung Solarertrag) hätte, um denen zu zeigen dass ihre Software Schrott ist und endlich überarbeitet gehört... (Den Bug kennt Vaillant nämlich schon seit mindestens 2012...)
Mal abgesehen von der Fehlerhaftigkeit der Berechnung - "Ja, die lese ich durchaus." Wie kommst Du denn an die Werte ran? Für die VPS S habe ich noch keine CSV Datei gefunden und in der für die VRS 620/3 sind die Codes für die monatlichen Solarerträge leider auch nicht drin. Ich bin da also erstmal auf der Suche nach Hilfe diese Werte auslesen zu können.
Danke und Grüssle
Sebastian
ZitatErklärung was die falsch machen steht in Deinem Buch? ;-)
Nicht ganz - es ist mir egal, was die falsch machen, so lange ich den richtigen Weg kenne. Meine Zirkulationspumpe wird durch FHEM gesteuert, siehe http://www.fhemwiki.de/wiki/1W-WPump und
SmartHome Hacks.
Betreffend SolarYield: Siehe den untenstehenden Ausschnitt aus meiner Konfigurationsdatei.
LG
pah
Zitat von: Tranquility am 07 Oktober 2016, 21:08:53
Wie kommst Du denn an die Werte ran? Für die VPS S habe ich noch keine CSV Datei gefunden und in der für die VRS 620/3 sind die Codes für die monatlichen Solarerträge leider auch nicht drin. Ich bin da also erstmal auf der Suche nach Hilfe diese Werte auslesen zu können.
Ich werde mal die Solarerträge der 620 in die CSVs einbauen.
@pah: Danke für die CSV. Ich seh schon, ich muss mal noch viel mehr in Deinen Bastelanleitungen (Buch) lesen. Hoffentlich ist im Winter wieder mehr Zeit...
@john30: Danke für die Mühe die CSV gleich zu übernehmen. So langsam bekomme ich alles zusammen... (siehe unten - 12 und fc müsste die VPM W Trinkwasserstation sein - die finde ich in den Config Files nur auf Adresse 0a. Die 25 sollte noch ein weiterer Teil der VPS S Solarstation sein vermute ich.)
localhost: info
version: ebusd 2.1.13cf5b2
signal: acquired
symbol rate: 66
masters: 5
messages: 858
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0608;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
Hallo zusammen,
ich habe an meine Wolf CGW2 Anlage einen Ebus USB-Adapter von E-Service angeschlossen.
Betrieben wird das ganze mit PI2 , ebusd und fhem.
Soweit so gut ... csv Dateien angepasst und ich bekomme entsprechende Ergebnisse.
Ich kann auch entsprechend meine Heizung steuern, zu mindestens das was ich brauche ... Heizungsprogramm und Warmwasserprogramm setzen.
Nachdem ich jetzt noch ein bisschen experimentiert habe, ist mir aufgefallen, dass wenn ich raw-Daten mit ebusd logge und auswerte, da noch wesentlich mehr Telegramme geschickt werden, als ich bei "grab result" sehe.
So weit ich das überblicke sind es Master-Master Telegramme, die ich nicht mit ebusd bei "grab" erfasse.
Wenn ich "grab result" eingebe, bekomme ich lediglich Master-Slave und Broadcast Telegramme angezeigt (dabei ist es egal ob ich diese in einer csv-Datei definiert habe oder nicht).
Wie bekomme ich ebusd dazu, auch die Master-Master Telegramme bei "grab" zu erfassen?
MfG
Hallo zusammen,
bin - besonders durch Lesen dieses Forums - mit Lesen und Schreiben einiger Werte bei meiner Vaillant ecoTEC plus VC 196/3-5 (außer einem Raumthermostat hängt da sonst nichts weiteres dran) schon relativ weit gekommen. Aber jetzt hänge ich definitiv: Finde keine Möglichkeit sowas wie RoomTemp oder RoomTempDesired zu lesen oder zu schreiben oder die dazu passenden hex Telegramme. Erst recht weiß ich nicht, wie man die Therme über den ebusd ein- oder ausschalten kann.
Danke für eure Hilfe
Walter
Das Teil ist in der Wohnung meiner Tochter installiert. Insofern plane ich die vollständige Steuerung mit FHEM schon länger. Muss aber noch ein paar Monate warten, sie und ihr Freund sind beide in der Endphase des Studiums und etwas gestresst.
LG
pah
Zitat von: Tranquility am 09 Oktober 2016, 21:45:11
12 und fc müsste die VPM W Trinkwasserstation sein - die finde ich in den Config Files nur auf Adresse 0a. Die 25 sollte noch ein weiterer Teil der VPS S Solarstation sein vermute ich.)
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0608;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/ed.pms.sc.csv"
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
ordentliches Setup! :-)
Geräte, die auf mehr als einer Adresse auf dem Bus erscheinen, aber physisch nur eine Einheit darstellen, teilen sich oft die Nachrichten. Insofern bringt m.W. die Nutzung der Adresse fc+0a zusätzlich zur 12 nichts, es sei denn Du hast mehr als eine Trinkwasserstation.
25 sollte auch ein Warmwasserteil sein, aber auch hier kann es sinnlos sein, dafür eigene CSVs zu nutzen.
Allerdings gibt es ja die 25.solsy.hwc.csv, hast Du die auch bei Dir in /etc/ebusd/vaillant/ ?
Zitat von: straightshooter am 10 Oktober 2016, 10:41:13
Nachdem ich jetzt noch ein bisschen experimentiert habe, ist mir aufgefallen, dass wenn ich raw-Daten mit ebusd logge und auswerte, da noch wesentlich mehr Telegramme geschickt werden, als ich bei "grab result" sehe.
So weit ich das überblicke sind es Master-Master Telegramme, die ich nicht mit ebusd bei "grab" erfasse.
Wenn ich "grab result" eingebe, bekomme ich lediglich Master-Slave und Broadcast Telegramme angezeigt (dabei ist es egal ob ich diese in einer csv-Datei definiert habe oder nicht).
Wie bekomme ich ebusd dazu, auch die Master-Master Telegramme bei "grab" zu erfassen?
Wenn die jetzt nicht gegrabbt werden, dann nur durch Korrektur des source codes :-)
Ich schau mir das am WE mal an, sollte nicht schwierig sein.
Zitat von: waltino am 10 Oktober 2016, 12:06:39
Finde keine Möglichkeit sowas wie RoomTemp oder RoomTempDesired zu lesen oder zu schreiben oder die dazu passenden hex Telegramme. Erst recht weiß ich nicht, wie man die Therme über den ebusd ein- oder ausschalten kann.
Poste doch mal Dein "ebusctl info" Ergebnis (auch privat wenn Du magst), dann kann ich Dir mehr dazu sagen.
@waltino
Die Sache mit der "Roomtemp" ist etwas verwirrend, da hier alles andere als die gewünschte "Raumtemperatur" kommt.
pi@raspberry2 ~ $ ebusctl read -m 10 roomtemp
40.12;ok
pi@raspberry2 ~ $ ebusctl read -m 10 displayedroomtemp
37.12
pi@raspberry2 ~ $ ebusctl read -m 10 Hc1ManualOPRoomTempDesired
25.0
Wenn du eine echte Raumtemperatur brauchst, empfiehlt sich ein Heizkörperthermostat mit Raumtemperaturregler von Homematic oder FS20, Damit kannst zusätzlich noch die Raumtemperatur einstellen und ablesen, siehe Bild im Anhang, ein Homematic und der Rest FHT80b.
Wenn du die Therme via eBusd ein/ausschalten willst hast nicht sehr viele Optionen. Ich schalte meine Therme generell über den Thermostatanschluß (Klemme 3+4 mit FS20 Schalter gebrückt für Sommer/Winterbetrieb), dann zusätzlich über die Zeitprogramme der Calormatic 430 die mir den groben Tag/Nachbetrieb realisieren. Will ich während dem Tagzyklus die Heizung abschalten, so senke ich einfach die Heizkurve via ebusd auf 0,2 ab. Somit wird die Heizkurve so flach, das sie abschaltet und erst wieder anläuft wenn diese erhöht wird. Die Heizkurve regelt dir ja auch sofort die Vorlauftemperatur herunter, was natürlich jede Zwischenstufe der Heizleistung ermöglicht und trotzdem noch die Außentemperatursteuerung eingreift.
Voraussetzung ist allerdings das an der Therme eine Calormatic oder sonstige Außentemperatursteuerung installiert ist. Ansonsten ist mir kein Ein/Auschalter über den ebusd bekannt, aber vielleicht hat ja jemand anderer noch Möglichkeiten gefunden und angewandt.
LG
Reinhart
diese Methode funktioniert aber nur wenn der 470er Regler abgesetzt ist und nicht in der Therme verbaut ist!
Sonst bekommt man viel zu hohe Temperaturwerte angezeigt, so wie bei mir.
pi@raspberry2 ~ $ ebusctl read -m 10 displayedroomtemp
33.31
Das ist irgend eine Luft Temperatur innerhalb der Therme.
LG
Reinhart
Vielen Dank für eure Anregungen, leider hilft mir das nicht weiter, da für meine Anlage Parameter wie Hc1ManualOPRoomTempDesired, RoomTemp, desiredRoomTemp oder displayedroomtemp leider nicht zur Verfügung stehen. Das liegt wohl daran, dass ich nur die Therme mit einem Raumthermostat angeschlossen habe, so dass jegliche "Komfortfunktionen" wie auch Heizkurven für mich nicht zur Verfügung stehen. Ich muss wohl da in die Tiefen des ebusd (und der passenden Dokumentationen) hinabsteigen, um passende Dinge zu finden. Sollte zufällig jemand wissen, wo man da was findet, wäre ich natürlich sehr dankbar.
LG
Walter
ja leider, ohne Zusatzgerät wie Calormatic etc. hast du nur die eBus Einstellungen die das Gerät selber bietet. Welche Files das sind findest du mit "ebusctl I"
pi@raspberry2 ~ $ ebusctl I
version: ebusd 2.1.422b8d6
signal: acquired
symbol rate: 22
masters: 3
messages: 429
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 26: slave, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002"
address 31: master #8, ebusd
address 36: slave #8
es werden alle gefundenen Geräte aufgelistet, bei dir werden das nur die "bai" Files sein. nun kannst du dir die Files anschauen welche Register hier geboten werden. Sollte aber auch teilweise in der Dokumentation des Gerätes enthalten sein.
Um eine halbwegs brauchbare Steuerung mit mehr Möglichkeiten zu bekommen, wäre aber mindestens eine Calormatic zu empfehlen. Ich habe meine 430 gebraucht um 150.- € gekauft.
zB. so was um 50.- €: https://www.willhaben.at/iad/kaufen-und-verkaufen/d/vaillant-calormatic-470-176257744/ (https://www.willhaben.at/iad/kaufen-und-verkaufen/d/vaillant-calormatic-470-176257744/)
LG
Reinhart
>Um eine halbwegs brauchbare Steuerung mit mehr Möglichkeiten zu bekommen, wäre aber mindestens eine Calormatic zu empfehlen.
Leistet das die Calormatic 323 auch schon? (ist die ebus-fähig?)
LG
Walter
soweit ich sehen kann, sind das alles nur Raumtemperaturregler mit eingebauter Schaltuhr und sind nicht eBus fähig!
Die Geräte sind allesamt mit 3-Draht verkabelt und an den Klemmen des Raumthermostaten (7,8,9) angeschlossen. Kontakt geschlossen = heizen, offen = nicht heizen.
Ich kenne die Produktpalette von Vaillant auch nicht genau, aber ich glaube das funktioniert erst ab der Calormatic 430, die hängt sicher am eBus. das kleine "f" hinter der Bezeichnung, bedeutet Funkverbindung zum Heizgerät und hat nichts direkt mit eBus zu tun.
Außerdem gibt es die csv Files nur für die Calormatic 430 und die 470! Neu würde ich die Geräte auch nicht unbedingt kaufen wollen, aber wie du siehst gibt es sie gebraucht schon ab 50.- €.
LG
Reinhart
Zitat von: Reinhart am 12 Oktober 2016, 10:43:42
Ich kenne die Produktpalette von Vaillant auch nicht genau, aber ich glaube das funktioniert erst ab der Calormatic 430, die hängt sicher am eBus. das kleine "f" hinter der Bezeichnung, bedeutet Funkverbindung zum Heizgerät und hat nichts direkt mit eBus zu tun.
Das stimmt nicht so ganz, denn die müssen noch irgendeine Art Basisstation haben, die widerum am eBus hängt.
Zitat von: Reinhart am 12 Oktober 2016, 10:43:42
Außerdem gibt es die csv Files nur für die Calormatic 430 und die 470! Neu würde ich die Geräte auch nicht unbedingt kaufen wollen, aber wie du siehst gibt es sie gebraucht schon ab 50.- €.
Stimmt auch nicht ganz, für die f Varianten gibt es nämlich auch CSVs, siehe z.B. hier:
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.f47.csv (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.f47.csv)
Zitatdie müssen noch irgendeine Art Basisstation haben, die widerum am eBus hängt
Das wäre jetzt wirklich sehr interessant für mich. Weiß denn jemand darüber genaueres?
ZitatAußerdem gibt es die csv Files nur für die Calormatic 430 und die 470
Und für die Calormatic 350 bzw. 370 gibt's doch auch schon csv Files (oder sehe ich das falsch) und die sind doch wohl auch schon ebus-fähig?
Zitat von: waltino am 12 Oktober 2016, 16:54:40
Das wäre jetzt wirklich sehr interessant für mich. Weiß denn jemand darüber genaueres?
einfach nach Installationsanleitung suchen, dann siehst Du, dass da eine Basisstation dabei ist, ein Funkaußenfühler und der Funkregler.
Zitat von: waltino am 12 Oktober 2016, 16:54:40
Und für die Calormatic 350 bzw. 370 gibt's doch auch schon csv Files (oder sehe ich das falsch) und die sind doch wohl auch schon ebus-fähig?
sehe ich auch so
Hi @ all
Den Regler CalorMatic VRC 430, 470, 470f gibt es nicht mehr von Vaillant als "Neuware" diese sind offiziell nur noch als Ersatzteil zu haben.
Ich würde euch gleich den Nachfolger CalorMatic VRC700 empfehlen.
Zur 7-8-9 Schnittstelle
9=Masse
8=15-24V Spannungsversorgung
7=Vorlaufsolltemp Heizbetrieb 0-15V
Wichtig ist kein Regler angeschlossen, wird der Wert vom Heizgerät bestimmt, der Angeschlossene Regler kann diesen nur senken (gegen Masse legen).
mfg maik
Zitat von: john30 am 11 Oktober 2016, 08:28:05
Wenn die jetzt nicht gegrabbt werden, dann nur durch Korrektur des source codes :-)
Ich schau mir das am WE mal an, sollte nicht schwierig sein.
Danke für die Mühe ...
Noch ein kleiner Hinweis:
Kurioserweise "grabbt" er tatsächlich 1 MasterMaster-Meldung mit. Im Raw-Log sind aber 5 weitere MasterMaster-Meldungen, die er nicht erfasst.
Was ich nicht verstehe, ist, dass bei den 5 weiteren Meldungen sogar noch zwei dabei sind, deren QQ und ZZ identisch zu der "gegrabbten" Meldung sind. Lediglich PBSB(und folgende Bytes) sind anders.
Zitat von: straightshooter am 13 Oktober 2016, 09:36:09
Kurioserweise "grabbt" er tatsächlich 1 MasterMaster-Meldung mit. Im Raw-Log sind aber 5 weitere MasterMaster-Meldungen, die er nicht erfasst.
Was ich nicht verstehe, ist, dass bei den 5 weiteren Meldungen sogar noch zwei dabei sind, deren QQ und ZZ identisch zu der "gegrabbten" Meldung sind. Lediglich PBSB(und folgende Bytes) sind anders.
Dann gib mir doch bitte mal das log, in dem das zu sehen ist.
Zitat von: john30 am 13 Oktober 2016, 09:38:58
Dann gib mir doch bitte mal das log, in dem das zu sehen ist.
Ich habe das Log für mich ein bisschen aufbereitet:
In der Tabelle "RAW" ist der direkte Mitschnitt aus den raw-daten ebusd. Laufzeit ca. 5min.
In der zweiten Tabelle habe ich versucht den Raw-Mischnitt sinnvoll zusammen zustellen (Die Datenbits sind nicht zu Ende verifziert, da es mir lediglich um QQ und ZZ ging.)
Die roten Spalten werden mit "grab" nicht erfasst, die blaue ist die besagte MM-Message die doch erkannt wird und grün müsste alles i.O. sein.
In der dritten Tabelle ist ein "grab result" Auszug. Nicht wundern diesen habe ich gerade gezogen. Das Log ist älter, somit stimmen die Datenbits nicht mit dem Log überein. Doppelte Einträge wie Uhrzeit etc. habe ich ebenfalls entfernt.
In der letzten Tabelle ist ein Auszug aus "ebusctl info".
Ich hoffe du kannst damit jetzt was anfangen ;-)
Zitat von: TiPpFeHlEr am 13 Oktober 2016, 06:14:04
Hi @ all
Den Regler CalorMatic VRC 430, 470, 470f gibt es nicht mehr von Vaillant als "Neuware" diese sind offiziell nur noch als Ersatzteil zu haben.
Ich würde euch gleich den Nachfolger CalorMatic VRC700 empfehlen.
Zur 7-8-9 Schnittstelle
9=Masse
8=15-24V Spannungsversorgung
7=Vorlaufsolltemp Heizbetrieb 0-15V
Wichtig ist kein Regler angeschlossen, wird der Wert vom Heizgerät bestimmt, der Angeschlossene Regler kann diesen nur senken (gegen Masse legen).
mfg maik
Danke für die Information, habe mir die Doku zum VCR700 jetzt gelesen und ersetzt eigentlich durch seine Mulitifähigkeit alle bisherigen Calormatic. In Verbindung mit dem VR 900 kann der Sollwert sogar per App vorgegeben werden. Bei einer Neuanschaffung sicher interessant, kostet halt dann etwas über 400.- für beide Geräte. Optisch gefallen mir die Calormatic alle sehr gut, ein schönes einfaches zeitloses Design, fast zu schade um sie in die Therme einzubauen.
Zu deiner Antwort zu Klemme 7, das ist dann ein reiner analoger Regler, somit ließe sich mit 4 Relaise (FS20 oder HM) eine kleine Widerstandskaskade aufbauen und man könnte so bequem 4 -5 verschiedene (feste) Temperaturen vorgeben. Eventuell könnte man das ganze sogar mit einem 8266 und einer Analogausgabe stufenlos ansteuern. Da ergeben sich dann viele kostengünstige Möglichkeiten für Bastler.
LG
Reinhart
Zitat von: john30 am 02 Oktober 2016, 15:17:10
So, Rätsel gelöst: das war ein kleiner feiner Bug, den ich vor 14 Tagen eingebaut habe. Mit aktuellem git code sollte es jetzt wieder regulär klappen und Deine Änderung an der 08.bai.csv damit auch wieder hinfällig sein. Allerdings musst Du das Polling aktiv lassen, sonst kann ebusd den Produktcode nicht rausfinden...
Hallo John,
habe heute mit neuen Daten vom git auf 2.1 aktualisiert und den gleichen Effekt wie R2D2_ (Fallback auf bai.308523.inc. - 0010009351 wird ignoriert) Ist der Bug noch vorhanden?
08;Vaillant;BAI00;0518;7401;21;12;22;0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
version: ebusd 2.1.28b50d2
...
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002", loaded "vaillant/15.470.csv"
mfg
D.
@reinhardt
http://www.mikrocontroller.net/topic/126250?goto=new#1456906
Hier wird die 7-8-9 Schnittstelle gut beschrieben.
Mfg Maik
ZitatZu deiner Antwort zu Klemme 7, das ist dann ein reiner analoger Regler, somit ließe sich mit 4 Relaise (FS20 oder HM) eine kleine Widerstandskaskade aufbauen und man könnte so bequem 4 -5 verschiedene (feste) Temperaturen vorgeben. Eventuell könnte man das ganze sogar mit einem 8266 und einer Analogausgabe stufenlos ansteuern. Da ergeben sich dann viele kostengünstige Möglichkeiten für Bastler.
Ach, lieber nicht. Viel besser: Mit einem DS2890 vom freundlichen Chinesen ein digitales Potentiometer mit 1-Wire Interface. Direkt ansteuerbar über das FHEM-Modul OWVAR, und zwar sogar als Temperaturwert.
LG
pah
Zitat von: de.jt am 13 Oktober 2016, 22:49:53
habe heute mit neuen Daten vom git auf 2.1 aktualisiert und den gleichen Effekt wie R2D2_ (Fallback auf bai.308523.inc. - 0010009351 wird ignoriert) Ist der Bug noch vorhanden?
version: ebusd 2.1.28b50d2
Deine Version ist vom Frühjahr. Du musst ebusd schon auf die aktuelle git Version aktualisieren, sonst ist der Fehler natürlich noch drin.
Zitat... VCR700 jetzt gelesen und ersetzt eigentlich durch seine Mulitifähigkeit alle bisherigen Calormatic. In Verbindung mit dem VR 900 kann der Sollwert sogar per App vorgegeben werden. Bei einer Neuanschaffung sicher interessant, kostet halt dann etwas über 400.- für beide Geräte
Bitte noch einmal, habe ich das richtig verstanden: Ohne Zusatzgerät (Calormatic 470) ist die Kommunikation mit der Therme auf ein Minimum beschränkt: Abfragen einiger Werte, aber keine (oder nur minimale) Steuerungsmöglichkeiten. Zusatzanschaffung, -einbau daher empfohlen. Konsequenz VR 700 und VR 900 ---> dann brauche ich allerdings die Kommunikation über den ebus nicht mehr????
LG
Walter
Zitatsogar per App vorgegeben werden kann
:'( :'(
Ich wünschte, unsere Mitbürger würden kapieren, dass eine Vielzahl von Steuerapps - jeder Hersteller macht seinen eigenen Müll - ein erhebliches Sicherheitsrisiko darstellen und die Datensammelei unterstützen...
LG
pah
Von der VR900+App Kombination, kann ich aus Erfahrung nur abraten! Im Moment gibt es große Probleme mit der App. Immerwieder Fehlermeldungen und nicht auslesbare Daten.
Unsere letzten Kunden liegen nun im Streit mit uns und vaillant.
Dies betrifft vor allem die "Green IQ" Serie von vaillant.
Mfg Maik
Zitat von: john30 am 14 Oktober 2016, 10:46:56
Deine Version ist vom Frühjahr. Du musst ebusd schon auf die aktuelle git Version aktualisieren, sonst ist der Fehler natürlich noch drin.
??? Ich habe ebusd deinstalliert, ebusd-2.1_armhf.deb aus dem git (https://github.com/john30/ebusd/releases/tag/v2.1) geladen und installiert.
Ergebnis:
version: ebusd 2.1.28b50d2
was mache ich falsch?
Grüsse,
D.
Zitat von: de.jt am 14 Oktober 2016, 22:09:15
??? Ich habe ebusd deinstalliert, ebusd-2.1_armhf.deb aus dem git (https://github.com/john30/ebusd/releases/tag/v2.1) geladen und installiert.
Ergebnis:
version: ebusd 2.1.28b50d2
was mache ich falsch?
Dann musst Du auf das nächste Release warten, ist noch nicht ganz so weit.
Zitat von: waltino am 14 Oktober 2016, 13:10:20
Bitte noch einmal, habe ich das richtig verstanden: Ohne Zusatzgerät (Calormatic 470) ist die Kommunikation mit der Therme auf ein Minimum beschränkt: Abfragen einiger Werte, aber keine (oder nur minimale) Steuerungsmöglichkeiten. Zusatzanschaffung, -einbau daher empfohlen. Konsequenz VR 700 und VR 900 ---> dann brauche ich allerdings die Kommunikation über den ebus nicht mehr????
Nicht ganz, Du kannst im Prinzip alles steuern, aber das ist halt keine so triviale Angelegenheit. Wenn Du wirklich auf einen Controller mit Heizkurve und Aussentemperatur abhängiger Steuerung verzichten willst, dann müsstest Du das halt komplett selbst machen. Diesen Anspruch hatte bis jetzt noch keiner, aber wie gesagt, möglich wäre es.
Zitat von: straightshooter am 13 Oktober 2016, 13:13:43
Ich habe das Log für mich ein bisschen aufbereitet:
In der Tabelle "RAW" ist der direkte Mitschnitt aus den raw-daten ebusd. Laufzeit ca. 5min.
In der zweiten Tabelle habe ich versucht den Raw-Mischnitt sinnvoll zusammen zustellen (Die Datenbits sind nicht zu Ende verifziert, da es mir lediglich um QQ und ZZ ging.)
Die roten Spalten werden mit "grab" nicht erfasst, die blaue ist die besagte MM-Message die doch erkannt wird und grün müsste alles i.O. sein.
In der dritten Tabelle ist ein "grab result" Auszug. Nicht wundern diesen habe ich gerade gezogen. Das Log ist älter, somit stimmen die Datenbits nicht mit dem Log überein. Doppelte Einträge wie Uhrzeit etc. habe ich ebenfalls entfernt.
In der letzten Tabelle ist ein Auszug aus "ebusctl info".
Ich hoffe du kannst damit jetzt was anfangen ;-)
tja, also nach dem raw log werden mindestens die ersten zwei der nicht gegrabbten messages vom adressierten device nicht acknowledged. darum erscheinen sie auch nicht im grab result.
den rest hab ich nicht mehr geprüft.
Hallo Zusammen,
Ich weiß gerade nicht ob es in diese Rubrik gehört oder doch in die Anfänger Rubrik.
Ich hab ein Problem mit den Readings.
Für das auslesen benutzen ich ECMD.
Folgendes habe ich definiert
################## bai00.cfg ###############
get Aussentemp cmd {"r -f outsidetemp temp\n"}
get Aussentemp expect ".*\n*"
get Aussentemp postproc { $_ }
#fhem.cfg
define Aussentemp ECMDDevice bai00.class
attr Aussentemp IODev EBUS
attr Aussentemp group Vaillant
attr Aussentemp icon sani_supply_temp
attr Aussentemp room Vaillant
Im device gibt es jetzt zwei Readings
Aussentemp: 15
state: Aussentemp 15
Wie bekomme ich das hin, das im State nur 15 steht?
Ich brauche das so, weil in meiner VISU, kann ich nur auf das Device und deren State zugreifen und nicht auf ein zusätzliches Reading.
Gruß
lewej
Probier mal stateFormat
Zitat von: jkriegl am 15 Oktober 2016, 21:42:55
Probier mal stateFormat
Hi,
Habe ich schon versucht, das ist aber nur eine formatierte Anzeige, die man nur in fhem. direkt nutzen kann. Meine Visu braucht das State vom Device und da steht das noch immer drin.
Gruß
Lewej
Zitat von: de.jt am 14 Oktober 2016, 22:09:15
??? Ich habe ebusd deinstalliert, ebusd-2.1_armhf.deb aus dem git (https://github.com/john30/ebusd/releases/tag/v2.1) geladen und installiert.
So, jetzt ist ebusd 2.2 als Release erhältlich:
https://github.com/john30/ebusd/releases/tag/v2.2
VG John
Zitat von: john30 am 16 Oktober 2016, 15:35:28
So, jetzt ist ebusd 2.2 als Release erhältlich:
https://github.com/john30/ebusd/releases/tag/v2.2
VG John
Hallo Johnm,
ist im 2.2 Release das Problem mit den Timern auch behoben?
7:10 klappt
7:01 nicht
Grüsse
Zitat von: lewej am 17 Oktober 2016, 21:39:12
ist im 2.2 Release das Problem mit den Timern auch behoben?
7:10 klappt
7:01 nicht
Behoben ist das falsche Wort, denn das war ja so beabsichtigt.
Aber in Release 2.2 sind diese Datentypen toleranter bzgl. Fehleingaben, insofern: ja
Zitat von: john30 am 15 Oktober 2016, 18:10:29
tja, also nach dem raw log werden mindestens die ersten zwei der nicht gegrabbten messages vom adressierten device nicht acknowledged. darum erscheinen sie auch nicht im grab result.
den rest hab ich nicht mehr geprüft.
Gehe ich recht in der Annahme, dass ohne ACK diese Messages nie gegrabbt werden?!
Andere Frage noch:
Ich betreibe den EBus USB-Adapter von E-Service an meiner CGW2 (entspricht der CGB2 mit Schichtenspeicher) und BM-2.
Angeschlossen ist der Adapter an der HCM-2 Platine (grüner Stecker Ebus).
Beim letzten mal ist mir aufgefallen, dass wenn ich den Adapter anschließe, werden im BM-2 bestimmte Werte (z.B. Vorlauf_Soll) nicht mehr aktualisiert. Wenn ich die Heizkurve am BM-2 ändere, bleibt der Wert Vorlauf_Soll immer gleich. Ziehe ich den Adapter heraus, wird wieder ganz normal aktualisiert.
Ich bin bisher davon ausgegangen, dass wenn ich EBUSD am Raspberry laufen habe, dass dies eine zusätzliche Steuerungsmöglichkeit für die Anlage ist. Aber ich habe das Gefühl, dass durch diesen Anschluss irgendwas am BM-2 deaktiviert wird.
Prinzipiell läuft die Anlage mit EBUSD, aber normal ist das nicht, dass auf einmal Werte nicht mehr aktualisiert werden.
Kennt jemand das Phänomen?
Hallo zusammen!
Ich bin neu hier und möchte gerne um Unterstützung bei meinem Problem ersuchen.
Doch erst einmal meinen Dank und meine Bewunderung an alle, die dieses Projekt so weit gebracht haben. Die unzähligen Stunden die hier hineingeflossen sind kann ich nur erahnen. Eine tolle Arbeit!
Also in meinem Heizungskeller befindet sich eine Vaillant EcoTec exclusiv, eine AuroMatic 620, ein Mischermodul VR60/3 und Im Wohnzimmer ein Fernbedienungsgerät VR90.
An den eBUS habe ich den eService eBus USB Koppler angeschlossen und dahinter einen Raspi mit dem ebusd laufen. Das funktioniert seit Wochen alles prima und stabil, zu meinem Glück habe ich keinerlei Probleme mit ,,connection lost" o.ä.
Einiges habe ich bereits identifizieren können, so sind z.B. Vorlauf- und Rücklauftemperatur von der ecoTec an VF1 und VF2 der Auromatic angeschlossen und ich kann dort auch vernünftige Werte auslesen.
Fußbodenheizung und Boiler sind allerdings über das Mischer-Modul VR60/3 angeschlossen (HKa, VFa, HKb und VFb) und hier beginnt mein Problem: Obwohl ich fast alle 127 Seiten in diesem Forum gelesen habe, und auch die WIKIs studiert habe, gelingt es mir nicht herauszubekommen, wie ich an die Werte des VR60 Mischermoduls herankomme. Irgendwie passen die Informationen in den .csv Files nicht zu den Beschriftungen und mir ist auch völlig unklar, ob die *SOLSY*.csv die nötigen Inhalte haben oder ob es für VR60 ein eigenes .csv geben müsste und dieses noch gar nicht existiert.
Hier einmal meine Konfiguration:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 56
masters: 4
messages: 696
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 17: master #17
address 1c: slave #17, scanned "MF=Vaillant;ID=RC C ;SW=0501;HW=6201", loaded "vaillant/1c.rcc.4.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Außerdem bekomme ich einige unknown messages. Ob das von Bedeutung ist ist mir allerdings auch unklar, denn sie betreffen ja alle ,,SOLSY" und dann müsste ja die VR60 da drin enthalten sein ?
1008b513020508 / 00
1023b505082b0f010000000080 / 00
1025b5040109 / 0a3c0000008016000f5a00
1025b5040117 / 0100
1025b5050427001900 / 00
1025b5050427001a00 / 00
1025b5050427001b00 / 00
1025b505082b0f010000000080 / 00
1026b5040101 / 09140300000580000100
1026b5050427001900 / 00
1026b5050427001a00 / 00
1026b5050427001b00 / 00
1026b505082b0f010000000080 / 00
1050b5050427001900 / 00
1050b5050427001a00 / 00
1050b5050427001b00 / 00
1050b505082b0f010000000080 / 00
10ecb5040101 / 09000200000207000100
10ecb504010d / 050000008000
10ecb5040121 / 05170000f200
10ecb5050427001900 / 00
10ecb5050427001a00 / 00
10ecb5050427001b00 / 00
10ecb505082b0f010000000080 / 00
10feb505025501
Also falls hier jemand durchblickt wäre ich sehr dankbar für eine kurze Aufklärung, was denn jetzt Sache ist.
Ach ja, und bei meinen Analysen bin ich auf Ungereimtheiten in zwei .csv Files gestoßen wo ich denke dass es so nicht gemeint war und deshalb vielleicht ausgebessert gehörte ?
- In ec.solsy.sc.csv - Storage4Sensor3: Statt ,,Temperature of SP4 Sensor" sollte es heißen: ,,Temperature of TD1 Sensor".
- In 50.solsy.mc.csv – FlowTemp: Statt ,,VF1 Sensor" sollte es heißen: ,,VF2 Sensor"
LG
Eduard
Zitat von: straightshooter am 18 Oktober 2016, 15:02:16
Gehe ich recht in der Annahme, dass ohne ACK diese Messages nie gegrabbt werden?!
richtig, ohne ACK muss davon ausgegangen werden, dass der Empfänger die Nachricht nicht versteht.
Zitat von: galileo am 19 Oktober 2016, 13:31:11
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 56
masters: 4
messages: 696
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 17: master #17
address 1c: slave #17, scanned "MF=Vaillant;ID=RC C ;SW=0501;HW=6201", loaded "vaillant/1c.rcc.4.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Problem Nr. 1: Dein VR60 ist nicht zu sehen.
Auf welchen Heizkreis hast Du den VR60 eingestellt?
ZitatAuf welchen Heizkreis hast Du den VR60 eingestellt?
Das hat mein Installateur gemacht.
Aber in einem Menue der 620 steht:
HK2: Radiatoren
HK4: Fussboden
HK5: Warmwasser
Da die Radiatoren an der 620 angeschlossen sind, muss auf der VR60
KHa = HK4 = Fussboden und HKb = HK5 = Warmwasser sein.
Zitat von: galileo am 19 Oktober 2016, 15:12:15
Das hat mein Installateur gemacht.
Aber in einem Menue der 620 steht:
HK2: Radiatoren
HK4: Fussboden
HK5: Warmwasser
Da die Radiatoren an der 620 angeschlossen sind, muss auf der VR60
KHa = HK4 = Fussboden und HKb = HK5 = Warmwasser sein.
Mach doch mal ein "ebusctl scan full", warte ne Minute und gib dann nochmal das info Ergebnis aus.
Im Moment scheint kein einziges Gerät mit HK4+HK5 zu kommunizieren...
ZitatMach doch mal ein "ebusctl scan full", warte ne Minute und gib dann nochmal das info Ergebnis aus.
Im Moment scheint kein einziges Gerät mit HK4+HK5 zu kommunizieren...
Also das ist sehr eigenartig. Ich hab das Warmwasser laufen lassen und auch die Solltemperatur Fussboden auf 30 Grad gestellt und 10 Minuten gewartet.
Da hätte sich doch etwas tun müssen ???
Wie könnte ich denn erkennen dass mit HK4-HK5 kommuniziert wird ?
pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;BAI00;0703;7401;21;13;28;0010004111;0006;005309;N2
15;Vaillant;UI ;0507;6201;21;13;26;0020080465;0907;007457;N9
1c;Vaillant;RC C ;0501;6201;21;12;11;0020040079;0907;005033;N9
23;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
25;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
26;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
50;Vaillant;SOLSY;0500;6301;21;13;26;0020080463;0907;006832;N0
ec;Vaillant;SOLSY;0500;6301
Ich habe auch noch alle Geräte stromlos gemacht und wieder eingeschaltet. Jetzt gibt es zwei Adressen mehr (3F und 52):
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 52
masters: 5
messages: 698
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 17: master #17
address 1c: slave #17, scanned "MF=Vaillant;ID=RC C ;SW=0501;HW=6201", loaded "vaillant/1c.rcc.4.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8
address 3f: master #23
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 52: slave
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Zitat von: galileo am 19 Oktober 2016, 20:15:04
Also das ist sehr eigenartig. Ich hab das Warmwasser laufen lassen und auch die Solltemperatur Fussboden auf 30 Grad gestellt und 10 Minuten gewartet.
Da hätte sich doch etwas tun müssen ???
Wie könnte ich denn erkennen dass mit HK4-HK5 kommuniziert wird ?
Das "info" Ergebnis zeigt alle Adressen, die seit Start von ebusd in einer erfolgreichen Kommunikation involviert waren, d.h. wenn dort die Geräte nicht auftauchen, dann hat kein anderes Gerät mit diesen erfolgreich kommuniziert. Zumindest aus Sicht von ebusd.
Es könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst. Dazu gibt es einige Hinweise im FHEM ebus Wiki.
ZitatEs könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst.
Ich werde das heute abend ausprobieren.
Aber kannst du mir bitte noch sagen, was ich zu erwarten habe, falls das VR60 erkannt würde.
Erscheint dann eine neue Adresse und eine neue ID ?
Welches csv wäre denn dafür zuständig ?
Oder gibt's noch gar kein csv welches das abdeckt ?
Entschuldige bitte die dumme Fragerei, aber ich denke ich tu mir leichter, wenn ich verstehe, wonach ich suchen muss.
LG
Eduard
Zitat von: galileo am 20 Oktober 2016, 10:31:26
Aber kannst du mir bitte noch sagen, was ich zu erwarten habe, falls das VR60 erkannt würde.
Erscheint dann eine neue Adresse und eine neue ID ?
Es müsste dann nach meinen Infos die Adressen 52 und 53 im "info" Ergebnis auftauchen.
Zitat von: galileo am 20 Oktober 2016, 10:31:26
Welches csv wäre denn dafür zuständig ?
52.mc2.mc.4.csv bzw. 53.mc2.mc.5.csv
ZitatEs könnte noch sein, dass Du das Poti Deiner eBUS Hardware etwas nachjustieren musst. Dazu gibt es einige Hinweise im FHEM ebus Wiki.
Hallo John,
das war's !!Lange am Poti gedreht, aber jetzt habe ich eine Adresse 52 und 53.
Vielen Dank für den Tip, ich wäre - eben
wegen der Anleitung im WIKI - nie auf die Idee gekommen.
Tatsächlich war es so dass ich einwandfreie <aa und dazwischen andere Hex Werte hatte, aber das ist offenbar nur notwendig - und nicht hinreichend.
Das heißt ja nur dass ich
irgendeinen Busteilnehmer empfange aber eben nicht alle. Wenn ein anderer mit seinen Pegeln ein wenig neben jenen mit dem Poti eingestellten liegt, dann empfängt man den halt nicht...
Ja und dann noch die Frage, ob ich mich da nicht nützlich machen könnte: Auch in der 53.mc2.mc.5.csv gibt's Einträge, die sicher so nicht gehören. Z.B. steht in der Überschrift "MK2", beim [comment] steht "Hk3P_Port3", bei comment steht "...pump on MK1P" und die tatsächliche Beschriftung in der VR60 lautet "HKb-P".
Besteht ein Interesse soetwas auszubessern und wenn ja, wo soll ich das "ablegen" ?
Zitat von: john30 am 05 Juni 2016, 11:33:02
Mit dem jüngsten commit 086dea5 (https://github.com/john30/ebusd/commit/086dea50604aba44fe4b789fb525a7a7a984af23) lassen sich jetzt auch ganz einfach mehrere ebusd Instanzen starten, indem mehrere EBUSD_OPTS in /etc/default/ebusd eingetragen werden.
Hey John,
lange ists her. Habe gestern meinen Raspberry frisch aufgesetzt und gleich deine aktuellste ebusd Version von git ausgecheckt.
Wollte dann folgendes testen:
EBUSD_OPTS1="--readonly --device=/dev/ftdi1 --localhost --port=5001 -l /var/log/ebusd1.log"
EBUSD_OPTS2="--readonly --device=/dev/ftdi2 --localhost --port=5002 -l /var/log/ebusd2.log"
sudo systemctl start ebusddie erste Instanz funktioniert dann einwandfrei aber im
/var/log/ebusd2.log steht
2016-10-21 07:46:45.920 [main notice] ebusd 2.2.af6e1c1 started
2016-10-21 07:46:45.931 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-21 07:46:45.939 [bus error] unable to open /dev/ftdi2: ERR: generic device error
schreibe ich aber
sudo systemctl stop ebusd
ebusd -f --readonly --device=/dev/ftdi2 --localhost --port=5002ins Terminal so erhalte ich gleich:
2016-10-21 08:03:54.638 [main notice] ebusd 2.2.af6e1c1 started
2016-10-21 08:03:54.650 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-21 08:03:54.676 [bus notice] signal acquired
2016-10-21 08:04:02.163 [bus notice] new master 71, master count 2
2016-10-21 08:04:02.163 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-21 08:04:17.112 [update notice] update solar temp: 0;41.88;34.62
weißt du worans liegen könnte?
bevor du diese Methode angeboten hast habe ich ja das ebusd programm dupliziert und es mit folgendem Startscript zum laufen gebracht:
systemctl start ebusd2
systemctl start ebusd
sleep 2
systemctl stop ebusd2
systemctl stop ebusd
systemctl start ebusd
sleep 1
systemctl start ebusd2wobei es hier auf die Reihenfolge ankam wie gestartet und gestoppt wird.
Beste Grüße
Zitat von: galileo am 20 Oktober 2016, 20:47:08
Hallo John, das war's !!
Lange am Poti gedreht, aber jetzt habe ich eine Adresse 52 und 53.
Vielen Dank für den Tip, ich wäre - eben wegen der Anleitung im WIKI - nie auf die Idee gekommen.
Tatsächlich war es so dass ich einwandfreie <aa und dazwischen andere Hex Werte hatte, aber das ist offenbar nur notwendig - und nicht hinreichend.
Das heißt ja nur dass ich irgendeinen Busteilnehmer empfange aber eben nicht alle. Wenn ein anderer mit seinen Pegeln ein wenig neben jenen mit dem Poti eingestellten liegt, dann empfängt man den halt nicht...
Das freut mich. Ja, die Pegel können halt insbesondere auch wegen der Leitungslänge je nach Device etwas unterschiedlich sein.
Zitat von: galileo am 20 Oktober 2016, 20:47:08
Ja und dann noch die Frage, ob ich mich da nicht nützlich machen könnte: Auch in der 53.mc2.mc.5.csv gibt's Einträge, die sicher so nicht gehören. Z.B. steht in der Überschrift "MK2", beim [comment] steht "Hk3P_Port3", bei comment steht "...pump on MK1P" und die tatsächliche Beschriftung in der VR60 lautet "HKb-P".
Besteht ein Interesse soetwas auszubessern und wenn ja, wo soll ich das "ablegen" ?
Interesse besteht da natürlich, klar. Allerdings sind die paar Tausend Zeilen der CSVs größtenteils generiert und warten eigentlich noch auf die Vereinheitlichung der Namen, die pah mal angeregt hatt und die ich auch befürworte. Da gehts nur leider seit nicht vorwärts, weil die Regeln für die Nomenklatur erst einmal diskutiert werden wollen. Der letzte Beitrag dazu ist schon einige Monate her fürchte ich.
Anyway, bevor diese Umbenennung durchgeführt wurde und in meinem Generator eingebaut ist, macht es nicht so wahnsinning viel Sinn, Korrekturen in den anderen Teilen der Definitionen durchzuführen. Denn sonst darf ich das nach der Generierung alles manuell mergen, was nicht wirklich der große Spaß ist...
VG John
Zitat von: flash91 am 21 Oktober 2016, 08:14:27
schreibe ich aber
ebusd -f --readonly --device=/dev/ftdi2 --localhost --port=5002
Hast Du mal die Rechte der dev nodes gecheckt?
meinst du unter /lib/udev/rules.d/50-udev-default.rules ?
dort steht
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"
bzw.:
ls -ldh /dev/ftdi1
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi1 -> ttyUSB1
ls -ldh /dev/ftdi2
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi2 -> ttyUSB0
Zitat von: flash91 am 21 Oktober 2016, 09:32:17
ls -ldh /dev/ftdi1
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi1 -> ttyUSB1
ls -ldh /dev/ftdi2
lrwxrwxrwx 1 root root 7 Oct 20 20:47 /dev/ftdi2 -> ttyUSB0
Das meinte ich, aber das scheint nicht das Problem zu sein. Merkwürdig, da hab ich jetzt spontan keine Idee, woran es liegen könnte.
Probier mal die EBUSD_OPTS1 auszukommentieren und die EBUSD_OPTS umzubenennen in EBUSD_OPTS (vorher service ebusd stop) und dann service ebusd start.
Ach ja, EBUSD_OPTS ist aber schon auskommentiert oder?
Zitat von: john30 am 22 Oktober 2016, 09:48:03
Das meinte ich, aber das scheint nicht das Problem zu sein. Merkwürdig, da hab ich jetzt spontan keine Idee, woran es liegen könnte.
Probier mal die EBUSD_OPTS1 auszukommentieren und die EBUSD_OPTS umzubenennen in EBUSD_OPTS (vorher service ebusd stop) und dann service ebusd start.
Ach ja, EBUSD_OPTS ist aber schon auskommentiert oder?
Ohh hatte nicht gesehen dass im Konfig-File ganz oben zwischen den Kommentaren noch
EBUSD_OPTS steht ::).
Daran hats gelegen! Jetzt starten beide Instanzen normal. Danke :)
Allerdings habe ich seit heute das Problem, dass ich über den ftdi2 keine updates mehr erhalte...
nicht mal mehr wenn ich den Prozess im Vordergrund starte, so wie gestern, obwohl ich immer folgende Meldungen erhalte:
2016-10-22 16:10:26.251 [main notice] ebusd 2.2.af6e1c1 started
2016-10-22 16:10:26.262 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-22 16:10:26.267 [bus notice] signal acquired
und sonst nichts geändert habe (außer die Konfig).
Ich hab auch mindestens 5 min gewartet und auch den ftdi2 im raw-Modus kontrolliert, da kommen schön die
aa und zwischendurch die Werte vom Wolf-Gerät mit
71 fe 50 17 10 01 01 7d ....Über den ftdi1 funktionierts aber reibungslos...
Folgendes habe ich auch schon probiert:
- raspi reboot
- make uninstall, /home/pi/ebusd löschen, erneut von git auschecken und wieder kompiliert und installiert
Hast du noch einen schnellen Rat was ich sonst noch probieren könnte?
Andernfalls werde ich den Raspberry vermutlich nochmal komplett neu aufsetzen.
Edit: achja und beide Instanzen verwenden dieselbe "50.csv" in /etc/ebusd also sind Tippfehler darin ausgeschlossen.
Sehr seltsam... seit heute bekomm ich wieder updates für beide ftdi
Naja damit hat sich das hoffentlich auch erledigt ^^
Danke nochmal :)
Zitat von: flash91 am 23 Oktober 2016, 09:24:56
Sehr seltsam... seit heute bekomm ich wieder updates für beide ftdi
Naja damit hat sich das hoffentlich auch erledigt ^^
Danke nochmal :)
gerne :-)
Zitat von: john30 am 16 Oktober 2016, 15:35:28
So, jetzt ist ebusd 2.2 als Release erhältlich:
https://github.com/john30/ebusd/releases/tag/v2.2
VG John
Hallo John.
Ich habe ebusd 2.2 (ebusd-2.2_armhf.deb) neu aufgesetzt.
version: ebusd 2.2.65328e5
...
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "
bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0128;HW=6002", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8
08;Vaillant;BAI00;0518;7401;21;12;22;
0010009351;3100;005676;N3
15;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
26;Vaillant;47000;0128;6002;21;12;23;0020108127;0082;020860;N8
Meine Hardware
0010009351 wird in vaillant/08.bai.csv aufgeführt (s. Anlage). Warum wird an Stelle der zugehörigen bai.0010003886.inc das Fallback bai.308523.inc geladen?
Was mache ich falsch?
Grüsse,
D.
Zitat von: de.jt am 23 Oktober 2016, 20:26:11
Warum wird an Stelle der zugehörigen bai.0010003886.inc das Fallback bai.308523.inc geladen?
berechtigte Frage. Kannst Du mal ebusd neu starten und mir dann das Log davon schicken?
Zitat von: john30 am 24 Oktober 2016, 09:40:11
berechtigte Frage. Kannst Du mal ebusd neu starten und mir dann das Log davon schicken?
Hallo John,
hier das Logfile:
2016-10-24 18:00:41.053 [main notice] ebusd 2.2.65328e5 started
2016-10-24 18:00:41.115 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2016-10-24 18:00:41.124 [bus notice] signal acquired
2016-10-24 18:00:45.833 [bus notice] new master 10, master count 2
2016-10-24 18:00:45.900 [bus notice] new master 03, master count 3
2016-10-24 18:00:45.901 [update notice] unknown MS cmd: 1008b5110101 / 093a38d0084e5a0000ff
2016-10-24 18:00:50.082 [update notice] unknown MS cmd: 1008b5100900004b8cffff00ff00 / 0101
2016-10-24 18:00:51.124 [main notice] starting initial scan for fe
2016-10-24 18:00:51.431 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2016-10-24 18:00:51.434 [main notice] read common config file /etc/ebusd/vaillant/general.csv
2016-10-24 18:00:51.439 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-10-24 18:00:51.452 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2016-10-24 18:00:51.636 [main notice] found messages: 211 (3 conditional on 23 conditions, 1 poll, 8 update)
2016-10-24 18:00:52.139 [bus notice] poll scan.08 id:
2016-10-24 18:00:53.934 [main notice] read scan config file /etc/ebusd/vaillant/15.470.csv for ID "47000", SW0128, HW6002
2016-10-24 18:00:54.002 [main notice] found messages: 457 (3 conditional on 23 conditions, 1 poll, 8 update)
2016-10-24 18:00:56.338 [update notice] update bai Status01 QQ=10: 28.0;28.0;8.812;39.0;45.0;off
2016-10-24 18:00:56.587 [update notice] update broadcast vdatetime QQ=10: 18:00:58;24.10.2016
2016-10-24 18:00:56.842 [update notice] unknown MS cmd: 1008b512020064 / 00
2016-10-24 18:00:57.674 [bus notice] poll scan.08 id:
2016-10-24 18:01:00.549 [update notice] update bai Mode QQ=10: standby
2016-10-24 18:01:03.658 [bus notice] poll scan.08 id:
2016-10-24 18:01:04.717 [update notice] update bai Status01 QQ=10: 28.0;28.0;8.812;39.0;45.0;off
2016-10-24 18:01:06.852 [update notice] update bai DateTime QQ=10: nosignal;18:01:09;-.-.-;8.812
2016-10-24 18:01:07.124 [update notice] update bai Status02 QQ=10: auto;60;45.0;80;45.0
2016-10-24 18:01:09.662 [bus notice] poll scan.08 id:
2016-10-24 18:01:11.047 [update notice] update bai Mode QQ=10: standby
Zitat von: de.jt am 24 Oktober 2016, 18:05:33
hier das Logfile:
2016-10-24 18:00:51.452 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2016-10-24 18:00:52.139 [bus notice] poll scan.08 id:
das ist merkwürdig, hier sollte eigentlich etwas mehr stehen, als dieses Nichts. Zudem sollte eigentlich der Scan vor dem Laden passieren. Muss ich mir mal in Ruhe anschauen.
Welche CSVs hast Du im Einsatz?
Zitat von: john30 am 25 Oktober 2016, 08:11:00
das ist merkwürdig, hier sollte eigentlich etwas mehr stehen, als dieses Nichts. Zudem sollte eigentlich der Scan vor dem Laden passieren. Muss ich mir mal in Ruhe anschauen.
Welche CSVs hast Du im Einsatz?
Ich habe aus dem git-Verzeichnis ebusd-configuration das Verzeichnis / ebusd-2.1.x / de / via ftp nach /etc/ebusd/ kopiert.
Zitat von: de.jt am 25 Oktober 2016, 08:42:10
Ich habe aus dem git-Verzeichnis ebusd-configuration das Verzeichnis / ebusd-2.1.x / de / via ftp nach /etc/ebusd/ kopiert.
und nichts davon modifiziert?
Zitat von: R2D2_ am 24 Oktober 2016, 20:48:31
@de.jt: ändere vorläufig die 08.bai.csv, die beiden letzten Zeilen wie folgt:
#!load,bai.308523.inc,,,
!load,bai.0010003886.inc,,,
Damit hast Du erstmal Ruhe ...
ja, so etwas in der Art habe ich mir auch schon gedacht... wäre aber keine saubere Installation. Die Problemlösung wäre mir lieber (schützt vor eventuellen späteren Überraschungen... ;))
Hallo John,
leider hat sich das Problem nicht ganz von selbst gelöst und wenn ich neustarte funktioniert das Update der zweiten Instanz ab und zu nicht.
Habe heute eigentlich ab 12:20 schon aufgegeben, aber es laufen lassen, da ich zu einem Termin musste. Nach 4 Stunden plötzlich updates.
Sagt dir die Meldung dazwischen etwas oder deutet die auf einen schlecht eingedrehten Konverter hin?
2016-10-25 10:17:08.790 [main notice] ebusd 2.2.af6e1c1 started
2016-10-25 10:17:08.813 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-25 10:17:08.963 [bus notice] signal acquired
2016-10-25 10:17:10.019 [bus notice] max. symbols per second: 109
2016-10-25 10:53:34.407 [bus notice] new master 71, master count 2
2016-10-25 11:27:40.344 [main notice] SIGTERM received
2016-10-25 11:27:40.445 [main notice] ebusd stopped
2016-10-25 11:27:55.768 [main notice] ebusd 2.2.af6e1c1 started
2016-10-25 11:27:55.780 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-25 11:27:55.791 [bus notice] signal acquired
2016-10-25 11:32:49.531 [bus notice] new master 71, master count 2
2016-10-25 11:39:46.909 [bus notice] new master 30, master count 3
2016-10-25 11:39:46.910 [update notice] unknown MM cmd: 7130502309b0f40200045d010000
2016-10-25 12:20:13.267 [main notice] SIGTERM received
2016-10-25 12:20:13.369 [main notice] ebusd stopped
2016-10-25 12:20:26.402 [main notice] ebusd 2.2.af6e1c1 started
2016-10-25 12:20:26.470 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-25 12:20:26.484 [bus notice] signal acquired
2016-10-25 12:24:00.099 [bus notice] new master 71, master count 2
2016-10-25 15:09:50.443 [update notice] update solar temp: 1;39.50;31.31
2016-10-25 15:16:24.941 [bus notice] new master 30, master count 3
2016-10-25 15:16:24.941 [update notice] unknown MM cmd: 7130502309b0f40200045d010000
2016-10-25 16:00:16.322 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-25 16:00:31.222 [update notice] update solar temp: 1;35.50;30.00
2016-10-25 16:28:35.571 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-25 16:28:50.470 [update notice] update solar temp: 0;35.62;29.88
2016-10-25 16:29:05.394 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-25 16:29:20.294 [update notice] update solar temp: 0;35.50;29.81
Zitat von: flash91 am 25 Oktober 2016, 21:29:46
Sagt dir die Meldung dazwischen etwas oder deutet die auf einen schlecht eingedrehten Konverter hin?
das könnte schon sein. Dreh doch mal den Log Level etwas hoch, dann kann man eher erkennen, was hier los ist.
Zitat von: john30 am 26 Oktober 2016, 08:49:44
das könnte schon sein. Dreh doch mal den Log Level etwas hoch, dann kann man eher erkennen, was hier los ist.
Passt habe zuerst level debug gewählt und dann auf info reduziert.
Allerdings läufts gerade (wenn auch nicht kontinuierlich) mit den Updates.
Kann dir nochmal debug logs geben wenn das Prob wieder auftritt.
Edit: ganz am Ende tauch wieder
unknown MM cmd auf
Zitat von: flash91 am 26 Oktober 2016, 12:48:54
Passt habe zuerst level debug gewählt und dann auf info reduziert.
Allerdings läufts gerade (wenn auch nicht kontinuierlich) mit den Updates.
Kann dir nochmal debug logs geben wenn das Prob wieder auftritt.
Edit: ganz am Ende tauch wieder unknown MM cmd auf
das scheint immer noch nicht ganz zu passen, oder weißt Du, was für Geräte 07 und 71 sind? Mach doch mal nen fulll scan und poste das info result.
Zitat von: john30 am 27 Oktober 2016, 08:40:01
das scheint immer noch nicht ganz zu passen, oder weißt Du, was für Geräte 07 und 71 sind? Mach doch mal nen fulll scan und poste das info result.
Morgen John,
ja bei 71 handelt es sich um Broadcasts vom Solarmodul SM1 von Wolf. Allerdings verstehe ich nicht warum mehrere Master gefunden werden, da der Raspi direkt mit dem SM1 verbunden ist, das selbst mit nichts anderem außer zwei Temperaturfühlern und einem Dreiwegeventil verbunden ist.
Derzeitige Konfig:
besitze zwei SM1 Module, die
nicht miteinander verbunden sind. Eines steuert das Zusammenspiel von Kollektor mit Speicher (über FTDI1 mit Raspi verbunden) und das zweite (über FTDI2 mit Raspi verbunden) ist Zuständig dafür, dass im Heizkreislauf der Solarspeicher über ein Dreiwegeventil verwendet wird, sofern dessen Temperatur ausreichend ist.
Hab dir im Anhang den Anschlussplan der Betriebsanleitung des Wolf Geräts beigefügt, dessen Beschaltung für FTDI2 folgendermaßen realisiert wurde:
- eBus (direkt zum Raspi)
- Temperatursensor auf SFK (für Vorlauf am Solarspeicher)
- Temperatursensor auf SFS (Sensor am Rücklauf der Heizung)
- Stromsteuerung des Dreiwegeventils über SKP
- Schließlich noch die Versorgung des SM1-Moduls selbst
(Anleitung unter www.wolf-heiztechnik.de/fileadmin/content/Downloads/Montage-Bedienungsanleitungen/Regelungen/3061592_201605_SM1_Solarmodul_WRS_Montage-und_Bedienungsanleitung.pdf (http://www.wolf-heiztechnik.de/fileadmin/content/Downloads/Montage-Bedienungsanleitungen/Regelungen/3061592_201605_SM1_Solarmodul_WRS_Montage-und_Bedienungsanleitung.pdf))
Mich interessiert eigentlich nur der Broadcast des SM1 mit den zwei Temperaturwerten, weshalb ich auch nur die
50.csv von dir verwende, mit der Abwandlung, dass bei type nicht
w sondern
u1 drin steht.
https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/wolf/50.csv (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/wolf/50.csv)
Edit: Achja und
_templates.csv,
broadcast.csv und
memory.csv von
https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.x.x/de)
liegen auch noch in
/etc/ebusdEin FullScan hätte würde ja nur was bringen, wenn entsprechende CSVs für WOLF vorhanden wären und wenn mehr als das SM1 am ebus hängt oder?
BG
Edit2:
Konnte noch folgendes finden:
https://github.com/csowada/openhab-bindings/blob/master/documents/ebus-develop.md (https://github.com/csowada/openhab-bindings/blob/master/documents/ebus-develop.md)
https://github.com/csowada/openhab-bindings/blob/master/org.openhab.binding.ebus/src/META-INF/wolf-configuration.json (https://github.com/csowada/openhab-bindings/blob/master/org.openhab.binding.ebus/src/META-INF/wolf-configuration.json)
wobei aber nirgends die Startkombination
07 71 50 23 ... beschrieben wird.
Zitat von: flash91 am 28 Oktober 2016, 06:36:08
ja bei 71 handelt es sich um Broadcasts vom Solarmodul SM1 von Wolf. Allerdings verstehe ich nicht warum mehrere Master gefunden werden, da der Raspi direkt mit dem SM1 verbunden ist, das selbst mit nichts anderem außer zwei Temperaturfühlern und einem Dreiwegeventil verbunden ist.
ja das ist eben die Frage.
Zitat von: flash91 am 28 Oktober 2016, 06:36:08
Ein FullScan hätte würde ja nur was bringen, wenn entsprechende CSVs für WOLF vorhanden wären und wenn mehr als das SM1 am ebus hängt oder?
nein, das hat mit den CSVs zunächst nichts zu tun. der full scan macht sozusagen nur Inventur vom Bus.
Zitat von: john30 am 28 Oktober 2016, 08:08:37
nein, das hat mit den CSVs zunächst nichts zu tun. der full scan macht sozusagen nur Inventur vom Bus.
Achso, dann noch eine Frage
wird bei full scan auf den Bus geschrieben, also eine Identifikationsanfrage gesendet, bzw. könnte das problematisch werden, wenn ebusd mit der Konfig "readonly" gestartet wird?
Etwas mühsam ist auch, dass der dritte Master nur alle heiligen Zeiten registriert wird nach einem Neustart...
Raspi gerade gestartet und bisher erhalte ich:
$ ebusctl -p 5002 info
version: ebusd 2.2.af6e1c1
signal: acquired
symbol rate: 20
masters: 2
messages: 14
address 31: master #8, ebusd
address 36: slave #8
address 71: master #9
$ ebusctl -p 5002 scan full
done
$ ebusctl -p 5002 scan result
empty
Nie wieder Poti einstellen !
Nachdem ich tagelang einen Fehler gesucht habe und sich danach herausgestellt hat, dass bloß das Potentiometer nicht richtig eingestellt war (obwohl ich mich an die Einstellanleitung im WIKI genau gehalten habe) habe ich mich ein wenig mit der gegenwärtigen Schaltung auseinandergesetzt. Primär war da die Frage, wieso Vaillant, der ja mit seiner Hardware auch am Bus spricht, nicht alle 2 Wochen ausrücken muss um beim Kunden ein Potentiometer nachzujustieren. Die Antwort lag auf der Hand: es gibt bei den Vaillant-Schaltungen kein Potentiometer.
Ich möchte gleich vorausschicken dass ich hier niemanden kritisieren will. Ganz im Gegenteil, das ist eine fantastische Arbeit die hier von allen geleistet wurde und ich bin schließlich auch ein Nutznießer davon. Vielen Dank dafür. Ich möchte das Folgende einfach als Anregung einbringen, aber auch erklären, warum es so ist wie es ist.
Ich fange einmal mit dem Problem der gegenwärtigen Schaltung (http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)) an:
Die eBus Spezifikation sieht für die beiden Pegel Low und High vor:
Low = 8,0 bis 10,0 Volt, High = 15,0 bis 24,0 Volt.
Das heißt, im schlechtesten Fall haben wir einen Bereich von 10V bis 15V der den Unterschied von Low zu High ausmacht.
Dieses Signal wird nun über den CNY17 Optokoppler ,,analog" übertragen. Vom CNY17 gibt es vier ,,Versionen" (-1, -2, -3 und -4) welche sich alleine in der Übertragungsrate IC/IF im Bereich zwischen 13% und 90% bewegen können. Welcher Typ hier verwendet werden soll, wurde nicht angegeben. Wegen dieses Verhältnisses ergibt sich für die Spannungsdifferenz zwischen Low und High am Eingang 2 des 4011 C-Mos Gatters:
Maximum = 15-10 * 90% = 4,5V; Minimum = 15-10 * 13% = 0,65V
Die Spezifikation des 4011 sieht aber bei dieser Versorgungsspannung (5V) typisch vor:
Low Level Input Voltage = 2V; High Level Input Voltage = 3V.
Worst case sogar 1,5 / 3,5 Volt. Alles dazwischen ist undefiniert, der CD4011 kann dann am Ausgang beliebiges produzieren. Die von PAH angegebene Spannung für High = 2,57V liegt aber in jedem Fall außerhalb des erlaubten Bereichs. Es ist also selbst bei optimal eingestelltem Poti möglich, dass es wegen der Verletzung der Spezifikationen zu Fehlfunktionen kommt. Insbesondere ist es auch möglich dass wegen der Temperaturabhängigkeit der Bauteile Verschiebungen während des Betriebs eintreten.
Die im Forum immer wieder aufgestellte Behauptung, die Leitungslänge des eBus habe einen Einfluss, kann ich keinesfalls nachvollziehen. Diese könnte bestenfalls auf die Signalform Einfluss haben, nicht aber auf die Spannungen. Hier geht es ausschließlich um Bauteil-Toleranzen und die Einhaltung der Spezifikationen.
Die Lösung für alle diese Probleme lautet ,,Comparator" (siehe: comparator_pah.jpg). Und zwar bereits so nahe wie möglich am Eingangssignal. Nebenbei bemerkt ist das auch die Lösung die Vaillant in seinen Geräten einsetzt.
Zuerst wird das Eingangssignal über einen Spannungsteiler R4/R5 heruntergeteilt: Aus High=15V wird 3,19V und aus Low=12V wird 2,55V. Das passt nun zur Weiterverarbeitung in einem System mit 5V Versorgung, wobei die 5V auch gleichzeitig als Referenzspannung dienen. Der Comparator ist ein ,,invertierender Comparator mit Hysterese" (Schmitt-Trigger). Das bringt diverse Vorteile bei der Bemessung der Bauteile und wegen der Hysterese auch eine Sicherheit gegen Störungen auf der Datenleitung. Die Werte von R1, R2 und R3 ergeben sich aus den Standard Formeln. Da der Ausgang üblicherweise ein Open-Collector ist, benötigt er einen Pull-Up-Widerstand. Dieser sollte klein gegenüber den Widerständen R1 R2 und R3 sein, da er sonst das Rechenergebnis verfälscht. Mit diesen Werten ergibt sich nun: Der Comparator schaltet auf Low, wenn der Eingang über 3,06V geht, und er schaltet auf High, wenn er unter 2,75V geht. Da der Comparator invertiert, wird ihm ein einfacher Inverter mit einem Transistor nachgeschaltet.
Die Wahl des Comparators ist relativ unkritisch. Ich habe hier einen LM311 gewählt, weil er gerade zur Hand war. Es können sowohl bipolare Typen als auch CMOS verwendet werden. Wenn ein Comparator mit Push-Pull Ausgang Verwendung findet, müsste man allerdings die Beschaltung in Richtung Transistor anpassen.
Ab diesem Zeitpunkt ist das Signal rein digital. Es spielt also keine Rolle mehr, welcher Klasse der CNY17 angehört, oder in welcher Position das Poti steht !! Alle kritischen Pegel wurden bereits am Comparator behandelt..
Diese Schaltung kostet ein paar Cent und kann auf einfache Weise nachgerüstet werden. Sie kann ,,statt" des 3k3 Widerstandes R1 in den Signalpfad eingefügt werden, also R1 auslöten und den Eingang (,,IN") an den Brückengleichrichter ,,+" anschließen und den Ausgang (,,OUT") an den CNY17. Wegen der für diesen Zweck etwas unglücklichen Beschaltung des CNY17 muss hier mit einem PNP Transistor etwas ,,getrickst" werden (Q1 / R7 / R8). Bei einem Neu-Design könnte man entsprechend direkter vorgehen. Die Versorgung 0 / +5V kann am 78L05 abgegriffen werden.
Ich habe diese Schaltung selbst auf einer Lochraster Platine aufgebaut, allerdings nicht in dieser Variante mit dem PNP Transistor am Ausgang sondern mit einer NPN Transistor (siehe weiter unten). Ich habe mir nämlich den ,,kommerziellen" eBus USB Koppler von e-Service geleistet. Eigentlich hauptsächlich weil der schon ein Hutschienen Gehäuse hat, welches ich benötige. Da dann aber dort auch ein Potentiometer zum Einstellen vorhanden war, sah ich mich veranlasst, mir auch diese Schaltung genauer anzusehen. So sieht sie aus:
(EService_Schaltung.jpg)
Der Spannungsteiler R1/R2/R3 teilt je nach Poti Einstellung von 21:1 bis 21:11. Somit ergibt sich schon einmal bei einer maximalen Eingangsspannung von 24V und voll aufgedrehtem Poti eine Spannung von 12,5V am Eingang des 4011. Weit über dessen Versorgungsspannung und eigentlich der Tod des 4011. Nicht gerade die feine Art...
Steht das Poti ,,optimal", d.h. wenn sich 12,5V Eingangsspannung auf 2,5V am 4011 abbilden, dann muss es (zusammen mit dem 1k Vorwiderstand) 4k2 haben. Bei dieser Stellung ergibt sich:
Low = 10*4,2/21 = 2V und High = 15*4,2/21 = 3V
was zwar gerade noch den typischen Werten des 4011 entspricht, aber nicht den Worst Case Werten (1,5 / 3,5) und es setzt voraus dass das Poti um keinen Mikrometer falsch steht. Also insgesamt gesehen hätten hier zwei Festwiderstände mit den richtigen Werten einen besseren Dienst getan...
Jedenfalls bringt auch hier der Einsatz eines Comparators die Lösung aller Eingangs-Probleme. Die Schaltung muss allerdings am Ausgangs-Inverter etwas anders aussehen, um in den bestehenden e-Service Koppler integriert werden zu können (Comparator_eService.jpg). Auch hier würde man bei einer Neukonstruktion ein paar sinnlos gewordene Inverter einsparen können.
Noch eine Bemerkung zur Spannungsversorgung. Beim e-Service Konverter ist der 5-Volt-Regler nicht direkt an ,,+" des Brückengleichrichters angeschlossen. Warum ? Im schlechtesten Fall (Low am Bus) bleiben dem Regler 8-5 = 3 Volt zum Regeln was schon ziemlich nahe an den minimalen 2V liegt. Ein 10uF Kondensator (C1) dient hier als Ladungsspeicher und integriert die Spannung auf. Ein 100Ohm Widerstand begrenzt den Strom in den Kondensator und dient außerdem als Tiefpass-Filter. Die Diode D2 ist notwendig, damit der Kondensator nicht wieder über den Darlington-Transistor T1 entladen wird. Das macht Sinn weil somit die Eingangsspannung am 5V-Regler permanent höher und auch ,,glatter" ist. Eine derartige Ergänzung würde sicherlich auch der Schaltung von PAH guttun.
Also mit diesem Comparator am Eingang läuft mein Interface jetzt problemlos, OHNE irgendeine Einstellung vorgenommen zu haben. Alle Geräte am Bus wurden problemlos gefunden, was ja vorher nicht der Fall war. Ein Foto vom Umbau habe ich noch angefügt (eservice_mod.jpg). Vielleicht hilft das ja dem einen oder anderen seine Empfangs-Probleme zu beheben.
LG
Eduard
Zitat von: flash91 am 28 Oktober 2016, 09:35:52
wird bei full scan auf den Bus geschrieben, also eine Identifikationsanfrage gesendet, bzw. könnte das problematisch werden, wenn ebusd mit der Konfig "readonly" gestartet wird?
naja, ohne die Möglichkeit, auf den Bus Telegramme zu senden, gibts natürlich keine aktive Abfrage von irgendwas. D.h. alles was Du am ebus siehst, wurde von einem anderen Gerät initiiert.
Zitat von: flash91 am 28 Oktober 2016, 09:35:52
Etwas mühsam ist auch, dass der dritte Master nur alle heiligen Zeiten registriert wird nach einem Neustart...
Im readonly Modus ziemlich logisch...
Zitat von: galileo am 28 Oktober 2016, 19:06:32
Nie wieder Poti einstellen !
Gute Arbeit! Als nur mittelprächtiger Elektroniker kann ich das nicht validieren, aber es klingt zumindest schlüssig. D.h. wir könnten Interface 2.0 designen :-) Gut dass jetzt die "stade" Zeit kommt...
Zitat von: de.jt am 24 Oktober 2016, 18:05:33
hier das Logfile:
Danke für das Logfile.
Mit welchen Parametern sstartest Du denn ebusd?
Zitat von: john30 am 29 Oktober 2016, 14:56:30
Danke für das Logfile.
Mit welchen Parametern sstartest Du denn ebusd?
Hallo John,
Ich starte mit: service ebusd start --scanconfig
Die /etc/default/ebusd ist original und unverändert:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
Ich habe nun in 08.bai.csv direkt hinter das Fallback für HW7401 die 0010003886.inc eingetragen. Damit funktioniert es erst einmal.
#fallbacks:,,,,
[HW=6701]!load,bai.0010003886.inc,,,
[HW=0902]!load,bai.0010004121.inc,,,
[HW=8801]!load,bai.0010006101.inc,,,
[HW=0702]!load,bai.0010010674.inc,,,
[HW=8701]!load,bai.0020066007.inc,,,
#[HW=7401]!load,bai.308523.inc,,,
[HW=7401]!load,bai.0010003886.inc,,,!load,bai.308523.inc,,,
!include,hcmode.inc,,,
Zitat von: john30 am 29 Oktober 2016, 10:04:15
naja, ohne die Möglichkeit, auf den Bus Telegramme zu senden, gibts natürlich keine aktive Abfrage von irgendwas. D.h. alles was Du am ebus siehst, wurde von einem anderen Gerät initiiert.
Hi John,
sorry hat jetzt etwas länger gedauert.
hier der fullscan von ftdi1:
ebusd -f --device=/dev/ftdi1 --localhost --port=5001
2016-10-30 21:10:33.881 [main notice] ebusd 2.2.af6e1c1 started
2016-10-30 21:10:33.893 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-30 21:10:33.999 [bus notice] signal acquired
2016-10-30 21:10:36.698 [bus notice] new master 71, master count 2
2016-10-30 21:10:36.699 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-30 21:10:46.123 [bus notice] scan 02 timed out (227 slaves left)
2016-10-30 21:10:46.218 [bus notice] scan 04 timed out (226 slaves left)
2016-10-30 21:10:46.312 [bus notice] scan 05 timed out (225 slaves left)
2016-10-30 21:10:46.408 [bus notice] scan 06 timed out (224 slaves left)
2016-10-30 21:10:46.501 [bus notice] scan 08 timed out (223 slaves left)
2016-10-30 21:10:46.595 [bus notice] scan 09 timed out (222 slaves left)
2016-10-30 21:10:46.690 [bus notice] scan 0a timed out (221 slaves left)
2016-10-30 21:10:46.785 [bus notice] scan 0b timed out (220 slaves left)
2016-10-30 21:10:46.876 [bus notice] new master 07, master count 3
2016-10-30 21:10:46.877 [bus error] scan 0c failed (219 slaves left): ERR: invalid position
2016-10-30 21:10:46.877 [bus notice] scan 0c: ;0;
2016-10-30 21:10:47.004 [bus notice] scan 0d timed out (218 slaves left)
2016-10-30 21:10:47.098 [bus notice] scan 0e timed out (217 slaves left)
2016-10-30 21:10:47.193 [bus notice] scan 12 timed out (216 slaves left)
2016-10-30 21:10:47.287 [bus notice] scan 14 timed out (215 slaves left)
2016-10-30 21:10:47.382 [bus notice] scan 15 timed out (214 slaves left)
2016-10-30 21:10:47.478 [bus notice] scan 16 timed out (213 slaves left)
2016-10-30 21:10:47.572 [bus notice] scan 18 timed out (212 slaves left)
2016-10-30 21:10:47.665 [bus notice] scan 19 timed out (211 slaves left)
2016-10-30 21:10:47.761 [bus notice] scan 1a timed out (210 slaves left)
2016-10-30 21:10:47.855 [bus notice] scan 1b timed out (209 slaves left)
2016-10-30 21:10:47.948 [bus notice] scan 1c timed out (208 slaves left)
2016-10-30 21:10:48.044 [bus notice] scan 1d timed out (207 slaves left)
2016-10-30 21:10:48.139 [bus notice] scan 1e timed out (206 slaves left)
2016-10-30 21:10:48.234 [bus notice] scan 20 timed out (205 slaves left)
2016-10-30 21:10:48.328 [bus notice] scan 21 timed out (204 slaves left)
2016-10-30 21:10:48.422 [bus notice] scan 22 timed out (203 slaves left)
2016-10-30 21:10:48.516 [bus notice] scan 23 timed out (202 slaves left)
2016-10-30 21:10:48.612 [bus notice] scan 24 timed out (201 slaves left)
2016-10-30 21:10:48.705 [bus notice] scan 25 timed out (200 slaves left)
2016-10-30 21:10:48.800 [bus notice] scan 26 timed out (199 slaves left)
2016-10-30 21:10:48.897 [bus notice] scan 27 timed out (198 slaves left)
2016-10-30 21:10:48.990 [bus notice] scan 28 timed out (197 slaves left)
2016-10-30 21:10:49.084 [bus notice] scan 29 timed out (196 slaves left)
2016-10-30 21:10:49.179 [bus notice] scan 2a timed out (195 slaves left)
2016-10-30 21:10:49.273 [bus notice] scan 2b timed out (194 slaves left)
2016-10-30 21:10:49.367 [bus notice] scan 2c timed out (193 slaves left)
2016-10-30 21:10:49.463 [bus notice] scan 2d timed out (192 slaves left)
2016-10-30 21:10:49.558 [bus notice] scan 2e timed out (191 slaves left)
2016-10-30 21:10:49.652 [bus notice] scan 2f timed out (190 slaves left)
2016-10-30 21:10:49.745 [bus notice] scan 32 timed out (189 slaves left)
2016-10-30 21:10:49.841 [bus notice] scan 34 timed out (188 slaves left)
2016-10-30 21:10:49.934 [bus notice] scan 35 timed out (187 slaves left)
2016-10-30 21:10:50.030 [bus notice] scan 36 timed out (186 slaves left)
2016-10-30 21:10:50.124 [bus notice] scan 38 timed out (185 slaves left)
2016-10-30 21:10:50.219 [bus notice] scan 39 timed out (184 slaves left)
2016-10-30 21:10:50.313 [bus notice] scan 3a timed out (183 slaves left)
2016-10-30 21:10:50.412 [bus notice] scan 3b timed out (182 slaves left)
2016-10-30 21:10:50.508 [bus notice] scan 3c timed out (181 slaves left)
2016-10-30 21:10:50.602 [bus notice] scan 3d timed out (180 slaves left)
2016-10-30 21:10:50.698 [bus notice] scan 3e timed out (179 slaves left)
2016-10-30 21:10:50.791 [bus notice] scan 40 timed out (178 slaves left)
2016-10-30 21:10:50.885 [bus notice] scan 41 timed out (177 slaves left)
2016-10-30 21:10:50.981 [bus notice] scan 42 timed out (176 slaves left)
2016-10-30 21:10:51.075 [bus notice] scan 43 timed out (175 slaves left)
2016-10-30 21:10:51.169 [bus notice] scan 44 timed out (174 slaves left)
2016-10-30 21:10:51.264 [bus notice] scan 45 timed out (173 slaves left)
2016-10-30 21:10:51.359 [bus notice] scan 46 timed out (172 slaves left)
2016-10-30 21:10:51.453 [bus notice] scan 47 timed out (171 slaves left)
2016-10-30 21:10:51.548 [bus notice] scan 48 timed out (170 slaves left)
2016-10-30 21:10:51.642 [bus notice] scan 49 timed out (169 slaves left)
2016-10-30 21:10:51.676 [bus error] scan 4a failed (168 slaves left): ERR: invalid argument
2016-10-30 21:10:51.800 [bus error] scan 4b failed (167 slaves left): ERR: invalid argument
2016-10-30 21:10:51.865 [bus error] scan 4c failed (166 slaves left): ERR: invalid argument
2016-10-30 21:10:51.989 [bus error] scan 4d failed (165 slaves left): ERR: invalid argument
2016-10-30 21:10:52.055 [bus error] scan 4e failed (164 slaves left): ERR: invalid argument
2016-10-30 21:10:52.299 [bus error] scan 4f failed (163 slaves left): ERR: invalid argument
2016-10-30 21:10:52.617 [bus notice] scan 50 timed out (162 slaves left)
2016-10-30 21:10:52.712 [bus notice] scan 51 timed out (161 slaves left)
2016-10-30 21:10:52.807 [bus notice] scan 52 timed out (160 slaves left)
2016-10-30 21:10:52.901 [bus notice] scan 53 timed out (159 slaves left)
2016-10-30 21:10:52.996 [bus notice] scan 54 timed out (158 slaves left)
2016-10-30 21:10:53.090 [bus notice] scan 55 timed out (157 slaves left)
2016-10-30 21:10:53.185 [bus notice] scan 56 timed out (156 slaves left)
2016-10-30 21:10:53.280 [bus notice] scan 57 timed out (155 slaves left)
2016-10-30 21:10:53.374 [bus notice] scan 58 timed out (154 slaves left)
2016-10-30 21:10:53.469 [bus notice] scan 59 timed out (153 slaves left)
2016-10-30 21:10:53.562 [bus notice] scan 5a timed out (152 slaves left)
2016-10-30 21:10:53.658 [bus notice] scan 5b timed out (151 slaves left)
2016-10-30 21:10:53.752 [bus notice] scan 5c timed out (150 slaves left)
2016-10-30 21:10:53.846 [bus notice] scan 5d timed out (149 slaves left)
2016-10-30 21:10:53.940 [bus notice] scan 5e timed out (148 slaves left)
2016-10-30 21:10:54.036 [bus notice] scan 5f timed out (147 slaves left)
2016-10-30 21:10:54.130 [bus notice] scan 60 timed out (146 slaves left)
2016-10-30 21:10:54.225 [bus notice] scan 61 timed out (145 slaves left)
2016-10-30 21:10:54.319 [bus notice] scan 62 timed out (144 slaves left)
2016-10-30 21:10:54.414 [bus notice] scan 63 timed out (143 slaves left)
2016-10-30 21:10:54.509 [bus notice] scan 64 timed out (142 slaves left)
2016-10-30 21:10:54.604 [bus notice] scan 65 timed out (141 slaves left)
2016-10-30 21:10:54.698 [bus notice] scan 66 timed out (140 slaves left)
2016-10-30 21:10:54.792 [bus notice] scan 67 timed out (139 slaves left)
2016-10-30 21:10:54.886 [bus notice] scan 68 timed out (138 slaves left)
2016-10-30 21:10:54.981 [bus notice] scan 69 timed out (137 slaves left)
2016-10-30 21:10:55.075 [bus notice] scan 6a timed out (136 slaves left)
2016-10-30 21:10:55.171 [bus notice] scan 6b timed out (135 slaves left)
2016-10-30 21:10:55.265 [bus notice] scan 6c timed out (134 slaves left)
2016-10-30 21:10:55.359 [bus notice] scan 6d timed out (133 slaves left)
2016-10-30 21:10:55.454 [bus notice] scan 6e timed out (132 slaves left)
2016-10-30 21:10:55.549 [bus notice] scan 6f timed out (131 slaves left)
2016-10-30 21:10:55.643 [bus notice] scan 72 timed out (130 slaves left)
2016-10-30 21:10:55.738 [bus notice] scan 74 timed out (129 slaves left)
2016-10-30 21:10:55.832 [bus notice] scan 75 timed out (128 slaves left)
2016-10-30 21:10:55.969 [bus notice] scan 76 completed (127 slaves left)
2016-10-30 21:10:55.970 [bus notice] scan 76: ;Kromschroeder; ;0227;-
2016-10-30 21:10:56.096 [bus notice] scan 78 timed out (126 slaves left)
2016-10-30 21:10:56.190 [bus notice] scan 79 timed out (125 slaves left)
2016-10-30 21:10:56.285 [bus notice] scan 7a timed out (124 slaves left)
2016-10-30 21:10:56.380 [bus notice] scan 7b timed out (123 slaves left)
2016-10-30 21:10:56.474 [bus notice] scan 7c timed out (122 slaves left)
2016-10-30 21:10:56.568 [bus notice] scan 7d timed out (121 slaves left)
2016-10-30 21:10:56.663 [bus notice] scan 7e timed out (120 slaves left)
2016-10-30 21:10:56.757 [bus notice] scan 80 timed out (119 slaves left)
2016-10-30 21:10:56.853 [bus notice] scan 81 timed out (118 slaves left)
2016-10-30 21:10:56.947 [bus notice] scan 82 timed out (117 slaves left)
2016-10-30 21:10:57.042 [bus notice] scan 83 timed out (116 slaves left)
2016-10-30 21:10:57.136 [bus notice] scan 84 timed out (115 slaves left)
2016-10-30 21:10:57.231 [bus notice] scan 85 timed out (114 slaves left)
2016-10-30 21:10:57.326 [bus notice] scan 86 timed out (113 slaves left)
2016-10-30 21:10:57.420 [bus notice] scan 87 timed out (112 slaves left)
2016-10-30 21:10:57.513 [bus notice] scan 88 timed out (111 slaves left)
2016-10-30 21:10:57.608 [bus notice] scan 89 timed out (110 slaves left)
2016-10-30 21:10:57.703 [bus notice] scan 8a timed out (109 slaves left)
2016-10-30 21:10:57.798 [bus notice] scan 8b timed out (108 slaves left)
2016-10-30 21:10:57.893 [bus notice] scan 8c timed out (107 slaves left)
2016-10-30 21:10:57.986 [bus notice] scan 8d timed out (106 slaves left)
2016-10-30 21:10:58.082 [bus notice] scan 8e timed out (105 slaves left)
2016-10-30 21:10:58.176 [bus notice] scan 8f timed out (104 slaves left)
2016-10-30 21:10:58.271 [bus notice] scan 90 timed out (103 slaves left)
2016-10-30 21:10:58.365 [bus notice] scan 91 timed out (102 slaves left)
2016-10-30 21:10:58.460 [bus notice] scan 92 timed out (101 slaves left)
2016-10-30 21:10:58.554 [bus notice] scan 93 timed out (100 slaves left)
2016-10-30 21:10:58.878 [bus notice] scan 94 timed out (99 slaves left)
2016-10-30 21:10:58.972 [bus notice] scan 95 timed out (98 slaves left)
2016-10-30 21:10:59.067 [bus notice] scan 96 timed out (97 slaves left)
2016-10-30 21:10:59.161 [bus notice] scan 97 timed out (96 slaves left)
2016-10-30 21:10:59.256 [bus notice] scan 98 timed out (95 slaves left)
2016-10-30 21:10:59.350 [bus notice] scan 99 timed out (94 slaves left)
2016-10-30 21:10:59.445 [bus notice] scan 9a timed out (93 slaves left)
2016-10-30 21:10:59.540 [bus notice] scan 9b timed out (92 slaves left)
2016-10-30 21:10:59.634 [bus notice] scan 9c timed out (91 slaves left)
2016-10-30 21:10:59.730 [bus notice] scan 9d timed out (90 slaves left)
2016-10-30 21:10:59.824 [bus notice] scan 9e timed out (89 slaves left)
2016-10-30 21:10:59.918 [bus notice] scan 9f timed out (88 slaves left)
2016-10-30 21:11:00.012 [bus notice] scan a0 timed out (87 slaves left)
2016-10-30 21:11:00.107 [bus notice] scan a1 timed out (86 slaves left)
2016-10-30 21:11:00.202 [bus notice] scan a2 timed out (85 slaves left)
2016-10-30 21:11:00.297 [bus notice] scan a3 timed out (84 slaves left)
2016-10-30 21:11:00.391 [bus notice] scan a4 timed out (83 slaves left)
2016-10-30 21:11:00.485 [bus notice] scan a5 timed out (82 slaves left)
2016-10-30 21:11:00.580 [bus notice] scan a6 timed out (81 slaves left)
2016-10-30 21:11:00.674 [bus notice] scan a7 timed out (80 slaves left)
2016-10-30 21:11:00.769 [bus notice] scan a8 timed out (79 slaves left)
2016-10-30 21:11:00.863 [bus notice] scan ab timed out (78 slaves left)
2016-10-30 21:11:00.958 [bus notice] scan ac timed out (77 slaves left)
2016-10-30 21:11:01.052 [bus notice] scan ad timed out (76 slaves left)
2016-10-30 21:11:01.147 [bus notice] scan ae timed out (75 slaves left)
2016-10-30 21:11:01.241 [bus notice] scan af timed out (74 slaves left)
2016-10-30 21:11:01.337 [bus notice] scan b0 timed out (73 slaves left)
2016-10-30 21:11:01.431 [bus notice] scan b1 timed out (72 slaves left)
2016-10-30 21:11:01.525 [bus notice] scan b2 timed out (71 slaves left)
2016-10-30 21:11:01.620 [bus notice] scan b3 timed out (70 slaves left)
2016-10-30 21:11:01.714 [bus notice] scan b4 timed out (69 slaves left)
2016-10-30 21:11:01.809 [bus notice] scan b5 timed out (68 slaves left)
2016-10-30 21:11:01.903 [bus notice] scan b6 timed out (67 slaves left)
2016-10-30 21:11:01.998 [bus notice] scan b7 timed out (66 slaves left)
2016-10-30 21:11:02.093 [bus notice] scan b8 timed out (65 slaves left)
2016-10-30 21:11:02.188 [bus notice] scan b9 timed out (64 slaves left)
2016-10-30 21:11:02.282 [bus notice] scan ba timed out (63 slaves left)
2016-10-30 21:11:02.377 [bus notice] scan bb timed out (62 slaves left)
2016-10-30 21:11:02.470 [bus notice] scan bc timed out (61 slaves left)
2016-10-30 21:11:02.566 [bus notice] scan bd timed out (60 slaves left)
2016-10-30 21:11:02.660 [bus notice] scan be timed out (59 slaves left)
2016-10-30 21:11:02.755 [bus notice] scan bf timed out (58 slaves left)
2016-10-30 21:11:02.849 [bus notice] scan c0 timed out (57 slaves left)
2016-10-30 21:11:02.944 [bus notice] scan c1 timed out (56 slaves left)
2016-10-30 21:11:03.037 [bus notice] scan c2 timed out (55 slaves left)
2016-10-30 21:11:03.133 [bus notice] scan c3 timed out (54 slaves left)
2016-10-30 21:11:03.227 [bus notice] scan c4 timed out (53 slaves left)
2016-10-30 21:11:03.322 [bus notice] scan c5 timed out (52 slaves left)
2016-10-30 21:11:03.416 [bus notice] scan c6 timed out (51 slaves left)
2016-10-30 21:11:03.512 [bus notice] scan c7 timed out (50 slaves left)
2016-10-30 21:11:03.606 [bus notice] scan c8 timed out (49 slaves left)
2016-10-30 21:11:03.700 [bus notice] scan c9 timed out (48 slaves left)
2016-10-30 21:11:03.795 [bus notice] scan ca timed out (47 slaves left)
2016-10-30 21:11:03.889 [bus notice] scan cb timed out (46 slaves left)
2016-10-30 21:11:03.983 [bus notice] scan cc timed out (45 slaves left)
2016-10-30 21:11:04.078 [bus notice] scan cd timed out (44 slaves left)
2016-10-30 21:11:04.174 [bus notice] scan ce timed out (43 slaves left)
2016-10-30 21:11:04.268 [bus notice] scan cf timed out (42 slaves left)
2016-10-30 21:11:04.362 [bus notice] scan d0 timed out (41 slaves left)
2016-10-30 21:11:04.456 [bus notice] scan d1 timed out (40 slaves left)
2016-10-30 21:11:04.551 [bus notice] scan d2 timed out (39 slaves left)
2016-10-30 21:11:04.646 [bus notice] scan d3 timed out (38 slaves left)
2016-10-30 21:11:04.740 [bus notice] scan d4 timed out (37 slaves left)
2016-10-30 21:11:04.835 [bus notice] scan d5 timed out (36 slaves left)
2016-10-30 21:11:04.929 [bus notice] scan d6 timed out (35 slaves left)
2016-10-30 21:11:05.024 [bus notice] scan d7 timed out (34 slaves left)
2016-10-30 21:11:05.119 [bus notice] scan d8 timed out (33 slaves left)
2016-10-30 21:11:05.213 [bus notice] scan d9 timed out (32 slaves left)
2016-10-30 21:11:05.308 [bus notice] scan da timed out (31 slaves left)
2016-10-30 21:11:05.402 [bus notice] scan db timed out (30 slaves left)
2016-10-30 21:11:05.496 [bus notice] scan dc timed out (29 slaves left)
2016-10-30 21:11:05.591 [bus notice] scan dd timed out (28 slaves left)
2016-10-30 21:11:05.687 [bus notice] scan de timed out (27 slaves left)
2016-10-30 21:11:05.781 [bus notice] scan df timed out (26 slaves left)
2016-10-30 21:11:05.874 [bus notice] scan e0 timed out (25 slaves left)
2016-10-30 21:11:05.969 [bus notice] scan e1 timed out (24 slaves left)
2016-10-30 21:11:06.063 [bus notice] scan e2 timed out (23 slaves left)
2016-10-30 21:11:06.158 [bus notice] scan e3 timed out (22 slaves left)
2016-10-30 21:11:06.254 [bus notice] scan e4 timed out (21 slaves left)
2016-10-30 21:11:06.348 [bus notice] scan e5 timed out (20 slaves left)
2016-10-30 21:11:06.442 [bus notice] scan e6 timed out (19 slaves left)
2016-10-30 21:11:06.537 [bus notice] scan e7 timed out (18 slaves left)
2016-10-30 21:11:06.691 [bus error] scan e8 failed (17 slaves left): ERR: invalid argument
2016-10-30 21:11:06.995 [bus notice] scan e9 timed out (16 slaves left)
2016-10-30 21:11:07.088 [bus notice] scan ea timed out (15 slaves left)
2016-10-30 21:11:07.184 [bus notice] scan eb timed out (14 slaves left)
2016-10-30 21:11:07.278 [bus notice] scan ec timed out (13 slaves left)
2016-10-30 21:11:07.373 [bus notice] scan ed timed out (12 slaves left)
2016-10-30 21:11:07.467 [bus notice] scan ee timed out (11 slaves left)
2016-10-30 21:11:07.561 [bus notice] scan ef timed out (10 slaves left)
2016-10-30 21:11:07.663 [bus notice] scan f2 timed out (9 slaves left)
2016-10-30 21:11:07.756 [bus notice] scan f4 timed out (8 slaves left)
2016-10-30 21:11:07.850 [bus notice] scan f5 timed out (7 slaves left)
2016-10-30 21:11:07.945 [bus notice] scan f6 timed out (6 slaves left)
2016-10-30 21:11:08.040 [bus notice] scan f8 timed out (5 slaves left)
2016-10-30 21:11:08.134 [bus notice] scan f9 timed out (4 slaves left)
2016-10-30 21:11:08.228 [bus notice] scan fa timed out (3 slaves left)
2016-10-30 21:11:08.330 [bus notice] scan fb timed out (2 slaves left)
2016-10-30 21:11:08.423 [bus notice] scan fc timed out (1 slaves left)
2016-10-30 21:11:08.516 [bus notice] scan fd timed out (0 slaves left)
2016-10-30 21:11:08.517 [bus notice] scan finished
2016-10-30 21:11:21.425 [update notice] update solar temp: 0;5.00;39.81
ebusctl -p 5001 scan result
0c;0;
76;Kromschroeder; ;0227;-
von ftdi2
ebusd -f --device=/dev/ftdi2 --localhost --port=5002
2016-10-30 21:05:40.030 [main notice] ebusd 2.2.af6e1c1 started
2016-10-30 21:05:40.042 [main notice] found messages: 14 (0 conditional on 0 conditions, 0 poll, 7 update)
2016-10-30 21:05:40.062 [bus notice] signal acquired
2016-10-30 21:05:46.811 [bus notice] new master 71, master count 2
2016-10-30 21:05:46.812 [update notice] update solar temp: 0;40.19;30.38
2016-10-30 21:06:01.735 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-30 21:06:14.426 [bus notice] scan 02 timed out (227 slaves left)
2016-10-30 21:06:14.519 [bus notice] scan 04 timed out (226 slaves left)
2016-10-30 21:06:14.615 [bus notice] scan 05 timed out (225 slaves left)
2016-10-30 21:06:14.709 [bus notice] scan 06 timed out (224 slaves left)
2016-10-30 21:06:14.803 [bus notice] scan 08 timed out (223 slaves left)
2016-10-30 21:06:14.897 [bus notice] scan 09 timed out (222 slaves left)
2016-10-30 21:06:14.992 [bus notice] scan 0a timed out (221 slaves left)
2016-10-30 21:06:15.085 [bus notice] scan 0b timed out (220 slaves left)
2016-10-30 21:06:15.178 [bus notice] new master 07, master count 3
2016-10-30 21:06:15.178 [bus error] scan 0c failed (219 slaves left): ERR: invalid position
2016-10-30 21:06:15.178 [bus notice] scan 0c: ;0;
2016-10-30 21:06:15.305 [bus notice] scan 0d timed out (218 slaves left)
2016-10-30 21:06:15.399 [bus notice] scan 0e timed out (217 slaves left)
2016-10-30 21:06:15.494 [bus notice] scan 12 timed out (216 slaves left)
2016-10-30 21:06:15.587 [bus notice] scan 14 timed out (215 slaves left)
2016-10-30 21:06:15.682 [bus notice] scan 15 timed out (214 slaves left)
2016-10-30 21:06:15.776 [bus notice] scan 16 timed out (213 slaves left)
2016-10-30 21:06:15.872 [bus notice] scan 18 timed out (212 slaves left)
2016-10-30 21:06:15.966 [bus notice] scan 19 timed out (211 slaves left)
2016-10-30 21:06:16.060 [bus notice] scan 1a timed out (210 slaves left)
2016-10-30 21:06:16.155 [bus notice] scan 1b timed out (209 slaves left)
2016-10-30 21:06:16.249 [bus notice] scan 1c timed out (208 slaves left)
2016-10-30 21:06:16.343 [bus notice] scan 1d timed out (207 slaves left)
2016-10-30 21:06:16.438 [bus notice] scan 1e timed out (206 slaves left)
2016-10-30 21:06:16.532 [bus notice] scan 20 timed out (205 slaves left)
2016-10-30 21:06:16.626 [bus notice] scan 21 timed out (204 slaves left)
2016-10-30 21:06:16.779 [bus error] scan 22 failed (203 slaves left): ERR: invalid argument
2016-10-30 21:06:17.158 [bus notice] scan 23 timed out (202 slaves left)
2016-10-30 21:06:17.252 [bus notice] scan 24 timed out (201 slaves left)
2016-10-30 21:06:17.347 [bus notice] scan 25 timed out (200 slaves left)
2016-10-30 21:06:17.441 [bus notice] scan 26 timed out (199 slaves left)
2016-10-30 21:06:17.537 [bus notice] scan 27 timed out (198 slaves left)
2016-10-30 21:06:17.631 [bus notice] scan 28 timed out (197 slaves left)
2016-10-30 21:06:17.725 [bus notice] scan 29 timed out (196 slaves left)
2016-10-30 21:06:17.819 [bus notice] scan 2a timed out (195 slaves left)
2016-10-30 21:06:17.914 [bus notice] scan 2b timed out (194 slaves left)
2016-10-30 21:06:18.008 [bus notice] scan 2c timed out (193 slaves left)
2016-10-30 21:06:18.101 [bus notice] scan 2d timed out (192 slaves left)
2016-10-30 21:06:18.197 [bus notice] scan 2e timed out (191 slaves left)
2016-10-30 21:06:18.291 [bus notice] scan 2f timed out (190 slaves left)
2016-10-30 21:06:18.385 [bus notice] scan 32 timed out (189 slaves left)
2016-10-30 21:06:18.481 [bus notice] scan 34 timed out (188 slaves left)
2016-10-30 21:06:18.575 [bus notice] scan 35 timed out (187 slaves left)
2016-10-30 21:06:18.668 [bus notice] scan 36 timed out (186 slaves left)
2016-10-30 21:06:18.763 [bus notice] scan 38 timed out (185 slaves left)
2016-10-30 21:06:18.857 [bus notice] scan 39 timed out (184 slaves left)
2016-10-30 21:06:18.953 [bus notice] scan 3a timed out (183 slaves left)
2016-10-30 21:06:19.047 [bus notice] scan 3b timed out (182 slaves left)
2016-10-30 21:06:19.141 [bus notice] scan 3c timed out (181 slaves left)
2016-10-30 21:06:19.234 [bus notice] scan 3d timed out (180 slaves left)
2016-10-30 21:06:19.330 [bus notice] scan 3e timed out (179 slaves left)
2016-10-30 21:06:19.424 [bus notice] scan 40 timed out (178 slaves left)
2016-10-30 21:06:19.518 [bus notice] scan 41 timed out (177 slaves left)
2016-10-30 21:06:19.612 [bus notice] scan 42 timed out (176 slaves left)
2016-10-30 21:06:19.706 [bus notice] scan 43 timed out (175 slaves left)
2016-10-30 21:06:19.802 [bus notice] scan 44 timed out (174 slaves left)
2016-10-30 21:06:19.895 [bus notice] scan 45 timed out (173 slaves left)
2016-10-30 21:06:19.991 [bus notice] scan 46 timed out (172 slaves left)
2016-10-30 21:06:20.084 [bus notice] scan 47 timed out (171 slaves left)
2016-10-30 21:06:20.180 [bus notice] scan 48 timed out (170 slaves left)
2016-10-30 21:06:20.273 [bus notice] scan 49 timed out (169 slaves left)
2016-10-30 21:06:20.368 [bus notice] scan 4a timed out (168 slaves left)
2016-10-30 21:06:20.462 [bus notice] scan 4b timed out (167 slaves left)
2016-10-30 21:06:20.556 [bus notice] scan 4c timed out (166 slaves left)
2016-10-30 21:06:20.651 [bus notice] scan 4d timed out (165 slaves left)
2016-10-30 21:06:20.745 [bus notice] scan 4e timed out (164 slaves left)
2016-10-30 21:06:20.840 [bus notice] scan 4f timed out (163 slaves left)
2016-10-30 21:06:20.934 [bus notice] scan 50 timed out (162 slaves left)
2016-10-30 21:06:21.028 [bus notice] scan 51 timed out (161 slaves left)
2016-10-30 21:06:21.123 [bus notice] scan 52 timed out (160 slaves left)
2016-10-30 21:06:21.218 [bus notice] scan 53 timed out (159 slaves left)
2016-10-30 21:06:21.313 [bus notice] scan 54 timed out (158 slaves left)
2016-10-30 21:06:21.407 [bus notice] scan 55 timed out (157 slaves left)
2016-10-30 21:06:21.501 [bus notice] scan 56 timed out (156 slaves left)
2016-10-30 21:06:21.595 [bus notice] scan 57 timed out (155 slaves left)
2016-10-30 21:06:21.691 [bus notice] scan 58 timed out (154 slaves left)
2016-10-30 21:06:21.785 [bus notice] scan 59 timed out (153 slaves left)
2016-10-30 21:06:21.879 [bus notice] scan 5a timed out (152 slaves left)
2016-10-30 21:06:21.973 [bus notice] scan 5b timed out (151 slaves left)
2016-10-30 21:06:22.067 [bus notice] scan 5c timed out (150 slaves left)
2016-10-30 21:06:22.163 [bus notice] scan 5d timed out (149 slaves left)
2016-10-30 21:06:22.256 [bus notice] scan 5e timed out (148 slaves left)
2016-10-30 21:06:22.351 [bus notice] scan 5f timed out (147 slaves left)
2016-10-30 21:06:22.444 [bus notice] scan 60 timed out (146 slaves left)
2016-10-30 21:06:22.540 [bus notice] scan 61 timed out (145 slaves left)
2016-10-30 21:06:22.633 [bus notice] scan 62 timed out (144 slaves left)
2016-10-30 21:06:22.729 [bus notice] scan 63 timed out (143 slaves left)
2016-10-30 21:06:22.823 [bus notice] scan 64 timed out (142 slaves left)
2016-10-30 21:06:22.918 [bus notice] scan 65 timed out (141 slaves left)
2016-10-30 21:06:23.012 [bus notice] scan 66 timed out (140 slaves left)
2016-10-30 21:06:23.106 [bus notice] scan 67 timed out (139 slaves left)
2016-10-30 21:06:23.200 [bus notice] scan 68 timed out (138 slaves left)
2016-10-30 21:06:23.296 [bus notice] scan 69 timed out (137 slaves left)
2016-10-30 21:06:23.390 [bus notice] scan 6a timed out (136 slaves left)
2016-10-30 21:06:23.483 [bus notice] scan 6b timed out (135 slaves left)
2016-10-30 21:06:23.577 [bus notice] scan 6c timed out (134 slaves left)
2016-10-30 21:06:23.672 [bus error] scan 6d failed (133 slaves left): ERR: invalid argument
2016-10-30 21:06:23.797 [bus error] scan 6e failed (132 slaves left): ERR: invalid argument
2016-10-30 21:06:23.921 [bus error] scan 6f failed (131 slaves left): ERR: invalid argument
2016-10-30 21:06:24.274 [bus notice] scan 72 timed out (130 slaves left)
2016-10-30 21:06:24.368 [bus notice] scan 74 timed out (129 slaves left)
2016-10-30 21:06:24.463 [bus notice] scan 75 timed out (128 slaves left)
2016-10-30 21:06:24.599 [bus notice] scan 76 completed (127 slaves left)
2016-10-30 21:06:24.600 [bus notice] scan 76: ;Kromschroeder; ;0227;-
2016-10-30 21:06:24.726 [bus notice] scan 78 timed out (126 slaves left)
2016-10-30 21:06:24.820 [bus notice] scan 79 timed out (125 slaves left)
2016-10-30 21:06:24.916 [bus notice] scan 7a timed out (124 slaves left)
2016-10-30 21:06:25.008 [bus notice] scan 7b timed out (123 slaves left)
2016-10-30 21:06:25.103 [bus notice] scan 7c timed out (122 slaves left)
2016-10-30 21:06:25.198 [bus notice] scan 7d timed out (121 slaves left)
2016-10-30 21:06:25.293 [bus notice] scan 7e timed out (120 slaves left)
2016-10-30 21:06:25.386 [bus notice] scan 80 timed out (119 slaves left)
2016-10-30 21:06:25.480 [bus notice] scan 81 timed out (118 slaves left)
2016-10-30 21:06:25.576 [bus notice] scan 82 timed out (117 slaves left)
2016-10-30 21:06:25.670 [bus notice] scan 83 timed out (116 slaves left)
2016-10-30 21:06:25.764 [bus notice] scan 84 timed out (115 slaves left)
2016-10-30 21:06:25.859 [bus notice] scan 85 timed out (114 slaves left)
2016-10-30 21:06:25.953 [bus notice] scan 86 timed out (113 slaves left)
2016-10-30 21:06:26.048 [bus notice] scan 87 timed out (112 slaves left)
2016-10-30 21:06:26.142 [bus notice] scan 88 timed out (111 slaves left)
2016-10-30 21:06:26.236 [bus notice] scan 89 timed out (110 slaves left)
2016-10-30 21:06:26.331 [bus notice] scan 8a timed out (109 slaves left)
2016-10-30 21:06:26.425 [bus notice] scan 8b timed out (108 slaves left)
2016-10-30 21:06:26.520 [bus notice] scan 8c timed out (107 slaves left)
2016-10-30 21:06:26.614 [bus notice] scan 8d timed out (106 slaves left)
2016-10-30 21:06:26.708 [bus notice] scan 8e timed out (105 slaves left)
2016-10-30 21:06:26.803 [bus notice] scan 8f timed out (104 slaves left)
2016-10-30 21:06:26.897 [bus notice] scan 90 timed out (103 slaves left)
2016-10-30 21:06:26.991 [bus notice] scan 91 timed out (102 slaves left)
2016-10-30 21:06:27.085 [bus notice] scan 92 timed out (101 slaves left)
2016-10-30 21:06:27.181 [bus notice] scan 93 timed out (100 slaves left)
2016-10-30 21:06:27.275 [bus notice] scan 94 timed out (99 slaves left)
2016-10-30 21:06:27.368 [bus notice] scan 95 timed out (98 slaves left)
2016-10-30 21:06:27.464 [bus notice] scan 96 timed out (97 slaves left)
2016-10-30 21:06:27.557 [bus notice] scan 97 timed out (96 slaves left)
2016-10-30 21:06:27.652 [bus notice] scan 98 timed out (95 slaves left)
2016-10-30 21:06:27.748 [bus notice] scan 99 timed out (94 slaves left)
2016-10-30 21:06:27.842 [bus notice] scan 9a timed out (93 slaves left)
2016-10-30 21:06:27.936 [bus notice] scan 9b timed out (92 slaves left)
2016-10-30 21:06:28.031 [bus notice] scan 9c timed out (91 slaves left)
2016-10-30 21:06:28.124 [bus notice] scan 9d timed out (90 slaves left)
2016-10-30 21:06:28.219 [bus notice] scan 9e timed out (89 slaves left)
2016-10-30 21:06:28.313 [bus notice] scan 9f timed out (88 slaves left)
2016-10-30 21:06:28.407 [bus notice] scan a0 timed out (87 slaves left)
2016-10-30 21:06:28.503 [bus notice] scan a1 timed out (86 slaves left)
2016-10-30 21:06:28.597 [bus notice] scan a2 timed out (85 slaves left)
2016-10-30 21:06:28.690 [bus notice] scan a3 timed out (84 slaves left)
2016-10-30 21:06:28.786 [bus notice] scan a4 timed out (83 slaves left)
2016-10-30 21:06:28.880 [bus notice] scan a5 timed out (82 slaves left)
2016-10-30 21:06:28.974 [bus notice] scan a6 timed out (81 slaves left)
2016-10-30 21:06:29.069 [bus notice] scan a7 timed out (80 slaves left)
2016-10-30 21:06:29.162 [bus notice] scan a8 timed out (79 slaves left)
2016-10-30 21:06:29.257 [bus notice] scan ab timed out (78 slaves left)
2016-10-30 21:06:29.351 [bus notice] scan ac timed out (77 slaves left)
2016-10-30 21:06:29.447 [bus notice] scan ad timed out (76 slaves left)
2016-10-30 21:06:29.541 [bus notice] scan ae timed out (75 slaves left)
2016-10-30 21:06:29.635 [bus notice] scan af timed out (74 slaves left)
2016-10-30 21:06:29.730 [bus notice] scan b0 timed out (73 slaves left)
2016-10-30 21:06:29.824 [bus notice] scan b1 timed out (72 slaves left)
2016-10-30 21:06:29.919 [bus notice] scan b2 timed out (71 slaves left)
2016-10-30 21:06:30.013 [bus notice] scan b3 timed out (70 slaves left)
2016-10-30 21:06:30.107 [bus notice] scan b4 timed out (69 slaves left)
2016-10-30 21:06:30.202 [bus notice] scan b5 timed out (68 slaves left)
2016-10-30 21:06:30.296 [bus notice] scan b6 timed out (67 slaves left)
2016-10-30 21:06:30.390 [bus notice] scan b7 timed out (66 slaves left)
2016-10-30 21:06:30.486 [bus notice] scan b8 timed out (65 slaves left)
2016-10-30 21:06:30.580 [bus notice] scan b9 timed out (64 slaves left)
2016-10-30 21:06:30.673 [bus notice] scan ba timed out (63 slaves left)
2016-10-30 21:06:30.767 [bus notice] scan bb timed out (62 slaves left)
2016-10-30 21:06:30.862 [bus notice] scan bc timed out (61 slaves left)
2016-10-30 21:06:30.957 [bus notice] scan bd timed out (60 slaves left)
2016-10-30 21:06:31.051 [bus notice] scan be timed out (59 slaves left)
2016-10-30 21:06:31.147 [bus notice] scan bf timed out (58 slaves left)
2016-10-30 21:06:31.240 [bus notice] scan c0 timed out (57 slaves left)
2016-10-30 21:06:31.335 [bus notice] scan c1 timed out (56 slaves left)
2016-10-30 21:06:31.429 [bus notice] scan c2 timed out (55 slaves left)
2016-10-30 21:06:31.523 [bus notice] scan c3 timed out (54 slaves left)
2016-10-30 21:06:31.558 [bus error] scan c4 failed (53 slaves left): ERR: invalid argument
2016-10-30 21:06:31.751 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-30 21:06:31.871 [bus notice] scan c5 timed out (52 slaves left)
2016-10-30 21:06:31.965 [bus notice] scan c6 timed out (51 slaves left)
2016-10-30 21:06:32.061 [bus notice] scan c7 timed out (50 slaves left)
2016-10-30 21:06:32.155 [bus notice] scan c8 timed out (49 slaves left)
2016-10-30 21:06:32.248 [bus notice] scan c9 timed out (48 slaves left)
2016-10-30 21:06:32.343 [bus notice] scan ca timed out (47 slaves left)
2016-10-30 21:06:32.438 [bus notice] scan cb timed out (46 slaves left)
2016-10-30 21:06:32.532 [bus notice] scan cc timed out (45 slaves left)
2016-10-30 21:06:32.626 [bus notice] scan cd timed out (44 slaves left)
2016-10-30 21:06:32.721 [bus notice] scan ce timed out (43 slaves left)
2016-10-30 21:06:32.815 [bus notice] scan cf timed out (42 slaves left)
2016-10-30 21:06:32.909 [bus notice] scan d0 timed out (41 slaves left)
2016-10-30 21:06:33.005 [bus notice] scan d1 timed out (40 slaves left)
2016-10-30 21:06:33.099 [bus notice] scan d2 timed out (39 slaves left)
2016-10-30 21:06:33.193 [bus notice] scan d3 timed out (38 slaves left)
2016-10-30 21:06:33.287 [bus notice] scan d4 timed out (37 slaves left)
2016-10-30 21:06:33.382 [bus notice] scan d5 timed out (36 slaves left)
2016-10-30 21:06:33.476 [bus notice] scan d6 timed out (35 slaves left)
2016-10-30 21:06:33.570 [bus notice] scan d7 timed out (34 slaves left)
2016-10-30 21:06:33.665 [bus notice] scan d8 timed out (33 slaves left)
2016-10-30 21:06:33.759 [bus notice] scan d9 timed out (32 slaves left)
2016-10-30 21:06:33.853 [bus notice] scan da timed out (31 slaves left)
2016-10-30 21:06:33.948 [bus notice] scan db timed out (30 slaves left)
2016-10-30 21:06:34.042 [bus notice] scan dc timed out (29 slaves left)
2016-10-30 21:06:34.137 [bus notice] scan dd timed out (28 slaves left)
2016-10-30 21:06:34.231 [bus notice] scan de timed out (27 slaves left)
2016-10-30 21:06:34.325 [bus notice] scan df timed out (26 slaves left)
2016-10-30 21:06:34.421 [bus notice] scan e0 timed out (25 slaves left)
2016-10-30 21:06:34.515 [bus notice] scan e1 timed out (24 slaves left)
2016-10-30 21:06:34.609 [bus notice] scan e2 timed out (23 slaves left)
2016-10-30 21:06:34.703 [bus notice] scan e3 timed out (22 slaves left)
2016-10-30 21:06:34.798 [bus notice] scan e4 timed out (21 slaves left)
2016-10-30 21:06:34.892 [bus notice] scan e5 timed out (20 slaves left)
2016-10-30 21:06:34.986 [bus notice] scan e6 timed out (19 slaves left)
2016-10-30 21:06:35.081 [bus notice] scan e7 timed out (18 slaves left)
2016-10-30 21:06:35.175 [bus notice] scan e8 timed out (17 slaves left)
2016-10-30 21:06:35.270 [bus notice] scan e9 timed out (16 slaves left)
2016-10-30 21:06:35.364 [bus notice] scan ea timed out (15 slaves left)
2016-10-30 21:06:35.458 [bus notice] scan eb timed out (14 slaves left)
2016-10-30 21:06:35.553 [bus notice] scan ec timed out (13 slaves left)
2016-10-30 21:06:35.647 [bus notice] scan ed timed out (12 slaves left)
2016-10-30 21:06:35.742 [bus notice] scan ee timed out (11 slaves left)
2016-10-30 21:06:35.835 [bus notice] scan ef timed out (10 slaves left)
2016-10-30 21:06:35.938 [bus notice] scan f2 timed out (9 slaves left)
2016-10-30 21:06:36.030 [bus notice] scan f4 timed out (8 slaves left)
2016-10-30 21:06:36.125 [bus notice] scan f5 timed out (7 slaves left)
2016-10-30 21:06:36.219 [bus notice] scan f6 timed out (6 slaves left)
2016-10-30 21:06:36.313 [bus notice] scan f8 timed out (5 slaves left)
2016-10-30 21:06:36.407 [bus notice] scan f9 timed out (4 slaves left)
2016-10-30 21:06:36.501 [bus notice] scan fa timed out (3 slaves left)
2016-10-30 21:06:36.603 [bus notice] scan fb timed out (2 slaves left)
2016-10-30 21:06:36.696 [bus notice] scan fc timed out (1 slaves left)
2016-10-30 21:06:36.791 [bus notice] scan fd timed out (0 slaves left)
2016-10-30 21:06:36.791 [bus notice] scan finished
2016-10-30 21:06:46.448 [update notice] update solar temp: 0;40.19;30.81
2016-10-30 21:07:01.371 [update notice] update solar ertraege: -;0;128;0;128;0
2016-10-30 21:07:16.271 [update notice] update solar temp: 0;40.12;30.88
2016-10-30 21:07:31.145 [update notice] update solar ertraege: -;0;128;0;128;0
ebusctl -p 5002 scan result
0c;0;
76;Kromschroeder; ;0227;-
Edit: zuvor noch Updates erhalten und jetzt nach einem Neustart von ebusd um 8:30 sind wieder keine Updates von ftdi2 verfügbar :-\
Edit2: hier noch der Debug-Log, könnte doch auf ein schlecht eingedrehtes Poti hindeuten,
komisch nur, dass es vorm Neustart des ebusd gegangen ist
ebusd -f --readonly --device=/dev/ftdi2 --localhost --port=5002
2016-10-31 09:10:10.925 [main notice] ebusd 2.2.af6e1c1 started
2016-10-31 09:10:10.937 [main notice] found messages: 14 (0 conditional on 0 con ditions, 0 poll, 7 update)
2016-10-31 09:10:10.983 [bus notice] signal acquired
2016-10-31 09:10:58.582 [main debug] <<< done
2016-10-31 09:10:58.583 [network info] [00001] connection closed
2016-10-31 09:10:59.582 [network debug] dead connection removed - 0
2016-10-31 09:11:08.582 [main debug] performing regular tasks
2016-10-31 09:11:13.145 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:11:18.583 [main debug] performing regular tasks
2016-10-31 09:11:20.035 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2016-10-31 09:11:20.061 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-10-31 09:11:20.157 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2016-10-31 09:11:20.183 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-10-31 09:11:28.019 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:11:28.583 [main debug] performing regular tasks
2016-10-31 09:11:38.584 [main debug] performing regular tasks
2016-10-31 09:11:42.924 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:11:48.584 [main debug] performing regular tasks
2016-10-31 09:11:49.877 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:11:49.973 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2016-10-31 09:11:49.999 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-10-31 09:11:57.838 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:11:58.585 [main debug] performing regular tasks
2016-10-31 09:12:08.585 [main debug] performing regular tasks
2016-10-31 09:12:12.735 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:12:18.585 [main debug] performing regular tasks
2016-10-31 09:12:19.675 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2016-10-31 09:12:19.688 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2016-10-31 09:12:19.796 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
2016-10-31 09:12:19.822 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2016-10-31 09:12:27.659 [bus debug] ERR: read timeout during receive command, switching to skip
2016-10-31 09:12:28.586 [main debug] performing regular tasks
Zitat von: de.jt am 29 Oktober 2016, 19:52:52
Ich habe nun in 08.bai.csv direkt hinter das Fallback für HW7401 die 0010003886.inc eingetragen. Damit funktioniert es erst einmal.
Gut, dann behalt das mal so bei fürs Erste.
Die Abfrage des Produktcodes war etwas ungeschickt implementiert, das sollte nun aber mit dem letzten commit behoben sein.
Zitat von: flash91 am 30 Oktober 2016, 21:12:43
hier der fullscan von ftdi1:
ebusd -f --device=/dev/ftdi1 --localhost --port=5001
...
2016-10-30 21:10:46.785 [bus notice] scan 0b timed out (220 slaves left)
2016-10-30 21:10:46.876 [bus notice] new master 07, master count 3
2016-10-30 21:10:46.877 [bus error] scan 0c failed (219 slaves left): ERR: invalid position
2016-10-30 21:10:46.877 [bus notice] scan 0c: ;0;
...
2016-10-30 21:10:51.676 [bus error] scan 4a failed (168 slaves left): ERR: invalid argument
...
2016-10-30 21:11:06.691 [bus error] scan e8 failed (17 slaves left): ERR: invalid argument
...
Ist ja mal spannend. Deine Geräte scheinen ID-Anfragen inkorrekt zu beantworten. Mach doch mal bitte die Scans all der Adressen in den Zeilen (ohne die mit Timeout) in hex:
hex 0c070400für die Adresse 0c und analog für alle anderen (0c durch die entsprechende Adresse ersetzen).
Zitat von: flash91 am 30 Oktober 2016, 21:12:43
Edit2: hier noch der Debug-Log, könnte doch auf ein schlecht eingedrehtes Poti hindeuten,
komisch nur, dass es vorm Neustart des ebusd gegangen ist
...
2016-10-31 09:11:20.035 [bus debug] ERR: CRC error during receive command, switching to receive command ACK
...
Das schreit förmlich nach schlecht eingestelltem Poti...
Zitat von: john30 am 02 November 2016, 08:32:57
Mach doch mal bitte die Scans all der Adressen in den Zeilen (ohne die mit Timeout) in hex
$ ebusctl -p 5001 hex 0c070400
00
bei allen anderen Adressen erhalte ich
$ ebusctl -p 5001 hex 22070400
ERR: read timeout
Zitat von: john30 am 02 November 2016, 08:32:57
Das schreit förmlich nach schlecht eingestelltem Poti...
Kann man das Poti eig überdrehen oder so?
Hab jetzt mal probiert von der aktuellen Position zwei Umdrehungen in jeweils beide Richtungen zu drehen, bekomme aber gerade unabhängig davon immer Updates
Hallo flash91
ZitatHab jetzt mal probiert von der aktuellen Position zwei Umdrehungen in jeweils beide Richtungen zu drehen,
Was hast du denn für eine Hardware? Das muss wohl ein Spindelpotentiometer sein wenn du vier Umdrehungen machen kannst.
Damit ist es aber weder die Platine aus dem FHEM WIKI noch die von eService.
ZitatKann man das Poti eig überdrehen oder so?
Das kommt auf die Schaltung an. Die aus dem WIKI kann man ohne Schaden überdrehen. Die von eService könnte theoretisch Schaden nehmen. Praktisch haben aber diese Chips Schutzschaltungen eingebaut sodass sie es mit hoher Wahrscheinlichkeit überleben werden.
LG
Eduard
Zitat von: galileo am 03 November 2016, 07:25:16
Was hast du denn für eine Hardware? Das muss wohl ein Spindelpotentiometer sein wenn du vier Umdrehungen machen kannst.
Damit ist es aber weder die Platine aus dem FHEM WIKI noch die von eService.
Doch doch ich habe Platine mit den Bauteilen aus der 2. Sammelbestellung
https://forum.fhem.de/index.php/topic,45127.0.html (https://forum.fhem.de/index.php/topic,45127.0.html)
allerdings nicht den liegenden Cermet-Trimmer der bei der Bauteilliste jetzt drinnen ist, sondern das selbe Poti wie in den Abbildungen von Reinhart
https://forum.fhem.de/index.php/topic,45127.msg388020.html#msg388020 (https://forum.fhem.de/index.php/topic,45127.msg388020.html#msg388020)
BG,
Philipp
Zitat von: flash91 am 03 November 2016, 08:27:35
allerdings nicht den liegenden Cermet-Trimmer der bei der Bauteilliste jetzt drinnen ist, sondern das selbe Poti wie in den Abbildungen von Reinhart
das ist genau ein Spindeltrimmer. Ich habe es bei einer meiner Schaltungen auch schon geschafft, den zu überdrehen. Der Endpunkt ist irgendwie schlecht zu fühlen...
Zitat von: flash91 am 02 November 2016, 18:13:38
$ ebusctl -p 5001 hex 0c070400
00
Das habe ich mir gedacht. Also keine ordentliche Antwort vom Gerät auf eine eBUS Standardabfrage. Ärgerlich.
ZitatDoch doch ich habe Platine mit den Bauteilen aus der 2. Sammelbestellung
Oh entschuldige, damals war ich noch nicht dabei und habe es überlesen. Aber das macht ja auch Sinn weil der Einstellbereich eine ziemliche Zitterpartie ist.
Leider hat die Schaltung keine LED zur Kontrolle, sonst könnte man während des Drehens am Poti sehen ob man richtig liegt oder nicht. Meist ist ja die Schaltung im Keller und der PC ganz wo anders.
Übrigens wäre es relativ einfach, den Widerstand R4 = 10kOhm auszulöten und durch eine LED + 1kOhm zu ersetzen. Dann würde man die Eingangs-Pulse vor Ort sehen.
Also aus meiner mühevollen Erfahrung kann ich nur diese Vorgangsweise zur Einstellung vorschlagen:
1. Poti ganz an einen Anschlag drehen. Die LED sollte jetzt statisch sein (aus oder an). Im Terminalfenster dürfte nichts zu sehen sein.
2. Poti solange drehen bis die LED langsam blinkt (größer als 1/2 Sekunde oder so). Das 4011 Gatter befindet sich jetzt im verbotenen Bereich und scheint nur für ganze Pakete zu schalten oder sonstigen Blödsinn zu machen, nicht jedoch die einzelnen Pulse weiterzuleiten.
3. Weiterdrehen bis schnelle Pulse erkennbar sind. Die Frequenz liegt jetzt bei den 2400 Baud. Natürlich muss da jemand senden, also wird man Pakete sehen, aber mit 2400 Baud gepulst. Im Monitor sollten jetzt die "aa" erkennbar sein und auch die Hex-Werte der Pakete.
Diese Einstellung am Poti merken.
4. Weiterdrehen bis die LED wieder langsam blinkt oder ganz an/ausgeht. Im Monitor müssten die Pakete verschwunden sein oder Nonsens zeigen.
5. Den Mittelwert aus dieser Einstellung und der gemerkten Einstellung bilden und das Poti dorthin drehen.
Jetzt sollte es funktionieren. Zumindest für den einen Sender auf den man sich einjustiert hat. Aber ich glaube du hast ja nur einen.
Bei mir waren es mehrere und das verkompliziert die Sache nochmals, weil ja nicht gesagt ist, dass ein anderer Sender mit den gleichen Pegeln daherkommt...
Ja und nochmals: kann man sich mit einem Comparator am Eingang alles sparen :-)
LG
Eduard
P.S. Kaputtgehen sollten diese Spindeltrinmmer eigentlich nicht, wenn man sie überdreht. Das ist soetwas wie die Auslaufrille bei den Vinyl-Schallplatten. wenn man einfach zurückdreht dann greift es wieder.
Habs grad gesehen: in http://www.fhemwiki.de/wiki/Datei:EBUS_Adapter_Messpunkte.png (http://www.fhemwiki.de/wiki/Datei:EBUS_Adapter_Messpunkte.png) ist diese Kontroll-LED eingezeichnet.
Leider scheint sie im endgültigen Schaltplan nicht mehr auf
Okay danke erstmal für eure Hilfe! :)
Werde mir überlegen, ob ich die Komparatorschaltung noch dazubastle.
zum Thema "Komparatorschaltung" basierend auf die pah Schaltung und zentis666 eagle Files.
Würde die Schaltung, unabhängig davon wie man diese auf die 5x5 cm Platine unterbringen würde, so aussehen?
Was ich noch nicht verstanden habe ist die 5V Stromversorgung vom 78L05, wo genau kann ich die abgreifen 1 (VO)? Oder reicht es, wie im angehängtem Schaltplan, die 5V direkt vom FTDI/UART Adapter abzugreifen?
Fehlt noch etwas (ja, LEDs ;o) ) ?
Ist etwas flasch und was?
Sonstige Anmerkungen?
@galileo
Könntest Du bitte unterstützen?
Danke.
EDIT: Ebusd 1.6 Schaltung von zentis666 auch noch angehängt (Vergleich) - Sorry.
Prinzipiell dürfte das so passen. Aber eben nur prinzipiell. Ich habe die Schaltung nur mit meinem eService Modul getestet. Da funktioniert sie einwandfrei.
Um seriös zu bleiben müsste ich sie aber wenigstens einmal mit der pah Schaltung testen. Die habe ich aber leider nicht !! Die Anbindung ist dort anders und da ich das nur "im Kopf" angepasst habe kann mir ja sonst irgendein Fehler passiert sein...
Außerdem nochmals: so wie ich sie gezeichnet habe ist sie als Quick-And-Dirty Einsatz gedacht, um in die bestehende Schaltung integriert zu werden, nur durch Ersatz von R1. Der Rest sollte gleich bleiben.
Was auf jeden Fall falsch ist ist die Versorgung vom LM311 auf VDD und GND zu hängen. Die gehört auf 1(VO) und 2(GND) vom 78L05. Wir wollen ja schliesslich weiterhin eine galvanische Trennung haben.
Mit dem R7 und dem CNY17 ist auch was kräftig durcheinander geraten. Das gäbe ja einen satten Kurzschluss am Transistor von U1 :-)
Also: entweder alles so lassen wie es ist und NUR R1 durch die Comparator-Schaltung ersetzen
Oder: die gesamte Schaltung auf die neuen Gegebenheiten anpassen. Hab mir schon Gedanken gemacht - aber das wird heute nichts mehr. Ich melde mich wieder wenn ich was konkretes habe. Eigentlich wollte ich es ja zuerst zum Testen aufbauen - aber dazu muss ich mir erst die Bauteile besorgen..
Also, nun mal langsam - hier geht es jetzt doch etwas ans Eingemachte.
1. Auch wenn mehrere Sender auf dem Bus unterwegs sind, müssen diese die Signalpegel einhalten. Insofern kann es eigentlich nicht sein, dass die nach der Spezifikation festgelegten Schwellen unter- oder überschritten werden. Wahrscheinlicher ist, dass die Verkabelung Mist ist und hohe Durchgangswiderstände aufweist - und wenn dann ein paar mA gezogen werden, kommt es zum Spannungsabfall.
2. Die Einstellung der von mir publizierten Schaltung ist m.E. gar nicht schwierig, und das Dingens arbeitet bei mir seit Jahren unverändert - bis auf einen Ausfall der Zenerdiode aus ungeklärtem Grund. WENN man also eine Erweiterung für eine bessere Einstellbarkeit in komplizierten Situationen zu schaffen, sollte diese OHNE manuellen Eingriff auskommen.
Dazu braucht man nur einen beliebigen Operationsverstärker - spezialisierte Komparatoren unterscheiden sich davon fast nur durch die hohe Flankensteilheit, die braucht es aber bei diesem Bus nun wirklich nicht.
Zur Schaltung selbst: Der Operationsverstärker wird an beiden Eingängen aus dem Bus versorgt. Auf dem einen Eingang ist aber noch ein Integrationsglied vorgeschaltet (kann man, wenn es luxuriös sein soll, noch mit einem zweiten OpAmp bestücken). Das versorgt den Operationsverstärker an diesem Eingang mit einer Spannung, die dem Mittelwert der Busspannung über einen Zeitraum (sagen wir: 10 Sekunden ?) entspricht. Der zweite Eingang kommt ohne dieses Integrationsglied aus - ist seine Spannung höher, als die gemittelte, wir der OpAmp das als "HIGH"-Pegel, ist sie niedriger, als "LOW"-Pegel detektieren.
3.Natürlich darf die Spannungsversorgung im Bus-teil NICHT aus dem USB-Adapter kommen. Sondern muss aus dem 78L05 gezogen werden.
LG
pah
Hallo pah,
ZitatAuch wenn mehrere Sender auf dem Bus unterwegs sind, müssen diese die Signalpegel einhalten. Insofern kann es eigentlich nicht sein, dass die nach der Spezifikation festgelegten Schwellen unter- oder überschritten werden
Stimmt. Das Problem ist nur, dass die Pegel bei dieser Schaltung zuerst den CNY17 analog durchlaufen müssen bevor sie am 4011 in ein digitales Signal gewandelt werden. Der CNY17 hat aber lt. Datenblatt einen "Current Transfer Ratio" - IC/IF je nach Typ, Charge und Temperatur von 13% bis 90%. Und wenn dieser Wert im unteren Bereich liegt, dann wird der 4011 außerhalb seiner Spezifikation betrieben. Heisst schlicht und einfach: Die Schaltung kann funktionieren, muss sie aber nicht immer (oder besser: bei jedem)
ZitatWahrscheinlicher ist, dass die Verkabelung Mist ist und hohe Durchgangswiderstände aufweist - und wenn dann ein paar mA gezogen werden, kommt es zum Spannungsabfall.
Der Eingangswiderstand wird hauptsächlich durch den 3k3 Widerstand bestimmt. Bei einer angenommenen Kupferleitung mit 0,1mm2 und einer "Störung" von 1% (also 33 Ohm Leitungswiderstand) müsste die Leitung ca 300m lang sein.
Aber wenn das schon gemutmaßt wird, dann bietet sich doch genau das an: Vorschalten eines Operationsverstärkers oder Comparators - und schon kann der Eingangswiderstand so groß sein dass die Beschaffenheit der Leitung völlig egal ist. (Natürlich bez. der Pegel und nicht der dynamischen Signaleigenschaften).
ZitatDie Einstellung der von mir publizierten Schaltung ist m.E. gar nicht schwierig, und das Dingens arbeitet bei mir seit Jahren unverändert
Siehe oben: das muss nicht für jeden zutreffen.
ZitatWENN man also eine Erweiterung für eine bessere Einstellbarkeit in komplizierten Situationen zu schaffen, sollte diese OHNE manuellen Eingriff auskommen.
Das habe ich jetzt nicht ganz verstanden. Das wäre doch das Ziel: ohne Einstellung auszukommen. Oder?
ZitatDazu braucht man nur einen beliebigen Operationsverstärker - spezialisierte Komparatoren unterscheiden sich davon fast nur durch die hohe Flankensteilheit, die braucht es aber bei diesem Bus nun wirklich nicht.
Einig. Der Unterschied ist dass bei einem OP-Verstärker normalerweise eine Gegenkopplung stattfindet und bei einem Schmitt-Trigger/Vergleichs-Schaltung keine Gegenkopplung oder sogar eine Mitkopplung erfolgt. In beiden Fällen gehen die Transistoren im Chip beim Schalten in die Sättigung und deshalb nimmt man einen Comparator der das verhindert und damit höhere Schaltfrequenzen zulässt. Aber klar, bei den 1200 Baud ist das kein Thema. Nur wenn ich schon beides zur Verfügung habe dann nehme ich das was dafür gedacht ist...
ZitatZur Schaltung selbst: Der Operationsverstärker wird an beiden Eingängen aus dem Bus versorgt. Auf dem einen Eingang ist aber noch ein Integrationsglied vorgeschaltet (kann man, wenn es luxuriös sein soll, noch mit einem zweiten OpAmp bestücken). Das versorgt den Operationsverstärker an diesem Eingang mit einer Spannung, die dem Mittelwert der Busspannung über einen Zeitraum (sagen wir: 10 Sekunden ?) entspricht. Der zweite Eingang kommt ohne dieses Integrationsglied aus - ist seine Spannung höher, als die gemittelte, wir der OpAmp das als "HIGH"-Pegel, ist sie niedriger, als "LOW"-Pegel detektieren.
Interessante Idee. Würde sich vermutlich auch an Systeme anpassen, die nicht der Norm entsprechen oder mit der Zeit davondriften. Aber ich denke wir können davon ausgehen, dass sich Vaillant & Co an die Spezifikation halten. Und dann reicht ein Vergleich mit einem festen Wert irgendwo zwischen 12 und 15 Volt (lt. Spezifikation).
Hab übrigens gestern noch den Schaltplan der original Vaillant Schaltung aus dem VR60 aufgenommen, weils mich interessiert hat. Die verwenden einen TS393 Comparator, allerdings ohne Hysterese, mit einer fixen Schaltschwelle irgendwo bei 12 Volt (muss das nochmals nachrechnen). Kanns ja noch posten falls es jemanden interessiert.
LG
Eduard
Bei der o.a. Komparator-Diskussion sehe ich nach wie vor die Notwendigkeit zur Einstellung.
ZitatDer Eingangswiderstand wird hauptsächlich durch den 3k3 Widerstand bestimmt.
Ich meine aber gar nicht den EBUS-Adapter. Sondern ich tippe eher, dass andere Geräte auf dem Bus nicht so genügsam sind und das die Abweichungen bei mehreren Sendern erklärt.
ZitatInteressante Idee. Würde sich vermutlich auch an Systeme anpassen, die nicht der Norm entsprechen oder mit der Zeit davondriften
Eben. Beispielsweise habe ich das 1977 in das erste Cassettenrecorder-Interface eingebaut, das mit meinem Selbstbaucomputer verbunden war. Extrem stabile Sache.
Ich vermute auch gar nicht, dass sich die Hersteller nicht an die Normen halten. Missttraue aber (aus gegebenem Anlass) der Verkabelung durch Heizungsinstallateure.
LG
pah
Zum Thema ,,Komparatorschaltung" - mich als nicht Elektoniker habt ihr längst abgehängt, weil mir vieles nicht vertraut ist, aber dennoch interessiert mich wie die Schaltung aussehen würde/könnte. ;o)
ZitatWas auf jeden Fall falsch ist ist die Versorgung vom LM311 auf VDD und GND zu hängen. Die gehört auf 1(VO) und 2(GND) vom 78L05. Wir wollen ja schliesslich weiterhin eine galvanische Trennung haben.
Habe ich angepasst.
ZitatMit dem R7 und dem CNY17 ist auch was kräftig durcheinander geraten. Das gäbe ja einen satten Kurzschluss am Transistor von U1 :-)
Also: entweder alles so lassen wie es ist und NUR R1 durch die Comparator-Schaltung ersetzen.
Ja, das stimmt. Ich nahm an, dass das Poti und der Widerstand komplett entfallen könnten.
Eine Frage habe ich dazu. Ist der Poti für eine Feinjustierung überhaupt noch notwendig, oder reicht dann nur noch ein 20k Widerstand.
So, anbei die neue Version (1.7.1) des Schaltplans. Es wäre nett wenn galileo, pah oder jemand der sich auskennt drüber schauen könnte. Danke.
P.S: Ach ja, eine Rx LED habe ich auch spendiert.
So, jetzt gibt es ebusd in Version 2.3 (https://github.com/john30/ebusd/releases/tag/v2.3), womit nun endlich das Thema falsch geladener "bai.*.inc" Dateien der Vergangenheit angehören dürfte.
Viel Spaß damit :-)
VG John
Hallo amunra,
ZitatEine Frage habe ich dazu. Ist der Poti für eine Feinjustierung überhaupt noch notwendig, oder reicht dann nur noch ein 20k Widerstand.
Es gibt keine Feinjustierung mehr (an dieser Stelle). Wir sind dort nur mehr DIGITAL unterwegs weshalb der Wert des Widerstandes irrelevant ist. Natürlich in bestimmten Grenzen.
Wenn nahe 0 --> Kurzschluss. Wenn zu hochohmig --> Gefahr der Störeinstrahlung. Also ist es egal ob das Poti da ist oder nicht oder wie es steht. Insgesamt 1k oder 10k ist sicherlich ein guter Wert.
ZitatSo, anbei die neue Version (1.7.1) des Schaltplans. Es wäre nett wenn galileo, pah oder jemand der sich auskennt drüber schauen könnte
Ja das könnte jetzt so passen. Aber Sicherheit kann man erst nach einem Probeaufbau haben.
Ich weiss allerdings nicht, was du vorhast. Möchtest du eine neue Schaltung/Print erzeugen? Sollte das so sein dann möchte ich anmerken, dass durch die Verlagerung der analogen Verarbeitung in den Komparator einiges der jetzigen Schaltung schlicht überflüssig wird. Z.B. wird ein digitales Signal nicht besser wenn man es noch 2x invertiert. Und der CP2109 (USB/Serial Converter) hat an seinem Ausgang bereits genug Leistung um den Optokoppler direkt zu treiben zu können.
Ich habe versucht, vor diesem Hintergrund die Schaltung zu reduzieren. Ich wollte das aber noch nicht posten weil es bis hierher einfach nur "Theorie" ist und ich auch nicht davor gefeit bin, einen Denkfehler zu machen. Ich werde aber, wenn ich nächste Woche die Bauteile zusammenhabe, einmal eine Schaltung aufbauen und testen. Bis dahin diese Schaltung BITTE einfach nur als Diskussionsbeitrag sehen.
Kritiken dazu sind aber gerne willkommen.
LG
Eduard
Hallo galileo,
vielen Dank für dein Feedback.
Zum Poti:
ok, verstanden.
Zum Schaltplan:
Ja, einen Probeaufbau (inkl. Messungen etc.) ist notwendig das sehe ich auch wie Du und ,,ich" würde es (und hatte es auch nicht vor) auch ohne nicht an mein EBUS anschließen.
Was ich vorhabe?
Primär – Das Thema interessiert mich.
Sekundär - ich habe eine 1.3 und 1.5 Version der hier im Forum gefertigten Platinen, sowie die von e-serivce bei mir seit der Ersteinrichtung (vor Monaten, man könnte sagen Jahren) ohne Probleme im Einsatz. Damit eigentlich kein wirklicher Eigenbedarf, aber wenn man den Adapter optimiert kann und den Betrieb verbessern bzw. Inbetriebnahme vereinfachen kann, dann finde ich das gut.
In dem Zusammenhang sehe ich zwei Anwendungsfälle:
1) Einen neuen verbesserten/optimierten Ebus Adapter - von mir aus EBUS-Adapter 2.0.
2) Eine Erweiterung (auf einer 5x5 cm Platine könnte man mehrere davon unterbringen) für die bestehenden Adapter. Grober Ablauf für die Erweiterung wäre: R1 auslöten, eine kleine Platine per Pineheads auflöten und zwei Leitungen (GND,VCC) an den 78L05 anbringen. Fertig! (ok die Erweiterungsplatine muss auch noch gelötet werden ;o) )
Soviel zu meiner Motivation (ob das alles so kommt und sinnvoll ist sei mal dahingestellt.)
Bin mal auf deine Ergebnisse gespannt...
EDIT: Sorry, natürlich R1 und nicht R3 :-\
Wenn wir das Ganze schon erweitern: Ich habe im Gehäuse meine EBUS-Adapters noch ein paar 1-Wire-Komponenten untergebracht - mit galvanischer Trennung, primärseitig versorgt aus dem 78L05
1-Wire-Counter zum Zählen der Impulse vom solaren Durchflusssensor
Feuchtesensor zur Warnung vor austretendem Wasser
Steuerung der Zirkluationspumpe http://www.fhemwiki.de/wiki/1W-WPump
1-Wire Busmaster
Nun wird nicht jeder alle Teile benötigen (oder wollen). Es wäre aber schön, wenn wir so etwas definieren könnten, wie stapelbare Platinen mit jeweils einer weiblichen und einer männlichen Steckerleiste.
Daran könnte man auch statt des EBUS-Adapters ein anderes Heizungsinterface andocken.
LG
pah
Hallo,
ich habe das Problem, daß ich die verbliebenen Stunden bis zur Wartung nicht aus meiner ecoCompact auslesen kann. Der Wert steht momentan auf 1590h (d.84).
pi@raspberrypi ~ $ ebusctl r HoursTillService
ERR: invalid position in decode
ebusctl find
bai HoursTillService = (ERR: invalid position for 3108b509030d20 / 00)
Das steht in meiner 08.bai.HW9602.csv:
r;wi,,HoursTillService,d.84 Stunden bis Wartung,,,,"2004",,,hoursum2,,,Wartungsintervall:Anzahl der Stunden bis zur nächsten Wartung,,,
Es scheint ein Formatierungsproblem zu sein, oder? Mit welcher Formatierung komme ich an das Format ran?
Für jeden Hinweis dankbar,
Dietmar
In meinem System funktioniert für die Therme (bai00)
Zitatr;wi,,TimeToService,d.84 Stunden bis Wartung,,,,2004,,,hoursum2,,,Wartungsintervall:Anzahl der Stunden bis zur nächsten Wartung,,,,,,,,,,,,,,,,,,,,,,,,,,,
problemlos. Mein Tipp: niemals direkt in den CSV-Dateien editieren. Stattdessen eine übersichtliche OpenOffice-Tabelle anlegen und die CSV-Dateien daraus exportieren.
LG
pah
Danke für den Hinweis - ich mache es eigentlich so, wenn auch mit Excel.
Allerdings meinte ich hier weniger die Formatierung der csv Datei, sondern die Schwierigkeit von ebusd die Ausgabe mit hoursum2 darzustellen.
Die Ausgabe z.B. der Betriebsstunden mit dem Format hoursum2 klappt dagegen gut:
r,,HcHours,d.80 Hz. Betriebsstunden,,,,"2800",,,hoursum2,,,Betriebsstunden im Heizbetrieb,,,
pi@raspberrypi ~ $ ebusctl r HcHours
2945
Was bietet sich an für eine hex Ausgabe statt hoursum2, was wohl unsigned int entspricht?
Zitat von: mirror am 12 November 2016, 18:45:32
ich habe das Problem, daß ich die verbliebenen Stunden bis zur Wartung nicht aus meiner ecoCompact auslesen kann. Der Wert steht momentan auf 1590h (d.84).
pi@raspberrypi ~ $ ebusctl r HoursTillService
ERR: invalid position in decode
ebusctl find
bai HoursTillService = (ERR: invalid position for 3108b509030d20 / 00)
Hier scheint deine ecoCompact mit "00" zu antworten, was die Länge der Antwort ist, sprich leere Antwort. Daraus lassen sich dann auch schlecht 2 Bytes lesen...
Jetzt wäre der Produktcode Deiner ecoCompact mal spannend, denn es haben bereits andere User berichtet, dass die produkt-spezifischen BAI CSVs nicht ganz zu stimmen scheinen.
Also bitte mal nen Scan initiieren und das Ergebnis von "scan result" posten (auch gern als PM).
Hallo John,
anbei die Daten der ecoCompact und des VCR700 Reglers (hatte ich schon mal auf Deinem github gepostet). Die bai.csv ist eine modifizierte 08.bai.HW7401.csv:
pi@raspberrypi ~ $ ebusctl scan full
done
pi@raspberrypi ~ $ ebusctl scan result
08;Vaillant;BAI00;0116;9602
15;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
ec;Vaillant;70000;0206;4103;21;15;43;0020171314;0082;036705;N4
pi@raspberrypi ~ $ ebusctl info
version: ebusd 2.0.5ccdb76
signal: acquired
symbol rate: 37
masters: 3
messages: 461
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/08.bai.HW9602.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103", loaded "vaillant/15.700.csv"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103"
Nachdem letzte Woche alle Bauteile eingetroffen sind habe ich jetzt den Probeaufbau gestartet. Gegenüber der ersten Idee hat sich aber nun doch noch einiges verändert.
1. Die LED für RxD war so angeschlossen, dass sie nicht bei den Pulsen sondern in den Pausen dazwischen geleuchtet hat. Dadurch war sie praktisch immer hell was relativ sinnlos war.
Also habe ich das Signal am CNY17 invertiert (Ausgang vom Emitter zum Kollektor verschoben), was aber einen weiteren Inverter notwendig machte um wieder die richtigen Polarität herzustellen. Ich habe dazu die zweite unbenutzte Hälfte des Komparators genommen, die war ja sozusagen "gratis". Ich hätte stattdessen auch den invertierenden Komparator auf einen nicht-invertierenden umbauen können, aber bei dieser Schaltung würden sich der Eingangs-Spannungsteiler und die Mitkopplung vermischen, was die ganze Sache nur komplizierter macht. Deshalb die einfache Schaltung "invertierender Komparator" und noch ein Inverter hintennach.
2. Was niemand bedacht hat und was bei meiner Schaltung dann zur Fehlfunktion geführt hat: VDD mag ja 5V sein, aber der CP2102 Chip, der auf dem USB/Serial Wandler verbaut ist, liefert nur einen High-Pegel von 3,3V. Das mag bei einem 4011 mit 5V Versorgung noch durchgehen, wenn man den aber wegrationalisiert und den Optokoppler direkt am Ausgang des CP2102 betreibt, dann muss man dort auch mit 3,3V arbeiten. Deshalb keine Verwendung mehr von den 5V auf der USB Seite.
Nachdem die Schaltung lief habe ich auch noch verschiedene Sachen nachgemessen, um die Theorie zu verifizieren.
Da ist einmal der TxD Pfad. Aus dem USB/Seriell Wandler kommt ein 0V/3,3V Signal, welches auch genug Strom liefern kann. Durch die LED im CNY17 fließen dann (3,3-1,25)/1k = 2mA. Damit der Ausgangstransistor beim Durchschalten die (5-1,6-0,7)/1k = 2,7mA Strom liefern kann, ist ein Übersetzungsverhältnis IC/IF > 100 notwendig. Das ist der Grund, warum ich hier einen CNY17-3 gewählt habe. Ist aber nicht ganz so kritisch, weil ja dieser Transistor mit dem BC337 noch einen "Darlington" bildet und dessen Stromverstärkung mit eingeht. Wichtig ist nur dass dieser letzte Transistor die von der eBus Spezifikation geforderten maximalen 100mA treiben kann. 100mA/2,7mA ergibt also ein hFE Minimum von 37.
Ich habe den BC337-40 mit einem garantierten hFE von 250 gewählt und somit sind wir insgesamt auf der gaaanz sicheren Seite. Und das kostet auch nicht mehr - die Preise für alle Strich-Versionen sind sowohl beim CNY17 als auch beim BC337 gleich. Man braucht aber jetzt für den Transistor keinen Darlington mehr, und es fällt an ihm auch keine nennenswerte Leistung ab. Im Anhang kann man ein Oszillogramm sehen, gemessen am Kollektor vom BC337, wo zuerst der Bus von einem anderen Busteilnehmer getrieben wird (5V/13V) und dann die Schaltung ,,sendet" und der BC337 sauber von 13V auf 0V zieht.
Die Schaltschwelle des Komparators lag gemessen (am eBus) bei 13,1V (High to Low) und 13,8V (Low to High).
Das zweite Oszillogramm zeigt den Eingang VI vom 78L05 Spannungsregler. Man kann erkennen wie (in der Mitte vom Bild) die Spannung während einer Sendung zwar abfällt, aber eben nicht unmittelbar auf 8-9V sondern nur langsam wegen des 10uF Kondensators.
So, das war's vorerst von meiner Seite. Diese Schaltung läuft stabil und ohne Einstellung (natürlich ,,nur" solange sich alle an die Spezifikation halten). Wollte man etwas einstellbar machen, dann könnte man R3/R4 durch 2 Widerstände und ein Potentiometer ersetzen. Auch an der Mitkopplungs-Schraube könnte man drehen und R9 vergrößern. Dadurch würde die Hysterese kleiner werden und damit der Toleranzbereich zwischen High und Low vergrößert. Hilft vielleicht gegen die von pah geschilderten Installateur-Sünden ;)
Da ich persönlich mit meinem umgebauten eService Koppler zufrieden bin, habe ich nicht vor, einen Print zu machen. Mich hat nur die Schaltung als solche gereizt. Auch für den Testaufbau habe ich keine weitere Verwendung. Ich kann ihn gerne jemandem überlassen der damit spielen möchte.
LG
Eduard
Vielen Dank für die "plug-and-play" Schaltung :-)
Hast du auch ein Foto von der Rückseite der Lochrasterplatine?
Na das gewinnt sicher keinen Schönheitswettbewerb, aber ich hab's kreuzungsfrei geschafft, für den Preis einer sicherlich zu großen Fläche.
Zitat von: galileo am 14 November 2016, 19:30:11
2. Was niemand bedacht hat und was bei meiner Schaltung dann zur Fehlfunktion geführt hat: VDD mag ja 5V sein, aber der CP2102 Chip, der auf dem USB/Serial Wandler verbaut ist, liefert nur einen High-Pegel von 3,3V.
Wie kommt der CP2102 mit dem Timing auf dem Bus klar?
Wir hatten in der Vergangenheit häufig Probleme mit zu großen bzw. nicht einstellbaren Buffern an nicht-FT232 Bausteinen, was letztlich eine zuverlässige Kommunikation verhindert hat...
Zitat von: mirror am 13 November 2016, 18:32:31
anbei die Daten der ecoCompact und des VCR700 Reglers (hatte ich schon mal auf Deinem github gepostet). Die bai.csv ist eine modifizierte 08.bai.HW7401.csv:
Dein Produktcode ist wesentlich neuer, als das, was im github an solchen verfügbar ist. Insofern kann es seht gut sein, dass der gesuchte Wert nicht mehr in dem bis jetzt bekannten Register zu finden ist.
Du könntest jetzt das Script readall.sh (https://github.com/john30/ebusd/blob/master/contrib/scripts/readall.sh) nutzen, um nach einem 2-byte Wert zu suchen, der Deiner aktuellen Anzeige entspricht.
D.h. Wert aus der Anzeige nehmen und in Hex wandeln, die beiden Bytes vertauschen, "02" vorne dran stellen, und dann im Ergebnis von readall.sh nach dieser Folge suchen.
Also z.B. bei Anzeige des Werts 1590:
1590=0x0636.
In eBUS Format dann 023606.
[EDIT]: readall.sh ist natürlich das falsche Skript, ich meinte das Skript allregisters.sh (https://forum.fhem.de/index.php/topic,29737.msg497570/topicseen.html#msg497570) im Anhang der Message von damals.
Hallo John!
ZitatWir hatten in der Vergangenheit häufig Probleme mit zu großen bzw. nicht einstellbaren Buffern an nicht-FT232 Bausteinen, was letztlich eine zuverlässige Kommunikation verhindert hat...
Wenn ich es richtig verstanden habe (bitte korrigiere mich) dann geht es dabei um die Bus Arbitrierung. Nachdem der Empfänger erkannt hat dass er jetzt senden darf, hat er nur eine gewisse Zeit zur Verfügung in der er mit dem Senden beginnen muss. Ich glaube mich erinnern zu können dass pah das Problem in diesem Thread einmal auf das Transmit-FIFO zurückgeführt hat. Dadurch dauert es einfach zu lange bis tatsächlich gesendet wird.
Ich habe mich einmal wegen eines ähnlichen Problems mit all den UARTs auseinandersetzen müssen und bin denke ich auf die eigentliche Ursache gestossen. Es gibt verschiedene UART-Familien und nicht alle sind für Anwendungen dieser Art geeignet. Ein Typ 32590 beispielsweise hat die Möglichkeit, sofort nach dem Empfang eines Zeichens im Receiver einen Interrupt am Prozessor auszulösen. Das wäre O.K.
Ein Typ aus der Familie 16650 hat als minimal mögliche Einstellung nur 1/8 Receiver FIFO full. Diese Familie gibt's mit 16 Byte FIFO, bis zu 128 Byte FIFO. Das heisst es müssen am Receiver wenigstens 2 oder 4 oder sonst wieviele Bytes eintreffen bevor der Interrupt ausgelöst wird. Treffen die nicht ein, hat der Chip noch ein "Timeout" sodass er dann trotzdem einen Interrupt auslöst. Das Timeout liegt aber auch in der Größenordnung einiger Character. Damit muss die Arbitrierung schiefgehen, weil das Timeout verstreicht falls die empfangenen Character nicht genau mit dem 1/8 FIFO Trigger Level zusammenfallen.
Jetzt ist natürlich richtig, dass der Linux-Treiber mit VMIN=1 und VTIME=0 korrekt eingestellt ist um bei genau einem empfangenen Byte zu reagieren, aber was kann denn die Software schon ausrichten, wenn die Hardware dahinter nicht mitspielt. Nicht mitspielen kann.
Der Rasperry Pi 3 hat den Broadcom BCM2837 eingebaut und dieser verwendet lt. Datenblatt einen 16C650-ähnlchen UART. Ich nehme an bei den älteren RASPIs wird das genauso sein. Das würde erklären warum die Schaltung direkt an der Seriellen des RASPI nicht funktioniert.
Welchen UART der CP2102 verwendet konnte ich bis jetzt nicht herausfinden. Würde mich sehr interessieren falls das jemand schafft. Prinzipiell denke ich aber dass es ein "guter" sein muss, denn wenn man das Oszillogramm betrachtet (Senden.jpg - mein vorheriger Post) dann kann man die Turnaround-Zeit sehen, also die Zeit die verstreicht vom Hören des letzten Bytes bis zum Senden des ersten Bytes (kleine Pegel - grosse Pegel) und diese Zeit ist sicher nicht um 1 oder 2 FIFO Füllungen verzögert.
Zitat von: galileo am 15 November 2016, 12:13:36
Jetzt ist natürlich richtig, dass der Linux-Treiber mit VMIN=1 und VTIME=0 korrekt eingestellt ist um bei genau einem empfangenen Byte zu reagieren, aber was kann denn die Software schon ausrichten, wenn die Hardware dahinter nicht mitspielt. Nicht mitspielen kann.
das hängt immer gravierend von der Modul Implementierung und den Möglichkeiten der Hardware ab. Der CP210x kann zumindest einen Timeout beim Lesen, der allerdings nicht verwendet wird.
Naja, solange das Interface mitspielt, ist ja alles gut :)
Zitat von: Prof. Dr. Peter Henning am 01 März 2016, 02:42:15
Edit: Habe es gelöst. War ein Problem der Timeouts auf einem wesentlich schnelleren Rechner. Danke für die Anteilnahme
hallo pah, ich habe im Moment auch das Problem, dass mein Befehl zerlegt wird. welche Timeouts musstest du ändern?
lg Primi
Edit: Habe es gelöst. War mein Fehler... hatte aus welchen Gründen das Attribut RequestSeperator = 1 eingestellt. Daher hat er alle cmd's beim Auftreten des Zeichens "1" getrennt...
Hallo,
ich habe mich im Forum angemeldet weil ich nicht weiterkomme. Ich vermute das meine Anlage zu neu ist und es noch keine csv-Dateien gibt.
Die Anlage besteht aus:
0010015603;ecoCOMPACT;VSC 206/4-5 150;21163800100156033100005407N2
;;VRC 700/4;
002184843;;VR70;21163400201848430082013423N2
Die eBus-Schnittstelle und das Programm läuft. Ich habe folgendes mit einem scan ausgelesen:
pi@raspberrypiwlan ~ $ ebusctl scan result
08;Vaillant;BAI00;0116;9602;21;16;38;0010015603;3100;005407;N2
15;Vaillant;70000;0419;4603
52;Vaillant;VR_70;0109;2903;21;16;34;0020184843;0082;013423;N2
pi@raspberrypiwlan ~ $ ebusctl info
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 23
masters: 3
messages: 212
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
und wie man sieht fehlen die csv-Dateien für den VRC 700/4 und für den VR70, dazu habe ich noch nichts gefunden.
Zitat von: hermann65 am 29 November 2016, 21:16:52
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
und wie man sieht fehlen die csv-Dateien für den VRC 700/4 und für den VR70, dazu habe ich noch nichts gefunden.
Für die VRC700 gibt es bereits eine erste Fassung im aktuellen Stand vom git (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.700.csv).
Allerdings ist dafür noch kein neues Release verfügbar.
Wenn dich aktuelle Erkenntnisse zum VR70 interessieren, schicke mir bitte per PN deine Mailadresse.
Allerdings gibt es aktuell nur 4 Meldungen, die ich dazu interpretieren kann und deren Inhalt steht eigentlich auch im VRC700.
Ich bin allerdings immer an bereitwilligen Testern interessiert, gerade mit unterschiedlichen Systemkonfigurationen, um vielleicht auch noch fehlende Sachen im VRC zu finden!
Kleine Ankündigung: ebusd Version 2.4 (https://github.com/john30/ebusd/blob/master/ChangeLog.md#24-2016-12-10) ist fertig und als Release (https://github.com/john30/ebusd/releases/tag/v2.4) verfügbar.
Das ist auch wahrscheinlich die letzte Version 2, jetzt geht es an Version 3 mit neuen Features.
Wünsche werden noch angenommen ;) und können in den Github Issues (https://github.com/john30/ebusd/milestone/2) für Milestone 3.0 hinterlegt werden. Die Issues mit den meisten +1 reactions werden zuerst bearbeitet :)
VG John
Hallo John,
Ich habe bisher mit ebusd V2.1 gearbeitet. Nun habe ich mit
dpkg -i --force-overwrite ebusd-2.4_armhf.deb
ein Upgrade gemacht. Nach dem Reboot ging das ebusctl nicht mehr:
pi@raspberrypi:~ $ ebusctl info
error connecting to localhost:8888
Nachdem ich mit
dpkg -i --force-overwrite ebusd-2.1_armhf.deb
die alte Version wieder drüber installiert habe, ging's wieder.
Ich hab das mehrmals probiert, immer mit dem gleichen Effekt.
Mache ich etwas falsch ? Oder vergesse ich etwas ?
LG Eduard
Zitat von: galileo am 11 Dezember 2016, 19:16:39
Ich habe bisher mit ebusd V2.1 gearbeitet. Nun habe ich mit
dpkg -i --force-overwrite ebusd-2.4_armhf.deb
ein Upgrade gemacht. Nach dem Reboot ging das ebusctl nicht mehr:
pi@raspberrypi:~ $ ebusctl info
error connecting to localhost:8888
Danke für den Hinweis!
Da war leider noch ein kleiner Fehler drin, der sich offensichtlich nur auf dem Raspi zeigt. Ich baue das Paket gerade neu.
UPDATE: Paket ist neu gebaut und im Release hochgeladen. Könntest Du das bitte nochmal probieren?
UPDATE die zweite: Also da ist noch ein zweiter Wurm drin, das kann ich Euch so nicht guten Gewissens in die Hand geben.
Darum: Release 2.4 nochmal um ein paar Tage verschoben.
ich fange gerade erst an meine Vaillant Heizung über fhem zu steuern.
ich habe ein raspberry und ein ebus Adapter von eservice und ich habe eine auromatic 620
eigentlich dachte ich, es sieht gar nicht schleicht aus mit den werten. jedoch scheinen die werte nicht ganz zu passen. Rücklauf -13.5 ???
mein eigentliches Ziel : ich möchte die 2 Heizkreise (Wohnung 1 /und Wohnung 2) aus der ferne unterschiedlich konfigurieren können. also absenken wenn ich nicht da bin und 2 tage vorher anheben, damit die Fußbodenheizung schon warm ist wenn ich komme also so art schalter Heizung Frostschutz an / aus nur für jeden der beide heizkreise separat.... naja und natürlich braucht dann auch kein wasser warm gemacht werden.
es wäre schön, wenn ihr mir weiterhelfen könntet
hier die Infos :
pi@raspberrypi:~ $ ebusctl info
version: ebusd 2.4.2e9d65b
signal: acquired
symbol rate: 60
reconnects: 0
masters: 6
messages: 1099
conditional: 24
poll: 0
update: 8
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.0010007508.inc" ([PROD='0010007508';'0010007510';'0010007512';'0010007514';'0010007516';'0010007518';'0010007520';'0010007522';'0010007524';'0010007526';'0010007688';'0010007692';'0010007696';'0010007700';'0010007704']), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 52: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/52.mc2.mc.4.csv"
address 53: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/53.mc2.mc.5.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
pi@raspberrypi:~ $ ebusctl scan result
06;Vaillant;PMS00;0107;4302
08;Vaillant;BAI00;0703;7401;21;12;34;0010007512;3100;005340;N5
0a;Vaillant;PMW00;0117;4402;21;12;25;0010007267;3110;006423;N3
12;Vaillant;PMW00;0117;4402;21;12;25;0010007267;3110;006423;N3
15;Vaillant;UI ;0507;6201;21;12;27;0020080465;0907;009346;N2
23;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
25;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
26;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
44;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
50;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
52;Vaillant;MC2 ;0500;6301;21;12;27;306782<<<<;0907;006657;N9
53;Vaillant;MC2 ;0500;6301;21;12;27;306782<<<<;0907;006657;N9
ec;Vaillant;SOLSY;0500;6301;21;12;27;0020080463;0907;008494;N4
ed;Vaillant;PMS00;0107;4302;21;12;26;0020071488;3110;005587;N3
fc;Vaillant;PMW00;0117;4402;21;12;25;0010007267;3110;006423;N3
pi@raspberrypi:~ $ ebusd --checkconfig --scanconfig
2016-12-14 09:58:09.786 [main notice] ebusd 2.4.2e9d65b performing configuration check...
2016-12-14 09:58:10.966 [main notice] found messages: 5938 (445 conditional on 143 conditions, 2 poll, 56 update)
2016-12-14 09:58:11.017 [main notice] ebusd stopped
pi@raspberrypi:~ $
Nicht so leicht aufgeben, das wird noch. Mit der Auromatic läuft das nämlich ganz hervorragend.
LG
pah
vielleicht noch wichtig: es ist eine auromatic 630
Wie gesagt die werte passen nicht so recht. ich habe es über den ebus installer installiert. könnte da das Problem liegen?
schau doch mal in die "bai01.cfg" was hier bei dir abgefragt wird.
# vorlauftemperatur
get Vorlauf cmd {"r -f flowtemp temp\n"}
#get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -f sdtrt temp\n"}
#get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
Soweit ich sehe, stimmt ja die Vorlauftemperatur (laut deinem Bild), mit derselben Methode kannst auch die Rücklauftemperatur holen. Entweder aus dem Status auslesen (ist hier mit # gesperrt) oder mit den entsprechenden Namen. Kann ja sein, das dies bei der Auromatic im csv anders bezeichnet wird.
Ich würde so vorgehen: Also zunächst schauen welches csv für die Auromatic geladen wird und dann in diesem File nach Ruecklauf suchen, dann kennst du die exakte Bezeichnung.
Ich habe leider keine Auromatic, daher kenne ich auch die Bezeichnung für "Rücklauf" nicht.
LG
@Reinhart
danke übrigens für deine Erklärungen hier im Forum ... ich bin auf einen Artikel von dir gestoßen, der mir schon mal ein wenig licht ins dunkle bringt.
ich denke meine anbindung an den EBUS ist okay. ebusctl find bringt einiges. da ich scheinbar auch alles auslesen kann, wollte ich im kleinen mal probieren eine wert zu ändern, den ich dann am Display sehe.
Ich weiß nicht wie ich mich da irren konnte, aber es ist definitis eine VRS 620 also auromatic 620.
ich würde gern die Warmwassertemperatur ändern... das könnte ich am Display auch nachvollziehen.
hat jemand ein Beispiel für mich? was ich bei der 620 sofort testen kann?
was ist eigentlich bai hc cc hwc mc mc.4 mc.5 pms sc ui ?
schau doch mal mit "ebusctl i" welche csv Files bei dir vom eBus geladen werden, dann kennst du genau die Bezeichnungen die vom eBus geliefert werden.
so in etwa:
pi@raspberry2 ~ $ ebusctl i
version: ebusd 2.1.6311149
signal: acquired
symbol rate: 119
masters: 3
messages: 429
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 26: slave, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002"
address 31: master #8, ebusd
address 36: slave #8
bei meiner Konstellation wären das bai.308523.inc, 08.bai.csv, 15.430.csv
Dann brauchst du nur die Files öffnen und schauen was da so alles möglich (eingetragen) ist.
LG
oh danke für die antwort...
in die bai.0010007508.inc habe ich schon mal rein geschaut. finde nicht so wirklich warmwassertemperatur. kann ich alle werte nur lesen (r) oder auch schreiben (w) gibt es dafür eine liste welche werte beschreibbar sind?
bei mir ist es:
version: ebusd 2.4.2e9d65b
signal: acquired
symbol rate: 48
reconnects: 0
masters: 5
messages: 1097
conditional: 24
poll: 0
update: 8
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "bai.0010007508.inc" ([PROD='0010007508';'0010007510';'0010007512';'0010007514';'0010007516';'0010007518';'0010007520';'0010007522';'0010007524';'0010007526';'0010007688';'0010007692';'0010007696';'0010007700';'0010007704']), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address 52: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/52.mc2.mc.4.csv"
address 53: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/53.mc2.mc.5.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
du hast ja jede Menge Geräte die da gefunden wurden.
Rücklauf und Warmwassersolltemperatur findest du in der bai.0010007508.inc
r;wi,,HwcTempMax,d.20 Max. WW Temperatur,,,,"D900",,,temp,,,Max. Speichersollwert. Begrenzt den max. Einstellbereich des Potentiometers (Rechtsanschlag).
r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,tempmirrorsensor,,,Rücklauftemperatur
beschreiben kannst du alles was mit "w" beginnt.
LG
Zitat von: qwert4u am 15 Dezember 2016, 18:28:48
finde nicht so wirklich warmwassertemperatur.
Nun, in der CSV der 620 scheint es keine Warmwassertemperatur zu geben... oder ich finde Sie nicht.
Du könntest die der Trinkwasserstation direkt setzen: ManualTappingTempDesired
Aber ob die auch zurück zur 620 gemeldet wird?!
Ansonsten suche doch mal in 'ebusctl find' nach anderen "Tapping"...
Sieht mir alles etwas durcheinander aus, da die 620 auf so viele CSV und Client-IDs aufgeteilt ist - bei meiner VRC700 ist alles über die 15 les-/schreibbar.
Du hast z.B einen Solarkreis mit solsy.sc.csv
Probier doch mal Storage?Sensor? (Storage1Sensor3) aus, da bekommst Du die Puffertempeaturen.
Ansonsten mit ebusctl find temp suchen und welche davon lesen und überprüfen
@sven77
ich habe mal versucht folgendes abzufragen
pi@raspberrypi:~ $ ebusctl r -c hwc manualtappingtempdesired
45.00
pi@raspberrypi:~ $ ebusctl r -c hwc actualtappingtempdesired
60.00
pi@raspberrypi:~ $ ebusctl r -c hwc autotappingtempdesired
60.00
bei manualtappingtempdesired kommt ein wert 45 im Display der Steuerung sehe ich 60grad
actualtappingtempdesired und autotappingtempdesired kann man nur lesen laut csv
@ Reinhart
pi@raspberrypi:~ $ ebusctl r HwcTempMax
65.00
es stehen dort 65 am display wie gesagt 60
wie gesagt, ich kenne leider das Gerät nicht und kann dir daher nur allgemeine Tipps geben. Eventuell findest du noch weitere Personen die genau dieses Gerät haben und auch schon damit experimentiert haben. Aber so wie du es jetzt durchführst, bist auf dem richtigen Weg.
Einen Wert setzen und schauen was sich real geändert hat. Irgendwann findest du die richtige Logik oder zumindest jene Werte die du benötigst. Eventuell einen Wert an der Auromatic ändern und protokollieren was übern Bus kommt. Die ganze eBus Entwicklung hat ja auf diese Methode aufgebaut wenn du dir die ersten Artikel anschaust und was heute daraus geworden ist sind es gewaltige Schritte.
LG
Zitat von: john30 am 10 Januar 2016, 16:55:42
Wenn es nur um eine einmalige Speicherladung geht, dann könnte mal jemand probieren ob das mit "write -h 08b505020601" funktioniert oder evtl. sogar mit "write -h 15b505020601". Das aktiviert zumindest bei einer EHP (allerdings auf einer anderen Zieladresse) eine einmalige Speicherladung.
Nach Absetzen des Befehls sollte höchstens eine Minute später der ladevorgang beginnen und im Controller erkenntlich sein.
Ach so, Antwort auf den Request ist zumindest bei mir einfach nur "00".
Hallo,
nach ca. einem Jahr Pause habe ich mich nun mal wieder mit dem Thema ebusd beschäftigt.
Hier mein Setup:
-Vaillant Geotherm plus VWS 62/3
-ebus Koppler RS232 von eservice-online
-USB-RS232 Adapter
-Raspberry Pi 3 mit ebusd 2.4
Ich habe bereits mehrere Tage mit der Kommunikation auf dem ebus gekämpft. Immer CRC Fehler, falsche oder gar keine Nachrichten usw. Zunächst bin ich davon ausgegangen, dass es am falsch eingestellten Poti lag, jetzt konnte ich jedoch das USB-RS232 Kabel als Schuldigen identifizieren. Ich habe hier zwei Belkin Kabel, die an anderen Geräten fehlerfrei funktionieren. Nur mit dem ebus Koppler machen sie beide Probleme. Ein günstiges Chinesen Noname Kabel funktioniert jetzt endlich fehlerfrei...
read und write Befehle funktionieren, mein einziges Problem ist jedoch die "Einmalige Speicherladung". Ich möchte an meinem Terminal im Badezimmer die Möglichkeit haben, bei Bedarf schon mal die Speicherladung zu aktiveren. Leider klappt das noch nicht so ganz.
localhost: w -c mc load onwird zwar mit done quittiert, es passiert aber nichts.
Die von john vorgeschlagenen hex Befehle werden abgelehnt:
localhost: write -h 08b505020601
ERR: element not found
localhost: write -h 15b505020601
ERR: element not foundMache ich hier irgendetwas falsch oder liegt das an der neueren ebusd Version, dass sie direkt abgelehnt werden?
Hier noch mal der Vollständigkeit halber der scan result:
08;Vaillant;EHP00;0419;7201
15;Vaillant;UIH00;0374;6901
23;Vaillant;EHP00;0419;7201
25;Vaillant;EHP00;0419;7201
50;Vaillant;EHP00;0419;7201Danke und Gruß
Sven
Bei mir funktioniert die einmalige Speicherladung mit
25b505020601 -> on 00 -> off
hier hat es bei jemanden mit einem anderen Kreis funktioniert (suche Speicherladung)
Zitat von: jkriegl am 16 Dezember 2016, 19:16:48
Bei mir funktioniert die einmalige Speicherladung mit
25b505020601 -> on 00 -> off
hier hat es bei jemanden mit einem anderen Kreis funktioniert (suche Speicherladung)
25b505020601 bringt leider auch keinen Erfolg.
50b505020601 wird immerhin schon mal mit 00 quittiert, passieren tut aber leider immer noch nichts...
localhost: w -h 50b505020601
00Bei allen anderen Empfängern (08, 15, 23, 25) bekomme ich nur ERR: element not found
ist die Temperaturdifferenz Ist - Soll gross genug? (erinner mich irgendwie an 7 Grad) und immer etwas warten.
Zitat von: jkriegl am 16 Dezember 2016, 20:25:55
ist die Temperaturdifferenz Ist - Soll gross genug? (erinner mich irgendwie an 7 Grad) und immer etwas warten.
Werd ich am Sonntag noch mal probieren. Kann sein das es gerade in dem Bereich war. Habs vorhin übers Bedienfeld aktiviert nachdem es über ebusd nicht ging. Darum bin ich jetzt bei 55°C HWTemp. Will jetzt nicht auf 65 stellen nur um das zu testen, der Heizstab ist mir zu teuer ;)
Zitat von: Goodevil am 16 Dezember 2016, 16:49:07
Speicherladung zu aktiveren. Leider klappt das noch nicht so ganz.
localhost: w -c mc load on
wird zwar mit done quittiert, es passiert aber nichts.
Hm, ich schätze dass der Mischer schlicht und einfach nicht für die Speicherladung verantwortlich ist, sondern die Wärmepumpe.
D.h. das load müsste an eine andere Adresse gesendet werden.
An den ganzen quick Kommandos und den generischen B504/B505 Definitionen bin ich gerade dran, der erste Teil für Mischer ist bereits im de Zweig der ebusd-configuration eingecheckt.
Jetzt frage ich mich allerdings, ob Du Speicherladung für Warmwasser oder für den Puffer der Heizkreise anstoßen willst.
Zitat von: Goodevil am 16 Dezember 2016, 16:49:07
Die von john vorgeschlagenen hex Befehle werden abgelehnt:
localhost: write -h 08b505020601
ERR: element not found
Nachdem Du den aktuellen ebusd im Einsatz hast, lautet das Kommando zum Absetzen beliebiger hex Nachrichten "hex" (und nicht mehr "write -h", denn das toleriert die Anfrage nur noch, wenn eine entsprechende write Message auch definiert ist). Das "hex" Kommando musst Du evtl. noch erlauben mit ebusd Startparameter "--enablehex".
Dann kannst Du also "hex 08b505020601" absetzen und solltest eine andere Antwort als "not found" bekommen.
VG John
Zitat von: john30 am 10 Dezember 2016, 11:39:33
Kleine Ankündigung: ebusd Version 2.4 (https://github.com/john30/ebusd/blob/master/ChangeLog.md#24-2016-12-17) ist fertig und als Release (https://github.com/john30/ebusd/releases/tag/v2.4) verfügbar.
Zitat von: john30 am 11 Dezember 2016, 20:48:26
Da war leider noch ein kleiner Fehler drin, der sich offensichtlich nur auf dem Raspi zeigt. Ich baue das Paket gerade neu.
Darum: Release 2.4 nochmal um ein paar Tage verschoben.
So, Release 2.4 (https://github.com/john30/ebusd/releases/tag/v2.4) funktioniert nun wie erwartet.
Viel Spaß damit :-)
VG John
Danke für Deine Bemühungen John.
Ich werde diese Version nächste Woche mal testen obwohl ich noch die Version 2.0 nutze und damit bisher alles läuft was ich benötige. Bisher nutzte ich ebusd nur zur Analyse und Darstellung der Verläufe (Temperaturen, Gasverbrauch etc.) mit rrdtool .
Zitat von: henry22 am 17 Dezember 2016, 16:52:27
Ich werde diese Version nächste Woche mal testen obwohl ich noch die Version 2.0 nutze und damit bisher alles läuft was ich benötige. Bisher nutzte ich ebusd nur zur Analyse und Darstellung der Verläufe (Temperaturen, Gasverbrauch etc.) mit rrdtool .
Mach ich auch, allerdings mit munin und dem zugehörigen ebusd Plugin (https://github.com/john30/ebusd/tree/master/contrib/munin) :-)
Hallo!
Ich habe nun auch eine neue Vaillant Heizung bekommen und gleich gestartet mit eBus Adapter diese in meine FHEM Installation integrieren zu wollen. Habe nun dieses Forum und die Anleitungen von John und anderen durchgearbeitet. Ich bekomme soweit erstmal eine Verbindung:
# ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 25
reconnects: 0
masters: 4
messages: 547
conditional: 24
poll: 0
update: 8
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"Leider werden mir aber nur ganz wenige Werte angezeigt:
ebusctl find -p
broadcast datetime = 4.000;02:39:02;18.12.2016
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast ident = Vaillant;SOLSY;0500;6301
broadcast load = no data stored
broadcast outsidetemp = 4.000
broadcast signoflife = no data stored
broadcast vdatetime = 02:39:02;18.12.2016Ich würde gern alle Werte, wenn möglich bekommen und zumindest auf gewisse Konfigurationen einwirken vom FHEM aus, z.B.:
- Pumpen (an/aus)
- Ventile
- Temperaturfühler im Speicher
- (späterer Ausbau) Solarthermie
- usw...
Habt Ihr eine Idee, was mir noch fehlt? Bin etwas ratlos...
Danke!
Zitat von: bacanol am 18 Dezember 2016, 02:46:31
Ich habe nun auch eine neue Vaillant Heizung bekommen und gleich gestartet mit eBus Adapter diese in meine FHEM Installation integrieren zu wollen. Habe nun dieses Forum und die Anleitungen von John und anderen durchgearbeitet. Ich bekomme soweit erstmal eine Verbindung:
Ich würde sagen, Dir fehlt das Heizgerät auf Adresse 08 bzw. 03.
Was produziert denn bei Dir die Wärme?
Zitat von: bacanol am 18 Dezember 2016, 02:46:31
Leider werden mir aber nur ganz wenige Werte angezeigt:
ebusctl find -p
Mit obigem Kommando bekommst Du nur das, was ausschließlich passiv mitgelesen wird.
Versuch mal statt dessen:
ebusctl find -d -r -w -pAber ohne Heizgerät fehlt natürlich sehr viel...
Zitat von: john30 am 18 Dezember 2016, 08:46:55
Ich würde sagen, Dir fehlt das Heizgerät auf Adresse 08 bzw. 03.
Was produziert denn bei Dir die Wärme?
Mit obigem Kommando bekommst Du nur das, was ausschließlich passiv mitgelesen wird.
Versuch mal statt dessen:
ebusctl find -d -r -w -p
Aber ohne Heizgerät fehlt natürlich sehr viel...
Als Wärmeproduzenten habe ich eine VSC196-150, einen Walltherm und Solarthermie (derzeit noch in Kartons). Kommando probiere ich gleich mal...
Gesendet von iPhone mit Tapatalk
Zitat von: john30 am 18 Dezember 2016, 08:46:55
Ich würde sagen, Dir fehlt das Heizgerät auf Adresse 08 bzw. 03.
Was produziert denn bei Dir die Wärme?
Mit obigem Kommando bekommst Du nur das, was ausschließlich passiv mitgelesen wird.
Versuch mal statt dessen:
ebusctl find -d -r -w -p
Aber ohne Heizgerät fehlt natürlich sehr viel...
Habe nun einmal das Kommando abgesendet, da kommt in der Tat mehr:
ebusctl find -d -r -w -p
broadcast datetime = 5.562;11:48:02;18.12.2016
broadcast ident = Vaillant;SOLSY;0500;6301
broadcast outsidetemp = 5.562
broadcast vdatetime = 11:48:02;18.12.2016
cc Mode = 30;auto;02;off
hc currenterror = -;-;-;-;-
hc DateTime = valid;11:47:48;18.12.2016;5.562
hc SumFlowSensor = -13.94;cutoff
hwc currenterror = -;-;-;-;-
hwc Mode = 65;auto;00;off
hwc Status = 72;on;-;65
hwc Timer.Monday = 00:00;-:-;-:-;-:-;-:-;-:-;selected
mc Mode = 23;auto;03;off
mc Status = 42;off;44.62;23
mc Timer.Monday = 05:00;22:00;-:-;-:-;-:-;-:-;Mo-Su
scan.0a = Vaillant;PMW01;0206;8302
scan.0a id = 21;16;42;0010014311;3110;011034;N9
scan.12 = Vaillant;PMW01;0206;8302
scan.12 id = 21;16;42;0010014311;3110;011034;N9
scan.15 = Vaillant;UI ;0508;6201
scan.15 id = 21;15;02;0020080465;0907;005492;N7
scan.23 = Vaillant;SOLSY;0500;6301
scan.23 id = 21;15;02;0020080463;0907;005499;N7
scan.25 = Vaillant;SOLSY;0500;6301
scan.25 id = 21;15;02;0020080463;0907;005499;N7
scan.26 = Vaillant;SOLSY;0500;6301
scan.26 id = 21;15;02;0020080463;0907;005499;N7
scan.44 = Vaillant;SOLSY;0500;6301
scan.44 id = 21;15;02;0020080463;0907;005499;N7
scan.50 = Vaillant;SOLSY;0500;6301
scan.50 id = 21;15;02;0020080463;0907;005499;N7
scan.ec = Vaillant;SOLSY;0500;6301
scan.ec id = 21;15;02;0020080463;0907;005499;N7
scan.fc = Vaillant;PMW01;0206;8302
scan.fc id = 21;16;42;0010014311;3110;011034;N9
cc Timer.Friday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Monday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Saturday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Sunday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Thursday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Tuesday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
cc Timer.Wednesday = -:-;-:-;-:-;-:-;-:-;-:-;Mo-Su
mc RoomTempOffset = 0.00Allerdings kann ich zu Pumpenschaltern (on/off) oder Mischerstati (open,closed) noch nicht das sehen, was mir das kleine Vaillant Interface zeigt. Muss ich da ggf. Kanäle direkt ansprechen? Wenn ja, welche?
Habe jetzt nochmal etwas herumprobiert und das Logfile genauer studiert. Da tauchen einige Dinge auf, die mich etwas stutzig machen:
2016-12-18 12:14:12.887 [main notice] starting initial scan for fe
2016-12-18 12:14:13.129 [main error] error reading templates in /etc/ebusd/vaillant: ERR: element not found, last error: /etc/ebusd/vaillant/_templates.csv:45
2016-12-18 12:14:13.132 [main error] error reading common config file /etc/ebusd/vaillant/broadcast.csv: ERR: duplicate entry
2016-12-18 12:14:13.133 [main notice] read common config file /etc/ebusd/vaillant/general.csv
2016-12-18 12:14:13.134 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-12-18 12:14:13.135 [main error] error reading scan config file /etc/ebusd/vaillant/0a.pmw.hwc.csv for ID "pmw01", SW0206, HW8302: ERR: element not found
2016-12-18 12:14:13.676 [update notice] unknown MS cmd: 10ecb5040121 / 050000044b00
2016-12-18 12:14:14.428 [update notice] unknown MM cmd: 103f050105aa2c2c0500
2016-12-18 12:14:14.925 [update notice] unknown MS cmd: 1026b509040e100000 / 00
2016-12-18 12:14:15.252 [main error] error reading scan config file /etc/ebusd/vaillant/15.ui.csv for ID "ui", SW0508, HW6201: ERR: element not found
2016-12-18 12:14:15.505 [update notice] unknown MS cmd: 1026b509030d0400 / 0321ffaa
2016-12-18 12:14:15.682 [update notice] unknown MS cmd: 10ecb5040101 / 09000200000207000100
2016-12-18 12:14:16.008 [update notice] unknown MS cmd: 100ab504010d / 054801008041
2016-12-18 12:14:17.388 [main error] error reading scan config file /etc/ebusd/vaillant/26.solsy.hc.csv for ID "solsy", SW0500, HW6301: ERR: element not found
2016-12-18 12:14:17.496 [update notice] unknown MS cmd: 10ecb5050427005a00 / 00
2016-12-18 12:14:18.541 [update notice] unknown MS cmd: 10ecb5040110 / 0a3105100200800080e304
2016-12-18 12:14:19.406 [update notice] unknown MS cmd: 1026b5040101 / 09160200000380000100
2016-12-18 12:14:19.515 [main error] unable to load scan config 44: no file from /etc/ebusd/vaillant with prefix 44. found
2016-12-18 12:14:19.643 [update notice] unknown MS cmd: 10ecb505082b0f080000000080 / 00
2016-12-18 12:14:20.558 [update notice] unknown MS cmd: 1026b5040100 / 0a0320141218120716d005
2016-12-18 12:14:21.658 [main error] error reading scan config file /etc/ebusd/vaillant/50.solsy.mc.csv for ID "solsy", SW0500, HW6301: ERR: element not found
2016-12-18 12:14:23.802 [main error] error reading scan config file /etc/ebusd/vaillant/ec.solsy.sc.csv for ID "solsy", SW0500, HW6301: ERR: element not found
Jemand eine Idee?
Ich habe folgende Versionen im Einsatz:
ii ebusd 2.4 armhf eBUS daemon.
in ebusd-configuration <keine> all (keine Beschreibung vorhanden)
Zitat von: bacanol am 18 Dezember 2016, 09:03:47
Als Wärmeproduzenten habe ich eine VSC196-150, einen Walltherm und Solarthermie (derzeit noch in Kartons). Kommando probiere ich gleich mal...
Hängt Deine VSC196 am eBUS überhaupt dran?
Zitat von: bacanol am 18 Dezember 2016, 12:17:07
Habe jetzt nochmal etwas herumprobiert und das Logfile genauer studiert. Da tauchen einige Dinge auf, die mich etwas stutzig machen:
2016-12-18 12:14:12.887 [main notice] starting initial scan for fe
2016-12-18 12:14:13.129 [main error] error reading templates in /etc/ebusd/vaillant: ERR: element not found, last error: /etc/ebusd/vaillant/_templates.csv:45
2016-12-18 12:14:13.132 [main error] error reading common config file /etc/ebusd/vaillant/broadcast.csv: ERR: duplicate entry
Wie hast Du denn die Konfigurationsdateien installiert? Über ein ebusd-configuration Release? Wenn ja, welches genau?
Am besten Du schickst mir mal Dein gesamtes Verzeichnis etc/ebusd/ (an ebusd@ebusd.eu), denn da ist sicher etwas nicht in Ordnung.
Guten Abend zusammen!
Nach einigen Stunden zähen Ringens und dieses sehr hilfreichend Freds hab ich mein neues Heizsystem endlich am sprechen.
Die Kernkomponente, nämlich die Wärmepumpe, fehlt aber scheinbar noch in der Definition.
Der Reihe nach...
Meine Installation (Vaillant):
Grundwasser-WP Flexotherm VWF157
Mischermodul VR70
Regler Multimatic VRC700
Solarladestation VPS20
Trinkwasserstation VPM35
Die Recovair 350 hängt an einem zweiten Ebus. Kommt später....
Das Ergebnis meines Ebus-Scans:
version: ebusd 2.4.be55283
signal: acquired
symbol rate: 23
reconnects: 0
masters: 5
messages: 516
conditional: 15
poll: 0
update: 8
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0305;HW=0403"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0305;HW=0403"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
Meine Frage:
Wie bringe ich dem Ebus nun bei, doch mal testweise die 08.ehp.csv anzuziehen (in der Hoffnung, die Telegramme sind nicht so unterschiedlich)?
Alternative ANsatzpunkte sind willkommen :-)
Grüße, Andi
Morgen!
Gut, die Datei hab ich mittlerweile eingebunden...allerdings ohne Erfolg. Die Nachrichten scheinen doch recht unterschiedlich zu sein.
Konnte bereits jemand mit der FlexoTherm Erfahrungen sammeln?
Grüße, Andi
hat noch jemand eine VRS 620? der mir in der Konfiguration behilflich sein kann?
Zitat von: john30 am 18 Dezember 2016, 13:53:24
Wie hast Du denn die Konfigurationsdateien installiert? Über ein ebusd-configuration Release? Wenn ja, welches genau?
Am besten Du schickst mir mal Dein gesamtes Verzeichnis etc/ebusd/ (an ebusd@ebusd.eu), denn da ist sicher etwas nicht in Ordnung.
Habe etwas romprobiert, wird aber derzeit nicht besser. Es gibt noch einen weiteren Threat hier, der das Thema behandelt. Aber es scheint, als ob irgendwas noch nicht richtig passt. Habe Dir @john30 einmal die Geschichte per Mail zugeschickt. Vielen Dank!!
So nun alles neu eingespielt (Danke an john30) und folgende Ergebnisse:
ebusctl find -p:
broadcast datetime = 4.500;00:08:03;24.12.2016
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast outsidetemp = 4.500
broadcast signoflife = no data stored
broadcast vdatetime = 00:08:03;24.12.2016
myCustom Status01 = no data stored
myCustom Status02 = no data stored
myCustom1 DateTime = no data stored
myCustom2 Pumpenstatus = no data stored
ebusctl find -d -r -w -p:
broadcast datetime = 4.500;00:11:00;24.12.2016
broadcast outsidetemp = 4.500
broadcast vdatetime = 00:10:04;24.12.2016
hc currenterror = -;-;-;-;-
hc DateTime = valid;00:11:24;24.12.2016;4.500
hc SumFlowSensor = -13.94;cutoff
hwc currenterror = -;-;-;-;-
hwc Mode = 65;auto;02;off
hwc Status = 0;off;-;65
mc Mode = 25;eco;0;0;off;mixer;night
mc Status = 0;off;30.94;5
scan.0a = Vaillant;PMW01;0206;8302
scan.12 = Vaillant;PMW01;0206;8302
scan.15 = Vaillant;UI ;0508;6201
scan.26 = Vaillant;SOLSY;0500;6301
scan.44 = Vaillant;SOLSY;0500;6301
scan.50 = Vaillant;SOLSY;0500;6301
scan.ec = Vaillant;SOLSY;0500;6301
ui YieldThisYear = 71;138;171;428;451;0;0;0;0;0;0;0
mc RoomTempOffset = 0.00
Sieht soweit ok aus. Allerdings fehlt mir jetzt noch etwas die Richtung. Ich möchte gern die Pumpen der 2 Heizkreise steuern können aus FHEM und die Zirkulationspumpe nach Bedarf anschalten können (on-for-timer) mit Amazon Dash Buttons. In der Installationsanleitung gibt es so eine Schnittstelle, die per Taster ausgelöst wird, siehe Anlage.
Das geht doch sicher auch per ebus oder?! Hat jemand eine zündende Idee?
Zitat von: bacanol am 24 Dezember 2016, 01:12:59
In der Installationsanleitung gibt es so eine Schnittstelle, die per Taster ausgelöst wird, siehe Anlage.
Das geht doch sicher auch per ebus oder?! Hat jemand eine zündende Idee?
Am einfachsten grab result abholen & in Datei speichern, 1xZP kurzschließen, wieder grab result holen, diff machen und dann schauen wir weiter :)
Den Taster kann man meines Wissens nicht durch einen Software-Befehl ersetzen.
Ich habe auch keine Möglichkeit gefunden, die Zirkulationspumpe durch einen "Override"-Befehl unabhängig vom Zeitprogramm zu starten und zu stoppen.
Meine Zirkulationspumpensteuerung habe ich deshalb extern durch einen Zustandsautomaten realisiert. Kurze Doku hier: https://wiki.fhem.de/wiki/1W-WPump, ausführliche Beschreibung in den SmartHome Hacks.
Die Ersparnis durch so etwas liegt bei ca. 100 €/Jahr.
LG
pah
Nachdem ich Dank der Hilfe im Forum den ebsud zum Laufen gebracht habe, versuche ich jetzt die Parameter meinen Heizung zu finden. Scheinbar habe ich aber eine sehr selten verwendete Heizung von Vaillant. Es ist eine Zeotherm (Zeolith-Wärmepumpe mit Solarunterstützung). Ein ebusctl info bringt:
pi@raspberrypi ~ $ ebusctl info
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 66
masters: 4
messages: 96
conditional: 0
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0201;HW=8701", loaded "bai.0020066007.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIZ00;SW=0110;HW=9801"
address 23: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
address 25: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
address 31: master #8, ebusd
address 36: slave #8
address 50: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
address 7f: master #24
address 84: slave #24, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
address ec: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
Ein ebusctl find bringt:
pi@raspberrypi ~ $ ebusctl find -d -r -w -p
broadcast datetime = 3.500;15:54:03;27.12.2016
broadcast hwcStatus = off;26;off
broadcast outsidetemp = 3.500
broadcast vdatetime = 15:54:03;27.12.2016
bai Mode = standby
scan.08 = Vaillant;BAI00;0201;8701
scan.08 id = 21;10;99;0020066007;9999;999999;N9
scan.15 = Vaillant;UIZ00;0110;9801
scan.15 id = 21;12;47;0020093225;0907;005040;N5
scan.23 = Vaillant;ZEO00;0148;9701
scan.23 id = 21;99;99;0010008698;9999;999999;N9
scan.25 = Vaillant;ZEO00;0148;9701
scan.25 id = 21;99;99;0010008698;9999;999999;N9
scan.50 = Vaillant;ZEO00;0148;9701
scan.50 id = 21;99;99;0010008698;9999;999999;N9
scan.84 = Vaillant;ZEO00;0148;9701
scan.84 id = 21;99;99;0010008698;9999;999999;N9
scan.ec = Vaillant;ZEO00;0148;9701
scan.ec id = 21;99;99;0010008698;9999;999999;N9
Wie es für mich aussieht, läd der ebus zum Modul UIZ00 und ZEO00 keine CSV-Datei.
Wie kann ich herausfinden, welche andere CSV-Datei am ehesten zum Modul paßt?
Kann dann diese durch einfaches Umbenennen oder Erweitern um die HW verwendet werden?
Z.B. werden die Vorlauftemperatur und Rücklauftemperatur nicht gefunden. In welchem Modul wird das abgefragt (BAI, ZEO, UIZ?).
Vielleicht hat noch jemand einen Tip, wie ich hier weitermachen kann.
Gruß Jürgen
Hab noch weietr getestet, aber viele Fragen.
Wenn ich das Modul 08.bai.HW7401.csv aus Reinharts Beispiel in 08.bai.HW8701.csv umbenenne und auf den Raspi ins Verzeichnis /ebusd/vaillant kopiere, kann ich z.B. die Betriebsstunden HcHours abfragen. Wenn ich die entsprechende Zeile dann mit OpenOffice in die Datei bai.0020066007.inc kopiere (scheint auf die ZeoTherm angepasst zu sein) und die 08.bai.csv wieder lade (löschen der 08.bai.HW8701.csv in dem Verzeichnis), dann wird diese inc-Datei gar nicht mehr geladen und ich kann demzufolge die Betriebsstunden nicht abfragen.
Dürfen die inc-Dateien gar nicht verändert werden? Kann ich nicht glauben, da man die ja an die Geräte anpassen muß.
Wie kann ich denn die CSV-Dateien oder INC-Dateien modifizieren, damit sie trotzdem noch geladen werden?
Ich verwende auf einen Tip von pah hin nicht mehr Excel sondern OpenOffice und speichere im selben Format, wie geladen (Komma-getrennt; Texttrenner ist ') wieder ab. Trotzdem wird, sobald ich eine Änderung mache, die Datei nicht mehr von ebusd geladen.
Gruß Jürgen
Hey Leute.....
ich bräuchte mal dringend eine Jahresendstarthilfe!
Problem: schon im letzten Jahr kurz nach Inbetriebnahme fiel meine Vaillant-Heizung ziemlich oft in einen Fehlerstatus. Anfangs lag es an einem vorgeschalteten Ölzähler, der auf einmal nicht für die neuen Heizungen einsetzbar war, später lag es an Einstellungen und zuletzt fiel im Urlaubsmodus der Wasserdruck immer zu weit ab.
Nun scheint inzwischen alles andere behoben - ich bin/war eine Woche im Urlaub und alles ging bis jetzt gut.
Doch heute sollte die Heizung wieder anspringen und zeigte beim ersten Versuch "F.28 Zündfehler" >:(
Wenn ich vor Ort wäre, würde ich 1-x Mal die Entstörungstaste drücken, bis die Zündung gelingt und alles läuft wieder.
Das Problem ist aber: ich sitze noch 500 km entfernt und sehe nur den (Fehler)Status 28 und die Raumtemperatur von 8°C :o
Frage: Kennt jemand eine Möglichkeit, den icoVIT 156/3 aus der Ferne irgendwie zurückzusetzen?
Ich habe schon die errorhistory gelöscht, aber der currenterror bleibt bei 28. Gibt es bekannte Kommandos, die den BAI.HW7401 zurücksetzen - gewollt oder ungewollt??
Ich friere schon jetzt, wenn ich daran denke morgen nach Hause zu kommen...
Bin etwas weiter mit meiner ZeoTherm. Deswegen ein kurzer Statusbericht, falls noch jemand mit dem Gerät kämpft:
Ich habe die Datei 15.uih.csv kurzerhand in 15.uiz.csv umbenannt, da zur ID=UIZ00 keine passende csv-Datei gefunden wird. Siehe da, eine ganze Reihe an Parametern können ausgelesen werden. Einige in der Datei vorhandene Parameter gibt es allerdings nicht. Wenn jemand Interesse an der Datei hat stelle ich sie gerne zur Verfügung.
Ebenso gibt es im geladenen Modul bai.0020066007.inc einige Parameetr nicht in der Zeotherm. Andere können ausgelesen werden.
Lediglich zur ID_ZEO00 habe ich noch nichts passendes gefunden. Da suche ich aber weiter.
Noch eine Info zum Programm, um die csv- und inc-Dateien zu bearbeiten.
Im Forum wird empfohlen, ein SpreadSheet-Programm (z.B. Excel oder OpenOffice) zu verwenden. Das funktioniert bei mir nicht, obwohl ich die Datei als Komma-separierte Datei mit Texttrennzeichen = ' (einzelnes Hochkomma) öffne und so auch wieder abspeichere. Auch ohne Änderung in einer der Dateien ist die Datei nach dem Abspeichern etwas größer und das ebusd-Programm lädt sie nicht mehr. Die Ursache konnte ich nicht finden, so dass ich im Moment die Dateien mit Notepad bearbeite. Ist zwar nicht so übersichtlich, aber es geht bei mir wenigstens. Wenn jemand eine Idee hat, was ich falsch mache, bin ich für einen Hinweis dankbar.
Gruß Jürgen
Zitat von: bmwfan am 27 Dezember 2016, 16:00:15
Es ist eine Zeotherm (Zeolith-Wärmepumpe mit Solarunterstützung).
Für die Zeotherm hab ich auch CSVs, die hat nur bisher keiner gebraucht.
Siehe Anhang.
Hallo John,
Super, Danke. Habe sie gleich eingebunden, bekomme aber diese Meldung:
pi@raspberrypi /etc/default $ ebusd --checkconfig --scanconfig
2017-01-01 17:10:38.575 [main notice] ebusd 2.4.79708d2 performing configuration check...
condition burner]r not defined
Error reading "/etc/ebusd/vaillant/50.zeo.mc.csv" line 12 field 1 value "[burner]r": ERR: element not found
Erroneous item is here:
[burner]r,,FlowTempMin,Min. Vorlauftemp.,,,,0B04,,,temp0,,,1 °C resolution
^
condition burner]r not defined
Error reading "/etc/ebusd/vaillant/50.zeo.mc.csv" line 15 field 1 value "[burner]r": ERR: element not found
Erroneous item is here:
[burner]r,,FlowTempMax,Max. Vorlauftemp.,,,,0C04,,,temp0,,,1 °C resolution
^
condition burner]r not defined
Error reading "/etc/ebusd/vaillant/50.zeo.mc.csv" line 18 field 1 value "[burner]r": ERR: element not found
Erroneous item is here:
[burner]r,,TempDesired,Solltemperatur,,,,0D0A,,,temp1,,,1/2 °C resolution
^
condition burner]r not defined
Error reading "/etc/ebusd/vaillant/50.zeo.mc.csv" line 20 field 1 value "[burner]r": ERR: element not found
Erroneous item is here:
[burner]r,,TempDesiredLow,Absenksollwert,,,,0E00,,,temp1,,,1/2 °C resolution
^
2017-01-01 17:10:39.846 [main notice] found messages: 6459 (453 conditional on 145 conditions, 2 poll, 56 update)
2017-01-01 17:10:39.928 [main notice] ebusd stopped
Kommentiere die Zeilen einstweilen mal aus und teste weiter. So läuft der ebus, allerdings wird das Modul 84.zeo.csv nicht geladen.
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 122
reconnects: 0
masters: 4
messages: 537
conditional: 8
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0201;HW=8701", loaded "bai.0020066007.inc" ([PROD='0020066007']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIZ00;SW=0110;HW=9801", loaded "vaillant/15.uiz.csv"
address 23: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701", loaded "vaillant/23.zeo.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701", loaded "vaillant/25.zeo.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701", loaded "vaillant/50.zeo.mc.jg.csv"
address 7f: master #24
address 84: slave #24, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
address ec: slave, scanned "MF=Vaillant;ID=ZEO00;SW=0148;HW=9701"
Woran kann das liegen?
Gruß Jürgen
Erst einmal ein gesundes neues Jahr.
Bei mir hat es gleich schlecht angefangen. Die Vaillant streikte und ging immer wieder in einen Fehler (F.27 Ionisationssignal meldet Flamme trotz abgeschalteten Gasventils). Anfangs konnte ich sie durch Fehler löschen dazu bewegen weiter zu machen, was sich aber immer weiter verschlechterte. Der Vaillant Kundendienst hat dann nicht lange gesucht und hat das Mainboard der Heizung getauscht. Jetzt läuft sie wieder wie am ersten Tag und ich bin 412,- Euronen ärmer. :(
Nun habe ich aber bedenken, dass die Schnittstelle oder der Anschluß der Stromversorgung des Raspi's an die Heizung den Fehler auf dem Mainboard verursacht hat. Die Stromversorgung für den Raspi hatte ich an den Klemmen 7-8-9 (24V) der Heizung angeschlossen. Den Bus ganz einfach an die Bus Klemme.
Alles lief über ein Jahr wunderbar und ohne Probleme über das GAEBUS Modul und nur lesend. Vor ca. einem Monat habe ich mich dann an das ECMD Modul gemacht und versucht Werte von und zur Heizung zu übertragen. Funktionierte anfangs auch ohne Probleme bis dann der Fehler auftrat.
Jetzt habe ich bedenken, dass bei einem erneuten Anschluß das Mainboard über kurz oder lang auch wieder abraucht. Es könnte aber auch sein, dass das Mainboard nach acht Jahren einfach blöderweise den Geist aufgegeben hat. Wenn ich das Interface wieder anschließe werde ich aber auf jeden Fall die Stromversorgung von extern bereitstellen. Das war auch das was auch der Monteur bemängelt hat da die 24V keine echte Stromversorgung sind.
Habt ihr bisher Proleme gehabt? Oder liegt es nur an meinem blöden Raspi Stromversorgungsanschluß?
Was meint Ihr?
Ich tippe auf den Stromversorgungsanschluss. Ein Raspberry Pi kann schon mal 2 A ziehen - und das ist für einen Anschluss, der eigenlich nur einen kleinen Sensor mit Strom versorgen soll, enorm viel. Insbesondere der Einschaltstrom des Schaltnetzteils für den Raspberry Pi könnte das Vaillant-Board durchaus gekillt haben.
Das war, wie man so schön sagt, am falschen Ende gespart - und ich hätte auch jedem davon abgeraten.
LG
pah
Zitat von: majorshark am 03 Januar 2017, 09:22:47
Die Stromversorgung für den Raspi hatte ich an den Klemmen 7-8-9 (24V) der Heizung angeschlossen.
Das war auch das was auch der Monteur bemängelt hat da die 24V keine echte Stromversorgung sind.
Habt ihr bisher Proleme gehabt? Oder liegt es nur an meinem blöden Raspi Stromversorgungsanschluß?
Also ich wäre jetzt nicht auf die Idee gekommen, der Therme den Strom zu klauen! ;)
Unter [1] sind ein paar Beiträge verlinkt, wo ebenfalls über die Belastbarkeit diskutiert wird - aber es "traut" sich dort jemand, 150mA abzugreifen - damit würde ein Raspi selbst bei verlustfreiem Step-Down von 24V auf 5V nicht weit kommen...
Auch wenn prinzipiell jede Spannungsversorgung gegen Überlastung gesichert werden sollte - Vaillant hält sich leider viel zu selten an irgendwelche Etiquette und gibt außerdem nirgends offiziell an, dass dort eine Spannungsversorgung anliegt, es ist lediglich ein interner Anschluss für hauseigenes Zubehör.
Nur so als Vergleich: wenn ich an den Anschluss für die Zirkulationspumpe eine 25A Klimaanlage anschließe, raucht sicher auch so einiges auf der Platine durch...
Also - wie pah bereits schreibt: nimm ein separates Netzteil und gut!
(hat nebenbei den Vorteil, dass der Raspi nicht ausgeht, wenn irgendein Monteur vorschnell die Heizung ausschaltet)
VG, Sven
[1] https://dl1mk.wordpress.com/hybrid/
Dank für eure Einschätzung. Dann kann ich es nicht auf die Alterung ;) schieben und muss das auf meine Kappe schreiben. :(
Wie ich auf den schmalen Grat kommen konnte das dort echte 24V anliegen kann ich aus der Heutigen Sicht auch nicht mehr sagen. Habe mich wahrscheinlich durch den Aufdruck (24V) einfach verleiten lassen und gedacht diese Reserve hat die schon. Jetzt bin ich schlauer. Wobei - Einer hat es im Mikrocontroller Forum auch versucht, mit einem NET-IO. Aber scheinbar nicht über eine sol lange Zeit.
Einzig die Lust ist mir jetzt ein wenig vergangen die Vaillant noch einmal mit FHEM zu verbinden. :'(
Grüße
Zitat von: Prof. Dr. Peter Henning am 12 Januar 2016, 05:07:55
Es geht ja nicht nur darum, di eZirkulationspumpe mal außer der Reihe anzuschalten, sondern auch darum, sie abzuschalten, wenn sie nicht gebraucht wird. Darum steckt bei mir zwischen der Heizungssteuerung und der Pumpe noch dieses Teil hier:
http://www.fhemwiki.de/wiki/1W-WPump
Damit wird tagsüber die Pumpe ausgeschaltet, wenn genügend heißes Wasser in der Leitung ist. Und außerhalb der zeitgesteuerten Laufzeit die Pumpe eingeschaltet, wenn man heißes Wasser benötigt.
So etwas suche ich auch - drei Fragen hierzu:
1) Gibt es für die 1W-WPump-Steuerung Platinenlayouts (oder gar fertige Platinen zu kaufen)?
2) Misst Du an einer Heißwasserleitung, ob noch genügend warmes Wasser in der Leitung ist, oder ist das ein Erfahrungswert (Abnahme Warmwasser, dann x Minuten, bis Wasser in der Leitung abgekühlt ist)?
3) Wie triggerst Du die Pumpe außerhalb der "zeitgesteuerten Laufzeit", wenn heißes Wasser benötigt wird? Manueller Taster, Bewegungsmelder, ...?
LG
SP
Zitat1) Gibt es für die 1W-WPump-Steuerung Platinenlayouts (oder gar fertige Platinen zu kaufen)?
2) Misst Du an einer Heißwasserleitung, ob noch genügend warmes Wasser in der Leitung ist, oder ist das ein Erfahrungswert (Abnahme Warmwasser, dann x Minuten, bis Wasser in der Leitung abgekühlt ist)?
3) Wie triggerst Du die Pumpe außerhalb der "zeitgesteuerten Laufzeit", wenn heißes Wasser benötigt wird? Manueller Taster, Bewegungsmelder, ...?
1 Nein
2 Ich messe Vorlauf und Rücklauf in der Nähe der Pumpe. Falls T < 45°C im Rücklauf -> Annahme, dass nicht mehr genügend warmes Wasser in der Leitung. Siehe Zustandsautomat.
3. Diverse Ansteuerungen, z.B. wenn nach 21:30 das Licht im Wohnzimmer komplett ausgeschaltet wird. Eine entsprechende Messkurve hab eich oben irgendwo angehängt, zeigt sehr deutlich, wi egut das funktioniert.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 05 Januar 2017, 16:22:42
1 Nein
2 Ich messe Vorlauf und Rücklauf in der Nähe der Pumpe. Falls T < 45°C im Rücklauf -> Annahme, dass nicht mehr genügend warmes Wasser in der Leitung. Siehe Zustandsautomat.
3. Diverse Ansteuerungen, z.B. wenn nach 21:30 das Licht im Wohnzimmer komplett ausgeschaltet wird. Eine entsprechende Messkurve hab eich oben irgendwo angehängt, zeigt sehr deutlich, wi egut das funktioniert.
Danke! Habe die Messkurven gefunden. Falls sie noch jemand sucht: https://forum.fhem.de/index.php/topic,22054.msg211519.html#msg211519
Ist der Code des Zustandsautomaten frei verfügbar?
LG
SP
Zitat von: bmwfan am 01 Januar 2017, 17:16:54
Super, Danke. Habe sie gleich eingebunden, bekomme aber diese Meldung:
pi@raspberrypi /etc/default $ ebusd --checkconfig --scanconfig
2017-01-01 17:10:38.575 [main notice] ebusd 2.4.79708d2 performing configuration check...
condition burner]r not defined
Error reading "/etc/ebusd/vaillant/50.zeo.mc.csv" line 12 field 1 value "[burner]r": ERR: element not found
Erroneous item is here:
[burner]r,,FlowTempMin,Min. Vorlauftemp.,,,,0B04,,,temp0,,,1 °C resolution
^
Die Bedingung gibts wohl nicht und ich weiß auch nicht, ob das Gerät CfgHeatSinkType unterstützt, also weg damit :-)
@John:
Dann lösche ich sie ganz.
Kannst Du mir auch einen Tip geben, warum das Modul 84_ZEO.... nicht geladen wird. Auch wenn ich die HW-Version und/oder die SW-Version im Namen ergänze wird sie nicht geladen. Dabei sind gerade da die meisten Werte drinnen. :(
Hallo,
Ich habe nach der Anleitung https://wiki.fhem.de/wiki/EBUS (https://wiki.fhem.de/wiki/EBUS) mein EBUS modus aufgebaut, nur leider bekomme ich nicht die Spannung wie angegeben https://wiki.fhem.de/w/images/9/9d/EBUS_Adapter_Messpunkte.png (https://wiki.fhem.de/w/images/9/9d/EBUS_Adapter_Messpunkte.png) hin.
Woran könnten die Probleme liegen, das die Spannungen nicht stimmen? Selbst beim oben angegebene optokoppler stimmt die Spannung nicht, obwohl nicht viel dahinter steckt.
Gemessen habe ich bei einer 10V Eingangsspannung am EBUS.
Zitat von: bmwfan am 07 Januar 2017, 20:04:38
Kannst Du mir auch einen Tip geben, warum das Modul 84_ZEO.... nicht geladen wird. Auch wenn ich die HW-Version und/oder die SW-Version im Namen ergänze wird sie nicht geladen. Dabei sind gerade da die meisten Werte drinnen. :(
Also "84_ZEO" darf sie nicht heißen, sondern "84.zeo.csv". Dann sollte es eigentlich klappen. Wenn nicht, dann mal ins ebusd Log schauen, da sollte schon irgendwas dazu drin stehen.
Hallo John,
die Datei heißt wie von Dir zugesendet 84.zeo.csv.
Habe das log level auf debug gestellt. Anbei das log. Mir fällt auf, dass in memory.csv eine Fehlermeldung kommt und die 84.zeo.csv nicht geladen wird, da sie nicht matched. Vielleicht kannst Du erkennen, wo der Fehler liegt.
Gruss Jürgen
Hallo zusammen,
ich melde mich mal wieder zurück, meine Vaillant ecoTec Plus VC146/5 E mit Calormatic 470/3 läuft seit 2 Jahren mit ebusd 1.0 im produktiven Betrieb.
Nun würde ich gerne den Wert d.71 max. Vorlauftemperatur in der Therme selbst fernsteuern.
Hierzu verwende ich folgenden Code aus dieser Datei https://raw.githubusercontent.com/john30/ebusd-configuration/master/ebusd-1.x.x/vaillant_de/bai.csv (https://raw.githubusercontent.com/john30/ebusd-configuration/master/ebusd-1.x.x/vaillant_de/bai.csv):
#,BAI00,ecoTEC (euro),308523 174 518+618+631+703+803+816,,,,,,,,,,,,,,,,,,,,,,
*r,bai,,,,"08","B509","0D",,,,,,,,,,,,,,,,,,
*w,bai,,,,"08","B509","0E",,,,,,,,,,,,,,,,,,
*wi,baiinstall,,,,"08","B509","0E",,,,,,,,,,,,,,,,,,
*ws,baiservice,,,,"08","B509","0E",,,,,,,,,,,,,,,,,,
r;wi,,FlowsetHcMax,d.71 Max. Vorlauftemp. Heizbetrieb,,,,"0E04",,,temp,,,Einstellung des maximalen Vorlaufsollwert im Heizbetrieb (bei Linksanschlag des Poti),,,,,,,,,,,,
Read klappt, es kommt der korrekte Wert.
Schreiben klappt nicht, es ändert sich nichts.
Bislang ist es mir auch nur gelungen, werte in der Calormatic 470 zu ändern, nicht in der Therme selbst.
Von der Therme kommende Werte kann ich nur auslesen (z.B. Vorlauf/Rücklauf/DCF-Signal) - wobei dies auch alles Werte sind, die ich in der Calormatic in der Fachhandwerkerebene sehen kann...
Wer könnte mir weiterhelfen?
Oder kann man die Werte in der Therme gar nicht fernsteuern?
Viele Grüße,
Heiko
Hallo Trainer
ZitatWoran könnten die Probleme liegen, das die Spannungen nicht stimmen? Selbst beim oben angegebene optokoppler stimmt die Spannung nicht, obwohl nicht viel dahinter steckt.
Lies doch einmal die Diskussion in diesem Thread ab #1933 über die aktuelle Schaltung. Vielleicht hilft dir das weiter. Mit welchen Bauteilen hast du die Schaltung aufgebaut ?
Zitat von: bmwfan am 08 Januar 2017, 19:36:08
die Datei heißt wie von Dir zugesendet 84.zeo.csv.
Da sind schon irgendwelche Modifikationen drin. Schick mir doch bitte mal dein Konfigurationsverzeichnis komplett (ebusd@ebusd.eu).
Hallo John,
in der 84.zeo.csv hatte ich keine Änderungen gemacht. Lediglich angeschaut.
Die 50.zeo.mc.csv habe ich in 50.zeo.mc.jg.csv umbenannt, da ich 3 Zeilen gelöscht habe und nicht wollte, dass die Datei bei einem Update überschrieben wird.
Ich sende Dir eine ZIP-Datei des Verzeichnisses zu.
Gruß Jürgen
Zitat von: bmwfan am 10 Januar 2017, 20:01:00
Die 50.zeo.mc.csv habe ich in 50.zeo.mc.jg.csv umbenannt, da ich 3 Zeilen gelöscht habe und nicht wollte, dass die Datei bei einem Update überschrieben wird.
Ah verstehe, darum der andere Name.
Nimm bitte mal Zeile 172 aus der 84.zeo.csv raus. Die mag nicht, weiß aber noch nicht warum.
@John: Heureka! Die Datei wurde geladen. Jetzt mache ich mich mal ans Testen der Parameter.
Besten Dank
Gruß Jürgen
Habe nun Dank der Hilfe von John alles an den Start bekommen. Eine Sache fehlt mir noch, der HK2 direkt am VCR 620, siehe Anlage. Habe dort die eine FBH angeschlossen, die zweite am VR60. letztere sehe ich auch schön aufgeführt und kann die Werte entsprechend ändern bei Bedarf.
Readings
Heizkurve
0.50
2017-01-12 16:19:31
Ist_Vorlauftemperatur
29.38
2017-01-12 16:19:31
Max_Vorlaufsolltemperatur
45
2017-01-12 16:19:31
Solltemperatur
25.0
2017-01-12 16:19:31
Solltemperatur_Absenken
20.0
2017-01-12 16:19:31
bzw
r~mc~FlowTempDesired~Vorlaufsolltemperatur
Vorlaufsolltemperatur
deleteattr
r~mc~FlowTempMax~Maximaler_Vorlaufsollwert
Max_Vorlaufsolltemperatur
deleteattr
r~mc~FlowTemp~VF1_Sensor
Ist_Vorlauftemperatur
deleteattr
r~mc~HeatingCurve~Heizkurve
Heizkurve
deleteattr
r~mc~TempDesiredLow~Absenksollwert
Solltemperatur_Absenken
deleteattr
r~mc~TempDesired~Solltemperatur
Solltemperatur
Leider gibt mir die CSV Datei für den 620er nur den HK1 bis jetzt, an dem meine Therme klemmt.
Hat jemand eine Idee, wie ich weiter kommen kann?
Ich habe Probleme mit der Decodierung der DCFTimeDate in meiner bai. Ich verwende die aktuelle ebusd git Version.
Dieser Eintrag ist ja in vielen bai csv'en drin:
r,,DCFTimeDate,DCF Datum/Uhrzeit,,,,"E500",,,btime;bdate,,,DCF Time / date stamp struct { uchar sec; uchar min; uchar std; uchar tag; uchar mon; uchar wtg; uchar jah; } Tdcf77_time;
Ein hex Auslesen ergibt:
08b509030dE500 / 072218150c010411
Diese 7 Bytes ergeben 21Uhr 24min 34 sek 12. Jan. 4. Tag Jahr 17.
Also alles OK.
Wenn ich aber das ebusctl read gebe kommt:
pi@raspberrypi:~ $ ebusctl r DCFTimeDate
ERR: argument value out of valid range in decode
Ich habe auch schon mal einen richtig decodierte Parameter gesehen.
Zitat von: mirror am 12 Januar 2017, 21:47:07
r,,DCFTimeDate,DCF Datum/Uhrzeit,,,,"E500",,,btime;bdate,,,DCF Time / date stamp struct { uchar sec; uchar min; uchar std; uchar tag; uchar mon; uchar wtg; uchar jah; } Tdcf77_time;
Ein hex Auslesen ergibt:
08b509030dE500 / 072218150c010411
Diese 7 Bytes ergeben 21Uhr 24min 34 sek 12. Jan. 4. Tag Jahr 17.
Da scheint ein Bock drin zu sein; in meiner Version war das noch als HEX:8 definiert, was auch falsch ist - mit HEX:7 klappte es.
Die btime und bdate sind in den Templates als BTI und BDA definiert, also BCD codiert - es ist aber eher HEX codiert...
Versuche mal "btime;bdate" durch "HTI;HDA" zu ersetzen. Wenn das klappt, könnte man besser noch "hdate" und "htime" Templates erstellen, ich habe jetzt keine gefunden.
Zu Hülf, ich habe ein vermutlich trivial zu lösendes Problem und bin doch zu blöd, es zu lösen:
Ich kann mit ebusctl hex die Raumtemperatur meines Raumthermostaten (Wolf BM2) auslesen. Aber ich kriege das einfach nicht in eine csv-Zeile umgewandelt.
root@raspberrypi2_ebusd:/home/pi# ebusctl hex 3550220377b427
02e100
Die Temperatur steckt im zweiten Byte der Antwort:
hex e1=dezimal 225 = 22,5 Grad Celcius, sprich Byte 2 in dezimal umrechnen * 0,1 = aktuelle Temperatur.
Wie lautet denn wohl die passende CSV-Zeile?
EDIT: Ich konnte es doch lösen, des Rätsels Lösung:
#################################
# 3550220377b427 Raumtemperatur #
#################################
r,betrd_bm2,raumtemp,Raumtemperatur (35->50),,35,5022,77b427,,,UIN,10,°C,,,,,,,,
Zitat von: Sven77 am 13 Januar 2017, 17:49:27
Da scheint ein Bock drin zu sein; in meiner Version war das noch als HEX:8 definiert, was auch falsch ist - mit HEX:7 klappte es.
Die btime und bdate sind in den Templates als BTI und BDA definiert, also BCD codiert - es ist aber eher HEX codiert...
Versuche mal "btime;bdate" durch "HTI;HDA" zu ersetzen. Wenn das klappt, könnte man besser noch "hdate" und "htime" Templates erstellen, ich habe jetzt keine gefunden.
Hallo Sven,
danke das geht sofort. Was meint John dazu?
Gruß,
Dietmar
Zitat von: mirror am 13 Januar 2017, 20:43:40
danke das geht sofort. Was meint John dazu?
Na dann halt in hex :-) Am besten htime und hdate in _templates dazu definieren und dann in den bai's entsprechend verwenden.
Hallo Zusammen,
ich habe eine geotherm 61/3 s mit dem ebusd am laufen.
Ich habe immer wieder unknown Messages drin, sind das Messages die der ebusd nicht kennt, fehlende csv oder sind das Fehler auf dem EBUS?
2017-01-16 19:17:44.516 [updatenotice]unknown 1050b505072b000100000000 / 00
2017-01-16 19:17:48.764 [updatenotice]unknown 1025b5040132 / 0a00000000000000010000
2017-01-16 19:17:48.914 [updatenotice]unknown 1025b5040131 / 020000
2017-01-16 19:17:52.531 [updatenotice]unknown 10feb505034a0400
2017-01-16 19:17:54.394 [updatenotice]unknown 1025b505072b000100000000 / 00
2017-01-16 19:17:55.994 [updatenotice]unknown 03e0b5210500050600e7 / 09010690ffb2ff073943
2017-01-16 19:17:56.706 [updatenotice]unknown 03e0b509040e3a0000 / 00
2017-01-16 19:17:57.707 [updatenotice]unknown 03e0b509040e480000 / 00
2017-01-16 19:17:58.842 [updatenotice]unknown 1023b5040132 / 0a00000000000000010000
2017-01-16 19:17:58.992 [updatenotice]unknown 1023b5040131 / 020000
2017-01-16 19:18:03.114 [updatenotice]unknown 10feb505034a0400
2017-01-16 19:18:04.641 [updatenotice]unknown 1023b505072b000100000000 / 00
2017-01-16 19:18:08.858 [updatenotice]unknown 1050b5040132 / 0a00200603010000010100
2017-01-16 19:18:09.009 [updatenotice]unknown 1050b5040131 / 020001
2017-01-16 19:18:11.741 [updatenotice]unknown 10feb51603040001
2017-01-16 19:18:12.760 [updatenotice]unknown 10feb505034a0400
2017-01-16 19:18:14.643 [updatenotice]unknown 1050b505072b000100000000 / 00
2017-01-16 19:18:16.433 [updatenotice]unknown 03e0b5210500050600e7 / 0901068fffb2ff073a43
2017-01-16 19:18:17.003 [updatenotice]unknown 03e0b509040e3a0000 / 00
2017-01-16 19:18:17.622 [updatenotice]unknown 03e0b509040e480000 / 00
2017-01-16 19:18:18.950 [updatenotice]unknown 1025b5040132 / 0a00000000000000010000
2017-01-16 19:18:19.098 [updatenotice]unknown 1025b5040131 / 020000
Gruss
Ich kämpfe jetzt seit Wochen mit dem Auslesen der Werte aus meiner Auromatic 620 und VR60/3. Fast alles funktioniert schon, aber bei der Auromatic
fehlt mir noch das Auslesen des Zustandes vom Ausgang "MA".
Das ist jener Ausgang, welcher anspricht, wenn TD1 grösser/kleiner als TD2 wird (mit Hysterese).
TD1 kann ich auslesen. Das ist Storage4Sensor3 im ec.solsy.sc.csv. Ebenso TD2, das ist SumBackflowSensor ebendort.
Auch die Hysterese kann mit DeltaTOnFlexDtController und DeltaTOffFlexDtController bestimmt werden.
Ich könnte also theoretisch errechnen, ob der Ausgang MA geschaltet werden sollte. Aber eben nur "sollte". Ob er es tatsächlich wird, möchte ich gerne vom Bus auslesen.
Ich habe leider keinen Eintrag im csv gefunden, der dem tatsächlichen MA Ausgang entspricht.
Deshalb meine Bitte: kann mir jemand sagen, ob dieser Wert existiert, oder ob er existieren sollte aber bisher noch nicht gefunden wurde,
ob ich danach suchen könnte und wie ich diese Suche im Fall der Fälle angehen soll.
Vielen Dank für einen Hinweis
Eduard
Zitat von: galileo am 16 Januar 2017, 20:30:14
Deshalb meine Bitte: kann mir jemand sagen, ob dieser Wert existiert, oder ob er existieren sollte aber bisher noch nicht gefunden wurde,
ob ich danach suchen könnte und wie ich diese Suche im Fall der Fälle angehen soll.
Ich habe keine VRS620, dafür die VRC700 - von der war anfangs gar nichts bekannt. :-)
Sieht so aus, als würde die 620 "nur" auf die normalen b509 reagieren. Auslesen lassen sich diese mit 0d und 2 zusätzlichen Bytes.
Laut CSV scheint die 620 generell im letzten Byte 00 oder 08 zu haben. Also könnte man ein Script schreiben, was 2x 255 Nachrichten per Hex abfragt:
ebusctl hex ecb509030dxx00
ebusctl hex ecb509030dxx08Wenn Du
sicher bist, dass in der CSV kein entsprechender Wert vorhanden ist, könnte man die bekannten Messages auslassen.
Und dann heisst es warten: das Script zu verschiedenen Zeiten ausführen und danach per diff vergleichen. Mehrmals zu Zeiten wo der MA ein- und dann mehrmals wenn er ausgeschaltet ist.
Danach vergleichen, welche Werte in der einen Dateimenge 00 und in der anderen 01 ist - ach ja; Vaillant ist da variabel, "ein" kann auch manchmal etwas anderes als 01 sein, z.Bsp. 20 oder 64. Oder es ist ganz und gar bitcodiert und "aus" hat auch einen anderen Wert - ich habe schon c0==aus und c8==ein gesehen.....
Zitat von: lewej am 16 Januar 2017, 19:19:53
Ich habe immer wieder unknown Messages drin, sind das Messages die der ebusd nicht kennt, fehlende csv oder sind das Fehler auf dem EBUS?
Das sind messages, die ebusd trotz der CSVs noch nicht kennt. Deshalb "unknown".
Hallo Sven77,
Vielen Dank für die Erklärung. Dann werde ich mich einmal an die Arbeit machen. Ist bei mir nur mühsam, weil ich zum Schalten vom MA erst einmal einen ganzen Pufferspeicher händisch auf
Temperatur bringen muss.
@john30:
Kann es sein, dass im WIKI (TCP Client Commands) beim HEX Befehl die Zeile
Dx data byte(s) to send
doppelt ist und eigentlich nur jene am Ende gehört? Die erste Dx Zeile ist demnach falsch ?
Grüße,
Eduard
Zitat von: galileo am 17 Januar 2017, 12:59:59
Ist bei mir nur mühsam, weil ich zum Schalten vom MA erst einmal einen ganzen Pufferspeicher händisch auf Temperatur bringen muss.
Was genau sind denn TD1 und TD2?
Wenn ich das richtig verstehe, wird MA geschaltet, sobald der Puffer wärmer als der Solarkreis ist - das sollte doch jetzt im Winter machbar sein?!
Notfalls mal mit der Hysterese spielen...
ZitatWas genau sind denn TD1 und TD2?
TD1 ist die Temperatur im Puffer. TD2 ist die Temperatur im Rücklauf zum Gasbrenner.
Der Solarkreis ist eigentlich keiner, weil stattdessen ein Ofen (Holz) mit Wärmetauscher zum Pufferkreislauf eingebaut ist.
Wenn der Puffer warm genug ist, soll er den Gasbrenner "unterstützen" oder im Notfall auch ersetzen.
Also Ofen einheizen (das geht derzeit sehr gut :) ) und dann wieder auskühlen lassen. Mein Problem ist dass beim Bau dieser
Anlage von den "Professionisten" schon so viel falsch gemacht wurde dass der Pufferkreislauf erst seit kurzem wirklich funktioniert
und ich aber bis heute nicht weiss, ob dieser Ausgang MA auch wirklich schaltet. Ich wollte das über den eBus aufzeichnen...
Ich werde mir jetzt einmal ein Script schreiben, wie du es vorgeschlagen hast. Und den MA Ausgang einmal elekrisch messen.
Dann werde ich schon weiterkommen.
Wenn ich das richtig verstehe ist der MA ein Indiz dafür, dass aus dem Puffer geheizt wird. Bei mir kommt es tatsächlich vor, dass aus dem Puffer (solar-betankt) geheizt wird und die Therme abgeschaltet wird. Einen Schaltwert habe ich auch noch nicht gefunden.
Kann nur feststellen, die Therme tut nichts, die Hz-Umwälzpumpe läuft und am 620-Display wird "Puffer >> HK" angezeigt. Da die Therme einen Nachlauf hat, ist die Abfrage "wer heizt" = "auto 17.0 Puffer <" zu simpel.
Die Solare Heizungsunterstüzung ist bei auroMatic 620 Anhang S. 46 beschrieben.
ZitatWenn ich das richtig verstehe ist der MA ein Indiz dafür, dass aus dem Puffer geheizt wird
Ja, das stimmt. Allerdings wurde das bei mir völlig losgelöst vom Solarsystem der Auromatic eingebaut.
Es gibt nur die Logik mit TD1 und TD2, die den MA ansteuert welcher dann über ein 3-Wege Ventil das Wasser aus dem Puffer
in den Rücklauf der Therme einspeist. Die Therme selbst läuft munter weiter und weiss von dem nichts, ausser dass jetzt die
Rücklauftemperatur höher ist.
Eigentlich ist es egal, ob die Energie aus einer Solarzelle oder einem Ofen kommt.
In der Doku steht unter 3. Temperatur am "Fühler Mitte" SP4 als "Anlagenrücklauftemperatur" RF +8K, das Umschaltventil wird geöffnet.
Lassen wir mal die Ladefreigabezeit ausser acht, muss noch Wärmebedarf bestehen.
Werde mein "wer heizt" überarbeiten.
Hallo Zusammen,
kann mir jemand sagen wie ich herausfinden kann was für einen Bus meine Rotex HPSU bi-bloc von 2010 hat?
Das User Interface ist mit einem 2-adrigen Kabel angeschlossen. Mehr Info habe ich leider nicht.
Würde gerne einige Werte auslesen.
Mercie
Zitat von: galileo am 17 Januar 2017, 12:59:59
@john30:
Kann es sein, dass im WIKI (TCP Client Commands) beim HEX Befehl die Zeile
doppelt ist und eigentlich nur jene am Ende gehört? Die erste Dx Zeile ist demnach falsch ?
Ja, Danke fürs Melden! Ist korrigiert.
Hallo Zusammen,
beim auslesen vom ebusd nutze ich statt telnet die json Schnittstelle.
Jetzt sagen einigen Readings nicht direkt einem was.
@john30: Wäre es möglich die Readings noch zusätzlich mit der Beschreibung, die ja in den
CSVs vorhanden sind, zu erweitern?
Das hätte den Vorteil, das man nicht suchen muss, was welcher Wert zu Bedeuten hat.
Gruss
Zitat von: lewej am 18 Januar 2017, 07:11:28
@john30: Wäre es möglich die Readings noch zusätzlich mit der Beschreibung, die ja in den
CSVs vorhanden sind, zu erweitern?
Häng mal "?verbose" an die URL :)
Zitat von: Tungsten am 17 Januar 2017, 19:50:33
kann mir jemand sagen wie ich herausfinden kann was für einen Bus meine Rotex HPSU bi-bloc von 2010 hat?
Das User Interface ist mit einem 2-adrigen Kabel angeschlossen. Mehr Info habe ich leider nicht.
Würde gerne einige Werte auslesen.
Rotex kenne ich leider gar nicht, aber Google spuckt das hier aus:
https://community.openenergymonitor.org/t/hack-my-heat-pump-and-publish-data-onto-emoncms/2551
Scheint also kein ebus zu sein... Aber vielleicht kann Dir dort jemand genauere Auskünfte erteilen.
Zitat von: cs-online am 29 Dezember 2015, 12:43:16
@Roland:
Jawoll, das geht, mache ich bei mir auch, habe aber festgestellt, daß die Therme da nicht immer direkt drauf reagiert und eine "Denkpause", die mitunter einen halben Tag dauerte, eingelegt hat. Wenn ich das an der Therme einstelle, wird es gleich übernommen. Den Befehl dazu nimmst Du aus der CSV (bei mir die zur Therme gehörende, "PartloadHcKW" - Parameter auf D.0).
@Christian:
Ich habe das gleiche Verhalten. Kann PartloadHcKW korrekt lesen und beim Schreiben auf neuen Wert kommt "done". Aber beim erneuten Lesen (auch mit -f) steht der alte Wert immer noch drin. Auch nach einer Stunde bzw. einem Tag. Beim Einstellen über Therme - alles korrekt. Dies tritt nur bei diesem Parameter auf, egal ob er mit w oder wi Attribute in der csv ist:
r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"6C00",,,power,,,Heizungsteillast,,,
Hast Du dieses Verhalten immer noch oder konntest Du die Ursache finden.
Gruß,
Dietmar
Möchte für andere Nutzer einer Zeotherm die ersten Erkenntnisse meiner Versuche aufzeigen, da es doch etwas mühsam war die Parameter zuzuordnen:
Parameter: ActualTempDesired
Ist je nach Heizungs-Betriebsart (Auto, Heizen...) entweder der Wert, der in der Zeile Raumsolltemperatur eingegeben wird (wenn Anlage nicht im Absenkbetrieb) oder der Wert, der in der Zeile Absenktemperatur eingegeben wird (wenn Anlage in Nachtabsenkung ist).
Parameter: FlowTemp
Ist die Heizungs- oder Warmwasservorlauftemperatur je nachdem, ob geheizt oder Warmwasser erzeugt wird.
Frage: FlowTemp == F1Temp? Bei beiden Parametern wird derselbe Wert angezeigt.
Parameter: FlowTempDesired
Da ich Rücklauftemperaturregelung eingestellt habe, ist dies die Rücklauftemperatur SOLL
Frage: FlowTemp Desired== RTemp? Bei beiden Parametern wird derselbe Wert angezeigt.
Parameter: TempDesired
Ich vermute, dass dies die Sollwertvorgabe an den Regler ist.
Parameter: collTemp:
Kollektor-Vorlauftemperatur für die Bereitstellung der Umweltwärme für das Zeolith-Modul
Parameter: collRTemp:
Kollektor-Rücklauftemperatur für die Bereitstellung der Umweltwärme für das Zeolith-Modul
Alle Parameter sind aber in den csv mit r bezeichnet, daher, so weit ich weis, nur zum lesen.
r,,FlowTempDesired,Vorlaufsollwert,,,,"5000",,,temp,,,
Wie kann ich denn die Sollwert wie FlowTempDesired bzw. Heizkurve r,,HeatingCurve,Heizkurve,,,,"1000",,,curve,,,1/100 resolution
auch beschreiben? Ich möchte gerne den Sollwert bzw. die Heizkurve morgens niedriger haben, da in der kurzen Zeit zwischen Aufstehen und zur Arbeit gehen die Wohnung nicht so warm sein muss und abends höher einstellen, damit es komfortabler ist.
Gruß Jürgen
Zitat von: bmwfan am 18 Januar 2017, 21:34:08
Wie kann ich denn die Sollwert wie FlowTempDesired bzw. Heizkurve auch beschreiben?
Das sollte mit den SetTempDesired und SetHeatingCurve Nachrichten aus der mcmode.inc gehen, die von Deinem Mischer durch die entsprechende CSV geladen werden sollte. Wenn Du keinen Mischer hast, könntest Du mal versuchen, die mcmode.inc in deine Heizungs-CSV mit aufzunehmen.
Hallo Miteinander,
wir haben eine auroCompact VSC S 126/2-C 180 HL. Die Schaltung würde ich gerne aufbauen, die Platine habe ich schon. Nur ein paar Fragen noch dazu.
- Welchen USB to Seriell Adapter verwendet man am besten? (Bei Reichelt habe ich nichts passendes gefunden, einzig bei ELV wurde ich fündig, "https://www.elv.de/mini-usb-modul-um2102-komplettbausatz.html" allerdings zwei mal die Versandkosten, also wenn es bei Reichelt was gibt ... )
- Sind die Steckanschlüsse auf der Platine und den Adapter "Pin kompatibel" oder muss man da was vertauschen, wenn ja, wie habt Ihr das ohne fliegenden Aufbau gemacht.
- In welches Gehäuse packt Ihr die Schaltung? Wie befestigen? Ich sehe da einzig einen Schraube durch die Bohrung des T1?
- Der eBus der auroCompact hat zwei Anschlüsse. Welches Kabel verwendet man am besten, um ihn aus der Anlage heraus zu führen? Wie früher für serielle Leitungen geschirmt oder zwei verdrillte Adern eines Cat5/6/7 Kabels?
Vielen Dank für Eure Antworten und beste Grüße
Jürgen
Ich habe den MA Ausgang bei der Auromatic 620 gefunden!
Danke nochmals an Sven77 für den Tip:
ZitatAlso könnte man ein Script schreiben, was 2x 255 Nachrichten per Hex abfragt:
Das war jetzt das Script mit dem ich ausgelesen habe. Da es für mich als Linux-Newbee gar nicht so leicht war, es zu erstellen, poste ich es einmal hier.
#!/bin/bash
time=$(date "+%y-%m-%d_%H-%M-%S")
file=outfile"$time".txt
echo -e "$time\n">$file
for ((ii=0;ii<=255;ii++))
do
num=$(printf "%02x" $ii)
echo -n "$num / ">>$file
ebusctl hex ecb509030d"$num"00>>$file
done
echo -e "\r\n">>$file
for ((ii=0;ii<=255;ii++))
do
num=$(printf "%02x" $ii)
echo -n "$num / ">>$file
ebusctl hex ecb509030d"$num"08>>$file
done
Schon nach ein paar Messungen war klar, dass der Ausgang MA auf "1C" liegen muss. Die retournierten Daten waren "0100" und "0101".
Ich hab dann noch (jede Menge) Kontrollmessungen mit einer angepassten csv Datei gemacht und bin mir jetzt ziemlich sicher.
Das ist die Zeile für's ec.solsy.sc.csv :
r,,OutputMA,MA Output,,,,"1C00",,,onoff,,,State of MA Output@john30: kann ich irgendetwas dazu beitragen, dass das eventuell ins csv der Distribution einfliesst ?
Grüße,
Eduard
Zitat von: galileo am 23 Januar 2017, 07:38:20
Ich habe den MA Ausgang bei der Auromatic 620 gefunden!
Was ist denn der MA Ausgang?
Zitat von: galileo am 23 Januar 2017, 07:38:20
Das war jetzt das Script mit dem ich ausgelesen habe. Da es für mich als Linux-Newbee gar nicht so leicht war, es zu erstellen, poste ich es einmal hier.
So was ähnliches gab es schon mal hier:
https://forum.fhem.de/index.php/topic,29737.msg497570.html#msg497570 (https://forum.fhem.de/index.php/topic,29737.msg497570.html#msg497570)
:-)
Zitat von: galileo am 23 Januar 2017, 07:38:20
Das ist die Zeile für's ec.solsy.sc.csv :
r,,OutputMA,MA Output,,,,"1C00",,,onoff,,,State of MA Output
@john30: kann ich irgendetwas dazu beitragen, dass das eventuell ins csv der Distribution einfliesst ?
Du müsstest rausfinden, für welche Softwarevarianten die Definition gültig ist.
Also angefangen damit, was Dein Scan Result für die ec ausgibt, noch ein paar andere User vor allem mit älteren Versionen fragen, was bei denen mit Übernahme der Zeile ins CSV so rauskommt.
Und ne deutsche Übersetzung wär cool (deshalb die Frage nach der Bedeutung von "MA").
Zitat von: Orpheus am 21 Januar 2017, 17:39:58
- Welchen USB to Seriell Adapter verwendet man am besten? (Bei Reichelt habe ich nichts passendes gefunden, einzig bei ELV wurde ich fündig, "https://www.elv.de/mini-usb-modul-um2102-komplettbausatz.html" allerdings zwei mal die Versandkosten, also wenn es bei Reichelt was gibt ... )
Am sichersten sind die FTDI basierten Adapter, bei den anderen hängt ein vernünftiger Betrieb stark von der internen Puffergröße ab, die evtl. nicht durch den Treiber veränderbar ist. Puffer ist für eBUS Kommunikation fast ein Killerkriterium.
Was alternativ auch geht, sind USB-to-Ethernet Adapter. Da hab ich selbst zwei einigermaßen günstige im Einsatz. Das hat zwar eine höhere Latenz, aber geht trotzdem recht gut.
ZitatWas ist denn der MA Ausgang?
Das bezieht sich alles auf die Auromatic 620
Ich zitiere aus dem Vaillant Manual:
ZitatFunktionsweise:
– wenn TD2 > TD1 + Einschaltdifferenz (Menü C5), dann wird Ausgang MA angesteuert
– wenn TD2 < TD1 + Ausschaltdifferenz (Menü C5), dann wird Ausgang MA wieder abgeschaltet
TD1 und TD2 sind Temperatursensoren. MA ist ein (vermutlich Relais-)Ausgang der 230V schaltet.
Die beiden Temperaturen werden (unter Berücksichtigung einer Hysterese, typisch +8/-3 Grad) verglichen und dann der Ausgang MA geschaltet.
ZitatUnd ne deutsche Übersetzung wär cool (deshalb die Frage nach der Bedeutung von "MA")
Das ist schon Deutsch ;) Warum das "MA" heisst weiss vermutlich nur Vaillant alleine. Könnte aber sein dass es "Manuell" heisst, weil das der einzige
Regelkreis sein dürfte, der mit keiner anderen Funktion (Brenner, Boiler, Solar...) gekoppelt ist. Also quasi Stand-Alone.
Im ec.solsy.sc.csv ist übringens schon fast alles dazu vorhanden (abgesehen davon dass es TD1 und nicht SP4 heissen müsste):
Zitatr,,Storage4Sensor3,TD1 Sensor,,,,"1400",,,tempsensor,,,Temperature of SP4 sensor
r,,SumBackflowSensor,TD2 Sensor,,,,"0700",,,tempsensor,,,Temperature of TD2 sensor
r;w,,DeltaTOnFlexDtController,Einschaltdifferenz TD1/TD2,,,,"A600",,,calibration0,,,Temperaturdifferenz zwischen TD1 und TD2 ab der der Ausgang MA angesteuert wird
r;w,,DeltaTOffFlexDtController,Ausschaltdifferenz TD1/TD2,,,,"A700",,,calibration0,,,Temperaturdifferenz zwischen TD1 und TD2 ab der der Ausgang MA wieder abgeschaltet wird
Da ist auch schon von "MA" die Rede. Nur der tatsächliche Wert von MA fehlt dort noch und wird imho auf 1C00 geliefert.
Was meine Software-Versionen angeht (ich hoffe dass ich das aus dem richtigen Menue ablese):
i/o Karte 5.00
User Interface 5.07
VR90 5.01
VR60 5.00
Heizgerät 7.03
und beim ebusctl info kommt:
Zitataddress ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
das hast du vermutlich gemeint ?
Also wenn es noch jemanden gibt der soetwas hat dann bitte ich, es auszupobieren. Ich vermute nur, dass das meistens unbenutzt ist und nur bei mir
für eine reichlich krumme Lösung verwendet wurde. Wenn es unbenutzt ist dann sollte eigentlich konstant "off" (Hex 0100) herauskommen.
ZitatSo was ähnliches gab es schon mal hier:
https://forum.fhem.de/index.php/topic,29737.msg497570.html#msg497570
:-)
Oh ja, das habe ich nicht entdeckt. Bei 2000 Antworten in diesem Thread ist es nicht einfach, den Überblick zu behalten.
Schade, hätte mir einiges erspart. Ist auch viel cooler programmiert als mein script 8)
Grüsse,
Eduard
Hallo John,
vielen Dank für Deine Antwort.
USB to Ethernet ist nicht erforderlich, ich habe mir für den Heizraum noch einen Pi zugelegt.
Zitat von: john30 am 23 Januar 2017, 13:20:36
Am sichersten sind die FTDI basierten Adapter,
Bei den großen weltweiten Versender als auch in der Bucht habe ich massenweise Angebote für den rechten roten Adapter (https://wiki.fhem.de/w/images/1/19/EBUS_RS232_Konverter.png), FTDI - FT 232 gefunden. Allerdings kommt da fast alles aus China. Bei dem Preis, können es auch gefakte Chips sein?
Würde da lieber zu einem Produkt eines deutschen Händlers greifen.
Wie schließe ich den Adapter am besten an die Ebus Platine an? Gibt es etwas wie eine Buchsenleiste auf die man ein Flachbandkabel quetschen kann, wie bei den alten Floppy, IDE oder SCSI Anschlüssen?
Vielen Dank und beste Grüße
Jürgen
@galileo Habe eine Auromatic 620 und den 1C00 ausprobiert.
Meine Heizung wurde 2009 installiert, ebusctl info liefert
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 41
masters: 3
messages: 670
address 03: master #3
address 08: slave #3
address 10: master #6
address 23: slave
address 25: slave
address 26: slave
address 50: slave
address ec: slave
Dieses Register ging auf on, als die solare Heizungsunterstützung an der 620 angezeigt wurde. Auch ist die Vorlaufkurve angestiegen, obwohl die Therme nicht lief.
Ganz synchron war nicht alles, aber dazu müsste man bessere Tests durchführen. Liegt vermutlich an div. Nachlaufzeiten. Ich versuche noch weitere Daten aufzuzeichnen.
Habe den Vorschlag in meine csv aus der 1.x Zeit eingebaut.
Zitat von: galileo am 23 Januar 2017, 20:09:17
Das ist schon Deutsch ;) Warum das "MA" heisst weiss vermutlich nur Vaillant alleine.
Bei der Installationsanleitung meiner VRC700 steht "MA: Multifunktionsausgang" und bezieht sich je nach eingestellter Konfiguration auf einen Ausgang am VR70, den man mit verschiedenen Funktionen belegen kann.
Somit wäre "MA Ausgang" genauso falsch wie "LED Display" ;-)
Davon ganz abgesehen, ist der Anschluss am VRS620 lt. Installationsanleitung aber auch einfach nur mit "MA" beschriftet.
ZitatBei der Installationsanleitung meiner VRC700 steht "MA: Multifunktionsausgang"
Das macht Sinn! In der Anleitung der 620 kommt dieses Wort zwar nicht vor, aber ich habe dort noch folgendes gefunden:
Bei den Hydraulikplänen 1-4 ist MA ... 3-Wege Ventil Heizungsunterstützung und TD1/TD2 ... Differenztemperaturfühler Heizungsunterstützung
Bei den Hydraulikplänen 5-9 ist MA ... Speicherladepumpe und TD1 ... Speichertemperaturfühler. (TD2 nicht verwendet)
Das erklärt auch die Beobachtung von jkriegl. @jkriegl: Demnach müsste bei dir ein Hydraulikplan zwischen 1 und 4 eingestellt sein ?
Und die Einschätzung meiner Anlage relativiert sich dadurch auch ein wenig. Danke nochmals für die Rückmeldungen.
ZitatDavon ganz abgesehen, ist der Anschluss am VRS620 lt. Installationsanleitung aber auch einfach nur mit "MA" beschriftet.
Das kann ich bestätigen, auch am Gerät selbst ist der Stecker mit MA beschriftet.
Ein Vorschlag für das csv wäre dann:
r,,OutputMA,Multifunktionsausgang MA,,,,"1C00",,,onoff,,,Status 3-Wege Ventil Heizungsunterstützung oder Status Speicherladepumpe
@galileo
richtig Hydraulikplan-1,
wenn die Bedingungen für Solarunterstützung erfüllt sind: "Das Umschaltventil LP/UV zum Kombispeicher wird geöffnet"
Hallo
habe gestern mein neue Vaillant Heizung bekommen, natürlich auch gleich versucht ebus anzubinden.
Also ebusd installiert und konfiguriert. Zum testen mal GAEBUS connected, soweit so gut, Info gibt folgenden Output:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
soweit ich ebusd jetzt verstanden habe, werden, wenn ich den daemon mit --scanconfig starte, die csv's automatisch geladen, soweit verfügbar.
Daraus folgere ich jetzt dass ich da zwei Geräte am Bus habe zu denen es keine csv gibt. Eines davon davon dürfte die Steuerung für den Mischerkreis sein, genau diesen Teil wollte ich auslesen/steuern.
Hat vielleicht schon jemand csv's für die beiden Geräte die mir fehlen? Wenn nein. gibts irgendwo ein Howto wie ich das weiterkomme?
Gruß, Karl
Zitat von: schka17 am 28 Januar 2017, 22:42:42
Daraus folgere ich jetzt dass ich da zwei Geräte am Bus habe zu denen es keine csv gibt. Eines davon davon dürfte die Steuerung für den Mischerkreis sein, genau diesen Teil wollte ich auslesen/steuern.
Hat vielleicht schon jemand csv's für die beiden Geräte die mir fehlen?
Wenn Du den letzten Stand vom git (ebusd-2.1.x/de) verwendest, dann bekommst Du auch Konfigurationsdaten der Multimatik. Das VR_70 Modul ist an sich hinfällig, weil alle Daten davon im 700 enthalten sind.
Zitat von: galileo am 24 Januar 2017, 12:47:38
Ein Vorschlag für das csv wäre dann:
r,,OutputMA,Multifunktionsausgang MA,,,,"1C00",,,onoff,,,Status 3-Wege Ventil Heizungsunterstützung oder Status Speicherladepumpe
Habs mal eingecheckt, aber mit etwas allgemeinerem Kommentar, da es ja anscheinend vom Hydraulikplan abhängt.
Zitat von: john30 am 29 Januar 2017, 10:21:50
Wenn Du den letzten Stand vom git (ebusd-2.1.x/de) verwendest, dann bekommst Du auch Konfigurationsdaten der Multimatik. Das VR_70 Modul ist an sich hinfällig, weil alle Daten davon im 700 enthalten sind.
Danke, nachdem bei mir alles englisch ist habe ich en dateien verwendet, da gibts die 15.700.csv nicht, und auf die Idee im de Verzeichnis nachzuschauen bin ich nicht gekommen :-(
OK, das habe ich jetzt angepasst, aber keine Änderung
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 23
masters: 3
messages: 216
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903" ich meine auch das eben das konfigfile für die Multimatik nicht eingelesen wird und daher auch Werte ausgelesen werden:
root@HAL9000:~# ebusctl -s 192.168.255.9 -p 8888 find |grep -v data
broadcast outsidetemp = -2.375
broadcast vdatetime = 11:34:32;29.01.2017
bai currenterror = -;-;-;-;-
bai DateTime = nosignal; (ERR: argument value out of valid range for 1008b5040100 / 0a00ffffffffffffffa0fd)
bai FloorHeatingContact = off
bai FlowSetPotmeter = (ERR: invalid position for 3108b509030df003 / )
bai FlowTemp = 74.94;ok
bai FlowTempDesired = 75.00
bai FlowTempMax = 89.56
bai HcHours = 34
bai HcPumpMode = (ERR: invalid position for 3108b509030d4904 / )
bai HoursTillService = (ERR: invalid position for 3108b509030d2004 / )
bai HwcDemand = no
bai HwcWaterflow = 0.00
bai Mode = standby
bai ModulationTempDesired = 20.3
bai OutdoorstempSensor = -2.62;ok
bai PartloadHcKW = (ERR: invalid position for 3108b509030d0704 / )
bai PowerValue = 10 04 53 14 64 18
bai PrEnergyCountHc1 = 87926
bai ReturnRegulation = (ERR: invalid position for 3108b509030d0c04 / )
bai ReturnTemp = -1.81;cutoff
bai SDFlame = on
bai SDGasvalve = on
bai SDTRT = 70.00;64415;ok
bai SerialNumber = 36 31 35 30 35 32 39 34
bai SetFactoryValues = no
bai Status = (ERR: invalid position for 3108b5110103 / )
bai Status01 = 74.5;70.0;-2.375;49.5;49.5;on
bai Status02 = auto;60;75.0;70;65.0
bai Status16 = (ERR: invalid position for 3108b5040116 / )
bai StorageTemp = 49.81;ok
bai StorageTempDesired = 55.00
bai ValveMode = (ERR: invalid position for 3108b509030d2a04 / )
bai WaterPressure = 2.152;ok
scan.08 = Vaillant;BAI00;0116;9602
scan.08 id = 21;16;31;0010015600;3100;006988;N1
scan.15 = Vaillant;70000;0419;4603
scan.15 id = 21;16;46;0020218357;0082;036759;N3
scan.52 = Vaillant;VR_70;0109;2903
scan.52 id = 21;16;34;0020184843;0082;013535;N3
und gleichzeitig bekomme ich auch jede Menge unknown messages
2017-01-29 11:35:46.462 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:35:46.677 [update notice] update broadcast outsidetemp QQ=10: -2.375
2017-01-29 11:35:54.411 [update notice] update bai Status01 QQ=10: 75.0;70.0;-2.375;49.5;49.5;on
2017-01-29 11:35:54.705 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008086041a02c87d00
2017-01-29 11:35:54.971 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:35:55.229 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:35:55.476 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:04.474 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:04.768 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041902c87d00
2017-01-29 11:36:05.038 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:05.297 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:05.544 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:14.501 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:14.794 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041902c87d00
2017-01-29 11:36:15.065 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:15.322 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-01-29 11:36:15.580 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:15.827 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:24.560 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:24.853 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041902c87d00
2017-01-29 11:36:25.128 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:25.380 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:25.628 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:34.603 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:34.895 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041802c87d00
2017-01-29 11:36:35.166 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:35.424 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:35.671 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:44.621 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:44.915 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041802c87d00
2017-01-29 11:36:45.184 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:45.442 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-01-29 11:36:45.715 [update error] unable to parse bai DateTime from 1008b5040100 / 0a00ffffffffffffffa0fd: ERR: argument value out of valid range
2017-01-29 11:36:45.952 [update notice] update broadcast vdatetime QQ=10: 11:36:32;29.01.2017
2017-01-29 11:36:46.210 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:46.476 [update notice] unknown MS cmd: 1008b5110100 / 08af04152b040f0081
2017-01-29 11:36:46.721 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:36:46.937 [update notice] update broadcast outsidetemp QQ=10: -2.375
2017-01-29 11:36:54.675 [update notice] update bai Status01 QQ=10: 75.0;70.0;-2.375;49.5;49.5;on
2017-01-29 11:36:54.969 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041802c87d00
2017-01-29 11:36:55.239 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:36:55.498 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:36:55.744 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
2017-01-29 11:37:04.738 [update notice] update bai Status01 QQ=10: 74.5;70.0;-2.375;49.5;49.5;on
2017-01-29 11:37:05.030 [update notice] unknown MS cmd: 1052b5230103 / 0f008000800080008085041802c87d00
2017-01-29 11:37:05.298 [update notice] update bai Mode QQ=10: standby
2017-01-29 11:37:05.557 [update notice] unknown MS cmd: 1052b523080114ff0000ffff00 / 0101
2017-01-29 11:37:05.804 [update notice] unknown MS cmd: 1052b5230402010158 / 020155
das wäre ja jetzt grundsätzlich egal, aber ich möchte gerne die Werte der Multimatik auslesen, und vor allem möchte die Betriebsarten der beiden Heizkreise steuern, also eben z.b. die Heizkureven anspassen. Da blicke ich im Moment noch nicht durch.
noch eine Frage, wenn ich MQTT benutzen will muss ich den ebusd mit der mqtt selbst kompilieren?
Gruß, Karl
edit: habe gerade beim full scan folgende Fehelermeldung gesehen:
2017-01-29 11:50:23.210 [main error] unable to load scan config ec: no file from /etc/ebusd/vaillant with prefix ec. matches ID "70000", SW0419, HW4603
20
Zitat von: schka17 am 29 Januar 2017, 11:45:41
OK, das habe ich jetzt angepasst, aber keine Änderung
da ist wohl was schief gegangen. sicher dass die 15.700.csv in /etc/ebusd/vaillant liegt, lesbar ist, und ebusd neu gestartet wurde?
EDIT:ach ja, für MQTT gibts noch kein Release.
und deine BAI scheint wieder mal neuer zu sein, als eigentlich von den CSVs supported...
Zitat von: john30 am 29 Januar 2017, 12:07:27
da ist wohl was schief gegangen. sicher dass die 15.700.csv in /etc/ebusd/vaillant liegt, lesbar ist, und ebusd neu gestartet wurde?
Spannend, ich hatte den service neu gestartet, aber scheinbar lief noch im Hintergrund ein zweiter daemon den ich zuvor mal manuell gestartet hatte, anyway, ja jetzt wurde die 15.700.csv geladen, ich wühle mich jetzt mal durch die Werte, ist nicht alles sehr sprechend für einen nicht gelernten Installateur....
version: ebusd 2.3.5bcc475
signal: acquired
symbol rate: 70
masters: 3
messages: 557
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
Zitat von: john30 am 29 Januar 2017, 12:07:27
EDIT:ach ja, für MQTT gibts noch kein Release.
und deine BAI scheint wieder mal neuer zu sein, als eigentlich von den CSVs supported...
Kann ich da ich da was beitragen um das upzudaten?
Ab und zu bekomme ich folgende Meldung in verschiedenen readings
ERR: invalid position in decodeIst das ein Lesefehler auf dem ebus?
Dann sind da noch ein paar Fragen aufgetaucht, ist es richtig dass ich keine Rücklauftemperaturen auslesen kann? Ich habe bei mir nur folgende Variablen für den HK1:
root@HAL9000:/opt/fhem/log# ebusctl find |grep Hc1
700 Hc1ActualFlowTempDesired = 0.0
700 Hc1AutoOffMode = eco
700 Hc1CircuitType = mixer
700 Hc1ExcessTemp = 0.0
700 Hc1FlowTemp = 59.2
700 Hc1HeatCurve = 1.5
700 Hc1HeatCurveAdaption = 0.0
700 Hc1MaxFlowTempDesired = no data stored
700 Hc1MinFlowTempDesired = no data stored
700 Hc1MixerMovement = 0.0
700 Hc1PumpStatus = 0
700 Hc1RoomTempSwitchOn = off
700 Hc1Status = 0
700 Hc1SummerTempLimit = 21.0
bai PrEnergyCountHc1 = no data stored
bai PrEnergySumHc1 = no data stored
Und noch eine Frage zur Steuerung, ich habe meine FBH umgestellt und regle nun mit PWMR die einzelnen Kreise, die Heizkörper im Keller und Wintegrarten sind mit Homematic Aktoren ausgestattet. Wenn nun keiner der FBH Kreise oder Heizköprer eine Wärmeanforderung hat (sprich, alles ist geschlossen) über welchen Parameter fahre ich am besten den jewiligen HK kreis zurück (HK1=Heizkörper, HK2=FBH), einfach den Kreis ausschalten oder z.b. über die Vorlauftemperatur zurückfahren?
Gruß,
Karl
Edit:
diese Fehlermeldung habe ich nch wie vor
2017-01-29 17:09:36.652 [main error] unable to load scan config 52: no file from /etc/ebusd/vaillant with prefix 52. matches ID "vr_70", SW0109, HW2903
was bedeutet das?
Zitat von: schka17 am 29 Januar 2017, 16:46:32
Kann ich da ich da was beitragen um das upzudaten?
Ja:
- alle bai Nachrichten abfragen und auf Validität gegen angezeigte Daten der Anlage prüfen
- schauen ob eine das bai.*.inc besser passt
- restliche von der Anlage angezeigte Daten auf dem Bus identifizieren
- entsprechend aktualisiertes CSV dafür schreiben
Zitat von: schka17 am 29 Januar 2017, 16:46:32
Ab und zu bekomme ich folgende Meldung in verschiedenen readings
ERR: invalid position in decode
Ist das ein Lesefehler auf dem ebus?
Nein, das bedeutet, dass die Nachrichtendefinition in der CSV nicht zur tatsächlichen Nachricht passt.
Zitat von: schka17 am 29 Januar 2017, 16:46:32
Dann sind da noch ein paar Fragen aufgetaucht, ist es richtig dass ich keine Rücklauftemperaturen auslesen kann?
Da musst Du Sven fragen, der alle Nachrichten der 700 entschlüsselt hat.
Zitat von: schka17 am 29 Januar 2017, 16:46:32
Und noch eine Frage zur Steuerung, ich habe meine FBH umgestellt und regle nun mit PWMR die einzelnen Kreise, die Heizkörper im Keller und Wintegrarten sind mit Homematic Aktoren ausgestattet. Wenn nun keiner der FBH Kreise oder Heizköprer eine Wärmeanforderung hat (sprich, alles ist geschlossen) über welchen Parameter fahre ich am besten den jewiligen HK kreis zurück (HK1=Heizkörper, HK2=FBH), einfach den Kreis ausschalten oder z.b. über die Vorlauftemperatur zurückfahren?
Das hängt wieder von den Möglichkeiten ab, die die CSVs definieren. M.W. kann man einen Heizkreis über B505 einfach auf off bzw. eco schalten. Alternativ auch Heizungskurve runterfahren.
Zitat von: schka17 am 29 Januar 2017, 16:46:32
diese Fehlermeldung habe ich nch wie vor
siehe früherer Post
Moin! Wie würde man vorgehen müssen, um weitere Werte zu dekodieren? Habe noch eine Unbekannte in der Anlage...
Zitat von: bacanol am 05 Februar 2017, 18:25:45
Moin! Wie würde man vorgehen müssen, um weitere Werte zu dekodieren? Habe noch eine Unbekannte in der Anlage...
Naja, beobachten, wie sich die Daten verändern und versuchen, das mit einem realen Wert zu assoziieren... Wie sieht die Unbekannte denn aus?
Hallo ebus-Freunde,
ich habe meine Vaillant-Therme in Verbindung mit auromatic 620/3 und einer VR90-Fernbedingung mit der ebus-Platine gekoppelt. Es lief auch soweit alles problemlos, bis nach ein paar Stunden / einen Tag, sporadisch in der auromatic stand "Verbindung zum Heizgerät verloren", vorhin gerade zur VR90.
Auch das ECMD liefert nun immer wieder:
2017.02.06 19:23:49 2: EBUS: first attempt to read timed out, trying to close and open the device.
2017.02.06 19:24:50 2: EBUS: first attempt to read timed out, trying to close and open the device.
2017.02.06 19:24:54 2: EBUS: first attempt to read timed out, trying to close and open the device.
2017.02.06 19:25:41 2: EBUS: first attempt to read timed out, trying to close and open the device.
2017.02.06 19:25:44 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
Als USB-to-seriell habe ich das hier:
http://www.ebay.de/itm/272519766747?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Der Ebus selbst scheint aber stabil zu laufen
ebusctl-info:
ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 23
reconnects: 0
masters: 5
messages: 726
conditional: 12
poll: 1
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Vaillant;ID=RC C ;SW=0508;HW=6201", loaded "vaillant/35.rcc.1.csv"
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Was kann da das Problem sein?
Das sieht mir so aus, als ob FHEM den EBUS mit irgendwelchen Befehlen flutet und damit lahm legt. Die auromatic kann damit den Bus nicht mehr selbst nutzen.
LG
pah
Dann müsste es so sein, dass FHEM "write" an EBUS sendet?
[main notice] write hc TempDesired: decode done
Das sollte jedoch nur passieren wenn ich eine Einstellung ändere, wie hier den Sollwert für die Raumtemp.
Eine andere Frage:
Ich habe mich aus dem Ebus-Wiki an Einstellungen für Devices für die fhem.cfg und bai00.cfg gehalten.
Im Device erhalte ich immer 2 Readings, Bsp:
fhem.cfg:
define Aussentemp ECMDDevice bai00.class
attr Aussentemp DbLogExclude .*
attr Aussentemp DbLogInclude Aussentemp.*
attr Aussentemp IODev EBUS
attr Aussentemp addLog Aussentemp
attr Aussentemp alias Außentemperatur
attr Aussentemp event-aggregator Aussentemp:300:mean
attr Aussentemp group Vaillant
attr Aussentemp icon temp_outside
attr Aussentemp room Heizung
attr Aussentemp sortby 1
attr Aussentemp stateFormat {sprintf "%.1f °C", ReadingsVal($name, "Aussentemp", 0)}
bai00.cfg:
get Aussentemp cmd {"r -m 10 outsidetemp\n"}
get Aussentemp expect "-?\d+\.\d+\n\n"
get Aussentemp postproc { $_ }
Aussentemp -1.5 2017-02-07 21:49:21
state Aussentemp -1.5 2017-02-07 21:49:21
Ich kann nicht nachvollziehen woher das "doppelte" Reading kommt, state wäre hier irgendwie sinnfei.
Zitat von: john30 am 06 Februar 2017, 08:21:32
Naja, beobachten, wie sich die Daten verändern und versuchen, das mit einem realen Wert zu assoziieren... Wie sieht die Unbekannte denn aus?
Konkret geht es um den VR60 und den Heizkreis 3, bzw um die Werte und die Steuerung.
Zitat von: bacanol am 08 Februar 2017, 10:51:19
Konkret geht es um den VR60 und den Heizkreis 3, bzw um die Werte und die Steuerung.
Der VR60 ist in den CSVs verfügbar.
Zitat von: john30 am 09 Februar 2017, 08:16:02
Der VR60 ist in den CSVs verfügbar.
Prima! Dann aktualisiere ich nochmal und melde mich.
@John30
Hallo Zusammen,
bei mir läuft jetzt die 3pre Version.
version: ebusd 3.0pre.1e6b776
signal: acquired
symbol rate: 23
reconnects: 0
masters: 3
messages: 712
conditional: 12
poll: 1
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
Die Config Dateien habe ich aus https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de kopiert und nach /etc/ebusd abgelegt. Sind die csv für ebusd-2.1.x auch für ebus-3.0pre geeignet? Denn ebusd --checkconfig zeigt mir haufenweise Fehlermeldungen an.
Error reading "/etc/ebusd/vaillant/05.vd3.csv" line 8 field 8 value "0000": ERR: duplicate entry
Erroneous item is here:
r,,SoftwareVersion,,,,,0000,,,HEX:4,,,
^
Error reading "/etc/ebusd/vaillant/05.vd3.csv" line 9 field 8 value "0100": ERR: duplicate entry
Erroneous item is here:
r,,EnableMonitoring,,,,,0100,,,HEX:5,,,
^
Error reading "/etc/ebusd/vaillant/05.vd3.csv" line 10 field 8 value "0200": ERR: duplicate entry
Erroneous item is here:
r,,FlexibleMonitoring,,,,,0200,,,HEX:8,,,
...
...
...
Was mache ich falsch?
Danke,
a200.
Hat jemand Erfahrung mit den Zählern PrEnergySumHc1, PrEnergySumHwc1 bzw. PrEnergyCountHc1, PrEnergyCountHwc1
Habe bislang via PrEnergySumxxx ausreichend zuverlässig auf den Verbrauch hochgerechnet.
Nun zählt PrEnergySumHc1 nicht mehr weiter, die hex-Abfrage ergibt 049bffffff
Eigentlich müsste man diese Zähler gefahrlos zurücksetzen können, da es sich um Wartungsdaten handelt.
r,bai,PrEnergySumHc1,PrEnergySumCH1_DK,,08,b509,0df500,,s,ULG,,,Wartungsdaten
In der Doku und der Bedienerführung habe ich keine Möglichkeit gefunden den Zähler zurückzusetzen.
Hat jemand diese Zähler schon mal zurückgesetzt?
Diese beiden habe ich noch nicht zurückgesetzt.
Wohl aber die Fehler im ersten/zweiten Zündversuch - die sind laut CSV auch readonly, lassen sich aber per Hex auf jeden beliebigen Wert setzen. Nicht so allerdings der Zähler der Zündausfälle! Wenn der bei 254 ist, zählt er offenbar gar nicht weiter. Die anderen beiden bleiben auch bei 254, bis man sie manuell zurücksetzt.
Der Vaillant-Kundendienst erfährt das offenbar auch nur auf interne Rückfrage - bin gespannt, welche Möglichkeit man mir offiziell präsentiert, wie man den Zähler zurücksetzt.
Also zu den PrEnergyCount/Sum: versuche es einfach mal! Bei mir sind die Zähler noch nicht so hoch - aber es zählt bei mir auch nicht immer der richtige Zähler - also vielleicht zählt auch der PrEnergySumHwc1 aktuell bei Dir?
Oder zählt denn der PrEnergyCountHc1 und nur der Sum nicht??
Zitat von: a200 am 19 Februar 2017, 14:54:00
Sind die csv für ebusd-2.1.x auch für ebus-3.0pre geeignet?
ja.
Zitat von: a200 am 19 Februar 2017, 14:54:00
Denn ebusd --checkconfig zeigt mir haufenweise Fehlermeldungen an.
Das liegt daran, dass Du --scanconfig als Parameter vergessen hast. Ohne den werden
alle CSVs geladen und dann gibt es natürlich Überlappungen.
Zitat von: john30 am 20 Februar 2017, 10:21:32
ja.
Das liegt daran, dass Du --scanconfig als Parameter vergessen hast. Ohne den werden alle CSVs geladen und dann gibt es natürlich Überlappungen.
Mea culpa. Vor lauten Bäumen sehe ich die Parameter nicht mehr! Sorry.
Jetzt noch eine Verständnisfrage. Ich nutze z.Zt. den ReadOnly Adapter: http://ebus-wiki.org/lib/exe/detail.php/ebus/arduinoebus2usbreadonly.png?id=ebus%3Aebuskonverter (http://ebus-wiki.org/lib/exe/detail.php/ebus/arduinoebus2usbreadonly.png?id=ebus%3Aebuskonverter) an der erweiterten Version arbeite ich noch! ;) Ist das aber der Grund für die ganzen Timeouts beim Lesen der Geräte?
2017-02-19 20:39:30.415 [bus error] send to 26: ERR: read timeout, retry
2017-02-19 20:39:30.459 [bus error] send to 26: ERR: read timeout, retry
2017-02-19 20:39:30.517 [bus error] send to 26: ERR: read timeout, retry
2017-02-19 20:39:30.544 [bus error] send to 26: ERR: read timeout
2017-02-19 20:39:30.544 [main error] scan config 26 message: ERR: read timeout
2017-02-19 20:39:32.566 [bus error] send to 50: ERR: read timeout, retry
2017-02-19 20:39:32.609 [bus error] send to 50: ERR: read timeout, retry
Gehe ich Recht in der Annahme, dass ebusctrl/busd die Komponente auslesen will, das aber nicht kann weil er keine Kommandos senden kann? Und dass wen ich die erwachsenen Version einsetze, dass ich dann auch die ganzen Parameter erhalte? Und bis dahin ich nur passiv zuhören kann wenn was gesendet wird?
Danke und Gruß,
a200.
@ Sven77 die hwc haben noch weitergezählt, die hc nicht mehr (weil am Anschlag)
Habe alle mit einem mulmigen Gefühl per write hex zurückgesetzt.
Die hc zählen jetzt wieder. Ich hoffe, dass es auch mit den hwc klappt.
Edit: es wird auch in hwc gezählt - vermutlich wegen Umschaltung, obwohl keine Pufferladung.
Zitat von: a200 am 20 Februar 2017, 18:03:15
Ich nutze z.Zt. den ReadOnly Adapter. Ist das aber der Grund für die ganzen Timeouts beim Lesen der Geräte?
exakt.
Zitat von: a200 am 20 Februar 2017, 18:03:15
Gehe ich Recht in der Annahme, dass ebusctrl/busd die Komponente auslesen will, das aber nicht kann weil er keine Kommandos senden kann? Und dass wen ich die erwachsenen Version einsetze, dass ich dann auch die ganzen Parameter erhalte? Und bis dahin ich nur passiv zuhören kann wenn was gesendet wird?
genau so ist es.
Ich bin jetzt dabei die unknown messages zu analysieren, vor allem suche ich noch nach ein paar für wichtigen Parametern. Einem bin ich schon sehr nahe (glaube ich), nämlich dem Holiday Status.
Beim aktivieren bekomme ich diese Meldung:
2017-02-25 17:42:27.269 [update notice] unknown MS cmd: 1008b512020000 / 00
Beim deaktivieren
2017-02-25 17:42:56.060 [update notice] unknown MS cmd: 1008b512020064 / 00
Mithilfe von Wiki und google habe ich schon ein paar Dinge herausgefunden
ein kommando:
1008b512020000 / 00
10 Adresse Sender Zentrale
08 Adresse Empfänger = BAI
b5 Vaillant
12 Klasse des Kommandos
02 Anzahl datenbytes = 2
aber was bedeutet der Rest 0000 / 00 und vor allem wie erstelle ich hier die richtige Einträge für das Configfile?
Zitat von: schka17 am 25 Februar 2017, 18:57:52
Ich bin jetzt dabei die unknown messages zu analysieren, vor allem suche ich noch nach ein paar für wichtigen Parametern. Einem bin ich schon sehr nahe (glaube ich), nämlich dem Holiday Status.
Beim aktivieren bekomme ich diese Meldung:
2017-02-25 17:42:27.269 [update notice] unknown MS cmd: 1008b512020000 / 00
Beim deaktivieren
2017-02-25 17:42:56.060 [update notice] unknown MS cmd: 1008b512020064 / 00
Mithilfe von Wiki und google habe ich schon ein paar Dinge herausgefunden
ein kommando:
1008b512020000 / 00
10 Adresse Sender Zentrale
08 Adresse Empfänger = BAI
b5 Vaillant
12 Klasse des Kommandos
02 Anzahl datenbytes = 2
aber was bedeutet der Rest 0000 / 00 und vor allem wie erstelle ich hier die richtige Einträge für das Configfile?
ich glaube, das ist eher die Warmwasserzirkulation an (0x64) bzw. aus (0x00).
Hallo John,
Danke für die Antwort, aber das kann ich ausschließen, ich habe keine Warmwasserzirkulation, zumindest weiss ich nichts davon, und ich kann es jederzeit nachstellen. Also setzen und rücksetzen über die Vaillant App erzeugt genau diese messages. Ich habe zwar jede Menge anderer unknown Messages, aber da bin ich mir sehr sicher.
Sent from my iPad using Tapatalk
Zitat von: schka17 am 26 Februar 2017, 12:37:27
Danke für die Antwort, aber das kann ich ausschließen, ich habe keine Warmwasserzirkulation, zumindest weiss ich nichts davon, und ich kann es jederzeit nachstellen. Also setzen und rücksetzen über die Vaillant App erzeugt genau diese messages. Ich habe zwar jede Menge anderer unknown Messages, aber da bin ich mir sehr sicher.
ich glaubs nicht. probier mal den hex selbst zu senden. dann müsste die app irgendwann den angezeigten holiday status nachziehen
Zitat von: john30 am 26 Februar 2017, 12:49:40
ich glaubs nicht. probier mal den hex selbst zu senden. dann müsste die app irgendwann den angezeigten holiday status nachziehen
Genau das wollte ich auch machen, aber ich habe die Syntax einfach nicht verstanden und bekomme immer nur eine Fehlermeldung, kann mich jetzt nicht mehr erinnern welche
Sent from my iPad using Tapatalk
Zitat von: schka17 am 26 Februar 2017, 12:56:32
Genau das wollte ich auch machen, aber ich habe die Syntax einfach nicht verstanden und bekomme immer nur eine Fehlermeldung, kann mich jetzt nicht mehr erinnern welche
schätze mal, Du hast das ganze an ebusctl übergeben. du musst aber die absenderadresse (erstes Byte) entfernen, da der Absender dann ja ebusd ist, also z.B. so:
ebusctl hex 08b512020000
Also mit Holiday hat das nichts zu tun - bzw. nur indirekt. Ich bekomme diese "unknown MS" über den ganzen Tag verteilt und habe festgestellt:
1008b512020064 / 00 --> Hwc Bedarf
1008b512020000 / 00 --> kein Hwc Bedarf
Der Brenner hat intern einen Anschluss für eine Zirkulationspumpe - da ist egal, ob der genutzt wird oder nicht. Von daher könnte John recht haben und es setzt nur die Zirkulationspumpe. Könnte man mal versuchen, mitzulesen:
# ebusctl r -c bai cirpump
Die ist bei mir aktuell auch "100", obwohl gar keine Pumpe angeschlossen ist.
Sven
Ja, Ihr habt ja recht, mich hat nur irritiert genau diese Meldungen als erstes und jedesmal kommen. Ich hab mal ein Video aufgenommen wo man den zeitlich Ablauf sieht, aber beim Hochladen bekomme ich leider eine Fehlermeldung. Die Meldungen sehen aber so aus:
einschalten
2017-02-26 13:19:47.241 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-02-26 13:19:53.572 [update notice] unknown MS cmd: 0015b52406020003001b00 / 0601031b000700
2017-02-26 13:19:58.792 [update notice] unknown MS cmd: 0015b52406020003011b00 / 0601031b000700
2017-02-26 13:20:01.966 [update notice] unknown MS cmd: 0015b52406020000007800 / 06030078000700
2017-02-26 13:20:13.778 [update notice] unknown MS cmd: 1008b5110100 / 085003130000080001
2017-02-26 13:20:19.359 [update notice] unknown MS cmd: 0015b52406020000000700 / 050300070000
ausschalten
2017-02-26 13:20:38.396 [update notice] unknown MS cmd: 1008b512020064 / 00
2017-02-26 13:20:51.804 [update notice] unknown MS cmd: 0015b52406020000007800 / 06030078000000
2017-02-26 13:21:14.240 [update notice] unknown MS cmd: 1008b5110100 / 08f603130014380080
2017-02-26 13:21:27.112 [update notice] unknown MS cmd: 0015b52406020000007800 / 06030078000000
2017-02-26 13:21:27.618 [update notice] unknown MS cmd: 0015b52406020000000700 / 050300070000
Ich weiss nicht wie ich da weiter komme, ich hoffe Ihr habt eine Idee
Gruß
Karl
Also erstmal wäre es interessant zu erfahren, welche Steuerung Du hast.
Ich setze die Ferienfunktion bei mir einfach über die Steuerung...
Für die multiMATIC (VRC700) geht das so:
# ebusctl w -c 700 HolidayStartPeriod 01.04.2017
# ebusctl w -c 700 HolidayEndPeriod 15.04.2017
Oder über hwcHolidayStartPeriod, hc1HolidayStartPeriod, hc2HolidayStartPeriod usw. nur den Warmwasserkreis oder einen der Heizkreise.
Ich denke nicht, dass der Brenner (08) überhaupt einen Ferienmodus kennt. In diesem bekommt er halt einfach keine Wärmeanforderung.
Ich habe auch eine VRC700, aber die verwende ich nicht, ich verwende nur die App
version: ebusd 3.0pre.15d5500
signal: acquired
symbol rate: 39
reconnects: 0
masters: 4
messages: 568
conditional: 3
poll: 0
update: 8
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=0607;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
Zitat von: schka17 am 26 Februar 2017, 14:59:06
Ich habe auch eine VRC700, aber die verwende ich nicht, ich verwende nur die App
Ein Irrglaube ;)
Die App sendet nur Befehle an die VRC!
Die aus dem Log mitgeschickten "0015b524060200..." ist alles nur lesend, das macht die App (bzw. vielmehr die VR900), um zu prüfen ob auch alles so gesetzt wurde, wie sie es erwartet.
Suche mal nach "0015b524060201..." das sind Schreibnachrichten, und genau die könntest Du auch schicken.
Welche Funktion genau nutzt du überhaupt? "Einen Tag nicht zu Hause" oder wirklich mit Datum geplante?
Das "Einen Tag nicht zu Hause" habe ich noch nicht weiter untersucht - in meiner Steuerung setze ich einfach immer ein Datum... diese sind übrigens immer erster und letzter Urlaubstag. Da meine Heizkreise schon ein paar Stunden vor meiner Rückkehr wieder angehen sollen, setze ich übrigens immer einzeln die hwc/hc1/hc2 wie oben genannt!
Sven
Guten Abend zusammen,
ich hab mich heute mal wieder rangesetzt - leider mit beschränktem Erfolg. Meine virtuelle Maschine empfängt grundsätzlich, hat aber beim Senden und auch beim Scannen immer wieder Probleme. Da ich hier über ca. 40m twisted-pair (CAT-7) dranhänge, vermute ich den Fehler hier.
Also wollte ich den Adapter direkt an der ANlage verdrahten - mein NAS steht ja neben dran.
Ich scheitere allerdings bereits am kompilieren.
autogen.sh liefert:
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... no
checking whether g++ supports C++11 features with -std=gnu++0x... no
configure: error: *** A compiler with support for C++11 language features is required.
Ein Test sagt allerdings was anderes:
admin@nas:~/ebusd$ g++ -std=gnu++11
g++: fatal error: no input files
compilation terminated.
Ich nutze Wheezy und gcc mit Version 4.7.2
Kann mir jemand einen Tip geben?
Grüße, Andi
Zitat von: Sven77 am 26 Februar 2017, 15:26:44
Ein Irrglaube ;)
Die App sendet nur Befehle an die VRC!
Die aus dem Log mitgeschickten "0015b524060200..." ist alles nur lesend, das macht die App (bzw. vielmehr die VR900), um zu prüfen ob auch alles so gesetzt wurde, wie sie es erwartet.
Suche mal nach "0015b524060201..." das sind Schreibnachrichten, und genau die könntest Du auch schicken.
Welche Funktion genau nutzt du überhaupt? "Einen Tag nicht zu Hause" oder wirklich mit Datum geplante?
Das "Einen Tag nicht zu Hause" habe ich noch nicht weiter untersucht - in meiner Steuerung setze ich einfach immer ein Datum... diese sind übrigens immer erster und letzter Urlaubstag. Da meine Heizkreise schon ein paar Stunden vor meiner Rückkehr wieder angehen sollen, setze ich übrigens immer einzeln die hwc/hc1/hc2 wie oben genannt!
Sven
Ich meinte natürlich, ich bediene nicht das Steuergerät. Das die heizung und Pumpen über das VRC gesteuert werden, ist mir schon klar, genauso dass die App über das Kommunikationsmodul die entsprechenden Kommandos absetzt.
Die Stati für einen Tag zuhause oder einen Tag abwesend werden mit dem Parameter SFMode 3 bzw. 4 übergeben., genauso wie Partymodus usw.
Holiday mit Datum funktioniert irgendwie anders, in der App gibts dann auch eindeutig einen Status dazu, sieht in der App so aus
(https://uploads.tapatalk-cdn.com/20170226/d8c47269b3abdbb6fad23cec369d7394.jpg)
Wo kann man nachlesen was lesend oder schreibend ist, oder welche Kategorien diese commands sind?
Sent from my iPad using Tapatalk
Ich benutze ECMD (läuft seit über 1,5 Jahren problemlos)
Seit dem letzten fhem-update bekomme ich z. B. bei einem "set HK.Hz T.Ferien 16.0" in einem popup
jquery.min.js line 2:
Error: Syntax error, unrecognized expression: .dval[informid=HK\.Hz-T.Ferien]
Im Log steht nichts (verbose=5).
Die Definition
# Ferientemperatur
get T.Ferien cmd {"r RoomTempHoliday\n"}
get T.Ferien expect ".*\n\n"
get T.Ferien postproc { sprintf("%.1f",$_) }
set T.Ferien cmd { "w -c ui RoomTempHoliday %temp\n" }
set T.Ferien params temp
set T.Ferien expect "done\n"
set T.Ferien postproc {if ($_ =~ "done") {"%temp"} else {$_}}
Hat jemand die letzten Tage einen fhem-update gemacht?
Muss ich ich irgendwo was ändern?
Einen fhem restore habe ich noch nicht versucht.
Bitte mal im Web Frontend Device (typischerweise genannt WEB, Modul FHEMWEB) das Attribut confirmJSError auf 0 setzen.
LG
pah
@pah
mit confirmJSError 0 kommt das Popup nicht mehr, aber das set wird nicht ausgeführt.
Ein Logeintrag wird nur beim get erzeugt nicht beim set.
Edit: mit featurelevel 5.7 funktioniert der set-cmd
Edit-2: von Rudi gefixt
Zitat von: Andi291 am 26 Februar 2017, 21:23:55
autogen.sh liefert:
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... no
checking whether g++ supports C++11 features with -std=gnu++0x... no
configure: error: *** A compiler with support for C++11 language features is required.
Ich nutze Wheezy und gcc mit Version 4.7.2
Du brauchst g++ (>=4.8.1), wie hier (https://github.com/john30/ebusd) und da (https://github.com/john30/ebusd/wiki/1.-Build-and-install) beschrieben.
Hallo,
ich habe den eService eBus Ethernet Koppler und versuche verzweifelt, ebusd ans Laufen zu bringen. Im Raw-Modus bekomme ich die aa-Zeichen, aber im normalen Modus bekomme ich nur Fehler (s.u.). Was kann das sein?
Ich habe die .csv-Dateien der Version 2.1.x (DE) inkl. des Vaillant-Unterverzeichnisses auf mein Raspi kopiert.
Ansonsten ein super Projekt, vielen Dank für die herausragende Arbeit!
Vielen Dank und viele Grüße,
Tom
2017-02-28 22:59:51.198 [main notice] ebusd 3.0pre.p20170228 started
2017-02-28 22:59:51.209 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-02-28 22:59:51.310 [bus notice] signal acquired
2017-02-28 22:59:51.311 [bus notice] new master 10, master count 2
2017-02-28 22:59:51.311 [bus notice] new master 03, master count 3
2017-02-28 22:59:51.311 [update notice] unknown MS cmd: 1008b5110101 / 094f3d1001ffff0100ff
2017-02-28 22:59:51.312 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.314 [update notice] unknown MS cmd: 1008b5110101 / 094f3d1001ffff0100ff
2017-02-28 22:59:51.314 [update notice] unknown BC cmd: 10feb516080006592228020217
2017-02-28 22:59:51.315 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.315 [update notice] unknown MS cmd: 1008b5110102 / 06033c96467850
2017-02-28 22:59:51.315 [update notice] unknown MS cmd: 1008b5110100 / 087d02197d040f0001
2017-02-28 22:59:51.316 [update notice] unknown MS cmd: 1008b5100305ff01 / 0101
2017-02-28 22:59:51.316 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-02-28 22:59:51.316 [update notice] unknown MS cmd: 1008b5120204ff / 0101
2017-02-28 22:59:51.316 [update notice] unknown BC cmd: 10feb516030100d8
2017-02-28 22:59:51.318 [update notice] unknown MS cmd: 1008b5110101 / 09503d1001ffff0100ff
2017-02-28 22:59:51.319 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.321 [update notice] unknown MS cmd: 1008b5110101 / 09503e1001ffff0100ff
2017-02-28 22:59:51.321 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.324 [update notice] unknown MS cmd: 1008b5110101 / 09503d1001ffff0100ff
2017-02-28 22:59:51.324 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.324 [update notice] unknown MS cmd: 1008b5110102 / 06033c96467850
2017-02-28 22:59:51.327 [update notice] unknown MS cmd: 1008b5110101 / 09503e1001ffff0100ff
2017-02-28 22:59:51.327 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:51.330 [update notice] unknown MS cmd: 1008b5110101 / 094f3d1001ffff0100ff
2017-02-28 22:59:51.330 [update notice] unknown MS cmd: 1008b5100900005affffff040000 / 0101
2017-02-28 22:59:52.033 [bus notice] max. symbols per second: 2057
2017-02-28 23:00:01.201 [main notice] starting initial scan for fe
2017-02-28 23:00:06.366 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:09.238 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-02-28 23:00:09.269 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:14.916 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:22.032 [bus error] send to fe: ERR: arbitration lost
2017-02-28 23:00:22.032 [main error] initial scan failed: ERR: arbitration lost
2017-02-28 23:00:30.563 [bus error] send to 08: ERR: arbitration lost, retry
2017-02-28 23:00:33.287 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:37.574 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:38.278 [bus error] send to 08: ERR: wrong symbol received
2017-02-28 23:00:38.278 [main error] scan config 08 message: ERR: wrong symbol received
2017-02-28 23:00:47.779 [bus error] send to 15: ERR: arbitration lost, retry
2017-02-28 23:01:00.712 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:10.923 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:11.683 [bus error] send to 15: ERR: wrong symbol received
2017-02-28 23:01:11.684 [main error] scan config 15 message: ERR: wrong symbol received
Fehler sind das nicht - zeigt nur, dass keine passende CSV geladen wurde.
Kannst Du bitte mal die Ausgabe von 'ebusctl info' posten, am besten nachdem Du einige Minuten vorher ein 'ebusctl scan full' abgesetzt hast (das gibt direkt nichts aus und läuft eine Weile, bis es alle Busteilnehmer gefunden hat).
Zitat von: tom37 am 28 Februar 2017, 23:09:34
2017-02-28 23:00:01.201 [main notice] starting initial scan for fe
2017-02-28 23:00:06.366 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:09.269 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:14.916 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:22.032 [bus error] send to fe: ERR: arbitration lost
2017-02-28 23:00:22.032 [main error] initial scan failed: ERR: arbitration lost
2017-02-28 23:00:30.563 [bus error] send to 08: ERR: arbitration lost, retry
2017-02-28 23:00:33.287 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:37.574 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:38.278 [bus error] send to 08: ERR: wrong symbol received
2017-02-28 23:00:38.278 [main error] scan config 08 message: ERR: wrong symbol received
2017-02-28 23:00:47.779 [bus error] send to 15: ERR: arbitration lost, retry
2017-02-28 23:01:00.712 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:10.923 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:11.683 [bus error] send to 15: ERR: wrong symbol received
2017-02-28 23:01:11.684 [main error] scan config 15 message: ERR: wrong symbol received
das sind definitiv problematische Logeinträge. Insbesondere permanent arbitration lost deutet darauf hin, dass der Sendeweg nicht klappt. Somit kannst Du vermutlich nie irgendwas aktiv auf den Bus senden.
Ethernet Koppler sind wegen der deutlich höheren Latenz immer etwas tricky. Hier solltest Du mal schauen, ob der Hersteller ein Tool zur Konfiguration des Adapters hat, womit Du Puffergrößen und evtl. Latenzzeiten justieren kannst.
Puffer darf max. 1 byte sein.
Zitatich habe den eService eBus Ethernet Koppler und versuche verzweifelt, ebusd ans Laufen zu bringen.
Ich habe auch lange Zeit mit dem eService Ethernet Koppler gekämpft, aber nicht zum Laufen gebracht. Hab ihn dann gegen einen eService USB Koppler + RasPi getauscht und erst dort lief es dann.
ZitatEthernet Koppler sind wegen der deutlich höheren Latenz immer etwas tricky. Hier solltest Du mal schauen, ob der Hersteller ein Tool zur Konfiguration des Adapters hat, womit Du Puffergrößen und evtl. Latenzzeiten justieren kannst.
Das mit der Latenz ist ein klares Problem. Deshalb funktioniert ja wohl auch die serielle Schnittstelle am Raspi nicht. Beim eService Modul gibt es nach meinem Wissen keinerlei Möglichkeit, soetwas einzustellen. Man kann dort nur eine TCP oder UDP Verbindung wählen. Wobei ich klar UDP den Vorzug geben würde (Connection-less, kein Retry, schnellerer Transfer). Die Retries macht doch dann eh der ebusd (@john30: stimmt doch, oder?)
Und noch etwas zu den Einstellungen mit dem Poti speziell am am eService Modul (egal ob Ethernet oder USB). Wenn man "aa" empfängt oder die LED blinkt oder auch sonst irgendetwas vernünftiges ankommt, dann heisst das noch lange nicht dass das Poti richtig eingestellt ist. eService ist da ganz schlecht unterwegs und minimalste Änderungen entscheiden z.B. ob man gut oder schlecht kommuniziert, mit einigen oder mit allen Geräten sprechen kann.
Hallo zusammen,
danke für die Tipps! Ich habe mir die Konfiguration nochmal angeschaut und festgestellt, dass ich in der Konfiguration des eService ebusd Ethernet Adapters "enable debug Message Output" aktiviert hatte, was wohl falsch war. Nachdem ich das deaktiviert hatte, scheint es nun zu funktionieren. Unten mal die Ausgabe von ebusctl info (wie von Sven77 vorgeschlagen) und die Log-Einträge. Es ist gigantisch, was Ihr hier auf die Beine gestellt habt (und ich nutze ja aktuell nur einen kleinen Teil der Software ...).
Zwei konkrete Fragen habe ich allerdings: Ich habe eine Vaillant Therme ecoTEC exclusive VC 216/5-7 mit Multimatic 700 Steuerung und eine AroStor Wärmepumpe für die Brauchwasseraufbereitung.
1. In der Steuerung der Therme kann man für die Zirkulationspumpe pro Tag nur 3 Zeitfenster eingeben, an der sie jeweils eingeschaltet wird. Ich würde das gerne flexibler handhaben (z.B. jede Stunde soll sie 10 min. laufen). Gibt es eine Möglichkeit, die Zirkulationspumpe über ebusd ein- und auszuschalten?
2. Auf der Vaillant Webseite steht zur AroStor Wärmpumpe, dass sie ein eBus Interface hat. Mein Heizungsfachmann meinte aber, er hätte lediglich einen Temperaturfühler der Wärmepumpe mit der Steuerung der Therme verbunden und keine eBus Leitung. Hat jemand schon mal über eBusd eine Vaillant AroStor Wärmepumpe ausgelesen und/oder gesteuert?
Nochmals vielen Dank für dieses tolle Projekt und die Unterstützung!
Viele Grüsse,
Tom
version: ebusd 3.0pre.p20170228
signal: acquired
symbol rate: 60
reconnects: 0
masters: 4
messages: 556
conditional: 3
poll: 0
update: 8
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=0607;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0502;HW=9102", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
2017-03-01 20:35:07.404 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:35:07.671 [update notice] unknown MS cmd: 0015b52406020000000700 / 050300070000
2017-03-01 20:35:07.757 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;60.0
2017-03-01 20:35:08.019 [update notice] unknown MS cmd: 1008b5110100 / 0808021822040f0081
2017-03-01 20:35:08.265 [update notice] unknown MS cmd: 1008b5100305ff01 / 0101
2017-03-01 20:35:08.501 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-03-01 20:35:08.742 [update notice] unknown MS cmd: 1008b5120204ff / 0101
2017-03-01 20:35:08.962 [update notice] update broadcast outsidetemp QQ=10: 5.562
2017-03-01 20:35:16.567 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:35:16.841 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:35:26.564 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:35:26.838 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:35:27.247 [update notice] update 700 Date QQ=00: 01.03.2017
2017-03-01 20:35:28.124 [update notice] unknown MS cmd: 0015b52406020000007800 / 06030078000000
2017-03-01 20:35:28.667 [update notice] update 700 Time QQ=00: 20:35:30
2017-03-01 20:35:36.359 [update notice] unknown MS cmd: 0015b52406020003001b00 / 0601031b000000
2017-03-01 20:35:36.545 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:35:36.820 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:35:37.104 [update notice] update 700 z1RoomTemp QQ=00: nan
2017-03-01 20:35:37.189 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;60.0
2017-03-01 20:35:37.690 [update notice] update 700 z1ActualRoomTempDesired QQ=00: 22
2017-03-01 20:35:38.223 [update notice] update 700 z1OpMode QQ=00: day
2017-03-01 20:35:38.768 [update notice] update 700 z1NightTemp QQ=00: 22.5
2017-03-01 20:35:39.353 [update notice] update 700 z1DayTemp QQ=00: 22
2017-03-01 20:35:39.883 [update notice] update 700 z1SFMode QQ=00: auto
2017-03-01 20:35:43.745 [update notice] update 700 z1QuickVetoTemp QQ=00: 22.5
2017-03-01 20:35:45.438 [update notice] update 700 HwcSFMode QQ=00: auto
2017-03-01 20:35:46.145 [update notice] update 700 HwcOpMode QQ=00: auto
2017-03-01 20:35:46.542 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:35:46.653 [update notice] update 700 HwcTempDesired QQ=00: 40
2017-03-01 20:35:46.882 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:35:56.559 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:35:56.834 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:36:01.290 [update notice] unknown MS cmd: 0015b52406020003001c00 / 0501031c0000
2017-03-01 20:36:02.031 [update notice] unknown MS cmd: 0015b52406020003001100 / 050303110001
2017-03-01 20:36:03.518 [update notice] update 700 Date QQ=00: 01.03.2017
2017-03-01 20:36:04.351 [update notice] unknown MS cmd: 0015b52406020000007800 / 06030078000000
2017-03-01 20:36:04.890 [update notice] update 700 Time QQ=00: 20:36:06
2017-03-01 20:36:06.544 [update notice] update bai Status01 QQ=10: 32.5;29.5;5.562;-;-;on
2017-03-01 20:36:06.819 [update notice] update bai DateTime QQ=10: valid;20:36:08;01.03.2017;5.562
2017-03-01 20:36:07.059 [update notice] update broadcast vdatetime QQ=10: 20:36:07;01.03.2017
2017-03-01 20:36:07.334 [update notice] update bai Mode QQ=10: standby
2017-03-01 20:36:07.591 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;60.0
2017-03-01 20:36:07.852 [update notice] unknown MS cmd: 1008b5110100 / 0808021822040f0081
2017-03-01 20:36:08.099 [update notice] unknown MS cmd: 1008b5100305ff01 / 0101
2017-03-01 20:36:08.339 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-03-01 20:36:08.579 [update notice] unknown MS cmd: 1008b5120204ff / 0101
2017-03-01 20:36:08.799 [update notice] update broadcast outsidetemp QQ=10: 5.562
Zitat von: tom37 am 01 März 2017, 20:49:12
1. In der Steuerung der Therme kann man für die Zirkulationspumpe pro Tag nur 3 Zeitfenster eingeben, an der sie jeweils eingeschaltet wird. Ich würde das gerne flexibler handhaben (z.B. jede Stunde soll sie 10 min. laufen). Gibt es eine Möglichkeit, die Zirkulationspumpe über ebusd ein- und auszuschalten?
Dazu 3 Ideen:
1. Du könntest regelmäßig die Timer des aktuellen Tages ändern - also morgens anfangen mit 3 Timern "6:00-6:10, 7:00-7:10, 8:00-8:10" und dann nach 8:10 Uhr die Timer auf die nächsten 3 Stunden ändern.
2. Du schaust einfach mal, was die Steuerung für Nachrichten verschickt, um die Zirkulation ein/auszuschalten. Ich vermute ja, dass hier die Nachrichten zuständig sind, die ich u.a. in [1] gezeigt habe. Du könntest also mal das Log durchsuchen nach "08b5120200", ob diese bei Dir überhaupt und wie oft verschickt werden. Wenn ja, dann könntest Du mal zum Test absetzen (ich hoffe, Du hast schon ein "--enablehex" in den Optionen):
# ebusctl hex 08b512020064
Geht davon die Zirkulation an?
Leider kommen die Nachrichten bei mir im Minutentakt von der multiMATIC - wenn das bei Dir auch so ist, wird es lästig, das jede Minute zurückzustellen...
3. Du hast doch das VR900... wenn Du über die App die einmalige Speicherladung aktivierst (oder in der multiMATIC müsste das auch gehen) - geht dabei die Zirkulation mit an? Wenn ja, dann kann ich Dir heraussuchen, wie Du das über ebusd ein- und nach 10 Minuten wieder ausschalten kannst!
Zur AuroStor kann ich leider nichts sagen - aber hast Du nicht die Installationsanleitungen?
Sonst schicke mal die genaue Bezeichnung, dann versuche ich herauszufinden, ob das Ding einen eBus-Anschluss hat. ;-)
Sven
[1] https://forum.fhem.de/index.php/topic,29737.msg594256.html#msg594256
Hallo zusammen,
ich habe die eBus Platine aus dem Wiki gelötet und an meine Vaillant 620/3 angeschlossen.
Ich bekomme dir Broadcasts rein, d.h. z.B. "ebusctl read outsidetemp" funktioniert ohne Probleme.
Wenn ich jedoch ein Gerät direkt abfragen möchte, mit z.B. "ebusctl read -c ui HcName1" laufe ich immer in einen "ERR: read timeout".
Mir ist noch aufgefallen, dass ich am Poti drehen kann wie ich will, die RAW Daten (aktiviert über ebusctl raw) verändern sich für mich nicht ersichtlich. Wie auch immer der Poti steht, ich bekomme immer lesbare broadcast rein.
Hier noch ein paar Outputs:
ebusctl scan result
08;Vaillant;BAI00;0604;5502
15;Vaillant;UI ;0508;6201
23;Vaillant;SOLSY;0500;6301
25;Vaillant;SOLSY;0500;6301
26;Vaillant;SOLSY;0500;6301
50;Vaillant;SOLSY;0500;6301
ec;Vaillant;SOLSY;0500;6301
ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 67
reconnects: 0
masters: 3
messages: 685
conditional: 12
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
2017-03-03 15:41:49.508 [bus notice] <aa
2017-03-03 15:41:49.549 [bus notice] <aa
2017-03-03 15:41:49.593 [bus notice] <aa
2017-03-03 15:41:49.636 [bus notice] <aa
2017-03-03 15:41:49.678 [bus notice] <aa
2017-03-03 15:41:49.722 [bus notice] <aa
2017-03-03 15:41:49.765 [bus notice] <aa
2017-03-03 15:41:49.809 [bus notice] <aa
2017-03-03 15:41:49.851 [bus notice] <aa
2017-03-03 15:41:49.894 [bus notice] <aa
2017-03-03 15:41:49.937 [bus notice] <aa
2017-03-03 15:41:49.980 [bus notice] <aa
2017-03-03 15:41:50.023 [bus notice] <aa
2017-03-03 15:41:50.066 [bus notice] <aa
2017-03-03 15:41:50.108 [bus notice] <aa
2017-03-03 15:41:50.151 [bus notice] <aa
2017-03-03 15:41:50.195 [bus notice] <aa
2017-03-03 15:41:50.237 [bus notice] <aa
2017-03-03 15:41:50.281 [bus notice] <aa
2017-03-03 15:41:50.324 [bus notice] <aa
2017-03-03 15:41:50.368 [bus notice] <aa
2017-03-03 15:41:50.412 [bus notice] <aa
2017-03-03 15:41:50.417 [bus notice] <10
2017-03-03 15:41:50.424 [bus notice] <08
2017-03-03 15:41:50.428 [bus notice] <b5
2017-03-03 15:41:50.432 [bus notice] <13
2017-03-03 15:41:50.437 [bus notice] <02
2017-03-03 15:41:50.441 [bus notice] <05
2017-03-03 15:41:50.445 [bus notice] <08
2017-03-03 15:41:50.449 [bus notice] <c6
2017-03-03 15:41:50.454 [bus notice] <00
2017-03-03 15:41:50.472 [bus notice] <00
2017-03-03 15:41:50.476 [bus notice] <00
2017-03-03 15:41:50.481 [bus notice] <00
2017-03-03 15:41:50.485 [bus notice] <aa
2017-03-03 15:41:50.528 [bus notice] <aa
2017-03-03 15:41:50.571 [bus notice] <aa
2017-03-03 15:41:50.615 [bus notice] <aa
2017-03-03 15:41:50.658 [bus notice] <aa
2017-03-03 15:41:50.700 [bus notice] <aa
2017-03-03 15:41:50.744 [bus notice] <aa
2017-03-03 15:41:50.785 [bus notice] <aa
2017-03-03 15:41:50.829 [bus notice] <aa
2017-03-03 15:41:50.872 [bus notice] <aa
2017-03-03 15:41:50.916 [bus notice] <aa
2017-03-03 15:41:50.920 [bus notice] <10
2017-03-03 15:41:50.927 [bus notice] <26
2017-03-03 15:41:50.933 [bus notice] <b5
2017-03-03 15:41:50.936 [bus notice] <09
2017-03-03 15:41:50.940 [bus notice] <03
2017-03-03 15:41:50.944 [bus notice] <0d
2017-03-03 15:41:50.948 [bus notice] <04
2017-03-03 15:41:50.953 [bus notice] <00
2017-03-03 15:41:50.957 [bus notice] <8c
2017-03-03 15:41:50.961 [bus notice] <00
2017-03-03 15:41:50.966 [bus notice] <03
2017-03-03 15:41:50.970 [bus notice] <21
2017-03-03 15:41:50.974 [bus notice] <ff
2017-03-03 15:41:50.978 [bus notice] <a9
2017-03-03 15:41:50.983 [bus notice] <01
2017-03-03 15:41:50.987 [bus notice] <e6
2017-03-03 15:41:50.991 [bus notice] <00
2017-03-03 15:41:50.996 [bus notice] <aa
2017-03-03 15:41:51.039 [bus notice] <aa
2017-03-03 15:41:51.085 [bus notice] <aa
2017-03-03 15:41:51.088 [bus notice] <10
2017-03-03 15:41:51.097 [bus notice] <25
2017-03-03 15:41:51.101 [bus notice] <b5
2017-03-03 15:41:51.105 [bus notice] <04
2017-03-03 15:41:51.109 [bus notice] <01
2017-03-03 15:41:51.114 [bus notice] <01
2017-03-03 15:41:51.118 [bus notice] <d2
2017-03-03 15:41:51.122 [bus notice] <00
2017-03-03 15:41:51.127 [bus notice] <09
2017-03-03 15:41:51.131 [bus notice] <37
2017-03-03 15:41:51.135 [bus notice] <03
2017-03-03 15:41:51.139 [bus notice] <00
2017-03-03 15:41:51.144 [bus notice] <00
2017-03-03 15:41:51.148 [bus notice] <02
2017-03-03 15:41:51.151 [bus notice] <83
2017-03-03 15:41:51.156 [bus notice] <00
2017-03-03 15:41:51.160 [bus notice] <01
2017-03-03 15:41:51.164 [bus notice] <00
2017-03-03 15:41:51.168 [bus notice] <18
2017-03-03 15:41:51.173 [bus notice] <00
2017-03-03 15:41:51.180 [bus notice] <aa
2017-03-03 15:41:51.221 [bus notice] <aa
2017-03-03 15:41:51.265 [bus notice] <aa
2017-03-03 15:41:51.269 [bus notice] <10
2017-03-03 15:41:51.278 [bus notice] <ec
2017-03-03 15:41:51.282 [bus notice] <b5
2017-03-03 15:41:51.286 [bus notice] <04
2017-03-03 15:41:51.289 [bus notice] <01
2017-03-03 15:41:51.293 [bus notice] <0d
2017-03-03 15:41:51.298 [bus notice] <c5
2017-03-03 15:41:51.302 [bus notice] <00
2017-03-03 15:41:51.306 [bus notice] <05
2017-03-03 15:41:51.311 [bus notice] <00
2017-03-03 15:41:51.315 [bus notice] <00
2017-03-03 15:41:51.319 [bus notice] <00
2017-03-03 15:41:51.323 [bus notice] <80
2017-03-03 15:41:51.327 [bus notice] <00
2017-03-03 15:41:51.332 [bus notice] <4c
2017-03-03 15:41:51.336 [bus notice] <00
2017-03-03 15:41:51.340 [bus notice] <aa
2017-03-03 15:41:51.383 [bus notice] <aa
2017-03-03 15:41:51.426 [bus notice] <aa
2017-03-03 15:41:51.431 [bus notice] <10
2017-03-03 15:41:51.439 [bus notice] <25
2017-03-03 15:41:51.443 [bus notice] <b5
2017-03-03 15:41:51.448 [bus notice] <04
2017-03-03 15:41:51.452 [bus notice] <01
2017-03-03 15:41:51.456 [bus notice] <0d
2017-03-03 15:41:51.460 [bus notice] <de
2017-03-03 15:41:51.463 [bus notice] <00
2017-03-03 15:41:51.469 [bus notice] <05
2017-03-03 15:41:51.472 [bus notice] <00
2017-03-03 15:41:51.476 [bus notice] <00
2017-03-03 15:41:51.481 [bus notice] <4a
2017-03-03 15:41:51.485 [bus notice] <03
2017-03-03 15:41:51.489 [bus notice] <37
2017-03-03 15:41:51.493 [bus notice] <00
2017-03-03 15:41:51.498 [bus notice] <00
2017-03-03 15:41:51.504 [bus notice] <aa
2017-03-03 15:41:51.545 [bus notice] <aa
2017-03-03 15:41:51.588 [bus notice] <aa
2017-03-03 15:41:51.592 [bus notice] <10
2017-03-03 15:41:51.600 [bus notice] <ec
2017-03-03 15:41:51.605 [bus notice] <b5
2017-03-03 15:41:51.609 [bus notice] <04
2017-03-03 15:41:51.613 [bus notice] <01
2017-03-03 15:41:51.617 [bus notice] <21
2017-03-03 15:41:51.621 [bus notice] <e9
2017-03-03 15:41:51.626 [bus notice] <00
2017-03-03 15:41:51.630 [bus notice] <05
2017-03-03 15:41:51.633 [bus notice] <1a
2017-03-03 15:41:51.639 [bus notice] <00
2017-03-03 15:41:51.642 [bus notice] <00
2017-03-03 15:41:51.646 [bus notice] <3d
2017-03-03 15:41:51.650 [bus notice] <00
2017-03-03 15:41:51.655 [bus notice] <87
2017-03-03 15:41:51.659 [bus notice] <00
2017-03-03 15:41:51.663 [bus notice] <aa
2017-03-03 15:41:51.707 [bus notice] <aa
2017-03-03 15:41:51.750 [bus notice] <aa
2017-03-03 15:41:51.793 [bus notice] <aa
2017-03-03 15:41:51.836 [bus notice] <aa
2017-03-03 15:41:51.879 [bus notice] <aa
2017-03-03 15:41:51.921 [bus notice] <aa
2017-03-03 15:41:51.965 [bus notice] <aa
2017-03-03 15:41:52.008 [bus notice] <aa
2017-03-03 15:41:52.050 [bus notice] <aa
2017-03-03 15:41:52.094 [bus notice] <aa
2017-03-03 15:41:52.137 [bus notice] <aa
2017-03-03 15:41:52.181 [bus notice] <aa
2017-03-03 15:41:52.222 [bus notice] <aa
2017-03-03 15:41:52.266 [bus notice] <aa
2017-03-03 15:41:52.309 [bus notice] <aa
2017-03-03 15:41:52.353 [bus notice] <aa
2017-03-03 15:41:52.395 [bus notice] <aa
2017-03-03 15:41:52.438 [bus notice] <aa
2017-03-03 15:41:52.482 [bus notice] <aa
Problem ist gelöst, hatte einen Optokoppler versehentlich falsch herum eingesetzt
Zitat
Dazu 3 Ideen:
1. Du könntest regelmäßig die Timer des aktuellen Tages ändern - also morgens anfangen mit 3 Timern "6:00-6:10, 7:00-7:10, 8:00-8:10" und dann nach 8:10 Uhr die Timer auf die nächsten 3 Stunden ändern.
2. Du schaust einfach mal, was die Steuerung für Nachrichten verschickt, um die Zirkulation ein/auszuschalten. Ich vermute ja, dass hier die Nachrichten zuständig sind, die ich u.a. in [1] gezeigt habe. Du könntest also mal das Log durchsuchen nach "08b5120200", ob diese bei Dir überhaupt und wie oft verschickt werden. Wenn ja, dann könntest Du mal zum Test absetzen (ich hoffe, Du hast schon ein "--enablehex" in den Optionen):
# ebusctl hex 08b512020064
Geht davon die Zirkulation an?
Leider kommen die Nachrichten bei mir im Minutentakt von der multiMATIC - wenn das bei Dir auch so ist, wird es lästig, das jede Minute zurückzustellen...
3. Du hast doch das VR900... wenn Du über die App die einmalige Speicherladung aktivierst (oder in der multiMATIC müsste das auch gehen) - geht dabei die Zirkulation mit an? Wenn ja, dann kann ich Dir heraussuchen, wie Du das über ebusd ein- und nach 10 Minuten wieder ausschalten kannst!
Zur AuroStor kann ich leider nichts sagen - aber hast Du nicht die Installationsanleitungen?
Sonst schicke mal die genaue Bezeichnung, dann versuche ich herauszufinden, ob das Ding einen eBus-Anschluss hat. ;-)
Sven
Die Idee, einfach die Uhrzeiten zu überschreiben, ist genial, vielen Dank.
Die Wärmepumpe ist die AroStor: https://www.vaillant.de/heizung/produkte/warmwasserwarmepumpe-arostor-6400.de_de.html
Auf der Seite steht auch weiter unten unter Technische Daten: "eBus System-Schnittstelle vorhanden"
Ich habe die Fachhandwerker und die Betreiber Anleitungen zu der WP vorliegen, da ist nirgends etwas von eBus beschrieben. Ggf. hat sie tatsächlich keine eBus Schnittstelle und die Angabe auf der Webseite ist schlichtweg falsch ...
Aktuell habe ich leider wieder das Problem, dass ich die Fehlermeldungen bekomme, die ich ganz zu Anfang hatte:
2017-02-28 22:59:52.033 [bus notice] max. symbols per second: 2057
2017-02-28 23:00:01.201 [main notice] starting initial scan for fe
2017-02-28 23:00:06.366 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:09.238 [update notice] unknown MS cmd: 1008b512020000 / 00
2017-02-28 23:00:09.269 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:14.916 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:22.032 [bus error] send to fe: ERR: arbitration lost
2017-02-28 23:00:22.032 [main error] initial scan failed: ERR: arbitration lost
Es lag wohl doch nicht an der Einstellung in der Konfig des eBus Ethernet Adapters. Ich habe aber eigentlich nichts geändert. Ich werde wohl noch etwas forschen müssen ..
Viele Grüße,
Tom
Hallo zusammen,
mein ebusd Ethernet Koppler läuft nun seit 2 Tagen stabil mit ebusd zusammen und ich bin wirklich begeistert!
Aktuell habe ich eine kleine Herausforderung mit den Daten: Ich habe eine Vaillant ecoTEC exclusive VC 216/5-7 und ich würde gerne für den Heizkreis 1 (wir haben nur einen) die Vorlauf-Solltemperatur (die aus der Heizkurve, der Außentemperatur und der Zieltemperatur berechnet wird) sowie die Vorlauf-Ist Temperatur auslesen.
ebusctl r Hc1ActualFlowTempDesired liefert mir hierbei einen Wert (aktuell 32.1198), während ebusctl r Hc1FlowTemp nur ein "nan" liefert. Liegt das ggf. daran, dass die Therme sehr neu ist und die CSV Dateien hierfür noch nicht passen?
Hier das Ergebnis von ebusctl info:
version: ebusd 3.0pre.p20170228
signal: acquired
symbol rate: 23
reconnects: 0
masters: 4
messages: 555
conditional: 3
poll: 0
update: 8
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=0607;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0502;HW=9102", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Hat jemand ggf. noch einen Tipp für mich ?
@Sven77: Das Steuern der Zirkulationspumpe nehme ich als Nächstes in Angriff ...
Viele Grüsse,
Tom
Hallo Tom,
die Vorlauftemperatur und die Vorlaufsolltemperatur erhalte ich über die Parameter "FlowTemp" und "FlowTempDesired". Ich benutze allerdings noch die Version 2.0 vom ebusd. Anscheinend hat sich dann was an den Config-Files geändert.
freundliche Grüße
Henry22
Zitat
Hallo Tom,
die Vorlauftemperatur und die Vorlaufsolltemperatur erhalte ich über die Parameter "FlowTemp" und "FlowTempDesired". Ich benutze allerdings noch die Version 2.0 vom ebusd. Anscheinend hat sich dann was an den Config-Files geändert.
freundliche Grüße
Henry22
Hallo Henry22,
super, das funktioniert und beide Werte kommen an!
An der Stelle vielleicht mal eine Frage zur Therme: Aktuell wird eine Soll-Vorlauftemperatur von 32 Grad ermittelt, die Ist-Vorlauftemperatur ist 36 Grad, aber die Therme heizt trotzdem, zwar mit niedriger Leistung (sieht man ja an dem Balken im Display link in der Anzeige), aber dennoch quasi durchgehend. Ist das normal?
Vielen Dank und viele Grüsse,
Tom
Hallo Tom,
ich "beobachte" meine Heizung seit geraumer Zeit und habe auch solche Effekte und zwar immer dann, wenn die Aussentemperatur über 5 Grad steigt. Der Hauptgrund ist wohl das der Brenner mit 19kW überdimensioniert ist und ab dieser Aussentemperatur das "Takten" anfängt, sprich sehr häufig anspringt, dann schnell auf den Vorlauftemperaturwert kommt und dann wieder ausschaltet. Dieser Betriebsmodus führt dann auch zum "Überschwingen" der Vorlauftemperatur (siehe meine Grafik im Anhang)
Man kan das Takten etwas minimieren indem man die Brennersperrzeit etwas erhöht.
freundliche Grüße
Henry22
Zitat von: tom37 am 05 März 2017, 21:20:39
ebusctl r Hc1ActualFlowTempDesired liefert mir hierbei einen Wert (aktuell 32.1198), während ebusctl r Hc1FlowTemp nur ein "nan" liefert. Liegt das ggf. daran, dass die Therme sehr neu ist und die CSV Dateien hierfür noch nicht passen?
Okay..... ganz langsam.
Also so weit ich weiß, wurde an den CSVs (noch) nichts geändert, 3.0 sollte genau genommen die 2.1.x haben.
Es könnte allerdings an einem anderen Hydraulikschema liegen - die Bezeichnungen in der 15.700.csv sind alle aus Beobachtungen entstanden und richten sich demnach nur nach meinem Hydraulikschema, oder dem was mir andere User berichtet haben. Genauere Analysen gern per Mail - schickt mir eine PM mit Eurer Mailadresse und ich melde mich!
Fangen wir aber mal vorn an: zeigt denn die multiMATIC (in der Fachhandwerkerebene) die Vorlauftemperatur des Heizkreises? Ist es ein gemischter oder ungemischter Kreis?
Generell bitte nichts verwechseln: der Heizkreis1 hat eine Vorlauf-Ist- und -Soll-Temperatur. Diese wird (im Falle der VRC700 um einen kaum vorhersehbaren, sich stets ändernden) Offset an den Brenner geschickt. Das ist vermutlich das, was Du mit "FlowTemp" und "FlowTempDesired" ausliest.
Warum die Ist- dort höher als die Soll-Temperatur ist, liegt auf der Hand: der Brenner arbeitet mit einer Ein-/Ausschalthysterese.
Also bitte nochmal ganz genau prüfen, welche Soll- mit welcher Ist-Temperatur verglichen wird und wie die Hysterese des Brenners eingestellt ist!
Ach ja, nur so als Warnung: wer eine VRC700 vor Version VRC700/4 hat, sollte mit dem Erhöhen der Sperrzeit sparsam umgehen, ich rate sogar eher zum Verkürzen der Sperrzeit und eher der Spreizung der Hysterese auf ein Maximum. Bei Interesse führe ich das gern genauer aus...
VG, Sven
Hallo Henry, Hallo Tom,
das Takten sollte so gut es geht vermieden werden und ein "Durchlaufen" anforciert werden.
Mit einer Therme ist es ähnlich einem Motor, wenn man ihn auf niedrigem Niveau und gleichbleibender Geschwindigkeit fährt so hat man einen optimaleren Wirkungsgrad, weniger Verschleiß und weniger Verbrauch.
Entweder ist der Modulationsbereich zu gering (oder keiner Vorhanden?) oder die meisten Heizkörper des Hauses/ Wohnung sind zugedreht und somit kann natürlich die Wärme nicht an die Räume abgegeben werden.
Meine Vaillant ecotec hat 4-20kW, wenn ich nur in Wohnstube den Heizkörper aufdrehe dann haben natürlich auch die 4kW keine "Chance" ohne Takten aus zu kommen.
Hallo,
ich befürchte, ich habe hier eine Diskussion angestossen, die nicht wirklich zum Thema des Threads gehört (Takten, Modulationsbereich, etc.) ...
Dennoch vielen Dank für die Tipps! Es scheint, dass meine Therme so eingestellt ist, dass sie mit geringer Leistung durchläuft, was offensichtlich so gewollt ist. Ich frage mich lediglich in dem Zusammenhang, was die Einstellung "Minimaltemperatur" in der VRC700 genau bezweckt (steht aktuell bei 30 Grad)!?
Vielen Dank und viele Grüße,
Tom
Zitat von: tom37 am 06 März 2017, 20:38:57Ich frage mich lediglich in dem Zusammenhang, was die Einstellung "Minimaltemperatur" in der VRC700 genau bezweckt (steht aktuell bei 30 Grad)!?
Auch hier wieder: bitte nicht Äpfel mit Birnen vergleichen... ;)
Soweit ich das sehe, gibt es in der VRC700 nur eine "minimale Vorlauftemperatur" für einen Heizkreis, ebenso die maximale.
Letztere kann ich leicht erklären: was auch immer die eingestellte Heizkurve mit der Außentemperatur verlangt - beim Maximum wird gedeckelt.
Fürs Minimum könnte es ähnlich sein und einfach nur die Vorlauftemperatur minimal auf diesem Wert halten. Könnte aber auch bedeuten: wenn weniger verlangt, wird Heizkreis abgeschaltet - müsste man ausprobieren...
Wer hat die denn auf 30 Grad gestellt? Standard sollte 15 sein!
Zitat von: Sven77 am 06 März 2017, 07:42:54
Ach ja, nur so als Warnung: wer eine VRC700 vor Version VRC700/4 hat, sollte mit dem Erhöhen der Sperrzeit sparsam umgehen, ich rate sogar eher zum Verkürzen der Sperrzeit und eher der Spreizung der Hysterese auf ein Maximum. Bei Interesse führe ich das gern genauer aus...
VG, Sven
Sven,
hat die 700 einen Eintrag für die Brennersperrzeit des Heizkreises? Ich habe das nur in der bai mit d.02.
Gruß,
Dietmar
Nein, hat nur der Brenner. (soweit ich weiß)
Problem bei mir ist:
Wenn der Brenner nicht so oft taktet, wie's die VRC gern hätte, ändert letztere ihre Wärmeanforderung an den Brenner. Also wenn's ihr "zu warm" wird, weil der Brenner zu lange läuft, schraubt sie die Wärmeanforderung nach unten. Bis sie sie schließlich auf 0 setzt (in meinem Fall sobald der Pufferspeicher 10K über der eigentlichen Anforderung des Heizkreises ist). Dann irgendwann (wenn der allSTOR unter die Anforderung des Heizkreises abgekühlt ist), setzt sie dem Brenner wieder eine Anforderung. Wenn dieser dann nicht angeht, weil entweder FlowHysteresisOn zu klein ist oder er in der Sperrzeit ist, wird die Anforderung schrittweise erhöht.
Und hier kommt der Haken: wenn die geforderte Wärmeanforderung während der Sperrzeit geändert wird, setzt der Brenner diese wieder hoch auf Maximum!
Das ist in angehängter Grafik ganz gut zu sehen, auch wenn hier die Puffertemperatur ausgeblendet ist. Auf diese Weise kommt es schonmal dazu, dass aus einer maximalen Sperrzeit von 20 Minuten effektiv 50 werden (nicht in Abbildung) und auf der anderen Seite, dass der Brenner seine Sperrzeit ignoriert und trotzdem angeht.
Zu allem Überfluss ist der Offset, den die VRC auf die eigentlich benötigte Vorlauftemperatur aufschlägt über einen mir unbekannten Zeitraum geglättet. Durch dieses beschriebene Spiel zwischen den beiden kommt es also irgendwann dazu, dass die VRC den gewünschten Brennervorlauf brutal erhöht (z.Bsp. 25K), nur um dann den Brenner mittendrin abzuwürgen, weil der Puffer 10K über dem Soll liegt (kein Wunder, denn die Anforderung war ja nochmal 15K höher).
Ob das mit allen Brennern zu beobachten ist, kann ich nicht sagen. Ebenso könnte es sein, dass das nur in Verbindung mit einem allSTOR überhaupt auftritt. Jedenfalls soll es mit dem VRC700/4 behoben sein. Bis dahin steht meine Sperrzeit auf 6 Minuten, womit ich sehr gut fahre. Die effektive Sperrzeit wird dann allein durch die Hysterese bestimmt und wenn das Vorlaufsoll nach Ablauf der Sperrzeit durch den Regler geändert wird, hat das keine negativen Auswirkungen mehr.
Sven
Hallo,
ich lasse den ebusd mit mqtt laufen, jetzt sendet ebusd die Nachrichten an das Topic mit folgendem Format:
ebusd/ehp/SourceTempInput 17.31;ok
Kann man den ebusd so einstellen, das er an das Topic die Daten ohne das ok sendet?
ebusd/ehp/SourceTempInput 17.31
Gruß
lewej
Du musst herausfinden, wie das erste Feld heisst - dann kannst Du gezielt nur dieses abfragen. Am Beispiel von "WaterPressure":
$ ebusctl r -c bai WaterPressure
2.461;ok
$ grep WaterPressure /etc/ebusd/vaillant/08.bai.csv
r,,WaterPressure,Wasserdruck,,,,"0200",,,presssensor,,,Wasserdruck
$ grep presssensor /etc/ebusd/vaillant/_templates.csv
presssensor,press;sensor,,,
$ ebusctl r -c bai WaterPressure sensor
ok
$ ebusctl r -c bai WaterPressure press
2.461
Zitat von: lewej am 10 März 2017, 09:39:59
ich lasse den ebusd mit mqtt laufen, jetzt sendet ebusd die Nachrichten an das Topic mit folgendem Format:
ebusd/ehp/SourceTempInput 17.31;ok
Kann man den ebusd so einstellen, das er an das Topic die Daten ohne das ok sendet?
ebusd/ehp/SourceTempInput 17.31
ja mit:
--mqtttopic=ebusd/%circuit/%name/%fieldDamit wird das Topic dann pro Feld gesendet, also z.B.
ebusd/ehp/SourceTempInput/temp und
ebusd/ehp/SourceTempInput/sensorAllerdings ist dann ein Schreiben auf ein Topic mit Suffix /set derzeit nicht mehr möglich und expliziter Refresh mit /get muss dann auch das Feld beinhalten.
Zitat von: john30 am 11 März 2017, 10:07:34
ja mit: --mqtttopic=ebusd/%circuit/%name/%field
Damit wird das Topic dann pro Feld gesendet, also z.B. ebusd/ehp/SourceTempInput/temp und ebusd/ehp/SourceTempInput/sensor
Allerdings ist dann ein Schreiben auf ein Topic mit Suffix /set derzeit nicht mehr möglich und expliziter Refresh mit /get muss dann auch das Feld beinhalten.
Hi,
@john: Danke, teste ich mal.
Ich will später doch mal was ins Topic schreiben. Deshalb die Frage, ob man mit Fhem Mitteln, die Readings nicht manipulieren könnte um z.B. das ok weg zu schneiden?
Grüsse
lewej
Zitat von: lewej am 11 März 2017, 18:56:06
Ich will später doch mal was ins Topic schreiben. Deshalb die Frage, ob man mit Fhem Mitteln, die Readings nicht manipulieren könnte um z.B. das ok weg zu schneiden?
Das geht natürlich auch. Dazu via userReadings den entsprechenden Teil abtrennen, z.B. so:
attr DEVICENAME userReadings NEWNAME { my @parts = split(/;/, ReadingsVal($name, READINGNAME, "")); return $parts[0]; }Dabei DEVICENAME und READINGNAME durch die existierenden Namen ersetzen und NEWNAME durch den gewünschten neuen "Teilnamen".
Hallo Zusammen,
ich habe ein Problem mit dem ebusd und meiner auromatic 560. Wenn ich den ebusd starte dann funktionieren erstmal keine Readings, da die auromatic kein broadcast auf den BUS sendet, man muss expliziet die Readings triggern.
Dienst starte ich mit:
-c /etc/ebusd2x --pollinterval=5 --scanconfig -d /dev/ebusvaillantsolar -p 8889 -l /var/log/ebusdvaillantsolar.log --mqttport=1883 --mqtthost=ebus --mqtttopic=ebusdsolar"
ebusctl -p 8889 find -v
broadcast datetime = no data stored
broadcast error = no data stored
broadcast id = no data stored
broadcast signoflife = no data stored
broadcast id = no data stored
memory eeprom = no data stored
memory ram = no data stored
Ich muss zuerst ein
scan full
ausführen.
root@smarthome:/etc/ebusd/solar# ebusctl -p 8889 find -v
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = no data stored
broadcast id = no data stored
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.15 = MF=Vaillant;ID=SDR_P;SW=0312;HW=6801
scan.15 id = prefix=??;year=??;week=??;product=??????????;supplier=????;counter=??????;suffix=??
scan.23 = MF=Vaillant;ID=SDR_P;SW=0312;HW=6801
sdr_p ActualTempDesired = no data stored
sdr_p BypassValve = no data stored
sdr_p C1C2 = no data stored
sdr_p CirPump = no data stored
sdr_p Coll1Sensor = no data stored
sdr_p Coll2Sensor = no data stored
sdr_p CollPump1 = no data stored
sdr_p CollPump1ActualPower = no data stored
sdr_p CollPump2 = no data stored
sdr_p CollPumpHRuntime = no data stored
sdr_p Date = no data stored
sdr_p DisableAutoSync = no data stored
sdr_p ElectronicCartridge = no data stored
sdr_p HwcLoadingDelay = no data stored
sdr_p HydraulicScheme = no data stored
sdr_p IsInHoliday = no data stored
sdr_p IsInParty = no data stored
sdr_p IsInSingleHwcLoading = no data stored
sdr_p LegioProtectionEnabled = no data stored
sdr_p LegioPump = no data stored
sdr_p NumCollPanels = no data stored
sdr_p OperatingMode = no data stored
sdr_p ResetOperatingTimes = no data stored
sdr_p ResetYield = no data stored
sdr_p SolDisableDiffTemp = no data stored
sdr_p SolEDEnable = no data stored
sdr_p SolEnableDiffTemp = no data stored
sdr_p SolEnableDiffTempMax = no data stored
sdr_p SolEnableDiffTempMin = no data stored
sdr_p SolFlowRate = no data stored
sdr_p SolHwcMaxLoadTemp = no data stored
sdr_p SolPumpBlockingTime = no data stored
sdr_p SolPumpPower = no data stored
sdr_p StartTimeFillingMode = no data stored
sdr_p StartTimeOperatingMode = no data stored
sdr_p Storage1Sensor = no data stored
sdr_p Storage2Sensor = no data stored
sdr_p Storage3Sensor = no data stored
sdr_p ThreeWayValve1 = no data stored
sdr_p Time = no data stored
sdr_p Weekday = no data stored
sdr_p Yield = no data stored
sdr_p YieldSensor = no data stored
Danach sind zwar die Readings da, aber die werden nicht gefühlt. Ich muss die Readings selber triggern.
ebusctl -p 8889 r Storage1Sensor
58.88;ok
Hat jemand eine Idee, warum die Reading nicht automatisch abgefragt werden, pollingintervall ist ja auch gesetzt.
Gruß
lewej
Zitat von: lewej am 12 März 2017, 11:57:05
ich habe ein Problem mit dem ebusd und meiner auromatic 560. Wenn ich den ebusd starte dann funktionieren erstmal keine Readings, da die auromatic kein broadcast auf den BUS sendet, man muss expliziet die Readings triggern.
Du kannst auch --scanconfig=full an ebusd übergeben, dann macht er initial einen full scan.
Zitat von: lewej am 12 März 2017, 11:57:05
Danach sind zwar die Readings da, aber die werden nicht gefühlt. Ich muss die Readings selber triggern.
Die Werte werden mit der jetzigen Definition (CSV) nicht zyklisch gepollt.
Du kannst entweder alle type Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1" ersetzen, womit dann die poll priority auf 1 gesetzt wird und somit die Werte auch zyklisch abgefragt werden.
Oder Du nimmst das "read" Kommando und setzt dadurch die poll priority temporär um.
Zitat von: john30 am 13 März 2017, 07:53:40
Du kannst auch --scanconfig=full an ebusd übergeben, dann macht er initial einen full scan.
Die Werte werden mit der jetzigen Definition (CSV) nicht zyklisch gepollt.
Du kannst entweder alle type Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1" ersetzen, womit dann die poll priority auf 1 gesetzt wird und somit die Werte auch zyklisch abgefragt werden.
Oder Du nimmst das "read" Kommando und setzt dadurch die poll priority temporär um.
Hi,
funktioniert
--scanconfig=fullfunktioniert ebenfalls
Spalten mit "r" in den entsprechenden CSVs durch bspw. "r1"
Danke und Gruß
lewej
Hi,
ich bekomme die Meldung, das er die prefixe 23 und 25 nicht finden kann. Für die 630 sind diese bereits vorhanden. Kann man die für die auromatic 560 auch erstellen?
2017-03-13 09:54:40.873 [main notice] SIGTERM received
2017-03-13 09:54:41.766 [main notice] ebusd stopped
2017-03-13 09:54:51.520 [main notice] ebusd 3.0pre.daeea20 started
2017-03-13 09:54:51.569 [mqtt notice] connection established
2017-03-13 09:54:51.576 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-03-13 09:54:52.006 [bus notice] signal acquired
2017-03-13 09:55:01.569 [main notice] starting initial full scan
2017-03-13 09:55:08.952 [bus notice] new master 10, master count 2
2017-03-13 09:55:08.952 [bus notice] scan 15: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:11.591 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/broadcast.csv
2017-03-13 09:55:11.592 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/general.csv
2017-03-13 09:55:11.594 [main notice] read common config file /etc/ebusd-2.1.x/vaillant/scan.csv
2017-03-13 09:55:11.615 [main notice] read scan config file /etc/ebusd-2.1.x/vaillant/15.sdr_p.csv for ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:11.615 [main notice] found messages: 104 (0 conditional on 0 conditions, 2 poll, 8 update)
2017-03-13 09:55:14.726 [bus notice] scan 15: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:16.002 [bus notice] scan 23: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:16.722 [bus notice] scan 25: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:55:19.711 [bus notice] scan 23: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:19.714 [main error] unable to load scan config 23: no file from /etc/ebusd-2.1.x/vaillant with prefix 23. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:19.714 [main error] scan config 23: ERR: element not found
2017-03-13 09:55:24.925 [bus notice] scan 25: ;??;??;??;??????????;????;??????;??
2017-03-13 09:55:24.927 [main error] unable to load scan config 25: no file from /etc/ebusd-2.1.x/vaillant with prefix 25. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:55:24.928 [main error] scan config 25: ERR: element not found
2017-03-13 09:57:02.308 [bus notice] scan ec: ;Vaillant;SDR_P;0312;6801
2017-03-13 09:57:10.336 [bus notice] scan ec: ;??;??;??;??????????;????;??????;??
2017-03-13 09:57:10.338 [main error] unable to load scan config ec: no file from /etc/ebusd-2.1.x/vaillant with prefix ec. matches ID "sdr_p", SW0312, HW6801
2017-03-13 09:57:10.339 [main error] scan config ec: ERR: element not found
Gruß
lewej
Hallo zusammen,
ich wollte kurz eine Rückmeldung zu einem Problem geben. Ich hatte u.a. in Beitrag #2112 das Problem mit diversen Fehlermeldungen geschildert (unten nochmal eingefügt). Nach zahlreichen Tests habe ich die Ursache nun mit 99% Wahrscheinlichkeit gefunden: Es lag am Netzteil des Raspberry PI, auf dem ebusd bei mir läuft. Mir ist aufgefallen, dass ich hin und wieder "broken pipe" Fehlermeldungen in meiner ssh Session erhalten hatte, mit der ich vom PC auf den Raspberry PI zugreife. D.h. dass die Netzwerkverbindung abgebrochen war und das hat wahrscheinlich auch dazu geführt, dass die Verbindung des Raspberry PI zum eService ebus Ethernet Doppler gestört war. Das Netzteil war wohl zu schwach. Ich habe mir die Tage einen neuen Raspberry PI gekauft und das dazugehörige, neue Netzteil an den Raspberry PI angeschlossen, auf dem ebusd läuft und seitdem habe ich keinerlei Probleme mehr. Vielleicht hilft das dem einen oder anderen, der ähnliche Probleme hat ...
Viele Grüße
Tom
2017-02-28 23:00:01.201 [main notice] starting initial scan for fe
2017-02-28 23:00:06.366 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:09.269 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:14.916 [bus error] send to fe: ERR: arbitration lost, retry
2017-02-28 23:00:22.032 [bus error] send to fe: ERR: arbitration lost
2017-02-28 23:00:22.032 [main error] initial scan failed: ERR: arbitration lost
2017-02-28 23:00:30.563 [bus error] send to 08: ERR: arbitration lost, retry
2017-02-28 23:00:33.287 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:37.574 [bus error] send to 08: ERR: wrong symbol received, retry
2017-02-28 23:00:38.278 [bus error] send to 08: ERR: wrong symbol received
2017-02-28 23:00:38.278 [main error] scan config 08 message: ERR: wrong symbol received
2017-02-28 23:00:47.779 [bus error] send to 15: ERR: arbitration lost, retry
2017-02-28 23:01:00.712 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:10.923 [bus error] send to 15: ERR: wrong symbol received, retry
2017-02-28 23:01:11.683 [bus error] send to 15: ERR: wrong symbol received
2017-02-28 23:01:11.684 [main error] scan config 15 message: ERR: wrong symbol received
Zitat von: lewej am 13 März 2017, 10:05:21
ich bekomme die Meldung, das er die prefixe 23 und 25 nicht finden kann. Für die 630 sind diese bereits vorhanden. Kann man die für die auromatic 560 auch erstellen?
kann man, aber ich hab keine Defintionen dafür und ich denke, dass da nichts anderes zu finden sein wird als für die Hauptadresse.
Hallo zusammen,
Ich versuch gerade eine (ur)alte Wolf R16 Steuerung mit Ebus auszulesen.
Die ersten Werte, Temperaturen etc. hab ich schon, aber bei den Zeitprogrammen bin ich jetzt an
einem Punkt wo ich nicht mehr weiterkomme.
Im gegensatz zu neueren Heizungen die für jeden Tag mehrere Ein und Ausschaltpunkte besitzen
sind an der R16 für jedes Zeitprogramm 14 Schaltblöcke vorhanden.
Für jeden Schaltblock kann folgendes eingestellt werden.
- Die Tage, also Mo;Di;Mi;Do;Fr;Sa;So;Mo-Do;Mo-Fr;Mo-So;Sa-So
- Die Uhrzeit (in Viertelstundenschritten)
- Ein bzw Aus
Für die Blöcke werden zwei Byte verwendet
1 Byte, die Tage
2 Byte die Schaltzeiten
Allerdings wird das zweite Byte sowohl für die Einschalt, als auch für die Ausschaltzeiten verwendet
(Z.B: A2 schaltet um 08:00 Ein / 22 schaltet um 08:00 aus)
Wenn ich hier den Datentyp TTQ verwende werden auch alle Ausschaltzeiten korrekt angezeigt,
allerdings erhalte ich bei allen Einschaltzeiten eine Fehlermeldung ERR: argument value out of valid range in decode
Hier würde ich vermutlich eine angepasste TTQ benötigen.
In einem anderen Thread hab ich zwar den Aufbau der TTQ gefunden,
add(new DateTimeDataType("TTQ", 8, 0, 0, false, true, 15)); // truncated time (only multiple of 15 minutes), 00:00 - 24:00 (minutes div 15 + hour * 4 as integer)
aber da ich kein Programmierer bin weiss ich nicht wie ich das abändern könnte.
Kann mir hier jemand evtl. jemand diesbezüglich einen Tipp geben?
Gruss und Dank
Hans
Hallo,
mittlerweile funktioniert mein ebusd Interface stabil und ich kann zahlreiche Werte auslesen. Aber einen Wert finde ich in den cvs-Dateien nicht: Ob der Brenner an oder aus ist!
Ich habe eine Vaillant Therme mit MultiMatic 700, hier die Ausgabe von ebusctl info:
version: ebusd 3.0pre.p20170228
signal: acquired
symbol rate: 20
reconnects: 0
masters: 4
messages: 555
conditional: 3
poll: 0
update: 8
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=0607;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0502;HW=9102", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Kennt jemand den Parameter, mit dem man den Brennerstatus auslesen kann?
Vielen Dank und viele Grüsse,
Tom
Hallo Tom,
als Indikator für den Brennerstatus nehme ich das "SDGasvalve" als indirekte Anzeige das der Brenner läuft. Denn das Gasventil geht bzw bleibt nur offen wenn auch der Brenner läuft und wenn das Gasventil zu ist läuft auch der Brenner nicht.
freundliche Grüße
Henry22
Hallo,
im EBUSD 1.1. habe ich dafür "sdflame"
Grüße
Christian
Hallo henry22 und cs-online,
Zitat
Aber einen Wert finde ich in den cvs-Dateien nicht: Ob der Brenner an oder aus ist!
"Flame" und "GasValve" funktionieren bei mir, vielen Dank für die Tipps!
Viele Grüsse,
Tom
Zitat von: hansg am 18 März 2017, 14:00:24
Allerdings wird das zweite Byte sowohl für die Einschalt, als auch für die Ausschaltzeiten verwendet
(Z.B: A2 schaltet um 08:00 Ein / 22 schaltet um 08:00 aus)
Wenn ich hier den Datentyp TTQ verwende werden auch alle Ausschaltzeiten korrekt angezeigt,
allerdings erhalte ich bei allen Einschaltzeiten eine Fehlermeldung ERR: argument value out of valid range in decode
Kannst Du verifizieren, dass die Einschaltzeiten immer das Bit 7 gesetzt haben, sprich da immer ein Byte >= 0x80 rauskommt?
Und 0x22 wäre bei Verwendung von TTQ eigentlich 8:30. Schau doch mal nach, wie ein paar andere Werte kodiert sind, also z.B. 12:00 und 12:30, sowie 00:00.
VG John
Hallo John
Es ist tatsächlich so dass bei den Einschaltzeiten immer das 7 Bit gesetzt ist.
Das 0x22 war falsch, das ist natürlich 8:30.
Anbei noch ein paar Messwerte
00:00 Aus = 0x00 Ein = 0x80
06:00 Aus = 0x18 Ein = 0x98
12:00 Aus = 0x30 Ein = 0xB0
12:30 Aus = 0x32 Ein = 0xB2
18:00 Aus = 0x48 Ein = 0xC8
18:15 Aus = 0x49 Ein = 0xC9
Beste Grüße,
Hans
Hallo Zusammen,
Ich bin seit paar Tagen auf der neuesten 3er ebusd Version mit mqtt. Seit dem geht meine Heizung mit den verschiedensten Fehler in Störung.
Heizung: geotherm vwl61/3s
Stb- Fehler...
Aussenwinheit nicht erreichbar
Aussentemperatur zu niedrig
Soledruck zu gering
...
Gestern habe ich das eservice Teil vom USB getrennt und die WP ist ganze Nacht durchgelaufen, ohne in Störung zu gehen. Die Verbindung selber ist meiner Meinung ok, ich kann alle Werte auslesen und auch setzen.
Hat jemand ähnliche Probleme schon mal gehabt?
Gruss
Lewej
Hallo in die Runde,
ich kann mittlerweile meine Ochsner Wärmepumpe mit dem OTE3 / OTE4 Regler auslesen und auch schon Test-Werte schreiben.
Leider weiß ich nicht wie die Betriebswahl Heizkreis von Automatik auf Standby (und zurück) umschalten kann.
Das gleiche möchte ich bei der Betriebswahl Warmwasserkreis machen.
Mir fehlen auch die passenden Lesewerte dazu.
Wer kann mir einen TIPP geben, wie ich auf die Lösung komme.
Danke
Manfred
Hallo Zusammen,
ich habe bei meiner geotherm vwl61/3, ein paar Positionen die momentan nicht erkannt werden, hat jemand auch diese Fehler, bzw. weiss jemand wie ich die CSVs erweitern könnte, damit diese Meldung auch erkannt werden.
2017-03-21 22:05:13.659 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position 2017-03-21 22:05:22.509 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position 2017-03-21 22:05:32.572 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position 2017-03-21 22:05:42.643 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position 2017-03-21 22:05:52.700 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position 2017-03-21 22:06:02.775 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
Das sind alle die momentan nicht erkannt werden:
sort|uniq from file:
1008b51009000100000000000002
1008b51009000240000000000002
1008b51009000242000000000002
1008b51009000246000000000002
1008b51009000300000000000002
1008b5100900030000a000000002
gruss
lewej
Zitat von: lewej am 20 März 2017, 07:18:47
Ich bin seit paar Tagen auf der neuesten 3er ebusd Version mit mqtt. Seit dem geht meine Heizung mit den verschiedensten Fehler in Störung.
schick mir doch mal ein bisschen von deinem ebusd log file, vielleicht lässt sich da was erkennen.
Grundsätzlich ist das Auslesen via eBUS natürlich eine gewisse Störung, es sei denn mal liest nur mit. Des weiteren verändert auch der bloße Anschluss an den Bus physisch die Eigenschaften durch Verdrahtung, Impedanz, Lasten etc.
Wie verhält es sich denn mit der Vorgängerversion von ebusd?
Zitat von: lewej am 23 März 2017, 20:37:12
ich habe bei meiner geotherm vwl61/3, ein paar Positionen die momentan nicht erkannt werden, hat jemand auch diese Fehler, bzw. weiss jemand wie ich die CSVs erweitern könnte, damit diese Meldung auch erkannt werden.
das scheint die antwort vom slave (ehp) nicht dem zu entsprechen, was erwartet wird. versuch mal, das letzte feld (currentmode) aus ModeDesired in hcmode.inc wegzunehmen. dann müsste es für deine ehp klappen.
Hallo Forum,
ich bekomme es leider nicht hin die korrekten Vor und Rücklauf Temperaturen auszulesen:
ebusctl info
version: ebusd 3.0pre.daeea20
update check: version 3.0pre available
signal: acquired
symbol rate: 41
max symbol rate: 163
reconnects: 0
masters: 3
messages: 740
conditional: 9
poll: 5
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
# grep -R SumFlowSensor /etc/ebusd/*
/etc/ebusd/vaillant/26.solsy.hc.csv:r,,SumFlowSensor,VF1,,,,"0400",,,tempsensor,,,Temperature measured on VF1
/etc/ebusd/vaillant/26.vr630.hc.csv:r,,SumFlowSensor,Vorlauftemp. IST,,,,"0400",,,tempsensor,,,
# ebusctl read SumFlowSensor
-13.94;cutoff
Auszug Log:
2017-03-26 20:57:43.123 [bus notice] poll mc Status0a: 25.94;close;on;off;23
2017-03-26 20:57:44.104 [update notice] unknown MS cmd: 10ecb5040121 / 050900044300
2017-03-26 20:57:47.208 [update notice] update bai Mode QQ=10: standby
2017-03-26 20:57:48.189 [update notice] unknown MS cmd: 1008b513020508 / 00
2017-03-26 20:57:48.681 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
2017-03-26 20:57:48.865 [update notice] update mc Mode QQ=10: 19;auto;0;0;low;mixer;night
2017-03-26 20:57:49.029 [update notice] unknown MS cmd: 10ecb504010d / 050000008000
2017-03-26 20:57:49.132 [bus notice] poll mc Mode: 19;auto;0;0;low;mixer;night
2017-03-26 20:57:49.254 [update notice] update hwc Status QQ=10: 0;off;61.75;55
2017-03-26 20:57:49.411 [update notice] update mc RoomTempOffset QQ=10: 0.00
2017-03-26 20:57:50.286 [update notice] update bai Status01 QQ=10: 53.0;54.0;-;-;-;off
2017-03-26 20:57:50.443 [update notice] unknown MS cmd: 1050b5050427005a00 / 00
2017-03-26 20:57:50.739 [update notice] unknown MS cmd: 1025b5040117 / 0101
2017-03-26 20:57:51.286 [update notice] unknown MS cmd: 1026b5040101 / 09140300000585000000
2017-03-26 20:57:51.458 [update notice] unknown MS cmd: 1050b505082b0f010000000080 / 00
2017-03-26 20:57:56.618 [bus notice] poll ui YieldThisYear: 0;0;0;0;0;0;0;0;0;0;0;0
2017-03-26 20:57:57.307 [update notice] update bai Mode QQ=10: standby
2017-03-26 20:57:58.288 [update notice] unknown MS cmd: 1008b513020508 / 00
2017-03-26 20:57:58.781 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
2017-03-26 20:57:58.963 [update notice] update hwc Mode QQ=10: 55;auto;02;off
2017-03-26 20:57:59.127 [update notice] unknown MS cmd: 1026b504010d / 05160000800f
2017-03-26 20:57:59.294 [update notice] update hwc Status QQ=10: 0;off;61.75;55
2017-03-26 20:58:00.355 [update notice] update bai Status01 QQ=10: 53.0;54.0;-;-;-;off
2017-03-26 20:58:00.513 [update notice] unknown MS cmd: 1025b5050427005a00 / 00
2017-03-26 20:58:00.806 [update notice] unknown MS cmd: 1025b5040117 / 0101
2017-03-26 20:58:01.130 [bus notice] poll cc Mode: 30;auto;02;off
2017-03-26 20:58:01.351 [update notice] unknown MS cmd: 1025b505082b0f010000000080 / 00
2017-03-26 20:58:02.332 [update notice] unknown MS cmd: 10ecb5040121 / 050900044300
2017-03-26 20:58:03.530 [update notice] unknown MS cmd: 10ecb5040128 / 03000000
2017-03-26 20:58:07.109 [bus notice] poll mc Status: 22;off;25.94;15
2017-03-26 20:58:07.441 [update notice] update bai Mode QQ=10: standby
2017-03-26 20:58:08.384 [update notice] unknown MS cmd: 1008b513020508 / 00
2017-03-26 20:58:08.921 [update notice] unknown MS cmd: 1023b505082b0f010000000080 / 00
2017-03-26 20:58:09.403 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
Hat jemand auch eine auroMATIC 620/3 Steuerung ebusd im Einsatz?
Die folgende Zeile im Log schaut mir nicht korrekt aus:
2017-03-26 20:58:09.403 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
Grüße
NemoN
ich kenne jetzt deine Auromatic nicht, aber Vorlauf und Rücklauf hast du ja auch im Status01 drinnen und der wird ja richtig angezeigt.
2017-03-26 20:57:50.286 [update notice] update bai Status01 QQ=10: 53.0;54.0;-;-;-;off
Vorlauf = 53.0 ( r -m 10 Status01 temp1.0 )
Rücklauf = 54.0 ( r -m 10 Status01 temp1.1 )
LG
Hallo Reinhart,
ich war immer der Meinung das die VL Temperatur höher als die RL sein müsste, da ja Energie im System (Fussbodenheizung) bleiben müsste. Heizung ist eine
- Gasbrennwerttherme
- 750L Wärmespeicher
- Solar mit Heizungsunterstützung
- Heizkurve 0.6
- Speichersoll 55 Grad
- HK Soll 19 Grad.
Anzeige Sensor Werte im Auromatic Display:
SP1: 69 Grad
SP2: 62 Grad
SP3: 0 Grad
TD1: 68 Grad
TD2: 53 Grad
Außentemperatur: 11 Grad
# ebusctl r -m 10 Status01 temp1.0
63.0
# ebusctl r -m 10 Status01 temp1.1
64.0
Für die Fussbodenheizung sind die VL/RL werte viel zu hoch. Ist damit der VL/RL für den Wärmespeicher gemeint!?
2017-03-27 20:47:44.021 [update notice] update hwc Status QQ=10: 0;off;68.94;17
2017-03-27 20:47:44.587 [update notice] update bai Status01 QQ=10: 63.0;64.0;-;-;-;off
2017-03-27 20:47:49.098 [bus notice] poll mc Status0a: 27.44;close;on;off;19
2017-03-27 20:47:51.614 [update notice] update bai Mode QQ=10: standby
2017-03-27 20:47:53.092 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
2017-03-27 20:47:53.422 [update notice] update hwc Status QQ=10: 0;off;68.94;17
2017-03-27 20:47:54.669 [update notice] update hc DateTime QQ=10: valid;20:47:55;27.03.2017;11.250
2017-03-27 20:47:54.863 [update notice] update bai Status01 QQ=10: 63.0;64.0;-;-;-;off
2017-03-27 20:47:55.125 [bus notice] poll mc Mode: 19;auto;0;0;low;mixer;night
2017-03-27 20:48:01.129 [bus notice] poll cc Mode: 30;auto;02;off
2017-03-27 20:48:01.734 [update notice] update bai Mode QQ=10: standby
2017-03-27 20:48:03.475 [update notice] update hc SumFlowSensor QQ=10: -13.94;cutoff
2017-03-27 20:48:03.659 [update notice] update mc Mode QQ=10: 19;auto;0;0;low;mixer;night
2017-03-27 20:48:03.823 [update notice] update mc Status QQ=10: 19;off;27.56;15
2017-03-27 20:48:03.990 [update notice] update hwc Status QQ=10: 0;off;68.94;17
2017-03-27 20:48:04.147 [update notice] update mc RoomTempOffset QQ=10: 0.00
2017-03-27 20:48:04.801 [update notice] update bai Status01 QQ=10: 63.0;64.0;-;-;-;off
2017-03-27 20:48:07.087 [bus notice] poll mc Status: 19;off;27.56;15
Grüße
NemoN
Zitat von: Reinhart am 27 März 2017, 17:51:54
ich kenne jetzt deine Auromatic nicht, aber Vorlauf und Rücklauf hast du ja auch im Status01 drinnen und der wird ja richtig angezeigt.
2017-03-26 20:57:50.286 [update notice] update bai Status01 QQ=10: 53.0;54.0;-;-;-;off
Vorlauf = 53.0 ( r -m 10 Status01 temp1.0 )
Rücklauf = 54.0 ( r -m 10 Status01 temp1.1 )
Zitat von: john30 am 25 März 2017, 12:33:00
das scheint die antwort vom slave (ehp) nicht dem zu entsprechen, was erwartet wird. versuch mal, das letzte feld (currentmode) aus ModeDesired in hcmode.inc wegzunehmen. dann müsste es für deine ehp klappen.
Hallo John,
ich habe mich in der Kennzeichnung geirrt, ich habe eine geotherm 81/3. In meiner hcmode.inc, finde ich diese Optionen nicht, kannst mir sagen wie ich das ändern muss?
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Status,Status,,,B511,03,,,temp;press;press;HEX:4,,,
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,B511,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,B511,02,,,hwcmode;temp0;temp1;temp0;temp1,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,
Gruß
lewej
Zitat von: john30 am 25 März 2017, 12:22:39
schick mir doch mal ein bisschen von deinem ebusd log file, vielleicht lässt sich da was erkennen.
Grundsätzlich ist das Auslesen via eBUS natürlich eine gewisse Störung, es sei denn mal liest nur mit. Des weiteren verändert auch der bloße Anschluss an den Bus physisch die Eigenschaften durch Verdrahtung, Impedanz, Lasten etc.
Wie verhält es sich denn mit der Vorgängerversion von ebusd?
Hallo john,
das liegt wohl nicht an der Version. Wie es scheint, verliert mein Raspberry die Verbindung zum ebus Koppler. Ich habe den converter von eservice. Hat jemand evtl auch solche Probleme gehabt. Anbei der Fehler:
Mar 28 10:14:58 smarthome kernel: [240230.740508] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:19:50 smarthome kernel: [240522.773968] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:20:50 smarthome kernel: [240583.434989] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:24:23 smarthome kernel: [240796.109272] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:24:34 smarthome kernel: [240807.203525] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:26:19 smarthome kernel: [240911.913675] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:40:22 smarthome kernel: [241755.042497] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:40:45 smarthome kernel: [241777.826670] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:55:56 smarthome kernel: [242689.340429] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 10:56:24 smarthome kernel: [242717.059484] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 10:58:57 smarthome kernel: [242870.580593] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:05:50 smarthome kernel: [243282.987591] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:06:13 smarthome kernel: [243306.397362] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:06:48 smarthome kernel: [243341.165453] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 11:12:57 smarthome kernel: [243710.436558] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:13:17 smarthome kernel: [243729.865004] ftdi_sio ttyUSB1: failed to get modem status: -71
Mar 28 11:13:51 smarthome kernel: [243763.796175] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:16:27 smarthome kernel: [243919.744466] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:30:01 smarthome kernel: [244733.752663] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:31:20 smarthome kernel: [244813.062187] ftdi_sio ttyUSB1: failed to get modem status: -32
Mar 28 11:31:30 smarthome kernel: [244823.342173] ftdi_sio ttyUSB1: failed to get modem status: -71
Gruß
lewej
Hallo Zusammen,
läuft bei jemanden der ebus Koppler von eservice an einem PI 3 und einem aktiven HUB stabil?
Ich habe folgende Hardware:
- PI hängt an einem meanwell 5V 6A Schaltnetzteil, an diesem hängt auch ein aktiver HUB
- der ebus Koppler hängt am USB HUB
Ich bekomme weder den ebus Koppler von eservice noch den selbst gebauten aus dem Forum stabil ans laufen.
Meine anderen Usb Devices, laufen alle ohne Probleme. Deshalb kann ich ein Strom Problem ausschliessen.
Hat jemand eine Idee?
Gruss
Lewej
@NemoN habe eine vergreichbare Konfiguration.
Habe SumFlowSensor nur in einer csv. (Habe allerdings noch csv's aus den Anfängen)
Da grep bei Dir zwei Einträge liefert, musst Du den circuit angeben.
Prüfe mal mit ebusctl f -f SumFlowSensor die Auflösungen.
ebusctl r -c hc SumFlowSensor funtioniert bei mir.
Hallo Zusammen,
ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.
@john:
Hast eine Idee, was das sein kann?
Gruß
lewej
Guten Tag zusammen,
ich habe eine Wolf Heizung mit einem R2 BM. Der ebus läuft sauber und ich speicher fleissig Daten. Mein Ziel ist es, die Daten vom Bus per "ebusctl r Parameter" auszulesen und in eine Datenbank zu speichern. Auf den Bus senden möchte ich nicht. Durch dieses Forum und Google bin ich schon gut auf dem Weg. Vielen Dank für die geleistete Arbeit.
Zum Schluss habe ich noch folgende Zeile offen:
2017-03-31 08:24:47.690 [update notice] unknown MM cmd: 03f10800084d27000e00030037
2017-03-31 08:25:01.168 [update notice] unknown MM cmd: 1003050709bb0175020080ff6eff
2017-03-31 08:25:06.174 [update notice] unknown MM cmd: 10030800084d27000e80010037
Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen. Weder beim Neustart noch bei ebusctl reload gibt es einen Hinweis auf einen Öffnungsversuch der Dateien. Die Adressen lassen den deamon kalt. Was muss ich tun??
Ein ebusd --checkconfig läuft ohne Fehler durch.
Die Befehle 0507 und 0800 sind auch in der broadcast.csv hinterlegt. Dürfen die nur einmal vorhanden sein?
Viele Grüße
Binnesmann
Zitat von: lewej am 30 März 2017, 20:52:24
Hallo Zusammen,
ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.
@john:
Hast eine Idee, was das sein kann?
Gruß
lewej
Ich habe auch das Problem das über MQTT keine updates bekomme, allerdings nicht der ebusd hört auf zu publishen, sondern die MQTT Devices in FHEM bekommen die publish nicht mit, wenn ich direkt mit einem mosqutitto client lausche dann sehe ich alle updates. Das schräge dabei ist aber, das betrifft nur die MQTT DEVICES die ich aus dem ebusd topic subscribe, alle anderen funktionieren.
Sent from my iPad using Tapatalk
Zitat von: bmwfan am 18 Januar 2017, 21:34:08
Möchte für andere Nutzer einer Zeotherm die ersten Erkenntnisse meiner Versuche aufzeigen, da es doch etwas mühsam war die Parameter zuzuordnen:
Nachdem Du der einzige mit bekannte mit einer Zeotherm bist: Könntest Du bitte mal folgende Abfrage mit ebusd machen:
ebusctl hex 50b509030d3c00Damit wird hoffentlich der Typ des Heizkreises abgefragt.
Merci, john
Zitat von: Binnesmann am 31 März 2017, 09:56:16
Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen. Weder beim Neustart noch bei ebusctl reload gibt es einen Hinweis auf einen Öffnungsversuch der Dateien. Die Adressen lassen den deamon kalt. Was muss ich tun??
Ein ebusd --checkconfig läuft ohne Fehler durch.
Die Befehle 0507 und 0800 sind auch in der broadcast.csv hinterlegt. Dürfen die nur einmal vorhanden sein?
schick mir das log file, dann schau ich mal rein
Zitat von: lewej am 30 März 2017, 20:52:24
ich hab ein Problem mit dem ebusd und mqtt, nach einer Weile hört ebusd was an den MQTT Broker zu publishen.
Hat jemand auch diese Probleme. Leider konnte ich das ganze noch nicht eingrenzen. Ich habe jetzt das logging hochgeschraubt.
@john:
Hast eine Idee, was das sein kann?
ist denn noch signal da? nachdem dein ftdi device wohl ärger macht, könnte sowas evtl. sein.
Zitat von: lewej am 28 März 2017, 11:35:36
das liegt wohl nicht an der Version. Wie es scheint, verliert mein Raspberry die Verbindung zum ebus Koppler. Ich habe den converter von eservice. Hat jemand evtl auch solche Probleme gehabt. Anbei der Fehler:
Mar 28 10:14:58 smarthome kernel: [240230.740508] ftdi_sio ttyUSB1: failed to get modem status: -71
genau das gleiche hatte ich im januar auch mal über mehrere wochen. immer wieder spontan aufgetreten. hab dann den hersteller angeschrieben, aber nie eine antwort bekommen. ein paar wochen später war das phänomen dann einfach weg. total merkwürdig.
Zitat von: lewej am 28 März 2017, 11:32:34
ich habe mich in der Kennzeichnung geirrt, ich habe eine geotherm 81/3. In meiner hcmode.inc, finde ich diese Optionen nicht, kannst mir sagen wie ich das ändern muss?
das ist ja bizarr. aber okay. Ändere mal in hcmode die folgende Zeilen:
*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
in das hier:
*r,,,,,,"B504",,,,,,,
*u,,,,,,"B510",,,,,,,
r;u,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
Zitat von: john30 am 02 April 2017, 12:03:53
genau das gleiche hatte ich im januar auch mal über mehrere wochen. immer wieder spontan aufgetreten. hab dann den hersteller angeschrieben, aber nie eine antwort bekommen. ein paar wochen später war das phänomen dann einfach weg. total merkwürdig.
Hallo John,
wie immer Danke für deine Mühe, dein Support ist echt klasse.
Seit ca. 3 Tagen tritt der Fehler nicht mehr in der häufigkeit auf und der ebusd verliert auch seine Verbindung nicht mehr.
Was habe ich gemacht:
- Wie es scheint, sollte man mehrere usb-serial converter nicht am gleichen aktiven usb hub betreiben, sobald ich beide an einem hängen habe, gibt es fehler( mal weniger mal mehr, konnte es bis jetzt nicht einkreisen)
- getrennte usb hubs mit Schaltznetzteil 6A Stromversorgung
- raspi jessy auf aktuelleste Version upgedatet
- raspi firmware upgedatet
Bis heute scheint die Verbindung stabil zu laufen, das mqtt Problem bin ich noch am beobachten.
Gruss lewej
Hallo John,
den Teil des logs ab dem reload findest Du im Anhang. Ich bin übers Wochenende leider nicht weiter gekommen.
Wenn ich es schaffe, stelle ich auch noch meine csv's ein.
Grüße
Binnesmann
Edit: Ich habe die csv's angehängt und ich verwende Version 2.2.65328e5 - alt, aber läuft stabil und kann alles was ich brauche
Zitat von: Binnesmann am 31 März 2017, 09:56:16
Ich habe für beide Slaveadressen 03 und f1 jeweils eine .csv Datei im gleichen Unterverzeichniss wie die anderen.
Der Fehler ist, dass 03 und f1 beides Master Adressen sind und keine Slaves.
D.h. Dateien umbenennen in die korrespondierende Slave Adresse wird helfen (08 bzw. f6).
Das Log zeigt das eigentlich auch schon:
2017-03-30 22:02:42.532 [main error] unable to load scan config 08: no file from /etc/ebusd/kromschroeder with prefix 08. found
2017-03-30 22:02:50.602 [main error] unable to load scan config f6: no file from /etc/ebusd/kromschroeder with prefix f6. found
Könnte mal bitte jemand mit einer SOLSY oder VR630 prüfen, ob die quick Kommandos dort auch greifen?
Also insbesondere auf Adresse 25 für HWC. Dazu einfach an die 25.*.hwc.csv noch "!include,quick.inc" als neue Zeile dranhängen, dann reload und am Ende schauen ob bspw. "ebusctl w -c hwc load on" die Speicherladung startet.
Auch interessant wäre, ob save/party ebenfalls auf Adresse 25 funktionieren würden.
VG John
@ john30
Habe noch die "frühen" csv's und daher die quick.csv hinzugefügt.
u,quick,load,Quick - WW Speicherladung,,25,b505,06,onoff,s,UCH,0=off;1=on,,
w -c quick load on/off funktionieren.
Ich frage ab mit:
r -c hc IsInStorageFilling, r -c hc CleaningLady, r -c hc IsInParty
save/party habe ich nicht probiert.
Zitat von: john30 am 02 April 2017, 12:10:10
das ist ja bizarr. aber okay. Ändere mal in hcmode die folgende Zeilen:
*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
in das hier:
*r,,,,,,"B504",,,,,,,
*u,,,,,,"B510",,,,,,,
r;u,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
Hallo John,
ich habe das jetzt so angepasst, die Fehler sind fast weg, ist noch eine Adresse die nicht erkannt wird:
[bus debug] switching from receive command ACK to receive response
2017-04-08 17:30:33.104 [bus debug] switching from receive response to receive response CRC
2017-04-08 17:30:33.109 [bus debug] switching from receive response CRC to send response ACK
2017-04-08 17:30:33.116 [bus debug] notify request: done
2017-04-08 17:30:33.116 [bus notice] poll mc CfgHeatSinkType: mixer
2017-04-08 17:30:33.116 [bus debug] switching from send response ACK to send SYN
2017-04-08 17:30:33.285 [update info] update MS cmd: 1025b505072b000100000000 / 00
2017-04-08 17:30:33.285 [update notice] unknown MS cmd: 1025b505072b000100000000 / 00
2017-04-08 17:30:33.562 [update info] update MS cmd: 1008b511020300 / 0a59026d04890600000000
2017-04-08 17:30:33.564 [update notice] update ehp Status QQ=10: 37.56;1.133;1.673;00 00 00 00
2017-04-08 17:30:33.725 [update info] update MS cmd: 1008b5110102 / 050000c800c8
2017-04-08 17:30:33.727 [update notice] update ehp Status02 QQ=10: disabled;0;100.0;0;100.0
2017-04-08 17:30:35.304 [update info] update MS cmd: 1008b50903290100 / 0501003c0200
2017-04-08 17:30:35.307 [update notice] update ehp StorageTempTop QQ=10: 35.75;ok
2017-04-08 17:30:35.480 [update info] update MS cmd: 1008b51009000100000000000002 / 00
2017-04-08 17:30:35.483 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:35.545 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-08 17:30:35.671 [mqtt debug] publish ebusd/global/uptime 352
2017-04-08 17:30:36.119 [update info] update MS cmd: 1008b509040ed10000 / 00
2017-04-08 17:30:36.121 [update notice] update ehp EnergyBalancingRelease QQ=10: off
2017-04-08 17:30:36.587 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-08 17:30:37.353 [update info] update MS cmd: 1023b5040101 / 091e0300000006000000
2017-04-08 17:30:37.355 [update notice] upda
tail -f /var/log/ebusd/ebusdvaillant.log|grep invalid
2017-04-08 17:28:04.352 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:14.648 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:24.642 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:34.728 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:44.595 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:28:54.675 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:04.885 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:14.827 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:24.842 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:34.954 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:46.434 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:29:55.049 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:05.123 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:15.334 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
2017-04-08 17:30:25.241 [update error] unable to parse ehp Mode from 1008b51009000100000000000002 / 00: ERR: invalid position
Gruß lewej
Zitat von: john30 am 08 April 2017, 10:52:43
Könnte mal bitte jemand mit einer SOLSY oder VR630 prüfen, ob die quick Kommandos dort auch greifen?
Also insbesondere auf Adresse 25 für HWC. Dazu einfach an die 25.*.hwc.csv noch "!include,quick.inc" als neue Zeile dranhängen, dann reload und am Ende schauen ob bspw. "ebusctl w -c hwc load on" die Speicherladung startet.
Auch interessant wäre, ob save/party ebenfalls auf Adresse 25 funktionieren würden.
VG John
Hi,
wenn es was bringt, könnte ich das mit einer auroMATIC 560 testen, da meckert sowieso das für die 23 und 25 keine Konfig vorhanden ist, soll ich das machen?
Gruß
lewej
Hallo John,
oh man. Wie blöd ist das denn? Ich hab die Liste mit den Adressen vor mir liegen gehabt und hab das nicht gesehen. Werde dann morgen mal ausprobieren, bin gerade im Urlaub.
Vielen Dank und Gruß
Binnesmann.
Guten Morgen alle zusammen,
ich habe ein Problem vielleicht kann mir einer helfen ?
Bei der Installation auf Raspberry PI3 bekomme ich diese Meldung.
sudo dpkg -i --force-overwrite ebusd-2.4_armhf.deb
dpkg-deb: Fehler: »ebusd-2.4_armhf.deb« ist kein Archiv im Debian-Format
dpkg: Fehler beim Bearbeiten des Archivs ebusd-2.4_armhf.deb (--install):
Unterprozess dpkg-deb --control gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
ebusd-2.4_armhf.deb
finde leider keine Lösung.
Hi,
Was sagt den
file ebusd*
Und wie hast Du das deb geladen? Ich wette darauf, dass Du entweder eine html Datei mit einer Fehlermeldung geladen hast, statt dem deb-Paket, oder ein Windows/Unix Zeichensatz Problem vorliegt.
Let's see, shall we?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo,
ich benutze Arch Linux auf RPi 2 und kürzlich hat gefunden, dass ich nicht mehr aktiv mit ebusctl datei lesen kann.
Die automatische Nachrichten sind noch korrekt:
2017-04-09 17:20:26.934 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-09 17:20:30.635 [update info] update MS cmd: 1008b5110101 / 0928296011ffff0000ff
2017-04-09 17:20:30.636 [update notice] update MS StatusTHER: 20.0;20.5;17.375;-;-;0
2017-04-09 17:20:32.290 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2017-04-09 17:20:32.871 [update info] update MS cmd: 1008b5040100 / 0a00ffffffffffffff6011
2017-04-09 17:20:32.872 [update notice] update MS OutsideTemp: 17.375
2017-04-09 17:20:33.127 [update info] update MS cmd: 1008b5110102 / 050014965a78
2017-04-09 17:20:33.127 [update notice] update MS PumpStatus: off
2017-04-09 17:20:34.723 [main debug] performing regular tasks
Doch, als ich versuche z.B. 'ebusctl read RoomTemp' (oder 'scan' und so):
2017-04-09 09:46:08.259 [main debug] >>> read RoomTemp
2017-04-09 09:46:08.259 [bus info] send message: 3115b509030d3a00
2017-04-09 09:46:08.301 [bus debug] notify request: ERR: read timeout
2017-04-09 09:46:08.302 [bus error] send to 15: ERR: read timeout, retry
2017-04-09 09:46:08.302 [bus debug] ERR: read timeout during ready, switching to skip
2017-04-09 09:46:08.364 [bus debug] notify request: ERR: read timeout
2017-04-09 09:46:08.365 [bus error] send to 15: ERR: read timeout, retry
2017-04-09 09:46:08.365 [bus debug] ERR: read timeout during ready, switching to skip
2017-04-09 09:46:08.429 [bus debug] notify request: ERR: read timeout
2017-04-09 09:46:08.429 [bus error] send to 15: ERR: read timeout, retry
2017-04-09 09:46:08.429 [bus debug] ERR: read timeout during ready, switching to skip
2017-04-09 09:46:08.493 [bus debug] notify request: ERR: read timeout
2017-04-09 09:46:08.493 [bus error] send to 15: ERR: read timeout
2017-04-09 09:46:08.493 [bus error] send message part 0: ERR: read timeout
2017-04-09 09:46:08.493 [main debug] <<< ERR: read timeout
2017-04-09 09:46:08.493 [bus debug] ERR: read timeout during ready, switching to skip
2017-04-09 09:46:08.494 [main debug] >>>
... lot of empty lines removed ...
2017-04-09 09:46:08.494 [main debug] <<< ERR: command not found
2017-04-09 09:46:08.494 [network debug] [00007] wait for result
2017-04-09 09:46:08.494 [network info] [00007] connection closed
Ich überprüfte die Leitung, keine Veränderung. Ich versuchte sowohl neuere als auch ältere Version des Ebusd. Als letzen Versuch installierte ich rasbian (jessie) - und voila, ebusd 2.4 läuft wieder.
Als ich in meine Ebuslogs sehe, die Probleme fing am 21/03/2017 21:24 an. Kürzlich früher, aktualisierte ich viele Programme - volles Log is beigelegt, doch ich meine, dass der 'beste' Kandidat das Kernel oder RPi firmware ist. (P.S. Downgrade in Arch is nicht so leicht...)
Hat jemand Idee, was schiefgehen konnte?
das mit dem Update ist wohl eher Zufall, denn empfangen kannst ja noch alles, nur senden geht nicht, slso dürfte der ebusd ja noch korrekt arbeiten.
Ich würd eher auf den eBus Konverter tippen. Was verwendest du denn für eine Schaltung?
LG
ebus Koppler von eservice-online.de (mit USB). Ich versuchte auch den Trimmer drehen, besser war das nicht.
Interessant ist, dass im Debian Jessie alles läuft ;-(
Vorläufig habe ich den Koppler an zweites RPi angeschlossen, zum Glück habe in ein Switch im Keller mit freiem Port.
aha, wenn der selbe Koppler unter Debian funktioniert (also auch senden kann), dann hast du wohl recht mit deiner Vermutung, dass es wohl mit einem Update zu tun hat.
Da ich Arch Linux nicht kenne, kann ich dir leider auch nicht weiter helfen. Vielleicht findest du ja im Changelog noch Hinweise was da so alles geändert wurde, speziell im Kernel. Es könnte ja dann irgendwas mit der seriellen Kommunikation zu tun haben.
LG
Zitat von: lewej am 08 April 2017, 17:34:33
ich habe das jetzt so angepasst, die Fehler sind fast weg, ist noch eine Adresse die nicht erkannt wird:
okay, dann schick mir doch bitte mal Dein scan result. Ich hab ja auch eine EHP und für Deine müssen die CSVs ein bisschen abgeändert werden.
Zitat von: lewej am 08 April 2017, 17:38:50
wenn es was bringt, könnte ich das mit einer auroMATIC 560 testen, da meckert sowieso das für die 23 und 25 keine Konfig vorhanden ist, soll ich das machen?
Gute Idee. Brauchst nicht machen, die hab ich selbst ja auch noch (an nem separaten eBUS).
Zitat von: MilanK am 09 April 2017, 20:52:23
ebus Koppler von eservice-online.de (mit USB). Ich versuchte auch den Trimmer drehen, besser war das nicht.
Interessant ist, dass im Debian Jessie alles läuft ;-(
da hat Reinhart Recht. Da wird mit dem Update sich das Verhalten der seriellen Schnittstelle geändert habe. Du könntest mal mit größeren Latenzwerten versuchen, das zu kompensieren (siehe wiki (https://github.com/john30/ebusd/wiki/2.-Run#device-options) Stichwort latency).
Oder Du schaust, wie Du dem neuen Kernel beibringst, nicht so viel zu puffern und jedes einzelne Byte möglichst schnell von/an user level zu transportieren.
Zitat von: john30 am 10 April 2017, 08:25:15
Du könntest mal mit größeren Latenzwerten versuchen, das zu kompensieren (siehe wiki (https://github.com/john30/ebusd/wiki/2.-Run#device-options) Stichwort latency).
Leider hat es nicht geholfen, der maximale funktionierende Wert war 100000 µs für beide Latenzen. Eigentlich, das RPi is nicht so viel überladen, 'top' zeigt CPU load zwischen 0.05 - 0.40.
Am Ende, downgrade des Kernels zu 4.4.41 hat es gelöst. Ich aktualisiere auch den Report am GitHub.
Äh - setzt mich doch mal ins Bild, weil ich derzeit zu wenig Zeit habe, um alle Beiträge mitzulesen.
Hat da wirklich jemand versucht, über die serielle Schnittstelle zu gehen ?
Das war vor 2 Jahren mein erster Ansatz, ging vollkommen schief, weil diese serielle Schnittstelle im RPi nur per Emulation vorhanden ist und der dauernde Traffic auf dem EBUS diese Emulation total ausgebremst hat. Führte zu gewaltigen Verzögerungen bei der Weitergabe von Daten an den ebusd - Rekord waren 90 Minuten.
Bei dem USB-Zugang sollte das aber nicht auftreten.
LG
pah
Hi John!
Hast du zufällig ein csv für die Recovair 275? Ich besitze folgende:
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=VAI00;SW=0124;HW=8901"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address c0: slave, scanned "MF=Vaillant;ID=WTW04;SW=0127;HW=9001"
Liebe Grüße
Stefan
Zitat von: she am 14 April 2017, 09:22:47
Hast du zufällig ein csv für die Recovair 275?
noch nicht so wirklich. ich hab die gleiche, konnte aber mangels Zeit noch nicht viel rausfinden.
Schade. Mir würden vorerst die Telegramme für Auto/Nacht/Tag und Kühlen Ein/Aus und vielleicht noch High reichen. Hast du die zufällig schon herausgefunden?
Würde mir wirklich helfen..
Liebe Grüße
She
Hallo zusammen!
Ich hoffe jemand kann mir helfen!
Ich habe eine Heizungsanlage von Sieger. Diese hat eine SiegerControl s52a Steuerung. In den technischen Unterlagen wird ein Kommunikationsbus erwähnt.
Leider haben meine bisherigen Recherchen keine Ergebnisse geliefert.
Ist hier im Forum jemandem bekannt um welches Bussystem es sich handelt, und ob man diesen Bus mit FHEM verbinden könnte.
Meine Hoffnung ist, das es sich um eBus handeln könnte.
Vielen Dank!
mfg
Helmut
Hi,
Ich habe an einer alten Wolf R16 Steuerung Probleme die Zeitprogramme auszulesen.
Im gegensatz zu neueren Heizungen die für jeden Tag mehrere Ein und Ausschaltpunkte besitzen
sind bei den alten Wolf Regelungen für jedes Zeitprogramm 14 Schaltblöcke vorhanden.
Für jeden Schaltblock kann folgendes eingestellt werden.
- Die Tage, also Mo;Di;Mi;Do;Fr;Sa;So;Mo-Do;Mo-Fr;Mo-So;Sa-So
- Die Uhrzeit (in Viertelstundenschritten)
- Ein bzw Aus
Für die Blöcke werden zwei Byte verwendet
1 Byte, die Tage
2 Byte die Schaltzeiten
Allerdings wird das zweite Byte sowohl für die Einschalt, als auch für die Ausschaltzeiten verwendet
z.B
00:00 Aus = 0x00 Ein = 0x80
06:00 Aus = 0x18 Ein = 0x98
12:00 Aus = 0x30 Ein = 0xB0
12:30 Aus = 0x32 Ein = 0xB2
18:00 Aus = 0x48 Ein = 0xC8
18:15 Aus = 0x49 Ein = 0xC9
Wenn ich hier den Datentyp TTQ verwende werden alle Ausschaltzeiten korrekt angezeigt,
allerdings erhalte ich bei allen Einschaltzeiten eine Fehlermeldung ERR: argument value out of valid range in decode
Gruss
Hans
Zitat von: hansg am 15 April 2017, 17:40:33
Allerdings wird das zweite Byte sowohl für die Einschalt, als auch für die Ausschaltzeiten verwendet
z.B
00:00 Aus = 0x00 Ein = 0x80
Wenn ich hier den Datentyp TTQ verwende werden alle Ausschaltzeiten korrekt angezeigt,
allerdings erhalte ich bei allen Einschaltzeiten eine Fehlermeldung ERR: argument value out of valid range in decode
Dafür habe ich TTQ extra auf die notwendigen 7 Bits reduziert. D.h. das Flag Ein/Aus muss entsprechend separat definiert werden. Dafür brauchst Du einen aktuellen ebusd 3.0pre aus dem git.
Hallo John,
ich konnte das mit den richtigen Slave Adressen jetzt testen und die Dateien werden gelesen. Aber die Master-Master Komandos werden nicht dekodiert. Ich habe für
unknown MM cmd: 10030800081a2600068000000a
in der Datei 08.csv die Zeile
b,,sollw08,Sollwertübertragung des Reglers an andere Regler,,,0800,,kesselsolltemp,,temp2,,,Kesselsollwert,aussentemp,,temp2,,,Außentemperatur,leistungszwang,,D1B,,%,Leistungszwang,status,,HEX,,,Status,brauchwassersolltemp,,temp2,,,Brauchwassersollwert,,,,,,,,,,,,
aber die Daten wollen nicht übernommen werden. Als normaler Broadcast funktioniert die Datenübernahme - nur nicht als MM cmd.
Grüße
Binnesmann
Zitat von: Binnesmann am 16 April 2017, 22:41:03
unknown MM cmd: 10030800081a2600068000000a
b,,sollw08,Sollwertübertragung des Reglers an andere Regler,,,0800,,kesselsolltemp,,temp2,,,Kesselsollwert,aussentemp,,temp2,,,Außentemperatur,leistungszwang,,D1B,,%,Leistungszwang,status,,HEX,,,Status,brauchwassersolltemp,,temp2,,,Brauchwassersollwert,,,,,,,,,,,,
aber die Daten wollen nicht übernommen werden. Als normaler Broadcast funktioniert die Datenübernahme - nur nicht als MM cmd.
Eine MM Nachricht ist von der Logik her immer zwingend ein "Write", also musst Du es auch so definieren. Das "b" am Anfang der Zeile stuft die Nachricht als MS ein, womit die Felder automatisch im Slave Teil erwartet werden. Mach daraus ein "w" und ändere die dazugehörige Default Zeile darüber entsprechend ab (oder kopiere diese mitsamt Änderung auf w), dann sollte es passen.
Hallo John,
danke. Die Daten werden jetzt übersetzt, aber ich kann die Daten nicht per ebusctl r ... abrufen. Liegt das an meinem alten Softwarestand oder ist da noch ein Fehler?
Grüße
Binnesmann
Zitat von: Binnesmann am 17 April 2017, 21:32:09
danke. Die Daten werden jetzt übersetzt, aber ich kann die Daten nicht per ebusctl r ... abrufen. Liegt das an meinem alten Softwarestand oder ist da noch ein Fehler?
Wie gesagt, das sind von der Natur her eigentlich Write Messages, deshalb kann man die auch nicht mittels "ebusctl read" so einfach auslesen.
Ich schätze, was Du möchtest, ist, dass ebusd die von anderen Teilnehmern versendeten Write Nachrichten nur mitliest, damit Du sehen kannst, was damit transportiert wurde, richtig?
Dann musst Du den Typ entweder auf "uw" (sog. Update Write bzw. eigentlich Passive Write) setzen oder darum ergänzen (dann könntest Du auch selbst mit ebusd die Nachricht als Write verschicken).
Zitat von: hasenhirn am 19 Februar 2016, 07:01:27
Wenn ich das so halbwegs am laufen habe, werde ich mich mal mit der recoVair beschäftige.
Lieber Thomas!
Hattest du schon Zeit dich mit der recovair zu beschäftigen ? Ich habe das gleiche Modell, konnte aber leider noch keine hilfreichen Telegramme identifizieren.
Die beigefügten Telegramme funktionieren leider bei meiner Recovair 275 nicht.
lg
Stefan
Hallo john,
habe Deine Frage erst heute gelesen. Sorry. Kämpfe gerade an anderen Baustellen.
Ich habe den Befehl ebusctl hex 50b509030d3c00 eingegeben, bekomme aber diese Meldung: pi@raspberrypi ~ $ ebusctl hex 50b509030d3c00
ERR: command not enabled
Damit kann ich nichts anfangen. Muss ich vor Eingabe des Befehls etwas einschalten?
Gruß Jürgen
Hallo Zusammen,
ich habe mich auch daran gewagt einen ebusd mit meiner Heizungsanlage zu koppeln. Ich habe einen Multimatic 700 Regler. Für diesen habe ich bei https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de/vaillant auch ein csv file gefunden.
Leider wird diese nicht geladen, Info am Ende.
Ich habe ein wenig damit "herumgespielt" und herausgefunden das es es an den Definitionen "tempv", "calibrationv" und andere liegt. Ich bin nun auf der Suche nach einer funktionierenden CSV-Datei.
Danke und Gruß,
Dietmar
/etc/ebusd/vaillant# ebusctl info
version: ebusd 3.0pre.80e6f48
update check: unknown
signal: acquired
symbol rate: 24
max symbol rate: 189
reconnects: 0
masters: 3
messages: 251
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0203;HW=9102", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0110;HW=2103"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
Nimm die komplette Konfiguration von der genannten Quelle, vor allem die "_templates.csv", dann sollte es passen!
Hallo Sven,
danke für die schnelle Hilfe. Keine Ahnung welchen Mix ich mir da zusammengebaut habe.
Habe nochmal den Ordner gelöscht und neu reinkopiert.
Und siehe da...
Wie du es sagst ...
Dann passt das schon.
Danke,
Dietmar
Zitat von: bmwfan am 19 April 2017, 21:26:09
Ich habe den Befehl ebusctl hex 50b509030d3c00 eingegeben, bekomme aber diese Meldung: pi@raspberrypi ~ $ ebusctl hex 50b509030d3c00
ERR: command not enabled
Damit kann ich nichts anfangen. Muss ich vor Eingabe des Befehls etwas einschalten?
Du musst das hex Kommando noch enablen, dazu ebusd Startparameter um "--enablehex" ergänzen.
Nachdem Sven77 mir mit dem CSV geholfen hat, funktioniert bei mir fast alles was ich mir Wünsche.
Es fehlt mir zu meinem Glück aber noch die PartloadHcKW.
Leider bekomme ich bei meiner ecotec exclusiv ein "ERR: invalid position in decode".
Kann mir jemand helfen?
Gruß,
Dietmar
Zitat von: kleindi am 21 April 2017, 11:39:01
Nachdem Sven77 mir mit dem CSV geholfen hat, funktioniert bei mir fast alles was ich mir Wünsche.
Es fehlt mir zu meinem Glück aber noch die PartloadHcKW.
Leider bekomme ich bei meiner ecotec exclusiv ein "ERR: invalid position in decode".
Was geht nicht - Lesen und/oder Schreiben?
Du kannst mal versuchen andere Adressen zu lesen, die Du Dir aus den csv und inc Dateien raussuchst.
Also z.B. statt "0704" "6C00" oder "B000" nehmen.
bei meiner ecoCompact geht Lesen, aber Schreiben verändert nichts. Es kommt kein Fehler zurück - vielleicht schreibgeschütztes Register.
Berichte mal bei Erfolg.
Gruß,
(ein anderer) Dietmar
Ich habe bisher nur lesen getestet. Würde aber auch gerne schreiben.
Die meisten Sachen funktionieren wohl:
root@raspberrypi:/etc/ebusd/vaillant# ebusctl r -f FanMinSpeedOperation
1000
root@raspberrypi:/etc/ebusd/vaillant# ebusctl r -f ReturnTempMax
116.06
root@raspberrypi:/etc/ebusd/vaillant# ebusctl r -f PrEnergyCountHwc2
0
Um die Frage "Was geht nicht?" genuaer zu beantworten:
Alle in der bai.308523.inf funktionieren ausser folgende 27 Werte:
PartloadHcKW
WPPostrunTime
BlockTimeHcMax
ExtFlowTempDesiredMin
StoragereleaseClock
EBusHeatcontrol
externalFlowTempDesired
GasvalveUCFeedback
VortexFlowSensor
FlowSetPotmeter
HwcSetPotmeter
ReturnRegulation
HcPumpMode
SecondPumpMode
HwcTempMax
AccessoriesOne
AccessoriesTwo
FanSpeedOffsetMin
FanSpeedOffsetMax
SolPostHeat
ValveMode
HwcPostrunTime
WarmstartOffset
StorageLoadTimeMax
PartloadHwcKW
FlowsetHwcMax
HoursTillService
@John:
Das selbe Resultat.
pi@raspberrypi ~ $ ebusd --enablehex
pi@raspberrypi ~ $ ebusctl hex 50b509030d3c00
ERR: command not enabled
Wenn ich etwas falsch eingegeben habe gib doch bitte die ganze Befehlszeile an. Ich habe im Wiki geschaut, aber keinen Fehler bei meiner Eingabe gefunden.
Gruß Jürgen
Zitat von: bmwfan am 22 April 2017, 18:53:13
pi@raspberrypi ~ $ ebusd --enablehex
pi@raspberrypi ~ $ ebusctl hex 50b509030d3c00
ERR: command not enabled
Wenn ich etwas falsch eingegeben habe gib doch bitte die ganze Befehlszeile an. Ich habe im Wiki geschaut, aber keinen Fehler bei meiner Eingabe gefunden.
So funktioniert das nur, wenn ebusd nicht schon als Dienst im Hintergrund läuft. "--enablehex" muss in die Startparameter des Dienstes hinzugefügt werden (/etc/defaults/ebusd) und dann der Dienst neu gestartet werden.
Hallo John,
ich vermute diese Zeie ergänzen:
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
Müßte dann lauten:
EBUSD_OPTS="--scanconfig --enablehex"
Warum ist da --checkconfig nicht angegeben? Wird das nur bei der Installation benötigt?
Gruß Jürgen
Hat geklappt:
pi@raspberrypi /etc/default $ ebusctl hex 50b509030d3c00
0100
Gibt es inzwischen schon etwas neues zu den Zeotherm-Dateien. Ich kann einige Auslesen, aber die meisten Parameter findet ebusd nicht.
Gruß Jürgen
Trotz diverser Versuche und dem Befolgen vieler Ratschläge aus dem Forum und dem eBus Wiki lädt der ebusd die 15.700.csv nicht.
- da ja zumindest die 08.bai.csv geladen wird und auch einige plausible Werte gelesen werden, scheint mir die grundsätzliche Installation zu funktionieren (siehe angehängtes logfile).
- ich verstehe, dass für die VR71 Erweiterung noch kein .csv existiert... lassen wir das erstmal so stehen, wird ggf. mehreren Kommentaren zufolge nicht zwingend benötigt
Den verschiedenen Hinweisen bin ich gefolgt, verschiende Installationsversuche via Debian Package, via git clone, verschiedene ebusd Versionen probiert....Zugriffsrechte geprüft etc.
FHEM meldet folgendes zurück:
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 23
reconnects: 0
masters: 3
messages: 211
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Kann mir jemand mit diesen Informationen schon auf die Sprünge helfen?
DANKE!
Hallo Oldbeo,
wir scheinen eine ähnliche Konfiguration zu haben. Mir hat der Rat von Sven77 geholfen:
Nimm die komplette Konfiguration von der genannten Quelle, vor allem die "_templates.csv", dann sollte es passen!
dazu habe ich den gesamten Inhalt von /etc/ebusd gelöscht und die Dateien aus github heruntergeladen und ausgepackt.
insbesondere die Dateit /etc/ebusd_template.csv ist hier offensichtlich sehr wichtig.
Ich habe allerdings die Version 3.0 installiert. Sollte aber nicht daran liegen.
Versuche es mal mit:
sudo wget https://raw.githubusercontent.com/john30/ebusd-configuration/master/ebusd-2.1.x/de/_templates.csv -O /etc/ebusd/vaillant/_templates.csv
ebusctl reload
Gruß,
DIetmar
Hallo Dietmar,
vielen Dank!
Vermutlich war ich denkbar umständlich unterwegs, doch nach einem Git Clone der ebusd-configuration und verschieben der files in die /etc/ebusd direkt auf dem Raspi hat es dann endlich geklappt:
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 41
reconnects: 0
masters: 3
messages: 555
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Best Grüsse!
Guten Tag ,
kann mir jemand vielleicht weiterhelfen .
Ich habe eine Vaillant VSC s 196-4-5 190 mit Produktcode 0010015611 mit solarkollektoren.
Nach ebusctl Info bekomme ich dieses angezeigt:
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 42
reconnects: 0
masters: 4
messages: 26
conditional: 0
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=VMS01;SW=0112;HW=0303"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ed: slave, scanned "MF=Vaillant;ID=VMS01;SW=0112;HW=0303"
und nach scan result :
06;Vaillant;VMS01;0112;0303;??;??;??;??????????;????;??????;??
08;Vaillant;BAI00;0116;9602;21;14;27;0010015611;3100;005150;N7
15;Vaillant;47000;0420;1403;21;14;23;0020171280;0082;020901;N1
ed;Vaillant;VMS01;0112;0303;??;??;??;??????????;????;??????;??
hat da zufällig einer eine Idee was ich falsch gemacht habe.
Mfg Volker
Hallo Volker,
bin auch erst seit kurzem bei dem ebusd dabei. Die ?? gibt es bei mir auch.
05;Vaillant;COM00;0704;3103;21;15;31;0020197145;0933;008925;N7
08;Vaillant;BAI00;0203;9102;21;15;34;0010014919;0001;005230;N0
15;Vaillant;70000;0110;2103;21;15;33;0020171314;0082;019028;N4
35;Vaillant;VR_91;0104;1903;21;15;33;0020171333;0082;005289;N8
52;Vaillant;VR_70;0109;2903;??;??;??;??????????;????;??????;?4
Denk das ist nicht so schlimm. Für mich sieht das so aus, als wenn die Versionen nicht übertragen werden.
Wichtiger ist wohl die Frage, warum die 15.470.csv nicht geladen wird. Liegt diese den im vaillant ordner?
mach doch mal ein grep 15.470.csv /var/log/ebusd.log
Gruß,
Dietmar
Hallo,
kleiner Nachtrag. Ich habe noch eine kleine Änderung an meiner Verdrahtung des Raspi gemacht. Dabei habe ich den Raspi vorher nicht ordnungsgemäß runtergefahren.
Danach wurden die CSV nicht mehr geladen. Neustart des Dienstes und des Raspi brachten nichts. Danach den Inhalt des Ordners /etc/ebusd gelöscht und die Originaldateien von John eingespielt. Da lief es wieder.
Gruß,
Dietmar
Mein Vaillant Regler VRS 620 ist
nicht per ebus mit meiner Therme ecoTec plus VC DE 196/3-5 verbunden. Das ist im verbauten Hydraulikschema begründet. Sollwert bezieht die Therme über die 7-8-9 Verbindung.
Meine Idee war nun, sowohl den Regler als auch die Therme über eine eigene ebusd Instanz auszulesen.
Beim Regler klappt es gut. Es ist eine Menge Aktivität auf der Schnittstelle.
Von der Therme bekomme ich allerdings nur die<aa> beim raw logging. Per Scan wird das Gerät gefunden, aber es scheint keine Messages auf den Bus abzusetzen. Kann das jemand bestätigen?
Zitat von: john30 am 17 April 2017, 21:51:11
Wie gesagt, das sind von der Natur her eigentlich Write Messages, deshalb kann man die auch nicht mittels "ebusctl read" so einfach auslesen.
Ich schätze, was Du möchtest, ist, dass ebusd die von anderen Teilnehmern versendeten Write Nachrichten nur mitliest, damit Du sehen kannst, was damit transportiert wurde, richtig?
Dann musst Du den Typ entweder auf "uw" (sog. Update Write bzw. eigentlich Passive Write) setzen oder darum ergänzen (dann könntest Du auch selbst mit ebusd die Nachricht als Write verschicken).
Hallo John,
ich wollte noch eine kurze Rückmeldung geben. Ja, ich möchte "nur" auf
alle verfügbaren Daten zugreifen können. Die mir wichtigsten Daten werden ausgelesen und in eine Datenbank geschrieben.
Ich bekomme leider von meiner Frau nicht so viel Freizeit wie ich gerne hätte. ;) Ich habe gestern abend ein Update auf die Version 2.4 ausgeführt und Änderungen an den csv's gemacht. Jetzt läuft alles wie ich es möchte. Was es genau war kann ich nicht sagen, ich habe beides gleichzeitig durchgeführt.
Mir fehlt nur noch die Übersetzung für den Befehl 5023. Da findet man aber keine weiteren Info's zu, und ich kann bei den zyklisch wechselnden Telegrammen keine Zusammenhänge erkennen.
An dieser Stelle noch einmal vielen, vielen Dank für die geleistete Arbeit. Ich habe meine csv's mal angehängt für die, die eine Wolf R2 haben.
Beste Grüße
Binnesmann
Hallo zusammen,
ich bin gerade dabei, meine Heizung über FHEM zu steuern. Dank der vielen tollen Infos und Tips hier im Forum bin ich (für meine Amateur-Verhältnisse) schon recht weit gekommen. Der EBUS-Koppler läuft und ich haberbereits in FHEM die ersten Werte dargestellt. Jetzt wollte ich mich an die Heizkurve machen wie im EBUS-FHEMWiki beschrieben. Leider wird das Schreiben über TimeOut abgebrochen:
2017.04.27 22:12:09 1: PERL WARNING: Use of uninitialized value $ecmd in concatenation (.) or string at ./FHEM/67_ECMDDevice.pm line 60.
2017.04.27 22:12:09 1: PERL WARNING: Use of uninitialized value $cmd in substitution (s///) at fhem.pl line 993.
2017.04.27 22:12:09 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at fhem.pl line 1020.
2017.04.27 22:12:12 2: EBUS: first attempt to read timed out, trying to close and open the device.
2017.04.27 22:12:12 3: Opening EBUS device 192.168.178.40:8888
2017.04.27 22:12:12 3: EBUS device opened
2017.04.27 22:12:15 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2017.04.27 22:12:15 1: EBUS: no answer received (wrote 0.85 (\060\056\070\065), expected .*\n\n)
2017.04.27 22:12:15 3: get HeizkurveSchreiben HeizkurveSchreiben : HeizkurveSchreiben
2017.04.27 22:12:15 3: HeizkurveSchreiben_Click return value: HeizkurveSchreiben
Konfiguriert habe ich wie folgt (Fhem.cfg)
define HeizkurveEinstellen dummy
attr HeizkurveEinstellen group Heizkurve_Einstellen
attr HeizkurveEinstellen icon temp_control
attr HeizkurveEinstellen room Vaillant
attr HeizkurveEinstellen setList state:0.60,0.65,0.70,0.75,0.80,0.85,0.90,0.95,1.00,1.05,1.10,1.15,1.20,1.25,1.30
attr HeizkurveEinstellen webCmd state
define HeizkurveSchreiben_Click notify HeizkurveEinstellen {\
fhem("get HeizkurveSchreiben HeizkurveSchreiben");;\
}
attr HeizkurveSchreiben_Click group heatingControl
attr HeizkurveSchreiben_Click room Vaillant
define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
attr HeizkurveSchreiben group Heizkurve_Einstellen
attr HeizkurveSchreiben room Vaillant
und bai00.cfg
# Heizkurve lesen
get HKurve cmd {"r -f Hc1HeatCurve\n"}
get HKurve expect ".*\n*"
get HKurve postproc { sprintf("%3.2f",$_) }
#
# HeizkurveSchreiben Calormatic 470, bai00.cfg
get HeizkurveSchreiben cmd {"write -c 470#install Hc1HeatCurve".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_}
über cmd
ebusctl w -c 470#install Hc1HeatCurve 0.8
kann ich die Heizkurve verstellen. Wird mit done quittiert. Hat einer von euch eine Idee, was ich falsch mache? Würde mich sehr über Hilfe freuen!
da kommt done also expect ist schon mal falsch. Wie soll die Parameterübergabe funktionieren?
Ändere das Muster ab.
# Ferientemperatur
get T.Ferien cmd {"r RoomTempHoliday\n"}
get T.Ferien expect ".*\n\n"
get T.Ferien postproc { sprintf("%.1f",$_) }
set T.Ferien cmd { "w -c ui RoomTempHoliday %temp\n" }
set T.Ferien params temp
set T.Ferien expect "done\n"
set T.Ferien postproc {if ($_ =~ "done") {"%temp"} else {$_}}
Prüfe ob HeizkurveEinstellen nur ein Feld beinhaltet.
Hallo zusammen,
vielen Dank für die Tips! ich habe es jetzt hinbekommen. Heizkurve lässt sich verstellen und es kommt auch der Notify "done". :)
Was habe ich gemacht:
Ich hatte zuerst die Ansätze von jkriegl probiert, aber das ändert das eigentliche Fehlersymptom nicht ab. Parallel hatte ich john30 angeschrieben, weil ich noch andere Fragen hatte. Er hat mir dann den entscheidenden Tip gegeben. Die csv hatten einen Accesslevel, damit man die "riskanten" Größen nicht einfach so verstellen kann. Durch Modifikation der csv habe ich dann das Schreiben in FHEM erfolgreich hinbekommen,
@john30: Darf ich deinen Workaround hier so posten?
Grüße
Sebastian
Zitat von: heinkalot am 03 Mai 2017, 19:00:46
@john30: Darf ich deinen Workaround hier so posten?
kannst schon machen, aber das ist eigentlich nicht "der richtige" Weg. Besser wäre es, dem Aufrufer den Access Level beizubringen, damit eben nicht jede beliebige Nachricht ohne entsprechende Rechte verschickt werden kann.
Nochmal der Kontext für alle:
Vor kurzem habe ich ebusd durch Einführung von ACL etwas mehr Sicherheit beigebracht und insofern benötigt man nun zum Senden von Nachrichten mit einem definierten Access Level die entsprechenden Rechte.
Das lässt sich durch ein ACL File und Authentifizierung in der TCP Verbindung lösen oder indem man ebusd beim Starten den default Level anhebt.
Letzteres geht durch Anhängen von "--accesslevel=LEVEL" an die ebusd Startparameter (also z.B. "--accesslevel=install" für Installateur oder "--accesslevel=*" zum Ignorieren der Levels). Siehe dazu auch das Wiki zum Startparameter (https://github.com/john30/ebusd/wiki/2.-Run#daemon-options) und zum neuen auth Kommando (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#auth).
Wem das zu kompliziert ist (ist es ja eigentlich nicht wirklich), der kann alternativ auch einfach in den CSVs den Access Level rausoperieren (i.d.R. durch Ersetzen von "wi" oder "ws" in der ersten Spalte durch "w").
ich habe derzeit noch etwas Schwierigkeiten FHEM über ECMD mit dem Ebus zu verbinden.
Eingerichtet habe ich es derzeit für eine Variable wie im WIKI beschrieben und möchte es schrittweise ausbauen.
Die Anhänge zeigen das FHEM UI und einen Ausschnitt aus dem Logfile.
Es sieht so aus, als wenn sich FHEM nicht mit dem EBUS verbinden würde.
FHEM läuft auf einem Raspi mit 192.168.178.9, Ebusd läuft auf einem eigenen Raspi mit 192.168.178.11.
Beide hängen im selben Netz per LAN angebunden.
Habe ich etwas übersehen?
Den Fehler mit den drei Anführungszeichen hatte ich auch. Meine Code-Zeile sieht jetzt so aus. Damit geht es (musst nur deine IP ändern)
define EBUS ECMD telnet 192.168.178.40:8888
Grüße
Sebastian
Zitat von: heinkalot am 04 Mai 2017, 18:27:19
Den Fehler mit den drei Anführungszeichen hatte ich auch. Meine Code-Zeile sieht jetzt so aus. Damit geht es (musst nur deine IP ändern)
Genau das war es. Danke! Nun steht die Verbindung!
Kann mir jemand einen Hinweis geben wie ein Skript auszusehen hat, welches zyklisch die Parameter aus meiner Therme ausliest?
Ich habe eine Direktverbindung und der ebusd ist Master.
Ziel ist es dann die Daten in FHEM darzustellen.
Per Kommandozeile bekomme ich die Daten in die Konsole, aber wo muss dann das Skript abgelegt werden?
Für FHEM steht das ja hier sehr gut beschrieben: https://wiki.fhem.de/wiki/EBUS (https://wiki.fhem.de/wiki/EBUS)
Ich habe den Timer einfach kopiert:
# Abfrage Timersteuerung, fhem.cfg
define EBUS.Timer at +*00:15:00 get Aussentemp Aussentemp;;get Vorlauf Vorlauf;;get Ruecklauf Ruecklauf;;get PumpeWatt PumpeWatt;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get HKurve HKurve
attr EBUS.Timer group VaillantControl
attr EBUS.Timer icon time_timer
attr EBUS.Timer room Vaillant
attr EBUS.Timer verbose 0
Zitat von: heinkalot am 07 Mai 2017, 09:00:22
Für FHEM steht das ja hier sehr gut beschrieben: https://wiki.fhem.de/wiki/EBUS (https://wiki.fhem.de/wiki/EBUS)
Nach dem Schema habe ich es eingerichtet und bekomme auch einen Wert in FHEM. ( Aussentemperatur)
Mir erschliesst sich allerdings das Schema nicht ganz, wie ich die anderen Variablen auslese. Das müsste doch Copy/Paste sein, mt anderen Namen, oder?
Ich nehme an, dass das in FHEM in der *.cfg Datei beschrieben ist und dann zum Ebusd Dämon transferiert wird, oder?
Sorry für meine laienhaften Fragen, aber ich stosse des öfteren an meine Grenzen bei dem Projekt....
Nun habe ich es geschafft einige Variablen zu transferieren.
In der Datei 15.ui.csv für die Vaillant 620/3 stosse ich auf:
r,,FlowTempDesired,Vorlauftemp. SOLL,,,,"0500",,,temp,,,Ermittelte Vorlaufsolltemperatur für das System
Bei der Abfrage über die Konsole erhalte ich den Wert 0.0.
FHEM (ECMD) zeigt mir untenstehende Fehlermeldung.
Ist dies ein Fehler im .csv File?
Beim Versuch des Auslesens von FlowTempDesiredB1 erhalte ich über die Konsole ein Timeout.
Andere Werte kann ich ohne Probleme einlesen.
Hat jemand eine Idee woran das liegen könnte?
Gibt es eine Möglichkeit aus einem multiplen Datenwort einzelne Werte heraus zu filtern, z.B. aus diesem hier:
pi@raspberrypi:~ $ ebusctl r -f status0a
38.69;open;on;off;40
Wie müsste dann in ECMD der entsprechende Block in der *.cfg aussehen ?
ja!
pi@raspberrypi ~ $ ebusctl r -m 10 status01
37.0;37.0;9.062;32.0;35.0;off
pi@raspberrypi ~ $ ebusctl r -m 10 status01 temp1.0
37.0
pi@raspberrypi ~ $ ebusctl r -m 10 status01 temp1.1
37.0
pi@raspberrypi ~ $ ebusctl r -m 10 status01 temp1.2
32.0
pi@raspberrypi ~ $ ebusctl r -m 10 status01 temp1.3
35.0
LG
bezogen auf mein Register:
pi@raspberrypi:~ $ ebusctl r -m 10 status0a temp1.0
ERR: element not found in decode
Wobei:
pi@raspberrypi:~ $ ebusctl r -m 10 status0a
36.44;open;on;off;41
Das temp1.0 beschreibt die erste Variable der Antwort, aber wie muss es bei mir heissen?
Eigentlich doch ebenso, oder?
ich weis leider nicht in welcher CSV du den status0a definiert hast, da steht drinnen um welchen Variablentyp es sich handelt.
Bei meinem Beispiel war es in der hcmode.inc die temp1, wie du siehst gibt es hier 4 Positionen. Die 3. Position Außentemperatur wäre temp2
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,B511,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
das löst du wie folgt :
1.Pos = temp1.0
2.Pos = temp1.1
3.Pos = temp2.0
4.Pos = temp1.2
5.pos = temp1.3
6.pos = pumpstate
wenn es davon nur einen Typ im String gibt dann kannst die Zahl dahinter weglassen, also temp2.0 = temp2
Aber es können nicht allzuviel sein, hier die möglichen
temp,D2C,,°C,Temperatur
temp0,UCH,,°C,Temperatur
temp1,D1C,,°C,Temperatur
temp2,D2B,,°C,Temperatur
LG
Zitat von: Reinhart am 09 Mai 2017, 19:02:51
ich weis leider nicht in welcher CSV du den status0a definiert hast, da steht drinnen um welchen Variablentyp es sich handelt.
Ich habe alle geladenen csv`s durchgesehen, aber das Datenwort nicht gefunden.
Bin durch GAEBUS darauf gestossen. Lt. diesem Modul wird es mit r-mc geladen.
Hier habe ich nur 50.solsy.mc.csv in das Verzeichnis kopiert , aber darin finde ich es nicht. Gibt es einen ebusd Befehl, der mir sagt worin es steckt?
probiere mal
ebusctl find -d
bzw genauer
ebusctl find -d status
Aber du brauchst ja nur die 4 Möglichkeiten durchtesten, temp, temp0, temp1, temp2
LG
OK, gefunden.
Status0a ist in der Datei mcmode.inc
Lädt ebusd die zuzüglich zu den angezeigten mit ebusctl info ?
Sieht so aus:
r,,Status0a,Status Vorlauf Ist/Mixer/Pumpe/Vorlauf Soll,,,,0A,,,temp:flowtemp;mixer;onoff:pump;onoff;temp0:flowtempdesired
Zitat von: Reinhart am 09 Mai 2017, 21:21:56
probiere mal
ebusctl find -d
Liefert mir das
pi@raspberrypi:~ $ ebusctl find -d
broadcast datetime = 8.625;21:23:02;09.05.2017
broadcast hwcStatus = off;41;off
broadcast outsidetemp = 8.625
broadcast vdatetime = 21:23:02;09.05.2017
cc Mode = 20;off;02;off
cc Status = 0;off;-;0
cc Timer.Monday = 00:00;-:-;-:-;-:-;-:-;-:-;Mo-So
hc DateTime = valid;21:23:51;09.05.2017;8.625
hc FlowTempDesired = 0.0
hc FlowTempMax = 90
hc FlowTempMin = 15
hc HcFlowIncrease = 0
hc HydraulicScheme = 6
hc OutsideTemp = 8.62;ok
hc SumFlowSensor = 41.19;ok
hc TempDesired = 57.0
hwc Mode = 57;off;02;off
hwc Status = 0;off;-;0
hwc Timer.Wednesday = 00:00;-:-;-:-;-:-;-:-;-:-;Mo-So
mc FlowTemp = 39.94;ok
mc FlowTempDesired = 0.0
mc FlowTempMax = 90
mc FlowTempMin = 15
mc Mode = 24;auto;0;0;auto;mixer;day
mc Params = 24;19;0.80;mixer;14;0;25;55;0
mc Status = 41;off;39.94;24
mc Status0a = 39.94;open;on;off;41
mc StatYearOfInstallation = 50
mc TempDesired = 57.0
mc Timer.Friday = 00:00;-:-;-:-;-:-;-:-;-:-;Mo-So
mc Timer.Monday = 00:00;-:-;-:-;-:-;-:-;-:-;Mo-So
sc SolEnableDiffTemp1 = 5
sc Storage1Sensor3 = 41.00;ok
scan.15 = Vaillant;UI ;0324;6201
scan.23 = Vaillant;SOLSY;0306;6301
scan.25 = Vaillant;SOLSY;0306;6301
scan.26 = Vaillant;SOLSY;0306;6301
scan.44 = Vaillant;SOLSY;0306;6301
scan.50 = Vaillant;SOLSY;0306;6301
scan.ec = Vaillant;SOLSY;0306;6301
ui OutsideTemp = 8.62;ok
und was zeigt dir jetzt das
ebusctl r -f status0a temp
LG
Zitat von: Reinhart am 09 Mai 2017, 21:31:55
und was zeigt dir jetzt das
ebusctl r -f status0a temp
pi@raspberrypi:~ $ ebusctl r -f status0a temp
ERR: element not found in decode
pi@raspberrypi:~ $ ebusctl r -f status0a flowtemp
40.31
pi@raspberrypi:~ $ ebusctl r -f status0a temp0
ERR: element not found in decode
pi@raspberrypi:~ $ ebusctl r -f status0a flowtempdesired
42
ok, es ist flowtemp, dann hast du es extrahiert!
LG
Der Eintrag in ECMD sollte dann so sein?
# Vorlauftemperatur
get Vorlauf cmd {"r -m 10 status0a flowtemp\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
Was definiert das m 10 in der cmd Zeile?
Was das 5.1 ?
Ich habe etwas Probleme mit einem Parameter, den ich nicht in FHEM eingelesen bekomme.
csv sagt:
r,,Storage1Sensor3,SP1 Sensor,,,,"0000",,,tempsensor,,,Temperature of SP1 sensor
wenn ich mit der Konsole auslese, bekomme ich folgendes:
pi@raspberrypi:~ $ ebusctl r -f Storage1Sensor3
43.12;ok
Im *.cfg File steht:
# Temperatur Puffer an SP1
get SP1 cmd {"r -f Storage1Sensor3 tempsensor \n"}
get SP1 expect ".*\n*"
get SP1 postproc { $_ }
#
Aber in FHEM, wo ich es im ECMD eingebunden habe, steht "SP1 ERR: Element not found"
Übersehe ich hier etwas?
Zitat von: theotherhalf am 09 Mai 2017, 21:40:54
Der Eintrag in ECMD sollte dann so sein?
# Vorlauftemperatur
get Vorlauf cmd {"r -m 10 status0a flowtemp\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
Was definiert das m 10 in der cmd Zeile?
Was das 5.1 ?
ja, sollte so funktionieren.
Da eine Statusmeldung ja von selbst periodisch am eBus kommt, fragst du mit "m" nur den Buffer ab, deshalb kommt die Meldung auch sofort. Mit "f", wird die Anfrage an den eBus gesendet und somit der aktuellste Wert abgeholt.
Zur letzten Frage, was ergibt den in der Konsole:
ebusctl r -f Storage1Sensor3 tempsensorLG
Zitat von: Reinhart am 10 Mai 2017, 19:55:40
Zur letzten Frage, was ergibt den in der Konsole:
ebusctl r -f Storage1Sensor3 tempsensor
Das ergibt folgendes:
pi@raspberrypi:~ $ ebusctl r -f Storage1Sensor3 tempsensor
ERR: element not found in decode
Zitat von: theotherhalf am 10 Mai 2017, 20:15:59
Das ergibt folgendes:
pi@raspberrypi:~ $ ebusctl r -f Storage1Sensor3 tempsensor
ERR: element not found in decode
Und jetzt mit:
pi@raspberrypi:~ $ ebusctl r -f Storage1Sensor3 temp
41.19Scheint also ein Fehler in der .csv zu sein. temp scheint das korrekte Suffix zu sein.
Habe es im *.cfg File auf temp geändert. Aber im FHEM erscheint jetzt: SP1 ERR: element not found
Hallo,
ich möchte in FTUI den Wert Flamme anzeigen.
in der bai01.cfg steht:
Zitat
# Flammensignal
get Flamme cmd {"r -f Flame\n"}
get Flamme expect ".*\n*"
get Flamme postproc { $_ }
Ich habe im reading auch Flamme mit der Wert "on" oder "off" stehen, allerdings wird des in FTUI nicht richtig ausgewertet.
Ich nehme an, das ich bei dem Format noch ein Problem habe. Gibt es irgentwo eine Erklärung zu expect und postproc ?
Schreibe ich in das reading Flamme mit setreading "on" dann klappt es in FTUI.
Versuch es mal so:
# Flammensignal
get Flamme cmd {"r -f Flame UCH \n"}
get Flamme expect ".*\n*"
get Flamme postproc { $_ }
Klappt das?
klappt nicht, ERR: element not found in decode steht dann im reading
in der *.inc steht es so:
r,,Flame,Flammensignal,,,,"0500",,,UCH,240=off;15=on,,Flammensignal
Du hast eine Vaillant Therme, oder?
Zitat von: theotherhalf am 10 Mai 2017, 20:49:00
Versuch es mal so:
# Flammensignal
get Flamme cmd {"r -f Flame UCH \n"}
get Flamme expect ".*\n*"
get Flamme postproc { $_ }
Klappt das?
Bitte keine Leerzeichen vor dem \n, da das Linefeed ja direkt nach dem Wert kommt.
zu deiner letzten Frage:
{ sprintf("%5.1f",$_) }mit sprintf wird der Rückgabewert formatiert, "%f" = Dezimalzahl, 5= 5 stellig, .1 = ein Nachkomma
schau dazu mehr in der Perl Doc. https://perldoc.perl.org/functions/sprintf.html (https://perldoc.perl.org/functions/sprintf.html)
LG
OK.
@Reinhart, kannst du nochmals auf meinen Post von 20:36:12 eingehen?
LG
Zitat von: hanswerner1 am 10 Mai 2017, 20:42:57
Gibt es irgentwo eine Erklärung zu expect und postproc ?
mit postproc gibst du an wie formatiert werden soll (Ausgabefilter) und mit expect wie (nach was) gefiltert werden soll.
LG
Zitat von: theotherhalf am 10 Mai 2017, 21:30:38
OK.
@Reinhart, kannst du nochmals auf meinen Post von 20:36:12 eingehen?
LG
wenn du in der Konsole schon richtige Ergebnisse bekommst, dann sollte es in cfg auch funktionieren. Hast du dort eventuell auch ein Leerzeichen vor dem \? Ansonsten postproc und expect kontrollieren.
LG
dort ist es nun:
# Temperatur Puffer an SP1
get SP1 cmd {"r -f Storage1Sensor3 temp\n"}
get SP1 expect ".*\n*"
get SP1 postproc { $_ }
#
Konsole:
pi@raspberrypi:~ $ ebusctl r -f Storage1Sensor3 temp
33.81
ECMD: SP1 ERR: element not found
Im übrigen gibt GAEBUS den Wert korrekt aus.
das ist eigentlich unlogisch, wenn die direkte Abfrage in der Konsole funktioniert sollte es auch in Fhem funktionieren.
Du könntest den Loglevel auf 5 erhöhen, eine gezielte Abfrage durchführen und ins Log schauen ob nun mehr Info kommt.
LG
Zitat von: Reinhart am 10 Mai 2017, 21:18:45
zu deiner letzten Frage:
{ sprintf("%5.1f",$_) }
mit sprintf wird der Rückgabewert formatiert, "%f" = Dezimalzahl, 5= 5 stellig, .1 = ein Nachkomma
schau dazu mehr in der Perl Doc. https://perldoc.perl.org/functions/sprintf.html (https://perldoc.perl.org/functions/sprintf.html)
LG
Habs mal mit
{ sprintf("%5.1f",$_) } versucht, klappt nicht. Habs auch mal mit
{ sprintf("%s",$_) } versucht, klappt auch nicht. Wenn ich mit setreading den Wert von "Flamme" reading auf off oder on setzten klappt es. Sobald der ebus abgefragt wird und das off / on vom bus kommt klappt es nicht mehr. Im reading ist nichts zu erkennen, beides mal seht on oder off drin.
Zitat von: Reinhart am 11 Mai 2017, 19:08:16
Du könntest den Loglevel auf 5 erhöhen, eine gezielte Abfrage durchführen und ins Log schauen ob nun mehr Info kommt.
hab den Loglevel (verbose) auf 5 erhöht aber das brachte auch keine Änderung. Was bewirkt das denn?
Sieht bei mir auf der Konsole aus als wären da 2 NlL
Meine cfg ist fast 2 Jahre alt (ohne temp, noch mit split) und da habe ich bei StorageSensor3
get P.Temp expect ".*\n\n"
und das funktioniert.
Ein Beispiel mit Parameter ("no data stored" ist noch nie aufgetreten)
# Therme Temp
get T.Temp cmd {"read -f -c bai FlowTemp temp\n"}
get T.Temp expect ".*\n\n"
get T.Temp postproc { my $rval;\
if(($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
}else{\
$rval=sprintf("%.1f",$_);\
}\
$rval; }
Zitat von: theotherhalf am 12 Mai 2017, 09:32:42
hab den Loglevel (verbose) auf 5 erhöht aber das brachte auch keine Änderung. Was bewirkt das denn?
damit du im Fhem Log mehr Meldungen bekommst, die vielleicht auf den Fehler besser hindeuten!
und mach doch einmal den Versuch und lasse bei der Abfrage das \n ganz weg, also so:
get SP1 cmd {"r -f Storage1Sensor3 temp"}LG
Zitat von: Reinhart link=topic=29737.msg634232#msg634232 date=1494582541
und mach doch einmal den Versuch und lasse bei der Abfrage das \n ganz weg, also so:
code]get SP1 cmd {"r -f Storage1Sensor3 temp"}[/code]
Ändere ich den Loglevel auf ändert sich nicht viel, die Meldung im Log ist diese:
2017-05-12 12:17:10 ECMD EBUS FAILED
2017-05-12 12:17:13 ECMD EBUS DISCONNECTED
2017-05-12 12:17:13 ECMDDevice SP1 SP1: ERR: element not found
2017-05-12 12:17:13 ECMDDevice SP1 SP1 ERR: element not found
Alle anderen Variablen kommen korrekt.
Lösche ich das \n aus dem Befehl, so kommt auch die nächste Variable im Skript nicht mehr....
Zitat von: theotherhalf am 12 Mai 2017, 12:19:57
Ändere ich den Loglevel 5 auf ändert sich nicht viel, die Meldung im Log ist diese:
2017-05-12 12:17:10 ECMD EBUS FAILED
2017-05-12 12:17:13 ECMD EBUS DISCONNECTED
2017-05-12 12:17:13 ECMDDevice SP1 SP1: ERR: element not found
2017-05-12 12:17:13 ECMDDevice SP1 SP1 ERR: element not found
Alle anderen Variablen kommen korrekt.
Lösche ich das \n aus dem Befehl, so kommt auch die nächste Variable im Skript nicht mehr....
wenn du über ECMD eine Abfrage startest, dann chrashed der eBus und disconnected sich! Das darf nicht passieren und habe ich so auch noch nicht gesehen.
Warum hier so krasse Unterschiede des Verhaltens und der Ergebnisse sind, kann uns wohl nur John erklären. Ein normales ebusctl Kommando bringt in der Konsole tadellose Ergebnisse, aber über ECMD gibt es einen Crash. GAEBUS funktioniert ebenfalls problemlos. Ich kann da leider nichts testen, weil ich so ein Gerät nicht habe.
LG
Reinhart, danke dir erst einmal!
@John, falls du hier noch mitliest, hast du eine Idee woran das liegen könnte?
Zitat von: theotherhalf am 12 Mai 2017, 22:23:59
@John, falls du hier noch mitliest, hast du eine Idee woran das liegen könnte?
nö, könnte jetzt spontan nicht sagen, woran das liegt. lass mir doch mal deine ecmd definitionen zukommen, dann schau ichs mir mal an
Zitat von: john30 am 13 Mai 2017, 07:39:40
nö, könnte jetzt spontan nicht sagen, woran das liegt. lass mir doch mal deine ecmd definitionen zukommen, dann schau ichs mir mal an
Hallo John, hier ist die in Betrieb befindliche *.cfg aus /opt/fhem/FHEM/. :
#
#!/usr/bin/perl
# Aussentemperatur
get Aussentemperatur cmd {"r -f outsidetemp temp\n"}
get Aussentemperatur expect ".*\n*"
get Aussentemperatur postproc { $_ }
#
# Vorlauftemperatur vom Puffer zum Mischkreis
get Vorlauf_vom_Puffer cmd {"r -f SumFlowSensor temp\n"}
get Vorlauf_vom_Puffer expect ".*\n*"
get Vorlauf_vom_Puffer postproc { $_ }
#
# Vorlaufisttemperatur Mischkreis
get VorlaufIst_Mischkreis cmd {"r -f status0a flowtemp \n"}
get VorlaufIst_Mischkreis expect "\d+\.\d+\n\n"
get VorlaufIst_Mischkreis postproc { sprintf("%5.1f",$_) }
#
# Vorlaufsolltemperatur Mischkreisget VorlaufIst_Mischkreis cmd {"r -f status0a flowtemp \n"}
get VorlaufIst_Mischkreis expect "\d+\.\d+\n\n"
get VorlaufIst_Mischkreis postproc { sprintf("%5.1f",$_) }
#
# Vorlaufsolltemperatur Mischkreis
get VorlaufSoll_Mischkreis cmd {"r -f status0a flowtempdesired \n"}
get VorlaufSoll_Mischkreis expect "\d+\.\d+\n\n"
get VorlaufSoll_Mischkreis postproc { sprintf("%5.1f",$_) }
#
# Temperatur Puffer an SP1
get SP1 cmd {"r -f Storage1Sensor3 temp\n"}
get SP1 expect ".*\n*"
get SP1 postproc { $_ }
#
# Status Pumpe Mischkreisget Pumpe_Mischkreis cmd {"r -f status0a pump \n"}
get Pumpe_Mischkreis expect ".*\n*"
get Pumpe_Mischkreis postproc { $_ }
#
# Status Pufferbefüllung
get Speicherbefuellung cmd {"r -f isinstoragefilling yesno \n"}
get Speicherbefuellung expect ".*\n*"
get Speicherbefuellung postproc { $_ }
#
# Heizkurve Mischkreis Gain
get Heizkurve_Gain cmd {"r -f params curve \n"}
get Heizkurve_Gain expect "\d+\.\d+\n\n"
get Heizkurve_Gain postproc { sprintf("%5.1f",$_) }
#
# Abschalttemperatur MK1
get Abschalttemperatur_MK1 cmd {"r -f params shutdowntemp \n"}
get Abschalttemperatur_MK1 expect "\d+\.\d+\n\n"
get Abschalttemperatur_MK1 postproc { sprintf("%5.1f",$_) }
#
Du hast beim expect nach dem \n einen Stern
Hast Du das funktionierende Beispiel schon versucht und beachte Grossbuchstaben
# Außentemperatur
get A.Temp cmd {"r -f OutsideTemp temp\n"}
get A.Temp expect ".*\n\n"
get A.Temp postproc { sprintf("%.1f",$_) }
Hi,
irgendwie macht ECMD neuerdings bei mir Probleme.
Wenn ich mehrere Werte (ca. 25) hintereinander auslese, funktioniert es meistens problemlos. Manchmal schreibt ECMD aber einen falschen Wert zurück. Wenn ich z.B. die Raumtemperatur auslese, steht manchmal ein anderer Temperaturwert aus einem anderen Auslesevorgang drin.
Zudem hab ich beobachtet, das FHEM während der ECMD Aufrufe komplett hängt. D.h. erst wenn alle 25 Abfragen durch sind, reagiert FHEM wieder normal.
Habt ihr schon ähnliches beobachtet?
Ich überlege, ob ich auf MQTT umsteigen soll, um das ganze etwas zu entkoppeln?!
VG Texel
Zitat von: jkriegl am 14 Mai 2017, 12:52:41
Du hast beim expect nach dem \n einen Stern
Hast Du das funktionierende Beispiel schon versucht und beachte Grossbuchstaben
# Außentemperatur
get A.Temp cmd {"r -f OutsideTemp temp\n"}
get A.Temp expect ".*\n\n"
get A.Temp postproc { sprintf("%.1f",$_) }
Die Definitionen habe ich aus dem WIKI.
Alle im *.cfg definierten Skript kommen korrekt an, ausser SP1. Auch "OutsideTemp", obwohl meine Abfrage anders aussieht.
Gross- und Kleinschreibung habe ich schon versucht zu ändern, aber das hat scheinbar keinen Einfluss, auch nicht, wenn man mit dem Terminal die Werte ausliest.
Hi,
was kommt denn raus, wenn Du im Ebusctl
r -f OutsideTemp temp
eingibst ? Wenn da nichts sinniges raus kommt, dann ist möglicherweise da schon der Bug drin...
Grüße
Christian
Zitat von: cs-online am 16 Mai 2017, 12:25:13
Hi,
was kommt denn raus, wenn Du im Ebusctl
r -f OutsideTemp temp
eingibst ? Wenn da nichts sinniges raus kommt, dann ist möglicherweise da schon der Bug drin...
Das funktioniert ja soweit alles:
pi@raspberrypi:~ $ ebusctl r -f OutsideTemp temp
22.62
Mit der Konsole gibt es keinerlei Probleme. Ich kann alles einlesen.
Lediglich die Variable SP1 (die ich über die Konsole problemlos lesen kann) kommt im ECMD nicht an.
Die "*" habe ich mittlerweile entfernt. Den SP1 mal umbenannt in SPT1 aber mit gleichem Ergebnis.
Skript nun wie folgt:
# Aussentemperatur
get Aussentemperatur cmd {"r -f outsidetemp temp\n"}
get Aussentemperatur expect ".*\n"
get Aussentemperatur postproc { $_ }
#
# Vorlauftemperatur vom Puffer zum Mischkreis
get Vorlauf_vom_Puffer cmd {"r -f SumFlowSensor temp\n"}
get Vorlauf_vom_Puffer expect ".*\n"
get Vorlauf_vom_Puffer postproc { $_ }
#
# Vorlaufisttemperatur Mischkreis
get VorlaufIst_Mischkreis cmd {"r -f status0a flowtemp \n"}
get VorlaufIst_Mischkreis expect "\d+\.\d+\n\n"
get VorlaufIst_Mischkreis postproc { sprintf("%5.1f",$_) }
#
# Vorlaufsolltemperatur Mischkreis
get VorlaufSoll_Mischkreis cmd {"r -f status0a flowtempdesired \n"}
get VorlaufSoll_Mischkreis expect "\d+\.\d+\n\n"
get VorlaufSoll_Mischkreis postproc { sprintf("%5.1f",$_) }
#
# Status Pumpe Mischkreis
get Pumpe_Mischkreis cmd {"r -f status0a pump\n"}
get Pumpe_Mischkreis expect ".*\n"
get Pumpe_Mischkreis postproc { $_ }
#
# Status Pufferbefüllung
get Speicherbefuellung cmd {"r -f isinstoragefilling yesno\n"}
get Speicherbefuellung expect ".*\n"
get Speicherbefuellung postproc { $_ }# Heizkurve Mischkreis Gain
#
# Status Heizkurve Gain
get Heizkurve_Gain cmd {"r -f params curve \n"}
get Heizkurve_Gain expect "\d+\.\d+\n\n"
get Heizkurve_Gain postproc { sprintf("%5.1f",$_) }
#
# Abschalttemperatur MK1
get Abschalttemperatur_MK1 cmd {"r -f params shutdowntemp \n"}
get Abschalttemperatur_MK1 expect "\d+\.\d+\n\n"
get Abschalttemperatur_MK1 postproc { sprintf("%5.1f",$_) }
#
# Status SP1 Speicherfühler maxmax
get SPT1 cmd {"r -f Storage1Sensor3 tempsensor\n"}
get SPT1 expect ".*\n"
get SPT1 postproc { $_ }
#
der Grund warum du keinen Wert bekommst ist ja schon bekannt, wieso wissen wir nicht!
Da bei jeder Abfrage via ECMD von SP1 sich der Ebus disconected und das nur bei diesem einem Wert ist, würde ich den Weg des geringsten Widerstandes gehen und diesen einen Wert mit dem GAEBUS holen. Du kannst auch alle mit dem GAEBUS holen, es spricht ja nichts dagegen und wenn in Fhem die Messwerte eintrudeln fragt ja keiner wie die Werte abgeholt wurden.
Es kann viele Ursachen haben, zB. unsichtbare Steuerzeichen in der Config oder Zeit Kollisionen. Eventuell antwortet zeitgleich ein anderes Gerät?
Ich versuche meist bei Fehlern auch die Ursache zu finden und zu beheben, aber wenn dich dieser Fehler schon solange nervt dann geh doch den einfacheren Weg, zum Ergebnis kommst ja zum Glück noch über andere Wege.
LG
... interessanter Gedanke, daß es evtl. am Timing liegt. Müßte man doch ausprobieren können, indem man das -f (für force, also zwingen neuen Wert zu holen) wegläßt, dann würde ja aus dem Cache versorgt und nicht neu vom Bus gelesen oder ?
Grüße
Christian
Wenn ich an der Konsole Dein
ebusctl r -f Storage1Sensor3 tempsensor
eingebe kommt ERR: element not found in decode
Aber es funktiniert: ebusctl r -f Storage1Sensor3 temp
83.62
Zitat von: jkriegl am 17 Mai 2017, 13:48:58
Wenn ich an der Konsole Dein
ebusctl r -f Storage1Sensor3 tempsensor
eingebe kommt ERR: element not found in decode
Aber es funktiniert: ebusctl r -f Storage1Sensor3 temp
83.62
Ja, du hast Recht. "tempsensor" steht im *.csv, ist aber falsch. Nachdem ich das heraus gefunden habe, dachte ich die Ursache gefunden zu haben.
Mit "temp" habe ich es aber im Skript auch schon probiert, aber es funktioniert auch nicht.
Mit der Konsole sehe ich das gleiche wie du.
Der Thread ist mittlerweile schon recht lang, ich glaube ich werde es wie von Reinhart vorgschlagen belassen und den SP1 per GAEBUS auslesen, das klappt ja.
Einheitlich alles über ECMD wäre mir lieber gewesen, aber es scheint nicht zu klappen.
Was passiert bei dir wenn du den Block :
# Status SP1 Speicherfühler maxmax
get SP1 cmd {"r -f Storage1Sensor3 temp\n"}
get SP1 expect ".*\n"
get SP1 postproc { $_ }
#über ECMD einliest?
Kommt dann der Wert korrekt?
ebusctl f -f Storage1Sensor3
sagt Dir was letztendlich definiert ist.
schau Dir meine Empfelungen zu expect an. \n\n hattest Du doch schon mal.
Zitat von: theotherhalf am 17 Mai 2017, 15:59:55
# Status SP1 Speicherfühler maxmax
get SP1 cmd {"r -f Storage1Sensor3 temp\n"}
get SP1 expect ".*\n"
get SP1 postproc { $_ }
#
Damit sollte es eigentlich funktionieren. Steht im fhem Log irgendeine Fehlermeldung?
Für alle, die nach einem Linux Update Probleme mit Schreiben auf dem Bus haben, dürfte die Verwendung von /sbin/setserial /dev/ttyUSB0 low_latency die Lösung sein (Dabei "/dev/ttyUSB0" durch das entsprechende Device ersetzen).
EDIT: /bin/setserial
Hallo,
ich versuche gerade die ganze Thematik mit dem bus und der Heizungssteuerung zu verstehen ...
Nun leider habe ich noch eine grundsätzliche Frage, was ich noch nicht wirklich bei dem komplexen Thema verstanden habe.
Ich versuche jetzt mal das allgemeine Vorgehen mal mit einfachen Worten "runter zu brechen":
1. Ich besorge mir eine Platine mit Bauteilen, löte diese zusammen
2. Besorge mir FTDI Adapter FT232RL USB zu TTL Serial und verbinden diesen mit der Platine (dieser wird an Platine gelötete ?)
3. Verbinde den fertigen eBus "Adapter" mit dem Colormatic (Colormatic ist mit dem Heizkessel verbunden und vom Colormatic 470 dann an den eBus ?)
- Hier muss ich mal schauen welche Anschlüsse überhaupt am Colormatic sind und mit welchem Kabel und Anschluss Colormatic mit dem Kessel verbunden ist)
4. Besorge mir Raspi und installiere Debian und Bus Software (ebusd)
5. Verbinde den FTDI Adapter per USB mit dem Raspberry
6. Justiere mit Hilfe von Kommandozeilen am Raps den Poti (Keine separate Stromversorgung notwenig ??? Strom bekommt alles über Raspi ?)
7. Verbinde den Raspi per Lan mit meinem Netzwerk ???
8. Hole mir die Daten über FHEM (ECMD Devices anlegen etc.) (separater Raspi) per Telnet ??
Ist es das vereinfacht gesagt ? Ist dies Grundsätzlich so Richtig ?
Ich hoffe dies allgemeine Anfängerfrage ist jetzt hier im Thread passend ! :(
Nur brauche ich für mich immer erstmal eine einfache Übersicht um den Grundsatz zu verstehen.
Grüße & Danke
Torsten
Hi Torsten,
ja, prinzipiell so richtig. Den zweiten Raspi in Schritt 8 könntest Du Dir sparen, das passt schon noch alles auf einen. :-)
Wenn Dir SSOP nicht zu klein zum Löten ist, könntest Du auch bei Helmut H. (https://www.mikrocontroller.net/topic/346833#4995024) eine Platine mit USB-Anschluss bestellen und Schritt 2 weglassen. Diese hat eigentlich "nur" den Nachteil, dass am eBus-Anschluss kein Gleichrichter hängt, also auf Polarität geachtet werden muss - bin aber nicht sicher, bei welchen Platinen das überhaupt berücksichtigt wurde.
Wo genau steckt bei Dir die Calormatic? Wenn außerhalb des Heizkessels, muss ja schon eine Zweidrahtleitung zwischen beiden bestehen, die zapfst Du einfach an. Wenn im Kesselgehäuse, dann suche mal in den Unterlagen des Kessels, der muss auch anderswo einen Busanschluss haben.
Notfalls nimmt man einen RJ10-Stecker für die Diagnosebuchse der Calormatic, aber das sieht auf Dauer nicht schön aus und je nach Einbaulage ist diese auch nicht unbedingt zugänglich.
Sven
Zitat von: TottiToad am 29 Mai 2017, 22:43:18
1. Ich besorge mir eine Platine mit Bauteilen, löte diese zusammen
2. Besorge mir FTDI Adapter FT232RL USB zu TTL Serial und verbinden diesen mit der Platine (dieser wird an Platine gelötete ?)
3. Verbinde den fertigen eBus "Adapter" mit dem Colormatic (Colormatic ist mit dem Heizkessel verbunden und vom Colormatic 470 dann an den eBus ?)
- Hier muss ich mal schauen welche Anschlüsse überhaupt am Colormatic sind und mit welchem Kabel und Anschluss Colormatic mit dem Kessel verbunden ist)
4. Besorge mir Raspi und installiere Debian und Bus Software (ebusd)
5. Verbinde den FTDI Adapter per USB mit dem Raspberry
6. Justiere mit Hilfe von Kommandozeilen am Raps den Poti (Keine separate Stromversorgung notwenig ??? Strom bekommt alles über Raspi ?)
7. Verbinde den Raspi per Lan mit meinem Netzwerk ???
8. Hole mir die Daten über FHEM (ECMD Devices anlegen etc.) (separater Raspi) per Telnet ??
Ist es das vereinfacht gesagt ? Ist dies Grundsätzlich so Richtig ?
ja so könnte man das zusammenfassen
Hi,
Dank euch für die Rückmeldung !
Zitat
Den zweiten Raspi in Schritt 8 könntest Du Dir sparen, das passt schon noch alles auf einen. :-)
Ja ist mir bewusst, doch der Heizkessel für die drei Wohnung steht im Keller und meine FHEM Zentrale im OG im Serverschrank.
Zitat
Wenn Dir SSOP nicht zu klein zum Löten ist, könntest Du auch bei Helmut H. eine Platine mit USB-Anschluss bestellen und Schritt 2 weglassen
Danke für die Info. Da ich beim löten zwei linke Hände habe, hoffe ich irgendwie an eine fertige Platine zu kommen ? :(
Zitat
Wo genau steckt bei Dir die Calormatic? Wenn außerhalb des Heizkessels, muss ja schon eine Zweidrahtleitung zwischen beiden bestehen, die zapfst Du einfach an. Wenn im Kesselgehäuse, dann suche mal in den Unterlagen des Kessels, der muss auch anderswo einen Busanschluss haben.
Notfalls nimmt man einen RJ10-Stecker für die Diagnosebuchse der Calormatic, aber das sieht auf Dauer nicht schön aus und je nach Einbaulage ist diese auch nicht unbedingt zugänglich.
Die Calormatic hängt im Keller über dem Heizungskessel. Diese ist mit einer Zweidrahtleitung verbunden. Bin mir nur nicht sicher ob diese an einem eBus Anschluss des Heizkessels angeschlossen ist ? Oder muss dies sein, wenn Calormatic angeschlossen ist ?
Danke & grüße
Torsten
Ja, diese Zweidrahtleitung IST der eBus! :-)
für alle, die mit Latenz Probleme hatten:
setserial wird nun nicht mehr benötigt, ebusd setzt das entsprechende Flag auf dem /dev/tty* serial device inzwischen selbst.
VG John
Hallöchen,
ich habe gerade mein Linux geupdatet und nun bekomme ich bei meinen beiden eBus-Geräten komische Fehler:
1. Gastherme: Scan-config=full ergibt immer "notify request: ERR: SYN received"
Wenn der scan nicht läuft, dann bekomme ich die Broadcast-Nachrichten wie vorher, jedoch nun nicht mehr interpretiert
2. Solar-Steuerung: Scan läuft durch, aber ein Abfragen, bzw. setzen von Werten endet in einem Timeout
Ich habe die Dateien einmal angehangen, vielleicht wird dann einiges klarer.
HW-mäßig habe ich nichts geändert, sondern nur mein Ubuntu aktualisiert und nach dem Reboot geht es nicht mehr :-(
Hilfe!!!!
Hallo,
du hast zwei Möglichkeiten:
1) ebusd zu aktualliseren - auf den tagesaktuellen Stand.
2) oder dies zu machen:
Zitat von: a200 am 28 Mai 2017, 15:54:02
Vielen Dank an John!
Funktioniert bei mir bestens! Endlich wird bei mir alles eingelesen!
bei raspi 3 wird setserial in /bin installiert es heißt also:
/bin/setserial /dev/ttyUSB0 low_latency
Unter Umständen vorher mitsudo apt-get install setserial
setserial installieren.
Viel Erfolg.
Gruß
Maik
Vielen Dank!
Das setzen des seriellen Interfaces auf Low-Latency hat es wirklich gebracht.
Keine Ahnung, warum es nach dem Update des OS nicht mehr ging.
Ich hatte gestern Abend bereits die neuesten Quellen von Git gezogen und die neueste Version (denke ich jedenfalls) kompiliert.
Nun ja, erst einmal Problem gelöst!!!!
Servus zusammen,
nach zähem Ringen steige ich so langsam in meine Vaillant flexotherm ein.
Verständnisfrage:
Zwischen dem VR700 und dem VR70 (Mischer) werden zyklisch Nachrichten ausgetauscht. Eine davon hab ich entschlüsselt.
Inhalt:
1052b5230103 0f 13 04 0b 04 02 04 34 02 12 04 32 02 c8 00 00
x x D2C, 157 Speicher oben Wasser
x x D2C, 159 Speicher oben Heizung
x x D2C, 158 Speicher unten Wasser
x x D2C, 160 Speicher unten Heizung
x x D2C, 75 Vorlauftemperatur Mischer
Wie zum Geier bringe ich die nun in eine CSV?
Mein Scan sagt:
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903"
Also habe ich in /etc/ebusd/vaillant eine Datei mit dem Nachem 52.vr70.csv angelegt.
Jetzt hänge ich - wie bringe ich der CSV syntaktisch bei, dass aus der o.g. Zeichenfolge in einem ID verschiedene Datenpunkte rauszulesen sind?
Bitte gebt mir einen Schubs...
Danke, Andi
EDIT:
Habs hinbekommen - einfach um Felder (Spalten) nach rechts erweitern...
Für alle Interessierten hier mal mein Stand der VR70 (kann kaum noch weiterentwickelt werden, weil inzwischen gegen VR71 getauscht) und VR71 (recht frühe Version aus VR70 erstellt, da aus Zeitgründen noch nichts weiter untersucht).
Hallo zusammen,
ich habe mal eine ganz blöde Frage. Ich habe mein System neu aufgesetzt mit EBUSD 3.0pre und wollte am Ende mit "service ebusd start" den Dienst starten. Das geht nur, wenn ich davor auch noch sudo schreibe. Was hätte ich anders machen müssen oder was kann ich jetzt noch machen um es als normaler User ausführen zu dürfen? Ich habe das komplette Paket runtergeladen und installiert, nicht compiliert.
Was ich möchte ist, dass nach einem Neustart der Dienst automatisch geladen wird. Oder geht das auch mit sudo?
Grüße
Binnesmann
Hallo Sven,
Zitat von: Sven77 am 19 Juli 2017, 09:51:59
Für alle Interessierten hier mal mein Stand der VR70 (kann kaum noch weiterentwickelt werden, weil inzwischen gegen VR71 getauscht) und VR71 (recht frühe Version aus VR70 erstellt, da aus Zeitgründen noch nichts weiter untersucht).
Deine VR70 Konfig ist Klasse- der Großteil der unbekannten Nachrichten ist damit bei mir verschwunden :)
Vielen Dank,
Andreas
Zitat von: Binnesmann am 27 Juli 2017, 17:03:25
Was ich möchte ist, dass nach einem Neustart der Dienst automatisch geladen wird. Oder geht das auch mit sudo?
das sollte automatisch gehen, wenn Du dem System mitteilst, dass der Dienst automatisch starten soll. Wie das geht, hängt von der Distribution ab, aber ich dachte eigentlich, dass das ebusd Startfile dafür ausreicht.
Hi John,
das Problem habe ich auch, seit ich auf Jessie bin. Kannst Du da evtl. nochmal beschreiben, was man machen muss als (halb)laie im Bereich Linux ? mit /sudo etc/init.d/ebusd start bekomme ich ihn manuell zum Laufen, aber eben nicht automatisch. Script u ter /etc/default/ebusd ist angepasst an beide Adapter...
Hallo, das Problem mit dem automatischen Starten liegt an der Umstellung der Dienste-Start-Systematik. Seit Jessie benutzt Linux den "systemd" deamon zum starten der Dienste.
Damit ebusd automatisch startet muss der Dienst einmal dem deamon bekannt gemacht werden mit "sudo systemctl enable ebusd". Dieses Kommando erzeugt die notwendigen Links in den Startverzeichnissen und sorgt dafür, das der Dienst zukünftig automatisch gestartet wird.
siehe die man-pages zu "systemctl" und hier https://www.elektronik-kompendium.de/sites/raspberry-pi/2002211.htm
Coole Info !!! Werde ich mal durchprobieren, Danke für Info und den link !!! :)
Prima, nun startet er beim booten :-) das Hardwareproblem ist auch gelöst, alles super !
Noch eine Frage: Wie kann ich ebusd dazu bringen, "scan 15" beim start auszuführen bzw. eine bestimmte (in diesem Fall die SDR für die 560er) CSV zu laden ? Mit --scanconfig dauert das ewig, bis dann tatsächlich die Dateien (da werden gleich mehrere geladen) geladen werden (vermutlich, weil die 560 selber als stand alone keinen Traffic erzeugt oder ?) ... Wenn ich "ebusctl -p 8889 scan 15" eingebe, dann wird gleich die richtige geladen (und auch nur die)...
Zitat von: cs-online am 07 August 2017, 23:32:51
Wie kann ich ebusd dazu bringen, "scan 15" beim start auszuführen bzw. eine bestimmte (in diesem Fall die SDR für die 560er) CSV zu laden ?
z.B. --scanconfig=15, siehe https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options
...manchmal ist es einfacher als man denkt ;-) Danke, das war genau was ich brauchte :-)
Ich habe immer noch Probleme mit einer Fehlermeldung beim Auslesen der Vaillant-Parameter. In der bai00.cfg steht diese Abfrage:
# Aussentemperatur
get VaillantAussentemp cmd {"r -m 10 envTemp\n"}
get VaillantAussentemp expect ".*\n\n"
get VaillantAussentemp postproc { sprintf("%5.1f",$_) }
Frage jede 5 min. mit einem at ab.
+*00:05 get VaillantAussentemp VaillantAussentemp
Das List zeigt dies:
Internals:
DEF bai00.class
IODev EBUS
NAME VaillantAussentemp
NR 1416
STATE 13.9 °C
TYPE ECMDDevice
READINGS:
2017-08-11 21:45:34 VaillantAussentemp 13.9
2017-08-11 21:45:34 state VaillantAussentemp 13.9
fhem:
classname bai00.class
cache:
specials:
%NAME VaillantAussentemp
%TYPE ECMDDevice
Attributes:
IODev EBUS
group Vaillant
room 3.4_Heizung
stateFormat {sprintf("%.1f °C",ReadingsVal("VaillantAussentemp","VaillantAussentemp",0))}
userReadings {(split ' ',ReadingsVal("VaillantAussentemp","VaillantAussentemp",0))[0]}
Im log kommt diese Fehlermeldung:
2017.08.11 21:35:33.403 1: PERL WARNING: Argument "13.94;ok\n\n" isn't numeric in sprintf at (eval 359576) line 1.
Habe im Forum gestöbert und ein Beispiel gefunden, wonach die Aussentemp. so abgefragt werden muss
# Aussentemperatur
get VaillantAussentemp cmd {"r -m 10 envTemp\n"}
get VaillantAussentemp expect "\d+\.\d+\n\n"
get VaillantAussentemp postproc { sprintf("%5.1f",$_) }
Dann erhalte ich aber diese Fehlermeldung
EBUS: unexpected answer 13.94;ok\n\n (\061\063\056\071\064\073\157\153\012\012) received (wrote r -m 10 envTemp\n (\162\040\055\155\040\061\060\040\145\156\166\124\145\155\160\012), expected \d+\.\d+\n\n)
2017.08.11 21:35:33.403 1: PERL WARNING: Argument "13.94;ok\n\n" isn't numeric in sprintf at (eval 359576) line 1.
Habe auch schon nach einem Hinweis von pah mit split (das ist das userreading) versucht, den String zu zerlegen. Hat leider mangels perl-Kenntnissen trotz Suche im Forum und Wiki nicht geklappt.
Hat jemand einen Tip? Wenn bei anderen Anlagen die Vaillant-Aussentemp. so abgefragt wird, müßte es doch auch bei meiner Anlage klappen.
LG Jürgen
Mein Tipp: "expect" komplett auf ".*\n*" setzen, dann wird erst einmal alles akzeptiert. Und doie Zerlegung dann mit regulären Ausdrücken, siehe https://regex101.com/.
Da kann man auch sehr schön sehen, dass "13.94;ok\n\n" eben nicht durch "\d+\.\d+\n\n" gematcht wird.
LG
pah
Hallo pah,
der Tip hat leider keine Änderung bewirkt.
# Aussentemperatur
get VaillantAussentemp cmd {"r -m 10 envTemp\n"}
# get VaillantAussentemp expect "\d+\.\d+\n\n"
# get VaillantAussentemp expect ".*\n\n"
# Vorschlag pah
get VaillantAussentemp expect ".*\n*"
get VaillantAussentemp postproc { sprintf("%5.1f",$_) }
Wieder dieselbe Fehlermeldung im Log
2017.08.12 14:42:33.486 1: PERL WARNING: Argument "19.00;ok\n\n" isn't numeric in sprintf at (eval 2199) line 1.
Drehe ich am völlig falschen Punkt mit der BAI00.cfg? Dachte, da dort der String generiert wird muss ich da auch entsprechend formatieren. Kann es sein, dass die Fehlermeldung erst später "innerhalb" FHEM (stateformat ...) generiert wird?
LG Jürgen
Hallo zusammen,
ich springe hier auf den Zug mit auf, da ich Probleme habe, dass der ebusd in der Konfiguration mit meiner vrc 700/4 multiMATIC hat.
Hardware Heizung + Computer:
- ecoCOMAPCT Vaillant
- Bedienteil multiMATIC vrc 700/4 Vaillant
- ebus usb Koppler esera automation
- Laptop mit Linux Debian 9 ebusd und FHEM
Das habe ich bereits getan:
- usb latency runter gesetzt
- usb koppler abgeglichen
- ebusd raw Daten angeschaut und sieht ganz gut aus
- ebsuctl scan all und ebusctl scan result
- Rechte in /etc/ebusd/ und Unterverzeichnise "rw rw r owner root:root"
- fhem server abgeschaltet --> später auto usb fhem abzustellen
Mein Problem ist, dass er die Files für
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"also die Multimatic VRC 700/4 erst gesucht hat.
Ich habe aber "ebusd-configuration 2.1.x DE" deutsch installiert gehabt. Im DEB-file fehlt übrigens "15.700.csv" nach heutigem Stand, ich habe das tgz file auch ausgepackt und gesucht und dann habe ich händisch über github "RAW-Button" das file runter geladen und installiert.
Hier ein paar Ausgaben des ebus:
ebusctl info
version: ebusd 2.4.79708d2
signal: acquired
symbol rate: 23
reconnects: 0
masters: 3
messages: 213
conditional: 3
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603"ebus.log
2017-08-12 18:22:11.158 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-08-12 18:22:20.717 [update notice] update bai Status01 QQ=10: 41.0;38.5;16.188;38.0;50.0;off
2017-08-12 18:22:20.985 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:22:30.761 [update notice] update bai Status01 QQ=10: 41.0;38.5;16.188;38.0;50.0;off
2017-08-12 18:22:31.028 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:22:40.850 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;38.0;50.0;off
2017-08-12 18:22:41.118 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:22:41.393 [update notice] update bai DateTime QQ=10: valid;17:16:35;12.08.2017;16.188
2017-08-12 18:22:41.649 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-08-12 18:22:41.884 [update notice] update broadcast vdatetime QQ=10: 17:16:34;12.08.2017
2017-08-12 18:22:42.148 [update notice] unknown MS cmd: 1008b5110100 / 088f0211001f000080
2017-08-12 18:22:42.364 [update notice] update broadcast outsidetemp QQ=10: 16.188
2017-08-12 18:22:50.930 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;50.0;off
2017-08-12 18:22:51.197 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:00.978 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;50.0;off
2017-08-12 18:23:01.245 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:11.062 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;50.0;off
2017-08-12 18:23:11.329 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:11.586 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-08-12 18:23:21.105 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;50.0;off
2017-08-12 18:23:21.372 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:31.192 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;49.5;off
2017-08-12 18:23:31.459 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:41.244 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;49.5;off
2017-08-12 18:23:41.516 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:23:41.790 [update notice] update bai DateTime QQ=10: valid;17:17:35;12.08.2017;16.188
2017-08-12 18:23:42.045 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-08-12 18:23:42.281 [update notice] update broadcast vdatetime QQ=10: 17:17:34;12.08.2017
2017-08-12 18:23:42.545 [update notice] unknown MS cmd: 1008b5110100 / 088d0211001f000080
2017-08-12 18:23:42.761 [update notice] update broadcast outsidetemp QQ=10: 16.188
2017-08-12 18:23:51.331 [update notice] update bai Status01 QQ=10: 40.5;38.5;16.188;37.5;49.5;off
2017-08-12 18:23:51.602 [update notice] update bai Mode QQ=10: standby
ebus-log start
2017-08-12 18:27:33.669 [main notice] ebusd 2.4.79708d2 started
2017-08-12 18:27:33.684 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2017-08-12 18:27:33.686 [bus notice] signal acquired
2017-08-12 18:27:42.790 [bus notice] new master 10, master count 2
2017-08-12 18:27:42.851 [bus notice] new master 03, master count 3
2017-08-12 18:27:42.851 [update notice] unknown MS cmd: 1008b5110101 / 09504c30104b620000ff
2017-08-12 18:27:43.118 [update notice] unknown MS cmd: 1008b51009000000ffffff010000 / 0101
2017-08-12 18:27:43.392 [update notice] unknown MS cmd: 1008b5040100 / 0a03372117120806173010
2017-08-12 18:27:43.649 [update notice] unknown MS cmd: 1008b5110102 / 06033c9646826e
2017-08-12 18:27:43.681 [main notice] starting initial scan for fe
2017-08-12 18:27:43.920 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2017-08-12 18:27:43.922 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2017-08-12 18:27:43.925 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0202, HW9602
2017-08-12 18:27:44.004 [bus notice] max. symbols per second: 116
2017-08-12 18:27:45.289 [main notice] found messages: 209 (3 conditional on 23 conditions, 0 poll, 8 update)
2017-08-12 18:27:45.290 [main notice] scan config 08: file vaillant/08.bai.csv loaded
2017-08-12 18:27:45.571 [update notice] update broadcast outsidetemp QQ=10: 16.188
2017-08-12 18:27:47.438 [main error] error reading scan config file /etc/ebusd/vaillant/15.700.csv for ID "70000", SW0419, HW4603: ERR: element not found
2017-08-12 18:27:52.941 [update notice] update bai Status01 QQ=10: 40.0;38.0;16.188;37.5;49.0;off
2017-08-12 18:27:53.208 [update notice] update bai Mode QQ=10: standby
2017-08-12 18:28:02.982 [update notice] update bai Status01 QQ=10: 40.0;38.0;16.188;37.5;49.0;off
2017-08-12 18:28:03.249 [update notice] update bai Mode QQ=10: standby
Und da taucht auch die Fehlermeldung auf:
[main error] error reading scan config file /etc/ebusd/vaillant/15.700.csv for ID "70000", SW0419, HW4603: ERR: element not foundDas 15.700.csv ist unter /etc/ebusd/vaillant/ abgespeichert.
Hat von euch jemand einen Tipp, wo ich noch Fehler einkreisen kann? Der ebusd scheint ja zu laufen.
Viele Grüße und vielen Dank an die Entwickler von FHEM und EBUSD sowie dies tolle Forum, wodurch ich schon einige Probleme beseitigen konnte.
Viele Grüße
Kai
Koef2
P.S.: wenn neuer Thread erforderlich ist, bitte gern verschieben ode rich beginne einen neuen
Nachtrag output "ebusd --checkconfig --scanconfig" liefert
Achtung viele Fehlermeldungungen, vermutlich falsches csv file?
2017-08-12 18:43:02.397 [main notice] ebusd 2.4.79708d2 performing configuration check...
Error reading "/etc/ebusd/vaillant/15.700.csv" line 6 field 234396 value "-26=off, when the outside temperature falls below this threshold temperature the continuous heating function is started (off <=> function is disabled)": ERR: element not found
Erroneous item is here:
r,,ContinuosHeating,Durchgehendes Heizen,,,,0200,,,tempv,,,"-26=off, when the outside temperature falls below this threshold temperature the continuous heating function is started (off <=> function is disabled)"
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 14 field 236368 value "Hysterese Speicherladung": ERR: element not found
Erroneous item is here:
r,,CylinderChargeHyst,hystCylinderCharge,,,,2700,,,calibrationv,,,Hysterese Speicherladung
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 15 field 236420 value "Speicherlad. Offset": ERR: element not found
Erroneous item is here:
r,,CylinderChargeOffset,offsetCylinderCharge,,,,2900,,,calibrationv,,,Speicherlad. Offset
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 21 field 237214 value "Wasserdruck": ERR: element not found
Erroneous item is here:
r,,WaterPressure,Wasserdruck,,,,3900,,,pressv,,,Wasserdruck
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 24 field 237750 value "maximum flow temperature setpoint of Hwc": ERR: element not found
Erroneous item is here:
r,,HwcMaxFlowTempDesired,HwcMaxFlowTempDesired,,,,4600,,,tempv,,,maximum flow temperature setpoint of Hwc
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 25 field 237746 value "Systemvorlauf": ERR: element not found
Erroneous item is here:
r,,SystemFlowTemp,Systemvorlauf,,,,4B00,,,tempv,,,Systemvorlauf
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 26 field 237748 value "": ERR: element not found
Erroneous item is here:
r,,MultiRelaySetting,Multifunktionsausgang,,,,4D00,,,mamode,,,
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 36 field 239852 value "selection which heating circuit is affected by changing parameters in the basic display": ERR: element not found
Erroneous item is here:
r,,OpModeEffect,OpModeEffect,,,,6900,,,zonesel,,,selection which heating circuit is affected by changing parameters in the basic display
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 37 field 239856 value "installer's name": ERR: element not found
Erroneous item is here:
r,,Installer1,Installationsfirma Teil 1,,,,6C00,,,shortname,,,installer's name
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 38 field 239906 value "installer's name": ERR: element not found
Erroneous item is here:
r,,Installer2,Installationsfirma Teil 2,,,,6D00,,,shortname,,,installer's name
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 39 field 239802 value "installer's telephone number": ERR: element not found
Erroneous item is here:
r,,PhoneNumber1,Telefonnummer,,,,6F00,,,shortphone,,,installer's telephone number
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 40 field 239802 value "installer's telephone number": ERR: element not found
Erroneous item is here:
r,,PhoneNumber2,Telefonnummer,,,,7000,,,shortphone,,,installer's telephone number
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 43 field 240336 value "Außentemperatur": ERR: element not found
Erroneous item is here:
r,,DisplayedOutsideTemp,Außentemperatur,,,,7300,,,tempv,,,Außentemperatur
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 44 field 240334 value "": ERR: element not found
Erroneous item is here:
r,,SFMode,SFMode,,,,7400,,,sfmode,,,
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 46 field 240546 value "operation mode of all/configured zone(s) matching OpModeEffect": ERR: element not found
Erroneous item is here:
r,,OpMode,OpMode,,,,7b00,,,opmode,,,operation mode of all/configured zone(s) matching OpModeEffect
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 47 field 240576 value "holiday setpoint": ERR: element not found
Erroneous item is here:
r,,HolidayTemp,HolidayTemp,,,,8200,,,tempv,,,holiday setpoint
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 51 field 241110 value "gerundete mittlere Außentemperatur (alle 3h aktualisiert)": ERR: element not found
Erroneous item is here:
r,,OutsideTempAvg,mittlere Außentemperatur,,,,9500,,,tempv,,,gerundete mittlere Außentemperatur (alle 3h aktualisiert)
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 53 field 241298 value "Temp.fühler WW, oben": ERR: element not found
Erroneous item is here:
r,,HwcStorageTempTop,"Temp.fühler WW, oben",,,,9D00,,,tempv,,,"Temp.fühler WW, oben"
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 54 field 241298 value "Temp.fühler WW, unten": ERR: element not found
Erroneous item is here:
r,,HwcStorageTempBottom,"Temp.fühler WW, unten",,,,9E00,,,tempv,,,"Temp.fühler WW, unten"
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 55 field 241298 value "Temp.fühler Hz, oben": ERR: element not found
Erroneous item is here:
r,,HcStorageTempTop,"Temp.fühler Hz, oben",,,,9F00,,,tempv,,,"Temp.fühler Hz, oben"
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 56 field 241298 value "Temp.fühler Hz, unten": ERR: element not found
Erroneous item is here:
r,,HcStorageTempBottom,"Temp.fühler Hz, unten",,,,A000,,,tempv,,,"Temp.fühler Hz, unten"
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 61 field 241352 value "operation mode of Hwc": ERR: element not found
Erroneous item is here:
r,,HwcOpMode,HwcOpMode,,,,0300,,,opmode,,,operation mode of Hwc
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 62 field 241376 value "setpoint of domestic hot water circuit": ERR: element not found
Erroneous item is here:
r,,HwcTempDesired,gewünschte Temperatur Warmwasserkreis,,,,0400,,,tempv,,,setpoint of domestic hot water circuit
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 63 field 241352 value "Speicheristtemperatur": ERR: element not found
Erroneous item is here:
r,,HwcStorageTemp,HwcStorageTemp,,,,0500,,,tempv,,,Speicheristtemperatur
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 64 field 241354 value "desired flow temp for Hwc": ERR: element not found
Erroneous item is here:
r,,HwcFlowTemp,HwcFlowTemp,,,,0800,,,tempv,,,desired flow temp for Hwc
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 69 field 242458 value "": ERR: element not found
Erroneous item is here:
r,,HwcSFMode,HwcSFMode,,,,0D00,,,sfmode,,,
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 76 field 242734 value "current flow temperature setpoint of Hc1": ERR: element not found
Erroneous item is here:
r,,Hc1ActualFlowTempDesired,ActualFlowTempDesired Heizkreis 1,,,,0700,,,tempv,,,current flow temperature setpoint of Hc1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 77 field 242722 value "current flow temperature of Hc1": ERR: element not found
Erroneous item is here:
r,,Hc1FlowTemp,FlowTemp Heizkreis 1,,,,0800,,,tempv,,,current flow temperature of Hc1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 79 field 242768 value "excess temperature of Hc1 (flow temperature's setpoint is increased by this value to keep the mixing valve in its control range)": ERR: element not found
Erroneous item is here:
r,,Hc1ExcessTemp,ExcessTemp Heizkreis 1,,,,0B00,,,calibrationv,,,excess temperature of Hc1 (flow temperature's setpoint is increased by this value to keep the mixing valve in its control range)
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 82 field 242754 value "operation of Hc1 during the lowering time; no influence if room temperature modulation is set to thermostat": ERR: element not found
Erroneous item is here:
r,,Hc1AutoOffMode,AutoOffMode Heizkreis 1,,,,0E00,,,offmode,,,operation of Hc1 during the lowering time; no influence if room temperature modulation is set to thermostat
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 84 field 242952 value "maximum flow temperature setpoint (end emphasis) of Hc1": ERR: element not found
Erroneous item is here:
r,,Hc1MaxFlowTempDesired,MaxFlowTempDesired Heizkreis 1,,,,1000,,,tempv,,,maximum flow temperature setpoint (end emphasis) of Hc1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 86 field 242962 value "minimum flow temperature setpoint (end emphasis) of Hc1": ERR: element not found
Erroneous item is here:
r,,Hc1MinFlowTempDesired,MinFlowTempDesired Heizkreis 1,,,,1200,,,tempv,,,minimum flow temperature setpoint (end emphasis) of Hc1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 87 field 242974 value "if outside temperature > summer limit => heating is OFF;applies to comfort and night setback setpoint": ERR: element not found
Erroneous item is here:
r,,Hc1SummerTempLimit,AT-Abschaltgrenze Heizkreis 1,,,,1400,,,tempv,,,if outside temperature > summer limit => heating is OFF;applies to comfort and night setback setpoint
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 88 field 242958 value "room temperature modulation of Hc1": ERR: element not found
Erroneous item is here:
r,,Hc1RoomTempSwitchOn,RoomTempSwitchOn Heizkreis 1,,,,1500,,,rcmode,,,room temperature modulation of Hc1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 99 field 244062 value "current flow temperature setpoint of Hc2": ERR: element not found
Erroneous item is here:
r,,Hc2ActualFlowTempDesired,ActualFlowTempDesired Heizkreis 2,,,,0700,,,tempv,,,current flow temperature setpoint of Hc2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 100 field 244052 value "current flow temperature of Hc2": ERR: element not found
Erroneous item is here:
r,,Hc2FlowTemp,FlowTemp Heizkreis 2,,,,0800,,,tempv,,,current flow temperature of Hc2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 102 field 244082 value "excess temperature of Hc2 (flow temperature's setpoint is increased by this value to keep the mixing valve in its control range)": ERR: element not found
Erroneous item is here:
r,,Hc2ExcessTemp,ExcessTemp Heizkreis 2,,,,0B00,,,calibrationv,,,excess temperature of Hc2 (flow temperature's setpoint is increased by this value to keep the mixing valve in its control range)
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 105 field 244072 value "operation of Hc2 during the lowering time; no influence if room temperature modulation is set to thermostat": ERR: element not found
Erroneous item is here:
r,,Hc2AutoOffMode,AutoOffMode Heizkreis 2,,,,0E00,,,offmode,,,operation of Hc2 during the lowering time; no influence if room temperature modulation is set to thermostat
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 107 field 244302 value "maximum flow temperature setpoint (end emphasis) of Hc2": ERR: element not found
Erroneous item is here:
r,,Hc2MaxFlowTempDesired,MaxFlowTempDesired Heizkreis 2,,,,1000,,,tempv,,,maximum flow temperature setpoint (end emphasis) of Hc2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 109 field 244320 value "minimum flow temperature setpoint (end emphasis) of Hc2": ERR: element not found
Erroneous item is here:
r,,Hc2MinFlowTempDesired,MinFlowTempDesired Heizkreis 2,,,,1200,,,tempv,,,minimum flow temperature setpoint (end emphasis) of Hc2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 110 field 244332 value "if outside temperature > summer limit => heating is OFF;applies to comfort and night setback setpoint": ERR: element not found
Erroneous item is here:
r,,Hc2SummerTempLimit,AT-Abschaltgrenze Heizkreis 2,,,,1400,,,tempv,,,if outside temperature > summer limit => heating is OFF;applies to comfort and night setback setpoint
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 111 field 244316 value "room temperature modulation of Hc2": ERR: element not found
Erroneous item is here:
r,,Hc2RoomTempSwitchOn,RoomTempSwitchOn Heizkreis 2,,,,1500,,,rcmode,,,room temperature modulation of Hc2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 123 field 245780 value "holiday setpoint for zone 1": ERR: element not found
Erroneous item is here:
r,,z1HolidayTemp,Raumsollwert Ferienbetrieb Zone 1,,,,0500,,,tempv,,,holiday setpoint for zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 124 field 245794 value "operation mode of zone 1": ERR: element not found
Erroneous item is here:
r,,z1OpMode,Betriebsart Zone 1,,,,0600,,,opmode,,,operation mode of zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 125 field 245792 value "day setpoint for zone 1": ERR: element not found
Erroneous item is here:
r,,z1DayTemp,Solltemperatur Zone 1,,,,0700,,,tempv,,,day setpoint for zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 126 field 245798 value "manual override setpoint for zone 1": ERR: element not found
Erroneous item is here:
r,,z1QuickVetoTemp,Quick Veto Temperatur Zone 1,,,,0800,,,tempv,,,manual override setpoint for zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 127 field 245794 value "night setpoint for zone 1": ERR: element not found
Erroneous item is here:
r,,z1NightTemp,Absenktemperatur Zone 1,,,,0900,,,tempv,,,night setpoint for zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 130 field 246334 value "": ERR: element not found
Erroneous item is here:
r,,z1SFMode,SFMode Zone 1,,,,0E00,,,sfmode,,,
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 131 field 246352 value "current room temperature in zone 1": ERR: element not found
Erroneous item is here:
r,,z1RoomTemp,Raumisttemperatur Zone 1,,,,0F00,,,tempv,,,current room temperature in zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 133 field 246604 value "configures which room temperature is assigned to zone 1": ERR: element not found
Erroneous item is here:
r,,z1RoomZoneMapping,Raumregler Zuordnung Zone 1,,,,1300,,,zmapping,,,configures which room temperature is assigned to zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 134 field 246566 value "current room setpoint considering all basic conditions passed to the control algorithms": ERR: element not found
Erroneous item is here:
r,,z1ActualRoomTempDesired,Raumsolltemperatur Zone 1,,,,1400,,,tempv,,,current room setpoint considering all basic conditions passed to the control algorithms
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 136 field 246556 value "short name of zone 1": ERR: element not found
Erroneous item is here:
r,,z1Shortname,Kurzbezeichnung Zone 1,,,,1600,,,shortname,,,short name of zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 137 field 246604 value "name of zone 1": ERR: element not found
Erroneous item is here:
r,,z1Name1,Bezeichnung Zone 1 Teil 1,,,,1700,,,zname,,,name of zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 138 field 246608 value "name of zone 1": ERR: element not found
Erroneous item is here:
r,,z1Name2,Bezeichnung Zone 1 Teil 2,,,,1800,,,zname,,,name of zone 1
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 146 field 247226 value "holiday setpoint for zone 2": ERR: element not found
Erroneous item is here:
r,,z2HolidayTemp,Raumsollwert Ferienbetrieb Zone 2,,,,0500,,,tempv,,,holiday setpoint for zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 147 field 247240 value "operation mode of zone 2": ERR: element not found
Erroneous item is here:
r,,z2OpMode,Betriebsart Zone 2,,,,0600,,,opmode,,,operation mode of zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 148 field 247238 value "day setpoint for zone 2": ERR: element not found
Erroneous item is here:
r,,z2DayTemp,Solltemperatur Zone 2,,,,0700,,,tempv,,,day setpoint for zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 149 field 247244 value "manual override setpoint for zone 2": ERR: element not found
Erroneous item is here:
r,,z2QuickVetoTemp,Quick Veto Temperatur Zone 2,,,,0800,,,tempv,,,manual override setpoint for zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 150 field 247240 value "night setpoint for zone 2": ERR: element not found
Erroneous item is here:
r,,z2NightTemp,Absenktemperatur Zone 2,,,,0900,,,tempv,,,night setpoint for zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 153 field 247806 value "": ERR: element not found
Erroneous item is here:
r,,z2SFMode,SFMode Zone 2,,,,0E00,,,sfmode,,,
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 154 field 247810 value "current room temperature in zone 2": ERR: element not found
Erroneous item is here:
r,,z2RoomTemp,Raumisttemperatur Zone 2,,,,0F00,,,tempv,,,current room temperature in zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 156 field 248052 value "configures which room temperature is assigned to zone 2": ERR: element not found
Erroneous item is here:
r,,z2RoomZoneMapping,Raumregler Zuordnung Zone 2,,,,1300,,,zmapping,,,configures which room temperature is assigned to zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 157 field 248044 value "current room setpoint considering all basic conditions passed to the control algorithms": ERR: element not found
Erroneous item is here:
r,,z2ActualRoomTempDesired,Raumsolltemperatur Zone 2,,,,1400,,,tempv,,,current room setpoint considering all basic conditions passed to the control algorithms
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 159 field 248052 value "short name of zone 2": ERR: element not found
Erroneous item is here:
r,,z2Shortname,Kurzbezeichnung Zone 2,,,,1600,,,shortname,,,short name of zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 160 field 248048 value "name of zone 2": ERR: element not found
Erroneous item is here:
r,,z2Name1,Bezeichnung Zone 2 Teil 1,,,,1700,,,zname,,,name of zone 2
^
Error reading "/etc/ebusd/vaillant/15.700.csv" line 161 field 248048 value "name of zone 2": ERR: element not found
Erroneous item is here:
r,,z2Name2,Bezeichnung Zone 2 Teil 2,,,,1800,,,zname,,,name of zone 2
^
2017-08-12 18:43:03.276 [main notice] found messages: 6164 (445 conditional on 143 conditions, 2 poll, 56 update)
2017-08-12 18:43:03.304 [main notice] ebusd stopped
Viele Grüße
Kai
Koef2
...hast Du die csvs mit dem Installer gespielt oder z.b. mit FTP ? so sah das bei mir auch aus, wie ich das über Netzwerk kopiert habe...
Hallo CS-ONLINE,
habe nachträglich die csv Datei von github über den RAW-Button geholt.
Die Configurations-Pakete ebusd wurden vorher über den Debianinstaller dpkg -i und später dpkg --force-overwrite blabla.deb eimgespielt. Da war aber das File 15.700.csv nicht dabei.
Habe jetzt wieder die Installation überschrieben und das neue csv-File gelöscht. Da meckert er natürlich
[main error] unable to load scan config 15: no file from /etc/ebusd/vaillant with prefix 15. matches ID "70000", SW0419, HW4603
Ich suche jetzt nach einer Möglichkeit, dass spätere Paket mit der 15.700.csv von github herunter zu laden. Aber soviel Erfahrung habe ich leide rmit github noch nicht.
Bin für alle Tipps dankbar.
Viele Grüße und schönen Sonntag und danke für deinen Tipp
Kai
Koef2
Hallo zusammen,
habe nun von GITHUB die Masterfiles geholt mittels svn, kopiert und Rechte vergeben. Da gibt es auf GITHUB einen Info rechts oben mit "clone or download"
svn co https://github.com/john30/ebusd-configuration.git /opt/ebusd/github-configuration-master/
cd /opt/ebusd/github-configuration-master/
cp -aPRv *.* /etc/ebusd/
cp -aPRv * /etc/ebusd/
cd /etc/ebusd/
chmod -R g+w *
chmod -R g+w *.*
Die Dateien stehen unter "trunk" --> und zugehörige VErsion nehmen 2.1.x und unter "de"
Und ebusctl info liefert
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
Jetzt geht es ans einbinden in FHEM.
Problem war also die Vermutung von cs-online.
Danke!!!
Viele Grüße
Kai
Koef2
Hallo Kai,
das freut mich, dass es das war ;-)
Einbinden in FHEM am besten nach dem Anleitungen von PAH im ersten Post, ich arbeite mittlerweile nur noch mit wenigen Klassendateien, wo die Funktionen jeweils alle drin sind. Anzeige in FHEM dann über ReadingsProxy auf die Funktionen der Klassendefinitionen... wenn dann noch hakt einfach wieder hier posten.
Grüße
Christian
Hallo Christian,
habe ich gemacht.
Schreiben der HEizkurve will ich nicht.
Und habe auch jetzt verstanden, dass ich auf die devices Fanspeed usw. jewiel ein FileLog-device setzen muss
#FileLog als Logdevices auf devices erstellen
define Fanspeed_Log FileLog ./log/Fanspeed-%Y-%m.log Fanspeed
define HKurve_Log FileLog ./log/HKurve-%Y-%m.log HKurve
define PumpeWatt FileLog ./log/PumpeWatt-%Y-%m.log PumpeWatt
define Ruecklauf_Log FileLog ./log/Ruecklauf-%Y-%m.log Ruecklauf
define Vorlauf_Log FileLog ./log/Vorlauf-%Y-%m.log Vorlauf
Und dann kümmer ich mich ums plotten.
Viele Grüße
Kai
Koef2
Du brauchst nicht unbedingt für jeden Wert ein eigenes Log anlegen, kannst auch alle Werte in ein Log schreiben lassen. Dann über die "Create SVG plot" einfach beliebige Plots anfertigen...
Ich habe zuerst mal einzelne Logs eingerichtet. Plots erstellen klappt auch.
Muss mich aber noch durch die Klassen wühlen.
Aussentemp will noch nicht so wie ich will :(. Aber da gehe ich jetzt erstmal suchen.
was ist denn das Problem mit der Aussentemperatur ? ich schau immer erst in den CSVs wie das da heisst, dann ebusctl starten und schauen, ob mit "r -f <abzufragendes>" überhaupt was kommt, dann in einer neuen Funktion in der Klassendatei einfügen, in FHEM testen, Fehlereinträge wegen falschen Erwartungswerten ignoriert.... feddisch :-)
Hallo Christian,
das war ein super Tipp. Habe mal Date ausgelesen ;). Und probier weiter. Leider etwas wenig Zeit im Moment.
Wenn das auf dem Linux Laptop läuft, dann kann ich auch den Raspi konfigurieren.
Viele Grüße
Kai
Koef2
So.
Ich kann einige Dinge auslesen, aber ab und zu funktioniert das auslesen nicht.
root@laax:/home/klopp# ebusctl r -f DisplayedOutsideTemp
ERR: read timeout
root@laax:/home/klopp# ebusctl r -f DateTime
valid;19:38:51;16.08.2017;22.250
root@laax:/home/klopp# ebusctl r -f DisplayedOutsideTemp
ERR: read timeout
root@laax:/home/klopp# ebusctl r -f vdatime
ERR: element not found
root@laax:/home/klopp# ebusctl r -f DateTime
valid;19:39:55;16.08.2017;22.438
root@laax:/home/klopp# ebusctl r -f OutsideTemp
ERR: element not found
root@laax:/home/klopp# ebusctl r -f DisplayedOutsideTemp
22.4375
root@laax:/home/klopp# ebusctl r -f Date
16.08.2017
root@laax:/home/klopp# ebusctl r -f WaterPressure
ERR: read timeout
root@laax:/home/klopp# ebusctl r -f WaterPressure
ERR: read timeout
root@laax:/home/klopp# ebusctl r -f Date
ERR: read timeout
Interssanterweise zeigt er aber bei Vorlauf- ud Rücklauftemp immer was an und schreibt das sauber in die Logfiles.
Muss ich vielleicht noch Poti USB Bus Koppler nachjustieren? In /var/log/ebsud.log waren aber keine Fehlermeldungen mehr. Service fhem vorsichtshalber gestoppt.
device mittels setserial auf low_latency gesetzt
...schon mal gut, dass das meiste kommt... Sitzt der Adapter direkt am USB oder am Hub ? Ich hatte meinen zweiten Adapter am Hub, der hat sich teilweise mit den anderen Devices gebissen, da kam auch zwischendurch immer mal ein Fehler. Alleine am USB lief das super. Welchen Adapter hast Du ? Den von PAH ? Ich habe den aus dem Mikrokontroller-Forum, der läuft gut. Poti einstellen ist halt auch nicht unwichtig, das mal ein wenig nach links und rechts probieren... Du kannst übrigens auch einmal "ebusctl" starten, der läuft dann bis zum stoppen, dann brauchst Du das nicht immer vor das r -f schreiben. Aus dem Modus kommst Du dann wieder mit "q" raus...
Ich habe einen ebus-usb-Koppler von esera automation. Der sitzt näher an der Heizung. Vielleicht hat aber auch die USB-Schnittstelle ein Problem. werde sonst doch mal schauen und an den Raspi klemmen.
Als der Koppler schlecht eingestellt war moittels Poti kamen viele Fehlermeldung im ebusd log. Jetzt kommen keine.
bei mir hängen beide Adapter zusammen mit zwei Cul-Sticks und einem HM-Stick am Raspi-II, wo auch FHEM drauf läuft... alles ohne Probleme. Du kannst mit (ebusctl) info sehen, welche CSVs geladen wurden, mit find sollten alle Namen der abfragbaren Werte ausgegeben werden. Nicht wundern, wenn dann keine Werte dahinter stehen, die kommen erst, wenn die explizit abgefragt wurden. Evtl. liefert auch nicht jede Therme alle Werte aus den CSVs...
danke
ebusctl find liefert ne Menge.
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = 20.625
broadcast signoflife = no data stored
broadcast vdatetime = 20:54:56;16.08.2017
700 AdaptHeatCurve = no data stored
700 BankHolidayEndPeriod = no data stored
700 BankHolidayStartPeriod = no data stored
700 ccTimer.Friday = no data stored
700 ccTimer.Monday = no data stored
700 ccTimer.Saturday = no data stored
700 ccTimer.Sunday = no data stored
700 ccTimer.Thursday = no data stored
700 ccTimer.Tuesday = no data stored
700 ccTimer.Wednesday = no data stored
700 ContinuosHeating = no data stored
700 currenterror = no data stored
700 CylinderChargeHyst = no data stored
700 CylinderChargeOffset = no data stored
700 Date = 16.08.2017
700 DisplayedOutsideTemp = 20.625
700 errorhistory = no data stored
700 FrostOverRideTime = no data stored
700 Hc1ActualFlowTempDesired = no data stored
700 Hc1AutoOffMode = no data stored
700 Hc1CircuitType = no data stored
700 Hc1ExcessTemp = no data stored
700 Hc1FlowTemp = no data stored
700 Hc1HeatCurve = no data stored
700 Hc1HeatCurveAdaption = no data stored
700 Hc1MaxFlowTempDesired = no data stored
700 Hc1MinFlowTempDesired = no data stored
700 Hc1MixerMovement = no data stored
700 Hc1PumpStatus = no data stored
700 Hc1RoomTempSwitchOn = no data stored
700 Hc1Status = no data stored
700 Hc1SummerTempLimit = no data stored
700 Hc2ActualFlowTempDesired = no data stored
700 Hc2AutoOffMode = no data stored
700 Hc2CircuitType = no data stored
700 Hc2ExcessTemp = no data stored
700 Hc2FlowTemp = no data stored
700 Hc2HeatCurve = no data stored
700 Hc2HeatCurveAdaption = no data stored
700 Hc2MaxFlowTempDesired = no data stored
700 Hc2MinFlowTempDesired = no data stored
700 Hc2MixerMovement = no data stored
700 Hc2PumpStatus = no data stored
700 Hc2RoomTempSwitchOn = no data stored
700 Hc2Status = no data stored
700 Hc2SummerTempLimit = no data stored
700 HcStorageTempBottom = no data stored
700 HcStorageTempTop = no data stored
700 HolidayEndPeriod = no data stored
700 HolidayStartPeriod = no data stored
700 HolidayTemp = no data stored
700 HwcBankHolidayEndPeriod = no data stored
700 HwcBankHolidayStartPeriod = no data stored
700 HwcFlowTemp = no data stored
700 HwcHolidayEndPeriod = no data stored
700 HwcHolidayStartPeriod = no data stored
700 HwcLockTime = no data stored
700 HwcMaxFlowTempDesired = no data stored
700 HwcOpMode = no data stored
700 HwcParallelLoading = no data stored
700 HwcSFMode = no data stored
700 HwcStorageTemp = no data stored
700 HwcStorageTempBottom = no data stored
700 HwcStorageTempTop = no data stored
700 HwcTempDesired = no data stored
700 hwcTimer.Friday = no data stored
700 hwcTimer.Monday = no data stored
700 hwcTimer.Saturday = no data stored
700 hwcTimer.Sunday = no data stored
700 hwcTimer.Thursday = no data stored
700 hwcTimer.Tuesday = no data stored
700 hwcTimer.Wednesday = no data stored
700 HydraulicScheme = no data stored
700 Installer1 = no data stored
700 Installer2 = no data stored
700 KeyCodeforConfigMenu = no data stored
700 MaintenanceDate = no data stored
700 MaintenanceDue = no data stored
700 MaxCylinderChargeTime = no data stored
700 MaxRoomHumidity = no data stored
700 MultiRelaySetting = no data stored
700 noiseReductionTimer.Friday = no data stored
700 noiseReductionTimer.Monday = no data stored
700 noiseReductionTimer.Saturday = no data stored
700 noiseReductionTimer.Sunday = no data stored
700 noiseReductionTimer.Thursday = no data stored
700 noiseReductionTimer.Tuesday = no data stored
700 noiseReductionTimer.Wednesday = no data stored
700 OpMode = no data stored
700 OpModeEffect = no data stored
700 OutsideTempAvg = no data stored
700 PhoneNumber1 = no data stored
700 PhoneNumber2 = no data stored
700 PrEnergySum = no data stored
700 PrEnergySumHc = no data stored
700 PrEnergySumHcLastMonth = no data stored
700 PrEnergySumHcThisMonth = no data stored
700 PrEnergySumHwc = no data stored
700 PrEnergySumHwcLastMonth = no data stored
700 PrEnergySumHwcThisMonth = no data stored
700 PumpAdditionalTime = no data stored
700 SFMode = no data stored
700 SolarYieldTotal = no data stored
700 SystemFlowTemp = no data stored
700 tariffTimer.Friday = no data stored
700 tariffTimer.Monday = no data stored
700 tariffTimer.Saturday = no data stored
700 tariffTimer.Sunday = no data stored
700 tariffTimer.Thursday = no data stored
700 tariffTimer.Tuesday = no data stored
700 tariffTimer.Wednesday = no data stored
700 Time = no data stored
700 ventilationTimer.Friday = no data stored
700 ventilationTimer.Monday = no data stored
700 ventilationTimer.Saturday = no data stored
700 ventilationTimer.Sunday = no data stored
700 ventilationTimer.Thursday = no data stored
700 ventilationTimer.Tuesday = no data stored
700 ventilationTimer.Wednesday = no data stored
700 WaterPressure = no data stored
700 YieldTotal = no data stored
700 z1ActualRoomTempDesired = no data stored
700 z1BankHolidayEndPeriod = no data stored
700 z1BankHolidayStartPeriod = no data stored
700 z1CoolingTimer.Friday = no data stored
700 z1CoolingTimer.Monday = no data stored
700 z1CoolingTimer.Saturday = no data stored
700 z1CoolingTimer.Sunday = no data stored
700 z1CoolingTimer.Thursday = no data stored
700 z1CoolingTimer.Tuesday = no data stored
700 z1CoolingTimer.Wednesday = no data stored
700 z1DayTemp = no data stored
700 z1HolidayEndPeriod = no data stored
700 z1HolidayStartPeriod = no data stored
700 z1HolidayTemp = no data stored
700 z1Name1 = no data stored
700 z1Name2 = no data stored
700 z1NightTemp = no data stored
700 z1OpMode = no data stored
700 z1QuickVetoTemp = no data stored
700 z1RoomTemp = no data stored
700 z1RoomZoneMapping = no data stored
700 z1SFMode = no data stored
700 z1Shortname = no data stored
700 z1Timer.Friday = no data stored
700 z1Timer.Monday = no data stored
700 z1Timer.Saturday = no data stored
700 z1Timer.Sunday = no data stored
700 z1Timer.Thursday = no data stored
700 z1Timer.Tuesday = no data stored
700 z1Timer.Wednesday = no data stored
700 z1ValveStatus = no data stored
700 z2ActualRoomTempDesired = no data stored
700 z2BankHolidayEndPeriod = no data stored
700 z2BankHolidayStartPeriod = no data stored
700 z2CoolingTimer.Friday = no data stored
700 z2CoolingTimer.Monday = no data stored
700 z2CoolingTimer.Saturday = no data stored
700 z2CoolingTimer.Sunday = no data stored
700 z2CoolingTimer.Thursday = no data stored
700 z2CoolingTimer.Tuesday = no data stored
700 z2CoolingTimer.Wednesday = no data stored
700 z2DayTemp = no data stored
700 z2HolidayEndPeriod = no data stored
700 z2HolidayStartPeriod = no data stored
700 z2HolidayTemp = no data stored
700 z2Name1 = no data stored
700 z2Name2 = no data stored
700 z2NightTemp = no data stored
700 z2OpMode = no data stored
700 z2QuickVetoTemp = no data stored
700 z2RoomTemp = no data stored
700 z2RoomZoneMapping = no data stored
700 z2SFMode = no data stored
700 z2Shortname = no data stored
700 z2Timer.Friday = no data stored
700 z2Timer.Monday = no data stored
700 z2Timer.Saturday = no data stored
700 z2Timer.Sunday = no data stored
700 z2Timer.Thursday = no data stored
700 z2Timer.Tuesday = no data stored
700 z2Timer.Wednesday = no data stored
700 z2ValveStatus = no data stored
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai AntiCondensValue = no data stored
bai averageIgnitiontime = no data stored
bai BlockTimeHcMax = no data stored
bai BoilerType = no data stored
bai ChangesDSN = no data stored
bai CirPump = no data stored
bai CodingResistor = no data stored
bai CounterStartattempts1 = no data stored
bai CounterStartattempts2 = no data stored
bai CounterStartAttempts3 = no data stored
bai CounterStartAttempts4 = no data stored
bai currenterror = no data stored
bai DateTime = valid;20:54:58;16.08.2017;20.625
bai dcfState = no data stored
bai DCFTimeDate = no data stored
bai DCRoomthermostat = no data stored
bai DeactivationsIFC = no data stored
bai DeactivationsTemplimiter = no data stored
bai DeltaFlowReturnMax = no data stored
bai DisplayMode = no data stored
bai DSN = no data stored
bai DSNOffset = no data stored
bai DSNStart = no data stored
bai EbusSourceOn = no data stored
bai EbusVoltage = no data stored
bai errorhistory = no data stored
bai ExternalFaultmessage = no data stored
bai externalHwcSwitch = no data stored
bai ExternGasvalve = no data stored
bai ExtFlowTempDesiredMin = no data stored
bai ExtStorageModulCon = no data stored
bai extWP = no data stored
bai FanHours = no data stored
bai FanMaxSpeedOperation = no data stored
bai FanMinSpeedOperation = no data stored
bai FanPWMSum = no data stored
bai FanPWMTest = no data stored
bai FanSpeed = no data stored
bai FanSpeedOffsetMax = no data stored
bai FanSpeedOffsetMin = no data stored
bai FanStarts = no data stored
bai Flame = no data stored
bai FlameSensingASIC = no data stored
bai FloorHeatingContact = no data stored
bai FlowsetHcMax = no data stored
bai FlowTemp = no data stored
bai FlowTempDesired = no data stored
bai FlowTempMax = no data stored
bai Fluegasvalve = no data stored
bai FluegasvalveOpen = no data stored
bai Gasvalve3UC = no data stored
bai GasvalveASICFeedback = no data stored
bai GasvalveUC = no data stored
bai GasvalveUCFeedback = no data stored
bai HcHours = no data stored
bai HcPumpMode = no data stored
bai HcPumpStarts = no data stored
bai HcStarts = no data stored
bai HcUnderHundredStarts = no data stored
bai HeatingSwitch = no data stored
bai HoursTillService = no data stored
bai HwcDemand = no data stored
bai HwcHours = no data stored
bai HwcImpellorSwitch = no data stored
bai HwcStarts = no data stored
bai HwcSwitch = no data stored
bai HwcTemp = no data stored
bai HwcTempMax = no data stored
bai HwcTypes = no data stored
bai HwcUnderHundredStarts = no data stored
bai HwcWaterflowMax = no data stored
bai Ignitor = no data stored
bai InitialisationEEPROM = no data stored
bai IonisationVoltageLevel = no data stored
bai maintenancedata_HwcTempMax = no data stored
bai maxIgnitiontime = no data stored
bai minIgnitiontime = no data stored
bai Mode = standby
bai ModulationTempDesired = no data stored
bai OptionalRelais = no data stored
bai OutdoorstempSensor = no data stored
bai OverflowCounter = no data stored
bai ParamToken = no data stored
bai PartloadHcKW = no data stored
bai PartnumberBox = no data stored
bai PositionValveSet = no data stored
bai PowerValue = no data stored
bai PrAPSCounter = no data stored
bai PrAPSSum = no data stored
bai PrEnergyCountHc1 = no data stored
bai PrEnergyCountHc2 = no data stored
bai PrEnergyCountHc3 = no data stored
bai PrEnergyCountHwc1 = no data stored
bai PrEnergyCountHwc2 = no data stored
bai PrEnergyCountHwc3 = no data stored
bai PrEnergySumHc1 = no data stored
bai PrEnergySumHc2 = no data stored
bai PrEnergySumHc3 = no data stored
bai PrEnergySumHwc1 = no data stored
bai PrEnergySumHwc2 = no data stored
bai PrEnergySumHwc3 = no data stored
bai PrimaryCircuitFlowrate = no data stored
bai ProductionByte = no data stored
bai PrVortexFlowSensorValue = no data stored
bai PumpHours = no data stored
bai PumpHwcFlowNumber = no data stored
bai PumpHwcFlowSum = no data stored
bai PumpPower = no data stored
bai PumpPowerDesired = no data stored
bai RemainingBoilerblocktime = no data stored
bai ReturnRegulation = no data stored
bai ReturnTemp = no data stored
bai ReturnTempExternal = no data stored
bai ReturnTempMax = no data stored
bai SerialNumber = no data stored
bai SetFactoryValues = no data stored
bai SHEMaxDeltaHwcFlow = no data stored
bai SHEMaxFlowTemp = no data stored
bai Statenumber = no data stored
bai Status = no data stored
bai Status01 = 28.5;29.5;20.438;31.5;47.5;off
bai Status02 = auto;60;75.0;70;65.0
bai Status16 = no data stored
bai StorageDelay = no data stored
bai StorageExitTemp = no data stored
bai Storageloadpump = no data stored
bai StorageLoadPumpHours = no data stored
bai StorageloadPumpStarts = no data stored
bai StorageLoadTimeMax = no data stored
bai StorageTemp = no data stored
bai StorageTempDesired = no data stored
bai StorageTempMax = no data stored
bai TargetFanSpeed = no data stored
bai TargetFanSpeedOutput = no data stored
bai TempDiffBlock = no data stored
bai TempDiffFailure = no data stored
bai TempGradientFailure = no data stored
bai Templimiter = no data stored
bai TemplimiterWithNTC = no data stored
bai TempMaxDiffExtTFT = no data stored
bai Testbyte = no data stored
bai TimerInputHc = no data stored
bai ValveStarts = no data stored
bai VolatileLockout = no data stored
bai VolatileLockoutIFCGV = no data stored
bai WarmstartDemand = no data stored
bai WaterHcFlowMax = no data stored
bai WaterPressure = no data stored
bai WaterpressureBranchControlOff = no data stored
bai WaterpressureMeasureCounter = no data stored
bai WaterpressureVariantSum = no data stored
bai WP = no data stored
bai WPPostrunTime = no data stored
bai WPSecondStage = no data stored
broadcast id = no data stored
general valuerange = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.08 = Vaillant;BAI00;0202;9602
scan.08 id = 21;17;14;0010015600;3100;005895;N3
scan.15 = Vaillant;70000;0419;4603
Also schein er ganz gut zu laufen.
Ich glaube, ich mache noch in der bai00.cfg Fehler. Ich muss die aber erst genauer verstehen
Viele Grüße und danke für Deine Unterstützunge, das hilft
Kai
Koef2
ähm, das was er mit find alles ausgibt sind die Felder aus den CSVs, die ebusd beim Start lädt. Nur wenn statt "no data stored" richtige Werte hinterstehen, dann wurde dieser Wert schon einmal seit dem Start von ebusd abgefragt und dort zwischen gespeichert. Mit "find -d" gibt er auch nur die aus, wo schon Werte ausgelesen wurden. Wenn Du über "r" oder "r -f" Werte abgefragt hast, sollten die dann auch im "find" bzw "find -d" ausgegeben werden. Die FHEM-Seite brauchst Du erst dann vervollständigen, wenn das in der Konsole sauber läuft.
ebusctl find -d
broadcast outsidetemp = 19.438
broadcast vdatetime = 21:23:09;16.08.2017
700 Date = 16.08.2017
700 DisplayedOutsideTemp = 20.000
bai DateTime = valid;21:23:10;16.08.2017;19.438
bai Mode = standby
bai Status01 = 28.5;29.5;19.438;31.5;47.5;off
bai Status02 = auto;60;75.0;70;65.0
scan.08 = Vaillant;BAI00;0202;9602
scan.08 id = 21;17;14;0010015600;3100;005895;N3
scan.15 = Vaillant;70000;0419;4603
Da sehe ich auch teilweise im logfiel des ebusd
Es gibt Broadcastmeldungen und Meldungen durch die Heizungssteuerng (bai) bzw. Bediengerät vrc700
ja, Du wirst alles sehen, was deine Anlage von sich aus hin und herschickt + Broadcast + die Werte, die du aktiv abfragst. Das machst Du eben über "r -f" im ebusctl oder über FHEM in den Klassen, wenn die dann aufgerufen werden. Alternativ kannst Du die Polling-Priorität (hoffe das ist der richtige Name, John hatte das neulich mal erklärt) aktivieren, dann liest ebusd die Werte automatisch Intervallmäßig aus...
da fällt mir ein, du kannst die Broadcast-Werte (wie z.B. vdatetime) nur mit "r vdatetime" ohne "-f" auslesen, weil die anscheinend nicht aktiv abfragbar sind. Das "-f" steht dafür, daß dann nicht aus dem Cache angezeigt wird, sondern auf den nächsten aktuellen Wert gewartet wird. Das kann natürlich mal einen Moment dauern... evtl. kommt da der timeout her... Wenn die Werte nicht super brandaktuell sein müssen, dann ohne "-f" abfragen.
Hallo Christian,
habe es in der bai00.cfg mal mit und ohne -f eingetragen.
Ab und zu erhält er Werte nun für Datum und Aussentemperatur.
werde Poti nochmal prüfen und auch USB-Kabel. Ggfs. auch den ebus nur als Linie. Ich hbae es etwas mehr als STern und oben direkt angezapt mit dem ebus koppler. Evtl. kommt es dadurch und usb Kabel parallen zu Netzwerkkabel zu Problemen.
Ich schau Mal weiter morgen.
Deine Anregungen waren sehr hilfreich.
Schönen ABend noch
Viele Grüße
Kai
Hallo zusammen,
weitere Erfolgsmeldungen:
- USB Schnittstelle führt zu err-meldungen, ggfs, weil Rechner sehr alt und USB Maus rumzickte
- Auslesen/Erfassung weiterer Daten Datum, Uhrzeit, Warmwassertemp, Speichertemp funktioniert
Mein Lösungsweg dank der Anregungen von CS-Online:
Alle Daten, die in /var/log/ebsud.log stehen, sind ohne error regelmäßig erfassbar
Auszug /var/log/ebusd.log
2017-08-17 22:00:47.920 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:00:57.699 [update notice] update bai Status01 QQ=10: 32.5;31.5;18.625;33.0;50.5;off
2017-08-17 22:00:57.965 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:01:07.792 [update notice] update bai Status01 QQ=10: 32.5;31.5;18.812;33.0;50.5;off
2017-08-17 22:01:08.059 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:01:08.315 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
2017-08-17 22:01:17.836 [update notice] update bai Status01 QQ=10: 32.5;31.5;18.812;33.0;50.5;off
2017-08-17 22:01:18.104 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:01:27.929 [update notice] update bai Status01 QQ=10: 32.5;31.5;18.625;33.0;50.5;off
2017-08-17 22:01:28.196 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:01:38.017 [update notice] update bai Status01 QQ=10: 32.5;31.5;18.625;33.0;50.5;off
2017-08-17 22:01:38.284 [update notice] update bai Mode QQ=10: standby
2017-08-17 22:01:38.557 [update notice] update bai DateTime QQ=10: valid;21:57:07;17.08.2017;18.625
2017-08-17 22:01:38.813 [update notice] update bai Status02 QQ=10: auto;60;75.0;70;65.0
Auszulesen sind ohne Probleme DateTime Status01 und Status02. Die Inhalte Informationen zum Aufbau/Auslesen erhält man indirekt aus /etc/ebusd/vaillant/hcmode.inc.
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# HC Betriebsart,,,,,,,,,,,,,
*r,,,,,,"B504",,,,,,,
r,,Mode,Betriebsart,,,B510,00,mode,,UCH,0=off;1=standby;2=heat;3=water,,
r,,DateTime,Datum Uhrzeit,,,,00,,,dcfstate;btime;bdate;temp2,,,
r,,Status,Status,,,B511,03,,,temp;press;press;HEX:4,,,
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,B511,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,
r,,Status02,Betriebsart/Maximaltemperatur/ReglerCurrentTEMP/Maximaltemperatur/ReglerCurrentTemp,,,B511,02,,,hwcmode;temp0;temp1;temp0;temp1,,,
r,,Status16,Aussentemperatur,,,,16,,,temp,,,
Will man bei mir die Aussentemperatur über status01 haben, so kann man es vorab mal mi ebusctl Befehl ausprobieren
ebusctl r status01Das liefert dann den ganzen Output.
32.5;31.5;18.625;33.0;50.0;offAn dritter Stelle steht die Aussentemperatur "18.625".
Auslesen erfolgt nun über die ANgaben aus hwmode.inc
r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,B511,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,ebusctl r status01 temp2.0Das liefert
18.625Wichtig: Für die Warmwassertemperatur müsste z. B. eingeben werden
ebusctl r status01 temp1.3; weil vorher schon 2 mal temp1 in der Zeile auftaucht (ist temp1.0 und temp1.1).
Zurück zur Aussentemperatur.
Einträge in /opt/fhem/FHEM/bai00.cfg für Aussentemperatur
get Aussentemp cmd {"r -m 10 status01 temp2.0\n"}
get Aussentemp expect "\d+\.\d+\n\n"
get Aussentemp postproc { sprintf("%5.1f",$_) }
"-m 10" bedeutet glaube ich, dass wenn in den letzten 10 x 300s schon abgefragt wurde und der Wert vorliegt, nicht neu abgefragt wird.
Eintrag für fhem.cfg
define Aussentemp ECMDDevice bai00.class
attr Aussentemp IODev EBUS
attr Aussentemp group Vaillant
attr Aussentemp icon sani_supply_temp
attr Aussentemp room Vaillant
So erhalte ich ein paar Daten mehr. Der Befehl "ebusd r OPTIONEN" hilft wirklich - wie cs-online ebreits schrieb - die richtigen Einstellungen zu finden.
Nun werde ich dan mal das Ganze auf den Raspi überspielen und weiter konfiguerien.
Tolles Forum und tolle Software. Danke dafür!!!
Viele Grüße
Kai
Koef2
und nicht vergessen in fhem.cfg in den Timer auch Aussentemperatur einzufügen, sonst ruft er keine Daten ab.
# Abfrage Timersteuerung al1 10 Min Temp
define EBUS.TimerTemp at +*00:10:00 get Aussentemp Aussentemp;;get Vorlauf Vorlauf;;get Ruecklauf Ruecklauf;;get PumpeWatt PumpeWatt;; get Fanspeed Fanspeed
attr EBUS.TimerTemp group VaillantControl
attr EBUS.TimerTemp icon time_timer
attr EBUS.TimerTemp room Vaillant
attr EBUS.TimerTemp verbose 0
Guten Morgen,
es geht voran, Glückwunsch ;-) ist halt beim Einstieg zäh, aber eben klasse, wenn man erstmal blickt, wie es geht.
Grüsse Christian
HAllo zusammen,
Umzug der Testumgebung auf dem Laptop auf einen RAspi3 war erfolgreich.
Und nicht vergessen "/bin/setserial /dev/ttyUSB0" --> Latency-Problems. Ich nutze ebusd 2.4. in 3.0pre scheint das automatisch zu funktionieren.
Ich hatte aber immer noch Probleme Werte, welche nicht in den Standardaussendungen der Vaillant waren, nur jede 6 Anfrage funktionierte.
Aufgrund der Lantenzprobleme habe ich die Paramter für den ebusd mir angeschaut und damit gespielt.
In /etc/default/ebusd habe ich beim ebusd Aufruf ergänzt:
Zitat-latency=33500 --acquireretries=10 --acquiretimeout=99500 --receivetimeout=99500 --sendretries=10
Das erhöht wohl die Anzahl der Anfragen an Master und Slaves und auch das Warten zwischen den einzelnen Retries.
Werde nun erstmal weiter testen und ggfs. mir das Ebuskabel vornhemen.
Viele Grüße
Kai
Koef2
Was sollte denn mit dem Kabel nicht stimmen ?
LG
pah
Hallo Peter,
im Forum stand irgendwo auch, dass Empfangen funktioniert, aber bei Sendeproblemen auf dme ebusd sowohl ebus-Pegel-Poti nochmals justiert werden soll als auch Kabelleitungen überprüft werden sollen.
Allerdings, wenn der Empfang auf dem Kabelt funktioniert, sollte das Senden der Datenpakte nicht schlechter gehen. Ist ja schließlich drahtgebunden ;)
Viele Grüße
Kai
Koef2
Zitatsollte das Senden der Datenpakte nicht schlechter gehe
Das stimmt so nicht. Beim Senden werden relativ große Ströme gezogen - und wenn das Kabel zu hochohmig ist, fällt daran zuviel Spannung ab.
Gemessen werden muss also, wenn der Sendetransistor durchgeschaltet ist, die Spannung am Empfänger.
LG
pah
Hallo zusammen,
nachdem die ganze Sache bei mir zufridenstellend läuft noch ein paar Infos.
Problem war, dass wenn der Raspi allein lief ohne LAN (kein weiterer Server und Gateway), alle Messdaten auf den Wert 0 gingen. Im log von ebusd /etc/var/ebusd.log konnte ich aber erkennen, dass broadcast richtige aufgenommen wurden. Nur FHEM im log /opt/fhem/log/fhem-Monat-Jahr.log war zu erkennen "attempt to write to disconnected device".
Im LAN war dhcp abgeschaltet und ich hatte unter hosts alle Server usw. zumindest eingetragen, damit der eine IP-Anwort bekommt.
Schließlich hat der Aufruf des ebus als ECDM Device mit folgender Änderung funktioniert:
Zitat#define EBUS ECMD telnet 192.168.20.102:8888
define EBUS ECMD telnet 127.0.1.1:8888
Die erste Zeile mit dem ursprünglichen Inhalt und die 2. Zeile mit der Änderung.
Nach dem fhem Neustart hat es dann auch als alleinstehender Rechner funktioniert. 127.0.1.1 muss aber in der /etc/hosts stehen !!!.
Weiterhin liegen mittels ebus ja auch Datum und Uhrzeit vor.
Mit folgendem Skript "ebustime2raspi" mit "+x" executable Rechten, welches crond regelmäßig aufruft übergebe ich die Uhrzeit an den Raspi:
#!/bin/sh
#Umwandeln Datumsformat udn Zeit ebus fuer date Befehl, da dcf77 von Vaillant Heizung
echo "PRG EBUS Time Date wandeln und Systemzeit setzen"
# date MMDDhhmmssYY
#Abfage ebus
EbusDateTime=$(/usr/bin/ebusctl r -f DateTime)
#EbusDateTime=$(/usr/bin/ebusctl r -f DatevTimes) # Debugeintrag fuer Fehler
echo "ebus date time: "$EbusDateTime"\n"
#
# Datum und Uhrzeit mit Trenenr ";" splitten mit set und Datum und Uhrzeit in eigene Hilfsvariablen
IFS=";"
set -- $EbusDateTime
HilfDate=$(echo "$3")
HilfTime=$(echo "$2")
#Trenner Datum "." Trenner Uhrzeit ":"
echo "HilfDate: "$HilfDate" und HilfTime: "$HilfTime"\n"
#
# Datum umwandeln in Tag Monat und Datum
#DD.MM.YYYY --> MMDDYY
IFS="."
set -- $HilfDate
HilfDD=$(echo "$1")
HilfMM=$(echo "$2")
HilfYYYY=$(echo "$3")
echo "HilfDD: "$HilfDD" HilfMM: "$HilfMM" HilfYYYY: "$HilfYYYY"\n"
# Entferne erste beiden Zahlen YYYY zu YY
# Zusammensetzen Datum
DateDatumZeit="$HilfMM""$HilfDD""$HilfYYYY"
# 4 stelliges JAhr in 2 stelliges wandeln --> loesche ersten beiden Stellen
HilfYY=$(echo "$HilfYYYY" | awk '{print substr($0,3)}')
DateDatumZeit="$HilfMM""$HilfDD""$HilfYY"
echo "DateDatumZeit: "$DateDatumZeit"\n"
#
#Uhrzeit Auseinanadernehmen und umwandeln
#hh:mm:ss --> hhmmss
IFS=":"
set -- $HilfTime
Hilfhh=$(echo "$1")
Hilfmm=$(echo "$2")
Hilfss=$(echo "$3")
#endgueltiger string MMDDhhmmYY
DateDatumZeit="$HilfMM""$HilfDD""$Hilfhh""$Hilfmm""$HilfYY"
echo "DateDatumZeit: "$DateDatumZeit"\n"
# Abfrage ob Buchtabe udnd Zeichen enthält
#DateDatumZeit=$(echo "----") #zum Debuggen, denn das ist Fehlerstring keeen Zeit udn Datum uebermittelt
# wenn ERR Antwort oben, dann ist dieser String leer
case "$DateDatumZeit" in
'----')
echo "no date time found, problem vaillant dcf77 -->invalid --> no time sync with date neccessary";;
"")
echo "ebus readin ERR --> string empty --> invalid --> no time sync with date neccessary";;
*)
echo "time date string found --> write time and date to raspi with date"
# Datum schreiben
/bin/date $DateDatumZeit;;
esac
#
exit 0
Prinzip: nutze set mit IFS-"Trenner" und übergebe in einzelen Variablen und setze die neu zusammen. Mit "date" Zeit des RAspi neu setzen. Wenn ebusctl nur "--.--.--" liefert, ist die Heizungssteuerung zwar da, aber liefert keinen Wert. Das wird zu "----" nach dem wandeln der VAriablen. Wenn ebusctl eine "ERR" liefert, ist beim ebusctl Aufruf etwas schief gelaufen. In beiden Fällen wird in der case-Abfrage nichts passieren. In allen andere Fällen wird das Datum und Uhrzeit geschrieben.
Vielleicht müssen noch mehr Fehler berücksichtig werden. Ggfs. kan man es auch schöner programmieren/skripten.
Eintrag mittels crontab -e:
*/5 * * * * /root/bin/ebustime2raspi
@reboot /root/bin/ebustime2raspiSo muss ich nicht über andere Server ins Internet gehen, um Datum und Uhrzeit zu erhalten.
Viele Grüße
Kai
Koef2
hmmm.... ich habe meinen Raspi direkt an der Fritzbox, so daß ich FHEM auch von außerhalb nutzen kann (um Warmwasser für die Badewanne zu machen, z.b.), ich habe solche Probleme noch nie gehabt. Interessant finde ich aber die Variante,
EbusDateTime=$(/usr/bin/ebusctl r -f DateTime)
direkt ohne den Umweg über ein FHEM-Device... Funktioniert das auch innerhalb von FHEM über Perl ?
Hallo,
die FHEM ECMD Devices werden ja in der FHEM/bai00.cfg so konfiguriert, dass der ebus-Befehl dort angegeben wird. Dort ruft Perl den Ebusbefehl eigentlich auf.
CS-Online hatte mir den Tipp gegeben, bevor etwas in FHEM konfiguriert wird, es direkt mit dem ebusctl Befehl auszuprobieren. Auch für den Pegelabgleich des ebusd werden ja direkt die Befehle benutzt. Das ebus-Paket von John30 unter Linux sind ja alles Linuxbefehle. Es gibt auch Anwender, die so direkt mit den ebus-Befehlen unter Linux ihre Datenbanken pflegen und auch auswerten.
Ist als direkt auf dem Raspi nutzbar, da das ebus-deb-Paket eingespielt wurde.
Viele Grüße
Kai
koef2
Hallo,
hat einer eine Idee, wie ich per ebusd die Raumtemperatur einstellen kann (also den Setpoint)?
Die Abfrage geht, das Setzen der Tag-Temperatur auch, aber leider nicht die (vom Handrad einstellbare) abweichende Raumtemperatur.
Es ist eine Vaillant Ecotec (type 470) - in den 470-er files finde ich keinen Parameter mit write Option
ebusctl read ActualRoomTempDesiredHc1
ebusctl read DisplayedHc1RoomTempDesired
ebusctl read Hc1DayTemp
- alles kein Problen, wie gesagt.... aber wie stelle ich die Temperatur mal kurzzeitig auf 22Grad - wenn die Hc1DayTemp auf 20 Grad steht. oder umgekehrt wenn sie auf 22 Grad steht - wie kann ich sie dann runterstellen?
Habe schon viel gesucht und probiert - Ihr seid eine meiner letzten Hoffnungen :)
Vielen Dank!
Micha
Hi micha_pr,
also du kannst nur den Wert für "Raumsoll" hinterlegen, mittels
w -c 470 Hc1DayTemp
in der 15.470 ist diese Zeile verantwortlich
r;w,,Hc1DayTemp,HC1_DaySetTemp,,,,"2700",,,temp1,,,day setpoint,,,
hier steht r;w also lesen und schreiben.
die Kurzfristige geänderte Raumsoll Temp die der Regler beim nächsten Schaltpunkt wieder zurücksetzt und wieder die hinterlegte benutzt, kannst du meines Wissens nicht separat einstellen. Da dies Der 470er intern macht.?
in meiner bai00.cfg siehts so aus zum lesen und schreiben.
wobei "Value("RaumSollTemp")" bei mir ein dummy Knopf ist .
# RaumIstTemp
get RaumTemp cmd {"r -f RoomTemp \n"}
get RaumTemp expect "\d+\n\n"
get RaumTemp postproc { sprintf("%5.1f",$_) }
#
#
#
# RaumSollTempSchreiben
get RaumSollTempSchreiben cmd {"w -c 470 Hc1DayTemp ".Value("RaumSollTemp")."\n"}
get RaumSollTempSchreiben expect ".*\n\n"
get RaumSollTempSchreiben postproc { $_ }
#
# RaumSoll lesen
get RaumSoll cmd {"r -f Hc1DayTemp \n"}
get RaumSoll expect "\d+\n\n"
get RaumSoll postproc { sprintf("%5.1f",$_) }
#
ActualRoomTempDesiredHc1 & DisplayedHc1RoomTempDesired
sind interne Werte, diese werden durch den 470er auf die gewünschte Raumsolltemp gesetzt, bei Sommer oder Frostschutz Betrieb werden diese Werte intern auf zb. 5°C gesetzt ohne die Raumsolltemp zu ändern, ob mann diese auch von aussen schreiben kann glaube ich nicht, habs noch nicht probiert.
in fhem habe ich dazu folgendes definiert
#
define RaumTemp ECMDDevice bai00.class
attr RaumTemp IODev EBUS
attr RaumTemp group Vaillant
attr RaumTemp icon temp_inside
attr RaumTemp room Vaillant
attr RaumTemp stateFormat {sprintf("%.1f",ReadingsVal("RaumTemp","RaumTemp",0)-1.8)." °C"}
attr RaumTemp userReadings RaumTemp(("RaumTemp","RaumTemp",0)-1.8)
attr RaumTemp verbose 0
#
define RaumSollTemp dummy
attr RaumSollTemp alias Raum Soll
attr RaumSollTemp group VaillantControl
attr RaumSollTemp icon temp_control
attr RaumSollTemp room Vaillant,Heizung
attr RaumSollTemp setList state:knob,min:15,max:26,step:1,linecap:round,fgColor:red
attr RaumSollTemp verbose 0
attr RaumSollTemp webCmd state
define RaumSollTempSchreiben_Click notify RaumSollTemp {fhem("get RaumSollTempSchreiben RaumSollTempSchreiben")}
attr RaumSollTempSchreiben_Click group heatingControl
attr RaumSollTempSchreiben_Click room Vaillant
define RaumSollTempSchreiben ECMDDevice bai00.class
attr RaumSollTempSchreiben IODev EBUS
attr RaumSollTempSchreiben group heatingControl
attr RaumSollTempSchreiben room Vaillant
attr RaumSollTempSchreiben stateFormat RaumSollTempSchreiben
attr RaumSollTempSchreiben verbose 0
#
define RaumSoll ECMDDevice bai00.class
attr RaumSoll IODev EBUS
attr RaumSoll group 1
attr RaumSoll icon temp_inside
attr RaumSoll room hidden
attr RaumSoll stateFormat {sprintf("%.1f",ReadingsVal("RaumSoll","RaumSoll",0))." °C"}
attr RaumSoll verbose 0
mfg maik
für die Wunschtemperatur, die nur temporär gilt gibt es quick veto, die wird spätestens beim Datumswechsel wieder gelöscht bzw. deaktiviert. vielleicht hilft das ja...
@ cs-online
r,,Hc1QuickVetoTemp,Quick Veto Temperatur Heizkreis 1,,,,"3C00",,,temp1,,,manual override setpoint of the first heating circuit,,,
ist nicht beschreibbar ??
hast du schonmal getestet was passiert wenn du diesen Wert über den ebus setzt??
mfg maik
also habs mal probiert mit
ebusctl -p 8888 hex 15b509040e3c0030
danach kann ich mit
ebusctl r -f Hc1QuickVetoTemp
auslesen, und es wird mir 24,0°C zurückgegeben, alle anderen Werte bleiben wie sie vorher waren.
pi@ospi ~ $ ebusctl r -f Hc1NightTemp
15.0
pi@ospi ~ $ ebusctl r -f DisplayedHc1RoomTempDesired
5.0
pi@ospi ~ $ ebusctl r -f ActualRoomTempDesiredHc1
5.00
pi@ospi ~ $ ebusctl r -f Hc1DayTemp
23.0
der 470er ändert seine Anzeige nicht, ob also nun die vetotemp benutzt wird kann ich nicht sagen.
mann könnte also die 15.470 auf
r;w,,Hc1QuickVetoTemp,Quick Veto Temperatur Heizkreis 1,,,,"3C00",,,temp1,,,manual override setpoint of the first heating circuit,,,
ändern
mfg maik
Zitat von: TiPpFeHlEr am 26 August 2017, 08:16:21
Hi micha_pr,
also du kannst nur den Wert für "Raumsoll" hinterlegen, mittels
w -c 470 Hc1DayTemp
in der 15.470 ist diese Zeile verantwortlich
r;w,,Hc1DayTemp,HC1_DaySetTemp,,,,"2700",,,temp1,,,day setpoint,,,
hier steht r;w also lesen und schreiben.[/code]
Das klappt leider so nicht.
Wenn ich Hc1DayTemp aufg einen höheren Wert setze, dann wird die Raumtemperatur angepasst - die relevanten Werte ändern sich.
Beim Zurücksetzen allerdings passiert nichts - die vorherigen Werte DisplayedHc1RoomTempDesired,ActualRoomTempDesiredHc1 bleiben bestehen (ausser natürlich Hc1DayTemp). Sicher bis zum nächsten Schaltpunkt.
Damit ist eine Regelung nur in eine Richtung möglich ;)
Was mich etwas "verwirrt" ist, dass der Raumtemperaturregler ja auch die Daten über den eBus an die Therme gibt - also müssten doch diese Kommandos irgendwo auftauchen, oder? Wenn ich dort 23Grad einstelle dann bekommt die There das ja übermittelt.
Mein eBus Adapter liest die aber anscheinend nicht mit, oder ich hab sie noch nicht entdeckt.
Fehlt da noch irgendeine Übersetzung, oder habe ich da einen Denkfehler?
Das mit dem Hc1QuickVetoTemp werde ich mal ausprobieren, wobei es natürlich verwirrend ist, wenn man am Raumregler eine andere Soll-Temperatur sieht, und nicht merkt, dass im Hintergrund "jemand" die echte Temperatur verstellt hat ;)
Danke!
Micha
hi micha,
also wenn du mit w -c 470 Hc1DayTemp 21 die Raumsoll auf 21°C setzen kannst, kannst du auch mit w -c 470 Hc1DayTemp 15 die Raumsoll auf 15°C runtersetzen!
Sollten sich die Werte von ebusctl r -f DisplayedHc1RoomTempDesired
&
ebusctl r -f ActualRoomTempDesiredHc1
nicht ändern, dann ist deine Reglung entweder im Frostschutz oder Sommerbetrieb.
poste mal bitte die Ausgaben von ebusctl r -f DisplayedHc1RoomTempDesired
&
ebusctl r -f ActualRoomTempDesiredHc1
ebenso von pi@ospi ~ $ ebusctl w -c 470 Hc1DayTemp 25
done
es sollte ein done erscheinen
mfg maik
Nochwas,
im Normalfall übermittelt dein Raumregler keine Raumsolltemp an die Therme, sondern eine Vorlaufsolltemp und ggf eine Betriebsart/Modus des Heizkreises.
Der Regler ermittelt anhand der Aussentemp und der Raumsolltemp und der Heizkurve und der gewählten Betriebsart die Aktuelle Vorlaufsolltemp für HK1, Die Therme entscheidet dann anhand der Aktuellen Vorlauftemp und der Zeit in der diese steigt oder fällt ob sie den Brenner & Pumpe einschalten soll. Erreicht die Therme schnell die Vorlaufsolltemp verlängert sich die Brennersperrzeit weil anscheinend wenig Wärmeabnahme besteht.
mfg Maik
Zitat von: TiPpFeHlEr am 26 August 2017, 11:13:45
hi micha,
also wenn du mit w -c 470 Hc1DayTemp 21 die Raumsoll auf 21°C setzen kannst, kannst du auch mit w -c 470 Hc1DayTemp 15 die Raumsoll auf 15°C runtersetzen!
...
Hi, Du hast natürlich Recht - das Problem sass (wie oft) vor dem Bildschirm ;)
Ich hatte einfach beim read das "-f" vergessen und somit die gecachten Werte bekommen.
Mann... das hat wirklich Lehrgeld (in Form von Zeit) gekostet :)
Zumindest kann man so wirklich eine Raumtemperatur-Regelung mit korrekter Anzeige erstellen.
Übrigens danke für die Erklärung mir dem Raumregler - das war mir so nicht bewusst - ich dachte das Ding ist "dumm" und die Berechnungen passieren in der Therme....
Nochmals vielen Dank für die Hilfe!!!
Micha
Zur Info.
Der "Galileo" EBUS Adapter 2.0 ist fast fertig und bald verfügbar.
Weitere Informationen findet man hier (https://forum.fhem.de/index.php/topic,75878.0.html).
Noch als Nachtrag (habe jetzt nicht genau gelesen, ob das mit der kurzfristigen Temperatur-Änderung geklappt hat):
Beim VRC700 muss man nach Setzen der QuickVeto auch noch den "special function mode" (ich interpretiere das "SF" mal so) auf "QuickVeto" stellen. Wenn ich mich recht erinnere, zeigt danach auch das Display der Steuerung die so gewünschte Temperatur:
ebusctl w -c 700 Hc1QuickVetoTemp 25.5
ebusctl w -c 700 Hc1SFMode 3
@TiPpFeHlEr : sorry, das ich erst jetzt antworte: Ja, da muss das "w" mit rein, auch bei der Betriebsart für Warmwasser war das meine ich, da steht in der CSV auch nur "r" drin, kann aber auf "r;w" geändert werden, dann kann man auch einstellen. Und es muss auch die QucikVeto neben der Temperatur auch die Funktion selber angestellt werden, damit die Therme zwischen der QuickVeto und der normalen umschaltet. Dann sollte das auch im Display auftauchen,
Grüße
Christian
Hi,
ich habe nun trotzdem noch einen seltsamen Effekt, den ich mir nicht erklären kann....
ebusctl read -f DisplayedRoomTemp
0.00
ebusctl read -f DisplayedHc1RoomTempDesired
0.0
aber
ebusctl read -f RoomTemp
22.69;ok
ebusctl read -f BMUB51101StorageTemp
33.0
...
Früh hatte ich noch eine DisplayedRoomTemp ... Aber im Laufe des Vormittags war sie dann weg. Das passiert während der Absenkung der Temperatur (Abwesenheit)
Das selbe hatte ich auch abends - nachdem die Heizung in den Nacht-Modus gegangen ist.
Wieso bekommt man da keine Werte mehr zurück, hat da jemand eine Idee?
Danke!
Micha
Das liegt wohl am Regler selbst, ich denke die Bezeichnung ist hier irreführend.
Das ist die ermittelte Raum soll temp. Diese wird benutzt um mit Hilfe der heizkurve die Vorlauf soll temp zu berechnen. Da die Raum ist größer Raum soll liegt, gibt der Regler zum berechnen einen sehr geringen Wert vor, dieser müsste gleichzeitig die Frostschutz temp sein. Bei mir sind im Sommer und aus Betrieb beide auf 5 Grad. Dies entspricht meiner Frostschutz temp.
Mfg Maik
Zitat von: TiPpFeHlEr am 29 August 2017, 11:11:05
Das liegt wohl am Regler selbst, ich denke die Bezeichnung ist hier irreführend.
Das ist die ermittelte Raum soll temp. ...
Mir ging es um die
DisplayedRoomTemp und
DisplayedHc1RoomTempDesired Die "verschwinden", nachdem sie im Normal-Betrieb vorhanden sind und auch den angezeigten Werten auf dem Raumregler entsprechen.
Dass die RoomTemp nicht die Raumtemperatur ist, ist mir klar - ich wollte nur darstellen, dass ich ansonsten Werte bekomme...
Danke,
Micha
Sie verschwinden nicht, sie werden bei dir auf "0°C" gesetzt.
Bei mir werden sie auf "5°C" gesetzt, sobald der Regler im "sommer" "Aus" oder "Abschalt" Betrieb ist.
Dies geschieht wahrscheinlich auch im Nachtabsenkbetrieb wenn der Raumregler im Thermostat Betrieb und nicht im Raumaufschalt Betrieb gestellt ist.
Ich werde das mal mit meinem Regler nachstellen und berichten.
Schau mal nach auf welchen Wert deine Frostschutz Temperatur gestellt ist.
Mfg Maik
Also
DisplayedHc1RoomTempDesired
bei Tag Betrieb23.0
bei Nacht Betrieb15.0
bei Sommer Betrieb5.0
bei SystemAus[Frostschutz] Betrieb0.0
wobei mir meine DisplayedRoomTemp
pi@ospi ~ $ ebusctl r -f DisplayedRoomTemp
-1616.00
das zeigt, dazu liefert der hex Wert
pi@ospi ~ $ ebusctl -p 8888 hex 15b509030d8000
0100
also ist hier meine 15.470 falsch, weill ein "00" kann keine Temperatur sein.
also scheint deine Anlage im Nacht Betrieb auf Frostschutz zu gehen??
poste mal bitte die Ausgabe von
ebusctl r -f Hc1AutoOffMode
dieser sollte auf "eco" stehen oder anderes. falls er auf "frostprotection" steht, ist es klar warum dir 0.0 °C im Nachtbetrieb angezeigt werden.
Ich bitte immer um Korrektur falls ich etwas falsches gesagt habe!!
mfg Maik
Hallo,
also... ;)
470 Hc1AutoOffMode = eco
das sollte also stimmen.
Und alles was mit Temperatur zu tun hat (jetzt im Tag Modus)
470 ActualRoomTempDesiredHc1 = 17.50
470 ADCValueTempbelow = 2141
470 B51000TempDesiredLoadingPump = -
470 BMUB51101BoilerFlowTemp = 55.0
470 BMUB51101StorageTemp = 49.0
470 BMUFlowTempOrVF1 = 55.00;ok
470 DisplayedHc1RoomTempDesired = 17.5
470 DisplayedHwcStorageTemp = 49.0
470 DisplayedRoomTemp = 21.25
470 ExcessTemp = 0.0
470 Hc1ActualFlowTempDesired = 0.0
470 Hc1DayTemp = 17.5
470 Hc1FloorPavementDryingTemp = 0.0
470 Hc1HolidayRoomTemp = 4.5
470 Hc1MinimalFlowTempDesired = 15.0
470 Hc1NightTemp = 17.0
470 Hc1QuickVetoTemp = 0.0
470 Hc1RoomTempSwitchOn = modulating
470 Hc2TempDesiredB50418 = 0.0
470 HwcActualTempDesired = 50.0
470 HwcTempDesired = 50.0
470 OutsideTemp = 19.62;ok
470 OutsideTempOffset = 0.0
470 RaumtempIstUnten = 23.06;ok
470 RoomTemp = 23.06;ok
470 RoomTempCorrection = 0.0
470 RoomTempOffsetSelfWarming = -1.81
broadcast outsidetemp = 19.438
ich logge gerade mal die Werte mit über Nacht - mal sehen, ob ich danach schlauer bin...
Danke nochmal,
Micha
Hier nun die Nacht-Werte und das Umschalten morgens in den Tag Modus:
ActualRoomTempDesiredHc1
2017-08-29-22:20:03 17.50
2017-08-29-22:25:03 17.50
2017-08-29-22:30:03 0.00
...
2017-08-30-04:15:03 0.00
2017-08-30-04:20:03 17.50
DisplayedHc1RoomTempDesired
2017-08-29-22:25:22 17.5
2017-08-29-22:30:24 0.0
...
2017-08-30-04:15:21 0.0
2017-08-30-04:20:24 17.5
Merkwürdigerweise hat dieser Wert sich heute nicht auf "0.00" geschaltet, obwohl sich an der Konfig nicht geändert hat...
DisplayedRoomTemp
2017-08-29-13:55:05 0.00
2017-08-29-14:00:06 20.94
2017-08-29-14:05:06 21.00
...
2017-08-30-13:35:22 20.44
Was aber interessant ist - irgendwie spielt der FrostProtect-Mode da wirklich mit rein, warum auch immer....
FrostProtectStateMonitor
2017-08-29-22:25:31 0
2017-08-29-22:30:31 5 (Heizperiode inaktiv)
2017-08-29-22:35:30 5
...
2017-08-30-04:15:28 5 (Heizperiode aktiv)
2017-08-30-04:20:32 0
...
2017-08-30-06:35:33 0 (Heizperiode inaktiv)
2017-08-30-06:40:28 5
was man auch hieran sieht:
FrostprotectionRequiredMonitor
2017-08-29-22:25:30 no
2017-08-29-22:30:30 yes
...
2017-08-30-04:15:28 yes
2017-08-30-04:20:31 no
...
2017-08-30-06:35:32 no
2017-08-30-06:40:27 yes
HC1AutoOffMode steht immer auf "eco"
Es gibt auch keinen weiteren Hinweis darauf, warum die Therme in den Frostschutz geht...
Die Temp-Werte habe ich im letzten Post schon kopiert (DayTemp, NightTemp).
HC1OPMode ist auf auto
Unabhängig davon, warum die aktuelle Raumtemperatur nicht angezeigt wird, ist mir total unklar, wieso die Therme hier in den Frostschutzmodus geht, statt in den Nacht-Modus... Und woher die 0.00 Werte kommen...
Hat einer eine Idee?
Danke für Eure Geduld!
Micha
also das ist ja mal sehr merkwürdig :o
Warum dein Regler im Nachtbetrieb von 22:30-4:20 in den Frostschutzbetrieb geht ist mir ein Rätsel.
Mein 470/4 hat keine separate Einstellung für den Nacht Betrieb wie zb. "Absenk,Aussenhalt,Abschalt,Frostschutz Betrieb" wie es bei Buderus üblich ist.
poste mal Bitte
ebusctl r -f Hc1NightTemp
Welche Schaltzeiten für HK1 hast du im Regler programmiert? passt das mit 4:20-22:30 ??
hmmm ich kanns nicht nachstellen, SORRY,
mfg Maik
470 Hc1NightTemp = 17.0 - hatte ich vorher gepostet - bleibt auch konstant, so wie es sein soll.
Und die Zeiten stimmen, ja. Immer wenn die Heizung abgeschaltet wird, geht er in den Frostschutz.
470 hcTimer.Tuesday = 04:20;06:40;14:00;22:30;-:-;-:-;selected
Möglicherwese ist das eine "Logik", weil er ja nicht heizen muss.... Sicher was Vaillant spezifisches.
Da muss man ein wenig "eigene Logik" drum rum programmieren, um damit zurechtzukommen.
Wenn mir noch was auffällt, schreibe ich es mal hier rein.
@ALL Hat sonst noch jemand eine Vaillant EcoTec Plus VC mit Raumregler (470-er CSV) im Einsatz?
Danke!
Micha
Ecotec Plus, VR70, VRC700, kein Raumregler...
Hallo zusammen,
Ich stehe jetzt auch vor dem Problem, das ich mit FHEM meine Vaillant Heizung auslesen möchte.
Im Packet wurde eine VR900 mitgeliefert.
In verschiedenen Post wird darauf hingewiesen, das es mit einer VR900 einfacher währe, leider keine Hinweise, wie diese abgefragt werden kann.
Habt Ihr dies schon versucht und könnt Ihr mir einen Tip geben, wie ich diese abfragen kann.
Danke + Gruß
Mirko
Hallo,
habe genau dasselbe Problem.
Habe ein VWS 117/4 mit VR70, Multimatic 700 und einem VR900.
Möchte das ebenfalls gerne über FHEM auslesen (NUR auslesen).
Sollte das mit dem VR900 einfacher gehen, wäre ich über Hinweise
sehr dankbar :-)
lg
stiff
Zur VR900 gibt es direkt von Vaillant eine (Android)App.
In meinen Augen ist das Ding aber noch simpler gehalten als die Anzeige der VRC700. Zu mehr kann man die VR900 nicht gebraucht, gezielt abfragen lässt sie sich über eBus gar nicht. Wenn es natürlich nur um die Anzeige der eingestellten Temperaturen und Zeitprogramme geht oder zur Aktivierung von Party- und/oder Urlaubsmodus mag die VR900 mit App ausreichen.
Ich persönlich kann gut darauf verzichten - wenn also jemand eine VRC700 hat und eine VR900 möchte, kann er sich gern bei mir melden! ;)
Hallo zusammen,
Ich habe jetzt das VR900 beiseite gelegt und einen eBUS USB Wandler zugelegt.
Als Treiber habe ich eBUS 3.0 mit der Config ebusd-2.1.x installiert.
Bei der Initialen Einstellung sehe ich folgende Meldungen auf dem eBUS:
2017-09-15 22:46:51.175 [bus notice] <00073b03000080160388
2017-09-15 22:46:52.190 [bus notice] <000f5d01008000800080c4019401c87c008c
2017-09-15 22:46:52.457 [bus notice] <0001019a
2017-09-15 22:46:52.723 [bus notice] <0001019a
2017-09-15 22:46:53.704 [bus notice] <0001019a
2017-09-15 22:46:53.948 [bus notice] <0002019c2b
2017-09-15 22:46:59.974 [bus notice] <0009312c600bff670000ff17
2017-09-15 22:47:00.240 [bus notice] <0009ff2c600bff670000ffa8
2017-09-15 22:47:00.503 [bus notice] <00073b03000080160388
2017-09-15 22:47:00.795 [bus notice] <000f5e01008000800080c5019401c87c00ee
2017-09-15 22:47:01.064 [bus notice] <0001019a
2017-09-15 22:47:01.330 [bus notice] <0001019a
2017-09-15 22:47:01.587 [bus notice] <0001019a
2017-09-15 22:47:01.832 [bus notice] <0002019c2b
2017-09-15 22:47:10.026 [bus notice] <0009312c600bff670000ff17
2017-09-15 22:47:10.292 [bus notice] <0009ff2c600bff670000ffa8
2017-09-15 22:47:10.555 [bus notice] <00073b030000801503be
2017-09-15 22:47:10.848 [bus notice] <000f5d01008000800080c3019401c87c00d2
2017-09-15 22:47:11.116 [bus notice] <0001019a
2017-09-15 22:47:11.383 [bus notice] <0001019a
2017-09-15 22:47:11.639 [bus notice] <0001019a
2017-09-15 22:47:11.900 [bus notice] <0002019c2b
2017-09-15 22:47:20.046 [bus notice] <0009312c300bff670000ffd1
2017-09-15 22:47:20.314 [bus notice] <0009ff2c300bff670000ff6e
2017-09-15 22:47:20.575 [bus notice] <00073b030000801503be
2017-09-15 22:47:20.869 [bus notice] <000f5e01008000800080c5019401c87c00ee
Könnt Ihr mir bitte weiterhelfen, an welcher Stelle sollte das <AA erscheinen.
Wir haben eine Vaillant flexo Therm im Einsatz.
Die Konfiguration im FHEM sieht wie folgt aus:
define Vaillant.Heizung ECMD telnet 192.168.178.25:8888
attr Vaillant.Heizung classdefs HK.WW.class=/opt/fhem/FHEM/ebus_ww.cfg:HK.Hz.class=/opt/fhem/FHEM/ebus_hz.cfg
attr Vaillant.Heizung icon usb
attr Vaillant.Heizung room Heizung
define HK.Hz ECMDDevice HK.Hz.class
attr HK.Hz IODev Vaillant.Heizung
attr HK.Hz group heating
attr HK.Hz room Heizung
define HK.WW ECMDDevice HK.WW.class
attr HK.WW IODev Vaillant.Heizung
attr HK.WW group heating
attr HK.WW room Heizung
Das ich über Fhem nichts auslesen kann, liegt evtl auch daran, das die Konfiguration nicht sauber installiert wurde.
sudo dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
(Lese Datenbank ... 325156 Dateien und Verzeichnisse sind derzeit installiert.)
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).
dpkg: Fehler beim Bearbeiten des Paketes ebusd-configuration (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
ebusd-configuration
Alle Pakete wurden mit den der Paketen installiert und nicht neu kompiliert.
Evtl könnt Ihr mir hier weiterhelfen.
Danke und Gruß
Mirko
Ich würde erstmal probieren, ob Du im Linux mit ebusctl starten und dann z.b. mit find überhaupt was sehen kannst. Da müsste dann eine Auflistung der csv-Inhalte erscheinen. Mit "r -f ..." kannst Du dann ggf Werte abfragen. Wenn das funktioniert, dann erst Richtung FHEM starten
Zitat von: Mirko_2013 am 15 September 2017, 22:54:48
2017-09-15 22:46:51.175 [bus notice] <00073b03000080160388
Könnt Ihr mir bitte weiterhelfen, an welcher Stelle sollte das <AA erscheinen.
Mit ebusd 3.0 musst Du statt "--lograwdata" die neue Version mit "--lograwdata=bytes" benutzen, da ansonsten bereits das Protokoll teilweise interpretiert wird, sprich jetzt siehst Du alles was zwischen AA vorbei kommt.
Zitat von: Mirko_2013 am 15 September 2017, 22:54:48
ebusd-configuration hängt ab von ebusd (>= 2.1).
Hast Du denn das ebusd Release auch mit dpkg installiert? Sieht nicht so aus...
Hallo john30,
Ich habe alles nochmal weggeräumt und neu installiert.
ebus 3.0 installiert:
sudo dpkg -i ebusd-3.0_i386.deb
Vormals nicht ausgewähltes Paket ebusd:i386 wird gewählt.
(Lese Datenbank ... 325060 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von ebusd-3.0_i386.deb ...
Entpacken von ebusd:i386 (3.0) ...
ebusd:i386 (3.0) wird eingerichtet ...
Instructions:
1. Edit /etc/default/ebusd if necessary
(especially if your device is not /dev/ttyUSB0)
2. Place CSV configuration files in /etc/ebusd/
(see https://github.com/john30/ebusd-configuration)
3. To start the daemon, enter 'service ebusd start'
4. Check the log file /var/log/ebusd.log
Trigger für systemd (229-4ubuntu19) werden verarbeitet ...
Trigger für ureadahead (0.100.0-19) werden verarbeitet ...
danach die ebus configuration versucht zu installieren.
versucht ebus configuration installiert:
sudo dpkg -i --force-overwrite ebusd-configuration-2.1.b143f39-de_all.deb
Vormals nicht ausgewähltes Paket ebusd-configuration wird gewählt.
(Lese Datenbank ... 325066 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von ebusd-configuration-2.1.b143f39-de_all.deb ...
Entpacken von ebusd-configuration (2.1.b143f39-de) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von ebusd-configuration:
ebusd-configuration hängt ab von ebusd (>= 2.1).
dpkg: Fehler beim Bearbeiten des Paketes ebusd-configuration (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
ebusd-configuration
Wenn ich mir die installierten Pakete ansehe, sind folgende Versionen installiert:
ii ebusd:i386 3.0 i386 eBUS daemon.
iU ebusd-configuration 2.1.b143f39-de all ebusd configuration files (de).
sobald ich versuch mit "sudo apt-get -f install" die Abhängigkeitsprobleme aufzulösen, wird mir vorgeschlagen die Konfiguration zu entfernen.
mit ebusctl, bekomme ich folgende Ausgaben:
ebusctl
localhost: find
broadcast datetime = no data stored
broadcast error = no data stored
broadcast ident = no data stored
broadcast signoflife = no data stored
broadcast ident = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.05 ident = no data stored
scan.08 ident = Vaillant;HMU00;0305;0403
Ein checkconfig bringt folgende Meldung:
ebusd --checkconfig
2017-09-16 16:00:41.672 [main notice] ebusd 3.0.595c7c0 performing configuration check...
/etc/ebusd/vaillant/15.sdr_p.csv:6: ERR: duplicate entry, duplicate ID
2017-09-16 16:00:41.687 [main error] error reading config files: ERR: duplicate entry, last error: /etc/ebusd/vaillant/15.sdr_p.csv:6: ERR: duplicate entry, duplicate ID
2017-09-16 16:00:41.689 [main notice] found messages: 384 (2 conditional on 2 conditions, 0 poll, 4 update)
2017-09-16 16:00:41.690 [main notice] ebusd stopped
Gruß
Mirko
Zitat von: cs-online am 16 September 2017, 09:44:34
Ich würde erstmal probieren, ob Du im Linux mit ebusctl starten und dann z.b. mit find überhaupt was sehen kannst. Da müsste dann eine Auflistung der csv-Inhalte erscheinen. Mit "r -f ..." kannst Du dann ggf Werte abfragen. Wenn das funktioniert, dann erst Richtung FHEM starten
Hallo cs-online:
Danke für den Hinweis.
Leider bekomme ich keine Auflistung der cdv Inhalte, wie in meinem anderen Post geschrieben, habe ich allerdings auch Probleme die bus Konfiguration zu installieren.
Gibt es eine Möglichkeit diese Manuell zu installieren?
ebusctl
localhost: find
broadcast datetime = no data stored
broadcast error = no data stored
broadcast ident = no data stored
broadcast ident = no data stored
broadcast signoflife = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.08 = Vaillant;HMU00;0305;0403
Danke und Gruß
Mirko
Zitat von: Mirko_2013 am 16 September 2017, 13:35:36
sudo dpkg -i ebusd-3.0_i386.deb
sudo dpkg -i --force-overwrite ebusd-configuration-2.1.b143f39-de_all.deb
genau so wäres richtig. das ist ja bizarr. muss ich mal schauen, was das soll
EDIT: also ich kann leider nicht nachvollziehen, warum das bei dir nicht klappt.
Kannst höchstens die Anhängigkeiten ignorieren mit "--ignore-depends=ebusd" bei Installation der config.
Zitat von: john30 am 16 September 2017, 19:39:37
genau so wäres richtig. das ist ja bizarr. muss ich mal schauen, was das soll
EDIT: also ich kann leider nicht nachvollziehen, warum das bei dir nicht klappt.
Kannst höchstens die Anhängigkeiten ignorieren mit "--ignore-depends=ebusd" bei Installation der config.
Hallo John30,
Habe ich gerade eben versucht, das gleiche Problem.
Gibt es eine Möglichkeit die knotig manuell zu erstellen?
Gruß
Mirko
Zitat von: Mirko_2013 am 16 September 2017, 16:11:00
Hallo cs-online:
Danke für den Hinweis.
Leider bekomme ich keine Auflistung der cdv Inhalte, wie in meinem anderen Post geschrieben, habe ich allerdings auch Probleme die bus Konfiguration zu installieren.
Gibt es eine Möglichkeit diese Manuell zu installieren?
ebusctl
localhost: find
broadcast datetime = no data stored
broadcast error = no data stored
broadcast ident = no data stored
broadcast ident = no data stored
broadcast signoflife = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan.08 = Vaillant;HMU00;0305;0403
Danke und Gruß
Mirko
Hallo cs-online,
Ich habe gerade nochmal getestet.
Wenn ich den ebus scanne bekomme ich mit find folgende Ausgabe:
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast netloss = no data stored
broadcast netresetcfg = no data stored
broadcast netresetstate = no data stored
broadcast outsidetemp = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.08 = Vaillant;HMU00;0305;0403
scan.08 id = no data stored
scan.52 = Vaillant;VR_70;0109;2903
scan.76 = Vaillant;VWZ00;0305;0403
scan.76 id = (ERR: invalid position for 3176b5090124 / 00)
Gruß
Mirko
Hallo,
habe seit geraumer Zeit ein Problem beim auslesen des Ebus.
Dieses stellt sich wie folgt dar, ich hole mir mit einem Timer alle 15 Minuten dieverse Ebus Daten.
+*00:15:00
get Aussentemp Aussentemp ;
get Vorlauf Vorlauf;
get Ruecklauf Ruecklauf;
get HKurve HKurve;
get Wasserdruck Wasserdruck;
get RaumTemp RaumTemp;
get RaumSoll RaumSoll;
get WWIst WWIst;
get WWSoll WWSoll;
get WW_Ladung WW_Ladung;
get HzPumpe HzPumpe;
get HzMode HzMode;
get WwMode WwMode;
get HcMode HcMode;
get Raumtemp Raumtemp;
get FanspeedDay FanspeedDay;
get FanspeedNight FanspeedNight;
get WTMode WTMode;
get WaermeRueck WaermeRueck;
get Disbalance Disbalance;
get Ionisation Ionisation;
get Hz_hours Hz_hours;
get Hz_starts Hz_starts;
get Ww_hours Ww_hours;
get Ww_starts Ww_starts;
get Pump_hours Pump_hours;
get LegioTag LegioTag;
get LegioZeit LegioZeit;
manchmal kommt es vor das die erhaltenen Werte nicht den richtigen devices zugeordnet werden.
dies ist in Bild 1 gut zu sehen.
Dabei erhält zb. Ionisation den Wert von Disbalance usw....
also immer den Wert des davor abgerufenen ECMD devices.
woran liegt das??
kann es sein das der ebusd nicht lange genug auf die Antwort wartet??
die Fhemlog sagt dazu 2017.09.18 01:41:57 5: Cmd: >get Aussentemp Aussentemp<
2017.09.18 01:41:57 5: Starting notify loop for Aussentemp, 2 event(s), first is Aussentemp: 11.0
2017.09.18 01:41:57 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:57 5: End notify loop for Aussentemp
2017.09.18 01:41:57 5: Cmd: >get Vorlauf Vorlauf<
2017.09.18 01:41:57 5: Starting notify loop for Vorlauf, 2 event(s), first is Vorlauf: 25.6
2017.09.18 01:41:57 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:57 5: End notify loop for Vorlauf
2017.09.18 01:41:57 5: Cmd: >get Ruecklauf Ruecklauf<
2017.09.18 01:41:58 5: Starting notify loop for Ruecklauf, 2 event(s), first is Ruecklauf: 24.8
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for Ruecklauf
2017.09.18 01:41:58 5: Cmd: >get HKurve HKurve<
2017.09.18 01:41:58 5: Starting notify loop for HKurve, 2 event(s), first is HKurve: 0.4
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for HKurve
2017.09.18 01:41:58 5: Cmd: >get Wasserdruck Wasserdruck<
2017.09.18 01:41:58 5: Starting notify loop for Wasserdruck, 2 event(s), first is Wasserdruck: 1.8
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for Wasserdruck
2017.09.18 01:41:58 5: Cmd: >get RaumTemp RaumTemp<
2017.09.18 01:41:58 1: PERL WARNING: Argument "21.31;ok\n\n" isn't numeric in sprintf at (eval 36163) line 1.
2017.09.18 01:41:58 3: eval: { sprintf("%5.1f",$_) }
2017.09.18 01:41:58 5: Starting notify loop for RaumTemp, 2 event(s), first is RaumTemp: 21.3
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for RaumTemp
2017.09.18 01:41:58 5: Cmd: >get RaumSoll RaumSoll<
2017.09.18 01:41:58 5: Starting notify loop for RaumSoll, 2 event(s), first is RaumSoll: 21.0
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for RaumSoll
2017.09.18 01:41:58 5: Cmd: >get WWIst WWIst<
2017.09.18 01:41:58 1: PERL WARNING: Argument "42.44;ok\n\n" isn't numeric in sprintf at (eval 36169) line 1.
2017.09.18 01:41:58 3: eval: { sprintf("%5.1f",$_) }
2017.09.18 01:41:58 5: Starting notify loop for WWIst, 2 event(s), first is WWIst: 42.4
2017.09.18 01:41:58 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:58 5: End notify loop for WWIst
2017.09.18 01:41:58 5: Cmd: >get WWSoll WWSoll<
2017.09.18 01:41:59 5: Starting notify loop for WWSoll, 2 event(s), first is WWSoll: 50.0
2017.09.18 01:41:59 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:59 5: End notify loop for WWSoll
2017.09.18 01:41:59 5: Cmd: >get WW_Ladung WW_Ladung<
2017.09.18 01:41:59 5: ECMDDevice: Analyze command >{"r -f HwcDemand \n"}<
2017.09.18 01:41:59 5: Postprocessing "no\n\n (\156\157\012\012)" with perl command { $_ }.
2017.09.18 01:41:59 5: Postprocessed value is "no\n\n (\156\157\012\012)".
2017.09.18 01:41:59 5: Starting notify loop for WW_Ladung, 2 event(s), first is WW_Ladung: Aus\n\n
2017.09.18 01:41:59 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:41:59 5: End notify loop for WW_Ladung
2017.09.18 01:41:59 5: Cmd: >get HzPumpe HzPumpe<
2017.09.18 01:41:59 5: ECMDDevice: Analyze command >{"r -f WP \n"}<
2017.09.18 01:42:00 5: Postprocessing "off\n\n (\157\146\146\012\012)" with perl command { $_ }.
2017.09.18 01:42:00 5: Postprocessed value is "off\n\n (\157\146\146\012\012)".
2017.09.18 01:42:00 5: Starting notify loop for HzPumpe, 2 event(s), first is HzPumpe: off\n\n
2017.09.18 01:42:00 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:00 5: End notify loop for HzPumpe
2017.09.18 01:42:00 5: Cmd: >get HzMode HzMode<
2017.09.18 01:42:00 5: ECMDDevice: Analyze command >{"r -f Hc1OPMode \n"}<
2017.09.18 01:42:00 5: Postprocessing "Auto\n\n (\101\165\164\157\012\012)" with perl command { $_ }.
2017.09.18 01:42:00 5: Postprocessed value is "Auto\n\n (\101\165\164\157\012\012)".
2017.09.18 01:42:00 5: Starting notify loop for HzMode, 2 event(s), first is HzMode: Auto\n\n
2017.09.18 01:42:00 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:00 5: End notify loop for HzMode
2017.09.18 01:42:00 5: Cmd: >get WwMode WwMode<
2017.09.18 01:42:00 5: ECMDDevice: Analyze command >{"r -f HwcOPMode \n"}<
2017.09.18 01:42:00 5: Postprocessing "2\n\n (\062\012\012)" with perl command { $_ }.
2017.09.18 01:42:00 5: Postprocessed value is "2\n\n (\062\012\012)".
2017.09.18 01:42:00 5: Starting notify loop for WwMode, 2 event(s), first is WwMode: Auto\n\n
2017.09.18 01:42:00 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:00 5: End notify loop for WwMode
2017.09.18 01:42:00 5: Cmd: >get HcMode HcMode<
2017.09.18 01:42:00 5: ECMDDevice: Analyze command >{"r -c bai Mode \n"}<
2017.09.18 01:42:00 5: Postprocessing "Standby\n\n (\123\164\141\156\144\142\171\012\012)" with perl command { $_ }.
2017.09.18 01:42:00 5: Postprocessed value is "Standby\n\n (\123\164\141\156\144\142\171\012\012)".
2017.09.18 01:42:00 5: Starting notify loop for HcMode, 2 event(s), first is HcMode: Standby\n\n
2017.09.18 01:42:00 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:00 5: End notify loop for HcMode
2017.09.18 01:42:00 5: Cmd: >get Raumtemp Raumtemp<
2017.09.18 01:42:00 5: Cmd: >get FanspeedDay FanspeedDay<
2017.09.18 01:42:00 5: ECMDDevice: Analyze command >{"r -f FanLevelDay\n"}<
2017.09.18 01:42:00 5: Postprocessing "1\n\n (\061\012\012)" with perl command { sprintf("%1.0f",$_) }.
2017.09.18 01:42:00 5: Postprocessed value is "1 (\061)".
2017.09.18 01:42:00 5: Starting notify loop for FanspeedDay, 2 event(s), first is FanspeedDay: 1
2017.09.18 01:42:00 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:00 5: End notify loop for FanspeedDay
2017.09.18 01:42:00 5: Cmd: >get FanspeedNight FanspeedNight<
2017.09.18 01:42:00 5: ECMDDevice: Analyze command >{"r -f FanLevelNight\n"}<
2017.09.18 01:42:02 5: Postprocessing "1\n\n (\061\012\012)" with perl command { sprintf("%1.0f",$_) }.
2017.09.18 01:42:02 5: Postprocessed value is "1 (\061)".
2017.09.18 01:42:02 5: Starting notify loop for FanspeedNight, 2 event(s), first is FanspeedNight: 1
2017.09.18 01:42:02 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:02 5: End notify loop for FanspeedNight
2017.09.18 01:42:02 5: Cmd: >get WTMode WTMode<
2017.09.18 01:42:02 5: ECMDDevice: Analyze command >{"r -f Heatrecovery \n"}<
2017.09.18 01:42:04 5: Postprocessing "auto\n\n (\141\165\164\157\012\012)" with perl command { $_ }.
2017.09.18 01:42:04 5: Postprocessed value is "auto\n\n (\141\165\164\157\012\012)".
2017.09.18 01:42:04 5: Starting notify loop for WTMode, 2 event(s), first is WTMode: auto\n\n
2017.09.18 01:42:04 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:04 5: End notify loop for WTMode
2017.09.18 01:42:04 5: Cmd: >get WaermeRueck WaermeRueck<
2017.09.18 01:42:04 5: ECMDDevice: Analyze command >{"r -f ByPass \n"}<
2017.09.18 01:42:05 5: Postprocessing "on\n\n (\157\156\012\012)" with perl command { $_ }.
2017.09.18 01:42:05 5: Postprocessed value is "on\n\n (\157\156\012\012)".
2017.09.18 01:42:05 5: Starting notify loop for WaermeRueck, 2 event(s), first is WaermeRueck: on\n\n
2017.09.18 01:42:05 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:05 5: End notify loop for WaermeRueck
2017.09.18 01:42:05 5: Cmd: >get Disbalance Disbalance<
2017.09.18 01:42:05 5: ECMDDevice: Analyze command >{"r -f Disbalance \n"}<
2017.09.18 01:42:08 5: Starting notify loop for EBUS, 1 event(s), first is FAILED
2017.09.18 01:42:08 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:08 5: End notify loop for EBUS
2017.09.18 01:42:11 5: Starting notify loop for EBUS, 1 event(s), first is DISCONNECTED
2017.09.18 01:42:11 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:11 5: End notify loop for EBUS
2017.09.18 01:42:11 5: Postprocessing "empty string" with perl command { $_ }.
2017.09.18 01:42:11 5: Postprocessed value is "empty string".
2017.09.18 01:42:11 5: Starting notify loop for Disbalance, 1 event(s), first is Disbalance
2017.09.18 01:42:11 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:11 5: End notify loop for Disbalance
2017.09.18 01:42:11 5: Cmd: >get Ionisation Ionisation<
2017.09.18 01:42:11 5: ECMDDevice: Analyze command >{"r -f SDFlame \n"}<
2017.09.18 01:42:11 5: Postprocessing "-35\n\n (\055\063\065\012\012)" with perl command { $_ }.
2017.09.18 01:42:11 5: Postprocessed value is "-35\n\n (\055\063\065\012\012)".
2017.09.18 01:42:11 5: Starting notify loop for Ionisation, 2 event(s), first is Ionisation: -35\n\n
2017.09.18 01:42:11 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:11 5: End notify loop for Ionisation
2017.09.18 01:42:11 5: Cmd: >get Hz_hours Hz_hours<
2017.09.18 01:42:11 5: ECMDDevice: Analyze command >{"r -f HcHours \n"}<
2017.09.18 01:42:12 5: Postprocessing "240\n\n (\062\064\060\012\012)" with perl command { $_ }.
2017.09.18 01:42:12 5: Postprocessed value is "240\n\n (\062\064\060\012\012)".
2017.09.18 01:42:12 5: Starting notify loop for Hz_hours, 2 event(s), first is Hz_hours: 240\n\n
2017.09.18 01:42:12 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:12 5: End notify loop for Hz_hours
2017.09.18 01:42:12 5: Cmd: >get Hz_starts Hz_starts<
2017.09.18 01:42:12 5: ECMDDevice: Analyze command >{"r -f HcStarts \n"}<
2017.09.18 01:42:12 5: Postprocessing "15732\n\n (\061\065\067\063\062\012\012)" with perl command { $_ }.
2017.09.18 01:42:12 5: Postprocessed value is "15732\n\n (\061\065\067\063\062\012\012)".
2017.09.18 01:42:12 5: Starting notify loop for Hz_starts, 2 event(s), first is Hz_starts: 15732\n\n
2017.09.18 01:42:12 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:12 5: End notify loop for Hz_starts
2017.09.18 01:42:12 5: Cmd: >get Ww_hours Ww_hours<
2017.09.18 01:42:12 5: ECMDDevice: Analyze command >{"r -f HWcHours \n"}<
2017.09.18 01:42:12 5: Postprocessing "35800\n\n (\063\065\070\060\060\012\012)" with perl command { $_ }.
2017.09.18 01:42:12 5: Postprocessed value is "35800\n\n (\063\065\070\060\060\012\012)".
2017.09.18 01:42:12 5: Starting notify loop for Ww_hours, 2 event(s), first is Ww_hours: 35800\n\n
2017.09.18 01:42:12 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:12 5: End notify loop for Ww_hours
2017.09.18 01:42:12 5: Cmd: >get Ww_starts Ww_starts<
2017.09.18 01:42:12 5: ECMDDevice: Analyze command >{"r -f HwcStarts \n"}<
2017.09.18 01:42:12 5: Postprocessing "1874\n\n (\061\070\067\064\012\012)" with perl command { $_ }.
2017.09.18 01:42:12 5: Postprocessed value is "1874\n\n (\061\070\067\064\012\012)".
2017.09.18 01:42:12 5: Starting notify loop for Ww_starts, 2 event(s), first is Ww_starts: 1874\n\n
2017.09.18 01:42:12 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:12 5: End notify loop for Ww_starts
2017.09.18 01:42:12 5: Cmd: >get Pump_hours Pump_hours<
2017.09.18 01:42:12 5: ECMDDevice: Analyze command >{"r -f PumpHours \n"}<
2017.09.18 01:42:13 5: Postprocessing "16600\n\n (\061\066\066\060\060\012\012)" with perl command { $_ }.
2017.09.18 01:42:13 5: Postprocessed value is "16600\n\n (\061\066\066\060\060\012\012)".
2017.09.18 01:42:13 5: Starting notify loop for Pump_hours, 2 event(s), first is Pump_hours: 16600\n\n
2017.09.18 01:42:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:13 5: End notify loop for Pump_hours
2017.09.18 01:42:13 5: Cmd: >get LegioTag LegioTag<
2017.09.18 01:42:13 5: ECMDDevice: Analyze command >{"r -f HwcLegioStartDay \n"}<
2017.09.18 01:42:13 5: Postprocessing "23288\n\n (\062\063\062\070\070\012\012)" with perl command { $_ }.
2017.09.18 01:42:13 5: Postprocessed value is "23288\n\n (\062\063\062\070\070\012\012)".
2017.09.18 01:42:13 5: Starting notify loop for LegioTag, 2 event(s), first is LegioTag: 23288\n\n
2017.09.18 01:42:13 5: End notify loop for LegioTag
2017.09.18 01:42:13 5: Cmd: >get LegioZeit LegioZeit<
2017.09.18 01:42:13 5: ECMDDevice: Analyze command >{"r -f HwcLegioStartTime \n"}<
2017.09.18 01:42:13 5: Postprocessing "So\n\n (\123\157\012\012)" with perl command { $_ }.
2017.09.18 01:42:13 5: Postprocessed value is "So\n\n (\123\157\012\012)".
2017.09.18 01:42:13 5: Starting notify loop for LegioZeit, 2 event(s), first is LegioZeit: So\n\n
2017.09.18 01:42:13 5: End notify loop for LegioZeit
es föngt bei Disbalance an
2017.09.18 01:42:05 5: Cmd: >get Disbalance Disbalance<
2017.09.18 01:42:05 5: ECMDDevice: Analyze command >{"r -f Disbalance \n"}<
2017.09.18 01:42:08 5: Starting notify loop for EBUS, 1 event(s), first is FAILED
2017.09.18 01:42:08 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:08 5: End notify loop for EBUS
2017.09.18 01:42:11 5: Starting notify loop for EBUS, 1 event(s), first is DISCONNECTED
2017.09.18 01:42:11 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:11 5: End notify loop for EBUS
2017.09.18 01:42:11 5: Postprocessing "empty string" with perl command { $_ }.
2017.09.18 01:42:11 5: Postprocessed value is "empty string".
2017.09.18 01:42:11 5: Starting notify loop for Disbalance, 1 event(s), first is Disbalance
2017.09.18 01:42:11 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 01:42:11 5: End notify loop for Disbalance
in der ebusd log steht
2017-09-18 01:42:00.274 [update notice] update bai Status01 QQ=10: 25.0;24.0;11.000;-;42.0;off
2017-09-18 01:42:01.006 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:01.774 [update notice] update bai DateTime QQ=10: valid;01:42:02;18.09.2017;11.000
2017-09-18 01:42:01.992 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:03.582 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:04.560 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:05.521 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:07.444 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:08.177 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:10.238 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:10.955 [update notice] update bai Mode QQ=10: Standby
2017-09-18 01:42:11.171 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 01:42:12.113 [update notice] update bai Status01 QQ=10: 25.0;24.0;11.000;-;42.0;off
wobei das passen würde , da Disbalance vom Gerät 38 kommt. das Gerät 38 ist ein VR32 von Vaillant dahinter hängt die Lüftung (08), dort kommt es immerwieder zu verzögerten Antworten.
Kann man ebusd sagen das er länger auf die Antwort warten soll??? er bekommt sie ja , da der Wert von Disbalance (-35) im nächsten Gerät auftaucht.
mfg maik
was passiert denn, wenn Du den fehlerhaften an das Ende der Liste bringst ? Dann würde ja theoretisch "nur" kein Wert kommen. Würde auch ein gecachter, aber ein wenig älterer Wert reichen ? Dann das "-f" weglassen.
hmm.....
ich kanns mal probieren....
aber das Problem mit der extremen Latenz seitens der Lüftung (RecoVair+Vr32) ist mir ja bekannt und lässt sich nur mit einem 2ten Bus-Koppler direkt am RecoVair Ebus vor dem VR32 lösen.
meine Frage ist halt, der ebusd hat ja 9mal ein retry versucht nach 1er Sekunde. Kann man dieses erhöhen kann auf zb. 15 retry's ?
Die andere Sache ist ja auch noch, das er ja den Wert bekommen hat und dem falschen device zuordnet, das dürfte auch in keinem Fall passieren.
und heute nochmal, diesmal hat es öfter versucht plus einem "main error".
2017-09-18 13:12:00.428 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:01.171 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:02.741 [update notice] update bai Status01 QQ=10: 29.0;29.0;16.375;-;49.0;off
2017-09-18 13:12:03.056 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:05.356 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:06.317 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:07.284 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:08.768 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:09.539 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:10.971 [bus error] send to 38: ERR: read timeout
2017-09-18 13:12:10.971 [main error] send message part 0: ERR: read timeout
2017-09-18 13:12:11.743 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:12.486 [update notice] update bai Mode QQ=10: Standby
2017-09-18 13:12:12.701 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:13.655 [update notice] update bai Status01 QQ=10: 29.0;29.0;16.375;-;49.0;off
2017-09-18 13:12:13.877 [bus error] send to 38: ERR: read timeout, retry
2017-09-18 13:12:14.575 [bus error] send to 38: ERR: read timeout, retry
Auszug aus der Fhem Log
2017.09.18 13:12:07 5: Cmd: >get WaermeRueck WaermeRueck<
2017.09.18 13:12:07 5: ECMDDevice: Analyze command >{"r -f ByPass \n"}<
2017.09.18 13:12:10 5: Starting notify loop for EBUS, 1 event(s), first is FAILED
2017.09.18 13:12:10 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:10 5: End notify loop for EBUS
2017.09.18 13:12:13 5: Starting notify loop for EBUS, 1 event(s), first is DISCONNECTED
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for EBUS
2017.09.18 13:12:13 5: Postprocessing "empty string" with perl command { $_ }.
2017.09.18 13:12:13 5: Postprocessed value is "empty string"
2017.09.18 13:12:13 5: Starting notify loop for WaermeRueck, 1 event(s), first is WaermeRueck
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for WaermeRueck
2017.09.18 13:12:13 5: Cmd: >get Disbalance Disbalance<
2017.09.18 13:12:13 5: ECMDDevice: Analyze command >{"r -f Disbalance \n"}<
2017.09.18 13:12:13 5: Postprocessing "on\n\n (\157\156\012\012)" with perl command { $_ }.
2017.09.18 13:12:13 5: Postprocessed value is "on\n\n (\157\156\012\012)".
2017.09.18 13:12:13 1: PERL WARNING: Argument "on\n\n" isn't numeric in sprintf at (eval 55536) line 1.
2017.09.18 13:12:13 5: Starting notify loop for Disbalance, 2 event(s), first is Disbalance: on\n\n
2017.09.18 13:12:13 4: Closing connection WEBphone_192.168.2.34_60616 due to full buffer in FW_Notify
2017.09.18 13:12:13 5: End notify loop for Disbalance
diesmal hing er bei "get WaermeRueck WaermeRueck" und nach 3 Sekunden startet er den nächsten Befehl "get Disbalance Disbalance" dort erhält er nun den Wert "on" dieser stammt aber von "WaermeRueck".
mfg Maik
So,
habe jetzt
ECMDDevice: Analyze command >{"r -f ByPass \n"}< gegen ECMDDevice: Analyze command >{"r ByPass \n"}< getauscht.
mal sehen was passiert.
habe auch parallel auf ebusd 3.0 geupdated.
leider bindet er nun meine 38.v32.csv nicht mehr ein.
Geräte werden korrekt erkannt.
pi@ospi ~ $ ebusctl info
version: ebusd 3.0.v3.0
update check: OK, broadcast.csv: different version available, vaillant/08.bai.csv: different version available, vaillant/15.470.csv: different version available, vaillant/hcmode.inc: different version av
signal: acquired
symbol rate: 22
max symbol rate: 133
reconnects: 0
masters: 4
messages: 463
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004276']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 26: slave, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
pi@ospi ~ $ ebusctl scan result
08;Vaillant;BAI00;0518;7401;21;11;32;0010004276;0001;007809;N3
15;Vaillant;47000;0420;1403;21;14;32;0020171280;0082;031167;N9
26;Vaillant;47000;0420;1403;21;14;32;0020171280;0082;031167;N9
38;Vaillant;V32;0117;9802
mfg maik
Hallo zusammen,
ich habe mich mit dem Ebus Protokoll meiner Bartl Sole-Wärmepumpe Eco 6S HG mit TEM Controller beschäftigt und kann erste Ergebnisse vorlegen.
Grundlegende Parameter wie Soll-Ist-Werte (für Heizkreis, Wärmepumpe und Warmwasser) sind https://github.com/rellla/ebusd-configuration/tree/bartl_tem (https://github.com/rellla/ebusd-configuration/tree/bartl_tem) (vorerst nur lesend) in eine csv Datei verpackt.
Bevor ich mich ans Werte schreiben wage, würde ich mich gerne zuerst mit dem Auslesen der Expertenmenüs befassen. Hier könnte ich Hilfe gebrauchen:
Für den Zugriff auf die Fachmann-Parameter müssen an der Masterfernbedienung erst 2 Passwörter eingegeben werden, dann habe ich Zugriff auf die Parameter. Nach 15 min. Inaktivität wird das zurückgesetzt. Das funktioniert an der Wärmepumpe direkt einwandfrei.
1. Frage: Wie verbaue die Abfrage dieser Parameter inkl. der notwendigen Passwort Eingabe in meine Ebus Konfiguration? Oder muss fhem oder wer auch immer bei einer Abfrage dafür sorgen, dass die Passwörter vorher geschrieben werden oder eine Abfrage stattfindet, in welcher Menü-Ebene (0,1,2) wir uns befinden? Ohne Passworteingabe kommt übrigens bei Abfrage der versteckten Werte ein Error zurück.
2. Frage: Nach Eingabe der Passwörter verschieben sich die Adressräume des Controllers. D.h. Ein Wert auf Expertenebene (z.B. 0x0080004a) steht plötzlich für einen anderen Parameter als auf Userebene.
Gibt es das Problem auch bei anderen Herstellern bzw. hat jemand einen Ansatz parat, wie das zu lösen ist?
Ich bin relativer Neueinsteiger bei Ebusd und erstmal froh, was auslesen zu können. Mit fhem oder sonstigen Frontends habe ich mich noch nicht befasst.
Danke für eure Hilfe.
Gruß
Andreas
ZitatOder muss fhem oder wer auch immer bei einer Abfrage dafür sorgen, dass die Passwörter vorher geschrieben werden oder eine Abfrage stattfindet, in welcher Menü-Ebene (0,1,2) wir uns befinden?
Der Zugriff über EBUS kann durchaus unabhängig von der Bedienoberfläche sein. Bei Vaillant sind Experteneinstellungen auch durch Codenummern schützbar - können über EBUS aber trotzdem ausgelesen und modifiziert werden.
Sollte das bei diesem Hersteller wirklich anders sein (da bin ich noch skeptisch...), müsste man in der Tat etwas (z.B. in FHEM) programmieren, das dieses dann zustandsbehaftete Protokoll korrekt ausführt.
LG
pah
Danke für die schnelle Antwort. Leider ist es wohl so, siehe z.B. :
im Usermenu:
01 15 0621 04 6581000e / 0a b342 8d02f4016400 e001
-> b342 enspricht Parameter 05-051 (Warmwasser-Sollwert) und ergibt e001, d.h. 48.0 °C
nach Eingabe Passwort bekommt derselbe Menupunkt aber den Code 6592000e:
01 15 0621 04 6592000e / 0a b342 8d02f4016400 e001
und 6581000e wird zu 03-093 (Timer Zinenzuordnung)
01 15 0621 04 6581000e / 0a dd41 0900ffffff01 0000
Ohne Passworteingabe bringt ein Abruf von 6592000e durch Ebus einen Error.
Mir stellt sich die Frage, ob die verschiedenen Zugriffscodes für Warmwasser irgendwie gekoppelt sind (evtl. durch bit-Operationen) oder nach Passworteingabe einfach nur neu vergeben werden, was ich vermute. Dann müsste ich herausfinden, wie die Masterfernbedienung von der aktuellen Zugriffsebene erfährt bzw. diese aktiv abfragt, damit die Codes richtig gewählt werden. In irgendeiner Nachricht müssten da ja bits versteckt sein!?
Gruß
Andreas
Ich antworte mir schnell selbst. Ich glaube, ich habe es gefunden:
Warmwasser:
0115062104 04 ab004e / 0a 2b820000ff0000000000 = 2 (user-menu)
0115062104 04 ab004e / 0a 2b820000ff0000000200 = 6 (exp-menu)
Wärmepumpe:
0115062104 04 ab0042 / 0a 2b820000ff0000000000 = 1 (user-menu)
0115062104 04 ab0042 / 0a 2b820000ff0000000200 = 12 (exp-menu)
Heizkreis:
0115062104 04 ab004a / 0a 2b820000ff0000000000 = 5 (user-menu)
0115062104 04 ab004a / 0a 2b820000ff0000000200 = 13 (exp-menu)
Das taucht jeweils auf, wenn ich das Einstellungsmenu öffne - jeweils mit und ohne Passwort. Ich vermute, dass die letzten 2 byte der Antwort das Level angeben - 0 und 2.
Wenn ich mich nicht täusche, versucht die Master-FB hier zu erfahren, welche Einstellungsebene durch das Passwort geöffnet wurde. 2b82, sprich 04-043 ist in der Bedienungsanleitung nirgends vermerkt, würde nummernmäßig aber nahe an 04-040 Service-Passwort stehen ;)
D.h. für die Abfrage eines Wertes müsste man
für Experten-Ebene
(evtl. aktuelles Level abfragen) -> ggfs. Passwort setzen -> Wert abfragen mit Codes für Exp.
und für User-Ebene
aktuelles Level abfragen -> Wert abfragen mit Codes für User-Menu
Soweit so gut. Muss das dann Ebusd regeln, oder fhem?
Gruß
Andreas
UPDATE
das ändern von
"r -f ByPass \n"auf
"r ByPass \n" hat nichts gebracht.
Auch ein Update auf ebusd 3.0 brachte keine Änderung.
nun habe ich mal in den Start Befehl geschaut
EBUSD_OPTS="--receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
dort taucht --receivetimeout=100000auf,
diesen habe ich jetzt mal erhöht auf --receivetimeout=200000
zur Verständniss Frage, sind das Millisekunden?oder Was??
100.000 millis = 100 Sek. ?
nochwas....
kann ich bei -l /var/log/ebusd.log auch Datums oder Zeit Platzhalter benutzen, damit das Log nicht so gross wird??
mfg Maik
Zitat von: TiPpFeHlEr am 20 September 2017, 17:15:20
nochwas....
kann ich bei -l /var/log/ebusd.log auch Datums oder Zeit Platzhalter benutzen, damit das Log nicht so gross wird??
nimm doch Logrotate (https://forum.fhem.de/index.php/topic,29737.msg335970.html#msg335970), dann hast du die Größe im Griff!
LG
Zitat von: Mirko_2013 am 16 September 2017, 20:01:10
Habe ich gerade eben versucht, das gleiche Problem.
Gibt es eine Möglichkeit die knotig manuell zu erstellen?
ja klar. für die aktuelle config aus github kannst Du folgendes Kommando benutzen:
svn export --force https://github.com/john30/ebusd-configuration.git/trunk/ebusd-2.1.x/de/ /etc/ebusd/
Zitat von: TiPpFeHlEr am 18 September 2017, 16:13:24
aber das Problem mit der extremen Latenz seitens der Lüftung (RecoVair+Vr32) ist mir ja bekannt und lässt sich nur mit einem 2ten Bus-Koppler direkt am RecoVair Ebus vor dem VR32 lösen.
meine Frage ist halt, der ebusd hat ja 9mal ein retry versucht nach 1er Sekunde. Kann man dieses erhöhen kann auf zb. 15 retry's ?
das Problem mit dem VR32 ist, dass sich das Gerät als Bridge zu einem weiteren eBUS nicht an die standardisierten Zeiten der Spezifikation halten kann, denn es werden ja Nachrichten auf einem Bus empfangen, ausgewertet, an den anderen Bus gesendet, die Antwort abgewartet, und dann an den urspr. Bus als Antwort abgegeben.
Hier hilft nur, die Antwortzeit drastisch zu erhöhen mit "--receivetimeout=..." beim ebusd Start, andernfalls kann das gar nicht klappen.
Zitat von: TiPpFeHlEr am 19 September 2017, 10:01:40
leider bindet er nun meine 38.v32.csv nicht mehr ein.
was sagt denn das Logfile dazu?
Zitat von: TiPpFeHlEr am 20 September 2017, 17:15:20
diesen habe ich jetzt mal erhöht auf --receivetimeout=200000
zur Verständniss Frage, sind das Millisekunden?oder Was??
100.000 millis = 100 Sek. ?
Steht sowohl im wiki wie auch auf der Kommandozeilenhilfe von ebusd
Zitat von: john30 am 21 September 2017, 08:33:06
Steht sowohl im wiki wie auch auf der Kommandozeilenhilfe von ebusd
hi John,
mehr als 100.000 geht nicht!?
wenn ich mehr als 100000 angebe kommt das
pi@ospi /dev/serial/by-id $ sudo service ebusd start
[....] Starting ebusd: ebusdebusd: invalid receivetimeout
Try `ebusd --help' or `ebusd --usage' for more information.
also sind es laut Wiki 0,1 Sek ? 1.000.000µs = 1 Sek
mehr geht nicht??
werde dann wohl nen 2ten Ebus-Koppler benutzen müssen , schade.
mfg maik
Zitat von: TiPpFeHlEr am 21 September 2017, 17:06:52
mehr als 100.000 geht nicht!?
richtig, Maximum ist derzeit 100 ms, was im Normalfall schon weit hinter jeder sinnvollen Antwortzeit liegt.
Zitat von: TiPpFeHlEr am 21 September 2017, 17:06:52
werde dann wohl nen 2ten Ebus-Koppler benutzen müssen , schade.
Du kannst ja mal in src/ebusd/main.cpp Zeile 389 noch eine 0 an die 100000 dranhängen und dann höhere Werte probieren.
ZitatDu kannst ja mal in src/ebusd/main.cpp Zeile 389 noch eine 0 an die 100000 dranhängen und dann höhere Werte probieren.
hmmm... das würde bedeuten ich müsste ebusd neu kompilieren!?
das geht bei mir nicht. Ich musste die *.deb benutzen auf meinem pi, da etwas fehlt.
meine
gcc-g++
version ist zu alt und kann auf diesem system nicht aktuallisiert werden.
versucht hatte ich
pi@ospi ~ $ git clone https://github.com/john30/ebusd.git
dann
pi@ospi ~ $ ./autogen.sh
dort hies es
checking for g++-6... no
checking for g++-5... no
checking for g++-4.9... no
checking for g++-4.8... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=gnu++11... no
checking whether g++ supports C++11 features with -std=gnu++0x... no
configure: error: *** A compiler with support for C++11 language features is required.
mfg maik
Hi John,
erstmal Danke und große Bewunderung für deine Arbeit!
Eine Bitte hab ich:
könntest du bei der Überarbeitung der config-csv's noch das device e1 einfügen? Ich hab da 2 Ausseneinheiten und das bisher über symlinks gelöst (siehe config)
Ich bin am Umstieg auf V3.0 und da bin ich wieder drüber gestolpert.....
version: ebusd 2.1.422b8d6
signal: acquired
symbol rate: 27
masters: 3
messages: 1064
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;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=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
address 52: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/52.mc2.mc.4.csv"
address 53: slave, scanned "MF=Vaillant;ID=MC2 ;SW=0500;HW=6301", loaded "vaillant/53.mc2.mc.5.csv"
address e0: slave, scanned "MF=Vaillant;ID=OMU00;SW=0118;HW=5202", loaded "vaillant/e0.omu.0.csv"
address e1: slave, scanned "MF=Vaillant;ID=OMU00;SW=0118;HW=5202", loaded "vaillant/e1.omu.1.csv"
Herzlichen Dank
erwin
Zitat von: TiPpFeHlEr am 23 September 2017, 12:05:05
hmmm... das würde bedeuten ich müsste ebusd neu kompilieren!?
das geht bei mir nicht. Ich musste die *.deb benutzen auf meinem pi, da etwas fehlt.
Dann lass uns mal in die Trickkiste greifen:
Nimm mal noch --latency=100000 dazu, dann ist alles mit zusätzlicher Verzögerung von weiteren 100 ms erlaubt. --latency akzeptiert bis zu 200ms.
Zitat von: erwin am 23 September 2017, 22:38:03
könntest du bei der Überarbeitung der config-csv's noch das device e1 einfügen? Ich hab da 2 Ausseneinheiten und das bisher über symlinks gelöst (siehe config)
kein Thema, ist jetzt schon im 2.1.x Pfad als Symlink auf die e0.omu.csv drin.
Zitat von: john30 am 21 September 2017, 08:29:22
das Problem mit dem VR32 ist, dass sich das Gerät als Bridge zu einem weiteren eBUS nicht an die standardisierten Zeiten der Spezifikation halten kann, denn es werden ja Nachrichten auf einem Bus empfangen, ausgewertet, an den anderen Bus gesendet, die Antwort abgewartet, und dann an den urspr. Bus als Antwort abgegeben.
Hier hilft nur, die Antwortzeit drastisch zu erhöhen mit "--receivetimeout=..." beim ebusd Start, andernfalls kann das gar nicht klappen.
Hallo john30,
Die knotig habe ich eingespielt
Zitat von: john30 am 21 September 2017, 08:18:51
ja klar. für die aktuelle config aus github kannst Du folgendes Kommando benutzen:
svn export --force https://github.com/john30/ebusd-configuration.git/trunk/ebusd-2.1.x/de/ /etc/ebusd/
Die Konfiguration habe ich eingespielt, bei 2 der 3 Geräten wird auch die csv geladen.
broadcast datetime = no data stored
broadcast error = no data stored
broadcast hwcStatus = no data stored
broadcast id = no data stored
broadcast id = no data stored
broadcast load = no data stored
broadcast outsidetemp = no data stored
broadcast signoflife = no data stored
broadcast vdatetime = no data stored
general valuerange = no data stored
hmu ConsumptionThisYear10 = no data stored
hmu ConsumptionThisYear11 = no data stored
hmu ConsumptionThisYear12 = no data stored
hmu ConsumptionThisYear1 = no data stored
hmu ConsumptionThisYear2 = no data stored
hmu ConsumptionThisYear3 = no data stored
hmu ConsumptionThisYear4 = no data stored
hmu ConsumptionThisYear5 = no data stored
hmu ConsumptionThisYear6 = no data stored
hmu ConsumptionThisYear7 = no data stored
hmu ConsumptionThisYear8 = no data stored
hmu ConsumptionThisYear9 = no data stored
hmu ConsumptionTotal = no data stored
hmu currenterror = no data stored
hmu EnergyCool = no data stored
hmu EnergyHc = no data stored
hmu errorhistory = no data stored
hmu Hours = no data stored
hmu HoursCool = no data stored
hmu HoursHc = no data stored
hmu State = no data stored
hmu YieldThisYear10 = no data stored
hmu YieldThisYear11 = no data stored
hmu YieldThisYear12 = no data stored
hmu YieldThisYear1 = no data stored
hmu YieldThisYear2 = no data stored
hmu YieldThisYear3 = no data stored
hmu YieldThisYear4 = no data stored
hmu YieldThisYear5 = no data stored
hmu YieldThisYear6 = no data stored
hmu YieldThisYear7 = no data stored
hmu YieldThisYear8 = no data stored
hmu YieldThisYear9 = no data stored
hmu YieldTotal = no data stored
memory eeprom = no data stored
memory ram = no data stored
scan id = no data stored
scan.05 = no data stored
scan.08 = Vaillant;HMU00;0305;0403
scan.08 id = 21;16;41;0010016421;0006;005625;N5
scan.52 = Vaillant;VR_70;0109;2903
scan.52 id = 21;16;41;0020184843;0082;016043;N2
scan.76 = Vaillant;VWZ00;0305;0403
scan.76 id = (ERR: invalid position for 3176b5090124 / 00)
vr_70 currenterror = no data stored
vr_70 errorhistory = no data stored
vr_70 SensorData = no data stored
signal: acquired
symbol rate: 23
max symbol rate: 81
reconnects: 0
masters: 4
messages: 66
conditional: 0
poll: 0
update: 8
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0305;HW=0403", loaded "vaillant/08.hmu.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0305;HW=0403"
Einige der Werte können nicht abgefragt werden.
Ich würde mich gern daran machen, vorerst nur lesend, weitere Register auszulesen und die cdv zu erweitern.
Könnt Ihr mir einen Tip geben wie man am besten an das Thema rangeht, wie die Messages im Log erkannt / zum auslesen herangezogen werden können?
Danke
Mirko
Hallo,
ich habe an meiner Vaillant Wärmepumpe aroTherm VWL55/3 einen Multimatic 700 Heizungsregler.
Ich ging eigentlich davon aus dass das EBus Protokoll genormt sein müsste und es egal ist welcher Regler daran angeschlossen ist. Zumindest wenn es zunächst nur um das Auslesen der Werte geht.
Hat jemand einen Tipp wie ich die Werte ausgelesen bekomme?
Bisher habe ich nur die folgende Anzeige im FHEM
Tobias
ZitatEBus Protokoll genormt sein
Soso. Von wem denn ?
LG
pah
Allein die Formulierung "ich ging davon aus", dann noch ergänzt durch "eigentlich" zeugt doch von Nichtwissen, was keinesfalls zu kritisieren ist sondern für die meisten von uns der Hauptgrund, sich hier ans Forum zu wenden. Wozu also die provokative Gegenfrage??
Tobias,
welche Konfig benutzt Du denn? Zum 700 gibt es doch inzwischen eine recht ausgereifte CSV. Welche Infos möchtest Du denn auslesen?
(Oder geht es um die aroTherm VWL55/3? Auch hier dann aber: welche Werte sind gefragt, was liefert ein 'ebusctl info'?)
Sven
@TobiasR
Der eBus (https://de.wikipedia.org/wiki/EBus) ist in elektrischer Sicht festgelegt worden, sonst würde eine einheitliche Schnittstellenkommunikation nicht funktionieren. Was ein Low und ein High ist und in welcher Geschwindigkeit das serielle Signal übertragen wird muss daher von allen Anwendern die diesen Bus benutzen eingehalten werden.
Was nun die unterschiedlichen Hersteller von Geräten die diesen Bus verwenden daraus machen ist ihre Sache. Vaillant wird intern sicher Regeln haben wie sie den eBus verwenden. Was sie sich dabei gedacht haben und wie man das jetzt sinnvoll nutzen kann versuchen ja die Entwickler des ebusd zu rekonstruieren um es für uns nutzbar zu machen. eBusd ist alles eine private Entwicklung an der ein paar Leute viel Zeit und Gehirnschmalz hinein gesteckt haben und ihre Erkenntnisse kostenlos zur Verfügung stellen.
LG
Hallo Reinhard,
hallo alle anderen,
ich ging bisher davon aus das euch, den Entwicklern, das Protokoll auch Herstellerspezifisch bekannt ist.
Wenn das alles nur dich "Experimentieren" rausgekommen ist, dann habe ich jetzt noch größere Achtung vor euch!
Aber bei den Antworten muss ich davon ausgehen dass ich noch nicht alles was die Konfiguration angeht verstanden habe.
Ganz konkret: Ich ging davon aus dass durch die Kennung der Anlage im Protokoll die richtige CSV identifiziert wird? Muss ich nach deren Installation noch etwas machen?
@Sven777: Aus meiner Frage kannst du ablesen das ich da noch ein Verständnisproblem habe. Welche CSV müsste ich für den 700 den nutzen, bzw. wo muss diese liegen oder eingebunden werden?
Danke schon mal an alle für ihre Geduld mit mir
Tobias
Am besten ziehst Du nochmal je von ebusd und ebusd-configuration ein aktuelles Paket.
Die Konfig steht ansonsten in Github (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.700.csv), benötigt aber ein ebusd-Release nach Februar 2016, um zu funktionieren.
Sven
@John30
Zitat von: john30 am 24 September 2017, 09:52:40
Dann lass uns mal in die Trickkiste greifen:
Nimm mal noch --latency=100000 dazu, dann ist alles mit zusätzlicher Verzögerung von weiteren 100 ms erlaubt. --latency akzeptiert bis zu 200ms.
das hat geholfen!!!! ;D
für alle die das gleiche Problem habe mit nem VR32 von Vaillant, hier meine ebusd Startparameter.
EBUSD_OPTS="--latency=100000 --receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"Danke
mfG Maik
@Sven77: Die Frage war durchaus berechtigt. Denn wer sich auch nur minimal über das Protokoll informiert. wird lesen, dass es eben durch unterschiedliche Hersteller sehr unterschiedlich eingesetzt wird, dass keine "offizielle" Dokumentation vorliegt und alle Decodierungen über Reverse Engineering erfolgt sind. Auch die Provokation ist beabsichtigt - denn genau diese minimale Information sollte man sich beschaffen.
LG
pah
Zitat von: TiPpFeHlEr am 25 September 2017, 18:47:55
das hat geholfen!!!! ;D
okay, habs mal hier festgehalten (https://github.com/john30/ebusd/issues/109), damit das nicht in Vergessenheit gerät.
Hallo zusammen,
ich habe erfolgreich mal testweise meine Warmwasser-Ist Temperatur in FHEM über ECMD eingebunden:
get Warmwasser cmd {"r -f -c ww_param1 temp_soll temp\n"}
get Warmwasser expect ".*\n*"
get Warmwasser postproc { $_ }
Jetzt aber zurück zur Frage mit den bedingten Abfragen -> https://forum.fhem.de/index.php/topic,29737.msg688302.html#msg688302 (https://forum.fhem.de/index.php/topic,29737.msg688302.html#msg688302).
Es ist tatsächlich so, dass ich über ebusctl das aktuelle Einstellungs-Level (User oder Fachmann) abfragen kann. Ich kann dann auch das Passwort setzen um die Codes für die Fachmann-Ebene zu erreichen. Sinnvollerweise übernimmt diesen Vorgang (Abfrage Level->evtl. Passwort setzen->Einsteller abfragen/setzen) FHEM und nicht ebusd.
Wie verpacke ich das jetzt in eine Class-Definition? Ich tue mich da mit der Syntax schwer.
Vom Prinzip her (d.h. die Syntax unten wird wahrscheinlich nicht passen ;) ) brauche für den Fall eines Experteneinstellers sowas in der Art:
get Warmwasser cmd {if({"r -f -c globals parameter_level status\n"} = 'User Level') \
{"w -c globals global_password 256"};;{"r -f -c ww_param2 temp_soll temp\n"}}
get Warmwasser expect ".*\n*"
get Warmwasser postproc { $_ }
und für einen Userebenen-Einsteller:
get Warmwasser cmd {if({"r -f -c globals parameter_level status\n"} = 'Expert Level') \
{"w -c globals global_password 000"};;{"r -f -c ww_param1 temp_soll temp\n"}}
get Warmwasser expect ".*\n*"
get Warmwasser postproc { $_ }
Wie verpacke ich diese bedingte Abfrage korrekt in FHEM oder gibt es eine "klügere" Herangehensweise?
Danke und Gruß
Andreas
PS: Ich habe die Code-Schnipsel oben noch nicht ausprobiert...
Hallo,
ich habe ein ähnliches System wie Mirko_2013 und auch dasselbe Problem.
Meine Geräte:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/bai.308523.inc", "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
Zu 76 habe ich keine csv gefunden.
Das System ist Vaillant VWF 87/4 (Sole Wärmepumpe).
Viele Daten kann ich mit den vorhandenen CSV abrufen.
Interesse habe ich noch an Sole Temperatur Ein- und Ausgang sowie Soledruck.
Folgende Fragen:
1) Wo kann ich erkennen, welcher Master welche Funktion hat? Wofür steht bspw. "VWZ00"? Was ist HMU00, was ist BAI?
2) Wie kann ich am besten rausfinden, wonach ich fragen muss, um die Sole-Eingangstemperatur zu finden? (Dieser Wert wird an der Wärmepumpe in einem Menü angezeigt)
3) Ich habe immer wieder einige "unknown" Zeilen, die sich so oder ähnlich immer wieder wiederholen:
2017-10-01 21:47:56.379 [update notice] unknown MS cmd: 1076b5110101 / 09ff3b500aff750000ff
2017-10-01 21:47:56.645 [update notice] unknown MS cmd: 1076b512030f0201 / 07ae030000800f03
2017-10-01 21:47:57.177 [update notice] unknown MS cmd: 1076b51009000000ffffff010000 / 0101
Gibt es da Tips wie man am besten vorgeht? Oder einfach nur stumpf grab result decode und suchen?
Danke & Gruß,
Steffen
Hi steffen
also, im Vaillant Ebus hat das Heizgerät immer die Master 03 + Slave 08 (bai)
Der erste Raumregler Master 10 + Slave 15 (VRC700)
Die 71/76 ist ein Weiteres Gerät zb. Solar?? könnte der VR71 sein?
In Luftwärmepumpen von Vaillant existieren immer 2 Geräte (Inneneinheit & Ausseneinheit), da du aber eine Sole WP (nur Inneneinheit?) hast, kann das ja nicht sein.
1. Was bedeutet HMU00, VWZ00, .... -> dies ist eine Vaillant Abkürzung (englisch), der ID
beim Raumregler ist die ID 70000 = MultiMatic700
2. nur durch auslesen, und vergleichen.
Ich habe dazu ein script verwendet das den kpl speicherbereich abfragt und die Antworten logt.
dann kann man nach der Temp suchen und kennt den Speicherbereich im Regler und erstellt daraus eine eigene CSV
script ist im Anhang
#!/bin/sh
port=8889
if [ "x$1" = "x-p" ]; then
shift
port=$1
shift
fi
addr=08
if [ "x$1" = "x-a" ]; then
shift
addr=$1
shift
fi
for i in $(seq 16000 99999)
do
h=`printf "%4.4X" $i`
ret=`echo "hex ${addr}b509030d${h##??}${h%%??}"|nc localhost $port|head -n 1`
echo $i "=" ${h##??}${h%%??} "=" $ret
echo $i "=" ${h##??}${h%%??} "=" $ret >> ebusregister.txt
done
bei port bitte deinen Adapterport eintragen
bei addr bitte die zu scannende Ebus Adresse eintragen (08, 15, 76,...)
bei seq die Speicher/Register von bis eintragen die abgefragt werden sollen (seq 1 10000) 1-10000
das Ergebniss wird in der ebusregister.txt gespeichert.
3. + 4. es gibt einen Ebus standart nach dem die Nachrichten aufgebaut sind suche mal nach ebus spezifikation.
mfg maik
Hallo TiPpFeHlEr,
vielen Dank erstmal für Deine Infos!
Speicherbereich durchsuchen... na gut, wieso nicht :) Aber woher weiß ich welchen?
Da würde ich aber gerne noch Details zu Deiner herangehensweise wissen.
Ich habe ja 3 "interessante" Master: 08, 15, 76 (gut, könnte ich alle durchsuchen)
"hex ${addr}b509 03 0d${h##??}${h%%??}"
b5 ist klar (vaillant), aber wieso soll ich gerade nach 09 suchen?
03 ist auch klar (Länge)...
Aber 0D? wieso gerade das?
Um die Temperatur (zb 12.3 Grad) zu finden muss man die in den hex-ausgaben ja auch erstmal erkennen. Wie machst Du das?
Danke & Gruß,
Steffen
Die Protokolle sind systematisch aufgebaut - nur leider kennen wir die volle Systematik nicht. Insofern sind die Vorschläge durchaus sinnvoll, siehe Anlage.
LG
pah
Zitat von: steffen79 am 02 Oktober 2017, 08:47:36
Um die Temperatur (zb 12.3 Grad) zu finden muss man die in den hex-ausgaben ja auch erstmal erkennen. Wie machst Du das?
Genau hier ist ja die (Hand)Arbeit gefragt!
Mit dem genannten Script kannst Du bestimmte Bereiche abfragen.
WELCHE Bereiche Du abfragst, musst Du durch Probieren herausfinden. Entweder mal in CSVs anderer Wärmepumpen suchen oder die "unknown MS" als Anhaltspunkt nehmen. Dazu vorher wie schon von den Vorrednern angesprochen erstmal ein Grundwissen zum Aufbau der EBus-Nachrichten anlesen.
Ich habe dann, nachdem ich einen oder mehrere Bereiche gefunden hatte die irgendwelche Hex-Daten zurückgeben, die Ausgabe in eine Textdatei geschrieben und das ganze mehrmals am Tag wiederholt. Danach dann die Ausgabe(n) vergleichen, um zu sehen welche Werte sich wann ändern.
Außerdem am Besten gleich bei der Aufnahme die Ist-Werte der gesuchten Temperaturen mit notieren, dann kann man gleich versuchen mit den bekannten Datentypen (s. Wiki) aus den Hex-Daten genau diesen Wert zu finden.
Ich hatte mir mal ein Script geschrieben, was versucht die Hex-Ausgabe in alle möglichen Datentypen umzurechnen. Es müsste evtl. angepasst werden, weil ich mich auf die spezifische Rückgabe der VRC700 konzentriert hatte:
#!/bin/bash
RESONLY=0
if [ "$1" == "-" ] ; then
RESONLY=1
else
INP=$1
fi
#export RESONLY
if [ "$INP" == "" ] ; then
INP="-"
fi
cat $INP | /usr/bin/awk '
/.+/ {
hex = "X"
if ($2 == "/") {
hexmsg = $3
} else if ($3 == "/") {
hexmsg = $4
} else {
hexmsg = $1
}
if (length(hexmsg) > 11) {
# assume trailing register of VRC700 messages
if (length(hexmsg) > 17) {
hex = substr(hexmsg, length(hexmsg) - 7)
} else if (length(hexmsg) == 16) {
hex = substr(hexmsg, length(hexmsg) - 5)
} else if (length(hexmsg) == 14) {
hex = substr(hexmsg, length(hexmsg) - 3)
} else if (length(hexmsg) == 12) {
hex = substr(hexmsg, length(hexmsg) - 1)
}
# otherwise assume trailing length for normal messages
} else if (length(hexmsg) > 9) {
hex = substr(hexmsg, length(hexmsg) - 7)
} else if (length(hexmsg) == 8) {
hex = substr(hexmsg, length(hexmsg) - 5)
} else if (length(hexmsg) == 6) {
hex = substr(hexmsg, length(hexmsg) - 3)
} else if (length(hexmsg) == 4) {
hex = substr(hexmsg, length(hexmsg) - 1)
}
# convert reverse hex to dec
dec=0
sch=0
uch=0
sint=0
uint=0
ulng=0
exptype=0
expcls=0
if (length(hex) > 1) {
dec += index("123456789abcdef",tolower(substr(hex,2,1)))
sch = dec + (index("123456789abcdef",tolower(substr(hex,1,1)))%8)*16
if (int(index("123456789abcdef",tolower(substr(hex,1,1)))/8) == 1) sint = -sint
dec += index("123456789abcdef",tolower(substr(hex,1,1)))*16
uch = dec
}
if (length(hex) > 3) {
dec += index("123456789abcdef",tolower(substr(hex,4,1)))*256
sint = dec + (index("123456789abcdef",tolower(substr(hex,3,1)))%8)*4096
if (int(index("123456789abcdef",tolower(substr(hex,3,1)))/8) == 1) sint = -sint
dec += index("123456789abcdef",tolower(substr(hex,3,1)))*4096
uint = dec
}
if (length(hex) > 5) {
dec += index("123456789abcdef",tolower(substr(hex,6,1)))*65536
exptype = dec + (index("123456789abcdef",tolower(substr(hex,5,1)))%8)*1048576
# + 1<<23
exptype += 8388608
if (int(index("123456789abcdef",tolower(substr(hex,7,1)))/8) == 1) exptype = -exptype
dec += index("123456789abcdef",tolower(substr(hex,5,1)))*1048576
}
if (length(hex) > 7) {
dec += index("123456789abcdef",tolower(substr(hex,8,1)))*16777216
dec += index("123456789abcdef",tolower(substr(hex,7,1)))*268435456
ulng = dec
expcls =int(index("123456789abcdef",tolower(substr(hex,5,1)))/8)
expcls+=index("123456789abcdef",tolower(substr(hex,8,1)))*2
expcls+=(index("123456789abcdef",tolower(substr(hex,7,1)))%8)*32
}
if (expcls < 120) {
exptype = 0
} else {
# exptype = exptype / exp( (150-expcls) * log(2))
exptype = exptype / (2 ^ (150-expcls))
}
if ("'"$RESONLY"'" == "0") {
printf $0
if (length(hex) == 2) printf " --> "
else if (length(hex) == 4) printf " --> "
else if (length(hex) == 6) printf " --> "
else if (length(hex) == 8) printf " --> "
}
if (length(hex) == 8) {
printf "ULG:%10d", ulng
if (hex != "ffffff7f") printf " ; EXP: " exptype
} else if (length(hex) == 6) {
# special case for time and date
sch = index("123456789abcdef",tolower(substr(hex,2,1)))
sch += index("123456789abcdef",tolower(substr(hex,1,1)))*16
printf "%3d /", sch
sch = index("123456789abcdef",tolower(substr(hex,4,1)))
sch += index("123456789abcdef",tolower(substr(hex,3,1)))*16
printf "%3d /", sch
sch = index("123456789abcdef",tolower(substr(hex,6,1)))
sch += index("123456789abcdef",tolower(substr(hex,5,1)))*16
printf "%3d", sch
} else if (length(hex) == 4) {
printf "UIN:%5d ; D2B:%8.3f ; D2C:%8.2f", uint, (sint/256), (sint/16)
} else if (length(hex) == 2) {
printf "UCH:%3d ; D1C:%5.1f", uch, (uch/2)
}
print ""
}
'
Dieses kann einfach zum Pipen der Ausgabe eines anderen Scriptes benutzt werden.
VG, Sven
Hallo,
ich bin von EBUSD 1.1 auf 3.0 umgestiegen und habe nun ein Problem: Bislang konnte ich die Teillast (hier WW) mit
w -c bai#install partloadhwckw 10
einstellen. Nun kommt aber die Fehlermeldung
ERR: element not found
obwohl "partloadhwckw" unter find aufgelistet wird. In der CSV ist das mit "wi" gekennzeichnet, das wurde bislang immer mit "#install" geschrieben.
Wie mach ich das denn richtig ?
Sven77, vielen Dank, ich werde das mal als Grundlage nehmen! :)
Zitat von: cs-online am 06 Oktober 2017, 23:06:47
obwohl "partloadhwckw" unter find aufgelistet wird. In der CSV ist das mit "wi" gekennzeichnet, das wurde bislang immer mit "#install" geschrieben.
Wie mach ich das denn richtig ?
am einfachsten ebusd mit zusätzlichem Parameter "--accesslevel=*" starten.
BINGO :-) und dann ohne das #install, dann läufts :-)
Daaaaanke !!!
Hallo,
ich habe Probleme beim Schreiben/Verändern des HwcOPMode bei meiner Vaillant calorMATIC 470/4.
Der ebusd ist aktuell aus der git kompiliert, die csv-Dateien sind auch aus der git der ebusd-configuration.
Der HwcOPMode ist in der vaillant/15.470.csv als " r;w,,HwcOPMode... " abgeändert.
Der ebusd arbeitet ansonst (lesen und senden, auch in Version 2.x) seit ca. 12 Monaten völlig "lautlos" und ohne
weitere Probleme (Dank an john30 und pah und Reinhart und allen weiteren Zuarbeitern hierfür). :)
Erreichen möchte ich eine Zustandsänderung des HwcOPMode von "auto" auf "off" bzw. von "off" auf "auto".
Das senden des Befehls (ebusctl w -c 470 HwcOPMode off) wird ohne Fehler ausgeführt, eine Umschaltung in
der 470er findet jedoch nicht statt.
Hier (https://forum.fhem.de/index.php/topic,29737.msg383856.html#msg383856) z.B. gab es wohl auch schon Probleme mit dem HwcOPMode der 470er, eine richtige Lösung für
mein Problem kann ich da dann aber nicht rauslesen.
a)
Gibt es ggf. eine andere Möglichkeit, um den Warmwasserkreis von "auto" auf "aus" bzw. zurück
per ebusd zu ändern (z.B. per "Umweg" per bai?)?
b)
Wie und wo muß ich jetzt ansetzen/testen/ausspielen, um ein Werteänderung des HwcOPMode
auch in meiner starrköpfig 470/4er-Version zu ermöglichen?
Danke schon 'mal im voraus,
sua
PS:
Hier die Ausgabe der ebusd-Konfiguration und die Befehle/Ergebnisse dazu:
root@DietPi2B:~# ebusctl info
version: ebusd 3.0.v3.0-10-g2adbe24
signal: acquired
symbol rate: 25
max symbol rate: 148
reconnects: 0
masters: 3
messages: 449
conditional: 2
poll: 1
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0113;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015600']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
root@DietPi2B:~# ebusctl w -c 470 HwcOPMode off
done
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
root@DietPi2B:~# ebusctl w -c 470 HwcOPMode 0
done
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
Hallo,
bei mir sehen die Einträge in der Klassendatei für Warmwasser so aus:
set Speicher_laden cmd {"w -c 470 hwcOPMode 6\n"}
set Partymodus cmd {"w -c 470 hwcOPMode 4\n"}
set Speicherautomatik cmd {"w -c 470 hwcOPMode 2\n"}
und für Sommer / WInterbetrieb der Heizung
set Sommerbetrieb cmd {"w -c 470 hc1opmode 5\n"}
set Heizautomatik cmd {"w -c 470 hc1opmode 2\n"}
Das Display der 470 braucht einen Moment, bis es umschaltet.
Die CSV musste ich bei mir zum Schreiben so ändern (nur der Anfang der Zeile)
r;w,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200".......................
Grüße
Christian
Hallo Christian,
danke für Deine Infos, damit sollten meine o.g. Versuche ja prinzipiell schon 'mal richtig sein.
Zitat von: cs-online am 15 Oktober 2017, 19:46:08
bei mir sehen die Einträge in der Klassendatei für Warmwasser so aus:
set Speicher_laden cmd {"w -c 470 hwcOPMode 6\n"}
set Partymodus cmd {"w -c 470 hwcOPMode 4\n"}
set Speicherautomatik cmd {"w -c 470 hwcOPMode 2\n"}
... Das Display der 470 braucht einen Moment, bis es umschaltet.
Bei mir erfolgt dann leider keine Umschaltung, auch nicht nach einer Wartezeit...
Ich denke, ich habe da so eine 470/4-er-Version, die sich 'mal wieder von den allg. 470-er Version unterscheidet. :-(
Deshalb meine o.g. Frage b):
Wo/wie soll ich da jetzt ansetzen?
An welchem Sende-Wert, bzw. an welcher Sende-Befehlsänderung, wäre da der sinnvollste Ansatzpunkt zum Ändern und Austesten?
Danke,
sua
Hallo,
was kommt denn dabei heraus, wenn Du nach dem Setzen mit r -f hwcOPMode abfragst, ob das gesetzt wurde ? Ich weiß, daß ich zuerst da auch Probleme mit hatte...
Hallo Christian,
ja, ich hatte das mit dem zu beachteten "-f" auch schon etwas weiter vorne bei Dir gelesen, das ist aber leider wohl hier nicht mein Problem...
Bei mir ändert sich der Wert (nach dem ebusd-schreiben) weder in der 470/4-er (weder mit warten, noch direkt), als auch nicht per ebusd-Abfrage, trotz der vorherigen positiven ebusd-schreib-Rückmeldung.
Oben, im angehängten Konsolen-log auf dem Linux-System mit dem ebusd, sieht man die Befehle und das Ergebnis, ich hänge die hier aber noch einmal direkt an.
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
root@DietPi2B:~# ebusctl w -c 470 HwcOPMode off
done
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
root@DietPi2B:~# ebusctl w -c 470 HwcOPMode 0
done
root@DietPi2B:~# ebusctl r -f -c 470 HwcOPMode
auto
Jedes anderes Schreiben auf den ebus per ebusd funktioniert in der 470/4-er (z.B. Warmwassersolltemperatur = HwcTempDesired),
nur eben der HwcOPMode (mit gesetzten "r;w,, ...") nicht...
Watt nu?
;-(
sua
...und mit 2, 4 oder 6 tut sich auch nichts beim wieder auslesen ?
Dann fällt John vielleicht noch was ein ?
@sua
Als du die csv angepasst hast, hast du die csv neu einlesen lassen?
ebusd ggf neu starten.
Mfg Maik
...was mir gerade einfällt ist evtl. das Rechtemanagement, das John eingeführt hat. Irgendwo oben hatte er mir geschrieben, wie man EBUSD starten muss, damit man auch alle Rechte zum Schreiben hat.
Hallo Christian, hallo Maik,
ich glaube, ich habe jetzt alle Varianten durch getestet, sowohl das senden per Ziffer (1, 2, 0) als auch das senden als "Befehlswort" (off, auto, ...), auch immer den ebusd neu gestartet bzw. gleich neu gebootet usw. (der ebusd bringt ja da dann auch ggf. entsprechende Fehler-Rückmeldungen).
Ich habe auch die 470/4-er per Hand umgeschaltet und dann den entgegengesetzten ebusd-Befehl dazu abgesetzt:
Jeweils eine positive Befehlsausführung des ebusd ---> aber keine Reaktion an und in der 470/4-er (siehe o.g. Log). :(
Das reine lesen des HwcOPMode zeigt aber immer den richtigen, den in der 470/4-er jeweils vorhandenen, reellen Anlagenzustand.
Zitat von: cs-online am 17 Oktober 2017, 08:58:38
...was mir gerade einfällt ist evtl. das Rechtemanagement...
Das würde zumindest dann beim schreiben eine Fehlermeldung des ebusd bringen, ich habe dem ebusd aber auch immer mit der Option "--accesslevel=*" gestartet.
Für mich sieht es mit "meiner" 470/4-er-Variante da wohl leider so aus (Mist!...), daß der HwcOPMode darin ein nur-lesen-Wert ist.
Ich glaube 'eh nicht, daß es ein ebusd-Problem ist, sondern es ist wohl irgend etwas Vaillant-"spezial-vertüdelt-verbogenes", wenn es nicht sogar ein Bug in der internen Vaillant-Software "meiner" 470/4-er-Variante ist... :(
sua
Hi soa,
Welche 470er hast du genau?
ich habe den 470/4
Ich werde mal bei mir schauen ob ich den Wert schreiben kann.
Mfg Maik
UPDATE:
also ich kann auch nicht schreiben!!
pi@ospi ~ $ ebusctl r -f -c 470 HwcOPMode
2
pi@ospi ~ $ ebusctl w -c 470 HwcOPMode 0
done
pi@ospi ~ $ ebusctl r -f -c 470 HwcOPMode
2
auch das schreiben per hex ist nicht möglich!!
pi@ospi ~ $ ebusctl w -h 15b509040e420000
00
pi@ospi ~ $ ebusctl r -h 15b509030D4200
0102
mfg Maik
Zitat von: cs-online am 17 Oktober 2017, 08:58:38
...was mir gerade einfällt ist evtl. das Rechtemanagement, das John eingeführt hat. Irgendwo oben hatte er mir geschrieben, wie man EBUSD starten muss, damit man auch alle Rechte zum Schreiben hat.
wenn man das Recht nicht hätte, würde ebusd eine entsprechende Meldung ausgeben.
Mir scheint es so, dass das Gerät die Schreibnachricht zwar quittiert, aber nicht wirklich umsetzt.
Sprich: Es muss einen anderen Weg geben, den Modus zu setzen.
Schon mal das relativ neue SetMode aus hwcmode.inc ausprobiert?
Sollte bspw. mit "write -c hwc SetMode auto" klappen.
Hallo,
habe die calormatic 630/3 als Mehrkreisregler im Einsatz. Hat schon jemand herausbekommen, wie man die Werte der 3 Heizkreise ausliest?
Heizkreis 1 habe ich über vaillant/50.vr630.mc.csv
Heizkreis 3 kommt über vaillant/51.vr630.mc.3.csv
Für Heizkreis 2 fehlen mir noch sämtliche Daten. Und bei den anderen Kreisen wäre die Mischerposition eventuell noch interessant. Hat jemand eine Idee?
Danke gevoo
Poste mal bitte die Ausgabe von "ebusctl info", man müsste erstmal schauen, welches Gerät die anderen Kreise (Nr. 2) haben.
Ich habe nur einen VRC700 mit VR71 - bei diesem kann man definitiv NICHT die Mischerposition auslesen, nur ob und wie weit sich dieser bewegt bzw. bewegen soll. Wenn er still steht, ist die Position unbekannt. Ich glaube auch nicht, dass Vaillant früher Mischer mit Rückmeldung der Ist-Stellung eingesetzt hat...
NACHTRAG:
Habe mir die beiden CSVs mal angesehen und vermute, dass die 50 und 51 aufs gleiche Gerät zeigen und sich womöglich über beide identische Abfragen durchführen lassen - so ähnlich verhält sich die VRC700 als 15 und ec (Solar). Kannst ja mal folgende Hex-Nachrichten abfragen (ebusd mit --enablehex starten) und dazu die Vorlauftemperaturen der 3 Heizkreise schreiben:
ebusctl hex 50b509030d0100 ; ebusctl hex 50b509030d0200 ; ebusctl hex 50b509030d0300
ebusctl hex 51b509030d0100 ; ebusctl hex 51b509030d0200 ; ebusctl hex 51b509030d0300
Ich vermute mal, dass in 0100 und 0300 beide Male die abfragbaren Vorlauftemperaturen der HK 1 und 3 sind und in der 0200 beide Male die (unbekannte) Vorlauftemperatur des 2. Kreises ist.
Hallo Sven,
die Eingaben
ebusctl read -h 50b509030d0100
und
ebusctl read -h 51b509030d0300
liefern Ergebnisse. Alle anderen Varianten bringen
ERR: element not found.
So einfach war es leider nicht. Trotzdem danke für die Idee.
Gibt es irgenwo eine kurze Erläuterung, wie die csv Dateien funktionieren?
Kann ich z.B. in der vaillant/51.vr630.mc.3.csv zusätzlich zu den "B509"
Befehlen noch "B504" einbauen? Oder erfordert das dann eine separate Datei?
Und wie funktioniert das dann mit der Addressierung?
Danke gevoo
Starte bitte ebusd mit --enablehex (in /etc/default/ebusd nachtragen) und dann wie geschrieben mit "hex" statt "r -h". Anderenfalls lässt er dich nur Werte abfragen, die auch in der CSV definiert sind - für solche Tests wäre es aber zu aufwendig, diese alle zu definieren.
Es fehlt auch die Ausgabe von 'ebusctl info'!
Zu den CSVs überfliege bitte mal das Wiki - hier hat sich John viel Mühe gegeben, alles zu erklären:
https://github.com/john30/ebusd/wiki
Hallo,
ich benötige noch mal eine Hilfe bei der Abfrage aus FHEM.
Ich erhalte die Aussentemperatur auf meinem Heizungs-Raspi über
ebusctl r -m 10 outsidetemp
6.500
In der bai00.cfg meines FHEM Raspi habe ich dazu
# Aussentemperatur
get Aussentemp cmd {"r -m 10 outsidetemp temp\n"}
get Aussentemp expect ".\n*"
get Aussentemp postproc { sprintf("%5.1f",$_) }
in der fhem.cfg meines FHEM Raspi habe ich es so beschrieben:
define Aussentemp ECMDDevice bai00.class
attr Aussentemp IODev EBUS
attr Aussentemp group Vaillant
attr Aussentemp icon temp_outside
attr Aussentemp room Vaillant
Die ECMD Verbindung stelle ich so her:
define EBUS ECMD telnet 192.168.0.113:8888
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Vaillant
Leider kommt die Temperatur im FHEM aber nicht an. Sie bleibt immer auf 0.0.
Habe ich jetzt irgend etwas übersehen?
wenn du nur den Buffer abfragst ( -m ) dann lasse das Filter "temp" weg.
also so sollte es dann klappen
get Aussentemp cmd {"r -m 10 outsidetemp"}
KG
Hallo,
das hat leider nichts gebracht.
Gibt es noch eine andere Möglichkeit wie ich die Verbindung von einem zum anderen Raspberry testen kann?
Ja, da müsste der STATE vom ECMD Device auf "opened" stehen.
Du kannst aber auch vom PC aus in einer Shell "Telnet ipadresse 8888" aufrufen und testen ob die Verbindung zum Ebus Raspi klappt. Da muss der Cursor links oben linken.
So wie du es gepostet hast, wird ja outsidetemp vom eBus Raspi ordentlich ausgelesen. FHEM hast schon einmal neu gestartet?
LG
Hallo Reinhard,
der STATE vom ECMD sthet auf "opened". Und er ändert auch seinen Status wenn ich meinen Heizungsraspberry neu starte.
Telnet vom Windows PC klappt auch!
Ichhabe hier mal zwei Bilder angefügt.
Einmal der ECMD und meiner Aussentemp Device. Vielleicht ist da was falsch?
ich kann da nichts außergewöhnliches entdecken warum das nicht funktionieren sollte.
Ich habe mir jetzt nicht den ganzen Fall gelesen, aber warum fragst du nicht mit forced direkt ab?
get Aussentemp cmd {"r -f outsidetemp temp\n"}
LG
hm,
da bekomme ich ERR: element not found
ich habe jetzt nachgeschaut, du hast die Wärempumpe und die Multimatic 700.
mach einmal ebusd --checkconfig
Aber ich glaube in deinem Fall gibt es noch keine CSV, deshalb geht das nicht und du musst doch die Broadcastmeldungen auswerten.
und poste einmal
ebusctl find -d
LG
ja, dass ich da nicht sehr viele Werte rausbekomme weis ich.
Aber wenn die Aussentemperatur ja schon einmal da ist...
Kannst du mit diesen Ausgaben etwas anfangen?
ebusd --checkconfig
2017-11-18 21:31:25.085 [main notice] ebusd 3.0.595c7c0 performing configuration check...
/etc/ebusd/de/vaillant/_templates.csv:46: ERR: element not found, field type TEMP in field 0
2017-11-18 21:31:25.097 [main error] error reading templates in /etc/ebusd/de/vaillant: ERR: element not found, last error: /etc/ebusd/de/vaillant/_templates.csv:46: ERR: element not found, field type TEMP in field 0
/etc/ebusd/de/vaillant/15.e7f.csv:8: ERR: element not found, field type TEMP in field 0
2017-11-18 21:31:25.099 [main error] error reading config files: ERR: element not found, last error: /etc/ebusd/de/vaillant/15.e7f.csv:8: ERR: element not found, field type TEMP in field 0
2017-11-18 21:31:25.099 [main notice] found messages: 12 (0 conditional on 2 conditions, 0 poll, 4 update)
2017-11-18 21:31:25.100 [main notice] ebusd stopped
ebusctl find -d
broadcast outsidetemp = 5.000
broadcast vdatetime = 21:32:31;18.11.2017
hmu State = 0;247;off;ready
scan.08 = Vaillant;HMU01;0304;8802
scan.08 id = 21;17;28;0010019758;1610;005614;N2
scan.76 = Vaillant;VWZIO;0111;0103
scan.76 id = 21;17;20;0020143590;1610;005605;N7
scan.e8 = Vaillant;FMU00;0202;6502
scan.e8 id = 21;17;28;0010019758;1610;005614;N2
ja ist klar, es wurden keine CSV geladen, ich glaube aber John hat da schon mal was geschrieben das er sich das einmal anschaut ob man da was besser machen kann.
Du kannst nicht anders und musst daher mit den Broadcast auskommen. Warum das jetzt bei dir nicht funktioniert weis ich dann auch nicht, zumal der Wert ja aus dem Buffer eindeutig gelesen werden kann.
LG
Hallo Tobias,
ich habe in der bai00.cfg das so drin zur Außentemp:
get Aussentemp cmd {"r -m 10 outsidetemp\n"}
get Aussentemp expect "-?\d+\.\d+\n\n"
Evtl. siehst du auch im FHEM-Log mehr, da steht dann meist etwas wie ... EBUS: unexpected answer ...
Ein Regex von ".\n*" bedeutet doch: ein zeichen, beliebige umbrüche
Ich denke das ist der Haken und FHEM übernimmt das deshalb nicht.
Kommen kann ja bsp:
pi@raspi:~ $ ebusctl r outsidetemp
0.312
\n
\n
oder
pi@raspi:~ $ ebusctl r outsidetemp
-0.312
\n
\n
Zitat von: TobiasR am 18 November 2017, 20:06:32
da bekomme ich ERR: element not found
das liegt daran, dass es eine broadcast Nachricht mit ZZ=fe ist, sprich die kann ebusd gar nicht aktiv vom Bus abrufen, sondern muss darauf warten, dass der entsprechende Master sie sendet.
Zitat von: TobiasR am 18 November 2017, 21:34:36
Aber wenn die Aussentemperatur ja schon einmal da ist...
wie gesagt, das ist Broadcast, kann ebusd nicht aktiv abfragen.
Zitat von: TobiasR am 18 November 2017, 21:34:36
ebusd --checkconfig
so genügt das nur, wenn Du aus den CSV genau die rausgefischt hast, die für Deine Anlagenkonfiguration notwendig sind und alle anderen gelöscht hast.
Besser ist:
ebusd --scanconfig --checkconfigHast Du denn inzwischen die CSVs aus dem Repo ausgecheckt und verwendest diese auch?
Hallo john,
die csv aus dem Repo verwende ich. Deshalb wird jetzt auch die 7000 geladen. Danke nochmal.
Aber ich bin nun endlich an einem Punkt dass ich mich nach dem Sinn fragen.
Scheinbar bin ich zu doof das zu verstehen.
Und wenn ich dann nicht einmal den einzigen Wert nach FHEM bekommen, haben ich gestern Abend beschlossen,
hier nicht weiter zu machen.
Vielleicht gibt es ja irgend wann mal eine Konfig die ich dann mitnutzen kann.
Besten Dank an alle die mich bis hier her unterstützt haben
Tobias
trotz update auf die neuste version habe ich folgende ausgabe
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.0.595c7c0
update check: revision v3.0 available, broadcast.csv: newer version available, vaillant/08.ehp.csv: newer version available, vaillant/15.uih.csv: newer version available, vaillant/23.ehp.cc.csv: newer version available, vaillant/25.ehp.hwc.csv: newer version available, vaillant/50.ehp.mc.csv: newer version available, vaillant/broadcast.csv: different version
signal: acquired
symbol rate: 23
max symbol rate: 138
reconnects: 0
masters: 3
messages: 638
conditional: 285
poll: 2
update: 56
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
pi@raspberrypi:~ $ ebusd --checkconfig
2017-11-19 12:04:37.102 [main notice] ebusd 3.0.595c7c0 performing configuration check...
/etc/ebusd/vaillant/15.heb.csv:6: ERR: duplicate entry, duplicate ID
2017-11-19 12:04:37.792 [main error] error reading config files: ERR: duplicate entry, last error: /etc/ebusd/vaillant/15.heb.csv:6: ERR: duplicate entry, duplicate ID
2017-11-19 12:04:37.975 [main notice] found messages: 484 (20 conditional on 12 conditions, 0 poll, 4 update)
2017-11-19 12:04:37.996 [main notice] ebusd stopped
pi@raspberrypi:~ $ ebusctl find -d
broadcast datetime = 7.312;12:04:02;19.11.2017
broadcast hwcStatus = off;23;off
broadcast outsidetemp = 7.312
broadcast vdatetime = 12:04:02;19.11.2017
cc Mode = 30;auto;00;off
cc Status = 0;off;-;0
ehp ActualEnvironmentPower = 0
ehp ActualEnvironmentPowerFine = 56
ehp ActualEnvironmentPowerPercentage = 0
ehp errorhistory = 9;2;20:31;17.11.2017;580
ehp FlowTemp = 23.94;ok
ehp HeatpumpType = brinetowater
ehp Mode = (ERR: invalid position for 1008b51009000232000000000002 / 00)
ehp OutsideTemp = 7.31;ok
ehp SourcePumpStatus = 0
ehp SourceTempInput = 17.12;ok
ehp Status02 = disabled;0;100.0;0;100.0
ehp Status = 23.88;1.592;1.123;03 08 00 00
hwc Mode = 44;auto;00;off
hwc Status = 80;off;49.12;44
mc CfgHeatSinkType = mixer
mc DateTime = ok;12:03:47;19.11.2017;7.312
mc Mode = 21;auto;00;off
mc Status = 25;off;23.94;21
scan.08 = Vaillant;EHP00;0419;7201
scan.08 id = ??;??;??;??????????;????;??????;??
scan.15 = Vaillant;UIH00;0374;6901
scan.15 id = 21;13;48;0020101780;0907;011188;N4
scan.23 = Vaillant;EHP00;0419;7201
scan.23 id = ??;??;??;??????????;????;??????;??
scan.25 = Vaillant;EHP00;0419;7201
scan.25 id = ??;??;??;??????????;????;??????;??
scan.50 = Vaillant;EHP00;0419;7201
scan.50 id = ??;??;??;??????????;????;??????;??
hier das update
pi@raspberrypi:~ $ sudo service ebusd stop
pi@raspberrypi:~ $ dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
dpkg: Fehler: Angeforderte Operation benötigt Superuser-Rechte
pi@raspberrypi:~ $ sudo dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
(Lese Datenbank ... 116031 Dateien und Verzeichnisse sind derzeit installiert.)
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) ...
ebusd-configuration (2.1.b143f39-de) wird eingerichtet ...
pi@raspberrypi:~ $ sudo service ebusd start
Zitat von: realkeule am 19 November 2017, 12:09:54
trotz update auf die neuste version habe ich folgende ausgabe
okay, nochmal für alle:
Das letzte ebusd-configuration Release ist schon etwas alt (Juni 2016) und enthält nicht den letzten Stand der Dinge.
Man braucht aber nicht wirklich ein Release, um an die tagesaktuellen CSVs zu kommen.
Das geht auch einfach wie folgt:
cd ~
git clone https://github.com/john30/ebusd-configuration.git
mv /etc/ebusd /etc/ebusd.old 2>/dev/null
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusdDamit hat man den aktuellsten Stand in Deutsch zur Verfügung und wenn es im Repo etwas neues gibt, kann man einfach wie folgt wieder auf den aktuellen Stand kommen:
cd ~/ebusd-configuration
git pull
hi john,
sorry aber das klappt so bei mir nicht. ich habe auch schon überall gelesen aber nichts gefunden:
Zitatpi@raspberrypi:~/ebusd-configuration $ git pull
Already up-to-date.
pi@raspberrypi:~/ebusd-configuration $ ebusctl info
version: ebusd 3.0.595c7c0
update check: revision v3.0 available, broadcast.csv: newer version available, vaillant/08.ehp.csv: newer version available, vaillant/15.uih.csv: newer version available, vaillant/23.ehp.cc.csv: newer version available, vaillant/25.ehp.hwc.csv: newer version available, vaillant/50.ehp.mc.csv: newer version available, vaillant/broadcast.csv: different version
signal: acquired
symbol rate: 105
max symbol rate: 221
reconnects: 0
masters: 3
messages: 638
conditional: 285
poll: 2
update: 56
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
pi@raspberrypi:/etc/ebusd $ ls -la
insgesamt 436
drwxr-xr-x 3 root root 4096 Nov 19 14:38 .
drwxr-xr-x 112 root root 4096 Nov 6 20:32 ..
-rw-rw-r-- 1 pi pi 1202 Jun 5 2016 broadcast.csv
lrwxrwxrwx 1 root root 43 Nov 19 14:38 de -> /home/pi/ebusd-configuration/ebusd-2.1.x/de
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb
-rw-r--r-- 1 root root 182742 Sep 9 12:07 ebusd-3.0_armhf_mqtt1.deb
-rw-r--r-- 1 root root 52202 Mai 22 23:50 ebusd-configuration-2.1.b143f39-de_all.deb
-rw-rw-r-- 1 pi pi 754 Jun 5 2016 memory.csv
-rw-rw-r-- 1 pi pi 1228 Jun 5 2016 _templates.csv
drwxrwxr-x 2 pi pi 12288 Nov 19 11:59 vaillant
ist dieser symbollink(?) falsch? oder muss ich manuell kopieren? (leider kein linux profi...)
Zitat von: realkeule am 20 November 2017, 23:45:01
pi@raspberrypi:/etc/ebusd $ ls -la
-rw-rw-r-- 1 pi pi 1202 Jun 5 2016 broadcast.csv
lrwxrwxrwx 1 root root 43 Nov 19 14:38 de -> /home/pi/ebusd-configuration/ebusd-2.1.x/de
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb
-rw-r--r-- 1 root root 182742 Sep 9 12:07 ebusd-3.0_armhf_mqtt1.deb
-rw-r--r-- 1 root root 52202 Mai 22 23:50 ebusd-configuration-2.1.b143f39-de_all.deb
-rw-rw-r-- 1 pi pi 754 Jun 5 2016 memory.csv
-rw-rw-r-- 1 pi pi 1228 Jun 5 2016 _templates.csv
drwxrwxr-x 2 pi pi 12288 Nov 19 11:59 vaillant
ist dieser symbollink(?) falsch?
ja, so gehts nicht. Wie schon geschrieben einfach die Kommandos der Reihe nach ausführen, hier nochmal:
cd ~
git clone https://github.com/john30/ebusd-configuration.git
mv /etc/ebusd /etc/ebusd.old 2>/dev/null
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd
Hallo zusammen,
habe selbiges Problem nach Neuinstalltion ebusd, nach microSD-Kartencrash.
Kann bei mir die 15.700.csv (für VRC700) keine Daten einlesen. Funktioniert offensichtlich nur über bai08.csv und broadcast.csv.
Irgendwas mach ich falsch habe die letzten Schritte von heute auch versucht einzuspielen, aber ohne Erfolg.
Kann mir irgend jemand weiterhelfen?? :'( :'(
sudo ebusd --checkconfig --scanconfig
2017-11-21 07:49:24.912 [main notice] ebusd 3.0.595c7c0 performing configuration check...
2017-11-21 07:49:25.167 [main notice] found messages: 1233 (194 conditional on 46 conditions, 1 poll, 58 update)
2017-11-21 07:49:25.177 [main notice] ebusd stopped
sudo ebusctl info
version: ebusd 3.0.595c7c0
signal: acquired
symbol rate: 23
max symbol rate: 132
reconnects: 0
masters: 3
messages: 214
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
sudo ebusctl find -d
bai DateTime = nosignal;-:-:-;-.-.-;3.000
bai Mode = standby
bai SDFanSpeed = 3664
bai Status01 = 55.5;49.5;3.000;49.5;41.5;4
bai Status02 = auto;60;75.0;70;65.0
broadcast outsidetemp = 3.000
broadcast vdatetime = 07:52:07;21.11.2017
scan.08 = Vaillant;BAI00;0116;9602
scan.08 id = 21;16;14;0010015596;3100;006123;N4
scan.15 = Vaillant;70000;0209;4103
scan.15 id = 21;16;17;0020171314;0082;019519;N3
sudo ls -la
total 55396
drwxr-xr-x 2 pi pi 4096 Nov 19 16:44 .
drwxr-xr-x 3 root root 4096 Sep 7 16:59 ..
-rw------- 1 pi pi 6146 Nov 21 07:33 .bash_history
-rw-r--r-- 1 pi pi 220 Sep 7 16:59 .bash_logout
-rw-r--r-- 1 pi pi 3523 Sep 7 16:59 .bashrc
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb.1
-rw-r--r-- 1 root root 52202 May 22 23:50 ebusd-configuration-2.1.b143f39-de_all.deb
-rw-r--r-- 1 root root 18761948 Feb 19 2017 fhem-5.8.deb
-rw-r--r-- 1 root root 18761948 Feb 19 2017 fhem-5.8.deb.1
-rw-r--r-- 1 root root 18761948 Feb 19 2017 fhem-5.8.deb.2
-rw-r--r-- 1 pi pi 675 Sep 7 16:59 .profile
Danke im Voraus. ;)
Grüße
Torsten
Zitat von: MOLUSER am 21 November 2017, 07:54:30
habe selbiges Problem nach Neuinstalltion ebusd, nach microSD-Kartencrash.
Ist die Frage jetzt wirklich ernst gemeint? Einen Beitrag vorher ist die Anleitung zu finden...
Zitat von: john30 am 21 November 2017, 08:25:52
Ist die Frage jetzt wirklich ernst gemeint? Einen Beitrag vorher ist die Anleitung zu finden...
Hallo John,
sorry für die Umstände die ich dir bereit habe. Ich hatte vorher deine Hinweise beachtet und die Befehlsfolge abgesetzt. Wahrscheinlich hatte ich mich falsch ausgedrückt.
Prinzipiell werden ja einige Werte gelesen aber nicht die 700er aus der 15.700.csv.
Welche Dateien sind denn für das Ansprechen der 15.700.csv relevant, passiert das über die _template.csv?
Sorry für mein Unverständnis, aber ich tue mich hier wahrscheinlich ziemlich schwer.
Bislang konnte ich den Abläufen im Forum gut folgen und es funktionierte alles ganz gut.
Ich bin nun an einer Stelle angelangt wo ich einfach nicht mehr weiterkomme und langsam verzweifle.
Danke im voraus.
Grüße
Torsten.
Zitat von: MOLUSER am 21 November 2017, 12:13:57
Prinzipiell werden ja einige Werte gelesen aber nicht die 700er aus der 15.700.csv.
okay, dann wäre zu klären, welche Werte im vergleich zu vorher nicht mehr gelesen werden können und wie du die Werte liest (ebusctl/fhem+cmd/+gaebus/mqtt etc).
Zitat von: john30 am 21 November 2017, 06:58:11
ja, so gehts nicht. Wie schon geschrieben einfach die Kommandos der Reihe nach ausführen, hier nochmal:
cd ~
git clone https://github.com/john30/ebusd-configuration.git
mv /etc/ebusd /etc/ebusd.old 2>/dev/null
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd
ich hatte mich schon an deine anleitung gehalten. wenn ich sie nochmal ausführe kommt das:
pi@raspberrypi:~ $ cd ~
pi@raspberrypi:~ $ git clone https://github.com/john30/ebusd-configuration.git
fatal: Zielpfad 'ebusd-configuration' existiert bereits und ist kein leeres Verzeichnis.
pi@raspberrypi:~ $ mv /etc/ebusd /etc/ebusd.old 2>/dev/null
pi@raspberrypi:~ $ sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd
ln: die symbolische Verknüpfung ,,/etc/ebusd/de" konnte nicht angelegt werden: Die Datei existiert bereits
ist der symbol link falsch? oder ist eine fehler in meiner konfiguration?
Hallo zusammen,
meine Bartl WP läuft jetzt endlich mit FHEM und ebusd. Folgendes ist mir jetzt aufgefallen.
Auszug aus dem FileLog:
2017-11-22_02:49:19 HKVorlaufSoll HKVorlaufSoll: 26.1
2017-11-22_02:49:19 HKVorlaufSoll HKVorlaufSoll 26.1
2017-11-22_02:49:19 HKVorlaufIst HKVorlaufIst: 26.0
2017-11-22_02:49:19 HKVorlaufIst HKVorlaufIst 26.0
2017-11-22_02:49:20 HKRelaisPumpe HKRelaisPumpe: 1
2017-11-22_02:49:20 HKRelaisPumpe HKRelaisPumpe 1
2017-11-22_02:49:20 HKMischer HKMischer: 0
2017-11-22_02:49:20 HKMischer HKMischer 0
2017-11-22_02:51:30 HKVorlaufSoll HKVorlaufSoll: 0.0
2017-11-22_02:51:30 HKVorlaufSoll HKVorlaufSoll 0.0
2017-11-22_02:51:30 HKVorlaufIst HKVorlaufIst: 0.0
2017-11-22_02:51:30 HKVorlaufIst HKVorlaufIst 0.0
2017-11-22_02:51:30 HKRelaisPumpe HKRelaisPumpe: 0
2017-11-22_02:51:30 HKRelaisPumpe HKRelaisPumpe 0
2017-11-22_02:51:31 HKMischer HKMischer: 0
2017-11-22_02:51:31 HKMischer HKMischer 0
2017-11-22_02:53:19 HKVorlaufSoll HKVorlaufSoll: 26.2
2017-11-22_02:53:19 HKVorlaufSoll HKVorlaufSoll 26.2
2017-11-22_02:53:19 HKVorlaufIst HKVorlaufIst: 26.1
2017-11-22_02:53:19 HKVorlaufIst HKVorlaufIst 26.1
2017-11-22_02:53:20 HKRelaisPumpe HKRelaisPumpe: 1
2017-11-22_02:53:20 HKRelaisPumpe HKRelaisPumpe 1
2017-11-22_02:53:20 HKMischer HKMischer: 0
2017-11-22_02:53:20 HKMischer HKMischer 0
Die Daten werden alle 2 min. per Timer vom Ebus abgefragt. Es schleicht sich aber immer mal wieder Antwort ein, die jedem Reading eine "0" zuordnet, obwohl sämtliche Abfragen vorher und nachher die richtigen Werte liefern. Bemerkbar macht sich das dann spätestens im Plot, wenn die Kurve Haken schlägt.
Woran könnte das liegen? Kommt die Antwort von ebusd zu langsam? Wie kann ich da den Grund herausfinden?
Zur Not könnte ich versuchen, die fehlerhaften Werte irgendwie in fhem zu überspringen, damit sie nicht für den Plot verwendet werden.
Danke und Gruß
Andreas
Prüfe mal das EBUSD.LOG zu dieser Zeit!
Ansonsten könnte ich mir nur erklären, dass eBusd einen Fehler meldet, der dann nicht ausgewertet sondern als "0" interpretiert wird.
Hallo,
ich habe in der ebusd.log nachgesehen und glaube es liegt daran, dass immer um die Zeit mit den "0" Abfragen ein neues Setzen des Experten Levels erfolgt. Ich habe 4 Einsteller, die das Experten-Menü-Level voraussetzen und die Abfrage lautet z.B. wie folgt (was übrigens auch eine Frage von mir aus einem Post von oben beantwortet):
get PumpeWE cmd {fhem ("get ParameterLevel ParameterLevel");; \
if (ReadingsVal("ParameterLevel", "ParameterLevel", "") eq "Expert Level\n\n") {"r -f -c wp_relais2 we_pumpe status\n"} \
else {fhem("get ExpertLevel SetExpertLevel");; sleep(5);; "r -f -c wp_relais2 we_pumpe status\n"}}
get PumpeWE expect ".*\n"
get PumpeWE postproc { $_ }
Nach 20 Minuten springt der Regler nun automatisch wieder in das User Level zurück, weshalb dann wieder die else-Schleife zum Einsatz kommt. sleep(5) deshalb, weil das ganze etwas dauert. Die Logs sind allerdings das Ergebnis mit sleep(10).
Ich denke, irgendwo hakt es da noch. Gibt es irgendwo bei den FHEM-Timer-Abfragen einen timeout? Oder hat ebusd selbst so einen Mechanismus, so dass die Abfrage komplett übersprungen wird, falls nichts zurückkommt, oder es zu lange dauert?
EDIT: ECMD hat wohl einen timeout, der per default auf 3s steht... ->mal checken.
Mein Timer:
define EBUS.Timer at +*00:02:00 get Warmwasser Warmwasser;;get Zirkulation Zirkulation;;get WWPumpe WWPumpe;;get WWPumpe2 WWPumpe2;; \
get VorlaufWP VorlaufWP;;get VorlaufWPsoll VorlaufWPsoll;;get RuecklaufWP RuecklaufWP;;get WaermequelleIn WaermequelleIn;;get WaermequelleOut WaermequelleOut;; \
get TempHeissgas TempHeissgas;;get StatusWP StatusWP;;get Aussentemperatur Aussentemperatur;;get RelaisVerdichter RelaisVerdichter;; \
get WarmwasserSollCalc WarmwasserSollCalc;;get HKVorlaufSoll HKVorlaufSoll;;get HKVorlaufIst HKVorlaufIst;;get HKRelaisPumpe HKRelaisPumpe;; \
get HKMischer HKMischer;;get Schaltzyklen Schaltzyklen;;get Betriebsstunden Betriebsstunden;;get PumpeWE PumpeWE;;get PumpeWQ PumpeWQ;; \
get RelaisVerdichter RelaisVerdichter;;get WarmwasserSoll WarmwasserSoll
Ansonsten wäre ein Hack für eine schnelle Lösung, dafür zu sorgen, dass der Regler im Experten-Level bleibt. Z.B. durch einen Timer, der das Level setzt.
Ich muss da wohl noch etwas experimentieren...
Danke und Gruß
Andreas
PS: Und ja, sowohl Timer als auch Abfragen und FileLog muss ich fhem-codeseitig dringend optimieren, da das alles ganz schön lange dauert ;)
Zitat von: rellla am 22 November 2017, 14:49:12
Hallo zusammen,
meine Bartl WP läuft jetzt endlich mit FHEM und ebusd. Folgendes ist mir jetzt aufgefallen.
Auszug aus dem FileLog:
2017-11-22_02:49:19 HKVorlaufSoll HKVorlaufSoll: 26.1
2017-11-22_02:49:19 HKVorlaufSoll HKVorlaufSoll 26.1
2017-11-22_02:49:19 HKVorlaufIst HKVorlaufIst: 26.0
2017-11-22_02:49:19 HKVorlaufIst HKVorlaufIst 26.0
2017-11-22_02:49:20 HKRelaisPumpe HKRelaisPumpe: 1
2017-11-22_02:49:20 HKRelaisPumpe HKRelaisPumpe 1
2017-11-22_02:49:20 HKMischer HKMischer: 0
2017-11-22_02:49:20 HKMischer HKMischer 0
2017-11-22_02:51:30 HKVorlaufSoll HKVorlaufSoll: 0.0
2017-11-22_02:51:30 HKVorlaufSoll HKVorlaufSoll 0.0
2017-11-22_02:51:30 HKVorlaufIst HKVorlaufIst: 0.0
2017-11-22_02:51:30 HKVorlaufIst HKVorlaufIst 0.0
2017-11-22_02:51:30 HKRelaisPumpe HKRelaisPumpe: 0
2017-11-22_02:51:30 HKRelaisPumpe HKRelaisPumpe 0
2017-11-22_02:51:31 HKMischer HKMischer: 0
2017-11-22_02:51:31 HKMischer HKMischer 0
2017-11-22_02:53:19 HKVorlaufSoll HKVorlaufSoll: 26.2
2017-11-22_02:53:19 HKVorlaufSoll HKVorlaufSoll 26.2
2017-11-22_02:53:19 HKVorlaufIst HKVorlaufIst: 26.1
2017-11-22_02:53:19 HKVorlaufIst HKVorlaufIst 26.1
2017-11-22_02:53:20 HKRelaisPumpe HKRelaisPumpe: 1
2017-11-22_02:53:20 HKRelaisPumpe HKRelaisPumpe 1
2017-11-22_02:53:20 HKMischer HKMischer: 0
2017-11-22_02:53:20 HKMischer HKMischer 0
Die Daten werden alle 2 min. per Timer vom Ebus abgefragt. Es schleicht sich aber immer mal wieder Antwort ein, die jedem Reading eine "0" zuordnet, obwohl sämtliche Abfragen vorher und nachher die richtigen Werte liefern. Bemerkbar macht sich das dann spätestens im Plot, wenn die Kurve Haken schlägt.
Woran könnte das liegen? Kommt die Antwort von ebusd zu langsam? Wie kann ich da den Grund herausfinden?
Zur Not könnte ich versuchen, die fehlerhaften Werte irgendwie in fhem zu überspringen, damit sie nicht für den Plot verwendet werden.
Danke und Gruß
Andreas
bei mir im log sind auch alle werte doppelt aufgeführt. woran liegt das? stört mich irgendwie :)
Zitat von: realkeule am 21 November 2017, 18:55:36
ich hatte mich schon an deine anleitung gehalten. wenn ich sie nochmal ausführe kommt das:
nochmal ausführen ist dann nicht so gut, weil ja die Verzeichnisse alle schon da sind.
Hm, vielleicht liest Du Dich ein bisschen in Linux Grundkenntnisse ein, zumindest sowas wie Verzeichnisse erstellen und löschen etc solltest Du schon können...
So wie die Ausgabe aussieht, hast Du Teile der Kommandos inzwischen schon 3x ausgeführt, oder?
Poste doch mal, was die Ausgabe des folgenden Kommandos ergibt:
ls -la /etc/ebusd/
Zitat von: john30 am 23 November 2017, 20:17:37
nochmal ausführen ist dann nicht so gut, weil ja die Verzeichnisse alle schon da sind.
Hm, vielleicht liest Du Dich ein bisschen in Linux Grundkenntnisse ein, zumindest sowas wie Verzeichnisse erstellen und löschen etc solltest Du schon können...
So wie die Ausgabe aussieht, hast Du Teile der Kommandos inzwischen schon 3x ausgeführt, oder?
Poste doch mal, was die Ausgabe des folgenden Kommandos ergibt:
ls -la /etc/ebusd/
hi john,
hier mal eine kurze zusammenfassung da ich glaube das wir aneinander vorbei schreiben:
ich bitte um hilfe.
du gibst mit eine befehlsfolge.
ich führe sie aus und poste das ergebniss von ls -la /etc/ebusd/ und schreibe das es nicht geht
du schreibst ich solle einfach deine befehlsfolge ausführen.
ich führe sie nochmal aus um dir die ausgabe zu posten.
du informierst mich darüber das ich zu wenig kenntnisse über das erstellen von ordnern habe und willst die ausgabe die ich dir 2 posts vorher schon gesendet habe.
so wie ich das sehe muss der inhalt aus dem symbollink (de) in den ordner in dem er ist. ich fange dann mal zu lesen :)
unabhängig davon: vielen dank für deine ebusd entwicklung!!
//edit
selbst wenn ich den inhalt von ~/ebusd-configuration/ebusd-2.1.x/de nach /etc/ebusd kopiere gehts nicht:
(den symbol link habe ich gelöscht)
pi@raspberrypi:~/ebusd-configuration/ebusd-2.1.x/de $ ls -la
insgesamt 24
drwxr-xr-x 3 pi pi 4096 Nov 19 14:38 .
drwxr-xr-x 4 pi pi 4096 Nov 19 14:38 ..
-rw-r--r-- 1 pi pi 1253 Nov 19 14:38 broadcast.csv
-rw-r--r-- 1 pi pi 754 Nov 19 14:38 memory.csv
-rw-r--r-- 1 pi pi 1228 Nov 19 14:38 _templates.csv
drwxr-xr-x 2 pi pi 4096 Nov 19 14:38 vaillant
pi@raspberrypi:~/ebusd-configuration/ebusd-2.1.x/de $ ls -la /etc/ebusd
insgesamt 436
drwxr-xr-x 3 root root 4096 Nov 23 21:09 .
drwxr-xr-x 112 root root 4096 Nov 22 00:12 ..
-rw-rw-r-- 1 pi pi 1253 Nov 23 21:14 broadcast.csv
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb
-rw-r--r-- 1 root root 182742 Sep 9 12:07 ebusd-3.0_armhf_mqtt1.deb
-rw-r--r-- 1 root root 52202 Mai 22 2017 ebusd-configuration-2.1.b143f39-de_all.deb
-rw-rw-r-- 1 pi pi 754 Nov 23 21:14 memory.csv
-rw-rw-r-- 1 pi pi 1228 Nov 23 21:14 _templates.csv
drwxrwxr-x 2 pi pi 12288 Nov 23 21:14 vaillant
pi@raspberrypi:~/ebusd-configuration/ebusd-2.1.x/de $ ebusctl info
version: ebusd 3.0.595c7c0
update check: revision v3.0 available, broadcast.csv: different version available, vaillant/08.ehp.csv: different version available, vaillant/15.uih.csv: different version available, vaillant/23.ehp.cc.csv: different version available, vaillant/25.ehp.hwc.csv: different version available, vaillant/50.ehp.mc.csv: different version available, vaillant/broadcas
signal: acquired
symbol rate: 108
max symbol rate: 176
reconnects: 0
masters: 3
messages: 617
conditional: 213
poll: 3
update: 59
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
Hallo miteinander,
momentan bin ich auch dabei unsere Wärmepumpe mit dem Raspi auszulesen. Hierzu habe ich den Schnittstellenkonverter wie hier im Wiki beschrieben gebaut und eingebunden. Wenn ich nun den Poti einstellen möchte bekomme ich folgende Meldungen:
2017-11-25 13:38:37.940 [bus notice] bus started with own address 31/36
2017-11-25 13:38:37.954 [bus notice] signal acquired
2017-11-25 13:38:38.038 [bus notice] <23b5010000000000d000
2017-11-25 13:38:38.188 [bus notice] <1023b5043100
2017-11-25 13:38:40.033 [bus error] signal lost
2017-11-25 13:38:40.555 [bus notice] <10250929
2017-11-25 13:38:40.556 [bus notice] signal acquired
2017-11-25 13:38:40.772 [bus notice] new master 10, master count 2
2017-11-25 13:38:40.828 [bus notice] <1008b50303010105c700020e1518060f0402de00
2017-11-25 13:38:41.230 [bus notice] <ff
2017-11-25 13:38:41.615 [bus notice] new master 70, master count 3
2017-11-25 13:38:41.659 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:38:41.707 [bus notice] <10feb5050427013a0166
2017-11-25 13:38:42.519 [bus notice] <7050b504013213000a280100000504ae00
2017-11-25 13:38:43.743 [bus notice] new master 03, master count 4
2017-11-25 13:38:43.747 [bus notice] <1008b509032907004f00050700bd01000000
2017-11-25 13:38:43.914 [bus notice] <1023b505072b0001000000007900000000
2017-11-25 13:38:44.371 [bus notice] <1008b5110203001e000aa9010317074902043c0100dd00
2017-11-25 13:38:44.534 [bus notice] <1008b51101028a00050000c800c8ca00
2017-11-25 13:38:46.064 [bus notice] <03e0b521050005060072000000
2017-11-25 13:38:46.623 [bus notice] <1300
2017-11-25 13:38:46.740 [bus notice] <1300
2017-11-25 13:38:47.110 [bus notice] <b50e000000
2017-11-25 13:38:47.969 [bus notice] <100903a000000010b504000000
2017-11-25 13:38:49.822 [bus notice] <5004fe1501000013
2017-11-25 13:38:49.946 [bus notice] <b50d0005b24c
2017-11-25 13:38:50.175 [bus notice] <10b501320a060108e6
2017-11-25 13:38:50.281 [bus notice] <100431000100
2017-11-25 13:38:50.575 [bus notice] <130454
2017-11-25 13:38:50.669 [bus notice] <ff
2017-11-25 13:38:50.971 [bus notice] <130010b503010106c40008020a0918060fd8056a00
2017-11-25 13:38:51.707 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:38:51.891 [bus notice] <7050b504013213000a00280603010050080100e600
2017-11-25 13:38:52.046 [bus notice] <7050b505042d90ff00ea00000000
2017-11-25 13:38:54.670 [bus notice] <10b50527010903290f56050f000c00008d00
2017-11-25 13:38:56.120 [bus notice] <1008b5090329bb00ca0320010081011300
2017-11-25 13:38:56.529 [bus notice] <10081102031e000a031d074802043c01005c00
2017-11-25 13:38:56.741 [bus notice] <001008b51101028a00050000ca00
2017-11-25 13:38:57.231 [bus notice] <ff
2017-11-25 13:38:57.369 [bus notice] <ff
2017-11-25 13:38:57.508 [bus notice] <ff
2017-11-25 13:38:57.646 [bus notice] <ff
2017-11-25 13:38:57.784 [bus notice] <ff
2017-11-25 13:38:57.934 [bus notice] <10b51303cd017f000acd01000000000100fa00
2017-11-25 13:38:58.194 [bus notice] <1025b5092900
2017-11-25 13:38:59.822 [bus notice] <1008b5100900030000a000000002cd00000000
2017-11-25 13:38:59.975 [bus notice] <1008b509040ed100002900000000
2017-11-25 13:39:01.203 [bus notice] <10b5040133cc00025008de00
2017-11-25 13:39:01.808 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:39:02.324 [bus notice] <50
^C2017-11-25 13:39:05.087 [bus notice] <720731
2017-11-25 13:39:05.798 [bus notice] <10feb5050427013a0166
2017-11-25 13:39:06.756 [bus notice] <03e009
2017-11-25 13:39:07.039 [bus notice] <03e0b5090448
2017-11-25 13:39:07.866 [bus notice] <10b505072b00010000000085000000
Was mit etwas stutzig macht, ist das keine <aa im Log zu sehen sind. Müssen diese immer kommen oder ist mein Poti hier noch schlecht abgeglichen. Ich habe zwar schon am Poti rumgedreht, aber vielleicht war ich ja evtl. auch zu schnell. Ich kann jedoch zum Beispiel die Außentemperatur von Master 10 auslesen. Aber ich habe auch viele Nachrichten die unbekannt rüber kommen.
Daher meine Frage, ist mein Poti richtig abgeglichen oder muss ich da nochmals ran?
Liebe Grüße
nic
Zitat von: dkuschmierz am 25 November 2017, 13:46:18
Hallo miteinander,
momentan bin ich auch dabei unsere Wärmepumpe mit dem Raspi auszulesen. Hierzu habe ich den Schnittstellenkonverter wie hier im Wiki beschrieben gebaut und eingebunden. Wenn ich nun den Poti einstellen möchte bekomme ich folgende Meldungen:
2017-11-25 13:38:37.940 [bus notice] bus started with own address 31/36
2017-11-25 13:38:37.954 [bus notice] signal acquired
2017-11-25 13:38:38.038 [bus notice] <23b5010000000000d000
2017-11-25 13:38:38.188 [bus notice] <1023b5043100
2017-11-25 13:38:40.033 [bus error] signal lost
2017-11-25 13:38:40.555 [bus notice] <10250929
2017-11-25 13:38:40.556 [bus notice] signal acquired
2017-11-25 13:38:40.772 [bus notice] new master 10, master count 2
2017-11-25 13:38:40.828 [bus notice] <1008b50303010105c700020e1518060f0402de00
2017-11-25 13:38:41.230 [bus notice] <ff
2017-11-25 13:38:41.615 [bus notice] new master 70, master count 3
2017-11-25 13:38:41.659 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:38:41.707 [bus notice] <10feb5050427013a0166
2017-11-25 13:38:42.519 [bus notice] <7050b504013213000a280100000504ae00
2017-11-25 13:38:43.743 [bus notice] new master 03, master count 4
2017-11-25 13:38:43.747 [bus notice] <1008b509032907004f00050700bd01000000
2017-11-25 13:38:43.914 [bus notice] <1023b505072b0001000000007900000000
2017-11-25 13:38:44.371 [bus notice] <1008b5110203001e000aa9010317074902043c0100dd00
2017-11-25 13:38:44.534 [bus notice] <1008b51101028a00050000c800c8ca00
2017-11-25 13:38:46.064 [bus notice] <03e0b521050005060072000000
2017-11-25 13:38:46.623 [bus notice] <1300
2017-11-25 13:38:46.740 [bus notice] <1300
2017-11-25 13:38:47.110 [bus notice] <b50e000000
2017-11-25 13:38:47.969 [bus notice] <100903a000000010b504000000
2017-11-25 13:38:49.822 [bus notice] <5004fe1501000013
2017-11-25 13:38:49.946 [bus notice] <b50d0005b24c
2017-11-25 13:38:50.175 [bus notice] <10b501320a060108e6
2017-11-25 13:38:50.281 [bus notice] <100431000100
2017-11-25 13:38:50.575 [bus notice] <130454
2017-11-25 13:38:50.669 [bus notice] <ff
2017-11-25 13:38:50.971 [bus notice] <130010b503010106c40008020a0918060fd8056a00
2017-11-25 13:38:51.707 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:38:51.891 [bus notice] <7050b504013213000a00280603010050080100e600
2017-11-25 13:38:52.046 [bus notice] <7050b505042d90ff00ea00000000
2017-11-25 13:38:54.670 [bus notice] <10b50527010903290f56050f000c00008d00
2017-11-25 13:38:56.120 [bus notice] <1008b5090329bb00ca0320010081011300
2017-11-25 13:38:56.529 [bus notice] <10081102031e000a031d074802043c01005c00
2017-11-25 13:38:56.741 [bus notice] <001008b51101028a00050000ca00
2017-11-25 13:38:57.231 [bus notice] <ff
2017-11-25 13:38:57.369 [bus notice] <ff
2017-11-25 13:38:57.508 [bus notice] <ff
2017-11-25 13:38:57.646 [bus notice] <ff
2017-11-25 13:38:57.784 [bus notice] <ff
2017-11-25 13:38:57.934 [bus notice] <10b51303cd017f000acd01000000000100fa00
2017-11-25 13:38:58.194 [bus notice] <1025b5092900
2017-11-25 13:38:59.822 [bus notice] <1008b5100900030000a000000002cd00000000
2017-11-25 13:38:59.975 [bus notice] <1008b509040ed100002900000000
2017-11-25 13:39:01.203 [bus notice] <10b5040133cc00025008de00
2017-11-25 13:39:01.808 [bus notice] <7050b504010d2c00050000b201054c00
2017-11-25 13:39:02.324 [bus notice] <50
^C2017-11-25 13:39:05.087 [bus notice] <720731
2017-11-25 13:39:05.798 [bus notice] <10feb5050427013a0166
2017-11-25 13:39:06.756 [bus notice] <03e009
2017-11-25 13:39:07.039 [bus notice] <03e0b5090448
2017-11-25 13:39:07.866 [bus notice] <10b505072b00010000000085000000
Was mit etwas stutzig macht, ist das keine <aa im Log zu sehen sind. Müssen diese immer kommen oder ist mein Poti hier noch schlecht abgeglichen. Ich habe zwar schon am Poti rumgedreht, aber vielleicht war ich ja evtl. auch zu schnell. Ich kann jedoch zum Beispiel die Außentemperatur von Master 10 auslesen. Aber ich habe auch viele Nachrichten die unbekannt rüber kommen.
Daher meine Frage, ist mein Poti richtig abgeglichen oder muss ich da nochmals ran?
Liebe Grüße
nic
mach es so wie im wiki beschrieben:
ZitatPoti abgleichen
Zur ersten Justierung des Potis, wird der eBusd Dienst genutzt. Das Vorgehen sieht wie folgt aus:
1) eBus Dienst stoppen - Das kann mit der folgenden Kommandozeile bewerkstelligt werden:
service ebusd stop
2) eBus Dienst, jedoch mit minimalen Parametern und ohne eBusd Konfigurationsdateien (CSV-Files), mit der folgenden Kommandozeile erneut starten:
Hinweis: <DEVICE> Muss zuvor durch den entsprechenden USB-Port (siehe USB Device und Port unter Linux ermitteln) z.B. /dev/ttyUSB0 ersetzt werden.
ebusd -f -c /tmp --logareas bus --loglevel info -d <DEVICE>
3) Der eBusd Dienst läuft nun im Vordergrund.
4) Einem zweiten Terminal öffnen und den folgenden Befehl ausführen:
ebusctl raw
Mit dem Befehl erhält man im Terminalfenster die empfangenen Bytes als Hex, die wie folgt aussehen:
2015-12-24 12:07:16.955 [bus notice] <aa
2015-12-24 12:07:17.001 [bus notice] <aa
2015-12-24 12:07:17.047 [bus notice] <aa
2015-12-24 12:07:17.093 [bus notice] <aa
2015-12-24 12:07:17.097 [bus notice] <10
2015-12-24 12:07:17.102 [bus notice] <50
2015-12-24 12:07:17.107 [bus notice] <b5
2015-12-24 12:07:17.111 [bus notice] <04
Wenn gerade kein Gerät den Bus nutzt, dann sollten ca. 20 Zeilen pro Sekunde ausgegeben werden und zwar mit "<aa" (im Beispiel die oberen 4 Zeilen).
Sobald ein Gerät den eBus nutzt, tauchen neben "<aa" auch andere HEX Werte auf (im Beispiel die unteren 4 Zeilen). Diese Werte können ignoriert werden.
Wichtig bei der Poti Einstellung ist, dass vor allem die regulären "aa"s zu sehen sind. Tauchen die "aa"s auf, dann kann davon ausgegangen werden, dass der Poti korrekt eigestellt ist. Ist dies der Fall, dann kann der eBusd Dienst regulär gestartet werden. Dabei muss der im Vordergrund laufende eBusd Prozess (siehe Punkt 2) mit der Tastenkombination STRG+C abgebrochen und der folgende Befehl in der Kommandozeile ausgeführt werden:
service ebusd start
Zitat von: realkeule am 23 November 2017, 21:02:45
ich führe sie aus und poste das ergebniss von ls -la /etc/ebusd/ und schreibe das es nicht geht
von dem was du gepostet hast, sieht es allerdings nicht so aus, als hättest du als 3. Kommando "mv /etc/ebusd /etc/ebusd.old" ausgeführt und deshalb stimmt die Verzeichnisstruktur nicht.
Anyway, was genau meinst Du denn mit "aber das klappt so bei mir nicht"?
Zitat von: realkeule am 23 November 2017, 21:02:45
pi@raspberrypi:~/ebusd-configuration/ebusd-2.1.x/de $ ls -la /etc/ebusd
insgesamt 436
drwxr-xr-x 3 root root 4096 Nov 23 21:09 .
drwxr-xr-x 112 root root 4096 Nov 22 00:12 ..
-rw-rw-r-- 1 pi pi 1253 Nov 23 21:14 broadcast.csv
-rw-r--r-- 1 root root 172622 Sep 9 12:07 ebusd-3.0_armhf.deb
-rw-r--r-- 1 root root 182742 Sep 9 12:07 ebusd-3.0_armhf_mqtt1.deb
-rw-r--r-- 1 root root 52202 Mai 22 2017 ebusd-configuration-2.1.b143f39-de_all.deb
-rw-rw-r-- 1 pi pi 754 Nov 23 21:14 memory.csv
-rw-rw-r-- 1 pi pi 1228 Nov 23 21:14 _templates.csv
drwxrwxr-x 2 pi pi 12288 Nov 23 21:14 vaillant
das sieht schon halbwegs vernünftig aus, nur die .deb Files haben da eigentlich nichts zu suchen.
Zitat von: realkeule am 23 November 2017, 21:02:45
pi@raspberrypi:~/ebusd-configuration/ebusd-2.1.x/de $ ebusctl info
...
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
wird alles richtig gelesen anscheinend, oder kannst Du keine Daten abfragen?
Zitat von: dkuschmierz am 25 November 2017, 13:46:18
Was mit etwas stutzig macht, ist das keine <aa im Log zu sehen sind.
Das wiki ist hier noch nicht auf dem letzten Stand. Seit ebusd 3.0 werden per default bei "raw" ganze Sequenzen sprich Nachrichten protkolliert, nicht mehr einzelne Bytes. Um wieder die einzelnen Bytes zu bekommen, einfach "ebusctl raw bytes (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#raw-logging)" verwenden oder den entsprechend erweiterten Kommandozeilenparameter --lograwdata=bytes (https://github.com/john30/ebusd/wiki/2.-Run#raw-logging-options) für ebusd.
Zitat von: john30 am 25 November 2017, 18:00:15
von dem was du gepostet hast, sieht es allerdings nicht so aus, als hättest du als 3. Kommando "mv /etc/ebusd /etc/ebusd.old" ausgeführt und deshalb stimmt die Verzeichnisstruktur nicht.
Anyway, was genau meinst Du denn mit "aber das klappt so bei mir nicht"?
das sieht schon halbwegs vernünftig aus, nur die .deb Files haben da eigentlich nichts zu suchen.
wird alles richtig gelesen anscheinend, oder kannst Du keine Daten abfragen?
ich kann ziehlich viel abfragen, nur das mit dem update störte mich.
du hattest recht, durch die ausgabe umleitung ist mir nicht aufgefallen das der move gar nicht ausgeführt wurde ::)
/etc
lrwxrwxrwx 1 root root 43 Nov 25 18:45 ebusd -> /home/pi/ebusd-configuration/ebusd-2.1.x/de
drwxr-xr-x 3 root root 4096 Nov 25 18:33 ebusd.old
ls -la /etc/ebusd
pi@raspberrypi:/etc $ ls -la /etc/ebusd
lrwxrwxrwx 1 root root 43 Nov 25 18:45 /etc/ebusd -> /home/pi/ebusd-configuration/ebusd-2.1.x/de
sollte da jetzt nicht der inhalt aus dem ordner aufgeführt sein?
ZitatFür jeden Device wird hier festgelegt wie die Befehls Syntax der Abfrage auszusehen hat (cmd) und wie die Ergebnisse zu filtern sind (expect), wie soll das Ausgabeformat sein (postproc). Diese Definitionen bitte in einer neuen Datei "bai00.cfg" speichern.
gibts iwo eine info wo filter und ausgabeformat erklärt sind? ich habe bei dem soledruck nur volle zahlen und brauch eine genauere angabe. wenn ich es mit ebusd abfrage bekomme ich 3 nachkommastellen
Danke an alle
Zitat von: realkeule am 25 November 2017, 19:02:21
ich kann ziehlich viel abfragen, nur das mit dem update störte mich.
ach so, darum gings dir. das sollte mit dem nächsten update check bzw. nach einem ebusd neustart erledigt sein.
Zitat von: realkeule am 25 November 2017, 19:02:21
sollte da jetzt nicht der inhalt aus dem ordner aufgeführt sein?
Nachdem es ein symbolischer Link ist, braucht es noch ein abschließendes "/", also so:
ls -la /etc/ebusd/Zitat von: realkeule am 25 November 2017, 19:02:21
gibts iwo eine info wo filter und ausgabeformat erklärt sind? ich habe bei dem soledruck nur volle zahlen und brauch eine genauere angabe. wenn ich es mit ebusd abfrage bekomme ich 3 nachkommastellen
da bin ich raus.
das Ausgabeformat kannst du ganz normal mit sprintf im postproc formatieren. Hier ein Beispiel von der Vorlauftemperatur mit einer Nachkommastelle. Wenn du 3 brauchst, dann %5.3f.
# vorlauftemperatur
get Vorlauf cmd {"r -f flowtemp temp\n"}
get Vorlauf expect ".*\n*"
get Vorlauf postproc { sprintf("%5.1f",$_) }
LG
Reinhart
Zitat von: john30 am 25 November 2017, 18:08:27
Das wiki ist hier noch nicht auf dem letzten Stand. Seit ebusd 3.0 werden per default bei "raw" ganze Sequenzen sprich Nachrichten protkolliert, nicht mehr einzelne Bytes. Um wieder die einzelnen Bytes zu bekommen, einfach "ebusctl raw bytes (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#raw-logging)" verwenden oder den entsprechend erweiterten Kommandozeilenparameter --lograwdata=bytes (https://github.com/john30/ebusd/wiki/2.-Run#raw-logging-options) für ebusd.
Genau das war das Problem, vielen Dank! Das Poti war richtig abgeglichen und mit der Option bytes habe ich auch sofort die <aa gesehen.
Hallo Zusammen,
hat jemand vielleicht eine auf Pi kompilierte Version, wo die Einschränkung der receivetimeout ausgeschaltet ist? Bei mir dauert diese Nachricht knapp mehr als 100 ms.. :-( Oder noch eine Idee vielleicht?
200ms latency habe ich auch ausprobiert, hilft aber leider nicht.
2017-12-18 22:02:02.240 [bus notice] <aa
2017-12-18 22:02:02.374 [bus info] send message: 3ff108000880019a1280008019
2017-12-18 22:02:02.447 [bus notice] <aa
2017-12-18 22:02:02.450 [bus notice] >3f
2017-12-18 22:02:02.456 [bus notice] <3f
2017-12-18 22:02:02.459 [bus notice] >f1
2017-12-18 22:02:02.464 [bus notice] <f1
2017-12-18 22:02:02.466 [bus notice] >08
2017-12-18 22:02:02.472 [bus notice] <08
2017-12-18 22:02:02.473 [bus notice] >00
2017-12-18 22:02:02.479 [bus notice] <00
2017-12-18 22:02:02.481 [bus notice] >08
2017-12-18 22:02:02.486 [bus notice] <08
2017-12-18 22:02:02.488 [bus notice] >80
2017-12-18 22:02:02.493 [bus notice] <80
2017-12-18 22:02:02.495 [bus notice] >01
2017-12-18 22:02:02.500 [bus notice] <01
2017-12-18 22:02:02.502 [bus notice] >9a
2017-12-18 22:02:02.507 [bus notice] <9a
2017-12-18 22:02:02.509 [bus notice] >12
2017-12-18 22:02:02.514 [bus notice] <12
2017-12-18 22:02:02.516 [bus notice] >80
2017-12-18 22:02:02.523 [bus notice] <80
2017-12-18 22:02:02.524 [bus notice] >00
2017-12-18 22:02:02.531 [bus notice] <00
2017-12-18 22:02:02.533 [bus notice] >80
2017-12-18 22:02:02.538 [bus notice] <80
2017-12-18 22:02:02.541 [bus notice] >19
2017-12-18 22:02:02.547 [bus notice] <19
2017-12-18 22:02:02.549 [bus notice] >db
2017-12-18 22:02:02.555 [bus notice] <db
2017-12-18 22:02:02.763 [bus notice] <aa
2017-12-18 22:02:02.763 [bus error] send to f1: ERR: read timeout, retry
Mein startup Parameters:
ebusd --scanconfig --loglevel=info --logareas=all --lograwdata=bytes -f --receivetimeout=100000 --latency=200000 --address=3f
Ver: ebusd 3.0.595c7c0
Vielen Dank und LG,
Adam
Zitat von: ahollik am 18 Dezember 2017, 22:12:43
2017-12-18 22:02:02.374 [bus info] send message: 3ff108000880019a1280008019
...
2017-12-18 22:02:02.549 [bus notice] >db
2017-12-18 22:02:02.555 [bus notice] <db
2017-12-18 22:02:02.763 [bus notice] <aa
2017-12-18 22:02:02.763 [bus error] send to f1: ERR: read timeout, retry
Du hast hier kein Problem mit der Latency, sondern eine Master-Master Nachricht, die vom Empfänger nicht quittiert wird, ergo "Timeout".
Bist Du Dir sicher, dass die hex Nachricht die richtigen Daten enthält? Üblicherweise reagiert bei Vaillant ein Adressat nicht mit einem ACK, wenn dieser die Nachricht nicht kennt/versteht.
Vielen Dank John für die schnelle Antwort! Wie immer.. :D
Und dein Hinweis hat mir wirklich geholfen. Ich habe jetzt in eine Andere Richtung probiert, und jetzt geht's wieder.
Das war so, dass nach einem Neustart des Kessels die erste Telegramm immer funktioniert hat. Dann kommte diese broadcast scan:
2017-12-19 19:50:58.694 [main notice] starting initial broadcast scan
2017-12-19 19:50:58.694 [bus info] send message: 3ffe070400
darauf eine fehlerhafte Riesenantwort. Und nachher gangen meine Telegramme nicht mehr.
Ich habe jetzt die Zieladdresse von F1 auf FE umgeschaltet, und seitdem funktioniert. :-)
Also, danke nochmals!
Zitat von: ahollik am 19 Dezember 2017, 20:01:31
Ich habe jetzt die Zieladdresse von F1 auf FE umgeschaltet, und seitdem funktioniert. :-)
FE ist grundsätzlich ganz was anderes als jede sonstige Ziel-Adresse, denn das ist der Broadcast, sprich damit adressierst Du potentiell alle am Bus hängenden Teilnehmer.
Dadurch antwortet auch keiner auf eine solche Nachricht, sprich es quittiert kein Teilnehmer den Erhalt.
Hi, meine Vailant Steuerung hat seitlich einen Modularstecker mit 4 Polen.
Ist das eine 1:1 Weiterleitung wo ich eine 1.6 er eBus Platine anstecken und wie ist diese zu belegen?
Grüße
das ist sicher was anderes, der eBus Stecker ist 2-polig und auch angeschrieben. hast du ein Betriebshandbuch, da ist der eBus Stecker genau eingezeichnet.
LG
Hier im Post steht was von dem modularen 4 poligen Stecker. Von hinten geht ein zweipoliger Anschluss rein, dort kann ich mich draufklemmen. An der Seite kommt der 4 polige wie beschrieben, aber k.a. was man damit machen kann.
Da passt ein alter Telefonstecker drauf. Ist hier sehr weit vorne beschrieben.
Müsste noch einen rumliegen haben.
Ist es eine auromatic 620?
Werte Experten!
Nach einem Stromausfall meiner Heizung Vaillant Ölbrennwertkessel VKO246-7 Regler VRC430 und Regler VR61 bekomme ich keine vernünftigen Daten mit meinem selbstgebauten EBUS Adapater mehr , obwohl dieser mit Ebusd1 und Ebusd2 schon funktioniert hat!
Als erstes habe ich den Adapter auf die Version ,,ohne Poti" umgebaut!
Brachte leider auch keine Verbesserung !
Habe auch schon einen anderen Raspi probiert und ebusd2 neu installiert!
Versuche ich nach dem Start von ebusd ein ,,ebusctl info" so bekomme ich zurück :
pi@pi-ebus ~ $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 22
masters: 3
messages: 11
address 03: master #3
address 08: slave #3, scanned
address 10: master #6
address 50: slave, scanned
Auch ein : --checkconfig –scanconfig ändert nichts.
ebusd --checkconfig --scanconfig
2017-12-20 18:36:53.083 [main notice] Performing configuration check...
2017-12-20 18:36:56.984 [main notice] found messages: 5435 (436 conditional on 99 conditions, 2 poll, 58 update)
Meine Frage:
Wie kann bzw. soll man vorgehen, um die Ursache herauszufinden (ausschließen von Hard- bzw. Software)
Mit weihnachtlichen Grüßen HPT
genaueres kann man eigentlich nur sagen wenn du ein RawLog von den ersten 30-45 Sekunden nach Start des ebusd machst.
Interessant ist dann im Rawlog hier wie der eBus auf die Sendeanfragen der Platine reagiert und ob überhaupt was vernünftiges gesendet werden kann.
Ach ja, du hast noch die alte 2.0 Version, ein Update auf 3.0 wäre ebenfalls angebracht.
LG
Reinhart
Befund nach :
pi@pi-ebus ~ $ ebusctl raw
pi@pi-ebus ~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2017-12-24 11:51:14.687 [bus notice] signal acquired
2017-12-24 11:51:15.970 [bus notice] new master 10, master count 2
2017-12-24 11:51:20.321 [bus notice] new master 03, master count 3
2017-12-24 11:51:22.012 [bus notice] <ef
2017-12-24 11:51:22.016 [bus notice] <aa
2017-12-24 11:51:22.061 [bus notice] <aa
2017-12-24 11:51:22.105 [bus notice] <aa
2017-12-24 11:51:22.149 [bus notice] <aa
2017-12-24 11:51:22.193 [bus notice] <aa
2017-12-24 11:51:22.236 [bus notice] <aa
2017-12-24 11:51:22.280 [bus notice] <aa
2017-12-24 11:51:22.325 [bus notice] <aa
2017-12-24 11:51:22.369 [bus notice] <aa
2017-12-24 11:51:22.413 [bus notice] <aa
2017-12-24 11:51:22.458 [bus notice] <aa
2017-12-24 11:51:22.503 [bus notice] <aa
2017-12-24 11:51:22.549 [bus notice] <aa
2017-12-24 11:51:22.596 [bus notice] <aa
2017-12-24 11:51:22.640 [bus notice] <aa
2017-12-24 11:51:22.686 [bus notice] <aa
2017-12-24 11:51:22.731 [bus notice] <aa
2017-12-24 11:51:22.774 [bus notice] <aa
2017-12-24 11:51:22.819 [bus notice] <aa
2017-12-24 11:51:22.862 [bus notice] <aa
2017-12-24 11:51:22.906 [bus notice] <aa
2017-12-24 11:51:22.951 [bus notice] <aa
2017-12-24 11:51:22.995 [bus notice] <aa
2017-12-24 11:51:23.039 [bus notice] <aa
2017-12-24 11:51:23.084 [bus notice] <aa
2017-12-24 11:51:23.128 [bus notice] <aa
2017-12-24 11:51:23.172 [bus notice] <aa
2017-12-24 11:51:23.218 [bus notice] <aa
2017-12-24 11:51:23.265 [bus notice] <aa
2017-12-24 11:51:23.309 [bus notice] <aa
2017-12-24 11:51:23.353 [bus notice] <aa
2017-12-24 11:51:23.397 [bus notice] <aa
2017-12-24 11:51:23.440 [bus notice] <aa
2017-12-24 11:51:23.485 [bus notice] <aa
2017-12-24 11:51:23.529 [bus notice] <aa
2017-12-24 11:51:23.575 [bus notice] <aa
2017-12-24 11:51:23.619 [bus notice] <aa
2017-12-24 11:51:23.665 [bus notice] <aa
2017-12-24 11:51:23.709 [bus notice] <aa
2017-12-24 11:51:23.753 [bus notice] <aa
2017-12-24 11:51:23.798 [bus notice] <aa
2017-12-24 11:51:23.842 [bus notice] <aa
2017-12-24 11:51:23.887 [bus notice] <aa
2017-12-24 11:51:23.932 [bus notice] <aa
2017-12-24 11:51:23.977 [bus notice] <aa
2017-12-24 11:51:23.981 [bus notice] <10
2017-12-24 11:51:23.990 [bus notice] <50
2017-12-24 11:51:23.994 [bus notice] <b5
2017-12-24 11:51:23.998 [bus notice] <09
2017-12-24 11:51:24.002 [bus notice] <04
2017-12-24 11:51:24.007 [bus notice] <0e
2017-12-24 11:51:24.010 [bus notice] <01
2017-12-24 11:51:24.014 [bus notice] <00
2017-12-24 11:51:24.018 [bus notice] <01
2017-12-24 11:51:24.022 [bus notice] <55
2017-12-24 11:51:24.027 [bus notice] <00
2017-12-24 11:51:24.032 [bus notice] <00
2017-12-24 11:51:24.037 [bus notice] <00
2017-12-24 11:51:24.041 [bus notice] <00
2017-12-24 11:51:24.045 [bus notice] <aa
2017-12-24 11:51:24.090 [bus notice] <aa
2017-12-24 11:51:24.134 [bus notice] <aa
2017-12-24 11:51:24.178 [bus notice] <aa
2017-12-24 11:51:24.223 [bus notice] <aa
.... usw.......
Ist das OK ?
Leider habe ich die Version ebusd 3 nicht erfolgreich installieren können!
pi@pi-ebus ~ $ sudo service ebusd start
ebusd: unrecognized service
und mit:
pi@pi-ebus /bin $ ebusd -f --loglevel notice --logareas all -d /dev/ttyUSB0
ebusd: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ebusd)
Deshalb meine Versuche mit ebusd 2 - müsste ja auch funktionieren oder?
@hpt17
das du die ebusd 3 nicht installieren kannst, dir fehlen ein paar Komponenten, die glibc. John hat das sehr gut beschrieben (https://github.com/john30/ebusd/wiki/1.-Build-and-install) wie du vorgehen musst, bzw. was die Voraussetzungen sind.
Das Log passt schon, aber bitte dazu ebusd neu starten, man sieht hier keine Sendeversuche und genau das wäre wichtig. Du hast die ersten 10 Sekunden gepostet und das ist leider noch zuwenig.
Und bitte solche Logs immer in einem Code Tag ( # ) einfügen, sonst wird es unübersichtlich.
Vorgangsweise:
1. ebusd stoppen
2. Raw Log einschalten (oder so wie du es gemacht hast)
3. ebusd starten und mindestens 30-45 Sekunden loggen.
4. Das Log in einem Code Tag posten
im Log bedeutet:
Empfang = <
Senden = >
LG
Reinhart
Anbei der neue log:
pi@pi-ebus ~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2017-12-26 13:26:21.095 [bus notice] signal acquired
2017-12-26 13:26:22.293 [bus notice] new master 10, master count 2
2017-12-26 13:26:22.633 [bus notice] new master 03, master count 3
2017-12-26 13:26:42.717 [bus notice] <aa
2017-12-26 13:26:42.762 [bus notice] <aa
2017-12-26 13:26:42.806 [bus notice] <aa
2017-12-26 13:26:42.810 [bus notice] <10
2017-12-26 13:26:42.817 [bus notice] <08
2017-12-26 13:26:42.822 [bus notice] <b5
2017-12-26 13:26:42.826 [bus notice] <11
2017-12-26 13:26:42.830 [bus notice] <01
2017-12-26 13:26:42.835 [bus notice] <01
2017-12-26 13:26:42.839 [bus notice] <89
2017-12-26 13:26:42.843 [bus notice] <00
2017-12-26 13:26:42.860 [bus notice] <09
2017-12-26 13:26:42.865 [bus notice] <4e
2017-12-26 13:26:42.869 [bus notice] <ff
2017-12-26 13:26:42.873 [bus notice] <30
2017-12-26 13:26:42.877 [bus notice] <08
2017-12-26 13:26:42.881 [bus notice] <00
2017-12-26 13:26:42.886 [bus notice] <58
2017-12-26 13:26:42.890 [bus notice] <00
2017-12-26 13:26:42.894 [bus notice] <00
2017-12-26 13:26:42.897 [bus notice] <ff
2017-12-26 13:26:42.901 [bus notice] <e7
2017-12-26 13:26:42.907 [bus notice] <00
2017-12-26 13:26:42.911 [bus notice] <aa
2017-12-26 13:26:42.954 [bus notice] <aa
2017-12-26 13:26:43.000 [bus notice] <aa
2017-12-26 13:26:43.043 [bus notice] <aa
2017-12-26 13:26:43.088 [bus notice] <aa
2017-12-26 13:26:43.093 [bus notice] <10
2017-12-26 13:26:43.101 [bus notice] <fe
2017-12-26 13:26:43.105 [bus notice] <b5
2017-12-26 13:26:43.110 [bus notice] <16
2017-12-26 13:26:43.114 [bus notice] <03
2017-12-26 13:26:43.118 [bus notice] <01
2017-12-26 13:26:43.121 [bus notice] <30
2017-12-26 13:26:43.125 [bus notice] <08
2017-12-26 13:26:43.130 [bus notice] <82
2017-12-26 13:26:43.134 [bus notice] <aa
2017-12-26 13:26:43.180 [bus notice] <aa
2017-12-26 13:26:43.223 [bus notice] <aa
2017-12-26 13:26:43.268 [bus notice] <aa
2017-12-26 13:26:43.313 [bus notice] <aa
2017-12-26 13:26:43.357 [bus notice] <aa
2017-12-26 13:26:43.401 [bus notice] <aa
2017-12-26 13:26:43.444 [bus notice] <aa
2017-12-26 13:26:43.489 [bus notice] <aa
2017-12-26 13:26:43.534 [bus notice] <aa
2017-12-26 13:26:43.578 [bus notice] <aa
2017-12-26 13:26:43.624 [bus notice] <aa
2017-12-26 13:26:43.668 [bus notice] <aa
2017-12-26 13:26:43.711 [bus notice] <aa
2017-12-26 13:26:43.756 [bus notice] <aa
2017-12-26 13:26:43.802 [bus notice] <aa
2017-12-26 13:26:43.847 [bus notice] <aa
2017-12-26 13:26:43.890 [bus notice] <aa
2017-12-26 13:26:43.935 [bus notice] <aa
2017-12-26 13:26:43.979 [bus notice] <aa
2017-12-26 13:26:44.023 [bus notice] <aa
2017-12-26 13:26:44.068 [bus notice] <aa
2017-12-26 13:26:44.113 [bus notice] <aa
2017-12-26 13:26:44.158 [bus notice] <aa
2017-12-26 13:26:44.202 [bus notice] <aa
2017-12-26 13:26:44.246 [bus notice] <aa
2017-12-26 13:26:44.289 [bus notice] <aa
2017-12-26 13:26:44.333 [bus notice] <aa
2017-12-26 13:26:44.378 [bus notice] <aa
2017-12-26 13:26:44.423 [bus notice] <aa
2017-12-26 13:26:44.469 [bus notice] <aa
2017-12-26 13:26:44.512 [bus notice] <aa
2017-12-26 13:26:44.555 [bus notice] <aa
2017-12-26 13:26:44.561 [bus notice] <10
2017-12-26 13:26:44.568 [bus notice] <50
2017-12-26 13:26:44.572 [bus notice] <b5
2017-12-26 13:26:44.576 [bus notice] <04
2017-12-26 13:26:44.581 [bus notice] <01
2017-12-26 13:26:44.585 [bus notice] <26
2017-12-26 13:26:44.589 [bus notice] <d9
2017-12-26 13:26:44.594 [bus notice] <00
2017-12-26 13:26:44.598 [bus notice] <07
2017-12-26 13:26:44.604 [bus notice] <02
2017-12-26 13:26:44.608 [bus notice] <02
2017-12-26 13:26:44.612 [bus notice] <00
2017-12-26 13:26:44.616 [bus notice] <2a
2017-12-26 13:26:44.621 [bus notice] <01
2017-12-26 13:26:44.626 [bus notice] <85
2017-12-26 13:26:44.631 [bus notice] <01
2017-12-26 13:26:44.635 [bus notice] <f7
2017-12-26 13:26:44.639 [bus notice] <00
2017-12-26 13:26:44.644 [bus notice] <aa
2017-12-26 13:26:44.688 [bus notice] <aa
2017-12-26 13:26:44.732 [bus notice] <aa
2017-12-26 13:26:44.776 [bus notice] <aa
2017-12-26 13:26:44.821 [bus notice] <aa
2017-12-26 13:26:44.825 [bus notice] <10
2017-12-26 13:26:44.834 [bus notice] <50
2017-12-26 13:26:44.838 [bus notice] <b5
2017-12-26 13:26:44.842 [bus notice] <04
2017-12-26 13:26:44.846 [bus notice] <01
2017-12-26 13:26:44.851 [bus notice] <18
2017-12-26 13:26:44.854 [bus notice] <e7
2017-12-26 13:26:44.859 [bus notice] <00
2017-12-26 13:26:44.864 [bus notice] <06
2017-12-26 13:26:44.868 [bus notice] <1a
2017-12-26 13:26:44.872 [bus notice] <1a
2017-12-26 13:26:44.878 [bus notice] <00
2017-12-26 13:26:44.882 [bus notice] <a9
2017-12-26 13:26:44.886 [bus notice] <01
2017-12-26 13:26:44.891 [bus notice] <01
2017-12-26 13:26:44.895 [bus notice] <15
2017-12-26 13:26:44.901 [bus notice] <4c
2017-12-26 13:26:44.905 [bus notice] <00
2017-12-26 13:26:44.909 [bus notice] <aa
2017-12-26 13:26:44.954 [bus notice] <aa
2017-12-26 13:26:44.997 [bus notice] <aa
2017-12-26 13:26:45.042 [bus notice] <aa
2017-12-26 13:26:45.090 [bus notice] <aa
2017-12-26 13:26:45.135 [bus notice] <aa
2017-12-26 13:26:45.179 [bus notice] <aa
2017-12-26 13:26:45.222 [bus notice] <aa
2017-12-26 13:26:45.266 [bus notice] <aa
2017-12-26 13:26:45.312 [bus notice] <aa
2017-12-26 13:26:45.356 [bus notice] <aa
2017-12-26 13:26:45.400 [bus notice] <aa
2017-12-26 13:26:45.445 [bus notice] <aa
2017-12-26 13:26:45.489 [bus notice] <aa
2017-12-26 13:26:45.533 [bus notice] <aa
2017-12-26 13:26:45.577 [bus notice] <aa
2017-12-26 13:26:45.622 [bus notice] <aa
2017-12-26 13:26:45.667 [bus notice] <aa
2017-12-26 13:26:45.711 [bus notice] <aa
2017-12-26 13:26:45.755 [bus notice] <aa
2017-12-26 13:26:45.801 [bus notice] <aa
2017-12-26 13:26:45.845 [bus notice] <aa
2017-12-26 13:26:45.890 [bus notice] <aa
2017-12-26 13:26:45.934 [bus notice] <aa
2017-12-26 13:26:45.980 [bus notice] <aa
2017-12-26 13:26:46.023 [bus notice] <aa
2017-12-26 13:26:46.067 [bus notice] <aa
2017-12-26 13:26:46.111 [bus notice] <aa
2017-12-26 13:26:46.155 [bus notice] <aa
2017-12-26 13:26:46.201 [bus notice] <aa
2017-12-26 13:26:46.245 [bus notice] <aa
2017-12-26 13:26:46.289 [bus notice] <aa
2017-12-26 13:26:46.332 [bus notice] <aa
2017-12-26 13:26:46.376 [bus notice] <aa
2017-12-26 13:26:46.422 [bus notice] <aa
2017-12-26 13:26:46.469 [bus notice] <aa
2017-12-26 13:26:46.513 [bus notice] <aa
2017-12-26 13:26:46.558 [bus notice] <aa
2017-12-26 13:26:46.562 [bus notice] <10
2017-12-26 13:26:46.569 [bus notice] <50
2017-12-26 13:26:46.573 [bus notice] <b5
2017-12-26 13:26:46.578 [bus notice] <03
2017-12-26 13:26:46.582 [bus notice] <02
2017-12-26 13:26:46.586 [bus notice] <00
2017-12-26 13:26:46.590 [bus notice] <03
2017-12-26 13:26:46.595 [bus notice] <43
2017-12-26 13:26:46.599 [bus notice] <00
2017-12-26 13:26:46.603 [bus notice] <0a
2017-12-26 13:26:46.608 [bus notice] <ff
2017-12-26 13:26:46.612 [bus notice] <ff
2017-12-26 13:26:46.618 [bus notice] <ff
2017-12-26 13:26:46.622 [bus notice] <ff
2017-12-26 13:26:46.626 [bus notice] <ff
2017-12-26 13:26:46.630 [bus notice] <ff
2017-12-26 13:26:46.635 [bus notice] <ff
2017-12-26 13:26:46.640 [bus notice] <ff
2017-12-26 13:26:46.645 [bus notice] <ff
2017-12-26 13:26:46.649 [bus notice] <ff
2017-12-26 13:26:46.653 [bus notice] <0f
2017-12-26 13:26:46.659 [bus notice] <00
2017-12-26 13:26:46.662 [bus notice] <aa
2017-12-26 13:26:46.707 [bus notice] <aa
2017-12-26 13:26:46.750 [bus notice] <aa
2017-12-26 13:26:46.794 [bus notice] <aa
2017-12-26 13:26:46.839 [bus notice] <aa
2017-12-26 13:26:46.845 [bus notice] <10
2017-12-26 13:26:46.852 [bus notice] <50
2017-12-26 13:26:46.856 [bus notice] <b5
2017-12-26 13:26:46.860 [bus notice] <09
2017-12-26 13:26:46.864 [bus notice] <04
2017-12-26 13:26:46.869 [bus notice] <0e
2017-12-26 13:26:46.873 [bus notice] <01
2017-12-26 13:26:46.877 [bus notice] <00
2017-12-26 13:26:46.881 [bus notice] <01
2017-12-26 13:26:46.885 [bus notice] <55
2017-12-26 13:26:46.890 [bus notice] <00
2017-12-26 13:26:46.895 [bus notice] <00
2017-12-26 13:26:46.900 [bus notice] <00
2017-12-26 13:26:46.904 [bus notice] <00
2017-12-26 13:26:46.908 [bus notice] <aa
2017-12-26 13:26:46.954 [bus notice] <aa
2017-12-26 13:26:46.998 [bus notice] <aa
2017-12-26 13:26:47.041 [bus notice] <aa
2017-12-26 13:26:47.085 [bus notice] <aa
2017-12-26 13:26:47.089 [bus notice] <10
2017-12-26 13:26:47.098 [bus notice] <50
2017-12-26 13:26:47.102 [bus notice] <b5
2017-12-26 13:26:47.107 [bus notice] <09
2017-12-26 13:26:47.111 [bus notice] <04
2017-12-26 13:26:47.115 [bus notice] <0e
2017-12-26 13:26:47.118 [bus notice] <20
2017-12-26 13:26:47.122 [bus notice] <00
2017-12-26 13:26:47.127 [bus notice] <01
2017-12-26 13:26:47.131 [bus notice] <2e
2017-12-26 13:26:47.135 [bus notice] <00
2017-12-26 13:26:47.141 [bus notice] <00
2017-12-26 13:26:47.145 [bus notice] <00
2017-12-26 13:26:47.149 [bus notice] <00
2017-12-26 13:26:47.154 [bus notice] <aa
2017-12-26 13:26:47.198 [bus notice] <aa
2017-12-26 13:26:47.242 [bus notice] <aa
2017-12-26 13:26:47.288 [bus notice] <aa
2017-12-26 13:26:47.332 [bus notice] <aa
2017-12-26 13:26:47.336 [bus notice] <10
2017-12-26 13:26:47.344 [bus notice] <08
2017-12-26 13:26:47.348 [bus notice] <b5
2017-12-26 13:26:47.352 [bus notice] <10
2017-12-26 13:26:47.356 [bus notice] <09
2017-12-26 13:26:47.361 [bus notice] <00
2017-12-26 13:26:47.365 [bus notice] <00
2017-12-26 13:26:47.369 [bus notice] <56
2017-12-26 13:26:47.373 [bus notice] <74
2017-12-26 13:26:47.377 [bus notice] <ff
2017-12-26 13:26:47.382 [bus notice] <ff
2017-12-26 13:26:47.386 [bus notice] <04
2017-12-26 13:26:47.390 [bus notice] <ff
2017-12-26 13:26:47.394 [bus notice] <00
2017-12-26 13:26:47.398 [bus notice] <ae
2017-12-26 13:26:47.403 [bus notice] <00
2017-12-26 13:26:47.422 [bus notice] <01
2017-12-26 13:26:47.427 [bus notice] <01
2017-12-26 13:26:47.431 [bus notice] <9a
2017-12-26 13:26:47.436 [bus notice] <00
2017-12-26 13:26:47.439 [bus notice] <aa
2017-12-26 13:26:47.484 [bus notice] <aa
2017-12-26 13:26:47.528 [bus notice] <aa
2017-12-26 13:26:47.572 [bus notice] <aa
2017-12-26 13:26:47.618 [bus notice] <aa
2017-12-26 13:26:47.622 [bus notice] <10
2017-12-26 13:26:47.631 [bus notice] <50
2017-12-26 13:26:47.635 [bus notice] <b5
2017-12-26 13:26:47.639 [bus notice] <05
2017-12-26 13:26:47.642 [bus notice] <02
2017-12-26 13:26:47.646 [bus notice] <18
2017-12-26 13:26:47.651 [bus notice] <00
2017-12-26 13:26:47.655 [bus notice] <34
2017-12-26 13:26:47.659 [bus notice] <00
2017-12-26 13:26:47.664 [bus notice] <00
2017-12-26 13:26:47.669 [bus notice] <00
2017-12-26 13:26:47.674 [bus notice] <00
2017-12-26 13:26:47.678 [bus notice] <aa
2017-12-26 13:26:47.721 [bus notice] <aa
2017-12-26 13:26:47.765 [bus notice] <aa
2017-12-26 13:26:47.811 [bus notice] <aa
2017-12-26 13:26:47.857 [bus notice] <aa
2017-12-26 13:26:47.900 [bus notice] <aa
2017-12-26 13:26:47.945 [bus notice] <aa
2017-12-26 13:26:47.990 [bus notice] <aa
2017-12-26 13:26:48.035 [bus notice] <aa
2017-12-26 13:26:48.080 [bus notice] <aa
2017-12-26 13:26:48.124 [bus notice] <aa
2017-12-26 13:26:48.167 [bus notice] <aa
2017-12-26 13:26:48.211 [bus notice] <aa
2017-12-26 13:26:48.255 [bus notice] <aa
2017-12-26 13:26:48.300 [bus notice] <aa
2017-12-26 13:26:48.344 [bus notice] <aa
2017-12-26 13:26:48.390 [bus notice] <aa
2017-12-26 13:26:48.434 [bus notice] <aa
2017-12-26 13:26:48.479 [bus notice] <aa
2017-12-26 13:26:48.525 [bus notice] <aa
2017-12-26 13:26:48.570 [bus notice] <aa
2017-12-26 13:26:48.613 [bus notice] <aa
2017-12-26 13:26:48.617 [bus notice] <10
2017-12-26 13:26:48.626 [bus notice] <50
2017-12-26 13:26:48.630 [bus notice] <b5
2017-12-26 13:26:48.634 [bus notice] <05
2017-12-26 13:26:48.639 [bus notice] <02
2017-12-26 13:26:48.643 [bus notice] <30
2017-12-26 13:26:48.647 [bus notice] <01
2017-12-26 13:26:48.651 [bus notice] <48
2017-12-26 13:26:48.654 [bus notice] <00
2017-12-26 13:26:48.660 [bus notice] <01
2017-12-26 13:26:48.664 [bus notice] <01
2017-12-26 13:26:48.669 [bus notice] <9a
2017-12-26 13:26:48.673 [bus notice] <00
2017-12-26 13:26:48.677 [bus notice] <aa
2017-12-26 13:26:48.722 [bus notice] <aa
2017-12-26 13:26:48.767 [bus notice] <aa
2017-12-26 13:26:48.812 [bus notice] <aa
2017-12-26 13:26:48.856 [bus notice] <aa
2017-12-26 13:26:48.899 [bus notice] <aa
2017-12-26 13:26:48.945 [bus notice] <aa
2017-12-26 13:26:48.989 [bus notice] <aa
2017-12-26 13:26:49.032 [bus notice] <aa
2017-12-26 13:26:49.077 [bus notice] <aa
2017-12-26 13:26:49.122 [bus notice] <aa
2017-12-26 13:26:49.168 [bus notice] <aa
2017-12-26 13:26:49.214 [bus notice] <aa
2017-12-26 13:26:49.258 [bus notice] <aa
2017-12-26 13:26:49.302 [bus notice] <aa
2017-12-26 13:26:49.346 [bus notice] <aa
2017-12-26 13:26:49.391 [bus notice] <aa
2017-12-26 13:26:49.435 [bus notice] <aa
2017-12-26 13:26:49.479 [bus notice] <aa
2017-12-26 13:26:49.525 [bus notice] <aa
2017-12-26 13:26:49.569 [bus notice] <aa
2017-12-26 13:26:49.612 [bus notice] <aa
2017-12-26 13:26:49.657 [bus notice] <aa
2017-12-26 13:26:49.702 [bus notice] <aa
2017-12-26 13:26:49.745 [bus notice] <aa
2017-12-26 13:26:49.789 [bus notice] <aa
2017-12-26 13:26:49.833 [bus notice] <aa
2017-12-26 13:26:49.880 [bus notice] <aa
2017-12-26 13:26:49.925 [bus notice] <aa
2017-12-26 13:26:49.969 [bus notice] <aa
2017-12-26 13:26:50.012 [bus notice] <aa
2017-12-26 13:26:50.056 [bus notice] <aa
2017-12-26 13:26:50.102 [bus notice] <aa
2017-12-26 13:26:50.147 [bus notice] <aa
2017-12-26 13:26:50.190 [bus notice] <aa
2017-12-26 13:26:50.234 [bus notice] <aa
2017-12-26 13:26:50.279 [bus notice] <aa
2017-12-26 13:26:50.322 [bus notice] <aa
2017-12-26 13:26:50.366 [bus notice] <aa
2017-12-26 13:26:50.411 [bus notice] <aa
2017-12-26 13:26:50.455 [bus notice] <aa
2017-12-26 13:26:50.499 [bus notice] <aa
2017-12-26 13:26:50.545 [bus notice] <aa
2017-12-26 13:26:50.589 [bus notice] <aa
2017-12-26 13:26:50.634 [bus notice] <aa
2017-12-26 13:26:50.678 [bus notice] <aa
2017-12-26 13:26:50.723 [bus notice] <aa
2017-12-26 13:26:50.768 [bus notice] <aa
2017-12-26 13:26:50.811 [bus notice] <aa
2017-12-26 13:26:50.857 [bus notice] <aa
2017-12-26 13:26:50.900 [bus notice] <aa
2017-12-26 13:26:50.944 [bus notice] <aa
2017-12-26 13:26:50.988 [bus notice] <aa
2017-12-26 13:26:51.033 [bus notice] <aa
2017-12-26 13:26:51.078 [bus notice] <aa
2017-12-26 13:26:51.123 [bus notice] <aa
2017-12-26 13:26:51.166 [bus notice] <aa
2017-12-26 13:26:51.211 [bus notice] <aa
2017-12-26 13:26:51.257 [bus notice] <aa
2017-12-26 13:26:51.302 [bus notice] <aa
2017-12-26 13:26:51.347 [bus notice] <aa
2017-12-26 13:26:51.390 [bus notice] <aa
2017-12-26 13:26:51.435 [bus notice] <aa
2017-12-26 13:26:51.479 [bus notice] <aa
2017-12-26 13:26:51.523 [bus notice] <aa
2017-12-26 13:26:51.569 [bus notice] <aa
2017-12-26 13:26:51.613 [bus notice] <aa
2017-12-26 13:26:51.658 [bus notice] <aa
2017-12-26 13:26:51.702 [bus notice] <aa
2017-12-26 13:26:51.745 [bus notice] <aa
2017-12-26 13:26:51.789 [bus notice] <aa
2017-12-26 13:26:51.835 [bus notice] <aa
2017-12-26 13:26:51.879 [bus notice] <aa
2017-12-26 13:26:51.925 [bus notice] <aa
2017-12-26 13:26:51.969 [bus notice] <aa
2017-12-26 13:26:52.013 [bus notice] <aa
2017-12-26 13:26:52.058 [bus notice] <aa
2017-12-26 13:26:52.102 [bus notice] <aa
2017-12-26 13:26:52.146 [bus notice] <aa
2017-12-26 13:26:52.190 [bus notice] <aa
2017-12-26 13:26:52.235 [bus notice] <aa
2017-12-26 13:26:52.279 [bus notice] <aa
2017-12-26 13:26:52.323 [bus notice] <aa
2017-12-26 13:26:52.328 [bus notice] <10
2017-12-26 13:26:52.336 [bus notice] <50
2017-12-26 13:26:52.340 [bus notice] <b5
2017-12-26 13:26:52.343 [bus notice] <03
2017-12-26 13:26:52.348 [bus notice] <02
2017-12-26 13:26:52.352 [bus notice] <00
2017-12-26 13:26:52.356 [bus notice] <01
2017-12-26 13:26:52.360 [bus notice] <41
2017-12-26 13:26:52.364 [bus notice] <00
2017-12-26 13:26:52.370 [bus notice] <0a
2017-12-26 13:26:52.374 [bus notice] <ff
2017-12-26 13:26:52.379 [bus notice] <ff
2017-12-26 13:26:52.383 [bus notice] <ff
2017-12-26 13:26:52.387 [bus notice] <ff
2017-12-26 13:26:52.393 [bus notice] <ff
2017-12-26 13:26:52.397 [bus notice] <ff
2017-12-26 13:26:52.401 [bus notice] <ff
2017-12-26 13:26:52.406 [bus notice] <ff
2017-12-26 13:26:52.411 [bus notice] <ff
2017-12-26 13:26:52.416 [bus notice] <ff
2017-12-26 13:26:52.420 [bus notice] <0f
2017-12-26 13:26:52.424 [bus notice] <00
2017-12-26 13:26:52.428 [bus notice] <aa
2017-12-26 13:26:52.473 [bus notice] <aa
2017-12-26 13:26:52.517 [bus notice] <aa
2017-12-26 13:26:52.562 [bus notice] <aa
2017-12-26 13:26:52.607 [bus notice] <aa
2017-12-26 13:26:52.613 [bus notice] <10
2017-12-26 13:26:52.620 [bus notice] <08
2017-12-26 13:26:52.624 [bus notice] <b5
2017-12-26 13:26:52.629 [bus notice] <11
2017-12-26 13:26:52.633 [bus notice] <01
2017-12-26 13:26:52.637 [bus notice] <01
2017-12-26 13:26:52.642 [bus notice] <89
2017-12-26 13:26:52.646 [bus notice] <00
2017-12-26 13:26:52.660 [bus notice] <09
2017-12-26 13:26:52.663 [bus notice] <4e
2017-12-26 13:26:52.667 [bus notice] <ff
2017-12-26 13:26:52.671 [bus notice] <30
2017-12-26 13:26:52.676 [bus notice] <08
2017-12-26 13:26:52.680 [bus notice] <00
2017-12-26 13:26:52.684 [bus notice] <58
2017-12-26 13:26:52.688 [bus notice] <00
2017-12-26 13:26:52.693 [bus notice] <00
2017-12-26 13:26:52.697 [bus notice] <ff
2017-12-26 13:26:52.701 [bus notice] <e7
2017-12-26 13:26:52.705 [bus notice] <00
2017-12-26 13:26:52.710 [bus notice] <aa
2017-12-26 13:26:52.752 [bus notice] <aa
2017-12-26 13:26:52.798 [bus notice] <aa
2017-12-26 13:26:52.843 [bus notice] <aa
2017-12-26 13:26:52.885 [bus notice] <aa
2017-12-26 13:26:52.930 [bus notice] <aa
2017-12-26 13:26:52.975 [bus notice] <aa
2017-12-26 13:26:53.020 [bus notice] <aa
2017-12-26 13:26:53.063 [bus notice] <aa
2017-12-26 13:26:53.107 [bus notice] <aa
2017-12-26 13:26:53.152 [bus notice] <aa
2017-12-26 13:26:53.196 [bus notice] <aa
2017-12-26 13:26:53.240 [bus notice] <aa
2017-12-26 13:26:53.287 [bus notice] <aa
2017-12-26 13:26:53.332 [bus notice] <aa
2017-12-26 13:26:53.376 [bus notice] <aa
2017-12-26 13:26:53.419 [bus notice] <aa
2017-12-26 13:26:53.463 [bus notice] <aa
2017-12-26 13:26:53.507 [bus notice] <aa
2017-12-26 13:26:53.552 [bus notice] <aa
2017-12-26 13:26:53.596 [bus notice] <aa
2017-12-26 13:26:53.641 [bus notice] <aa
2017-12-26 13:26:53.685 [bus notice] <aa
2017-12-26 13:26:53.729 [bus notice] <aa
2017-12-26 13:26:53.773 [bus notice] <aa
2017-12-26 13:26:53.819 [bus notice] <aa
2017-12-26 13:26:53.865 [bus notice] <aa
2017-12-26 13:26:53.909 [bus notice] <aa
2017-12-26 13:26:53.954 [bus notice] <aa
2017-12-26 13:26:53.999 [bus notice] <aa
2017-12-26 13:26:54.044 [bus notice] <aa
2017-12-26 13:26:54.088 [bus notice] <aa
2017-12-26 13:26:54.132 [bus notice] <aa
2017-12-26 13:26:54.176 [bus notice] <aa
2017-12-26 13:26:54.220 [bus notice] <aa
2017-12-26 13:26:54.265 [bus notice] <aa
2017-12-26 13:26:54.309 [bus notice] <aa
2017-12-26 13:26:54.355 [bus notice] <aa
2017-12-26 13:26:54.359 [bus notice] <10
2017-12-26 13:26:54.366 [bus notice] <50
2017-12-26 13:26:54.370 [bus notice] <b5
2017-12-26 13:26:54.375 [bus notice] <04
2017-12-26 13:26:54.379 [bus notice] <01
2017-12-26 13:26:54.383 [bus notice] <18
2017-12-26 13:26:54.387 [bus notice] <e7
2017-12-26 13:26:54.392 [bus notice] <00
2017-12-26 13:26:54.396 [bus notice] <06
2017-12-26 13:26:54.402 [bus notice] <1a
2017-12-26 13:26:54.406 [bus notice] <1a
2017-12-26 13:26:54.410 [bus notice] <00
2017-12-26 13:26:54.415 [bus notice] <a7
2017-12-26 13:26:54.419 [bus notice] <01
2017-12-26 13:26:54.425 [bus notice] <15
2017-12-26 13:26:54.429 [bus notice] <73
2017-12-26 13:26:54.433 [bus notice] <00
2017-12-26 13:26:54.437 [bus notice] <aa
2017-12-26 13:26:54.482 [bus notice] <aa
2017-12-26 13:26:54.526 [bus notice] <aa
2017-12-26 13:26:54.569 [bus notice] <aa
2017-12-26 13:26:54.615 [bus notice] <aa
2017-12-26 13:26:54.620 [bus notice] <10
2017-12-26 13:26:54.628 [bus notice] <08
2017-12-26 13:26:54.632 [bus notice] <b5
2017-12-26 13:26:54.636 [bus notice] <11
2017-12-26 13:26:54.641 [bus notice] <01
2017-12-26 13:26:54.645 [bus notice] <02
2017-12-26 13:26:54.649 [bus notice] <8a
2017-12-26 13:26:54.653 [bus notice] <00
2017-12-26 13:26:54.671 [bus notice] <05
2017-12-26 13:26:54.675 [bus notice] <03
2017-12-26 13:26:54.679 [bus notice] <3c
2017-12-26 13:26:54.683 [bus notice] <8a
2017-12-26 13:26:54.688 [bus notice] <50
2017-12-26 13:26:54.692 [bus notice] <82
2017-12-26 13:26:54.696 [bus notice] <6d
2017-12-26 13:26:54.701 [bus notice] <00
2017-12-26 13:26:54.705 [bus notice] <aa
2017-12-26 13:26:54.748 [bus notice] <aa
2017-12-26 13:26:54.792 [bus notice] <aa
2017-12-26 13:26:54.836 [bus notice] <aa
2017-12-26 13:26:54.881 [bus notice] <aa
2017-12-26 13:26:54.925 [bus notice] <aa
2017-12-26 13:26:54.968 [bus notice] <aa
2017-12-26 13:26:55.013 [bus notice] <aa
2017-12-26 13:26:55.058 [bus notice] <aa
2017-12-26 13:26:55.102 [bus notice] <aa
2017-12-26 13:26:55.147 [bus notice] <aa
2017-12-26 13:26:55.190 [bus notice] <aa
2017-12-26 13:26:55.234 [bus notice] <aa
2017-12-26 13:26:55.278 [bus notice] <aa
2017-12-26 13:26:55.324 [bus notice] <aa
2017-12-26 13:26:55.368 [bus notice] <aa
2017-12-26 13:26:55.413 [bus notice] <aa
2017-12-26 13:26:55.457 [bus notice] <aa
2017-12-26 13:26:55.501 [bus notice] <aa
2017-12-26 13:26:55.544 [bus notice] <aa
2017-12-26 13:26:55.588 [bus notice] <aa
2017-12-26 13:26:55.633 [bus notice] <aa
2017-12-26 13:26:55.676 [bus notice] <aa
2017-12-26 13:26:55.723 [bus notice] <aa
2017-12-26 13:26:55.766 [bus notice] <aa
2017-12-26 13:26:55.810 [bus notice] <aa
2017-12-26 13:26:55.855 [bus notice] <aa
2017-12-26 13:26:55.899 [bus notice] <aa
2017-12-26 13:26:55.943 [bus notice] <aa
2017-12-26 13:26:55.988 [bus notice] <aa
2017-12-26 13:26:56.033 [bus notice] <aa
2017-12-26 13:26:56.078 [bus notice] <aa
2017-12-26 13:26:56.122 [bus notice] <aa
2017-12-26 13:26:56.166 [bus notice] <aa
2017-12-26 13:26:56.210 [bus notice] <aa
2017-12-26 13:26:56.254 [bus notice] <aa
2017-12-26 13:26:56.298 [bus notice] <aa
2017-12-26 13:26:56.343 [bus notice] <aa
2017-12-26 13:26:56.347 [bus notice] <10
2017-12-26 13:26:56.356 [bus notice] <50
2017-12-26 13:26:56.360 [bus notice] <b5
2017-12-26 13:26:56.364 [bus notice] <03
2017-12-26 13:26:56.368 [bus notice] <02
2017-12-26 13:26:56.373 [bus notice] <00
2017-12-26 13:26:56.377 [bus notice] <03
2017-12-26 13:26:56.381 [bus notice] <43
2017-12-26 13:26:56.386 [bus notice] <00
2017-12-26 13:26:56.390 [bus notice] <0a
2017-12-26 13:26:56.394 [bus notice] <ff
2017-12-26 13:26:56.398 [bus notice] <ff
2017-12-26 13:26:56.404 [bus notice] <ff
2017-12-26 13:26:56.408 [bus notice] <ff
2017-12-26 13:26:56.413 [bus notice] <ff
2017-12-26 13:26:56.417 [bus notice] <ff
2017-12-26 13:26:56.421 [bus notice] <ff
2017-12-26 13:26:56.427 [bus notice] <ff
2017-12-26 13:26:56.431 [bus notice] <ff
2017-12-26 13:26:56.436 [bus notice] <ff
2017-12-26 13:26:56.440 [bus notice] <0f
2017-12-26 13:26:56.444 [bus notice] <00
2017-12-26 13:26:56.449 [bus notice] <aa
2017-12-26 13:26:56.494 [bus notice] <aa
2017-12-26 13:26:56.539 [bus notice] <aa
2017-12-26 13:26:56.583 [bus notice] <aa
2017-12-26 13:26:56.627 [bus notice] <aa
2017-12-26 13:26:56.632 [bus notice] <10
2017-12-26 13:26:56.639 [bus notice] <50
2017-12-26 13:26:56.643 [bus notice] <b5
2017-12-26 13:26:56.647 [bus notice] <09
2017-12-26 13:26:56.651 [bus notice] <04
2017-12-26 13:26:56.656 [bus notice] <0e
2017-12-26 13:26:56.660 [bus notice] <01
2017-12-26 13:26:56.664 [bus notice] <00
2017-12-26 13:26:56.669 [bus notice] <01
2017-12-26 13:26:56.673 [bus notice] <55
2017-12-26 13:26:56.677 [bus notice] <00
2017-12-26 13:26:56.681 [bus notice] <00
2017-12-26 13:26:56.686 [bus notice] <00
2017-12-26 13:26:56.690 [bus notice] <00
2017-12-26 13:26:56.694 [bus notice] <aa
2017-12-26 13:26:56.739 [bus notice] <aa
2017-12-26 13:26:56.783 [bus notice] <aa
2017-12-26 13:26:56.827 [bus notice] <aa
2017-12-26 13:26:56.870 [bus notice] <aa
2017-12-26 13:26:56.876 [bus notice] <10
2017-12-26 13:26:56.883 [bus notice] <50
2017-12-26 13:26:56.887 [bus notice] <b5
2017-12-26 13:26:56.891 [bus notice] <09
2017-12-26 13:26:56.896 [bus notice] <04
2017-12-26 13:26:56.900 [bus notice] <0e
2017-12-26 13:26:56.904 [bus notice] <20
2017-12-26 13:26:56.908 [bus notice] <00
2017-12-26 13:26:56.911 [bus notice] <01
2017-12-26 13:26:56.916 [bus notice] <2e
2017-12-26 13:26:56.921 [bus notice] <00
2017-12-26 13:26:56.926 [bus notice] <00
2017-12-26 13:26:56.930 [bus notice] <00
2017-12-26 13:26:56.934 [bus notice] <00
2017-12-26 13:26:56.938 [bus notice] <aa
2017-12-26 13:26:56.983 [bus notice] <aa
2017-12-26 13:26:57.027 [bus notice] <aa
2017-12-26 13:26:57.073 [bus notice] <aa
2017-12-26 13:26:57.116 [bus notice] <aa
2017-12-26 13:26:57.120 [bus notice] <10
2017-12-26 13:26:57.129 [bus notice] <08
2017-12-26 13:26:57.133 [bus notice] <b5
2017-12-26 13:26:57.137 [bus notice] <10
2017-12-26 13:26:57.141 [bus notice] <09
2017-12-26 13:26:57.146 [bus notice] <00
2017-12-26 13:26:57.149 [bus notice] <00
2017-12-26 13:26:57.153 [bus notice] <56
2017-12-26 13:26:57.157 [bus notice] <74
2017-12-26 13:26:57.161 [bus notice] <ff
2017-12-26 13:26:57.166 [bus notice] <ff
2017-12-26 13:26:57.170 [bus notice] <04
2017-12-26 13:26:57.174 [bus notice] <ff
2017-12-26 13:26:57.179 [bus notice] <00
2017-12-26 13:26:57.183 [bus notice] <ae
2017-12-26 13:26:57.187 [bus notice] <00
2017-12-26 13:26:57.204 [bus notice] <01
2017-12-26 13:26:57.209 [bus notice] <01
2017-12-26 13:26:57.213 [bus notice] <9a
2017-12-26 13:26:57.217 [bus notice] <00
2017-12-26 13:26:57.221 [bus notice] <aa
2017-12-26 13:26:57.266 [bus notice] <aa
2017-12-26 13:26:57.309 [bus notice] <aa
2017-12-26 13:26:57.355 [bus notice] <aa
2017-12-26 13:26:57.402 [bus notice] <aa
2017-12-26 13:26:57.406 [bus notice] <10
2017-12-26 13:26:57.414 [bus notice] <50
2017-12-26 13:26:57.418 [bus notice] <b5
2017-12-26 13:26:57.422 [bus notice] <05
2017-12-26 13:26:57.426 [bus notice] <02
2017-12-26 13:26:57.431 [bus notice] <18
2017-12-26 13:26:57.435 [bus notice] <00
2017-12-26 13:26:57.439 [bus notice] <34
2017-12-26 13:26:57.443 [bus notice] <00
2017-12-26 13:26:57.448 [bus notice] <00
2017-12-26 13:26:57.453 [bus notice] <00
2017-12-26 13:26:57.456 [bus notice] <00
2017-12-26 13:26:57.461 [bus notice] <aa
2017-12-26 13:26:57.506 [bus notice] <aa
2017-12-26 13:26:57.549 [bus notice] <aa
2017-12-26 13:26:57.594 [bus notice] <aa
2017-12-26 13:26:57.639 [bus notice] <aa
2017-12-26 13:26:57.684 [bus notice] <aa
2017-12-26 13:26:57.728 [bus notice] <aa
2017-12-26 13:26:57.772 [bus notice] <aa
2017-12-26 13:26:57.816 [bus notice] <aa
2017-12-26 13:26:57.861 [bus notice] <aa
2017-12-26 13:26:57.904 [bus notice] <aa
2017-12-26 13:26:57.950 [bus notice] <aa
2017-12-26 13:26:57.994 [bus notice] <aa
2017-12-26 13:26:58.040 [bus notice] <aa
2017-12-26 13:26:58.086 [bus notice] <aa
2017-12-26 13:26:58.130 [bus notice] <aa
2017-12-26 13:26:58.174 [bus notice] <aa
2017-12-26 13:26:58.219 [bus notice] <aa
2017-12-26 13:26:58.263 [bus notice] <aa
2017-12-26 13:26:58.307 [bus notice] <aa
2017-12-26 13:26:58.351 [bus notice] <aa
2017-12-26 13:26:58.355 [bus notice] <10
2017-12-26 13:26:58.363 [bus notice] <50
2017-12-26 13:26:58.368 [bus notice] <b5
2017-12-26 13:26:58.372 [bus notice] <05
2017-12-26 13:26:58.376 [bus notice] <02
2017-12-26 13:26:58.380 [bus notice] <30
2017-12-26 13:26:58.384 [bus notice] <01
2017-12-26 13:26:58.389 [bus notice] <48
2017-12-26 13:26:58.393 [bus notice] <00
2017-12-26 13:26:58.397 [bus notice] <01
2017-12-26 13:26:58.401 [bus notice] <01
2017-12-26 13:26:58.407 [bus notice] <9a
2017-12-26 13:26:58.411 [bus notice] <00
2017-12-26 13:26:58.415 [bus notice] <aa
2017-12-26 13:26:58.461 [bus notice] <aa
2017-12-26 13:26:58.503 [bus notice] <aa
2017-12-26 13:26:58.548 [bus notice] <aa
2017-12-26 13:26:58.592 [bus notice] <aa
2017-12-26 13:26:58.636 [bus notice] <aa
2017-12-26 13:26:58.682 [bus notice] <aa
2017-12-26 13:26:58.729 [bus notice] <aa
2017-12-26 13:26:58.774 [bus notice] <aa
2017-12-26 13:26:58.817 [bus notice] <aa
2017-12-26 13:26:58.862 [bus notice] <aa
2017-12-26 13:26:58.907 [bus notice] <aa
2017-12-26 13:26:58.950 [bus notice] <aa
2017-12-26 13:26:58.994 [bus notice] <aa
2017-12-26 13:26:59.039 [bus notice] <aa
2017-12-26 13:26:59.083 [bus notice] <aa
2017-12-26 13:26:59.127 [bus notice] <aa
2017-12-26 13:26:59.173 [bus notice] <aa
2017-12-26 13:26:59.217 [bus notice] <aa
2017-12-26 13:26:59.261 [bus notice] <aa
2017-12-26 13:26:59.306 [bus notice] <aa
2017-12-26 13:26:59.350 [bus notice] <aa
2017-12-26 13:26:59.395 [bus notice] <aa
2017-12-26 13:26:59.441 [bus notice] <aa
2017-12-26 13:26:59.485 [bus notice] <aa
2017-12-26 13:26:59.530 [bus notice] <aa
2017-12-26 13:26:59.574 [bus notice] <aa
2017-12-26 13:26:59.620 [bus notice] <aa
2017-12-26 13:26:59.664 [bus notice] <aa
2017-12-26 13:26:59.708 [bus notice] <aa
2017-12-26 13:26:59.753 [bus notice] <aa
2017-12-26 13:26:59.797 [bus notice] <aa
2017-12-26 13:26:59.840 [bus notice] <aa
2017-12-26 13:26:59.884 [bus notice] <aa
2017-12-26 13:26:59.928 [bus notice] <aa
2017-12-26 13:26:59.973 [bus notice] <aa
2017-12-26 13:27:00.018 [bus notice] <aa
2017-12-26 13:27:00.063 [bus notice] <aa
2017-12-26 13:27:00.108 [bus notice] <aa
2017-12-26 13:27:00.152 [bus notice] <aa
2017-12-26 13:27:00.196 [bus notice] <aa
2017-12-26 13:27:00.241 [bus notice] <aa
2017-12-26 13:27:00.285 [bus notice] <aa
2017-12-26 13:27:00.329 [bus notice] <aa
2017-12-26 13:27:00.373 [bus notice] <aa
2017-12-26 13:27:00.378 [bus notice] <10
2017-12-26 13:27:00.386 [bus notice] <50
2017-12-26 13:27:00.390 [bus notice] <b5
2017-12-26 13:27:00.393 [bus notice] <03
2017-12-26 13:27:00.398 [bus notice] <02
2017-12-26 13:27:00.402 [bus notice] <00
2017-12-26 13:27:00.406 [bus notice] <01
2017-12-26 13:27:00.410 [bus notice] <41
2017-12-26 13:27:00.415 [bus notice] <00
2017-12-26 13:27:00.419 [bus notice] <0a
2017-12-26 13:27:00.423 [bus notice] <ff
2017-12-26 13:27:00.429 [bus notice] <ff
2017-12-26 13:27:00.433 [bus notice] <ff
2017-12-26 13:27:00.438 [bus notice] <ff
2017-12-26 13:27:00.443 [bus notice] <ff
2017-12-26 13:27:00.447 [bus notice] <ff
2017-12-26 13:27:00.452 [bus notice] <ff
2017-12-26 13:27:00.456 [bus notice] <ff
2017-12-26 13:27:00.461 [bus notice] <ff
2017-12-26 13:27:00.466 [bus notice] <ff
2017-12-26 13:27:00.470 [bus notice] <0f
2017-12-26 13:27:00.474 [bus notice] <00
2017-12-26 13:27:00.478 [bus notice] <aa
2017-12-26 13:27:00.523 [bus notice] <aa
2017-12-26 13:27:00.568 [bus notice] <aa
2017-12-26 13:27:00.612 [bus notice] <aa
2017-12-26 13:27:00.656 [bus notice] <aa
2017-12-26 13:27:00.660 [bus notice] <10
2017-12-26 13:27:00.669 [bus notice] <08
2017-12-26 13:27:00.673 [bus notice] <b5
2017-12-26 13:27:00.677 [bus notice] <11
2017-12-26 13:27:00.680 [bus notice] <01
2017-12-26 13:27:00.685 [bus notice] <01
2017-12-26 13:27:00.689 [bus notice] <89
2017-12-26 13:27:00.693 [bus notice] <00
2017-12-26 13:27:00.706 [bus notice] <09
2017-12-26 13:27:00.710 [bus notice] <4e
2017-12-26 13:27:00.715 [bus notice] <ff
2017-12-26 13:27:00.719 [bus notice] <30
2017-12-26 13:27:00.723 [bus notice] <08
2017-12-26 13:27:00.728 [bus notice] <00
2017-12-26 13:27:00.732 [bus notice] <58
2017-12-26 13:27:00.735 [bus notice] <01
2017-12-26 13:27:00.739 [bus notice] <00
2017-12-26 13:27:00.743 [bus notice] <ff
2017-12-26 13:27:00.748 [bus notice] <f1
2017-12-26 13:27:00.752 [bus notice] <00
2017-12-26 13:27:00.756 [bus notice] <aa
2017-12-26 13:27:00.800 [bus notice] <aa
2017-12-26 13:27:00.845 [bus notice] <aa
2017-12-26 13:27:00.889 [bus notice] <aa
2017-12-26 13:27:00.933 [bus notice] <aa
2017-12-26 13:27:00.976 [bus notice] <aa
2017-12-26 13:27:01.022 [bus notice] <aa
2017-12-26 13:27:01.067 [bus notice] <aa
2017-12-26 13:27:01.110 [bus notice] <aa
2017-12-26 13:27:01.155 [bus notice] <aa
2017-12-26 13:27:01.198 [bus notice] <aa
2017-12-26 13:27:01.242 [bus notice] <aa
2017-12-26 13:27:01.288 [bus notice] <aa
2017-12-26 13:27:01.332 [bus notice] <aa
2017-12-26 13:27:01.377 [bus notice] <aa
2017-12-26 13:27:01.422 [bus notice] <aa
2017-12-26 13:27:01.467 [bus notice] <aa
2017-12-26 13:27:01.511 [bus notice] <aa
2017-12-26 13:27:01.558 [bus notice] <aa
2017-12-26 13:27:01.601 [bus notice] <aa
2017-12-26 13:27:01.645 [bus notice] <aa
2017-12-26 13:27:01.690 [bus notice] <aa
2017-12-26 13:27:01.733 [bus notice] <aa
2017-12-26 13:27:01.777 [bus notice] <aa
2017-12-26 13:27:01.822 [bus notice] <aa
2017-12-26 13:27:01.867 [bus notice] <aa
2017-12-26 13:27:01.912 [bus notice] <aa
2017-12-26 13:27:01.955 [bus notice] <aa
2017-12-26 13:27:02.000 [bus notice] <aa
2017-12-26 13:27:02.044 [bus notice] <aa
2017-12-26 13:27:02.088 [bus notice] <aa
2017-12-26 13:27:02.134 [bus notice] <aa
2017-12-26 13:27:02.178 [bus notice] <aa
2017-12-26 13:27:02.222 [bus notice] <aa
2017-12-26 13:27:02.266 [bus notice] <aa
2017-12-26 13:27:02.309 [bus notice] <aa
2017-12-26 13:27:02.354 [bus notice] <aa
2017-12-26 13:27:02.358 [bus notice] <10
2017-12-26 13:27:02.366 [bus notice] <08
2017-12-26 13:27:02.371 [bus notice] <b5
2017-12-26 13:27:02.375 [bus notice] <04
2017-12-26 13:27:02.379 [bus notice] <01
2017-12-26 13:27:02.382 [bus notice] <00
2017-12-26 13:27:02.386 [bus notice] <3d
2017-12-26 13:27:02.391 [bus notice] <00
2017-12-26 13:27:02.405 [bus notice] <0a
2017-12-26 13:27:02.409 [bus notice] <03
2017-12-26 13:27:02.414 [bus notice] <03
2017-12-26 13:27:02.418 [bus notice] <27
2017-12-26 13:27:02.422 [bus notice] <13
2017-12-26 13:27:02.426 [bus notice] <26
2017-12-26 13:27:02.431 [bus notice] <12
2017-12-26 13:27:02.435 [bus notice] <02
2017-12-26 13:27:02.438 [bus notice] <17
2017-12-26 13:27:02.442 [bus notice] <30
2017-12-26 13:27:02.446 [bus notice] <08
2017-12-26 13:27:02.451 [bus notice] <e8
2017-12-26 13:27:02.455 [bus notice] <00
2017-12-26 13:27:02.459 [bus notice] <aa
2017-12-26 13:27:02.504 [bus notice] <aa
2017-12-26 13:27:02.549 [bus notice] <aa
2017-12-26 13:27:02.592 [bus notice] <aa
2017-12-26 13:27:02.637 [bus notice] <aa
2017-12-26 13:27:02.641 [bus notice] <10
2017-12-26 13:27:02.650 [bus notice] <fe
2017-12-26 13:27:02.654 [bus notice] <b5
2017-12-26 13:27:02.658 [bus notice] <05
2017-12-26 13:27:02.662 [bus notice] <02
2017-12-26 13:27:02.667 [bus notice] <04
2017-12-26 13:27:02.671 [bus notice] <00
2017-12-26 13:27:02.675 [bus notice] <0b
2017-12-26 13:27:02.679 [bus notice] <aa
2017-12-26 13:27:02.723 [bus notice] <aa
2017-12-26 13:27:02.768 [bus notice] <aa
2017-12-26 13:27:02.813 [bus notice] <aa
2017-12-26 13:27:02.858 [bus notice] <aa
2017-12-26 13:27:02.902 [bus notice] <aa
2017-12-26 13:27:02.946 [bus notice] <aa
2017-12-26 13:27:02.990 [bus notice] <aa
2017-12-26 13:27:03.035 [bus notice] <aa
2017-12-26 13:27:03.080 [bus notice] <aa
2017-12-26 13:27:03.124 [bus notice] <aa
2017-12-26 13:27:03.128 [bus notice] <10
2017-12-26 13:27:03.137 [bus notice] <50
2017-12-26 13:27:03.141 [bus notice] <b5
2017-12-26 13:27:03.145 [bus notice] <04
2017-12-26 13:27:03.149 [bus notice] <01
2017-12-26 13:27:03.154 [bus notice] <26
2017-12-26 13:27:03.158 [bus notice] <d9
2017-12-26 13:27:03.162 [bus notice] <00
2017-12-26 13:27:03.168 [bus notice] <07
2017-12-26 13:27:03.172 [bus notice] <02
2017-12-26 13:27:03.176 [bus notice] <02
2017-12-26 13:27:03.180 [bus notice] <00
2017-12-26 13:27:03.186 [bus notice] <2a
2017-12-26 13:27:03.190 [bus notice] <01
2017-12-26 13:27:03.194 [bus notice] <85
2017-12-26 13:27:03.198 [bus notice] <01
2017-12-26 13:27:03.204 [bus notice] <f7
2017-12-26 13:27:03.208 [bus notice] <00
2017-12-26 13:27:03.212 [bus notice] <aa
2017-12-26 13:27:03.256 [bus notice] <aa
2017-12-26 13:27:03.301 [bus notice] <aa
2017-12-26 13:27:03.345 [bus notice] <aa
2017-12-26 13:27:03.389 [bus notice] <aa
2017-12-26 13:27:03.432 [bus notice] <aa
2017-12-26 13:27:03.481 [bus notice] <aa
2017-12-26 13:27:03.525 [bus notice] <aa
2017-12-26 13:27:03.569 [bus notice] <aa
2017-12-26 13:27:03.615 [bus notice] <aa
2017-12-26 13:27:03.658 [bus notice] <aa
2017-12-26 13:27:03.702 [bus notice] <aa
2017-12-26 13:27:03.747 [bus notice] <aa
2017-12-26 13:27:03.790 [bus notice] <aa
2017-12-26 13:27:03.835 [bus notice] <aa
2017-12-26 13:27:03.878 [bus notice] <aa
2017-12-26 13:27:03.922 [bus notice] <aa
2017-12-26 13:27:03.968 [bus notice] <aa
2017-12-26 13:27:04.012 [bus notice] <aa
2017-12-26 13:27:04.057 [bus notice] <aa
2017-12-26 13:27:04.101 [bus notice] <aa
2017-12-26 13:27:04.145 [bus notice] <aa
2017-12-26 13:27:04.191 [bus notice] <aa
2017-12-26 13:27:04.236 [bus notice] <aa
2017-12-26 13:27:04.279 [bus notice] <aa
2017-12-26 13:27:04.324 [bus notice] <aa
2017-12-26 13:27:04.367 [bus notice] <aa
2017-12-26 13:27:04.372 [bus notice] <10
2017-12-26 13:27:04.380 [bus notice] <50
2017-12-26 13:27:04.384 [bus notice] <b5
2017-12-26 13:27:04.389 [bus notice] <04
2017-12-26 13:27:04.393 [bus notice] <01
2017-12-26 13:27:04.397 [bus notice] <18
2017-12-26 13:27:04.402 [bus notice] <e7
2017-12-26 13:27:04.406 [bus notice] <00
2017-12-26 13:27:04.410 [bus notice] <06
2017-12-26 13:27:04.414 [bus notice] <1a
2017-12-26 13:27:04.420 [bus notice] <1a
2017-12-26 13:27:04.424 [bus notice] <00
2017-12-26 13:27:04.429 [bus notice] <a3
2017-12-26 13:27:04.433 [bus notice] <01
2017-12-26 13:27:04.437 [bus notice] <15
2017-12-26 13:27:04.443 [bus notice] <2b
2017-12-26 13:27:04.446 [bus notice] <00
2017-12-26 13:27:04.450 [bus notice] <aa
2017-12-26 13:27:04.497 [bus notice] <aa
2017-12-26 13:27:04.542 [bus notice] <aa
2017-12-26 13:27:04.586 [bus notice] <aa
2017-12-26 13:27:04.630 [bus notice] <aa
2017-12-26 13:27:04.673 [bus notice] <aa
2017-12-26 13:27:04.717 [bus notice] <aa
2017-12-26 13:27:04.762 [bus notice] <aa
2017-12-26 13:27:04.806 [bus notice] <aa
2017-12-26 13:27:04.853 [bus notice] <aa
2017-12-26 13:27:04.897 [bus notice] <aa
2017-12-26 13:27:04.942 [bus notice] <aa
2017-12-26 13:27:04.987 [bus notice] <aa
2017-12-26 13:27:05.031 [bus notice] <aa
2017-12-26 13:27:05.075 [bus notice] <aa
2017-12-26 13:27:05.120 [bus notice] <aa
2017-12-26 13:27:05.164 [bus notice] <aa
2017-12-26 13:27:05.207 [bus notice] <aa
2017-12-26 13:27:05.251 [bus notice] <aa
2017-12-26 13:27:05.295 [bus notice] <aa
2017-12-26 13:27:05.340 [bus notice] <aa
2017-12-26 13:27:05.385 [bus notice] <aa
2017-12-26 13:27:05.430 [bus notice] <aa
2017-12-26 13:27:05.474 [bus notice] <aa
2017-12-26 13:27:05.519 [bus notice] <aa
2017-12-26 13:27:05.563 [bus notice] <aa
2017-12-26 13:27:05.607 [bus notice] <aa
2017-12-26 13:27:05.653 [bus notice] <aa
2017-12-26 13:27:05.697 [bus notice] <aa
2017-12-26 13:27:05.740 [bus notice] <aa
2017-12-26 13:27:05.785 [bus notice] <aa
2017-12-26 13:27:05.829 [bus notice] <aa
2017-12-26 13:27:05.873 [bus notice] <aa
2017-12-26 13:27:05.918 [bus notice] <aa
2017-12-26 13:27:05.963 [bus notice] <aa
2017-12-26 13:27:06.007 [bus notice] <aa
2017-12-26 13:27:06.051 [bus notice] <aa
2017-12-26 13:27:06.095 [bus notice] <aa
2017-12-26 13:27:06.140 [bus notice] <aa
2017-12-26 13:27:06.187 [bus notice] <aa
2017-12-26 13:27:06.231 [bus notice] <aa
2017-12-26 13:27:06.275 [bus notice] <aa
2017-12-26 13:27:06.320 [bus notice] <aa
2017-12-26 13:27:06.364 [bus notice] <aa
2017-12-26 13:27:06.368 [bus notice] <10
2017-12-26 13:27:06.377 [bus notice] <50
2017-12-26 13:27:06.381 [bus notice] <b5
2017-12-26 13:27:06.384 [bus notice] <03
2017-12-26 13:27:06.388 [bus notice] <02
2017-12-26 13:27:06.393 [bus notice] <00
2017-12-26 13:27:06.397 [bus notice] <03
2017-12-26 13:27:06.401 [bus notice] <43
2017-12-26 13:27:06.405 [bus notice] <00
2017-12-26 13:27:06.411 [bus notice] <0a
2017-12-26 13:27:06.415 [bus notice] <ff
2017-12-26 13:27:06.420 [bus notice] <ff
2017-12-26 13:27:06.424 [bus notice] <ff
2017-12-26 13:27:06.428 [bus notice] <ff
2017-12-26 13:27:06.434 [bus notice] <ff
2017-12-26 13:27:06.438 [bus notice] <ff
2017-12-26 13:27:06.442 [bus notice] <ff
2017-12-26 13:27:06.447 [bus notice] <ff
2017-12-26 13:27:06.451 [bus notice] <ff
2017-12-26 13:27:06.456 [bus notice] <ff
2017-12-26 13:27:06.461 [bus notice] <0f
2017-12-26 13:27:06.465 [bus notice] <00
2017-12-26 13:27:06.469 [bus notice] <aa
2017-12-26 13:27:06.514 [bus notice] <aa
2017-12-26 13:27:06.559 [bus notice] <aa
2017-12-26 13:27:06.603 [bus notice] <aa
2017-12-26 13:27:06.647 [bus notice] <aa
2017-12-26 13:27:06.651 [bus notice] <10
2017-12-26 13:27:06.660 [bus notice] <50
2017-12-26 13:27:06.664 [bus notice] <b5
2017-12-26 13:27:06.668 [bus notice] <09
2017-12-26 13:27:06.673 [bus notice] <04
2017-12-26 13:27:06.677 [bus notice] <0e
2017-12-26 13:27:06.681 [bus notice] <01
2017-12-26 13:27:06.685 [bus notice] <00
2017-12-26 13:27:06.690 [bus notice] <01
2017-12-26 13:27:06.694 [bus notice] <55
2017-12-26 13:27:06.698 [bus notice] <00
2017-12-26 13:27:06.702 [bus notice] <00
2017-12-26 13:27:06.707 [bus notice] <00
2017-12-26 13:27:06.711 [bus notice] <00
2017-12-26 13:27:06.715 [bus notice] <aa
2017-12-26 13:27:06.759 [bus notice] <aa
2017-12-26 13:27:06.804 [bus notice] <aa
2017-12-26 13:27:06.847 [bus notice] <aa
2017-12-26 13:27:06.895 [bus notice] <aa
2017-12-26 13:27:06.899 [bus notice] <10
2017-12-26 13:27:06.907 [bus notice] <50
2017-12-26 13:27:06.911 [bus notice] <b5
2017-12-26 13:27:06.915 [bus notice] <09
2017-12-26 13:27:06.919 [bus notice] <04
2017-12-26 13:27:06.924 [bus notice] <0e
2017-12-26 13:27:06.928 [bus notice] <20
2017-12-26 13:27:06.932 [bus notice] <00
2017-12-26 13:27:06.936 [bus notice] <01
2017-12-26 13:27:06.941 [bus notice] <2e
2017-12-26 13:27:06.945 [bus notice] <00
2017-12-26 13:27:06.949 [bus notice] <00
2017-12-26 13:27:06.954 [bus notice] <00
2017-12-26 13:27:06.958 [bus notice] <00
2017-12-26 13:27:06.962 [bus notice] <aa
2017-12-26 13:27:07.008 [bus notice] <aa
2017-12-26 13:27:07.051 [bus notice] <aa
2017-12-26 13:27:07.095 [bus notice] <aa
2017-12-26 13:27:07.140 [bus notice] <aa
2017-12-26 13:27:07.144 [bus notice] <10
2017-12-26 13:27:07.151 [bus notice] <08
2017-12-26 13:27:07.156 [bus notice] <b5
2017-12-26 13:27:07.160 [bus notice] <10
2017-12-26 13:27:07.164 [bus notice] <09
2017-12-26 13:27:07.168 [bus notice] <00
2017-12-26 13:27:07.173 [bus notice] <00
2017-12-26 13:27:07.177 [bus notice] <56
2017-12-26 13:27:07.181 [bus notice] <74
2017-12-26 13:27:07.185 [bus notice] <ff
2017-12-26 13:27:07.190 [bus notice] <ff
2017-12-26 13:27:07.194 [bus notice] <04
2017-12-26 13:27:07.198 [bus notice] <ff
2017-12-26 13:27:07.202 [bus notice] <00
2017-12-26 13:27:07.207 [bus notice] <ae
2017-12-26 13:27:07.209 [bus notice] <00
2017-12-26 13:27:07.226 [bus notice] <01
2017-12-26 13:27:07.231 [bus notice] <01
2017-12-26 13:27:07.233 [bus notice] <9a
2017-12-26 13:27:07.238 [bus notice] <00
2017-12-26 13:27:07.242 [bus notice] <aa
2017-12-26 13:27:07.288 [bus notice] <aa
2017-12-26 13:27:07.332 [bus notice] <aa
2017-12-26 13:27:07.376 [bus notice] <aa
2017-12-26 13:27:07.422 [bus notice] <aa
2017-12-26 13:27:07.426 [bus notice] <10
2017-12-26 13:27:07.434 [bus notice] <50
2017-12-26 13:27:07.437 [bus notice] <b5
2017-12-26 13:27:07.442 [bus notice] <05
2017-12-26 13:27:07.446 [bus notice] <02
2017-12-26 13:27:07.450 [bus notice] <18
2017-12-26 13:27:07.454 [bus notice] <00
2017-12-26 13:27:07.459 [bus notice] <34
2017-12-26 13:27:07.463 [bus notice] <00
2017-12-26 13:27:07.467 [bus notice] <00
2017-12-26 13:27:07.473 [bus notice] <00
2017-12-26 13:27:07.477 [bus notice] <00
2017-12-26 13:27:07.481 [bus notice] <aa
2017-12-26 13:27:07.526 [bus notice] <aa
2017-12-26 13:27:07.572 [bus notice] <aa
2017-12-26 13:27:07.617 [bus notice] <aa
2017-12-26 13:27:07.661 [bus notice] <aa
2017-12-26 13:27:07.706 [bus notice] <aa
2017-12-26 13:27:07.751 [bus notice] <aa
2017-12-26 13:27:07.794 [bus notice] <aa
2017-12-26 13:27:07.839 [bus notice] <aa
2017-12-26 13:27:07.884 [bus notice] <aa
2017-12-26 13:27:07.928 [bus notice] <aa
2017-12-26 13:27:07.972 [bus notice] <aa
2017-12-26 13:27:08.016 [bus notice] <aa
2017-12-26 13:27:08.061 [bus notice] <aa
2017-12-26 13:27:08.105 [bus notice] <aa
2017-12-26 13:27:08.148 [bus notice] <aa
2017-12-26 13:27:08.193 [bus notice] <aa
2017-12-26 13:27:08.240 [bus notice] <aa
2017-12-26 13:27:08.284 [bus notice] <aa
2017-12-26 13:27:08.329 [bus notice] <aa
2017-12-26 13:27:08.374 [bus notice] <aa
2017-12-26 13:27:08.420 [bus notice] <aa
2017-12-26 13:27:08.424 [bus notice] <10
2017-12-26 13:27:08.431 [bus notice] <50
2017-12-26 13:27:08.436 [bus notice] <b5
2017-12-26 13:27:08.440 [bus notice] <05
2017-12-26 13:27:08.444 [bus notice] <02
2017-12-26 13:27:08.448 [bus notice] <30
2017-12-26 13:27:08.453 [bus notice] <01
2017-12-26 13:27:08.457 [bus notice] <48
2017-12-26 13:27:08.461 [bus notice] <00
2017-12-26 13:27:08.466 [bus notice] <01
2017-12-26 13:27:08.470 [bus notice] <01
2017-12-26 13:27:08.476 [bus notice] <9a
2017-12-26 13:27:08.479 [bus notice] <00
2017-12-26 13:27:08.483 [bus notice] <aa
2017-12-26 13:27:08.527 [bus notice] <aa
2017-12-26 13:27:08.571 [bus notice] <aa
2017-12-26 13:27:08.616 [bus notice] <aa
2017-12-26 13:27:08.661 [bus notice] <aa
2017-12-26 13:27:08.706 [bus notice] <aa
2017-12-26 13:27:08.750 [bus notice] <aa
2017-12-26 13:27:08.794 [bus notice] <aa
2017-12-26 13:27:08.838 [bus notice] <aa
2017-12-26 13:27:08.882 [bus notice] <aa
2017-12-26 13:27:08.929 [bus notice] <aa
2017-12-26 13:27:08.974 [bus notice] <aa
2017-12-26 13:27:09.017 [bus notice] <aa
2017-12-26 13:27:09.061 [bus notice] <aa
2017-12-26 13:27:09.105 [bus notice] <aa
2017-12-26 13:27:09.149 [bus notice] <aa
2017-12-26 13:27:09.193 [bus notice] <aa
2017-12-26 13:27:09.237 [bus notice] <aa
2017-12-26 13:27:09.282 [bus notice] <aa
2017-12-26 13:27:09.327 [bus notice] <aa
2017-12-26 13:27:09.371 [bus notice] <aa
2017-12-26 13:27:09.416 [bus notice] <aa
2017-12-26 13:27:09.460 [bus notice] <aa
2017-12-26 13:27:09.504 [bus notice] <aa
2017-12-26 13:27:09.547 [bus notice] <aa
2017-12-26 13:27:09.594 [bus notice] <aa
2017-12-26 13:27:09.640 [bus notice] <aa
2017-12-26 13:27:09.684 [bus notice] <aa
2017-12-26 13:27:09.730 [bus notice] <aa
2017-12-26 13:27:09.774 [bus notice] <aa
2017-12-26 13:27:09.817 [bus notice] <aa
2017-12-26 13:27:09.862 [bus notice] <aa
2017-12-26 13:27:09.905 [bus notice] <aa
2017-12-26 13:27:09.949 [bus notice] <aa
2017-12-26 13:27:09.994 [bus notice] <aa
2017-12-26 13:27:10.038 [bus notice] <aa
2017-12-26 13:27:10.082 [bus notice] <aa
2017-12-26 13:27:10.128 [bus notice] <aa
2017-12-26 13:27:10.171 [bus notice] <aa
2017-12-26 13:27:10.215 [bus notice] <aa
2017-12-26 13:27:10.261 [bus notice] <aa
2017-12-26 13:27:10.307 [bus notice] <aa
2017-12-26 13:27:10.351 [bus notice] <aa
2017-12-26 13:27:10.395 [bus notice] <aa
2017-12-26 13:27:10.399 [bus notice] <10
2017-12-26 13:27:10.408 [bus notice] <50
2017-12-26 13:27:10.411 [bus notice] <b5
2017-12-26 13:27:10.415 [bus notice] <03
2017-12-26 13:27:10.419 [bus notice] <02
2017-12-26 13:27:10.424 [bus notice] <00
2017-12-26 13:27:10.428 [bus notice] <01
2017-12-26 13:27:10.432 [bus notice] <41
2017-12-26 13:27:10.436 [bus notice] <00
2017-12-26 13:27:10.441 [bus notice] <0a
2017-12-26 13:27:10.446 [bus notice] <ff
2017-12-26 13:27:10.450 [bus notice] <ff
2017-12-26 13:27:10.455 [bus notice] <ff
2017-12-26 13:27:10.460 [bus notice] <ff
2017-12-26 13:27:10.464 [bus notice] <ff
2017-12-26 13:27:10.469 [bus notice] <ff
2017-12-26 13:27:10.473 [bus notice] <ff
2017-12-26 13:27:10.478 [bus notice] <ff
2017-12-26 13:27:10.483 [bus notice] <ff
2017-12-26 13:27:10.487 [bus notice] <ff
2017-12-26 13:27:10.491 [bus notice] <0f
2017-12-26 13:27:10.495 [bus notice] <00
2017-12-26 13:27:10.501 [bus notice] <aa
2017-12-26 13:27:10.546 [bus notice] <aa
2017-12-26 13:27:10.589 [bus notice] <aa
2017-12-26 13:27:10.633 [bus notice] <aa
2017-12-26 13:27:10.677 [bus notice] <aa
2017-12-26 13:27:10.682 [bus notice] <10
2017-12-26 13:27:10.690 [bus notice] <08
2017-12-26 13:27:10.693 [bus notice] <b5
2017-12-26 13:27:10.697 [bus notice] <11
2017-12-26 13:27:10.702 [bus notice] <01
2017-12-26 13:27:10.706 [bus notice] <01
2017-12-26 13:27:10.710 [bus notice] <89
2017-12-26 13:27:10.715 [bus notice] <00
2017-12-26 13:27:10.732 [bus notice] <09
2017-12-26 13:27:10.735 [bus notice] <4e
2017-12-26 13:27:10.739 [bus notice] <ff
2017-12-26 13:27:10.743 [bus notice] <30
2017-12-26 13:27:10.747 [bus notice] <08
2017-12-26 13:27:10.752 [bus notice] <00
2017-12-26 13:27:10.756 [bus notice] <58
2017-12-26 13:27:10.760 [bus notice] <01
2017-12-26 13:27:10.765 [bus notice] <00
2017-12-26 13:27:10.769 [bus notice] <ff
2017-12-26 13:27:10.773 [bus notice] <f1
2017-12-26 13:27:10.777 [bus notice] <00
2017-12-26 13:27:10.782 [bus notice] <aa
2017-12-26 13:27:10.826 [bus notice] <aa
2017-12-26 13:27:10.870 [bus notice] <aa
2017-12-26 13:27:10.915 [bus notice] <aa
2017-12-26 13:27:10.959 [bus notice] <aa
2017-12-26 13:27:11.005 [bus notice] <aa
2017-12-26 13:27:11.050 [bus notice] <aa
2017-12-26 13:27:11.094 [bus notice] <aa
2017-12-26 13:27:11.138 [bus notice] <aa
2017-12-26 13:27:11.181 [bus notice] <aa
2017-12-26 13:27:11.225 [bus notice] <aa
2017-12-26 13:27:11.270 [bus notice] <aa
2017-12-26 13:27:11.315 [bus notice] <aa
2017-12-26 13:27:11.361 [bus notice] <aa
2017-12-26 13:27:11.404 [bus notice] <aa
2017-12-26 13:27:11.448 [bus notice] <aa
2017-12-26 13:27:11.492 [bus notice] <aa
2017-12-26 13:27:11.537 [bus notice] <aa
2017-12-26 13:27:11.580 [bus notice] <aa
2017-12-26 13:27:11.628 [bus notice] <aa
2017-12-26 13:27:11.670 [bus notice] <aa
2017-12-26 13:27:11.715 [bus notice] <aa
2017-12-26 13:27:11.761 [bus notice] <aa
2017-12-26 13:27:11.803 [bus notice] <aa
2017-12-26 13:27:11.848 [bus notice] <aa
2017-12-26 13:27:11.892 [bus notice] <aa
2017-12-26 13:27:11.938 [bus notice] <aa
2017-12-26 13:27:11.982 [bus notice] <aa
2017-12-26 13:27:12.026 [bus notice] <aa
2017-12-26 13:27:12.070 [bus notice] <aa
2017-12-26 13:27:12.114 [bus notice] <aa
2017-12-26 13:27:12.158 [bus notice] <aa
2017-12-26 13:27:12.202 [bus notice] <aa
2017-12-26 13:27:12.245 [bus notice] <aa
2017-12-26 13:27:12.291 [bus notice] <aa
2017-12-26 13:27:12.338 [bus notice] <aa
2017-12-26 13:27:12.384 [bus notice] <aa
2017-12-26 13:27:12.428 [bus notice] <aa
2017-12-26 13:27:12.433 [bus notice] <10
2017-12-26 13:27:12.441 [bus notice] <50
2017-12-26 13:27:12.445 [bus notice] <b5
2017-12-26 13:27:12.450 [bus notice] <05
2017-12-26 13:27:12.454 [bus notice] <05
2017-12-26 13:27:12.457 [bus notice] <3c
2017-12-26 13:27:12.461 [bus notice] <85
2017-12-26 13:27:12.466 [bus notice] <01
2017-12-26 13:27:12.470 [bus notice] <85
2017-12-26 13:27:12.474 [bus notice] <01
2017-12-26 13:27:12.478 [bus notice] <09
2017-12-26 13:27:12.483 [bus notice] <00
2017-12-26 13:27:12.487 [bus notice] <00
2017-12-26 13:27:12.493 [bus notice] <00
2017-12-26 13:27:12.497 [bus notice] <00
2017-12-26 13:27:12.501 [bus notice] <aa
2017-12-26 13:27:12.546 [bus notice] <aa
2017-12-26 13:27:12.589 [bus notice] <aa
2017-12-26 13:27:12.633 [bus notice] <aa
2017-12-26 13:27:12.677 [bus notice] <aa
2017-12-26 13:27:12.722 [bus notice] <aa
2017-12-26 13:27:12.766 [bus notice] <aa
2017-12-26 13:27:12.809 [bus notice] <aa
2017-12-26 13:27:12.855 [bus notice] <aa
2017-12-26 13:27:12.899 [bus notice] <aa
2017-12-26 13:27:12.943 [bus notice] <aa
2017-12-26 13:27:12.989 [bus notice] <aa
2017-12-26 13:27:13.035 [bus notice] <aa
2017-12-26 13:27:13.079 [bus notice] <aa
2017-12-26 13:27:13.122 [bus notice] <aa
2017-12-26 13:27:13.166 [bus notice] <aa
2017-12-26 13:27:13.212 [bus notice] <aa
2017-12-26 13:27:13.256 [bus notice] <aa
2017-12-26 13:27:13.299 [bus notice] <aa
2017-12-26 13:27:13.344 [bus notice] <aa
2017-12-26 13:27:13.388 [bus notice] <aa
2017-12-26 13:27:13.433 [bus notice] <aa
2017-12-26 13:27:13.477 [bus notice] <aa
2017-12-26 13:27:13.521 [bus notice] <aa
2017-12-26 13:27:13.566 [bus notice] <aa
2017-12-26 13:27:13.609 [bus notice] <aa
2017-12-26 13:27:13.653 [bus notice] <aa
2017-12-26 13:27:13.699 [bus notice] <aa
2017-12-26 13:27:13.744 [bus notice] <aa
2017-12-26 13:27:13.788 [bus notice] <aa
2017-12-26 13:27:13.833 [bus notice] <aa
2017-12-26 13:27:13.877 [bus notice] <aa
2017-12-26 13:27:13.920 [bus notice] <aa
2017-12-26 13:27:13.966 [bus notice] <aa
2017-12-26 13:27:14.010 [bus notice] <aa
2017-12-26 13:27:14.054 [bus notice] <aa
2017-12-26 13:27:14.099 [bus notice] <aa
2017-12-26 13:27:14.143 [bus notice] <aa
2017-12-26 13:27:14.187 [bus notice] <aa
2017-12-26 13:27:14.231 [bus notice] <aa
2017-12-26 13:27:14.276 [bus notice] <aa
2017-12-26 13:27:14.322 [bus notice] <aa
2017-12-26 13:27:14.367 [bus notice] <aa
2017-12-26 13:27:14.412 [bus notice] <aa
2017-12-26 13:27:14.417 [bus notice] <10
2017-12-26 13:27:14.424 [bus notice] <50
2017-12-26 13:27:14.429 [bus notice] <b5
2017-12-26 13:27:14.433 [bus notice] <04
2017-12-26 13:27:14.437 [bus notice] <01
2017-12-26 13:27:14.442 [bus notice] <18
2017-12-26 13:27:14.446 [bus notice] <e7
2017-12-26 13:27:14.450 [bus notice] <00
2017-12-26 13:27:14.454 [bus notice] <06
2017-12-26 13:27:14.459 [bus notice] <1a
2017-12-26 13:27:14.464 [bus notice] <1a
2017-12-26 13:27:14.469 [bus notice] <00
2017-12-26 13:27:14.473 [bus notice] <a1
2017-12-26 13:27:14.477 [bus notice] <01
2017-12-26 13:27:14.482 [bus notice] <15
2017-12-26 13:27:14.487 [bus notice] <07
2017-12-26 13:27:14.491 [bus notice] <00
2017-12-26 13:27:14.496 [bus notice] <aa
2017-12-26 13:27:14.540 [bus notice] <aa
2017-12-26 13:27:14.583 [bus notice] <aa
2017-12-26 13:27:14.627 [bus notice] <aa
2017-12-26 13:27:14.673 [bus notice] <aa
2017-12-26 13:27:14.716 [bus notice] <aa
2017-12-26 13:27:14.761 [bus notice] <aa
2017-12-26 13:27:14.806 [bus notice] <aa
2017-12-26 13:27:14.850 [bus notice] <aa
2017-12-26 13:27:14.895 [bus notice] <aa
2017-12-26 13:27:14.938 [bus notice] <aa
2017-12-26 13:27:14.982 [bus notice] <aa
2017-12-26 13:27:15.026 [bus notice] <aa
2017-12-26 13:27:15.073 [bus notice] <aa
2017-12-26 13:27:15.116 [bus notice] <aa
2017-12-26 13:27:15.162 [bus notice] <aa
2017-12-26 13:27:15.206 [bus notice] <aa
2017-12-26 13:27:15.249 [bus notice] <aa
2017-12-26 13:27:15.293 [bus notice] <aa
2017-12-26 13:27:15.338 [bus notice] <aa
2017-12-26 13:27:15.384 [bus notice] <aa
2017-12-26 13:27:15.427 [bus notice] <aa
2017-12-26 13:27:15.471 [bus notice] <aa
2017-12-26 13:27:15.516 [bus notice] <aa
2017-12-26 13:27:15.560 [bus notice] <aa
2017-12-26 13:27:15.604 [bus notice] <aa
2017-12-26 13:27:15.648 [bus notice] <aa
2017-12-26 13:27:15.693 [bus notice] <aa
2017-12-26 13:27:15.740 [bus notice] <aa
2017-12-26 13:27:15.785 [bus notice] <aa
2017-12-26 13:27:15.831 [bus notice] <aa
2017-12-26 13:27:15.875 [bus notice] <aa
2017-12-26 13:27:15.920 [bus notice] <aa
2017-12-26 13:27:15.963 [bus notice] <aa
2017-12-26 13:27:16.007 [bus notice] <aa
2017-12-26 13:27:16.052 [bus notice] <aa
2017-12-26 13:27:16.096 [bus notice] <aa
2017-12-26 13:27:16.142 [bus notice] <aa
2017-12-26 13:27:16.186 [bus notice] <aa
2017-12-26 13:27:16.230 [bus notice] <aa
2017-12-26 13:27:16.273 [bus notice] <aa
2017-12-26 13:27:16.317 [bus notice]
Zitat von: hpt17 am 26 Dezember 2017, 13:54:04
pi@pi-ebus ~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2017-12-26 13:26:21.095 [bus notice] signal acquired
2017-12-26 13:26:22.293 [bus notice] new master 10, master count 2
2017-12-26 13:26:22.633 [bus notice] new master 03, master count 3
...
Bitte editiere Deinen Beitrag und lösche das Log raus, 1300 Zeilen sind einfach viel zu viel für einen Beitrag. Häng das doch nächstes Mal einfach als Datei an bitte.
Dein ebusd sendet anscheinend gar nichts. Insofern ist es schwierig, eine Aussage zu treffen. Bitte nochmal Log aufzeichen und dabei irgendetwas via ebusctl aktiv abfragen.
@hpt17
es ist schwierig aus dieser langen Liste was zu lesen, aber hier ist kein einziger Sendeversuch zu sehen. Hast du auch wirklich den ebusd dazu neu gestartet? Ansonsten "ebusctl scan full" eingeben! Ohne den Sendeversuch zu sehen kann man absolut nichts sagen. Du siehst ja dann selbst ob da wo ein > auftaucht, genau so ein Log brauchen wir.
Und bitte unbedingt Code Tags verwenden, sonst kann das keiner lesen!
Einfach im Editor das "#" drücken und schon wird der Tag in der Schreibzone eingefügt. Du fügst dann dein Log einfach zwischen die 2 eckigen Klammern ein, so wie im Bild "Beispiel Text".
LG
Danke - OK - mach ich.
Habe schon gesehen, dass es ein Bisschen viel ist ....
Habe auch mal von der Möglichkeit mittels "tail -f /var/log/ebusd.log " gelesen, hier dieser Log.
Ist der vielleicht auch aussagekräftiger ?
pi@pi-ebus ~ $ tail -f /var/log/ebusd.log
2017-12-26 13:35:39.664 [main notice] ebusd 2.0.0ea7efc started
2017-12-26 13:35:39.677 [main error] error reading config files: ERR: element not found, /etc/ebusd/430.csv:8
2017-12-26 13:35:39.677 [main notice] found messages: 1 (0 conditional on 0 conditions, 0 poll, 0 update)
2017-12-26 13:35:39.715 [bus notice] signal acquired
2017-12-26 13:35:39.795 [bus notice] new master 10, master count 2
2017-12-26 13:35:39.814 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:35:41.569 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:35:43.584 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:35:43.866 [bus notice] new master 03, master count 3
2017-12-26 13:35:43.866 [update notice] unknown MS cmd: 1008b5110101 / 094eff300800580000ff
2017-12-26 13:35:45.551 [update notice] unknown BC cmd: 10feb51603013008
2017-12-26 13:35:47.547 [update notice] unknown MS cmd: 1050b5040126 / 070202002a018501
2017-12-26 13:35:47.794 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:35:48.038 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:35:48.299 [update notice] unknown MS cmd: 1050b5040118 / 06000000a40115
2017-12-26 13:35:48.584 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:35:49.620 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:35:49.724 [bus error] send to 08: ERR: read timeout, retry
2017-12-26 13:35:49.767 [bus error] send to 08: ERR: read timeout, retry
2017-12-26 13:35:49.857 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:35:49.961 [bus error] send to 08: ERR: read timeout, retry
2017-12-26 13:35:50.003 [bus error] send to 08: ERR: read timeout
2017-12-26 13:35:50.004 [main error] scan config 08 message: ERR: read timeout
2017-12-26 13:35:51.608 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:35:52.026 [bus error] send to 15: ERR: read timeout, retry
2017-12-26 13:35:52.070 [bus error] send to 15: ERR: read timeout, retry
2017-12-26 13:35:52.114 [bus error] send to 15: ERR: read timeout, retry
2017-12-26 13:35:52.159 [bus error] send to 15: ERR: read timeout
2017-12-26 13:35:52.159 [main error] scan config 15 message: ERR: read timeout
2017-12-26 13:35:53.626 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:35:53.909 [update notice] unknown MS cmd: 1008b5110101 / 094eff300800580000ff
2017-12-26 13:35:54.189 [bus error] send to 50: ERR: read timeout, retry
2017-12-26 13:35:54.235 [bus error] send to 50: ERR: read timeout, retry
2017-12-26 13:35:54.279 [bus error] send to 50: ERR: read timeout, retry
2017-12-26 13:35:54.324 [bus error] send to 50: ERR: read timeout
2017-12-26 13:35:54.324 [main error] scan config 50 message: ERR: read timeout
2017-12-26 13:35:55.641 [update notice] unknown MS cmd: 1008b5110102 / 05033c8a5082
2017-12-26 13:35:57.662 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:35:57.906 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:35:58.152 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:35:58.413 [update notice] unknown MS cmd: 1050b5040118 / 06000000a40115
2017-12-26 13:35:58.697 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:35:58.935 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:35:59.667 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:36:01.688 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:36:01.969 [update notice] unknown MS cmd: 1008b5110101 / 094eff300800580000ff
2017-12-26 13:36:03.716 [update notice] unknown MS cmd: 1008b5040100 / 0a03043613261202173008
2017-12-26 13:36:03.935 [update notice] unknown BC cmd: 10feb505020400
2017-12-26 13:36:05.706 [update notice] unknown MS cmd: 1050b5040118 / 06000000a40115
2017-12-26 13:36:06.108 [update notice] unknown MS cmd: 1050b5040126 / 070202002a018501
2017-12-26 13:36:07.726 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:36:07.970 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:36:08.219 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:36:08.502 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:36:08.739 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:36:09.694 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:36:11.759 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:36:12.039 [update notice] unknown MS cmd: 1008b5110101 / 094eff300800580000ff
2017-12-26 13:36:13.716 [update notice] unknown MS cmd: 1050b505053c85018501 / 00
2017-12-26 13:36:15.711 [update notice] unknown MS cmd: 1050b5040118 / 06000000a40115
2017-12-26 13:36:17.770 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:36:18.014 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:36:18.259 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:36:18.537 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:36:18.774 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:36:19.725 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:36:21.790 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:36:22.071 [update notice] unknown MS cmd: 1008b5110101 / 094eff600800580000ff
2017-12-26 13:36:23.785 [update notice] unknown BC cmd: 10feb516080025361326120217
2017-12-26 13:36:24.035 [update notice] unknown MS cmd: 1008b512020064 / 00
2017-12-26 13:36:24.657 [update notice] unknown MS cmd: 1050b5040126 / 070202002a018501
2017-12-26 13:36:25.762 [update notice] unknown MS cmd: 1050b5040118 / 06000000a50115
2017-12-26 13:36:27.820 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:36:28.068 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:36:28.312 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:36:28.595 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:36:28.831 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:36:29.785 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:36:31.803 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:36:32.087 [update notice] unknown MS cmd: 1008b5110101 / 094cff300800580000ff
2017-12-26 13:36:33.833 [update notice] unknown MS cmd: 1008b5040100 / 0a03353613261202173008
2017-12-26 13:36:34.100 [update notice] unknown MS cmd: 1008b5110102 / 05033c8a5082
2017-12-26 13:36:35.831 [update notice] unknown MS cmd: 1050b5040118 / 06000000a50115
2017-12-26 13:36:37.851 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:36:38.099 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:36:38.344 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:36:38.625 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:36:38.864 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:36:39.819 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-26 13:36:41.882 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-26 13:36:42.165 [update notice] unknown MS cmd: 1008b5110101 / 094cff300800580000ff
2017-12-26 13:36:43.226 [update notice] unknown MS cmd: 1050b5040126 / 070202002a018501
2017-12-26 13:36:43.806 [update notice] unknown BC cmd: 10feb51603013008
2017-12-26 13:36:45.831 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-26 13:36:46.076 [update notice] unknown MS cmd: 1050b509040e200001 / 00
2017-12-26 13:36:46.340 [update notice] unknown MS cmd: 1050b5040118 / 06000000a50115
2017-12-26 13:36:46.624 [update notice] unknown MS cmd: 1008b5100900005674ffff04ff00 / 0101
2017-12-26 13:36:47.885 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-26 13:36:48.124 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-26 13:36:49.879 [update notice] unknown MS cmd: 1050b505023001 / 0101
ja, aber das war jetzt leider kein Raw Log.
Aber was man hier sieht
[main error] error reading config files: ERR: element not found, /etc/ebusd/430.csv:8
findet der ebusd keine Konfigfiles. Schau doch einmal in /etc/ebusd/ nach ob hier überhaupt Files liegen und die wenigstens Leserechte haben?
LG
Hallo,
habe soeben ein "scan full" gemacht!
pi@pi-ebus ~ $ sudo service ebusd status
[ ok ] ebusd is running.
pi@pi-ebus ~ $ ebusctl scan full
done
pi@pi-ebus ~ $ ebusctl scan result
empty
Was kann da die Ursache sein ?
LG HPT
ja passt, und jetzt das Log von diesem Scan.
LG
Ist das Ergebnis vom "scan full" nicht das "ebusctl scan result" ???
Wo finde ich sonst das log file ?
dort wo du die anderen Logs her hast (/var/log/ebusd.log) , nur wäre interessant was zu diesem Zeitpunkt um Log steht, am besten im RawLog.
LG
Das sind meine Files im Verzeichnis:
pi@pi-ebus /etc/ebusd $ ls -al
insgesamt 76
drwxr-xr-x 3 root root 4096 Dez 22 19:35 .
drwxr-xr-x 108 root root 4096 Dez 26 14:20 ..
-rw-r--r-- 1 root root 14311 Okt 24 2015 430.csv
-rw-r--r-- 1 root root 19038 Okt 24 2015 bai.csv
-rw-rw-r-- 1 pi pi 1202 Jun 5 2016 broadcast.csv
-rw-r--r-- 1 root root 2373 Okt 24 2015 common.csv
-rw-r--r-- 1 root root 1099 Okt 24 2015 error.csv
-rw-rw-r-- 1 pi pi 754 Jun 5 2016 memory.csv
-rw-rw-r-- 1 pi pi 1228 Jun 5 2016 _templates.csv
-rw-r--r-- 1 root root 5025 Okt 24 2015 v61.csv
drwxrwxr-x 2 pi pi 4096 Dez 22 19:35 vaillant
Bei mir finde ich unter :
pi@pi-ebus /var/log $ ls *.log
alternatives.log daemon.log fontconfig.log mail.log user.log
auth.log dpkg.log kern.log mysql.log Xorg.0.log
bootstrap.log ebusd.log lpr.log regen_ssh_keys.log
Übrigens - das "ebusd.log" ist sehr lang !!!!
so wie es bis jetzt aussieht, hast du irgend eine inkonsistenz bei der Installation.
Willst du nicht versuchen, eine 3.0 Version zu installieren? John hat ja fertige Pakete (https://github.com/john30/ebusd/releases/tag/v3.0) liegen, die brauchst du nicht zu kompilieren und hier hat sich doch sehr viel geändert.
Die Konfigfiles liegen dann hier (https://github.com/john30/ebusd-configuration/releases).
LG
Kann ich nicht z.B. zuerst noch versuchen, die Configuration auf dem ebusd2 neu aufzusetzen?
Was muß ich vorher löschen und was neu installieren ?
Leider bin ich kein Experte, und so trivial ist alles zusammen auch gerade nicht !
Ansonsten wird mir wohl nichts anderes übrig bleiben als Ebusd3 aufzusetzen!
Bedingt eingentlich die ebusd_3.0_am64.deb unbedingt eines DEBIAN ?
was mich interessieren würde, warum findet ebusd ein Device (unten auf adress 50) aber nicht mehr ?
pi@pi-ebus / $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 30
masters: 3
messages: 9
address 03: master #3
address 08: slave #3, scanned
address 10: master #6
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0415;HW=1902"
Habe nach einem Neustart jetzt im var/log/ebusd.log nach 100erten Zeilen herausgesucht die Situation nach dem Neustart von ebusd2.
Im Anhang ist eine Scan_.pdf wo zu Beginn ersichtlich ist:
2017-12-26 15:53:03.235 [main error] error reading config files: ERR: element not found, /etc/ebusd/430.csv:8
Zitat von: hpt17 am 26 Dezember 2017, 14:35:24
pi@pi-ebus /etc/ebusd $ ls -al
insgesamt 76
drwxr-xr-x 3 root root 4096 Dez 22 19:35 .
drwxr-xr-x 108 root root 4096 Dez 26 14:20 ..
-rw-r--r-- 1 root root 14311 Okt 24 2015 430.csv
-rw-r--r-- 1 root root 19038 Okt 24 2015 bai.csv
-rw-rw-r-- 1 pi pi 1202 Jun 5 2016 broadcast.csv
-rw-r--r-- 1 root root 2373 Okt 24 2015 common.csv
-rw-r--r-- 1 root root 1099 Okt 24 2015 error.csv
-rw-rw-r-- 1 pi pi 754 Jun 5 2016 memory.csv
-rw-rw-r-- 1 pi pi 1228 Jun 5 2016 _templates.csv
-rw-r--r-- 1 root root 5025 Okt 24 2015 v61.csv
drwxrwxr-x 2 pi pi 4096 Dez 22 19:35 vaillant
die bai, 430 und v61 haben in diesem Verzeichnis eigentlich nichts zu suchen. Die gehören in das vaillant Unterverzeichnis.
Zitat von: hpt17 am 26 Dezember 2017, 15:05:15
Kann ich nicht z.B. zuerst noch versuchen, die Configuration auf dem ebusd2 neu aufzusetzen?
Was muß ich vorher löschen und was neu installieren ?
Leider bin ich kein Experte, und so trivial ist alles zusammen auch gerade nicht !
Ansonsten wird mir wohl nichts anderes übrig bleiben als Ebusd3 aufzusetzen!
Bedingt eingentlich die ebusd_3.0_am64.deb unbedingt eines DEBIAN ?
auch die 2.0 Versionen liegen auf diesem Link (https://github.com/john30/ebusd-configuration/releases). Besser aber vorher alles unter etc/ebusd löschen ( sudo rm -r /etc/ebusd ) und dann erst wieder installieren ( sudo dpkg -i --force-overwrite ebusd-configuration-2.0.*.deb" )
ich weiß jetzt nicht wo du den ebusd laufen hast, ist das ein PC weil du am64 gewählt hast?
Es sieht so aus. als hättest du vom Verz. Vaillant die 3 Files verschoben oder herauskopiert, weil auch der User root ist.
LG
Hallo John30 ! Müsste das Verzeichnis "Vaillant" mit diesen csv's ausreichen? Hier ist auch z.B. eine bai.csv jedoch mit einer vorangestellten Nr.08.bai.csv und für 430.csv eine 15.430.csv.......
Meine Eintragungen in vaillant :
pi@pi-ebus /etc/ebusd/vaillant $ ls
05.vd2.csv 15.f47.csv 50.v61.mc.csv broadcast.csv
05.vd3.csv 15.heb.csv 50.vr630.mc.csv currentservice.inc
05.vd4.csv 15.hep.csv 51.vr630.mc.3.csv e0.omu.csv
05.vd6.csv 15.sdr_p.csv 52.mc2.mc.4.csv ec.sol.sc.csv
05.vl8.csv 15.ui.csv 53.mc2.mc.5.csv ec.solsy.sc.csv
05.vl9.csv 15.uih.csv 75.rcc.csv ed.pms.sc.csv
06.pms.csv 1c.rcc.4.csv 75.v81.csv errors.inc
08.bai.csv 1c.v81.4.csv a0.sol.hwc.csv hcmode.inc
08.ehp.csv 23.ehp.cc.csv a1.sol.cc.csv hwcmode.inc
0a.pmw.hwc.csv 23.solsy.cc.csv bai.0010002315.inc mcmode.inc
15.140.csv 23.vr630.cc.csv bai.0010002465.inc quick.inc
15.350.csv 25.ehp.hwc.csv bai.0010003857.inc roomtempoffset.inc
15.360.csv 25.solsy.hwc.csv bai.0010003886.inc scan.csv
15.36p.csv 25.vr630.hwc.csv bai.0010004121.inc _templates.csv
15.370.csv 26.solsy.hc.csv bai.0010004150.inc tempsetpoints.inc
15.392.csv 26.vr630.hc.csv bai.0010005400.inc timercc.inc
15.400.csv 35.rcc.1.csv bai.0010006101.inc timercool.inc
15.430.csv 35.v81.1.csv bai.0010006341.inc timerhc.inc
15.470.csv 3c.rcc.5.csv bai.0010007508.inc timerhwc.inc
15.e7f.csv 3c.v81.5.csv bai.0010010674.inc timer.inc
15.f37.csv 50.ehp.mc.csv bai.0020066007.inc
15.f43.csv 50.solsy.mc.csv bai.308523.inc
Und die 430.csv, v61.csv, bai.csv im Verzeichnis /etc/ebusd kann ich löschen?
Soll man auch die nicht benötigten csv's aus Vaillant-Verzeichnis löschen? Macht das Sinn?
Und sollte ebusd nach jedem Neustart die csv dateien automatisch erkennen, oder muß ein checkconfig oder scancofig manuell gestartet werden?
Vielen Dank - lG HPT
Hallo
Nach intensiven probieren habe ich mich entschlossen die ebusd V3.1 zu installieren!
Zuerst:
pi@pi-ebus / $ sudo wget https://github.com/john30/ebusd/releases/download/v3.1/ebusd-3.1_armhf-jessie.deb
pi@pi-ebus / $ sudo dpkg -i --force-overwrite ebusd-3.1_armhf-jessie.deb
(Lese Datenbank ... 77261 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von ebusd 3.1 (durch ebusd-3.1_armhf-jessie.deb) ...
Ersatz für ebusd wird entpackt ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von ebusd:
ebusd hängt ab von libstdc++6 (>= 4.8.1); aber:
Version von libstdc++6:armhf auf dem System ist 4.7.2-5+rpi1.
dpkg: Fehler beim Bearbeiten von ebusd (--install):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
ebusd
Deswegen habe ich danach wie in "https://github.com/john30/ebusd/wiki/1.-Build-and-install" angegeben --> Install required packages on Debian
dpkg install git autoconf automake g++ make
pi@pi-ebus / $ dpkg install git autoconf automake g++ make
dpkg: Fehler: eine Aktions-Option wird benötigt
Das ergab die Meldung "eine Aktions-Option wird benötigt!
Jetzt bin ich am Ende meines Latein !!!!
Wie kann ich diese fehlenden Dateien für libstdc++6 installieren???
Gute Nacht!
versuche mal den Befehlen allen "sudo" voran zu stellen.
also so:
sudo dpkg install git autoconf automake g++ make
LG
pi@pi-ebus ~ $ sudo dpkg install git autoconf automake g++ make
dpkg: Fehler: eine Aktions-Option wird benötigt
sudo apt-get install git autoconf automake g++ make?
Und zwischendurch auch gerne mal ein apt-get update und apt-get upgrade ...
Gruß Andreas
Zitat von: hpt17 am 26 Dezember 2017, 21:13:22
pi@pi-ebus ~ $ sudo dpkg install git autoconf automake g++ make
dpkg: Fehler: eine Aktions-Option wird benötigt
das hängt noch von der Betriebssystem Version ab. Was hast Du denn auf dem RPi installiert? Wenn das Deine "alte Mühle" ist, dann doch bestimmt kein jessie oder?
Werte Experten. Das klingt ja nicht gerade ermunternd "alte Mühle" - oder meinst du gar mich ?
Mein Gerät ist ein: Raspberry Pi 2 Model B Rev 1.1^@
Installiert ist : PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
Getestet habe ich prakisch alles, und nach mehrmaligen Aufsetzen und Probieren bin ich jetzt soweit, dass "ebusd 3.1.v3.0-35-gb0e20b7" zu laufen scheint!
Zur Configuration habe ich downgeladen und installiert :
pi@pi-ebus / $ EBUSDCFGPACKAGE=ebusd-configuration-2.1.b143f39-de_all.deb
pi@pi-ebus / $ wget https://github.com/john30/ebusd-configuration/releases/download/v2.1.1/$EBUSDCFGPACKAGE
Gleich nach einem Neustart ergibt ein "ebusctl info":
pi@pi-ebus ~ $ ebusctl info
version: ebusd 3.1.v3.0-35-gb0e20b7
signal: acquired
symbol rate: 55
max symbol rate: 83
reconnects: 0
masters: 3
messages: 17
conditional: 0
poll: 0
update: 7
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave
und nach ca. 10 min Laufzeit:
pi@pi-ebus ~ $ ebusctl info
version: ebusd 3.1.v3.0-35-gb0e20b7
update check: version 3.0 available, broadcast.csv: different version available
signal: acquired
symbol rate: 38
max symbol rate: 89
reconnects: 0
masters: 3
messages: 17
conditional: 0
poll: 0
update: 7
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0415;HW=1902"
Das sind die ersten Eintragungen in ebusd.log nach dem Neustart:
2017-12-27 11:35:01.140 [main notice] ebusd 3.1.v3.0-35-gb0e20b7 started with auto scan
2017-12-27 11:35:01.165 [bus notice] bus started with own address 31/36
2017-12-27 11:35:01.184 [bus notice] signal acquired
2017-12-27 11:35:02.205 [bus notice] new master 10, master count 2
2017-12-27 11:35:02.268 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:02.549 [bus notice] new master 03, master count 3
2017-12-27 11:35:02.549 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:04.260 [update notice] unknown BC cmd: 10feb516080006351127120317
2017-12-27 11:35:04.511 [update notice] unknown MS cmd: 1008b512020064 / 00
2017-12-27 11:35:06.244 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:08.259 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:08.508 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:08.754 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:09.033 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:09.272 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:35:10.265 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:35:10.372 [main error] scan config 08: ERR: read timeout
2017-12-27 11:35:12.287 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:12.393 [main error] scan config 15: ERR: read timeout
2017-12-27 11:35:12.569 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:13.725 [update notice] unknown MS cmd: 1050b5040126 / 070202002a017501
2017-12-27 11:35:14.321 [update notice] unknown MS cmd: 1008b5040100 / 0a03163511271203174004
2017-12-27 11:35:14.425 [main error] scan config 50: ERR: read timeout
2017-12-27 11:35:14.587 [update notice] unknown MS cmd: 1008b5110102 / 05033c8a5082
2017-12-27 11:35:16.298 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:16.546 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:16.812 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:17.096 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:18.315 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:18.551 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:35:20.308 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:35:22.324 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:22.605 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:24.297 [update notice] unknown BC cmd: 10feb51603014004
2017-12-27 11:35:26.328 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:26.574 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:26.840 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:27.122 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:28.385 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:28.621 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:35:30.333 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:35:32.292 [update notice] unknown MS cmd: 1050b5040126 / 070202002a017501
2017-12-27 11:35:32.574 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:32.857 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:34.372 [update notice] unknown MS cmd: 1008b5110102 / 05033c8a5082
2017-12-27 11:35:36.356 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:36.600 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:36.866 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:37.150 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:38.411 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:38.649 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:35:40.360 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:35:42.423 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:42.702 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:42.423 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:42.702 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:44.410 [update notice] unknown MS cmd: 1008b5040100 / 0a03463511271203174004
2017-12-27 11:35:44.628 [update notice] unknown BC cmd: 10feb505020400
2017-12-27 11:35:46.391 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:46.639 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:46.903 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:47.185 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:48.444 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:48.681 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:35:50.433 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:35:50.877 [update notice] unknown MS cmd: 1050b5040126 / 070202002a017501
2017-12-27 11:35:52.453 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:35:52.735 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:35:54.453 [update notice] unknown MS cmd: 1050b505053c76017601 / 00
2017-12-27 11:35:56.436 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:35:56.683 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:35:56.949 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:35:57.231 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:35:58.491 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:35:58.728 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:36:00.523 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:36:00.806 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:36:01.047 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:36:02.493 [update notice] unknown BC cmd: 10feb516080004361127120317
2017-12-27 11:36:02.746 [update notice] unknown MS cmd: 1008b512020064 / 00
2017-12-27 11:36:04.524 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:36:06.542 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:36:06.787 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:36:07.035 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:36:07.317 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:36:07.556 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:36:08.507 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:36:09.481 [update notice] unknown MS cmd: 1050b5040126 / 070202002a017601
2017-12-27 11:36:10.568 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:36:10.849 [update notice] unknown MS cmd: 1008b5110101 / 0936ff800400520000ff
2017-12-27 11:36:12.556 [update notice] unknown MS cmd: 1008b5040100 / 0a03133611271203174004
2017-12-27 11:36:12.818 [update notice] unknown MS cmd: 1008b5110102 / 05033c8a5082
2017-12-27 11:36:14.555 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:36:16.574 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:36:16.818 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:36:17.065 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:36:17.345 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:36:17.581 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:36:18.539 [update notice] unknown MS cmd: 1050b505023001 / 0101
2017-12-27 11:36:20.602 [update notice] unknown MS cmd: 1050b503020001 / 0affffffffffffffffffff
2017-12-27 11:36:20.884 [update notice] unknown MS cmd: 1008b5110101 / 0936ff400400520000ff
2017-12-27 11:36:22.532 [update notice] unknown BC cmd: 10feb51603014004
2017-12-27 11:36:24.577 [update notice] unknown MS cmd: 1050b5040118 / 061c1c00aa0115
2017-12-27 11:36:26.598 [update notice] unknown MS cmd: 1050b503020003 / 0affffffffffffffffffff
2017-12-27 11:36:26.844 [update notice] unknown MS cmd: 1050b509040e010001 / 00
2017-12-27 11:36:27.089 [update notice] unknown MS cmd: 1050b509040e200000 / 00
2017-12-27 11:36:27.374 [update notice] unknown MS cmd: 1008b5100900003874ffff04ff00 / 0101
2017-12-27 11:36:27.611 [update notice] unknown MS cmd: 1050b505021800 / 00
2017-12-27 11:36:28.055 [update notice] unknown MS cmd: 1050b5040126 / 070202002a017601
Ich weiß nicht, was ich noch tun kann, oder soll ?! Bin ratlos .....
Bitte um Hilfe !!!!! (wenn möglich in Deutsch !)
DANKE !!!
Zitat von: hpt17 am 27 Dezember 2017, 15:25:02
Das klingt ja nicht gerade ermunternd "alte Mühle" - oder meinst du gar mich ?
Mein Gerät ist ein: Raspberry Pi 2 Model B Rev 1.1^@
Installiert ist : PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
Das meinte ich mit alte Mühle: "wheezy"
Diese Version von Ubuntu/Debian/Raspbian stammt aus 2013, hat also nächstes Jahr 5 Jahre auf dem Buckel. Irgendwann werde ich für Wheezy auch keine ebusd Releases mehr bauen und statt dessen Stretch unterstützen.
Zitat von: hpt17 am 27 Dezember 2017, 15:25:02
Getestet habe ich prakisch alles, und nach mehrmaligen Aufsetzen und Probieren bin ich jetzt soweit, dass "ebusd 3.1.v3.0-35-gb0e20b7" zu laufen scheint!
Tja, jetzt wäre halt spannend gewesen, was Du so alles probiert und aufgesetzt hast. Aber gut.
Zitat von: hpt17 am 27 Dezember 2017, 15:25:02
Gleich nach einem Neustart ergibt ein "ebusctl info":
...
Das sieht ja schon mal nicht ganz furchtbar aus. Das ist jetzt was für eine Version des Adapters?
Vielleicht hat der Schaden genommen während Deines Heizungs-Ausfalls.
Ist Deine Heizung jetzt vollständig wiederherstellt?
Hast Du eine neuere oder andere SW/HW Version bekommen?
Fragen über Fragen und viele Möglichkeiten, woran es liegen kann...
Zitat von: hpt17 am 27 Dezember 2017, 15:25:02
2017-12-27 11:35:10.372 [main error] scan config 08: ERR: read timeout
Das ist poblematisch. Du könntest jetzt mal versuchen, ebusd mit einem größeren Timeout zu starten. Dazu bspw. "--receivetimeout=50000" in der /etc/default/ebusd hinzufügen (in die Zeile mit "EBUSD_OPTS=" bspw. hinter das darin befindliche "--scanconfig" mit nem Leerzeichen dazwischen.
War das Deutsch genug? :)
Zitat
Das ist jetzt was für eine Version des Adapters?
Vielleicht hat der Schaden genommen während Deines Heizungs-Ausfalls.
Habe meinen alten Adapter mit Poti, umgebaut in die Version2 "ohne Poti" und auch schon den Usb-Adapter (FTDI232) getauscht. Leider keine Erfolg, deshalb habe ich auch einen original Bausatz bereits bestellt, um sicher die Hardware auszuschließen ! Warte auf die Lieferung. Außerdem hab ich mir einen original Vaillant-Adapter geliehen mit einer Software von Vaillant, um zu testen, ob es damit funktioniert. Ja - damit kann man mitlesen!
Zitat
Dazu bspw. "--receivetimeout=50000" in der /etc/default/ebusd hinzufügen (in die Zeile mit "EBUSD_OPTS=" bspw. hinter das darin befindliche "--scanconfig" mit nem Leerzeichen dazwischen.
Meinst du so :
EBUSD_OPTS="--scanconfig --receivetimeout=50000"
Es ist bei mir ja schon die Version ebusd1 und dann ebusd2 gelaufen! Es ist mir ein Rätsel!?
ja, aber auch den vorderen Teil eintragen.
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --lograwdata=Bytes --scanconfig --receivetimeout=50000"
und gleich mit der Variante das RawLog einzuschalten.
LG
was bedeuten diese Eintragungen und wozu sind sie notwendig ?
Startet ebusd dann mit diesen Parametern? Wo kann ich dann die Ergebnisse sehen? Muß ich für den Normalbetrieb auch wieder was rückgängig machen?
Jedenfalls das timeout=50000 allein scheint nichts zu verändern .....
Bedeutung der Parameter
ser. Device Port Logfile anlegen RAW Log aktivieren autom.scannen Timeout
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --lograwdata=Bytes --scanconfig --receivetimeout=50000"
entfernen musst du wenn alles klar ist nur diesen Eintrag:
--lograwdata=Bytes
LG
Habe den Rat von Reinhart umgesetzt und hier das Ergebnis im Anhang als pdf-Datei. Was kann man daraus ableiten oder schließen?
Erlaube mir noch ein paar quälende Fragen meinerseits aus Verständnisgründen:
1. Funktioniert das "Mit-Lesen" am e-bus auch ohne hardwaremäßig funktionierenden Adapter? Oder muß Schreiben auch zwingend funktionieren?
2. Wie kann man von Hand (manuell) die Konfiguration auf die Heizanlage einstellen? Genügt ein hineinkopieren von z.b. 430.csv in /etc/ebusd/vaillant ? Erkennt es ebusd automatisch (Neustart notwendig?)
3. Was sagt die Angabe nach dem "ebusctl info " z. B. "address 10: master #6 " und dann noch die Angabe "scanned" aus?
LG HPT
Habe den Rat von Reinhart umgesetzt und hier das Ergebnis im Anhang als pdf-Datei. Was kann man daraus ableiten oder schließen?
Erlaube mir noch ein paar quälende Fragen meinerseits aus Verständnisgründen:
1. Funktioniert das "Mit-Lesen" am e-bus auch ohne hardwaremäßig funktionierenden Adapter? Oder muß Schreiben auch zwingend funktionieren?
wenn schreiben nicht funktioniert, werden auch kein CSV geladen weil der Scan ja nicht abgesetzt werden kann.
2. Wie kann man von Hand (manuell) die Konfiguration auf die Heizanlage einstellen? Genügt ein hineinkopieren von z.b. 430.csv in /etc/ebusd/vaillant ? Erkennt es ebusd automatisch (Neustart notwendig?)
nein, erkennt er nicht automatisch, der Filename muss zumindest passen und der Scan muss funktionieren (senden generell). Neustart ist bei Änderungen in den CSV immer notwendig, zumindest neu laden.
3. Was sagt die Angabe nach dem "ebusctl info " z. B. "address 10: master #6 " und dann noch die Angabe "scanned" aus?
das sagt, das eine Masteradresse gefunden wurde, ist aber nicht unbedingt ein Ergebnis von scan. Und noch was, der Initialscan wird vom Dämon beim Start von selbst angestossen!
2017-12-29 21:57:30.730 [main error] scan config 08: ERR: read timeout
das hier sagt aus, das auf Adresse 08 keine Antwort kam, muss kein Fehler sein.
Aber am besten sagt immer ein Rawlog was aus, da weis man ob das Scanne funktioniert!
Hier ein Beispiel: beachte die Sendeanfrage des Adapters ">" und Antwort "<" und die Zeit!
2017-11-08 11:04:10.134 [bus notice] <aa
2017-11-08 11:04:10.178 [bus notice] <aa
2017-11-08 11:04:10.221 [main notice] starting initial broadcast scan
2017-11-08 11:04:10.225 [bus notice] <aa Syn vom eBus, Client dürfen den eBus belegen
2017-11-08 11:04:10.228 [bus notice] >01 eigene Adresse wird an den eBus gesendet um eine Anfrage zu initiieren
2017-11-08 11:04:10.233 [bus notice] <01 Bestätigung vom eBus, der Client darf nun senden
2017-11-08 11:04:10.237 [bus notice] >fe nun setzt der Konverter seine Abfragen auf und baut diese Byteweise zusammen
2017-11-08 11:04:10.242 [bus notice] <fe jedes Byte wird vom eBus bestätigt
2017-11-08 11:04:10.246 [bus notice] >07 usw.
2017-11-08 11:04:10.251 [bus notice] <07
2017-11-08 11:04:10.252 [bus notice] >04
2017-11-08 11:04:10.258 [bus notice] <04
2017-11-08 11:04:10.259 [bus notice] >00
2017-11-08 11:04:10.264 [bus notice] <00
2017-11-08 11:04:10.266 [bus notice] >14
2017-11-08 11:04:10.272 [bus notice] <14 die Anfrage ist durch, nun muss etwas gewartet werden,
2017-11-08 11:04:10.275 [bus notice] >aa es folgen SYN und andere Clients dürfen wieder senden
2017-11-08 11:04:10.280 [bus notice] <aa
2017-11-08 11:04:10.327 [bus notice] <aa
2017-11-08 11:04:10.372 [bus notice] <aa
2017-11-08 11:04:10.418 [bus notice] <aa
2017-11-08 11:04:10.462 [bus notice] <aa
2017-11-08 11:04:10.506 [bus notice] <aa
2017-11-08 11:04:10.552 [bus notice] <aa
LG
Reinhart
Hallo John,
hab gerade gesehen, dass du V3.1 erstellt hast ...wie update ich eigentlich am einfachsten mein laufendes System auf dem RASPI? (ohne Konfigurationsfiles groß anzufassen)
Gruß, Michael
Zitat von: micserver am 31 Dezember 2017, 16:01:37
hab gerade gesehen, dass du V3.1 erstellt hast ...wie update ich eigentlich am einfachsten mein laufendes System auf dem RASPI? (ohne Konfigurationsfiles groß anzufassen)
einfach das passende Paket runterladen und mit dpkg -i installieren.
Hallo,
ich möchte gerne eine einmalige Warmwasserbereitung meiner Wärmepumpe (Vaillant VWS 83/3) über den ebusd starten. Hierzu verwende ich den Befehl "write -c quick load", der allerdings nur die Ausgabe "ERR: element not found" bewirkt. Hat jemand eine Idee, wie ich die Funktion starten kann?
Hier die Ausgabe von "ebusctl info":
version: ebusd 3.0pre.bbc4d04
update check: version 3.1 available, broadcast.csv: newer version available, vaillant/08.ehp.csv: newer version available, vaillant/15.uih.csv: newer version available, vaillant/23.ehp.cc.csv: newer version available, vaillant/25.ehp.hwc.csv: newer version available, vaillant/50.ehp.mc.csv: newer version available, vaillant/broadcast.csv: different version a
signal: acquired
symbol rate: 108
max symbol rate: 153
min arbitration micros: 763
max arbitration micros: 1043
min symbol latency: 5
max symbol latency: 8
reconnects: 0
masters: 3
messages: 638
conditional: 285
poll: 2
update: 56
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
Dazu habe ich noch die Frage, weshalb der Update-Check neuere Versionen anzeigt, obwohl ich nach meinem Verständnis die aktuellsten Versionen installiert habe?
# dpkg -l | grep ebusd
ii ebusd 3.1 armhf eBUS daemon.
ii ebusd-configuration 2.1.b143f39-de all ebusd configuration files (de).
Viele Grüße
Robert
Hallo Zusammen,
ich nutze ebus mit mqtt, ist es möglich das ebusd beim schreiben in die Topics, den Status weglässt?
8.00;ok
statt dessen nur
8.00
meldet?
gruss
lewej
Zitat von: john30 am 01 Januar 2018, 19:27:40
einfach das passende Paket runterladen und mit dpkg -i installieren.
Hallo John30,
dpkg -i habe ich gerade auf einem nuc mit ubuntu lts 16 gemacht, dabei hat er mir meine Konfiguration unter /etc/default/ebusd überschrieben.
Gruss
lewej
Ich habe auch ein ähnliches Problem! Habe auch die letzte Version installiert und eine ähnliche Meldung!
Wie soll man das richtig updaten - upgraden?
Außerdem habe ich noch eine Frage:
Bei mir erkennt inzwischen das System zwar die bai.csv, die 430.csv , und auch die v61.mc.csv !
Jedoch kann ich unter der "v61" keine Werte entdecken! Auch ein "ebusctl find -c v61 " findet keine Daten! Warum ?
In der Version ebusd2 hat das schon mal funktioniert und Werte geliefert!
pi@pi-ebus ~ $ ebusctl info
version: ebusd 3.1.v3.0-35-gb0e20b7
update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, vaillant/08.bai.csv: newer version available, vaillant/15.430.csv: newer version available, vaillant/50.v61.mc.csv: newer version available, vaillant/bai.0010006341.inc: newer version available, vaillant/broadcast.csv: different version available, vaillant/errors.in
signal: acquired
symbol rate: 23
max symbol rate: 120
min arbitration micros: 728
max arbitration micros: 1086
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 3
messages: 528
conditional: 18
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0613;HW=7401", loaded "vaillant/bai.0010006341.inc" ([PROD='0010006341']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0415;HW=1902", loaded "vaillant/50.v61.mc.csv"
Hallo
bei mir läuft es nicht so wie es soll, ich sehe einige Werte nicht. Auch sehe ich Fehler im LOG.
@Reinhart: Ist der Installationsweg noch aktuell?? https://forum.fhem.de/index.php/topic,46098.msg405704.html#msg405704 (https://forum.fhem.de/index.php/topic,46098.msg405704.html#msg405704)
Wer kann mir helfen? Was kann ich noch protokollieren?
Die Unterschiede bei ebusdctl info und ebusd -V soll ich ja nicht beachten ....
pi@FHEM:/etc $ ebusctl info
version: ebusd 3.0.v3.0-30-g89c4612
update check: version 3.1 available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 123
min arbitration micros: 2061
max arbitration micros: 3843
min symbol latency: 5
max symbol latency: 8
reconnects: 0
masters: 3
messages: 430
conditional: 19
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
pi@FHEM:/etc $ ebusd -V
ebusd 3.1.v3.0-36-g60a18d1
Inhalt Verzeichnisse:
pi@FHEM:/etc/ebusd $ ls -al
total 24
drwxr-xr-x 3 root root 4096 Dec 30 09:46 .
drwxr-xr-x 4 root root 4096 Dec 30 09:46 ..
-rw-r--r-- 1 root root 1253 Dec 30 09:46 broadcast.csv
-rw-r--r-- 1 root root 754 Dec 30 09:46 memory.csv
-rw-r--r-- 1 root root 1228 Dec 30 09:46 _templates.csv
drwxr-xr-x 2 root root 4096 Dec 30 09:46 vaillant
pi@FHEM:/etc/ebusd $ cd vaillant
pi@FHEM:/etc/ebusd/vaillant $ ls -al
total 776
drwxr-xr-x 2 root root 4096 Dec 30 09:46 .
drwxr-xr-x 3 root root 4096 Dec 30 09:46 ..
lrwxrwxrwx 1 root root 10 Dec 30 09:46 05.vd2.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 05.vd3.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5833 Dec 30 09:46 05.vd4.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 05.vd6.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 05.vl8.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 05.vl9.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5350 Dec 30 09:46 06.pms.csv
-rw-r--r-- 1 root root 3723 Dec 30 09:46 08.bai.csv
-rw-r--r-- 1 root root 28639 Dec 30 09:46 08.ehp.csv
-rw-r--r-- 1 root root 2721 Dec 30 09:46 08.hmu.csv
-rw-r--r-- 1 root root 5656 Dec 30 09:46 0a.pmw.hwc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 15.140.csv -> 15.350.csv
-rw-r--r-- 1 root root 4822 Dec 30 09:46 15.350.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 15.360.csv -> 15.350.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 15.36p.csv -> 15.350.csv
-rw-r--r-- 1 root root 9886 Dec 30 09:46 15.370.csv
-rw-r--r-- 1 root root 8443 Dec 30 09:46 15.392.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 15.400.csv -> 15.350.csv
-rw-r--r-- 1 root root 15460 Dec 30 09:46 15.430.csv
-rw-r--r-- 1 root root 17160 Dec 30 09:46 15.470.csv
-rw-r--r-- 1 root root 19974 Dec 30 09:46 15.700.csv
-rw-r--r-- 1 root root 3949 Dec 30 09:46 15.e7f.csv
-rw-r--r-- 1 root root 9945 Dec 30 09:46 15.f37.csv
-rw-r--r-- 1 root root 14715 Dec 30 09:46 15.f43.csv
-rw-r--r-- 1 root root 16730 Dec 30 09:46 15.f47.csv
lrwxrwxrwx 1 root root 12 Dec 30 09:46 15.heb.csv -> 15.sdr_p.csv
lrwxrwxrwx 1 root root 12 Dec 30 09:46 15.hep.csv -> 15.sdr_p.csv
-rw-r--r-- 1 root root 2986 Dec 30 09:46 15.sdr_p.csv
-rw-r--r-- 1 root root 13608 Dec 30 09:46 15.ui.csv
-rw-r--r-- 1 root root 5908 Dec 30 09:46 15.uih.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 1c.rcc.4.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 1c.v81.4.csv -> 75.v81.csv
-rw-r--r-- 1 root root 539 Dec 30 09:46 23.ehp.cc.csv
-rw-r--r-- 1 root root 885 Dec 30 09:46 23.solsy.cc.csv
-rw-r--r-- 1 root root 886 Dec 30 09:46 23.vr630.cc.csv
-rwxr-xr-x 1 root root 913 Dec 30 09:46 23.zeo.cc.csv
-rw-r--r-- 1 root root 2196 Dec 30 09:46 25.ehp.hwc.csv
-rw-r--r-- 1 root root 2906 Dec 30 09:46 25.solsy.hwc.csv
-rw-r--r-- 1 root root 1944 Dec 30 09:46 25.vr630.hwc.csv
-rwxr-xr-x 1 root root 851 Dec 30 09:46 25.zeo.hwc.csv
-rw-r--r-- 1 root root 4203 Dec 30 09:46 26.solsy.hc.csv
-rw-r--r-- 1 root root 2187 Dec 30 09:46 26.vr630.hc.csv
-rw-r--r-- 1 root root 2447 Dec 30 09:46 26.vr_71.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 35.rcc.1.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 35.v81.1.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 3c.rcc.5.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 3c.v81.5.csv -> 75.v81.csv
-rw-r--r-- 1 root root 6424 Dec 30 09:46 50.ehp.mc.csv
-rw-r--r-- 1 root root 3794 Dec 30 09:46 50.solsy.mc.csv
-rw-r--r-- 1 root root 7583 Dec 30 09:46 50.v61.mc.csv
-rw-r--r-- 1 root root 2403 Dec 30 09:46 50.vr630.mc.csv
-rwxr-xr-x 1 root root 1599 Dec 30 09:46 50.zeo.mc.csv
-rw-r--r-- 1 root root 2446 Dec 30 09:46 51.vr630.mc.3.csv
-rw-r--r-- 1 root root 5359 Dec 30 09:46 52.mc2.mc.4.csv
-rw-r--r-- 1 root root 1349 Dec 30 09:46 52.vr_70.csv
-rw-r--r-- 1 root root 4957 Dec 30 09:46 53.mc2.mc.5.csv
lrwxrwxrwx 1 root root 15 Dec 30 09:46 54.mc2.mc.6.csv -> 52.mc2.mc.4.csv
lrwxrwxrwx 1 root root 15 Dec 30 09:46 55.mc2.mc.7.csv -> 53.mc2.mc.5.csv
-rw-r--r-- 1 root root 515 Dec 30 09:46 64.v65.csv
-rw-r--r-- 1 root root 713 Dec 30 09:46 75.rcc.csv
-rw-r--r-- 1 root root 2601 Dec 30 09:46 75.v81.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 7c.rcc.6.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 7c.v81.6.csv -> 75.v81.csv
-rwxr-xr-x 1 root root 15147 Dec 30 09:46 84.zeo.csv
-rw-r--r-- 1 root root 3309 Dec 30 09:46 a0.sol.hwc.csv
-rw-r--r-- 1 root root 661 Dec 30 09:46 a1.sol.cc.csv
-rw-r--r-- 1 root root 14212 Dec 30 09:46 bai.0010002315.inc
-rw-r--r-- 1 root root 16921 Dec 30 09:46 bai.0010002465.inc
-rw-r--r-- 1 root root 16142 Dec 30 09:46 bai.0010003857.inc
-rw-r--r-- 1 root root 16494 Dec 30 09:46 bai.0010003886.inc
-rw-r--r-- 1 root root 22824 Dec 30 09:46 bai.0010004121.inc
-rw-r--r-- 1 root root 17089 Dec 30 09:46 bai.0010004150.inc
-rw-r--r-- 1 root root 17150 Dec 30 09:46 bai.0010005400.inc
-rw-r--r-- 1 root root 18344 Dec 30 09:46 bai.0010006101.inc
-rw-r--r-- 1 root root 16327 Dec 30 09:46 bai.0010006341.inc
-rw-r--r-- 1 root root 17863 Dec 30 09:46 bai.0010007508.inc
-rw-r--r-- 1 root root 17872 Dec 30 09:46 bai.0010010674.inc
-rw-r--r-- 1 root root 16963 Dec 30 09:46 bai.0010015600.inc
-rw-r--r-- 1 root root 5547 Dec 30 09:46 bai.0020066007.inc
-rw-r--r-- 1 root root 17001 Dec 30 09:46 bai.308523.inc
-rw-r--r-- 1 root root 620 Dec 30 09:46 broadcast.csv
-rw-r--r-- 1 root root 6658 Dec 30 09:46 e0.omu.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 e1.omu.1.csv -> e0.omu.csv
-rw-r--r-- 1 root root 5665 Dec 30 09:46 ec.sol.sc.csv
-rw-r--r-- 1 root root 6001 Dec 30 09:46 ec.solsy.sc.csv
-rwxr-xr-x 1 root root 1280 Dec 30 09:46 ec.zeo.sc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 ed.pms.sc.csv -> 06.pms.csv
-rw-r--r-- 1 root root 525 Dec 30 09:46 errors.inc
lrwxrwxrwx 1 root root 10 Dec 30 09:46 f5.rcc.3.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 f5.v81.3.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 fc.rcc.7.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Dec 30 09:46 fc.v81.7.csv -> 75.v81.csv
-rw-r--r-- 1 root root 693 Dec 30 09:46 general.csv
-rw-r--r-- 1 root root 1010 Dec 30 09:46 hcmode.inc
-rw-r--r-- 1 root root 883 Dec 30 09:46 hwcmode.inc
-rw-r--r-- 1 root root 404 Dec 30 09:46 iotest620.inc
-rw-r--r-- 1 root root 407 Dec 30 09:46 iotest630.inc
-rw-r--r-- 1 root root 307 Dec 30 09:46 iotestact.inc
-rw-r--r-- 1 root root 348 Dec 30 09:46 iotestbmc.inc
-rw-r--r-- 1 root root 313 Dec 30 09:46 iotestbsol.inc
-rw-r--r-- 1 root root 423 Dec 30 09:46 iotesthp.inc
-rw-r--r-- 1 root root 1435 Dec 30 09:46 mcmode.inc
-rw-r--r-- 1 root root 316 Dec 30 09:46 quick.inc
-rw-r--r-- 1 root root 238 Dec 30 09:46 roomtempoffset.inc
-rw-r--r-- 1 root root 792 Dec 30 09:46 scan.csv
-rw-r--r-- 1 root root 530 Dec 30 09:46 service.inc
-rw-r--r-- 1 root root 3475 Dec 30 09:46 _templates.csv
-rw-r--r-- 1 root root 727 Dec 30 09:46 tempsetpoints.inc
-rw-r--r-- 1 root root 647 Dec 30 09:46 timercc.inc
-rw-r--r-- 1 root root 677 Dec 30 09:46 timercool.inc
-rw-r--r-- 1 root root 633 Dec 30 09:46 timerhc.inc
-rw-r--r-- 1 root root 647 Dec 30 09:46 timerhwc.inc
-rw-r--r-- 1 root root 979 Dec 30 09:46 timer.inc
-rw-r--r-- 1 root root 667 Dec 30 09:46 timertariff.inc
-rw-r--r-- 1 root root 606 Dec 30 09:46 yield3d43.inc
-rw-r--r-- 1 root root 606 Dec 30 09:46 yield3f40.inc
-rw-r--r-- 1 root root 606 Dec 30 09:46 yield4445.inc
-rw-r--r-- 1 root root 606 Dec 30 09:46 yield8485.inc
-rw-r--r-- 1 root root 630 Dec 30 09:46 yield8485r.inc
@ihatedenhasen
Du siehst die Werte nicht, weil vermutlich deine bai00.cfg Aufrufe von alten CSV hat. Wir haben ja anscheinend die gleiche Hardware und auch die gleichen CSV. Checke einmal diese hier:
get PumpeWatt cmd {"r -f WPPWMPower\n"}
get Fanspeed cmd {"r -f fanspeed\n"}
get Ruecklauf cmd {"r -f ReturnTemp temp\n"}
Fanspeed kann aber 0 sein, wenn der Ventilator steht.
du kannst aber diese einfach in der Konsole testen:
ebusctl r -f WPPWMPower
Dann siesht du gleich ob eine Antwort kommt.
PS: Mensch Mann, was machst du um diese Uhrzeit, schon auf oder noch nicht Bett weil der eBus nicht so will wie du?
LG
ja, das hat schon geholfen - teilweise:
pi@FHEM:~ $ ebusctl r -f ReturnTemp
45.56;64806;ok
pi@FHEM:~ $ ebusctl r -f WPPWMPower
ERR: element not found
pi@FHEM:~ $ ebusctl r -f fanspeed
1591
eine PWM Pumpe habe ich wohl nicht ... . Wie bekomme ich heraus welche Bauteile ich abfragen kann? Besonderes Interesse habe ich auch an der Fusspunkttemperatur. Die wird gerne verstellt.
Änderungen in der bai00.cfg kann ich nicht vornehmen, denn meine heißt bai01.cfg. Aber da greifen die Änderungen.
Und tatsächlich, wenn mich einige Sachen beschäftigen wird der Schlaf unterbrochen. :o
An meiner 430 ist die Fusspunkttemperatur der Wert ActualRoomTempDesiredHc1 . Das passt.
Nur den Druck kann ich aus der 15.430.csv nicht herauslesen. Reinhart hat den Druck aber visualisiert, nur wie?
Langsam werde ich warm 8)
Edit: Waterpressure . Lösung gefunden. Passt auch.
Fehlt mir noch die interne Heizungspumpe ...
ich habe die Pumpe "WPPWMPower" in der 0010006101.inc.
Schau einfach mit "ebusctl info" welche CSV geladen werden und in denen kannst suchen was du brauchst.
LG
Reinhart
aus der ebusd info dieses erkannt:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
in der 15.430 und bai.308523.inc nicht passendes gefunden. In der 08.bai.csv lese ich nur kryptisches. Ist auch nicht so wichtig (zur Zeit).
Wichtiger für meine Überwachung:
Ich habe zwei Darstellungsfehler zweier Antworten:
pi@FHEM:/etc/ebusd/vaillant $ ebusctl r -f Waterpressure
1.514;ok
pi@FHEM:/etc/ebusd/vaillant $ ebusctl r -f Hc1OPMode
auto
wie kann ich das korrekt darstellen, werde da noch nicht schlau.
Fehlermeldungen in der FHEM.LOG:
2018.01.05 14:20:24 1: EBUS: unexpected answer 1.497;ok\n\n (\061\056\064\071\067\073\157\153\012\012) received (wrote r -f Waterpressure\n (\162\040\055\146\040\127\141\164\145\162\160\162\145\163\163\165\162\145\012), expected \d+\.\d+\n\n)
2018.01.05 14:20:24 1: PERL WARNING: Argument "1.497;ok\n\n" isn't numeric in sprintf at (eval 4494) line 1.
2018.01.05 14:20:24 3: eval: { sprintf("%5.1f",$_) }
2018.01.05 14:20:30 1: EBUS: no answer received (wrote r -f Hc1OPMode (\162\040\055\146\040\110\143\061\117\120\115\157\144\145), expected \d+\.\d+\n\n)
2018.01.05 14:20:30 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 4496) line 1.
2018.01.05 14:20:30 3: eval: { sprintf("%5.1f",$_) }
na ja, du musst noch genauer filtern damit beim Druck das Ok gar nicht erst kommt, lies doch nur den Druck aus.
get Druck cmd {"r -f Waterpressure press.0\n"}
get Druck expect ".*\n*"
get Druck postproc { sprintf("%5.1f",$_) }
und beim HwcOPMode versuchst du den Zahlenwert heraus zu holen ( \d+\.\d+\n\n) und dann mit sprintf zu formatieren (sprintf("%5.1f",$_) obwohl das ein Textstring ist.
get WWSchalter cmd {"r -f HwcOPMode\n"}
get WWSchalter expect ".*\n\n"
get WWSchalter postproc {$_}
so ist es besser.
Wenn du dir bei solchen Sachen nicht sicher bist was das bedeutet, gib einfach in Google ein "Linux sprintf" und du weist wozu das gut ist und verstehst auch gleichzeitig die Syntax. Es ist noch kein Meister vom Himmel gefallen.
In der 08.bai.csv stehen alle Produkt IDs damit das richtige .inc File zugeordnet werden kann.
Jetzt wirst du dich noch fragen, woher ich weis das beim Waterpressure der Druck "press" heißt.
dazu suche ich in der CSV nach Waterpressure
r,,WaterPressure,Wasserdruck,,,,"0200",,,presssensor,,,value of waterpressure-sensor
hier steht "presssensor"
nun suche ich die Bezeichnung für den Sensorwert in der /etc/ebusd/vaillant/_templates
presssensor,press;sensor,,,
und da steht "press". 0 gibt nur die Anzahl der vorhanden Variablen "press" an und beginnt bei 0 zu zählen. Kannst in diesem Fall auch weglassen.
LG
:) :) :) D A N K E :) :) :)
löpt
super wenns klappt, wie du siehst ist das alles kein Hexenwerk!
LG
Bitte steinigt mich nicht . Ich habe nicht alle 168 Seiten gelesen.
Kann ich die Hardware die benötigt wird irgendwo fertig kaufen oder gibt es nur den Selbstbau ?
Andreas
Zitat von: vwsuser am 03 Januar 2018, 10:51:19
ich möchte gerne eine einmalige Warmwasserbereitung meiner Wärmepumpe (Vaillant VWS 83/3) über den ebusd starten. Hierzu verwende ich den Befehl "write -c quick load", der allerdings nur die Ausgabe "ERR: element not found" bewirkt. Hat jemand eine Idee, wie ich die Funktion starten kann?
Hat das wirklich keiner in Betrieb?
@vwuser Mache so etwas mit "einmal Speicher laden"
set P.Lad1x cmd { "w -c quick load %temp\n" }
set P.Lad1x params temp
set P.Lad1x expect "done\n"
set P.Lad1x postproc {if ($_ =~ "done") {"%temp"} else {$_}}
Du brauchst noch eine passende quick.csv. Habe leider eine veraltete Version, läuft aber bestens.
Und auch stoppen.
Zitat von: aruttkamp am 07 Januar 2018, 21:41:22
Bitte steinigt mich nicht . Ich habe nicht alle 168 Seiten gelesen.
Kann ich die Hardware die benötigt wird irgendwo fertig kaufen oder gibt es nur den Selbstbau ?
Andreas
oh, das hast du übersehen, eine Sammelbestellung lief fast 2 Monate hier (https://forum.fhem.de/index.php/topic,79427.0.html).
Aber jetzt sind leider alle Teile aus!
Aber fertige Adapter gibt es auch zu kaufen, einfach danach googlen, es gibt in der Zwischenzeit schon einige Anbieter.
LG
Hallo zusammen,
beim Auslesen meiner Vaillant EcoCompact habe ich 2 Probleme:
1.
Der Parameter "PumpPower" (d.15) wird am Display der Steuerung mit 34% angezeigt, beim Auslesen über den Ebus bekomme ich den Wert 15.
In der "bai.0010015600.inc" steht die Zeile "r,,PumpPower,d.15 Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,"
2.
Wenn ich an meiner Steuerung die Teillast (d.00) auf "Auto" stelle (die Steuerung bestimmt die Teillast selbsttätig), bekomme ich beim Auslesen des Parameters "PartloadHcKW" immer den maximalen Wert von 20 kW angezeigt. In der "bai.0010015600.inc" steht die Zeile "r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"6C00",,,power,,,Heizungsteillast,,,". Für mich stellt sich die Frage, ob dies der berechnete Wert der Steuerung ist oder die über den Datentyp "power" nicht abgedeckt wird.
Es freut mich wenn mir hier die Experten helfen. Danke
Hallo,
zu 1:
es gibt hier offensichtlich bei d.15 zwei verschiedene Anzeigen, einmal Prozent und einmal Watt, abhängig von der Hardware.
r,,WPPWMPower,d.15 Pumpendrehzahl Istwert,,,,"7300",,,percent0,,,actual PWM-Powerrate of electronic-pump
r,,PumpPower,d.15 Leistung Heizungspumpe,,,,7300,,,UCH,,,,,,
Bei mir wird ein CSV geladen, dass mit WPPWMPower definiert ist, also Prozent.
Mit deinem CSV wird PumpPower definiert, also Watt bei dieser Hardware. Ich kann das aber jetzt nur vermuten, das es so gemeint ist.
zu 2:
ja, ist bei mir auch so, es wird nur die maximale Leistung angezeigt.
LG
Hallo Reinhart,
vielen Dank für die schnelle Antwort.
zu 1.
habe die Zeile mit WPPWMPower eingefügt. Dies bringt dasselbe Ergebnis. Ich habe heute die Pumpe auf 100% Drehzahl gestellt. Dann wird über den Ebus der Wert 70 angezeigt. Das ist, wenn ich die technischen Daten richtig erinnere, die Maximal-Leistungsaufnahme der Pumpe in Watt. Deine Vermutung stimmt also, die ID 7300 gibt bei meiner EcoCompact Steuerung die Leistungsaufnahme der Pumpe an. Das einzige was mich noch stutzig macht, ist, warum bei Warmwasseraufbereitung der Wert 100 angezeigt wird.
zu 2.
Schade, dass nur die maximale Leistung angezeigt wird. Ich hätte gerne beobachtet was die Steuerung für Werte einstellt.
Nochmals danke für Deine Hilfe.
hallo,
erstmal danke es läuft alles soweit mit der hilfe von euch.
ich habe ein paar störende meldungen im log:
2018.01.11 22:04:26 1: PERL WARNING: Argument "4.06;ok\n\n" isn't numeric in sprintf at (eval 1847) line 1.
2018.01.11 22:04:26 3: eval: { sprintf("%5.2f",$_) }
pah schrieb man soll immer mit ".*\n*" alle werte auslesen. ich glaube das problem entsteht in der darstellung.
wie muss ich den sprintf definieren das er nur 4,06 ausgibt bzw es keine warnmeldung gibt.
grüße
Das Thema hatten wir ein paar Posts weiter oben (https://forum.fhem.de/index.php/topic,29737.msg743156.html#msg743156). Wie soll sprintf eine Numerische aus dem Text "ok" machen?
Also das "ok" doch gar nicht erst einlesen ist die bessere Methode! Steht auf dem Post beschrieben wie man das macht!
LG
Hallo Zusammen,
damit nicht broadcast Meldungen auch kontinuierlich ausgelesen werden, hat mir john gesagt, ich könnte in den csv Dateien hinter dem r noch eine 1 anhängen und das intervall polling im ebusdaemon auch noch setzen.
Das hat bis vorkurzem immer bei mir funktioniert. Jetzt bin ich auf der aktuellsten 3er Version. Da wird es scheinbar ignoriert. Hat jemand das gleiche Problem?
Gruss
lewej
ich habe diese Version installiert:
version: ebusd 3.1.v3.0-37-g88e4c7e
und da funktioniert wie es wie gewohnt.
2018-01-14 16:18:59.110 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:01.717 [update notice] update bai Status01 QQ=10: 55.0;53.0;0.062;44.0;46.0;off
2018-01-14 16:19:03.715 [update notice] update bai DateTime QQ=10: nosignal;03:59:14;-.-.-;0.062
2018-01-14 16:19:03.931 [update notice] unknown BC cmd: 10feb505020400
2018-01-14 16:19:05.122 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:05.735 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:11.113 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:11.768 [update notice] update bai Status01 QQ=10: 51.0;51.0;0.062;44.0;46.0;off
2018-01-14 16:19:15.799 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:17.110 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:21.868 [update notice] update bai Status01 QQ=10: 53.0;53.0;0.062;44.0;46.0;off
2018-01-14 16:19:23.137 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:23.844 [update notice] update broadcast vdatetime QQ=10: 15:50:45;14.01.2018
2018-01-14 16:19:24.106 [update notice] unknown MS cmd: 1008b512020064 / 00
2018-01-14 16:19:25.885 [update notice] update bai SetMode QQ=10: auto;54.0;-;-;0;0;1;0;0;0
2018-01-14 16:19:29.098 [bus notice] poll 430 Hc1HeatCurve: 1.30
2018-01-14 16:19:29.932 [update notice] update bai Status01 QQ=10: 51.0;47.0;0.062;44.0;47.0;off
Dämon hast nach der Änderung neu gestartet?
LG
Zitat von: lewej am 14 Januar 2018, 15:39:15
damit nicht broadcast Meldungen auch kontinuierlich ausgelesen werden
wie genau soll das denn funktionieren??
Zitat von: lewej am 14 Januar 2018, 15:39:15
, hat mir john gesagt, ich könnte in den csv Dateien hinter dem r noch eine 1 anhängen
das hast Du glaube ich missverstanden. Eine 1 hinter dem r bewirkt, dass eine nachricht mit ins Polling aufgenommen wird, sprich regelmäßig aktiv von ebusd abgerufen wird.
Mit broadcast hat das zunächst mal rein gar nichts zu tun und für broadcast Messages kann das auch gar nicht funktionieren, weil die ja immer vom Sender als broadcast kommen und somit nicht aktiv abgefragt werden können.
Zitat von: lewej am 14 Januar 2018, 15:39:15
Das hat bis vorkurzem immer bei mir funktioniert. Jetzt bin ich auf der aktuellsten 3er Version. Da wird es scheinbar ignoriert. Hat jemand das gleiche Problem?
das sollten wir erstmal klären, was du eigentlich erreichen willst
wenn lewej hier mit einer "1" arbeitet und das vielleicht bei mehreren Messwerten, dann kommt der eBus ordentlich ins schwitzen weil das sehr schnell ist und die Kommunikation ordentlich zustopft. Außer für Testzwecke würde ich das so nicht verwenden.
Broadcast ist ja egal, da wird der Bus ja nur einseitig belastet, aber ständig auch Tx senden ist etwas zu heftig. Ich habe das aber schon öfters gelesen, dass möglichst viele Messwerte in sehr kleinen Abständen für Steuerungen etc. scheinbar gebraucht werden. Ich finde das nicht, denn eine Heizung ist sehr träge und 10 Minuten sind in den meisten Fällen völlig ausreichend. Wer mehr braucht sollte sich eine andere Steuerungsmöglichkeit überlegen. Mann sollte dem Bus noch Zeit lassen seine interne Kommunikation zwischen den Geräten zu erledigen, für das wurde er ja schließlich gebaut.
LG
Hallo Reinhart,
Hallo John,
es funktioniert so wie es auch beschrieben ist, ich hätte einfach nur in logs schauen sollen. Wir hatten einfach seit dem 4.1 keine einzige längere Sonnenstunde, wo die Pumpe anspringen hätte können.
Gruss und Danke für eure Mühe
lewej
wenn du die Pollingtime auch mit hochschraubst passt es schon.
Aber zurück zu deiner ursprünglichen Frage, du hast doch Daten von heute in deinem Post. Was funktioniert denn jetzt deiner Ansicht nicht?
Oder war das noch vor dem ebusd Update auf 3.1 ?
PS: habe gerade gesehen du hast es schon korrigiert.
LG
Hallo Reinhart,
Hallo John,
also wie oben geschrieben wird doch richtig gepollt, jetzt schreibt Reinhart, das wäre nicht so wirklich toll für den bus.
Mein Problem ist, das meine Solarsteuerung gar keine broadcast Meldungen versendet, das heisst ich muss alle Readings Manuell mit get oder halt mit r1 ins polling aufnehmen.
Oder habt ihr eine bessere Idee, wie ich das machen kann.
In der testphase lasse ich alle Readings pollen, später wären es ca. 6-10, die anderen ändern sich ja nicht.
Gruss
lewej
Zitat von: Reinhart am 14 Januar 2018, 16:48:36
wenn lewej hier mit einer "1" arbeitet und das vielleicht bei mehreren Messwerten, dann kommt der eBus ordentlich ins schwitzen weil das sehr schnell ist und die Kommunikation ordentlich zustopft. Außer für Testzwecke würde ich das so nicht verwenden.
Broadcast ist ja egal, da wird der Bus ja nur einseitig belastet, aber ständig auch Tx senden ist etwas zu heftig. Ich habe das aber schon öfters gelesen, dass möglichst viele Messwerte in sehr kleinen Abständen für Steuerungen etc. scheinbar gebraucht werden. Ich finde das nicht, denn eine Heizung ist sehr träge und 10 Minuten sind in den meisten Fällen völlig ausreichend. Wer mehr braucht sollte sich eine andere Steuerungsmöglichkeit überlegen. Mann sollte dem Bus noch Zeit lassen seine interne Kommunikation zwischen den Geräten zu erledigen, für das wurde er ja schließlich gebaut.
LG
Zitat von: Reinhart am 14 Januar 2018, 19:54:47
wenn du die Pollingtime auch mit hochschraubst passt es schon.
Aber zurück zu deiner ursprünglichen Frage, du hast doch Daten von heute in deinem Post. Was funktioniert denn jetzt deiner Ansicht nicht?
Oder war das noch vor dem ebusd Update auf 3.1 ?
PS: habe gerade gesehen du hast es schon korrigiert.
LG
Ich bin davon ausgegangen das es nicht funktioniert, da die Collpumpe1 bereits seit dem 4.1 auf off steht und seit dem gab es keine Veränderung am Readingdstum, aber das ist richtig so, wir hatten seit dem 4.1 einfach keine Sonnenstunden wo die Pumpe angelaufen wäre, zumindest steht es so im ebus log.
Ich werde es mal die nächsten Tage beobachten.
gruss
lewej
Zitat von: jkriegl am 08 Januar 2018, 12:42:22
set P.Lad1x cmd { "w -c quick load %temp\n" }
set P.Lad1x params temp
set P.Lad1x expect "done\n"
set P.Lad1x postproc {if ($_ =~ "done") {"%temp"} else {$_}}
Du brauchst noch eine passende quick.csv. Habe leider eine veraltete Version, läuft aber bestens.
Und auch stoppen.
Bei mir funktioniert das leider nicht. Meine quick.csv sieht wie folgt aus:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
# MK: quick commands,,,,,,,,,,,,,
*w,,,,,,"B505",,,,,,,
w,,party,Quick - Party,,,,05,,,onoff,,,
w,,load,Quick - WW Speicherladung,,,,06,,,onoff,,,
w,,save,Quick - Sparen bis,,,,07,,,TTH,,,
Kannst du mal deine quick.csv posten?
Zitat von: vwsuser am 15 Januar 2018, 13:44:18
Bei mir funktioniert das leider nicht. Meine quick.csv sieht wie folgt aus:
Du musst einfach anstelle von "w -c quick load %temp\n" folgendes nehmen:
"w -c SLAVE load on\n"
und statt SLAVE vermutlich hwc nehmen.
Schau einfach mal, wie das bei Dir definiert ist mit "ebusctl find -w load".
hallo nochmals!
habe eine frage zur speicherladung mit der 470.
Zitat
ebusctl r -f HwcOPMode
ebusctl w -c 470#install HwcOPMode 6
sind das die richtigen befehle?
was ich so gelesen habe dürfte die cvs das write nicht erlauben.
stimmt das? und falls ja kann ich das file einfach mit dem write befehl erweitern und es sollte dann klappen?
danke und lg
das selbe gilt wohl auch für
Zitat
Hc1Pump
dort steht im cvs auch nur die leserechte.
wie muss man das richtig anpassen damit nichts kaputt geht?
ideal wäre die ansteuerung folgender teile mit fhem ohne
mit dem 470 arbeiten zu müssen.
einmal speicherladung falls nötig
ansteuerung der zirk. pumpe mit fhem
an und abschalten der heizungspumpe da in zukunft alternativ mit holz geheizt werden kann
wobei die selbe heizungspumpe verwendet werden soll.
das könnte man dann darüber regeln in dem man die soll temperatur vom vaillant runter regelt oder
gibt es dazu eine elegantere eingabe variante?
danke! :)
da muss in der CSV auf W geändert werden, dann geht das (mit meiner 470er). Kurzer Auszug aus meiner Klasse:
set Wannenfuellung cmd {"w -c 470 hwctempdesired 60\n"}
set Speicherfüllung cmd {"w -c 470 hwctempdesired 45\n"}
set Speicher_laden cmd {"w -c 470 hwcOPMode 6\n"}
set Partymodus cmd {"w -c 470 hwcOPMode 4\n"}
set Speicherautomatik cmd {"w -c 470 hwcOPMode 2\n"}
set Sommerbetrieb cmd {"w -c 470 hc1opmode 5\n"}
set Heizautomatik cmd {"w -c 470 hc1opmode 2\n"}
dann mittels Dummy und Notify einfach aufgerufen (ja, geht auch einfacher, nur war ich damals noch nicht soweit)
@vwuser, hier meine quick.csv
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m;s),type / templates,divider / values,unit
*b,quick,,,,25,B505,,,,,,
*w,quick,,,,25,B505,,,,,,
#*w4,quick_mc4,,,,52,B505,,,,,,
#*w5,quick_mc5,,,,53,B505,,,,,,
#w;w4;w5,,party,Quick - Party,,,,05,,,onoff,,
w;b,,load,Quick - WW Speicherladung,,,,06,,,onoff,,
#w;w4;w5,,save,Quick - Sparen bis,,,,07,,,TTH,,
Aber Achtung: bin noch auf ebusd 2.? Läuft aber wunderbar.
r;wi,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,0=off;1=on;2=auto;3=autosunday;4=party;5=load;7=holiday,,"operation mode of the domestic hot water circuit set implicitly"
in meiner csv fehlt die option 6 komplett.
er nimmt mir aber auch leider nicht die anderen optionen :(
pi@raspi:/etc/ebusd/vaillant $ ebusctl r -f hwctempdesired
61.0
pi@raspi:/etc/ebusd/vaillant $ ebusctl write -c 470 hwctempdesired 60
done
pi@raspi:/etc/ebusd/vaillant $ ebusctl write -c 470 Hc1DayTemp 22
done
pi@raspi:/etc/ebusd/vaillant $ ebusctl write -c 470 hwcOPMode 5
ERR: element not found
pi@raspi:/etc/ebusd/vaillant $ ebusctl write -c 470 hwcOPMode 4
ERR: element not found
...meine sieht an der Stelle so aus:
r;w,,HwcOPMode,Betriebsart Warmwasserkreis,,,,"4200",,,UCH,,,"operation mode of the domestic hot water circuit set implicitly (0 = off, 1 = on, 2 = auto, 3 = auto sunday, 4 = party, 6 = one time tank loading, 7 = holiday)"
Zitat von: rob uboot am 25 Januar 2018, 10:39:24
sind das die richtigen befehle?
was ich so gelesen habe dürfte die cvs das write nicht erlauben.
stimmt das? und falls ja kann ich das file einfach mit dem write befehl erweitern und es sollte dann klappen?
Ab der Version 3.0 hat John hier den Accesslevel eingeführt, siehe hier (https://forum.fhem.de/index.php/topic,46098.msg688713.html#msg688713).
--accesslevel=*dann kannst du schreiben.
LG
sudo service ebusd start --accesslevel=install
klappt super - danke! :)
pi@raspi:~ $ ebusctl w -c 470 Hc1Pump 1
done
pi@raspi:~ $ ebusctl r -f Hc1Pump
on
muss ich das im systemstart ebenfalls eintragen?
welcher befehl ist das dann?
danke & lg
pi@raspi:/etc/ebusd/vaillant $ ebusctl r -f hwcOPMode
2
pi@raspi:/etc/ebusd/vaillant $ ebusctl w -c 470 hwcOPMode 6
done
pi@raspi:/etc/ebusd/vaillant $ ebusctl r -f hwcOPMode
2
irgendwo habe ich da einen fehler. csv wurde wie beschrieben verändert.
den befehl 6 zeigt er zwar als erledigt an ändert aber nichts
pi@raspi:/etc/ebusd/vaillant $ ebusctl r -f hwcOPMode
6
pi@raspi:/etc/ebusd/vaillant $ ebusctl w -c 470 hwcOPMode 2
done
pi@raspi:/etc/ebusd/vaillant $ ebusctl r -f hwcOPMode
6
wenn man die speicherladung hingegen bei dem 470 aktiviert.
springt er auf den 6er modus um.
dieser lässt sich dann aber nicht mehr überschreiben?!?
was mache ich da falsch? :o
Hallo,
Zitat von: rob uboot am 25 Januar 2018, 23:28:25
... wenn man die speicherladung hingegen bei dem 470 aktiviert, springt er auf den 6er modus um.
Dieser lässt sich dann aber nicht mehr überschreiben?!?
Was mache ich da falsch? :o
höchstwahrscheinlich machst Du nichts falsch.
Die verschiedenen 470er-Versionen haben wohl ein internes Problem beim Beschreiben
des hwcOPMode per ebus (und damit dann per ebusd).
Lt. Forum gibt es hier wohl nur einen Nutzer, bei dem das Beschreiben des hwcOPMode in der
470er funktioniert, jedoch so ca. 5-8 Nutzer, bei denen es nicht klappt.
Es gibt ja mind. diese 470er-Versionen der calorMATIC: 470; 470/2; 470/3; 470/4; 470f; die
wohl alle auch noch unterschiedliche (interne) Software-Versionen besitzen können.
Es sieht dadurch wohl so aus, daß die unterschiedlichsten Softwareversionen der 470er wohl
einen internen Fehler beim Beschreiben des hwcOPMode besitzen, den Vaillant so auch nicht
repariert/repariert hat, weil es im "normalen" Betrieb des 470er-Reglers nicht als Fehler auftritt.
In der Original-Software von Vaillant ist lt. john30 der hwcOPMode für (alle) 470er auch nur als
lesend gekennzeichnet.
Ich bin mit meiner 470er-Version auch mit dem Nichtbeschreiben des hwcOPMode (https://forum.fhem.de/index.php/topic,29737.msg699848.html#msg699848) betroffen, eine Lösung
habe ich leider nicht gefunden, trotz vieler Versuche per unterschiedlichster Varianten und Vorgehensweisen.
Wie gesagt, das ist damit wohl kein Problem auf Seiten des ebusd.
sua
Zitat von: sua am 26 Januar 2018, 15:26:36
Ich bin mit meiner 470er-Version auch mit dem Nichtbeschreiben des hwcOPMode (https://forum.fhem.de/index.php/topic,29737.msg699848.html#msg699848) betroffen, eine Lösung
habe ich leider nicht gefunden, trotz vieler Versuche per unterschiedlichster Varianten und Vorgehensweisen.
Hast Du schon mal den letzten Stand der csv, insbesondere mit hwcmode.inc (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/hwcmode.inc) probiert?
Ich könnte mir gut vorstellen, dass sich der HWC Mode der 470 nur mit diesen "Standard"-Nachrichten von außen ändern lässt.
Hallo john30,
Zitat von: john30 am 26 Januar 2018, 17:54:45
Hast Du schon mal den letzten Stand der csv, insbesondere mit hwcmode.inc (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/hwcmode.inc) probiert?
im Prinzip schon, wenn wir vom "SetMode" und "B505" reden.
Die hwcmode.inc wird bei mir "normal" wohl nicht geladen, aber der "SetMode" ist dann in der bai mit enthalten...
Hier 'mal meine ebusctl info (Stand 2017-11):
root@ebusd30-Rpb2B:~# ebusctl info
version: ebusd 3.0.v3.0-23-g4c1aefb
...
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0113;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015600']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
der Setmode lieferte:
root@ebusd30-Rpb2B:~# ebusctl read SetMode
auto;36.0;-;-;0;0;1;0;0;0
root@ebusd30-Rpb2B:~#
root@ebusd30-Rpb2B:~# ebusctl r -c bai Setmode
auto;36.0;-;-;0;0;1;0;0;0Einen direkten HWC habe ich da nicht gefunden, oder habe ich hier einen groben Denkfehler???
Ich habe z.Z. nur Zugriff auf einen Teil meine damaligen log-Dateien, aber lt. denen erbrachte
ein write des "Setmode" auch ggf. ein done, aber eben dann keinerlei Änderung/Umschaltung
in der 470er (nach "hardcodieren" der hwcmode.inc abwechselnd in die bai- bzw 470-csv und
deaktivieren des original-Setmode).
Unabhängig davon hatte ich auch mit direkten hex-Schreiben des SetMode "02" und dem "B505"
jeweils bei bai und 470 getestet, für mich ohne Umschalt-Ergebnis...
Ggf. kannst Du mich ja doch noch irgendwie in die richtige Richtung "treten"? ;-)
Danke,
sua
bei mir ändert er den HwcOPMode auch nur für sehr kurze zeit.
so dinge wie die heizungspumpe kann ich damit auch nicht steuern auch wenn ich das 'done' bekomme.
denke mal es wird wirklich am 470 liegen. vaillant bietet den auch nicht mehr an
und die einzige offizielle schnittstelle bietet diese option an jedoch muss der multimatic vorhanden sein.
vielleicht ist aber auch der befehl der falsche und die rechte wurden daher nur auf lesen gesetzt.
kenne mich leider null aus.
wäre aber über eine hilfe sehr dankbar weil genau das die befehle sind die meiner meinung nach sinnvoll sind für eine smart home anbindung. :-\
Hi,
ich muss leider auf einen etwas älteren Post zurückgreifen, aber ich komme auch eigentlich aus der openhab ecke
und bin nun nur zufällig hier im thread über anghängtes posting von galileo gestolpert.
grundsätzlich tut bei mir ein esera ebus ethernet adapter seinen dienst, mit sehr schlechten ergebnissen (70-90% failed).
jemand aus dem openhab forum hat dann jetzt auf den ebus 2.0 adapter gewechselt und ist begeistert - dieser spur bin ich gefolgt und hier gelandet.
neben dem interesse an dem neuen adapter, hab ich beim einlesen diesen genialen umbau von galileo entdeckt.
meine frage: hat sich der umbau bewährt und funktioniert der adpater noch?
hat ev. jemand auch die ethernet variante des adapters umgebaut?
thx!
https://forum.fhem.de/index.php/topic,29737.msg511678.html#msg511678
Zitat von: galileo am 28 Oktober 2016, 19:06:32
Nie wieder Poti einstellen !
Nachdem ich tagelang einen Fehler gesucht habe und sich danach herausgestellt hat, dass bloß das Potentiometer nicht richtig eingestellt war (obwohl ich mich an die Einstellanleitung im WIKI genau gehalten habe) habe ich mich ein wenig mit der gegenwärtigen Schaltung auseinandergesetzt. Primär war da die Frage, wieso Vaillant, der ja mit seiner Hardware auch am Bus spricht, nicht alle 2 Wochen ausrücken muss um beim Kunden ein Potentiometer nachzujustieren. Die Antwort lag auf der Hand: es gibt bei den Vaillant-Schaltungen kein Potentiometer.
Ich möchte gleich vorausschicken dass ich hier niemanden kritisieren will. Ganz im Gegenteil, das ist eine fantastische Arbeit die hier von allen geleistet wurde und ich bin schließlich auch ein Nutznießer davon. Vielen Dank dafür. Ich möchte das Folgende einfach als Anregung einbringen, aber auch erklären, warum es so ist wie es ist.
Ich fange einmal mit dem Problem der gegenwärtigen Schaltung (http://www.fhemwiki.de/wiki/EBUS (http://www.fhemwiki.de/wiki/EBUS)) an:
Die eBus Spezifikation sieht für die beiden Pegel Low und High vor:
Low = 8,0 bis 10,0 Volt, High = 15,0 bis 24,0 Volt.
Das heißt, im schlechtesten Fall haben wir einen Bereich von 10V bis 15V der den Unterschied von Low zu High ausmacht.
Dieses Signal wird nun über den CNY17 Optokoppler ,,analog" übertragen. Vom CNY17 gibt es vier ,,Versionen" (-1, -2, -3 und -4) welche sich alleine in der Übertragungsrate IC/IF im Bereich zwischen 13% und 90% bewegen können. Welcher Typ hier verwendet werden soll, wurde nicht angegeben. Wegen dieses Verhältnisses ergibt sich für die Spannungsdifferenz zwischen Low und High am Eingang 2 des 4011 C-Mos Gatters:
Maximum = 15-10 * 90% = 4,5V; Minimum = 15-10 * 13% = 0,65V
Die Spezifikation des 4011 sieht aber bei dieser Versorgungsspannung (5V) typisch vor:
Low Level Input Voltage = 2V; High Level Input Voltage = 3V.
Worst case sogar 1,5 / 3,5 Volt. Alles dazwischen ist undefiniert, der CD4011 kann dann am Ausgang beliebiges produzieren. Die von PAH angegebene Spannung für High = 2,57V liegt aber in jedem Fall außerhalb des erlaubten Bereichs. Es ist also selbst bei optimal eingestelltem Poti möglich, dass es wegen der Verletzung der Spezifikationen zu Fehlfunktionen kommt. Insbesondere ist es auch möglich dass wegen der Temperaturabhängigkeit der Bauteile Verschiebungen während des Betriebs eintreten.
Die im Forum immer wieder aufgestellte Behauptung, die Leitungslänge des eBus habe einen Einfluss, kann ich keinesfalls nachvollziehen. Diese könnte bestenfalls auf die Signalform Einfluss haben, nicht aber auf die Spannungen. Hier geht es ausschließlich um Bauteil-Toleranzen und die Einhaltung der Spezifikationen.
Die Lösung für alle diese Probleme lautet ,,Comparator" (siehe: comparator_pah.jpg). Und zwar bereits so nahe wie möglich am Eingangssignal. Nebenbei bemerkt ist das auch die Lösung die Vaillant in seinen Geräten einsetzt.
Zuerst wird das Eingangssignal über einen Spannungsteiler R4/R5 heruntergeteilt: Aus High=15V wird 3,19V und aus Low=12V wird 2,55V. Das passt nun zur Weiterverarbeitung in einem System mit 5V Versorgung, wobei die 5V auch gleichzeitig als Referenzspannung dienen. Der Comparator ist ein ,,invertierender Comparator mit Hysterese" (Schmitt-Trigger). Das bringt diverse Vorteile bei der Bemessung der Bauteile und wegen der Hysterese auch eine Sicherheit gegen Störungen auf der Datenleitung. Die Werte von R1, R2 und R3 ergeben sich aus den Standard Formeln. Da der Ausgang üblicherweise ein Open-Collector ist, benötigt er einen Pull-Up-Widerstand. Dieser sollte klein gegenüber den Widerständen R1 R2 und R3 sein, da er sonst das Rechenergebnis verfälscht. Mit diesen Werten ergibt sich nun: Der Comparator schaltet auf Low, wenn der Eingang über 3,06V geht, und er schaltet auf High, wenn er unter 2,75V geht. Da der Comparator invertiert, wird ihm ein einfacher Inverter mit einem Transistor nachgeschaltet.
Die Wahl des Comparators ist relativ unkritisch. Ich habe hier einen LM311 gewählt, weil er gerade zur Hand war. Es können sowohl bipolare Typen als auch CMOS verwendet werden. Wenn ein Comparator mit Push-Pull Ausgang Verwendung findet, müsste man allerdings die Beschaltung in Richtung Transistor anpassen.
Ab diesem Zeitpunkt ist das Signal rein digital. Es spielt also keine Rolle mehr, welcher Klasse der CNY17 angehört, oder in welcher Position das Poti steht !! Alle kritischen Pegel wurden bereits am Comparator behandelt..
Diese Schaltung kostet ein paar Cent und kann auf einfache Weise nachgerüstet werden. Sie kann ,,statt" des 3k3 Widerstandes R1 in den Signalpfad eingefügt werden, also R1 auslöten und den Eingang (,,IN") an den Brückengleichrichter ,,+" anschließen und den Ausgang (,,OUT") an den CNY17. Wegen der für diesen Zweck etwas unglücklichen Beschaltung des CNY17 muss hier mit einem PNP Transistor etwas ,,getrickst" werden (Q1 / R7 / R8). Bei einem Neu-Design könnte man entsprechend direkter vorgehen. Die Versorgung 0 / +5V kann am 78L05 abgegriffen werden.
Ich habe diese Schaltung selbst auf einer Lochraster Platine aufgebaut, allerdings nicht in dieser Variante mit dem PNP Transistor am Ausgang sondern mit einer NPN Transistor (siehe weiter unten). Ich habe mir nämlich den ,,kommerziellen" eBus USB Koppler von e-Service geleistet. Eigentlich hauptsächlich weil der schon ein Hutschienen Gehäuse hat, welches ich benötige. Da dann aber dort auch ein Potentiometer zum Einstellen vorhanden war, sah ich mich veranlasst, mir auch diese Schaltung genauer anzusehen. So sieht sie aus:
(EService_Schaltung.jpg)
Der Spannungsteiler R1/R2/R3 teilt je nach Poti Einstellung von 21:1 bis 21:11. Somit ergibt sich schon einmal bei einer maximalen Eingangsspannung von 24V und voll aufgedrehtem Poti eine Spannung von 12,5V am Eingang des 4011. Weit über dessen Versorgungsspannung und eigentlich der Tod des 4011. Nicht gerade die feine Art...
Steht das Poti ,,optimal", d.h. wenn sich 12,5V Eingangsspannung auf 2,5V am 4011 abbilden, dann muss es (zusammen mit dem 1k Vorwiderstand) 4k2 haben. Bei dieser Stellung ergibt sich:
Low = 10*4,2/21 = 2V und High = 15*4,2/21 = 3V
was zwar gerade noch den typischen Werten des 4011 entspricht, aber nicht den Worst Case Werten (1,5 / 3,5) und es setzt voraus dass das Poti um keinen Mikrometer falsch steht. Also insgesamt gesehen hätten hier zwei Festwiderstände mit den richtigen Werten einen besseren Dienst getan...
Jedenfalls bringt auch hier der Einsatz eines Comparators die Lösung aller Eingangs-Probleme. Die Schaltung muss allerdings am Ausgangs-Inverter etwas anders aussehen, um in den bestehenden e-Service Koppler integriert werden zu können (Comparator_eService.jpg). Auch hier würde man bei einer Neukonstruktion ein paar sinnlos gewordene Inverter einsparen können.
Noch eine Bemerkung zur Spannungsversorgung. Beim e-Service Konverter ist der 5-Volt-Regler nicht direkt an ,,+" des Brückengleichrichters angeschlossen. Warum ? Im schlechtesten Fall (Low am Bus) bleiben dem Regler 8-5 = 3 Volt zum Regeln was schon ziemlich nahe an den minimalen 2V liegt. Ein 10uF Kondensator (C1) dient hier als Ladungsspeicher und integriert die Spannung auf. Ein 100Ohm Widerstand begrenzt den Strom in den Kondensator und dient außerdem als Tiefpass-Filter. Die Diode D2 ist notwendig, damit der Kondensator nicht wieder über den Darlington-Transistor T1 entladen wird. Das macht Sinn weil somit die Eingangsspannung am 5V-Regler permanent höher und auch ,,glatter" ist. Eine derartige Ergänzung würde sicherlich auch der Schaltung von PAH guttun.
Also mit diesem Comparator am Eingang läuft mein Interface jetzt problemlos, OHNE irgendeine Einstellung vorgenommen zu haben. Alle Geräte am Bus wurden problemlos gefunden, was ja vorher nicht der Fall war. Ein Foto vom Umbau habe ich noch angefügt (eservice_mod.jpg). Vielleicht hilft das ja dem einen oder anderen seine Empfangs-Probleme zu beheben.
LG
Eduard
Zitat von: aia am 28 Januar 2018, 09:13:24
meine frage: hat sich der umbau bewährt und funktioniert der adpater noch?
hat ev. jemand auch die ethernet variante des adapters umgebaut?
Den bestehenden Adapter umbauen ist für Leute die mit dem Lötkolben umgehen können kein Problem. Chons hat das Testmuster von galileo die ganze Zeit ohne Fehler in Betrieb gehabt. Es wird jedoch wieder eine Sammelbestellung der V2 geben da kannst du dich dann dazu hängen, nur Platine kostet ja 2,50.- und ist sicher leistbar.
Die Ethernet Variante macht einige Kopfzerbrechen weil du die erforderlichen Latenzen nicht so leicht erreichst, zumindest mit einem K2 oder K3. Es gibt aber auch andere Varianten die aber größer sind und auch in den kommerziellen Adaptern verbaut sind. Wenn du dir die WLAN Variante der Platine 2.0 anschaust, da musste John extra eine neue Softwareanbindung (Firmware für Wemos) schreiben weil eine herkömmliche serielle Bridge von der Latenz her nicht ausreicht. Empfang geht, aber zum Senden bist dann zu spät und kommt nicht mehr korrekt an.
Das ist der einzige springende Punkt beim eBus Protokoll, dass man hier nicht ewig Zeit hat auf ein Signal zu antworten. Wenn der Bus ein Syn aussendet (AA) , dann sollte die Hardware innerhalb weniger msec (bis etwa 10-15 kein Problem) darauf reagierien, sonst meldet sich eventuell ein anderer oder du bist zu spät oder funkst gar mitten ins Protokoll einer anderen Übertragungsanforderung.
LG
Bei der nächsen Adapter Bestellung bin ich dabei, das ist schon mal klar.
Trotzdem möchte ich diesen esera auch noch zum laufen bringen, ...
Den Lötkolben kann ich halten, komme aber grundsätzlich aus einer anderen Ecke, deshalb muss ich nochmals im Detail nachfragen.
Du schreibst in den kommerziellen Adaptern sind Varianten verbaut, welche entsprechende Latenzen erreichen können,
somit sollte dies auch im esera adapter passen ?
Soweit ich das jetzt sehe ist das Latenzproblem auch unabhängig von der neuen Schaltung statt dem Poti.
Fazit: der Umbau des esera sollte auch mit der Ethernet Variante klappen, da hier ja nur das Signal entsprechend angepasst wird?
Lieg ich da noch richtig ?
Zitat von: aia am 28 Januar 2018, 10:33:12
Du schreibst in den kommerziellen Adaptern sind Varianten verbaut, welche entsprechende Latenzen erreichen können,
somit sollte dies auch im esera adapter passen ?
Leider nein, der Ethernet Koppler ist bekannt für immer wieder auftretende Probleme. Das liegt zum Teil eben daran, dass der verbaute Serial-Ethernet Wandler nicht unbdeingt das beste Modell ist. Dieses verursacht Latenzen bis 100ms, was dann das eBUS Protkoll ruiniert.
Zitat von: aia am 28 Januar 2018, 10:33:12
Soweit ich das jetzt sehe ist das Latenzproblem auch unabhängig von der neuen Schaltung statt dem Poti.
das schon, ja.
Zitat von: aia am 28 Januar 2018, 10:33:12
Fazit: der Umbau des esera sollte auch mit der Ethernet Variante klappen, da hier ja nur das Signal entsprechend angepasst wird?
es macht die Einstellung natürlich leichter, löst aber nicht das Latenzproblem.
ok, alles klar!
danke für die infos, schön langsam verstehe ich die sache auch ein wenig auf der technischen seite.
teures stück plastik/elektro schrott :(
Hallo aia,
meine Geschichte beginnt auch bei dem esera/eservice Adapter, und zwar bei der Ethernet Variante. Dort habe ich allerdings auch die von dir beschriebenen Erfahrungen gemacht. Ging nur selten...
In meiner Verzweiflung und wegen der Berichte in diesem Forum (alle mit USB/Seriell Wandler) habe ich mir dann auch noch die eservice USB Variante besorgt. Damit konnte ich von meinen vier eBus Teilnehmern zwei erkennen und zwei nicht (lag wohl an unterschiedlichen Pegeln am Bus). Bin dann John30 auf die Nerven gegangen :) der mich dann auf das Problem mit dem Poti gebracht hat. Mit der "Mikrometer-Schraube" gings dann und das war letztlich der Auslöser für meine Überlegungen zu diesem Posting.
Ich habe dann zwei Dinge gemacht - einmal den eservice Adapter umgebaut (ich glaube, das wolltest du eigentlich wissen) und dann noch die Schaltung entworfen, die jetzt unter eBus Adapter 2.0 dank Chons, Reinhart und John30 mit so viel Mühe und Herzblut publiziert wird (an dieser Stelle danke an Euch und Hut ab für diese Arbeit!)
Der umgebaute eservice Adapter (USB) hat bei mir viele Monate klaglos funktioniert, ich habe ihn erst entfernt als ich den eBus Adapter 2.0 getestet und dann verwendet habe. Die Ethernet Variante
habe ich nie wieder angeschaut und heute weiss ich auch dass der Grund für das Nicht-funktionieren mit höchster Wahrscheinlichkeit das Latenzproblem ist.
Also leider kann ich dir auch keinen besseren Rat geben, als die Ethernet Variante zu vergessen. Wenn du nicht nocheinmal auf esera (USB) zurückgreifen willst dann kann ich dir nur den Adapter 2.0 ans Herz legen.
LG Eduard
P.S. Wenn du willst kann ich dir meinen umgebauten eservice-USB Adapter "borgen", bis es wieder Adapter 2.0 gibt. Liegt sonst eh nur bei mir herum. Schreib mir eine PM.
Hallo,
ich weiß nicht, ob der Thread noch länger werden soll, aber bei mir läufts leider auch nicht rund.
Ich hab den den Ebus Adapter über den Wemos am Raspi hängen (Wheezy).
Wenn ich den Wemos resette, bekomme ich für maximal 5-10 Minuten eine Kommunikation mit meiner Vaillant Therme hin. Danach meldet ebusctl "no signal".
In dieser Zeit kann ich z.B. über die Konsole mit:ebusctl r StorageTemp die Temperatur abfragen.
Über FHEM klappt es aber nicht. Da bekomme ich von Anfang an keine Antwort:
2018.01.28 17:55:56 3: EBUS device opened
2018.01.28 17:55:59 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2018.01.28 17:55:59 1: EBUS: no answer received (wrote r -f StorageTemp\n (\162\040\055\146\040\123\164\157\162\141\147\145\124\145\155\160\012), expected \d+\.\d+\n\n)
2018.01.28 17:55:59 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 2363) line 1.
2018.01.28 17:55:59 3: eval: { sprintf("%5.1f",$_) }
Meine Funktion ist wie folgt definiert:
# StorageTemp
get StorageTemp cmd {"r -f StorageTemp\n"}
get StorageTemp expect "\d+\.\d+\n\n"
get StorageTemp postproc { sprintf("%5.1f",$_) }
Wäre schön, wenn die Ergebnisse erst mal auch bei FHEM ankommen würden.
Vielleicht hat da jemand einen Tipp.
Warum der Wemos später aussteigt, kann ich selbst nochmal weiter untersuchen.
Danke
@galileo:
solange ich den traffic am bus niedrig halte, klappt das meiste eigentlich recht gut.
teilweise bekomme ich zwar über 5 minuten überhaupt keine antwort, in summe ist es aber noch erträglich (meistens lese ich ja nur).
wenn ich mir die failed ratio anschaue kommen mir allerdings die tränen - 85% aller telgramme sind für den kanal :(
ich komme gerne auf dein angebot zurück für ein paar wochen mal die usb variante zu testen - der direkte vergleich ist sicher sehr interessant.
bekommst eine pm.
@hanske
du versuchst den String "ok" in eine Zahl zu verwandeln, das klappt nicht!
Warum holst du nicht nur die Temperatur als Zahl vom Bus?
pi@Raspberry2:~ $ ebusctl r -f StorageTemp
36.38;ok
das ist das Ergebnis wie du sie holst, inkl. dem String "ok"
pi@Raspberry2:~ $ ebusctl r -f StorageTemp temp
36.25
und so separierst du nur die Temperatur.
das schaut dann so aus:
get StorageTemp cmd {"r -f StorageTemp temp\n"}
get StorageTemp expect ".*\n*"
get StorageTemp postproc {$_}
Betreffend dem Wlan, hast du ein halbwegs gutes Signal zum Wemos?
Ich habe bei den Tests die verschiedenen Übetragsungsmodi getestet und konnte bis 802.11b problemlos über mehrere Tage kommunizieren. Das Empfangssignal sollte jedoch in halbwegs guter Qualität sein und keine Aussetzer haben. Oft genügt eine neue Positionierung des Wemos für besseren Empfang.
LG
Hallo Rainer,
danke für den Tipp mit dem temp.
Ich hatte mich erst am Wiki orientiert, dann aber festgestellt, dass bei meiner Therme die Befehle anders sind und mir die Strings aus dem CSV geholt. Dabei habe ich das temp wohl vergessen.
Muss man immer "temp" schreiben, wenn man das "ok" nicht haben will?
Im Wiki steht auch mal "temp1.0"
Ich habe jetzt deinen Vorschlag implementiert:
get StorageTemp cmd {"r -f StorageTemp temp\n"}
get StorageTemp expect ".*\n*"
get StorageTemp postproc {$_}
bekomme aber immer noch keine Antwort.
2018.01.28 21:21:32 1: EBUS: no answer received (wrote r -f StorageTemp temp\n (\162\040\055\146\040\123\164\157\162\141\147\145\124\145\155\160\040\164\145\155\160\012), expected .*\n*)
Die Konsole liefert aber:
pi@raspberrypi ~ $ ebusctl r storageTemp temp
19.44
Da muss doch noch was anderes schief laufen?
Btw:
Wlan ist gut (Fritzbox ist nur 2 Meter entfernt) und der Raspi hängt am LAN.
Läuft jetzt gerade auch schon 1 Stunde stabil.
Beim Wemos hängt sich auch häufig der Webserver auf.
hallo nochmals!
habe noch eine frage betreffend 470 und 700 regler von vaillant.
vielleicht hat ja jemand diesbezüglich erfahren gemacht oder kennt sich mit dem ebus perfekt aus. :)
laut csv file kann man in der 470 variante weder den HwcOPMode noch den Hc1Pump schreiben.
stellt man das händisch um geht der befehl zwar als 'done' durch nur tut sich dabei eben nichts.
laut dem csv file am multimatic 700 ist das original schon auf schreiben.
würde mal daher davon ausgehen dass man eine 700 haben muss um den befehl auch durchführen zu können.
muss oder kann man das mit der hardware lösen oder geht das doch mit der software?
???
Hi,
zur 700 gibt es ja leider keine offiziellen Datenbanken mehr. Alles was da drin steht, wurde von Usern durch try&error zusammengetragen.
Den HwcOpMode kann man dort ganz normal und ohne Umstände schreiben.
Ich habe jedoch bei Vaillant auch einige Kuriositäten entdeckt:
a) Manche Informationen sind über verschiedene Nachrichten les-/schreibbar. So habe ich bei meinem icoVIT 156 beobachtet, dass mit einer zweiten Nachricht immer die aktuelle Einstellung gespiegelt ist. Dort kann man sie sogar schreiben, jedoch hat das überhaupt keinen Einfluss - nach einer gewissen Zeit steht dort wieder der aktive Wert drin. Erst wenn man die "richtige" ID beschreibt, ändert sich der Wert aktiv und wird widerum auf die Kopie gespiegelt. Ich vermute, dass intern so eine Kopie gehalten wird, um ein "Abbrechen" der Änderung von Einstellungen über das Bedienfeld zu ermöglichen. (daran musste ich denken, weil das Schreiben ja erfolgreich ist - später aber doch der alte Wert wieder in der 470 steht)
b) Im 700 ist der "special function mode" in 2 Registern zu lesen: 00007400 kann gelesen und geschrieben werden, danach steht auch in 00007800 der aktuell gültige Modus (z.Bsp. QuickVeto oder Party). Das Schreiben des 00007800 führt jedoch nicht dazu, dass der Modus aktiviert wird... mit einer Ausnahme: ist ein SpecialMode aktiv, kann der 00007800 auf 0 gesetzt werden, um diesen Modus abzubrechen! Es kann also zum AUS- nicht aber zum EINschalten eines Modus benutzt werden.
(das hatte ich aber mit dem VRC700/1 getestet und dann nie wieder mit dem /2 oder /4 überprüft)
Also vor dem Hintergrund kann ich nur empfehlen, sämtliche andere Nachrichten für eine 470 nochmal zu prüfen (es gab mal irgendwo ein allregisters.sh von John!). Eventuell findet sich ja eine ID, die auch immer dem HwcOpMode entspricht und deren Schreiben mehr Erfolg bringt.
Viel Erfolg,
Sven
@hanske
schau bitte einmal ins Log nachdem du FHEM neu gestartet hast ob da irgendwelche Fehlermeldungen von der baixx.cfg kommen das er was nicht laden kann?
Ist das jetzt nur der eine Wert der über FHEM nicht geht oder alle?
LG
Hallo Rainer,
im FHEM log kommt keine Fehlermeldung bei shutdown restart.
Es funktioniert keine Abfrage über FHEM.
Allerdings habe ich im Gegensatz zum Wiki nicht für jeden Parameter ein eigenes ECMD Device erstellen müssen.
Ich kann mit einem ECMD Device über "get" auf alle in der .cfg Datei definierten Befehle zugreifen.
Leider funktionieren sie aber nicht.
Schöne Grüße
hanske
Zitat von: Sven77 am 29 Januar 2018, 12:38:24
Hi,
zur 700 gibt es ja leider keine offiziellen Datenbanken mehr. Alles was da drin steht, wurde von Usern durch try&error zusammengetragen.
...
Sinisa Mikulandra von der openhab community hat sehr viel zur multimatic 700 geforscht, seine aktuellen json configs (command files) dazu sind hier: https://community.openhab.org/t/ebus-2-0-configuration-support-contribution/35961/44
Christian Sowada (Developer vom openhab ebus binding) hat diese in seiner letzten dev-version schon drinnen: https://community.openhab.org/t/ebus-2-0-configuration-support-contribution/35961/50
bei mir läuft das ganze seit ein paar tagen sehr gut, bis auf ein paar troubles mit dem esera ebus adapter, aber da bin ich dran.
Zitat von: hanske am 29 Januar 2018, 19:05:05
Hallo Rainer,
im FHEM log kommt keine Fehlermeldung bei shutdown restart.
Es funktioniert keine Abfrage über FHEM.
Allerdings habe ich im Gegensatz zum Wiki nicht für jeden Parameter ein eigenes ECMD Device erstellen müssen.
Ich kann mit einem ECMD Device über "get" auf alle in der .cfg Datei definierten Befehle zugreifen.
Leider funktionieren sie aber nicht.
Schöne Grüße
hanske
das ist schon eine interessante Sache, wie sieht denn deine Definition des ECMD Device aus?
Versuche auch einmal ob du mit Telnet auf den eBus Port zugreifen kannst, dass du im ECMD Device definiert hast!
telnet ipadresse-ebus Port
telnet 192.168.0.10 8888kannst auch vom PC durchführen sofern du Telnet installiert hast.
LG
vielen dank! - das hilft mir weiter. :)
Hallo Rainer,
telnet ist vom PC aus möglich. Allerdings kann ich da keine Befehle absetzen oder was lesen. Es öffnet sich nur eine leere Konsole.
Ist das denn der gleiche Port wie der Http Port vom Wemos.
Ich benutze statt 8888 den Port 9999. Dort kann ich auch die Webseite vom Wemos erreichen. Was sollte ich da mit telnet sehen?
Grüße
Hallo
so wurden meine Geräte mal erkannt:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
JETZT werden meine Geräte so erkannt:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Und nichts verändert!
Es hilft kein shutdown restart, kein reboot. Ich kann die Versorgungsspannung nicht mal eben abschalten, denn die Anlage steht 3 Stunden Fahrzeit entfernt.
Wie kann ich es erzwingen, dass alle Geräte am Bus wieder erkannt werden und somit die cvs geladen werden.
Über das Terminal kann ich nur die jetzigen bekannten Werte abfragen.
Wer mag mir helfen?
Gruß
Zitat von: hanske am 30 Januar 2018, 08:36:08
Hallo Rainer,
telnet ist vom PC aus möglich. Allerdings kann ich da keine Befehle absetzen oder was lesen. Es öffnet sich nur eine leere Konsole.
Ist das denn der gleiche Port wie der Http Port vom Wemos.
Ich benutze statt 8888 den Port 9999. Dort kann ich auch die Webseite vom Wemos erreichen. Was sollte ich da mit telnet sehen?
Grüße
das passt, es muss lediglich ein schwarzes leeres Fenster kommen, dann steht die Telnet Verbindung auf dieses Port. Die Webseite ist aber ein anderes Port!
Eigentlich müsste die Verbindung dann mit FHEM klappen!
4. ebusd TCP/UDP mode: TCP
5. ebusd TCP port: 8889
7. Management TCP port: 9999Protokoll = TCP, das ebusd Port ist jenes wo du Telnet überpüfen solltest und das Management Port ist das Webif vom Wemos!
Wie hast du denn die ECMD Verbindung definiert?
Meine sieht so aus, 10.0.0.6 ist jene IP-Adresse vom Raspi wo der Dämon läuft. Wenn du Fhem und Ebus getrennt hast, dann ist das eben eine andere als Fhem.
define EBUS ECMD telnet 10.0.0.6:8888
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room VaillantBitte nicht verwechseln, das Port das du hier angibst hat nichts mit dem ebusd Port unter Punkt 5 zu tun! Das ist das Port auf welches der Dämon hört und wenn du unter /etc/default/ebusd -p nichts anderes eingestellt hast, ist das 8888! Der Wemos überträgt seine Daten über Port unter Punkt 5 zum Dämon und der Dämon überträgt die Daten zu Fhem über das definierte Port in der opts (-p) !
EBUSD_OPTS="-d 10.0.0.166:8889 -p 8888 -l /var/log/ebusd.log --scanconfig --address=ff"
LG
Hallo,
ich habe mir eine ebus-Platine V2 bestellt und bin etwas verunsichert wo ich diese jetzt genau bei meiner Therme (Vaillant VSC 126 C-140) anschließen muss.
Denn laut Beschreibung soll der ebus-Anschluss neben den Anschlüssen 7,8,9 liegen. Eine andere sagt wiederum, dies sei der Anschluss für ein Anlegethermostat.
Ich hänge mal ein Bild an von meiner Platine.
Vielen Dank im voraus :)
Das wird nicht der Anschluss für den eBus sein, es ist fatal wenn der Bus eine Brücke hätte.
Du hast aber einen X6, frag mal rum ob dort ein eBus vorhanden ist.
Hast Du eine Regelung an der Therme ? Dann ist die höchstwahrscheinlich mit zwei Adern mit der Therme verbunden. Diese beiden Adern sind der EBUS, zu dem du parallel anschließt.
An der Therme ist eine VRC 410 angeschlossen. Nur wo diese direkt auf dem Board angeschlossen ist, weiß ich ehrlich gesagt nicht.
Habe auch nur mal einen kurzen Blick riskiert.
Hänge mal die Platinenanschlussbelegung mit an
Beim VSC 146 scheint es lt. Installationsanleitung einen Stecker mehr zu geben - statt Anl.Therm und 7-8-9 gibt es dort Burner-Off, RT24V und Bus.
Kann es sein, dass der VSC 126 noch gar keinen eBus hatte?
Die passende VRC410 scheint jedenfalls auch eine reine Steuerung über 7-8-9 zu sein - da kann der eBus-Adapter dann wohl wenig ausrichten.
EDIT:
Es gibt offenbar einen (völlig überteuerten) Adapter: Vaillant VR 37 (https://www.heizungsdiscount24.de/regelungstechnik/vaillant-vr-37-zusatzmodul-ebus-adapter-an-vorhandenen-regler.html)
Zitat von: john30 am 15 Januar 2018, 13:49:59
Du musst einfach anstelle von "w -c quick load %temp\n" folgendes nehmen:
"w -c SLAVE load on\n"
und statt SLAVE vermutlich hwc nehmen.
Schau einfach mal, wie das bei Dir definiert ist mit "ebusctl find -w load".
Danke für deine Hilfe! Leider funktioniert es noch nicht. Es ergibt sich bei mir Folgendes:
Zitat
# ebusctl find -w load
mc load = off
Wenn ich diesen Befehl ausführe
Zitat
# ebusctl w -c mc load on
done
Danach erfolgt allerdings keine Warmwasserbereitung. :( Gibt es da noch irgendwelche Vorbedingungen?
Hallo Rainer,
ja super, jetzt geht es. :) :) :)
Ich wusste nicht, dass der Dämon seinen eigenen Port bereitstellt.
Ich dachte ich muss direkt die IP und den Port vom Wemos nehmen und FHEM kommuniziert irgendwie anders mit dem Dämon.
Ich glaube "TobiasR" hatte ein ähnliches Problem und dann aufgegeben.
Ich bin auf jeden Fall froh, dass es jetzt geht und kann erst mal ordentlich mitloggen.
Irgendwann muss ich dann nochmal raus kriegen wie ich die Speicherladung für Warmwasser aktiviere.
Vielen Dank für die Hilfe
Super wenn es läuft, für solche Fragen geben wir gerne Unterstützung weil die WLAN Geschichte mit dem eBus Neuland ist.
Aber wir brauchen immer etwas Information (Logs) damit wir in etwa wissen wo wir ansetzen müssen!
Aber ich glaube jetzt ist das alles soweit klar, warum es 2 Ports sind die kommunizieren. Der Dämon sitzt hier quasi in der Mitte und spielt Bridge, er empfängt von Port A (Wemos) und stellt es auf Port B an FHEM bereit. Das mag für manche Anwender etwas verwirrend klingen.
LG
Reinhart
Zitat von: Allodo am 31 Januar 2018, 13:06:24
An der Therme ist eine VRC 410 angeschlossen. Nur wo diese direkt auf dem Board angeschlossen ist, weiß ich ehrlich gesagt nicht.
Habe auch nur mal einen kurzen Blick riskiert.
Hänge mal die Platinenanschlussbelegung mit an
schade das ich den Post nicht früher gesehen habe, habe extra Vormittag noch die Platine gelötet, geprüft und getestet und das Paket heute auf der Post aufgegeben.
Aber wenn du keinen eBus hast, dann läßt sich die fertig gelötete Platine sicher weiter verkaufen, es gibt genug Leute die sehnsüchtig darauf warten.
LG
Ich nehme gerne noch eine Basisplatine bei der nächsten Rutsche (kein Wemos), mit Gehäuse und sehr gerne mit 5 Schrauben [emoji16].
Die erste läuft seit 3 Wochen wunderbar.
Vielen Dank, Andreas
Gesendet von iPad mit Tapatalk
Zitat von: ihatedenhasen am 30 Januar 2018, 13:02:09
Hallo
so wurden meine Geräte mal erkannt:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
JETZT werden meine Geräte so erkannt:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Und nichts verändert!
Es hilft kein shutdown restart, kein reboot. Ich kann die Versorgungsspannung nicht mal eben abschalten, denn die Anlage steht 3 Stunden Fahrzeit entfernt.
Wie kann ich es erzwingen, dass alle Geräte am Bus wieder erkannt werden und somit die cvs geladen werden.
Über das Terminal kann ich nur die jetzigen bekannten Werte abfragen.
Wer mag mir helfen?
Gruß
... zwischenzeitlich wurde kein Master mehr gescannt. Habe das System mal gestoppt und einige Tage so belassen. Nun habe ich wieder diesen Zustand, der 430 wird nicht mehr erkannt. Wenn ich mir die Vor- und Rücklauftemperaturen ansehe, läuft da keine Regelung mehr. Auch die Raumtemperaturen weichen von der Solltemperatur ab.
Wie kann ich noch Einfluss auf den eBus nehmen, damit der 430 wieder erkannt wird - ohne hinzufahren (3 Stunden Fahrzeit)?
das ist natürlich jetzt schwierig zu sagen, entweder kann die Platine die Calormatic nicht erkennen oder die Calormatic spinnt oder die Calormatic wird nicht gefunden weil die Platine angeklemmt ist und Fehler verursacht.
Nachdem aber die Therme selbst einwandfrei erkannt wird, nehme ich auch an die Platine funktioniert soweit. Kannst du denn im Log in dem Zeitraum des Ausfalles was ungewöhnliches sehen? Wann sind die Statusmeldungen ausgefallen oder sind die noch da? Wenn nein, dann ist auch die Calormatic ausgefallen, wenn ja dann läuft die Calormatic und wird nur von der Platine nicht erkannt.
Ein einfacher WLAN Schalter könnte dir jetzt gute Dienste tun um die Therme von der Ferne zu resetten. Es reicht aber auch schon ein guter Nachbar mit Schlüssel.
LG
Hallo zusammen,
Ich bin hier neu und habe auch versucht so viel wie möglich zu lesen .... aber ich komme nicht weiter....
Also stand der Dinge:
Ich habe eine Vaillant Heizung eco Tec plus und die Steuerung colorMatic 430
des weiteren habe ich eine Bausatz 1.6 ; Serieller Konverter
Das ganze habe ich angeschlossen an die Heizung mit "Klingeldraht"....
soweit so gut...
ich habe laut Wiki die Software installiert gelöscht und noch mal Installiert
nach der eingabe
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2018-02-02 15:14:07.475 [bus notice] bus started with own address 31/36
kommt nichts ... denke das ist ja richtig..
auf der 2 Konsole
pi@raspberrypi:~ $ sudo ebusctl raw
raw logging enabled
pi@raspberrypi:~ $
kommt nur das und sonst nichts .....
Ich denke es bestimmt schon irgendwo beschrieben ... man müsste es nur finden...
auf dem Raspy läuft...
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.3 (stretch)
Release: 9.3
Codename: stretch
Bin für jeden Tipp dankbar .... in der ebusd. log steht
2018-02-02 12:52:10.004 [main notice] SIGTERM received
2018-02-02 12:52:13.624 [main notice] ebusd stopped
2018-02-02 14:47:24.651 [main notice] ebusd 3.0.595c7c0 started
2018-02-02 14:47:24.712 [bus notice] bus started with own address 31/36
2018-02-02 14:49:28.904 [main notice] update check: version 3.1 available, broadcast.csv: different version available
2018-02-02 14:52:13.094 [main notice] SIGTERM received
2018-02-02 14:52:14.245 [main notice] ebusd stopped
Hallo zusammen,
ich bräuchte mal die Einschätzung eines Wissenden, ob meine eBusD-Installation richtig funktioniert. Ich denke, dass alle Geräte gefunden werden aber trotzdem kann nur recht wenige Werte auslesen.
Meine Anlage besteht aus
- Regelsystem auroMatic 620
- Brenner ecoTEC VC DE 146
- Puffer allSTOR
- Solarladestation VPM 20 S
- Trinkwasserstation VPM 20/25 W
Es werden 2 Heizkreise (Fussboden und Wandheizkörper) versorgt.
Ein "ebusctl info" liefert
version: ebusd 3.1.v3.0-35-gb0e20b7
update check: revision v3.1-1-g60a18d1 available, broadcast.csv: newer version available, vaillant/06.pms.csv: newer version available, vaillant/08.bai.csv: newer version available, vaillant/0a.pmw.hwc.csv: newer version available, vaillant/15.ui.csv: newer version available, vaillant/26.solsy.hc.csv: newer version available, vaillant/50.solsy.mc.csv: newer
signal: acquired
symbol rate: 46
max symbol rate: 151
min arbitration micros: 989
max arbitration micros: 2509
min symbol latency: 5
max symbol latency: 7
reconnects: 0
masters: 5
messages: 826
conditional: 27
poll: 0
update: 8
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0602;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
wobei ich die Hinweise auf die veralteten cv-Dateien nicht verstehe, da ich heute die Konfiguration "ebusd-configuration-2.1.b143f39-de_all.tgz" von GitHub gezogen und installiert habe.
Um alle gefüllten Werte anzuzeigen führe ich "ebusctl find -d -v" aus:
bai HwcTempDesired = (ERR: invalid position for 3108b509030dea03 / 00)
bai Mode = mode=standby
bai PartloadHcKW = (ERR: invalid position for 3108b509030d0704 / 00)
bai Status01 = temp1=59.5;temp1=59.5;temp2=-;temp1=-;temp1=-;pumpstate=off
bai StorageTemp = temp=-14.94;sensor=cutoff
bai WaterPressure = press=1.514;sensor=ok
broadcast datetime = outsidetemp=0.062;time=20:09:04;date=02.02.2018
broadcast outsidetemp = temp2=0.062
broadcast vdatetime = time=20:09:04;date=02.02.2018
hc currenterror = error=-;error=-;error=-;error=-;error=-
hc DateTime = dcfstate=ok;btime=20:08:54;bdate=02.02.2018;temp2=0.062
hc OutsideTemp = temp=1.31;sensor=ok
hc SumFlowSensor = temp=50.44;sensor=ok
hwc currenterror = error=-;error=-;error=-;error=-;error=-
hwc Mode = temp0=50;hwcmode=auto;=00;onoff=off
hwc Status = temp0=67;onoff=on;temp=-;temp0=50
mc Mode = temp0=20;mcmode=auto;=05;onoff=off
mc Status = temp0=32;onoff=off;temp=33.94;temp0=20
pms SolarYieldCurrentDay = energy=0
scan.06 = MF=Vaillant;ID=PMS00;SW=0107;HW=4302
scan.06 id = prefix=21;year=12;week=46;product=0020071488;supplier=3110;counter=007842;suffix=N1
scan.08 = MF=Vaillant;ID=BAI00;SW=0602;HW=5502
scan.08 id = prefix=21;year=13;week=42;product=0010011640;supplier=0001;counter=007894;suffix=N9
scan.0a = MF=Vaillant;ID=PMW00;SW=0117;HW=4402
scan.0a id = prefix=21;year=12;week=45;product=0010007267;supplier=3110;counter=009062;suffix=N0
scan.12 = MF=Vaillant;ID=PMW00;SW=0117;HW=4402
scan.12 id = prefix=21;year=12;week=45;product=0010007267;supplier=3110;counter=009062;suffix=N0
scan.15 = MF=Vaillant;ID=UI ;SW=0507;HW=6201
scan.15 id = prefix=21;year=13;week=41;product=0020080465;supplier=0907;counter=010840;suffix=N9
scan.26 = MF=Vaillant;ID=SOLSY;SW=0500;HW=6301
scan.26 id = prefix=21;year=13;week=41;product=0020080463;supplier=0907;counter=009771;suffix=N9
scan.50 = MF=Vaillant;ID=SOLSY;SW=0500;HW=6301
scan.50 id = prefix=21;year=13;week=41;product=0020080463;supplier=0907;counter=009771;suffix=N9
scan.ec = MF=Vaillant;ID=SOLSY;SW=0500;HW=6301
scan.ec id = prefix=21;year=13;week=41;product=0020080463;supplier=0907;counter=009771;suffix=N9
scan.ed = MF=Vaillant;ID=PMS00;SW=0107;HW=4302
scan.ed id = prefix=21;year=12;week=46;product=0020071488;supplier=3110;counter=007842;suffix=N1
scan.fc = MF=Vaillant;ID=PMW00;SW=0117;HW=4402
scan.fc id = prefix=21;year=12;week=45;product=0010007267;supplier=3110;counter=009062;suffix=N0
ui BoilerCount = =1
ui BoilerSwitchSteps = =1
ui DesiredStateB1 = =off/auto
ui StorageSensorBottom = temp=48.69
ui StorageSensorMiddle = temp=59.00
ui StorageSensorTop = temp=68.75Die Anzahl der gefundenen Wert kommt mir recht gering vor. Wie z.B. kann ich daraus erkennen ob der Kessel gerade heizt? Auch Daten zur Solarladestation scheinen nicht dabei zu sein, oder?
Hat jemand Tipps, was ich noch tun kann?
Schon mal vielen Dank!
@h.urmel
du hat leider nicht beschrieben wie du installiert hast, selber compiliert oder vom Github oder ...
aber hast du denn überhaupt die /etc/default/ebusd konfiguriert?
Wenn ja, warum startest du aus der Konsole, jedesmal wenn du die schließt kommt dann im Log Sigterm. Lese dir bitte die Einrichtung nochmals durch und vor allem wie man den Dienst dann startet!
du kannst ja einmal folgendes versuchen (aber erst nach der Konfiguration von /etc/default/ebusd) :
cd /etc/init.d
sudo ./ebusd start
das sollte dann auf jeden Fall den Dämon starten, egal ob du ihn schon als Service eingerichtet oder nicht. Und dann schau mal was
ebusctl info
in der Konsole ausgibt, eventuell 2 x wiederholen.
LG
Zitat von: yazo am 02 Februar 2018, 20:14:43
Die Anzahl der gefundenen Wert kommt mir recht gering vor. Wie z.B. kann ich daraus erkennen ob der Kessel gerade heizt? Auch Daten zur Solarladestation scheinen nicht dabei zu sein, oder?
Wieso gering? Hast du überhaupt schon was abgefragt? Es kommen ja nur jene Werte über den Bus die entweder der Broadcast liefert oder weil sich gerade angeschlossenen Geräte miteinander unterhalten und Daten austauschen.
Du musst schon deine gewünschten Werte aktiv abfragen dann bekommst du auch eine Antwort!
Also eine baixx.cfg anlegen, die Abfragen definieren, in Fhem konfigurieren und so weiter, die ganze Palette durch so wie es alle andern auch durchführen. Soweit ich lese erwartest du vom eBus das er dir ständig alles sendet was es so an Messdaten gibt, so ist das leider nicht. Im Prinzip verhält sich der passiv und gibt nur Auskunft wenn du was willst.
Soweit ich sehe funktioniert ja dein Adapter und hat jede Menge an CSV geladen. Ich schätze du wirst ein paar Hundert Daten abfragen können.
LG
Reinhart
Zitat von: Reinhart am 02 Februar 2018, 20:52:06
Wieso gering? Hast du überhaupt schon was abgefragt? Es kommen ja nur jene Werte über den Bus die entweder der Broadcast liefert oder weil sich gerade angeschlossenen Geräte miteinander unterhalten und Daten austauschen.
Du musst schon deine gewünschten Werte aktiv abfragen dann bekommst du auch eine Antwort!
Also eine baixx.cfg anlegen, die Abfragen definieren, in Fhem konfigurieren und so weiter, die ganze Palette durch so wie es alle andern auch durchführen.
Hi Reinhart,
danke für die schnelle Antwort. Du hast völlig recht. Ich habe die FHEM-Seite der Geschichte noch nicht begonnen, weil ich zunächst herausfinden will, ob die ebusd-Installation funktioniert und welche Werte ich abfragen kann.
Zitat von: Reinhart am 02 Februar 2018, 20:52:06
Soweit ich lese erwartest du vom eBus das er dir ständig alles sendet was es so an Messdaten gibt, so ist das leider nicht.
Aber wäre das nicht schön, wenn es so einfach wäre? :-) ... nein - Spaß beiseite: die Abfrage der Werte funktioniert doch über "ebusctl read -f ....", oder? Das habe ich mit vielen der Werte in den eingelesenen csv-Dateien probiert aber immer eine Fehlermeldung "ERR: Element not found" erhalten.
Auf der anderen Seite habe ich eine zentrale Steuereinheit (die auroMATIC) die ja alle Daten anzeigt - insofern müssen sie auch irgendwie über den Bus gekommen sein - und sei es als Broadcast.
Das hat mich eben auf die Idee gebracht mal im Forum zu fragen, ob die Kombination aus Geräten und CSV-Dateinen, wie sie bei mir geladen werden, Sinn macht oder ob da was vermurkst ist.
Ich werde mich also weiter den CSVs widmen und Wert für Wert abklappern. Vielleicht könnte mir aber trotzdem jemand einen Tip geben welchen Wert man für den Brennerstatus (also ob der Kessel gerade feuert oder nicht) abfragen kann.
Viele Grüße
Yazo
Zitat von: ihatedenhasen am 01 Februar 2018, 18:09:11
... zwischenzeitlich wurde kein Master mehr gescannt. Habe das System mal gestoppt und einige Tage so belassen. Nun habe ich wieder diesen Zustand, der 430 wird nicht mehr erkannt. Wenn ich mir die Vor- und Rücklauftemperaturen ansehe, läuft da keine Regelung mehr. Auch die Raumtemperaturen weichen von der Solltemperatur ab.
Wie kann ich noch Einfluss auf den eBus nehmen, damit der 430 wieder erkannt wird - ohne hinzufahren (3 Stunden Fahrzeit)?
Schau doch mal in das Logfile von ebusd. Dort kannst Du z.B. erkennen, ob der 430 überhaupt noch was auf den Bus sendet. Ich vermute dass nicht... Alternativ könnte er auch einfach nicht mehr auf den Scan reagieren. Probier mal ein "scan 15", um zu sehen ob er noch willig ist.
... leider zu spät. Habe im Raspbian einen shutdown durchgeführt, damit ein definierter Zustand für die Abschaltung der Versorgungsspannung vorhanden ist. Leider hängt der raspi mit Platine mit an der Sicherung der Therme.
@yazo
ev. sind Deine Lesebefehle nicht korrekt. Läuft der Brenner?
read -f -c bai SDFlame
Achtung: prüfe in Deiner csv, bin noch auf einer urversion.
Edit: wie alt ist Deine Trinkwasserstation? Meine hat nur eine RS232
ist eine Therme mit DLH. Die Therme heizt, das merke ich an der Raumtemperatur, nur leider nicht mehr nach einer Heizkurve. Das konnte ich Anhand der Vorlauftemperatur feststellen. Muss jetzt das Schalten der Sicherung abwarten.
Zitat von: jkriegl am 03 Februar 2018, 12:37:45
@yazo
ev. sind Deine Lesebefehle nicht korrekt. Läuft der Brenner?
read -f -c bai SDFlame
Achtung: prüfe in Deiner csv, bin noch auf einer urversion.
Hi jkriegl,
jetzt hast Du was gesagt. :o Ich habe zum Durchprobieren der einzelnen Werte mit "read" in die bai.308523.inc reingesehen, die auf GitHub im master branch (ebusd-configuration/ebusd-2.1.x/de/vaillant/) liegt (heist das so) - also die aktuelle Version. Installiert ist aber die letzte gepackte Version vom ebusd-configuration repository. John30 hat da im November die SD-Präfixe entfernt. Mit "SDFlame" kann ich den Brennerstatus einwandfrei abfragen. Mit "Flame", wie in der aktuellen bai natürlich nicht. Da hätte ich natürlich drauf kommen können, dass es auch bei der config stabile und Arbeitsversionen gibt!! :-[
Das erklärt vermutlich auch, warum "info" sagt, dass es zu mehreren .csv-Dateien neue Versionen gibt.
Zitat von: jkriegl am 03 Februar 2018, 12:37:45
Edit: wie alt ist Deine Trinkwasserstation? Meine hat nur eine RS232
Die Trinkwasserstation wurde vor 4 Jahren eingebaut und hat eBus ... also zumindest eine zweipolige Klemme an der "eBus" steht ... man weiß ja nie :D .
Vielen Dank für die guten Tipps - ich denke so komme ich weiter!
Viele Grüße,
Yazo
Hallo,
ich habe für meine Heizung mit VRC 700 die Brennstoffverbrauchsdaten vermisst und habe meine 15.700.csv von ebusd etwas erweitert, jetzt werden die auch angezeigt.
Zeile 27-33 durch diese Zeilen ersetzen.
r;w,,PrFuelSumHcThisMonth,ThisMonthsFConsumptionHc,,,,4E00,,,energy4,,,Aktueller Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcThisMonth,ThisMonthsEConsumptionHc,,,,4F00,,,energy4,,,Aktueller Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcThisMonth,ThisMonthsEConsumptionHwc,,,,5000,,,energy4,,,Aktueller Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcThisMonth,ThisMonthsFConsumptionHwc,,,,5100,,,energy4,,,Aktueller Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHcLastMonth,LastMonthsFConsumptionHc,,,,5200,,,energy4,,,Letzter Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcLastMonth,LastMonthsEConsumptionHc,,,,5300,,,energy4,,,Letzter Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcLastMonth,LastMonthsEConsumptionHwc,,,,5400,,,energy4,,,Letzter Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcLastMonth,LastMonthsFConsumptionHwc,,,,5500,,,energy4,,,Letzter Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHc,TotalFConsumptionHc,,,,5600,,,energy4,,,Brennstoffverbrauch Heizung gesamt
r;w,,PrEnergySumHc,TotalEConsumptionHc,,,,5700,,,energy4,,,Stromverbrauch Heizung gesamt
r;w,,PrEnergySumHwc,TotalEConsumptionHwc,,,,5800,,,energy4,,,Stromverbrauch Warmwasser gesamt
r;w,,PrFuelSumHwc,TotalFConsumptionHwc,,,,5900,,,energy4,,,Brennstoffverbrauch Warmwasser gesamt
r;w,,PrEnergySum,TotalEConsumption,,,,5C00,,,energy4,,,Dieses Jahr Stromverbrauch gesamt
r;w,,PrFuelSum,TotalFConsumption,,,,5D00,,,energy4,,,Dieses Jahr Brennstoffverbrauch gesamt
Gruß Paul
Paul79,
Du hast eine sogenannte "exclusive" Anlage? Bei mir kommt da nichts.
Gruß,
Dietmar
Zitat von: mirror am 03 Februar 2018, 21:26:20
Paul79,
Du hast eine sogenannte "exclusive" Anlage? Bei mir kommt da nichts.
Gruß,
Dietmar
Das weiß ich nicht die Anlage ist 2 Monate alt und frage das ganze mit MQTT ab siehe Bild, hast du auch den ebusd restartet?
Meine Anlagedaten
address 00: master #1
address 03: master #11
address 05: slave #1, scanned "MF=Vaillant;ID=COM00;SW=0902;HW=3103"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0204;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
So, Sicherung wurde geschaltet. Ergebnis, wie erwartet:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0414;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004289']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0136;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Alles wieder gut.
Zitat von: Reinhart am 01 Februar 2018, 18:44:18
Kannst du denn im Log in dem Zeitraum des Ausfalles was ungewöhnliches sehen? Wann sind die Statusmeldungen ausgefallen oder sind die noch da? Wenn nein, dann ist auch die Calormatic ausgefallen, wenn ja dann läuft die Calormatic und wird nur von der Platine nicht erkannt.
Hier die Anfänge des Ausfalls, hilft das?
2018.01.29 12:32:29 1: EBUS: unexpected answer ERR: generic device error\n\n (\105\122\122\072\040\147\145\156\145\162\151\143\040\144\145\166\151\143\145\040\145\162\162\157\162\012\012) received (wrote r -f flowtemp temp\n (\162\040\055\146\040\146\154\157\167\164\145\155\160\040\164\145\155\160\012), expected \d+\.\d+\n\n)
2018.01.29 12:32:29 1: PERL WARNING: Argument "ERR: generic device error\n\n" isn't numeric in sprintf at (eval 26265) line 1.
2018.01.29 12:32:29 3: eval: { sprintf("%5.1f",$_) }
2018.01.29 12:32:32 2: EBUS: first attempt to read timed out, trying to close and open the device.
2018.01.29 12:32:32 3: Opening EBUS device 192.168.94.27:8888
2018.01.29 12:32:32 3: EBUS device opened
2018.01.29 12:32:35 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2018.01.29 12:32:35 1: EBUS: no answer received (wrote r -f ReturnTemp temp\n (\162\040\055\146\040\122\145\164\165\162\156\124\145\155\160\040\164\145\155\160\012), expected \d+\.\d+\n\n)
2018.01.29 12:32:35 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 26267) line 1.
2018.01.29 12:32:35 3: eval: { sprintf("%5.1f",$_) }
2018.01.29 12:32:38 2: EBUS: first attempt to read timed out, trying to close and open the device.
2018.01.29 12:32:38 3: Opening EBUS device 192.168.94.27:8888
2018.01.29 12:32:38 3: EBUS device opened
2018.01.29 12:32:41 2: EBUS: second attempt to read timed out, this is an unrecoverable error.
2018.01.29 12:32:41 1: EBUS: no answer received (wrote r -f fanspeed\n (\162\040\055\146\040\146\141\156\163\160\145\145\144\012), expected \d+\n\n)
2018.01.29 12:32:41 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 26269) line 1.
2018.01.29 12:32:41 3: eval: { sprintf("%5.0f",$_) }
2018.01.29 12:32:44 2: EBUS: first attempt to read timed out, trying to close and open the device.
2018.01.29 12:32:44 3: Opening EBUS device 192.168.94.27:8888
2018.01.29 12:32:44 3: EBUS device opened
Zitat von: paul79 am 03 Februar 2018, 22:57:22
Das weiß ich nicht die Anlage ist 2 Monate alt und frage das ganze mit MQTT ab siehe Bild, hast du auch den ebusd restartet?
Meine Anlage ist baugleich - aber älter, insbesondere die Multimatic:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0116;HW=9602", loaded "bai.0010015600.inc" ([PROD='0010015600']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0206;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Ich habe nur die Einträge aus der 15.700.csv ausprobiert, die schon drin waren. Und die gehen nicht bei mir. Wir hatten das schon mal in diesem Thread vor längerer Zeit.
Auch am Gerät zeigen die Werte bei mir 0 oder Unsinn an.
Gruß,
Dietmar
@ihatedenhasen
so einfach kann man das jetzt nicht sagen wo der Fehler liegt, es wird auf jeden Fall die Verbindung zum Dämon über die IP 192.168.94.27 unterbrochen und das 3 Sekunden nachdem FHEM einen Reconnect erfolgreich aufgebaut hat.
Du könntest jetzt versuchen in den Systemlogs nachzuschauen ob du da was entdeckst das dir einen weiteren Hinweis gibt, von irgendwo muss die Unterbrechung ja herkommen.
Wer ist den 192.168.94.27? Ist das eine WLAN oder Lan Verbindung zwischen FHEM und Raspberry?
LG
Hallo Reinhart , hallo zusammen
Also ich habe mir das Tool " eBus_Installer_Fhem" runter geladen und gestartet, danach habe ich wie in der Wiki beschrieben
service ebusd stop
Bus gestoppt,
dann dachte ich das ich ihn so wieder starte
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2 Konsole
ebusctl raw
und gewartet das ich etwas sehe um das potie abzugleichen .... >:( >:( >:( >:(
Dann hab ich nach der Wiki Anleitung Deinstalliert
sudo dpkg -r --force-overwrite ebusd-configuration
sudo dpkg -r --force-overwrite ebusd
dpkg -l | grep 'ebusd'
Danach neu Installiert nach Wiki
https://github.com/john30/ebusd/releases/download/v3.0/ebusd-3.0_armhf.deb
aber nur den eBus und dann wieder versucht den Poti abzustimmen
Nur noch mal zur Sicherheit :
der Poti an der Platine kann um 360° gedreht werden...
Auch wenn an der Heizung Plus/ Minus angegeben wird, an der Platine ist es egal.
ebusctl info kommt das ...
pi@raspberrypi:/etc/systemd/system $ ebusctl info
version: ebusd 3.0.595c7c0
update check: version 3.1 available, broadcast.csv: different version available
signal: no signal
reconnects: 0
masters: 1
messages: 10
conditional: 0
poll: 0
update: 7
address 31: master #8, ebusd
address 36: slave #8, ebusd
Unter
cd /etc/init.d
sudo ./ebusd start
ist nichts eingetragen und ich dachte der Ebus wird mit gestartet und gestopt
service ebusd start
service ebusd stop
der Rest wir in der Wiki später wegen Autosart beschrieben, doch soweit bin ich nicht gekommen ...hänge bei Poti abgleich
Zitat von: h.urmel am 04 Februar 2018, 13:36:57
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
ebusctl raw
das ist mit ebusd 3.0 nicht mehr ganz richtig. Verwende sstattdessen:
ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0 --lograwdata=bytesund lass die zweite Console eifnach weg. Dann sollten schon die Zeilen mit "<aa" oder was auch immer rauskommen.
Busanschluss passt, der ist verpolungssicher.
Hallo John,
Danke für den Hinweis... jetzt bin ich etwas schlauer :( und habe neue fragen...
Ich war an der Heizung nach der ersten Installation mit dem Skript "eBus_Installer_Fhem" hatte ich an dem USB/Seriall Teil 2 grüne und eine rote LED leuchten jetzt leuchte nur noch die rot ....
wenn ich da Buskabel oder das USB Kabel löse gehen die grünen LED's kurz an und die Konsole zeigt ... ansonsten passiert nichts, egal wie langsam ich am Poti drehen.
pi@raspberrypi:/etc/systemd/system $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0 --lograwdata=bytes
2018-02-04 14:05:26.745 [bus notice] bus started with own address 31/36
2018-02-04 14:05:54.544 [bus notice] <00
2018-02-04 14:05:54.544 [bus notice] signal acquired
2018-02-04 14:05:56.041 [bus error] signal lost
2018-02-04 14:07:26.634 [bus notice] <00
2018-02-04 14:07:26.634 [bus notice] signal acquired
2018-02-04 14:07:27.247 [bus notice] <00
2018-02-04 14:07:27.992 [bus notice] <60
2018-02-04 14:07:27.996 [bus notice] <00
2018-02-04 14:07:29.029 [bus error] signal lost
2018-02-04 14:07:36.718 [bus notice] <00
2018-02-04 14:07:36.719 [bus notice] signal acquired
2018-02-04 14:07:36.726 [bus notice] <10
2018-02-04 14:07:36.741 [bus notice] <00
2018-02-04 14:07:36.806 [bus notice] <00
2018-02-04 14:07:37.203 [bus notice] <f8
2018-02-04 14:07:37.230 [bus notice] <00
2018-02-04 14:07:37.313 [bus notice] <00
2018-02-04 14:07:39.017 [bus error] signal lost
2018-02-04 14:07:39.096 [bus notice] <00
2018-02-04 14:07:39.096 [bus notice] signal acquired
2018-02-04 14:07:39.156 [bus notice] <02
2018-02-04 14:07:39.160 [bus notice] <00
2018-02-04 14:07:39.176 [bus notice] <03
2018-02-04 14:07:39.179 [bus notice] <00
2018-02-04 14:07:39.680 [bus notice] <00
2018-02-04 14:07:41.023 [bus error] signal lost
2018-02-04 14:07:45.166 [bus notice] <00
2018-02-04 14:07:45.167 [bus notice] signal acquired
2018-02-04 14:07:45.203 [bus notice] <00
2018-02-04 14:07:47.011 [bus error] signal lost
2018-02-04 14:08:25.295 [bus notice] <07
2018-02-04 14:08:25.296 [bus notice] signal acquired
2018-02-04 14:08:25.299 [bus notice] <00
2018-02-04 14:08:25.302 [bus notice] <fe
2018-02-04 14:08:26.697 [bus notice] <00
2018-02-04 14:08:28.040 [bus error] signal lost
2018-02-04 14:08:28.428 [bus notice] <00
2018-02-04 14:08:28.428 [bus notice] signal acquired
2018-02-04 14:08:28.635 [bus notice] <fe
2018-02-04 14:08:28.689 [bus notice] <f0
2018-02-04 14:08:28.751 [bus notice] <00
2018-02-04 14:08:28.824 [bus notice] <00
2018-02-04 14:08:30.011 [bus error] signal lost
2018-02-04 14:08:48.300 [bus notice] re-opened /dev/ttyUSB0
2018-02-04 14:08:54.302 [bus notice] <00
2018-02-04 14:08:54.302 [bus notice] signal acquired
2018-02-04 14:08:56.006 [bus error] signal lost
2018-02-04 14:08:57.288 [bus notice] <00
2018-02-04 14:08:57.289 [bus notice] signal acquired
2018-02-04 14:08:59.044 [bus error] signal lost
2018-02-04 14:09:03.720 [bus notice] <00
2018-02-04 14:09:03.721 [bus notice] signal acquired
2018-02-04 14:09:03.980 [bus notice] <00
2018-02-04 14:09:05.013 [bus error] signal lost
2018-02-04 14:09:07.262 [bus notice] <00
2018-02-04 14:09:07.263 [bus notice] signal acquired
2018-02-04 14:09:09.019 [bus error] signal lost
2018-02-04 14:09:20.466 [bus notice] <00
2018-02-04 14:09:20.467 [bus notice] signal acquired
2018-02-04 14:09:22.016 [bus error] signal lost
2018-02-04 14:09:28.081 [bus notice] <80
2018-02-04 14:09:28.081 [bus notice] signal acquired
2018-02-04 14:09:28.090 [bus notice] <00
2018-02-04 14:09:29.351 [bus notice] <00
2018-02-04 14:09:29.576 [bus notice] <00
2018-02-04 14:09:30.170 [bus notice] <00
2018-02-04 14:09:30.400 [bus notice] <00
2018-02-04 14:09:31.572 [bus notice] <00
2018-02-04 14:09:31.837 [bus notice] <7f
2018-02-04 14:09:31.842 [bus notice] <fc
2018-02-04 14:09:32.602 [bus notice] <00
2018-02-04 14:09:33.586 [bus notice] <00
2018-02-04 14:09:34.007 [bus notice] <00
2018-02-04 14:09:36.021 [bus error] signal lost
2018-02-04 14:10:00.155 [bus notice] <5f
2018-02-04 14:10:00.155 [bus notice] signal acquired
2018-02-04 14:10:00.159 [bus notice] <00
2018-02-04 14:10:02.018 [bus error] signal lost
2018-02-04 14:10:02.801 [bus notice] <00
2018-02-04 14:10:02.801 [bus notice] signal acquired
2018-02-04 14:10:04.041 [bus error] signal lost
2018-02-04 14:10:05.309 [bus notice] <00
2018-02-04 14:10:05.309 [bus notice] signal acquired
2018-02-04 14:10:07.013 [bus error] signal lost
2018-02-04 14:10:13.329 [bus notice] <00
2018-02-04 14:10:13.330 [bus notice] signal acquired
2018-02-04 14:10:14.559 [bus notice] <00
2018-02-04 14:10:15.048 [bus notice] <00
2018-02-04 14:10:15.107 [bus notice] <00
2018-02-04 14:10:15.878 [bus notice] <00
2018-02-04 14:10:16.063 [bus notice] <00
2018-02-04 14:10:16.071 [bus notice] <fe
2018-02-04 14:10:16.108 [bus notice] <00
2018-02-04 14:10:18.019 [bus error] signal lost
2018-02-04 14:10:48.105 [bus notice] re-opened /dev/ttyUSB0
2018-02-04 14:11:12.916 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2018-02-04 14:11:22.917 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2018-02-04 14:11:32.917 [bus error] unable to open /dev/ttyUSB0: ERR: element not found
2018-02-04 14:11:42.920 [bus notice] re-opened /dev/ttyUSB0
2018-02-04 14:13:02.721 [bus notice] <02
2018-02-04 14:13:02.722 [bus notice] signal acquired
2018-02-04 14:13:02.726 [bus notice] <00
2018-02-04 14:13:04.017 [bus error] signal lost
Zitat von: h.urmel am 04 Februar 2018, 14:29:10
Ich war an der Heizung nach der ersten Installation mit dem Skript "eBus_Installer_Fhem" hatte ich an dem USB/Seriall Teil 2 grüne und eine rote LED leuchten jetzt leuchte nur noch die rot ....
wenn ich da Buskabel oder das USB Kabel löse gehen die grünen LED's kurz an und die Konsole zeigt ... ansonsten passiert nichts, egal wie langsam ich am Poti drehen.
pi@raspberrypi:/etc/systemd/system $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0 --lograwdata=bytes
2018-02-04 14:05:26.745 [bus notice] bus started with own address 31/36
2018-02-04 14:05:54.544 [bus notice] <00
also da hast du noch heftige Probleme, das Poti ist entweder "meilenweit" vom richtigen Punkt entfernt, oder etwas anderes ist ganz im argen.
Was am meisten irritiert:
Zitat
unable to open /dev/ttyUSB0: ERR: element not found
Hast Du da den USB2Serial abgeklemmt?
ZitatNur noch mal zur Sicherheit :
der Poti an der Platine kann um 360° gedreht werden...
Das kannst du sogar mehrfach um 360 Grad drehen, das ist ja ein Spindeltrimmer und geht mindestens 20x. Aber vorsichtig, nicht überdrehen wenn es dann leicht knackt.
LG
Zitat von: john30 am 04 Februar 2018, 14:37:10
also da hast du noch heftige Probleme, das Poti ist entweder "meilenweit" vom richtigen Punkt entfernt, oder etwas anderes ist ganz im argen.
Was am meisten irritiert: Hast Du da den USB2Serial abgeklemmt?
ja da habe ich das Kabel gegen ein anders getauscht.......
...also noch mal zum Poti ... ich drehe meist rechts rum und haben bisher noch keine Widerstand gespürt ..... also bin ich davon ausgegangen das es endlos ist und immer wieder (nach 360°) bei null anfängt ..
Gruß Frank :-[ :-\
Zitat von: h.urmel am 04 Februar 2018, 14:49:10
...also noch mal zum Poti ... ich drehe meist rechts rum und haben bisher noch keine Widerstand gespürt ..... also bin ich davon ausgegangen das es endlos ist und immer wieder (nach 360°) bei null anfängt ..
hm, das klingt als wärs schon hinüber. ist mir leider auch mal passiert und damit war der Trimmer am Ende und unbrauchbar. Ich fürchte, das Problem hast Du jetzt auch...
@john30: Kannst du mir bezüglich meiner Frage aus Post #2574 eventuell noch einen Tipp geben?
:-\
mmm also Poti kaputt ... kann man noch irgendwie das Teil prüfen...
wenn ich das dBus Kabel abschrauben und wider fest mache passiert etwas auf der Konsole ...
018-02-04 14:59:53.380 [bus notice] <80
2018-02-04 14:59:53.380 [bus notice] signal acquired
2018-02-04 14:59:55.032 [bus error] signal lost
2018-02-04 14:59:59.037 [bus notice] <00
2018-02-04 14:59:59.037 [bus notice] signal acquired
2018-02-04 14:59:59.135 [bus notice] <00
2018-02-04 15:00:01.046 [bus error] signal lost
2018-02-04 15:00:22.304 [bus notice] <fe
2018-02-04 15:00:22.304 [bus notice] signal acquired
2018-02-04 15:00:24.013 [bus error] signal lost
2018-02-04 15:00:36.304 [bus notice] <00
2018-02-04 15:00:36.304 [bus notice] signal acquired
2018-02-04 15:00:38.008 [bus error] signal lost
2018-02-04 15:01:09.566 [bus notice] <00
2018-02-04 15:01:09.567 [bus notice] signal acquired
2018-02-04 15:01:11.012 [bus error] signal lost
2018-02-04 15:01:11.111 [bus notice] <00
2018-02-04 15:01:11.111 [bus notice] signal acquired
2018-02-04 15:01:11.387 [bus notice] <00
2018-02-04 15:01:12.069 [bus notice] <00
2018-02-04 15:01:12.310 [bus notice] <00
2018-02-04 15:01:12.610 [bus notice] <00
2018-02-04 15:01:14.004 [bus error] signal lost
2018-02-04 15:01:14.252 [bus notice] <00
2018-02-04 15:01:14.252 [bus notice] signal acquired
2018-02-04 15:01:14.383 [bus notice] <00
2018-02-04 15:01:15.056 [bus notice] <00
2018-02-04 15:01:17.018 [bus error] signal lost
2018-02-04 15:01:19.302 [bus notice] <fc
2018-02-04 15:01:19.303 [bus notice] signal acquired
und die 2 grünen LED an ftdi usb/serial flackern....
Danke für die Hilfe... :)
Zitat von: h.urmel am 04 Februar 2018, 15:11:02
mmm also Poti kaputt ... kann man noch irgendwie das Teil prüfen...
ja, einfach mal den Widerstand messen (ohne dass eBUS oder UART dran hängen), drehen und schauen ob sich der Widerstand ändert.
Zitat von: vwsuser am 04 Februar 2018, 15:07:49
@john30: Kannst du mir bezüglich meiner Frage aus Post #2574 eventuell noch einen Tipp geben?
#2574 ist ja schon gefühlt Jahre her :)
Zitat von: vwsuser am 31 Januar 2018, 16:10:07
Danach erfolgt allerdings keine Warmwasserbereitung. :( Gibt es da noch irgendwelche Vorbedingungen?
Die wird so oder so m.W. nur gestartet, wenn es auch wirklich Bedarf gibt. Aber kann auch sein, dass Deine Anlage die Nachricht ignoriert.
Zitat von: h.urmel am 04 Februar 2018, 15:11:02
:-\
mmm also Poti kaputt ... kann man noch irgendwie das Teil prüfen...
wenn ich das dBus Kabel abschrauben und wider fest mache passiert etwas auf der Konsole ...
und die 2 grünen LED an ftdi usb/serial flackern....
so wie John geschrieben hat, kannst du das Poti prüfen, aber wenn beide Leds flackern bist du nicht mehr weit weg mit der Einstellung. Es kommt allerdings noch 00 anstatt aa.
Ich habe gesehen du hast auch die V2 bestellt, wird vermutlich dieser Grund sein! Mit dem Poti haben sich einige Leute die Zähne ausgebissen, aber die meisten haben es letztlich geschafft es abzustimmen.
LG
Zitat von: john30 am 04 Februar 2018, 15:37:24
#2574 ist ja schon gefühlt Jahre her :)
Die wird so oder so m.W. nur gestartet, wenn es auch wirklich Bedarf gibt. Aber kann auch sein, dass Deine Anlage die Nachricht ignoriert.
Danke für die Info! Ja, es hat leider etwas gedauert. Ein Temperaturfühler der Wärmepumpe war defekt und deshalb kam ich nicht gleich dazu. ;-)
OK, also auch wenn die Nachricht mit "done" quittiert wird, könnte es prinzipiell sein, dass die Wärmepumpe diese ignoriert? Ich werde es noch mal versuchen, wenn wieder Warmwasserbedarf besteht.
Hat eventuell noch jemand eine VWS83/3 (oder 63/3 bzw. 103/3) bei der das funktioniert?
Hallo zusammen,
Ja ich habe die V2 Platine bestellt .... will aber aus Prinzip auch die andre zum laufen bringen,,, >:( >:(
ich hab das Poti mal gemessen und verstehe ich das richtig das teil geht von 0 bis 20 K Ohm über 25 Umdrehungen ???
siehe Anhang ... habe das Messgerät an die zwei Punkte gehalten und der Wert ändert sich.......
ja das passt, dann musst du dich noch etwas damit auseinander setzen, du schaffst das schon!
Dreh einfach schön langsam und beobachte die Leds, dann merkst du gleich wo es "heiß" wird!
LG
Hallo...
so ich war dann noch mal zum lachen im Keller.....
bekomme jetzt ein signal .....
27:18.088 [bus notice] <ff
2018-02-04 18:27:18.180 [bus notice] <fe
2018-02-04 18:27:18.229 [bus notice] <ff
2018-02-04 18:27:18.362 [bus notice] <ea
2018-02-04 18:27:18.407 [bus notice] <ff
2018-02-04 18:27:18.541 [bus notice] <ff
2018-02-04 18:27:18.587 [bus notice] <ff
2018-02-04 18:27:18.720 [bus notice] <fe
2018-02-04 18:27:18.819 [bus notice] <fe
2018-02-04 18:27:18.864 [bus notice] <ff
2018-02-04 18:27:19.001 [bus notice] <fd
2018-02-04 18:27:19.044 [bus notice] <ff
2018-02-04 18:27:19.181 [bus notice] <fa
2018-02-04 18:27:19.227 [bus notice] <ff
2018-02-04 18:27:19.359 [bus notice] <ff
2018-02-04 18:27:19.403 [bus notice] <ff
2018-02-04 18:27:19.500 [bus notice] <aa
2018-02-04 18:27:19.680 [bus notice] <ea
2018-02-04 18:27:19.724 [bus notice] <ff
2018-02-04 18:27:19.860 [bus notice] <ff
2018-02-04 18:27:19.904 [bus notice] <ff
nach dem ich jetzt weis das ich den Drehregler bei fast 20K Ohm stehen hatte habe ich in runter gedreht auf etwa 5 K Ohm und dann wieder angefangen zu drehen .
Jetzt "blinken die grünen LED's"
was nur nicht ganz versteh.....
ich habe eine sehr großen Bereich in dem ich drehen kann bis keine Signal mehr kommt....
Gruß Frank
der große Bereich entsteht weil das Poti ja extrem übersetzt ist und das ist zur Abstimmung einfacher.
Stelle es gefühlsmäßig in die Mitte des Bereiches und kontrolliere wenn du den Bus wegnimmst ob beim Anklemmen wieder alles schön anläuft.
D.h. du hast dich nie getraut soweit zu drehen, aber wichtig wenn es jetzt funktioniert! Willst du jetzt deine Bestellung der V2 wieder stornieren?
LG
Hallo Reinhart,
Danke für deine geduldet ...
Die V2 Paltine nehme ich weiterhin ich habe ja noch eine Vaillant Lüftung und so wie ich beim ersten lesen gesehen habe hat die auch eine ebus
jetzt muss ich erst mal noch die Info zur FHEM bekommen habe noch mal das install skript gestartet und den Punkt 3 ausgeführt.... CSV usw...
Ja und dann muss ich das mit den Autostart /etc/init.d/ebusd noch verstehen .... oder kommt das jetzt bei /etc/systemd/system
Zitat
aber hast du denn überhaupt die /etc/default/ebusd konfiguriert?
was muss ich dort noch einstellen ... :-\
lg Frank
Zitat von: bmwfan am 18 Januar 2017, 21:34:08
Möchte für andere Nutzer einer Zeotherm die ersten Erkenntnisse meiner Versuche aufzeigen, da es doch etwas mühsam war die Parameter zuzuordnen:
Parameter: ActualTempDesired
Ist je nach Heizungs-Betriebsart (Auto, Heizen...) entweder der Wert, der in der Zeile Raumsolltemperatur eingegeben wird (wenn Anlage nicht im Absenkbetrieb) oder der Wert, der in der Zeile Absenktemperatur eingegeben wird (wenn Anlage in Nachtabsenkung ist).
Parameter: FlowTemp
Ist die Heizungs- oder Warmwasservorlauftemperatur je nachdem, ob geheizt oder Warmwasser erzeugt wird.
Frage: FlowTemp == F1Temp? Bei beiden Parametern wird derselbe Wert angezeigt.
Parameter: FlowTempDesired
Da ich Rücklauftemperaturregelung eingestellt habe, ist dies die Rücklauftemperatur SOLL
Frage: FlowTemp Desired== RTemp? Bei beiden Parametern wird derselbe Wert angezeigt.
Parameter: TempDesired
Ich vermute, dass dies die Sollwertvorgabe an den Regler ist.
Parameter: collTemp:
Kollektor-Vorlauftemperatur für die Bereitstellung der Umweltwärme für das Zeolith-Modul
Parameter: collRTemp:
Kollektor-Rücklauftemperatur für die Bereitstellung der Umweltwärme für das Zeolith-Modul
Alle Parameter sind aber in den csv mit r bezeichnet, daher, so weit ich weis, nur zum lesen.
r,,FlowTempDesired,Vorlaufsollwert,,,,"5000",,,temp,,,
Wie kann ich denn die Sollwert wie FlowTempDesired bzw. Heizkurve r,,HeatingCurve,Heizkurve,,,,"1000",,,curve,,,1/100 resolution
auch beschreiben? Ich möchte gerne den Sollwert bzw. die Heizkurve morgens niedriger haben, da in der kurzen Zeit zwischen Aufstehen und zur Arbeit gehen die Wohnung nicht so warm sein muss und abends höher einstellen, damit es komfortabler ist.
Gruß Jürgen
Vielen dank für die Tips!, bmwfan. Haben auch ein Zeotherm MIT ebusd laufen! Jetz noch ein Dashboard in FHEM machten.
Gruß Henk
Zitat von: h.urmel am 04 Februar 2018, 19:12:42
was muss ich dort noch einstellen ... :-\
2. Post in diesem Thread! (https://forum.fhem.de/index.php/topic,79600.msg716139.html#msg716139)
LG
Hallo,
kann mir noch jemand einen Tip zum Filtern der Antworten vom ebusd geben?
Bei Abfrage von OpMode oder HwcOpMode der Multimatic, bekomme ich zwar den Mode als String, aber mit anhängenden Leerzeichen oder Newlines in unterschiedlicher Anzahl.
Ich würde gerne nur den String des Modes (auto,day,night) rausfiltern.
Meine Abfrage sieht so aus:
get OpMode cmd {"r OpMode\n"}
get OpMode expect ".*\n*"
get OpMode postproc { $_ }
Ich hatte auch schon etwas umständlich so etwas versucht:
get OpMode postproc { my @values=split(' ',$_);\
if( values[0])\{
sprintf("%s",$values[0]);}\
else{\
sprintf("%s",$_);}}
Funktioniert aber auch nicht. Wahrscheinlich ist die if Bedingung auch immer falsch.
Ist etwas schwierig zu debuggen oder durch probieren rauszukriegen, wenn ich immer FHEM neu starten muss, damit die .cfg neu eingelesen wird.
Gibt es da was einfacheres, z.B. mit Regular Expresions?
Danke und Grüße
Zitat von: john30 am 04 Februar 2018, 15:37:24
Die wird so oder so m.W. nur gestartet, wenn es auch wirklich Bedarf gibt. Aber kann auch sein, dass Deine Anlage die Nachricht ignoriert.
Ich habe es gerade nochmal versucht. Es besteht aktuell Warmwasserbedarf, aber die WP tut leider nichts, wenn Sie über den ebusd die Nachricht erhält. Wie kann ich herausfinden, ob ich die WP in diesem Punkt doch noch zur Mitarbeit überreden kann? ;-)
Zitat von: hanske am 05 Februar 2018, 15:46:01
Bei Abfrage von OpMode oder HwcOpMode der Multimatic, bekomme ich zwar den Mode als String, aber mit anhängenden Leerzeichen oder Newlines in unterschiedlicher Anzahl.
Ich würde gerne nur den String des Modes (auto,day,night) rausfiltern.
wo merkst du denn dass hier noch Newlines und Leerzeichen kommen, eigentlich sollte dass passen.
Poste bitte einmal ein "list" von diesem Device!
LG
Hallo Rainer,
hier die aktuellen Readings:
Internals:
DEF bai00.class
IODev EBUS
NAME eb_hz_vaillant
NR 798
STATE auto
, 11.5, V: 42.6, R: 34.6, S: 28.0
TYPE ECMDDevice
READINGS:
2018-01-28 21:26:06 Brauchwassersollwert 0
2018-02-05 19:56:58 DayTemp 20.5
2018-01-27 09:21:01 Fanspeed 0
2018-02-05 19:57:11 HwcOpMode auto
2018-02-05 19:56:49 OpMode auto
2018-02-05 19:56:20 Outdoorstemp 0.1
2018-02-05 19:56:30 Ruecklauf 34.6
2018-02-05 19:57:05 ShortTemp 11.5
2018-02-05 19:56:10 StorageTemp 28.0
2018-02-05 19:56:37 Vorlauf 42.6
2018-02-05 19:57:11 state HwcOpMode auto
2018-02-02 13:13:26 writeDayTemp1 done
fhem:
classname bai00.class
cache:
specials:
%NAME eb_hz_vaillant
%TYPE ECMDDevice
Attributes:
IODev EBUS
event-on-change-reading state.*
room Climate,Heizung,Home
stateFormat OpMode, ShortTemp, V: Vorlauf, R: Ruecklauf, S: StorageTemp
Man kann die Linefeeds gut erkennen.
ja, ist irgend ein anderes Zeichen als \n drinnen.
Du kannst auf Nummer sicher gehen und beim 3. Zeichen einfach abschneiden, dann ist der Müll weg.
Internals:
DEF bai00.class
IODev EBUS
NAME WWSchalter
NR 1484
STATE WWSchalter aut
TYPE ECMDDevice
Helper:
DBLOG:
WWSchalter:
myDbLog:
TIME 1517861686.26258
VALUE aut
state:
myDbLog:
TIME 1517861686.26258
VALUE WWSchalter aut
READINGS:
2018-02-05 21:14:46 WWSchalter aut
2018-02-05 21:14:46 state WWSchalter aut
fhem:
classname bai00.class
cache:
specials:
%NAME WWSchalter
%TYPE ECMDDevice
Attributes:
IODev EBUS
group Vaillant
icon scene_hall
room Vaillant
hier schneide ich "auto" beim dritten Zeichen ab, weil "off" hat nur 3 Zeichen und wäre der kürzeste Rückgabewert.
get WWSchalter cmd {"r -f HwcOPMode\n"}
get WWSchalter expect ".*\n*"
get WWSchalter postproc {sprintf("%.3s",$_)}
LG
Hallo Rainer,
ich meine, dass auch manchmal noch ein Leerzeichen vor den \n kam.
Ich kann das erst mal mit fester Stringlänge machen. Sonst muss ich mir selbst noch ein Filter ausdenken.
Mit verschieden RegEx hatte ich bisher keinen Erfolg. Habe auch schon erfolglos Chop und Chomp probiert.
Danke
Hanske
Du musst FHEM nicht immer neu starten. Versuch mal ein rereadcfg
Zitat von: vwsuser am 05 Februar 2018, 17:17:05
Ich habe es gerade nochmal versucht. Es besteht aktuell Warmwasserbedarf, aber die WP tut leider nichts, wenn Sie über den ebusd die Nachricht erhält. Wie kann ich herausfinden, ob ich die WP in diesem Punkt doch noch zur Mitarbeit überreden kann? ;-)
@john30: Sorry, dass ich so beharrlich bin, aber die Funktion ist einfach ziemlich wichtig für mich. ;-) Kannst du mir hier behilflich sein?
Hallo,
kann mir jemand beim Autostart von ebusd helfen?
Ist eigentlich alles nach dem wiki eingerichtet aber ohne "sudo" startet der service nicht.
pi@raspberrypi ~ $ /etc/init.d/ebusd start
[ ok ] Starting ebusd: ebusd.
pi@raspberrypi ~ $ sudo service ebusd status
[FAIL] ebusd is not running ... failed!
pi@raspberrypi ~ $ sudo /etc/init.d/ebusd start
[ ok ] Starting ebusd: ebusd.
pi@raspberrypi ~ $ sudo service ebusd status
[ ok ] ebusd is running.
Die Rechte bei "/etc/init.d/ebusd" sind die gleichen wie bei "fhem" oder "hmland"
Außerdem findet er beim Starten häufig meine Multimatic 700 nicht.
Ich muss dann noch mal
sudo service ebusd stop
sudo service ebusd start
machen. dann klappt es meistens.
Meine ebusd options sind:
EBUSD_OPTS="--scanconfig -d 192.168.10.24:9999 -l /var/log/ebus.log --logleve=notice"
Muss da noch ein -checkconfig zu, damit dynamisch nach weiteren slaves gesucht wird?
Danke und Grüße
Zitat von: vwsuser am 07 Februar 2018, 19:30:20
@john30: Sorry, dass ich so beharrlich bin, aber die Funktion ist einfach ziemlich wichtig für mich. ;-) Kannst du mir hier behilflich sein?
naja, es ist halt entweder noch eine weitere/andere nachricht im Spiel, die das Verhalten auslöst, oder der Controller macht noch mehr als nur diese "load" nachricht zu verschicken.
Ich kann Dir da nicht wirklich weiterhelfen, da mein Controller nach 10 Jahren Betrieb gerade seinen Geist aufgegeben hat.
Zitat von: hanske am 08 Februar 2018, 18:23:59
Ist eigentlich alles nach dem wiki eingerichtet aber ohne "sudo" startet der service nicht.
das ist schon richtig so, ist ja schließlich ein Dienst und es wär ja noch schöner, wenn jeder alle Dienste starten/stoppen könnte.
Zitat von: hanske am 08 Februar 2018, 18:23:59
Außerdem findet er beim Starten häufig meine Multimatic 700 nicht.
Inzwischen kann ich behaupten, dass die Multimatic nicht immer gewillt ist, auf die Scan Nachricht zu antworten (hab jetzt selbst eine und werd sie wohl wieder verkaufen müssen, weil sie meinen Controller leider nicht ersetzen kann).
Zitat von: hanske am 08 Februar 2018, 18:23:59
Muss da noch ein -checkconfig zu, damit dynamisch nach weiteren slaves gesucht wird?
nein, das auf keinen Fall, weil damit ja nur die CSVs auf Korrektheit geprüft werden und ein normaler Betrieb verhindert wird.
Du könntest "--scanconfig=full" in die defaults eintragen, dann würden beim Start von ebusd immer alle über 200 Slaves gescannt werden, ist halt ganz schön viel.
Wenn Du nur eine Adresse explizit vermisst, kannst die auch hinter "--scanconfig=" in Hex eintragen.
Hallo John,
danke für die Antwort.
Zitatdas ist schon richtig so, ist ja schließlich ein Dienst und es wär ja noch schöner, wenn jeder alle Dienste starten/stoppen könnte.
Ok, wäre dann ja gut wenn man die passende Rückmeldung bekommen würde.
Wieso startet der Dienst beim Hochfahren nicht, an den Rechten liegt es dann ja wohl nicht?
Was kann ich da noch untersuchen?
ZitatWenn Du nur eine Adresse explizit vermisst, kannst die auch hinter "--scanconfig=" in Hex eintragen
Meinst du die Slavenummer, also in meinem Fall die 2?
slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
Kann der Dämon vielleicht im Hintergrund immer mal wieder scannen ob er noch ein neues Gerät findet?
Dann müsste er doch irgendwann auch die Multimatic finden. Beim Neustart klappt es ja auch manchmal.
Danke und Grüße
Hanske
ZitatOk, wäre dann ja gut wenn man die passende Rückmeldung bekommen würde.
Das kann man sich alles selbst einrichten, dafür muss man eben etwas über Linux lernen...
Ich finde diese dauernde Neustarterei sowieso suspekt - mein ebusd wird etwa einmal pro Halbjahr neu gestartet.
LG
pah
Zitat von: john30 am 10 Februar 2018, 13:51:08
Inzwischen kann ich behaupten, dass die Multimatic nicht immer gewillt ist, auf die Scan Nachricht zu antworten (hab jetzt selbst eine und werd sie wohl wieder verkaufen müssen, weil sie meinen Controller leider nicht ersetzen kann).
Das finde ich allerdings seltsam...
Ich hatte in den letzten 25 Monaten 5 verschiedene Multimatic an meinem Bus und ebusd hat immer alle korrekt gefunden.....
(allerdings zeigt diese Tatsache allein schon, dass Vaillant offenbar vieles mit der heißen Nadel strickt, von daher wundert mich die Beobachtung auch nicht wirklich)
Zitat von: Sven77 am 12 Februar 2018, 08:31:36
Das finde ich allerdings seltsam...
Ich hatte in den letzten 25 Monaten 5 verschiedene Multimatic an meinem Bus und ebusd hat immer alle korrekt gefunden.....
(allerdings zeigt diese Tatsache allein schon, dass Vaillant offenbar vieles mit der heißen Nadel strickt, von daher wundert mich die Beobachtung auch nicht wirklich)
Wow, 5 Stück? Das ist ja enorm.
Ich hab mir das Teil nur auf Verdacht besorgt in der Hoffnung, dass es mit meiner EHP zurecht käme - leider nein... Gar nicht so ganz modern, diese multimatic >:(
@pah
Wenn Fhem nicht abstürzt oder hängt, starte ich natürlich auch nicht neu.
Leider passierte das in der Vergangenheit häufiger (Absturz im DOIF und Hänger wenn das Internet streikt)
Im Moment läuft es aber stabil.
Schön wäre es schon, wenn der EBUSD auch nach dem Neustart mit startet, sonst muss ich immer die Konsole bemühen.
Danke und Grüße
hanske
Zitat von: hanske am 10 Februar 2018, 18:47:35
danke für die Antwort.Ok, wäre dann ja gut wenn man die passende Rückmeldung bekommen würde.
das ist wie schon von pah beantwortet OS Angelegenheit.
Zitat von: hanske am 10 Februar 2018, 18:47:35
Wieso startet der Dienst beim Hochfahren nicht, an den Rechten liegt es dann ja wohl nicht?
Weil es anscheinend noch nicht so eingestellt wurde. Auch das hängt allerdings vom verwendeten OS ab, einfach mal nach "Linux service autostart" o.ä. im Netz suchen.
Zitat von: hanske am 10 Februar 2018, 18:47:35
Kann der Dämon vielleicht im Hintergrund immer mal wieder scannen ob er noch ein neues Gerät findet?
Das macht er natürlich mit "--scanconfig", sobald ein weiterer Slave oder Master den Bus aktiv verwendet.
Dass Deine Multimatic nicht gefunden wird, klingt eher nach einem grundsätzlichen Problem. Schau mal ins ebusd log, ob da Fehler zu finden sind.
Zitat von: Allodo am 31 Januar 2018, 13:06:24
An der Therme ist eine VRC 410 angeschlossen. Nur wo diese direkt auf dem Board angeschlossen ist, weiß ich ehrlich gesagt nicht.
Habe auch nur mal einen kurzen Blick riskiert.
Hänge mal die Platinenanschlussbelegung mit an
Moin
Sorry, dass ich diesen Post erst so spaet gesehen habe. Bei Dir liegt der eBUS auf der Buchse X6, Du brauchst aber noch einen VR39, den Du links in die Elektronikbox "stecken" (ist nur mechanisch, deshalb die Haekchen) musst. Das beiligende Kabel wird dann in den X6 und die Platine gesteckt. Allerdings brauchst du auch noch einen eBus faehigen Regler, da meiner Meinung nach da die eigentlichen Daten abgegriffen werden. Sind aber inzwischen in der Bucht, oder auch in Kleinanzeigen zu Hauf zu finden.
Das Laeuft bei mir problemlos!
Gruss Christoph
Nachdem ich die Hoffnung auf eine Steuerung mit ebus schon aufgegeben habe, wurde diese durch den Hinweis von pc1246 mit dem VR39-Zusatzmodul wieder geweckt :)
Welcher ebus-fähige Regler wäre denn für meine Therme (Vaillant VSC 126 C-140) brauchbar? Derzeit verbaut ist eine VRC410, welche direkt an der Therme verbaut ist.
Der ebus-fähige Regler sollte möglichst in das Feld der Therme passen, sprich dort, wo die VRC410 jetzt hängt :)
Ich denke, das mit dem Passen wird schwierig.
Zunächst sehen alle neueren Steuerungen generell gleich groß aus - die Größe könnte somit auch zur VRC410 passen, aber die Anschlüsse sind ja ganz anders und ob dann noch genug Platz bleibt, den VR39 auch noch dahinter zu basteln?
So wie ich gehört habe, hat John gerade eine VRC700 abzugeben - zu dieser (und evtl. auch weiteren) gibt es im Lieferumfang eine Wandhalterung, in meinem icoVIT ist folglich nur eine Abdeckung und die VRC700 im Wohnraum montiert. Das wäre sicher einfacher zu realisieren, notfalls eine Wandmontage neben dem Brenner.
Vielleicht hat noch irgendjemand diese Abdeckung übrig, dass Du diese statt der VRC410 aufstecken kannst - oder lässt halt die alte VRC als "Abdeckung" drin. ;)
Das mit dem passen, ist eher Optional. Zur Not könnte ich die Steuerung auch neben die Therme an die Wand hängen.
Primär geht es mir darum, die Therme eBus-fähig zu machen, damit ich z.B. die Warmwassertemperatur, bei Bedarf, per Smartphone hochfahren kann. Oder mittels Anwesenheitssteuerung die Heizphasen koordiniere und dgl.
Moin Allodo
Also, Du kannst definitiv den Regler nicht n deine Therme stecken. Der hat dort den 7/8/9-Anschluss, und der eBus Regler hat an aehnlicher Position den eBus.
So wie ich das sehe, hast du einen Aussenfuehler, so dass Du eine Witterungsgefuehte Anlage hast. Da musst du dann auch einen passenden Regler nehmen. Zudem musst Du die Raumaufschaltung im Regler deaktivieren koennen. Das kann der 370 nicht, der 470 aber schon! Der 700er kann bestimmt auch beides, das wollte ich jetzt aber nicht auch noch erruieren!
Bei ebay und auch deren Kleinanzeigen findest Du die ab 90€. Jetzt brauchst du noch die VR39, die gerade eben bei Kleinanzeigen zu finden ist. Neu liegt die bei €120,-
Viel Spass und Erfolg
Christoph
Hallo zusammen,
irgendwie stehe ich auf dem Schlauch und habe mit entschieden jetzt mal im Forum nach Hilfe zu fragen nachdem ich mich durch diverse Foren usw. gesucht habe. Folgendes Problem:
Beim Aufruf von "ebusctl info" wird keine Konfiguration-/sdatei "CSV-Datei" angezeigt (siehe Screenshot 1) obwohl nach meinem bisherigen Verständnis der Befehl "ebusd --checkconfig --scanconfig" doch relevante Ergebnisse zeigt bzw. keine für mich erkennbaren Fehler wirft.
Ich hätte bei meiner Konfiguration (Vaillant VRC700; ECOTEC EXCLUSIV VC 276-E; EBUS Koppler) erwartet dass hier irgendwas mit "15.700.csv" oder ähnlichem angezeigt wird.
In diversen Threats wird von angepassten CSV-Dateien gesprochen. Muss ich noch irgendeinen Schritt machen - den ich bisher nicht gefunden habe - damit die CSV Konfiguration greift?
Bevor ich hier jetzt weiter Frage - und euch nerve - möchte ich erstmal herausfinden ob ich noch irgendwas grundsätzliches falsch mache.
Besten Dank vorab für Eure Fragen/Antworten.
Doc_Love
Zitat von: doc_love am 16 Februar 2018, 21:59:19
Ich hätte bei meiner Konfiguration (Vaillant VRC700; ECOTEC EXCLUSIV VC 276-E; EBUS Koppler) erwartet dass hier irgendwas mit "15.700.csv" oder ähnlichem angezeigt wird.
mach mal ein "ebusctl scan full", warte ne Minute und dann nochmal "ebusctl info"
Hi
I'm newbie in topic.
I connect ebus connector 1.6 to Vaillant ecoTec + VRC430 + V61
I installed ebusd (on RPi):
git clone https://github.com/john30/ebusd.git
cd ebusd
./autogen.sh
make
sudo make install
next copy configuration 2.1:
git clone https://github.com/john30/ebusd-configuration.git
sudo ln -s /home/pi/ebusd-configuration/ebusd-2.1.x/en /etc/ebusd
pi@raspberrypi:/usr/bin $ sudo ebusd -f -d /dev/ttyUSB2 --scanconfig
2018-02-15 18:13:27.033 [main notice] ebusd 3.1.v3.1-22-gdaf771e started with auto scan
2018-02-15 18:13:27.054 [bus notice] bus started with own address 31/36
2018-02-15 18:13:27.104 [bus notice] signal acquired
2018-02-15 18:13:37.962 [bus notice] new master 03, master count 2
2018-02-15 18:13:46.982 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2018-02-15 18:13:46.983 [update notice] store 08 ident: done
2018-02-15 18:13:46.984 [update notice] sent scan.08 QQ=31: Vaillant;BAI00;0518;7401
2018-02-15 18:13:46.985 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2018-02-15 18:13:47.014 [main notice] read common config file /etc/ebusd/vaillant/general.csv
2018-02-15 18:13:47.016 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2018-02-15 18:13:47.021 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2018-02-15 18:13:47.029 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2018-02-15 18:13:47.114 [bus error] send to 08: ERR: read timeout, retry
2018-02-15 18:13:47.713 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:47.949 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:48.120 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:48.295 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:13:48.383 [main notice] found messages: 200 (0 conditional on 23 conditions, 0 poll, 9 update)
2018-02-15 18:13:48.516 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:13:49.426 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:15:47.814 [main notice] update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.1.v3.1-22-gdaf771e
update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 110
min arbitration micros: 780
max arbitration micros: 916
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 3
messages: 201
conditional: 0
poll: 0
update: 9
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010003857.inc" ([PROD='0010003869']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
And my first problems:
1)
sudo systemctl enable ebusd
i get "Failed to execute operation: No such file or directory"
I can't run ebusd as daemon
2)
and many times, when i start ebusd in foreground i get only:
2018-02-15 18:18:41.820 [main notice] ebusd 3.1.v3.1-22-gdaf771e started with auto scan
2018-02-15 18:18:41.845 [bus notice] bus started with own address 31/36
2018-02-15 18:18:41.862 [bus notice] signal acquired
and nothing else
3) Why i can't write anything ?
regards
Fantom
Zitat von: Fantom am 17 Februar 2018, 10:40:31
sudo systemctl enable ebusd
i get "Failed to execute operation: No such file or directory"
I can't run ebusd as daemon
see my reply to your issue (https://github.com/john30/ebusd/issues/166#issuecomment-366430420).
Zitat von: Fantom am 17 Februar 2018, 10:40:31
and many times, when i start ebusd in foreground i get only:
2018-02-15 18:18:41.820 [main notice] ebusd 3.1.v3.1-22-gdaf771e started with auto scan
2018-02-15 18:18:41.845 [bus notice] bus started with own address 31/36
2018-02-15 18:18:41.862 [bus notice] signal acquired
and nothing else
well for that we need to dig deeper. how is your device connected? what devices are connected to the eBUS?
Zitat von: Fantom am 17 Februar 2018, 10:40:31
3) Why i can't write anything ?
the capability to write depends on the authorization level of the connected user and the message definition. if you don't care about security, then simply add "--accesslevel=*" to the start parameters of ebusd (usually in /etc/default/ebusd). then you can write every available message that is defined as write message.
I have Vaillant VSC ECOCOMPACT (196/2-C 150) + VRC430F (wireless) + VR61 (all connected to one ebus)
1)
When i started ebusd i many times get only
2018-02-15 18: 18: 41.820 [main notice] ebusd 3.1.v3.1-22-gdaf771e started with auto scan
2018-02-15 18:18 : 41.845 [bus notice] bus started with own address 31/36
2018-02-15 18: 18: 41.862 [bus notice] signal acquired
but after a few starts, it works fine, and I see more info.
2) And I think, that only one configuration file is loaded (for VSC). I don't see that configuration for VRC430F or VR61 is loaded.
Fantom
@john30
der Befehl "ebusctl scan full" brachte keine Verbesserung.
Ich habe mich dann entschieden den raspi neu aufzusetzen und von vorne anzufangen.
1. Poti Abgleich
Aus meiner Sicht müsste auf Basis von Screenshot 1 die technische Funktionsfähigkeit prinzipiell ok sein
2. Software (EBUSD) und Config-Files
Anders als im meinem ersten Posting erhalte ich jetzt folgendes Ergebnis (siehe TXT. Datei) zum Befehl "ebusd --checkconfig --scanconfig"
Ich denke dass da der Hund begraben liegt, habe aber keinerlei Ansatzpunkte gefunden woran es liegen könnte. Auch wenn hier
found messages: 9518 (454 conditional on 145 conditions, 2 poll, 56 update)
"gefunden" wurden, der Befehl "ebusctl scan full" bringt - auch nach 120 sek. warten - kein Ergebnis.
Wie immer, danke für Hinweise/Tipps die zur Lösung beitragen.
Grüße
Doc_Love
Zitat von: doc_love am 17 Februar 2018, 21:33:14
1. Poti Abgleich
Aus meiner Sicht müsste auf Basis von Screenshot 1 die technische Funktionsfähigkeit prinzipiell ok sein
neine, die werte sind ganz und gar nicht in ordnung. wenn das ebusd 3.x ist, dann solltest du für den poti abgleich "--lograwdata=bytes" in die kommandozeile mit dazu nehmen, und dann den abgleich nochmal von vorne beginnen
Hi john30,
it works (siehe Screenshot Anhang). Ich konnte sogar ein paar (wenige) Werte bereits abfragen:
ebusctl r -f Hc1HeatCurve => Heizkurve
ebusctl r -f z1RoomTemp => Raumisttemperatur
ebusctl r -f Time => Uhrzeit
ebusctl r -f z1Shortname => Zonenname
ebusctl r -f hwcTimer.Monday
ebusctl r -f z1Timer.Monday
Da jetzt die technische Basis steht will ich mich daran machen möglichst viele (sinnvolle) Werte auszulesen bzw. zu erfassen.
An obigen Werte bin ich über trial and error gelangt. Wer hat den für mich einen Tipp (Links, Literatur, usw.) für mich, wie ich mein Wissen durch Selbststudium erweitern kann?
Vielen Dank und gute Nacht!!!
doc_love
Zitat von: Fantom am 17 Februar 2018, 11:40:04
I have Vaillant VSC ECOCOMPACT (196/2-C 150) + VRC430F (wireless) + VR61 (all connected to one ebus)
And I think, that only one configuration file is loaded (for VSC). I don't see that configuration for VRC430F or VR61 is loaded.
Fantom
Any help ? How i can check why ebusd don't find 430F ?
Fantom
Zitat von: doc_love am 18 Februar 2018, 00:38:47
An obigen Werte bin ich über trial and error gelangt. Wer hat den für mich einen Tipp (Links, Literatur, usw.) für mich, wie ich mein Wissen durch Selbststudium erweitern kann?
das ebusd wiki (https://github.com/john30/ebusd/wiki) ist sicher hilfreich. Welche Nachrichten definiert sind, findest Du über "ebusctl find" heraus.
Zitat von: Fantom am 22 Februar 2018, 18:39:24
Any help ? How i can check why ebusd don't find 430F ?
you'd have to look at the ebusd log file in order to find that out. most of the time it is a bad potentiometer setting.
Hallo!
ich bezieh mich nochmals auf den alten Artikel von galileo bezüglich der nicht gut funktionierenden esera Adapter.
https://forum.fhem.de/index.php/topic,29737.msg511678.html#msg511678 (https://forum.fhem.de/index.php/topic,29737.msg511678.html#msg511678)
Lt. vielen Infos klappt der Umbau für die USB Variante relativ gut, bei der Ethernetversion soll es jedoch Latenz Probleme geben.
Ich hab zum Probieren den USB Adapter von galileo bekommen und hatte damit gegenüber der Eth Variante eine Failed Telegram Rate von 8-15% statt davor 75-85%.
Dank seiner Hilfe hab ich an der ursprünglichen Schaltung ein paar Änderungen vorgenommen, im Prinzip nur die Spannungsteiler lt. ebus adapter 2.0 / 2.1 übernommen (100k/22k und 18k/15k).
Der verbaute Adapter von Seriell nach Ethernet ist bei mir ein Wiznet und nimmt im Gehäuse doppelt so viel Platz ein wie beim USB Adapter.
Trotzdem geht es sich knapp aus die Schaltung noch im Geehäuse unterzubringen.
Ich hab den Adapter jetzt seit 2 Tagen in Betrieb und liege konstant bei unter 8% bei der Failure Rate!
Das Latenzproblem scheint bei mir nicht vorhanden zu sein :) Das Ding funktioniert wirklich gut!
Er findet mehr Bus Teilnehmer und es gibt keine Fehler mehr. Dort wo ich früher stundenlang auf ein Update gewartet habe, ist es jetzt sofort im ersten Ausleseversuch hier.
Die Broadcasts von Temperatur und Zeit hab ich davor ca. alle 2-10 Minuten bekommen, jetzt kommen sie punktgenau alle 60 Sek.
Ein großes Danke an alle die ihre Infos mit mir geteilt haben.
LG
aia
Nächstes Projekt der ebus Adapter 2.1 & RPI Adapter :)
Danke für deinen Erfahrungsbericht, bin schon gespannt wie weit du die Fehlerrate mit der Rpi nach unten treiben kannst.
Leider kann man die Ethernet mit der Rpi Variante nicht direkt vergleichen und schon aus rein physikalischen Gründen kann die Ethernet da nicht ganz mithalten. Mich würde interessieren welchen Latenzen du mit der Ethernet erreichst?
Ich habe mit meiner Rpi tagelang keinen einzigen Fehler, wobei ich aber nur eine Calormatic und das Heizgerät drauf hängen habe und in dieser Konstellation hat ja schon die V 1.6 gut funktioniert. Aber auch Galileo hat bei seinem empfindlichen Bussystem berichtet wie gut mit der Rpi die Fehlertoleranz jetzt geworden ist.
LG
Reinhart
Hallo aia,
Danke für Dein Feedback, ist wirklich interessant, auch nach all den Analysen und Tests die wir im Zuge der 2.0/2.1/RPI Entwicklung gemacht haben.
Ich gehe davon aus dass Dein Sprung von 75% auf 8% der exakteren Pegeleinstellung zuzuschreiben ist. Die restlichen 8% würde ich jetzt einmal bei der Latenz vermuten.
Das könnte sich mit meinen Beobachtungen decken, wonach ein Transfer immer dann schief geht, wenn er mit einem Transfer eines anderen Teilnehmers zusammenfällt, weil er selbst die Arbitrierung ja bereits schon lange Zeit hinter sich hat und der andere Teilnehmer aber glaubt, jetzt (gleichzeitig) senden zu dürfen. Je nach Buslast kann das so in 10% der Fälle auftreten. In den anderen 90% der Fälle funktioniert der Transfer trotzdem, weil der Bus gerade zufällig frei ist.
Wie Reinhart schon geschrieben hat, wären die gemessenen Latenzzeiten noch interessant, mit den Werten könnte man diese Theorie noch erhärten/verwerfen.
Wie auch immer, falls du auch eine RPI Platine ausprobieren möchtest (mit dem ttyebus Treiber garantiert mit NULL Latenz :) ), findest du diese jetzt hier (https://forum.fhem.de/index.php/topic,84633.msg769405.html#msg769405) verfügbar.
LG
Eduard
@Galileo
aia hat schon die Rpi bestellt, da war er gleich der zweite Besteller und dürfte sie noch diese Woche bekommen (ausgeliefert am 20.02), dann wissen wir mehr ob sich hier nochmals eine Verbesserung einstellt.
LG
Hi,
die Rpi liegt schon bei mir ein paar Tage herum, diese Woche schaut aber schlecht aus - nächste hab ich dann Zeit.
Sobald ich Zahlen habe - kommen sie hier rein.
Bzgl. Latenz: ich verwende OpenHAB und das ebus binding 2.0 in der alpha 15 von Christian Sowada, hab da noch keine Latenz Anzeige gefunden.
LG
Ich wollte mal Feedback geben, und einen großen Dank an pc1246 für seinen Tipp mit der VR39 und Calormatic VRC470.
Diese habe ich günstig bei ebay erstanden und heute sind sie endlich angekommen. Also die VR39 konnte ich sehr gut an die Seite meiner Platine verbauen (Vaillant VSC126 C-140). Dann ein Cat5-Kabel rausgeführt und an die Wand die VRC470/4 montiert und angeschlossen. Den alten Regler (VRC410) habe ich von der Therme abgezogen.
Die Therme wieder angeschaltet und alles hat funktioniert. Der Außentemperaturfühler brauchte einige Zeit bis er den korrekten Wert angezeigt hat (zuvor -40 und dann korrekt +7 Grad).
Warmwasserzeiten und dgl. kann ich auch einstellen, obwohl mir von seitens Vaillant gesagt wurde, dass dies per VR39 nicht funktionieren würde.
Falls also auch schon jemand die Flinte ins Korn werfen mag, weil er die gleiche Therme oder eine Ähnlichen ohne ebus hat, eine Nachrüstung ist offensichtlich möglich ;)
Nun muss ich am Wochenende mal schauen, ob ich die ebus-Platine V2.1 korrekt zusammengelötet habe und dazu bringe an FHEM Werte zu übertragen :)
Hallo Zusammen!
Ich habe eine Solarladestation Vaillant "VPM 20 S" und würde gerne den Druck des Solarkreises über den eBus erfahren. Ich habe mir schon alle geladenen csv's angesehen, kann aber keinen entsprechenden Eintrag finden. Grundsätzlich funktioniert der eBus natürlich bei mir - ich kann alle möglichen Werte abfragen.
Nutzt jemand den Solarkreisdruck?
Beste Grüße,
iceman.wtal
Also ich habe auch eine VPM20S - bin aber etwas verunsichert:
Kann man in deren Display überhaupt den Druck ablesen?
Ich müsste das mal prüfen, bisher hatte ich nie versucht diesen über eBus auszulesen.
...ob das am Display geht bin ich auch unsicher - aber im meine mich erinnern zu können irgendwo im Fachhandwerkermenü.
Zumindest schaltet das VPM ja bei zu wenig Druck ab. Diese Info sollte doch vielleicht auch irgendwo per eBus auszulesen sein...
Gruß,
iceman.wtal
In der Tat - war mir nie bewusst! In der Fachhandwerkerebene unter Sensor/Aktortest als T.53 "Druck Solarkreis".
Habe eben mal gesucht, aber in den bei mir antwortenden B509-Abfragen ist davon nichts dabei - oder ich finde es nicht.
Hättest Du (oder jemand anderes) die Möglichkeit, den Druck halbwegs beliebig zu ändern und/oder bei verschiedenen Drücken ein paar Abfragen zu starten, die man anschließend vergleichen könnte?
PS: Dafür habe ich so "nebenbei" die IDs für Solarertrag Gestern/Monat/Jahr gefunden ;-)
Ich habe leider nicht die Möglichkeit den Druck relativ einfach variabel einzustellen.
Aber man kann ja ausgelesene Werte mit dem in der Fachhandwerkerebene vergleichen. Es sollten ja nicht so viele ähnliche Werte vorhanden sein und beim nächsten Sonnenschein (und damit sich ändernden Drücken) kann man ja den gefundenen Wert noch mal verifizieren. Wie kann ich denn Werte welche noch nicht in den csv Dateien stehen abfragen? Gibt es eine Möglichkeit / Script alle Adressen "durchzudackeln" und die Ergebnisse zu anzuzeigen?
Die Solarerträge Heute/Gestern/Monate/Jahr stehen übrigens schon länger in den csv Dateien und ich nutze diese schon seit über 2 Jahren...
Welche Version Ebusd und welche Konfiguration nutzt Du?
In meiner und offenbar auch der neuesten auf Github (2.1.x (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/06.pms.csv), 2.x.x (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.x.x/de/vaillant/06.pms.csv)) gab es bisher nur YieldCurrentDay und YieldTotal.
Gerade dieses "durchdackeln" habe ich vor langer Zeit gemacht und die antwortenden IDs als zusätzliche Reads in meiner CSV aufgenommen. Suche im Forum mal nach "allregisters.sh". Im Anhang findest Du meine Werte von gestern Abend, Druck war zu dieser Zeit 3,7 bar - ich habe nichts gefunden, was das in einem halbwegs bekannten Datentyp darstellt.
Kannst das gern auch bei Dir mal vergleichen - die "UnknownXX" Nachrichten sind b509030dXX00 und die vierstelligen "UnknownXXXX" entsprechend b509030dXXXX.
Viel Erfolg - würde mich in der Tat auch interessieren!!
@iceman.wtal:
Kannst Du bitte mal die Rückgabe von 'ebusctl hex 06b509030dd100' zusammen mit dem (möglichst) zeitgleich abgelesenen Druck posten?
Dazu bitte falls noch nicht geschehen Ebusd mit '--enablehex' starten oder, bei ganz altem Ebusd, entsprechend 'ebusctl w -h 06b509030dd100' nutzen.
Habe gerade mal im laufenden Betrieb den hex Befehl eingegeben. Bei einem abgelesenen Druck zwischen 1,9 und 2,2 kommt am eBus "hex 06b509030dd100"
021100 und 021500
an. Macht das Sinn? Muss das noch irgendwie umgerechnet werden?
Ich sehe heute Abend im Ruhemodus noch mal nach. Dann sollte ich ja konstante Werte haben...
Macht dann schon Sinn! Die Werte sollten dann 1,7-2,1 bar bedeuten. Lies nochmal bei konstanten Werten, ich baue dir dann mal eine CSV zusammen.
Nochmal die Frage: welche Ebusd-Version hast du?
Meine Version ist "3.1.v3.1-22-gdaf771e".
Ich hole die Werte später dann noch mal im Stillstand...
Was hälst Du von "hex 06b509030d6f00"?
Da kam gestern bei Dir 167 raus und bei mir gerade 04c8000000.
Vielleicht liege ich ja komplett daneben aber HEX 167 könnte 359 (3,59 bar?) und die HEX c8 aus meinen 04c8 könnte 200 (2,00 bar?) sein. Oder bin ich da komplett auf dem Holzweg?
...im Ruhezustand habe ich 2,4 bar auf der Anzeige und "hex 06b509030dd10" bringt 021800, also 32? Oder sind die 18 hex und damit 24?
Mit meiner "hex 06b509030d6f00" Umrechnung war ich wohl voll auf dem Holzweg...
Das erste Byte einer Hex-Antwort ist immer die Länge der Antwort, gehört also nicht zu den Nutzdaten.
Füge mal in /etc/ebusd/vaillant/_templates.csv diese zwei Zeilen ein:
press2,UCH,10,bar,Druck
presssensor2,press2;sensor,,,
Und in der /etc/ebusd/vaillant/06.pms.csv diese Zeile:
r,,SolarPressure,Druck Solarkreis,,,,"D100",,,presssensor2,,,Druck im Solarkreis,,,
Es läuft!
Und stimmt auch mit dem aktuellen Druck (2.0 bar) überein. Ich melde mich wenn es Auffälligkeiten gibt, betrachte das "Problem" aber aktuell als gelöst.
Vielen Dank Herr Namensvetter! ;-)
P.S. geht unsere Erkenntnis nun eigentlich automatisch in die Quellen auf Github ein?
Nur mal so als Kommentar von mir - habe sozusagen über Monate nicht mehr hineingeschaut: Ich bin beeindruckt, was Ihr bisher in Hardware und Software aus dem Projekt gemacht habt.
Nachdem ich zwischendurch mal die gestorbene Zenerdiode ausgetauscht habe, werkelt bei mir übrigens immer noch die allererste Lochrasterversion der Schaltung vor sich hin.
LG
pah
@ John: Ich hatte mal irgendwo gelesen, dass es die Möglichkeit gibt, EBUSD regelmäßig bestimmte / alle Werte abfragen zu lassen ohne das aus FHEM heraus aktiv abzufragen, nur finde ich das nicht mehr wieder. Daher meine Frage: Wo kann ich das wohl finden und welche Mindestanforderung (ich habe aktuell die EBUSD 3.0 installiert) brauche ich dafür ?
Hintergrund ist, daß ich regelmäßig dann einen ca. 6s langen Freeze habe, wenn ich die Werte neu abfragen lasse und ich das gerne reduzieren würde...
Grüße
Christian
Hallo Christian,
suchst du das hier:
https://github.com/john30/ebusd/wiki/4.1.-Message-definition
Du kannst dies in den CSV Dateien der Konfiguration einstellen.
Gruß
Maik
Gesendet von meinem Aquaris_A4.5 mit Tapatalk
Hallo Maik,
wenn ich das richtig verstehe, dann muss ich also bei dem Wert, der mit regelmäßig abgefragt werden soll, eine z.B. 1 hinter das r in die CSV eintragen oder ? Dann würden alle, bei denen eine 1 dahinter ist, bei jedem Zyklus (wie lang ist das denn zwischen den Abfragen ?) automatisch aktualisiert, richtig ?
Hallo Christian,
ja richtig. Und das Poll-Intervall kannst du beim starten des Dämons angeben:
https://github.com/john30/ebusd/wiki/2.-Run
Gruß
Maik
Zitat von: cs-online am 17 April 2018, 12:27:58
wenn ich das richtig verstehe, dann muss ich also bei dem Wert, der mit regelmäßig abgefragt werden soll, eine z.B. 1 hinter das r in die CSV eintragen oder ? Dann würden alle, bei denen eine 1 dahinter ist, bei jedem Zyklus (wie lang ist das denn zwischen den Abfragen ?) automatisch aktualisiert, richtig ?
genau, istler hats ja schon beantwortet.
Anstelle die CSVs zu ändern, kannst Du auch einfach bei einem read Kommando direkt die poll prio verändern. Das ist aber nach einem ebusd Neustart wieder weg.
Also einmal alle Werte, die ich haben möchte statt mit "r -f" dann "r1 -f" abfragen und dann mittels "find" immer alle aktuellen Werte über einen Timer in FHEM abfragen ? In welchem Intervall werden die denn akrualisiert ?
Hallo Christian,
Das wird bei den Start-Parametern des Daemon (ebusd) festgelegt:
https://github.com/john30/ebusd/wiki/2.-Run
--pollinterval=SEC
Poll for data every SEC seconds (0=disable) [5]
Gruß
Maik
Hallo zusammen, ich hänge mich auch noch an den Riesen-Thread.
nach über 10 Jahren Bedenkzeit habe ich einen eBus-Adapter und ebusd auf einem Raspberry Pi mit meiner TEM-Controller-Wärmepumpenheizung verbunden. Mich interessieren Temperaturverläufe, abgegebene Wärmemenge etc. und vielleicht ein etwas tieferes Verständnis der Anlage. Aus Zerstörungsangst habe ich nur die lesende Hälfte des Interface bestückt und kann also nicht scannen oder aktiv Werte auslesen. Ich hatte gedacht, mir reichen die abgehörten Daten, die zwischen Controller und Bedienteil ausgetauscht werden.
In der Tat sehe ich sofort einige Standard-ebus-Nachrichten und einige unbekannte Nachrichten. Für die Standard-Nachrichten habe ich eigene Signaldefinitionen gemacht, in die ich die beobachteten Geräteadressen eingetragen habe (habe keine Standard-Messagenamen gefunden und mir selbst welche ausgedacht, vgl. angehängtes Log). Leider verstehe ich schon gar nicht, welches ebus-Device welches reale Gerät ist. Nach dem Neustart der Anlage melden sich folgende Adressen:
Zitataddress 03: master #11
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=TEM;ID=17385;SW=0106;HW=0100"
address 90: slave
address 91: slave
Dabei sendet 10 die "Regler"-Signale ("Room Controller" in der englischen Version), 03 und 13 sind Feuerungsautomaten ("Burner Control Unit"), 90 und 91 sind auch Feuerungsautomaten. Letztere Adressen werden für Betriebstunden- und Anlaufzähler-Abfragen benutzt. Adresse 15 sagt nach der Initialisierungsmeldung nichts mehr.
Meine Heizungsanlage enthält zwei Wärmepumpen (Abluft und Erdwärme) sowie zwei unabhängige Bedienteile (angeblich mit je einem "Heizkreis" verbunden). Wenn ich an einem Bedienteil die Uhrzeit verstelle, überträgt der regelmäßige Broadcast von Adresse 10 nach einigen Sekunden die neue Uhrzeit, welche erst dann vom anderen Bedienteil angezeigt wird. Ich finde aber keinen Hinweis, wie Adresse 10 an die geänderte Uhrzeit kommt. Genauso verhält es sich bei der Soll-Brauchwassertemperatur.
Meine Fragen an die Experten
- Können sich hinter 2 der gefundenen Adressen die Bedienteile verstecken?
- Kann es sein, dass ich ordentliche Standard-Ebus-Nachrichten sehe, aber einzelne Busteilnehmer (Bedienteile?) systematisch nicht bemerke? Der TEM-Controller hat nur einen ebus-Anschluss, an welchen beide Bedienteile und der Ebus-Adapter angeschlossen sind.
- Erkennt jemand ein Muster in den unbekannten Nicht-Standard-Nachrichten 100a (vgl. Anhang)? Ich habe z.B. nirgendwo eine Temperatur erraten können. Die john30-Howtos zum Thema kenne ich.
- Ist es vielleicht doch eine schlechte Idee, ein read-only Interface zu benutzen? Da geht offenbar nicht alles, wie Scan oder Conditions.
Danke für die Geduld und viele Grüße
Christoph "borg"
Zitat von: istler am 17 April 2018, 20:59:57
Hallo Christian,
Das wird bei den Start-Parametern des Daemon (ebusd) festgelegt:
https://github.com/john30/ebusd/wiki/2.-Run
--pollinterval=SEC
Poll for data every SEC seconds (0=disable) [5]
Gruß
Maik
Hallo Maik,
das ist ja super, genau nach sowas habe ich gesucht !!!
Danke :-)
Grüße
Christian
Hallo borg,
ich habe auch eine TEM Steuerung (mit Bartl WP).
Mit den Master-Master und Broadcast-Telegrammen habe ich mich leider noch nicht beschäftigt, kann dir also mit deinen Logs nur bedingt weiterhelfen.
Falls du aber verschiedene Werte lesen willst, kannst du die Master-Fernbedienung dafür "mißbrauchen". Dafür darf Ebusd aber nicht im read-only Modus gestartet werden, wenn ich mich recht erinnere.
Ich bin folgendermaßen vorgegangen:
- Ebusd in Grab Modus setzen
- Menüs auf der Master-FB auswählen und durchscrollen, damit die Werte angezeigt werden.
- In den Grabs solltest du nun Master-Slave Telegramme erhalten, die von der Master-FB getriggert werden
- Diese sind relativ einfach zu identifizieren, da der TEM-Code mit gesendet wird (Antwortbytes 1 + 2) und du die HEX-Werte mit den angezeigten Werten im Display vergleichen kannst.
Somit sollte es möglich sein, alle Werte per Ebusd abzufragen, die du auch mit der Fernbedienung abfragen kannst.
Eine relativ komplette csv (für meine Bartl) findest du hier: https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/TEM/bartl.csv
Hier: http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_7_v1_6_1_anhang_ausgabe_1.pdf gibts eine Übersicht über die Master/Slave Adressen. 15 ist die Slave Adresse des Reglers, 01 dürfte dann die Masteradresse einer deiner Fernbedienungen sein, wenn du die Abfragen triggerst. 90/91 sind Slave Adressen der Raumgeräte/Fernsteller - was auch immer das ist :p
Hinter deinen 1090 Nachrichten mit den vielen "Doppelbits" 03,0C und FF und der Durchnummerierung 30-37 vermute ich Zeitprogramme, die der Regler an das "Raumgerät" sendet. Hier gibt es mehrere verschiedene, z.b. 04, 05, 06 also z.B. 3004 und 3005, 3104 usw.
Wie der bytetream so eines Zeitprogramms aussieht, kannst du hier sehen: https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/TEM/bartl.csv#L103 Diese Nachrichten werden aneinandergehängt.
Vielleicht hilft dir das ja erstmal weiter.
Gruß
Andreas
PS: Ich fand diesen Online-Konverter hier http://manderc.com/concepts/umrechner/index.php sehr hilfreich. Ich habe mir das selbst auch etwas angepasst. Damit kannst du relativ schnell deine HEX Codes (1- und 2-Byte-weise) in Dezimal und einzelne Bits umwandeln, was die Entschlüsselung einfacher macht. Gerade bei den Zeitprogrammen brauchst du die einzelnen Bits... Darauf achten, dass die Datenbytes immer als einzelnes oder doppeltes Byte zu betrachten sind. Bei 2-Byte Werten ist allerdings die Endianess zu beachten, d.h. das kleinstwertigere Byte sitzt am Anfang. Aus 3004 muss dann 0430 werden, damit das Ergebnis richtig ist. Nur für den Fall, dass ich dir was neues erzählen konnte :)
Zitat von: borg am 17 April 2018, 23:34:22
Aus Zerstörungsangst habe ich nur die lesende Hälfte des Interface bestückt und kann also nicht scannen oder aktiv Werte auslesen. Ich hatte gedacht, mir reichen die abgehörten Daten, die zwischen Controller und Bedienteil ausgetauscht werden.
Ergänzend eine Erkenntnis, die mir kürzlich aufgefallen ist:
Der
--readonly Switch verträgt sich nicht mit
--scanconfig, da zumindest in meinem Fall kein externer Busteilnehmer die erforderdlichen Scans gestartet hat, die notwendig wären um die korrekten CSVs zu ermitteln.
Wenn also schon der Hardware-Sendeteil fehlt, sollte Ebusd mit --readonly gestartet werden um zu wissen, dass es nicht senden kann und eben ohne --scanconfig, wobei dann nur noch die passenden (bzw. keine gegenseitig kollidierenden CSVs) im Konfigurationsverzeichnis liegen dürfen.
Zitat von: rellla am 18 April 2018, 10:14:20
Somit sollte es möglich sein, alle Werte per Ebusd abzufragen, die du auch mit der Fernbedienung abfragen kannst.
Danke für die Antwort! Inzwischen bin ich etwas weiter. Die Fernbedienungen scheinen die Slave-Geräte mit den Adressen 90 und 91 zu sein. Sie senden weder Daten beim Menü-Durchsehen noch beim Wert-Einstellen. Sie werden zyklisch vom Controller abgefragt und können z.B. eine solche Antwort liefern:
Zitat
unknown MS cmd: 1091100a02200a / 0e300a700ac6a8080201000000aa91
Die eingestellte Uhrzeit sind 0a70 Minuten seit 0:00Uhr des vorherigen Dienstags. Es sind a8c6 Tage seit 1.1.1900. Ich versuche erstmal, passende Definitionen für ebusd aufzuschreiben. Ein einfaches ... 10,91,100a,02200a,... klappt nicht. Ich bleibe aber dran.
Viele Grüße
Der Fehler liegt darin, dass die 02 zwischen 1091100a und 200a die Länge der ID ist, die Ebusd selbst einfügt.
Eine Mögliche Definition für diese Nachricht wäre also:
r,,RemoteTEST,,,91,100a,200a,Wert1,,UIN,,,,Wert2,,UIN,,,,Wert3,,UIN,,,,Wert4,,UIN,,,,Wert5,,UIN,,,,Wert6,,UIN,,,,Wert7,,UIN,,,
(die Quelle 10 würde ich immer weglassen)
Zitat von: Sven77 am 19 April 2018, 09:16:07
Der Fehler liegt darin, dass die 02 zwischen 1091100a und 200a die Länge der ID ist, die Ebusd selbst einfügt.
Danke! Das habe ich nicht gewusst. Du rettest mir den Abend. :)
[...]
Zitat
(die Quelle 10 würde ich immer weglassen)
Habe auch nicht gewusst, dass das geht. Hatte nur probiert Quelle und Ziel wegzulassen, so wie in den Vorlagen. Und das ging nicht (ist auch logisch, bei mehreren Geräten mit gleichen Signalen).
Wie ist das eigentlich mit
Zitat
r,,RemoteTEST,,,
dem zweiten Parameter "circuit"? Ich hatte den Eindruck, dass ebusd wenigstens ab Version 3 darauf besteht, dass dieser angegeben wird. Konnte allerdings aus der Dokumentation nicht gut ablesen, was er bedeutet. Habe mal geraten, dass es irgendwie den Typ des Sendegeräts beschreibt und bei mir "ctrl" für Controller eingetragen.
Viele Grüße
Zitat von: borg am 19 April 2018, 10:37:54
Ich hatte den Eindruck, dass ebusd wenigstens ab Version 3 darauf besteht, dass dieser angegeben wird. Konnte allerdings aus der Dokumentation nicht gut ablesen, was er bedeutet. Habe mal geraten, dass es irgendwie den Typ des Sendegeräts beschreibt und bei mir "ctrl" für Controller eingetragen.
Sieh an, das mit Version 3 wusste ich noch nicht, ist aber gut möglich.
Man unterteilt so, zu welchem Gerät diese Nachricht gehört. In dem Fall dann aber eher "remote1" o.ä., weil sich diese Nachricht auf das Zielgerät bezieht, egal von welchem Slave sie kommt.
Zieladresse und Circuit(-Bezeichnung) kommen bei den mitgelieferten CSVs aus dem Dateinamen (Beispiel "08.hmu.csv" --> Ziel 08, Circuit "hmu").
Hier kannst Du aber frei einen Namen bestimmen, sie sollten sich nur nicht überschneiden, daher die 1 an meinem Vorschlag.
Zitat von: borg am 18 April 2018, 23:44:04
Danke für die Antwort! Inzwischen bin ich etwas weiter. Die Fernbedienungen scheinen die Slave-Geräte mit den Adressen 90 und 91 zu sein. Sie senden weder Daten beim Menü-Durchsehen noch beim Wert-Einstellen. Sie werden zyklisch vom Controller abgefragt und können z.B. eine solche Antwort liefern: Die eingestellte Uhrzeit sind 0a70 Minuten seit 0:00Uhr des vorherigen Dienstags. Es sind a8c6 Tage seit 1.1.1900. Ich versuche erstmal, passende Definitionen für ebusd aufzuschreiben. Ein einfaches ... 10,91,100a,02200a,... klappt nicht. Ich bleibe aber dran.
Ich glaube, ich habe mich falsch ausgedrückt... Wenn du die Menüs durchgehst, wäre es gut, wenn mehr 1090 bzw 1091 MS-Nachrichten auftauchen. Der Regler sendet an die Fernbedienungen habe ich natürlich gemeint. Ist das der Fall?
Was hast du für eine Wärmepumpe, bzw. haben deine Werte auch eine ID Nr. wie bei mir hier, z.B. 01-003 etc.?
Bei mir stellen nämlich die ersten 2 Byte in der Slave Antwort nach der Anzahl immer den TEM-Code dar.
10 91 100a 02 0005 / 06 1005 e200 0100
MM SS PBSB ID TEM Wert Wert
Aus 1005 würde dann 10-016 werden.
(Und e200 könnte entweder 226 oder 22.6 etc. werden, oder aber auch 0 und -30, falls e2 als signed integer betrachtet wird, oder ...)
Gruß
Andreas
Hallo borg,
nur noch ein Hinweis: im Tool ebusctl kann man sich auch die unbekannten Nachrichten dekodiert ausgeben lassen:
ebusctl grab result decode
Evlt. hilft das beim Analysieren.
Gruß
Maik
(Habe ein paar Tage gebraucht, um das weiter zu erforschen.)
Zitat von: rellla am 19 April 2018, 12:35:54
Ich glaube, ich habe mich falsch ausgedrückt... Wenn du die Menüs durchgehst, wäre es gut, wenn mehr 1090 bzw 1091 MS-Nachrichten auftauchen. Der Regler sendet an die Fernbedienungen habe ich natürlich gemeint. Ist das der Fall?
Das Bedienteil speichert alle Daten. Wenn ich Menüs durchgehe, passiert auf dem Bus nichts. Der Controller schickt vier verschiedene 100a Daten-Broadcasts im jeweils 80s-Zyklus: 1100/1000, 1101/1001, 1102/1002, 1103/1003. Die Daten der Anzeigen finde ich darin wieder und einiges mehr, was offenbar nicht angezeigt wird.
Wenn ich im Bedienteil Parameter ändere, passiert auf dem Bus immer noch nichts. Auch dafür schickt der Controller alle 80s an jedes Bedienteil eine Nachricht, diesmal eine Master-Slave-Message. In der Antwort wird ein Bit gesetzt für "habe neue Daten" und ein Code für den Datenbereich, in dem die Änderung liegt. Dieser wird dann vom Controller ausgelesen. Es wird auch noch eine Art Tokens ausgetauscht um sicherzugehen, dass die nur einmal zu lesende Änderung auch wirklich beim Controller ankommt.
Zitat
Was hast du für eine Wärmepumpe, bzw. haben deine Werte auch eine ID Nr. wie bei mir hier, z.B. 01-003 etc.?
Bei mir stellen nämlich die ersten 2 Byte in der Slave Antwort nach der Anzahl immer den TEM-Code dar.
10 91 100a 02 0005 / 06 1005 e200 0100
MM SS PBSB ID TEM Wert Wert
Aus 1005 würde dann 10-016 werden.
Das ist eine Hautec-Anlage von ca. 2006. Mit einer Abluft- und einer Erdwärmepumpe. Auf dem Controller steht "TEM SE 6000 WPC". Von TEM-Code habe ich bisher noch nie etwas gehört. Ich habe mal für eine Nachricht die auch hier vorkommenden Codes (s.o.) als TEM_P deklariert.
10 91 100a 02 200b / 0e 300b cd00 af00 f401 01000000 c091lese ich damit als
22-048;20.5;17.5;50.0;01 00 00 00 c0;91Welchen Vorteil hat diese Darstellung? Ich hätte 300b erst mal als übersichtlicher angesehen, zumal es auch 200b, 310b/300b, 310a/300a usw. gibt.
Gruß
Christoph
Zitat von: borg am 27 April 2018, 00:06:36
Das Bedienteil speichert alle Daten. Wenn ich Menüs durchgehe, passiert auf dem Bus nichts. Der Controller schickt vier verschiedene 100a Daten-Broadcasts im jeweils 80s-Zyklus: 1100/1000, 1101/1001, 1102/1002, 1103/1003. Die Daten der Anzeigen finde ich darin wieder und einiges mehr, was offenbar nicht angezeigt wird.
Wenn ich im Bedienteil Parameter ändere, passiert auf dem Bus immer noch nichts.
Schade, dann verhält sich die Anlage wohl doch anders...
Zitat
Auf dem Controller steht "TEM SE 6000 WPC".
Ok, hier ist es der TEM SE 6024 WPC ...
Zitat
Von TEM-Code habe ich bisher noch nie etwas gehört. Ich habe mal für eine Nachricht die auch hier vorkommenden Codes (s.o.) als TEM_P deklariert.
10 91 100a 02 200b / 0e 300b cd00 af00 f401 01000000 c091
lese ich damit als
22-048;20.5;17.5;50.0;01 00 00 00 c0;91
Welchen Vorteil hat diese Darstellung? Ich hätte 300b erst mal als übersichtlicher angesehen, zumal es auch 200b, 310b/300b, 310a/300a usw. gibt.
Das hat den Hintergrund, dass bei meiner WP alle Parameter durchnummeriert sind und diese Nummern sowohl im Menu des Bedienteils als auch in der Parameterliste der Anleitung angegeben sind. So lassen sich die Messages dann relativ einfach zuordnen. Aber wie es aussieht, läuft das bei deiner Steuerung etwas anders... Kann dir dann wohl beim Entschlüsseln doch nicht so weiterhelfen wie ich dachte :/
Gruß
Andreas
Bei mir läuft ein Calormatic VRC470 Regler + Solar für Warmwasser/Heizung + 700L Speicher + Gastherme.
Ist es möglich die Speicheraufheizung via Gastherme auf Knopfdruck zu deaktivieren? (Es soll ein Kinderpool mit Warmwasser befüllt werden)
Es ist mir noch nicht ganz klar, wie das gemeint ist.
Aber ich würde für diesen Fall eher einen ganz primitiven eigenen Wärmetauscher an den Solarkreislauf klemmen (zweites Wellrohr ein paar Meter entlang der Solarleitung, innerhalb einer - dann neu gemachten - isolierung) und dort einfach etwas von der solar erzeugten Wärme abgreifen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 03 Juli 2018, 15:34:53
Es ist mir noch nicht ganz klar, wie das gemeint ist.
ich würde ganz einfach einen Schlauch am Warmwasserhahn im HWR anschließen und den Pool befüllen.
Die Speicheraufheizung via Gastherme sollte dann deaktiviert sein, das er nicht nachlädt wenn der Speicher "leer" ist, sondern die Wärme vom Solarkreis gleich weitergibt (Ist ja im Sommer ausreichend vorhanden - der kreis hat dann um die 120 Grad)
Zitat von: NemoN am 04 Juli 2018, 08:56:35
ich würde ganz einfach einen Schlauch am Warmwasserhahn im HWR anschließen und den Pool befüllen.
vermutlich ließe sich über HwcCircuitActive (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/15.470.csv#L57) einfach der Warmwasserkreis abstellen oder über HwcOPMode das Laden abschalten, aber so ganz sicher bin ich da nicht.
...wenn es eine einmalige Sache sein soll, wäre es evtl. auch möglich einfach Tage der Abwesenheit / Urlaub in der Steuerung einzustellen, dann wird auch nicht über Therme nachgeladen... Oder einfach die Therme abstellen...
Was macht ihr jetzt wenn ihr im Urlaub seid? Last ihr die Solarflüssigkeit die Urlaubszeit vor sich hin köcheln? :-\
Ich dachte mir, dann kann ich doch während ich im Urlaub bin, Nachts meinen Speicher leer fahren und die Umwelt etwas heizen... Damit ich Tagsüber wieder den Solarertrag einfahren kann, bzw. eine Solarflüssigkeit in Bewegung halte.
Mit dem Befehl:
ebusctl hex 26b506020206
Startet der Testmod Kollektor1-Pumpe. Ggf. werden dann andere Pumpen weggeschaltet, dies ist auf jeden Fall der Fall, wenn man den Test über das Bedienteil startet. Zur Zeit ist aber meine Heizung eh aus...
Mit dem Befehl:
ebusctl hex 26b5060101
Wird die Kollektor1-Pumpe wieder abgeschaltet.
Sonnige Grüße
Maik
ähm, also ich hatte die Frage so verstanden, dass der Inhalt des Speichers, welcher durch Solar geheizt wurde, in den Pool sollte bis Speicher leer ist, aber eben dann nicht (wenn Nachladetemperatur erreicht wurde) mit der Therme der Speicher nachgeladen werden soll. Sonst müßte der Fragensteller das ggf. noch mal näher beschreiben, was er tun möchte, bevor wir hier 20 Lösungen haben, die nur leider nicht zum Problem passen...
Grüße
Christian
Zitat von: cs-online am 05 Juli 2018, 08:01:22
ähm, also ich hatte die Frage so verstanden, dass der Inhalt des Speichers, welcher durch Solar geheizt wurde, in den Pool sollte bis Speicher leer ist, aber eben dann nicht (wenn Nachladetemperatur erreicht wurde) mit der Therme der Speicher nachgeladen werden soll.
genau so
mit HwcCircuitActive = no müßte der WW-Kreis deaktiviert werden, danach läd die Therme nicht nach, bis HwcCircuitActive = yes gesetzt wird. Das müßte aber auch in der Steuerung deaktiviert werden können. Also falls das nur für mal sein soll, dann wäre das über Ebusd evtl. etwas too much...
Vor allem erschließt sich mir nicht, warum man einen Speicher mit kaltem Wasser vorhalten sollte.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 06 Juli 2018, 12:23:48
Vor allem erschließt sich mir nicht, warum man einen Speicher mit kaltem Wasser vorhalten sollte.
Ich will auch keinen kalten Speicher haben :-)
Nachdem ich den Speicher wärmetechnisch leer gemacht habe (und der Pool hoffentlich gut temperiert ist) kann der Solarkreis den Speicher natürlich wieder aufladen, welches vermutlich nicht allzu lange dauert. Aber ich möchte nicht, daß die Steuerung dazwischenfunkt mit "Speicher ist leer, Wärmeanforderung an die Gastherme". Ich könnte auch testen die Gastherme hart via Netzschalter auszuschalten.
Zitat von: Prof. Dr. Peter Henning am 06 Juli 2018, 12:23:48
Vor allem erschließt sich mir nicht, warum man einen Speicher mit kaltem Wasser vorhalten sollte.
Es geht um die Urlaubszeit, wenn keiner Warmwasser benötigt, aber das Wetter Zuhause Urlaub macht. Dann ist der Speicher permanent voll und die Solarkollektoren können ihre Wärme nicht abgeben. Damit erhitzten diese sich sehr ( > 150 °C). Diese mag aber wiederum das Glykol, das als Frostschutz in der Solarflüssigkeit vorhanden ist nicht besonders gerne. Das Glykol wechselt dann vom flüssigen in den gasförmigen Zustand (Druckzunahme). Dabei können Feststoffe im System entstehen und das Glykol verliert die Frostschutz-Eigenschaft. Die Solarflüssigkeit ist nicht sofort unbrauchbar, aber nach ein paar Jahren, ist der Frostschutz nicht mehr gegeben und die Flüssigkeit auch ganz trübe.
Um halt ein bisschen nett zu seiner Anlage zu sein, kann man, wenn man nicht zu Hause ist, halt nachts seinen Speicher leer fahren, damit tagsüber die Solarflüssigkeit nicht so stark strapaziert wird, und sie nur wohl temperiert wird, indem der kalte Speicher die Wärme aufnehmen kann.
Es soll ja sogar Leute geben, die Markisen über ihre Solarkollektoren gebaut haben, die diese dann beschatten, wenn der Speicher voll ist....
Mein Beitrag war ohne Bezug auf NemoN.
Gruß
Maik
Erstens ist die meistverwendete Flüssigkeit TYFOCOR auch bei 170°C langzeitstabil, erst ab ca. 200°C wird es kritisch (siehe https://www.tyfo.de/uploads/TI/Ti_TYFOCOR-LS_de.pdf)
Zweitens fängt es schin bei 105°C an zu sieden, keineswegs erst ab 150!C.
Siehe hierzu auch die von mir vor x Jahren vorgestellte Formel zur Ertragsmessung, https://wiki.fhem.de/wiki/Ertragsmessung_Solarthermie.
Das Problem der Überhitzung des Speichers lässt sich problemlos lösen, indem man die Zirkulationspumpe anschaltet und die Wärme im Haus verteilt. Das ist zwar nicht sehr intelligent, aber immer noch schlauer, als deswegen ein Kinderplanschbecken anzuschaffen.
Eine intelligentere Lösung besteht darin, die Solarpumpe kurzzeitig zwangsweise anzuschalten. Auch wenn der Speicher nichts mehr aufnehmen kann, verhindert dies das Ausfällen.
LG
pah
hmmm wie groß ist der Pool denn ? Meiner hat ca.7000 Liter und wenn ich da meinen 300 Liter Speicher mit 70 Grad reinlaufen lasse, dann erwärmt sich das ganze um ca. 2-3 Grad. Das hats bei mir nicht gebracht und deshalb hab ich das aufgegeben....
Es geht wohl um die Kühlung des Speichers, nicht um die Erwärmung des Pools.
LG
pah
Hi @ all
gibts irgendwo ne kpl. Anleitung zum betreiben von 2 EBUS Adaptern??
Ich bekomme den 2ten nicht zum laufen, er findet keine master/slaves
config:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
# In order to run multiple ebusd instances, simply define several EBUSD_OPTS
# with a unique suffix for each.
# Recommended is using a number as suffix for all EBUSD_OPTS settings.
# That number can then be used as additional "instance" parameter to the init.d
# script in order to start/stop an individual ebusd instance instead of all
# instances.
# Example (uncomment the EBUSD_OPTS above):
EBUSD_OPTS1="--lograwdata=Bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
EBUSD_OPTS2="--lograwdata=Bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"
INFO
pi@ospi ~ $ ebusctl info
version: ebusd 3.0.v3.0
signal: acquired
symbol rate: 22
max symbol rate: 94
reconnects: 0
masters: 3
messages: 461
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004276']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
allerdings sind dies nur master/slave des ersten EBUSD_OPTS1, EBUSD_OPTS2 scheint nix zu finden / zu machen.
ein Test für EBUSD_OPTS2 pi@ospi ~ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 bringt nur 2018-07-22 09:59:18.727 [bus notice] bus started with own address 31/36
2018-07-22 09:59:18.766 [bus notice] signal acquired
ein Test für EBUSD_OPTS1 pi@ospi ~ $ ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 bringt
2018-07-22 09:58:54.475 [bus notice] bus started with own address 31/36
2018-07-22 09:58:54.493 [bus notice] signal acquired
2018-07-22 09:58:56.377 [bus notice] new master 10, master count 2
2018-07-22 09:58:56.445 [bus notice] new master 03, master count 3
hat jemand ne idee???
MfG Maik
Zitat von: TiPpFeHlEr am 22 Juli 2018, 10:11:20
Ich bekomme den 2ten nicht zum laufen, er findet keine master/slaves
ist der Adapter mit Poti und wenn ja, hast das schon justiert?
Ansonsten einfach mal die raw Bytes ausgeben lassen (--lograwdata=bytes) und schauen, ob 0xAA dabei ist.
Hallo Maik,
für jeden ebusd müssen auch die Service Ports festgelegt werden, über die z. B. ebusctl auf den ebusd zugreift. Ebenso musst du beim Aufruf von ebusctl dann auch den passenden Port vom ebusd angeben.
Standardmäßig sind die Ports mit Default Werten angegeben. Daher wird der erste ebusd korrekt starten und wenn du ebusctl aufrust, wird dies sich über die Defaultsports mit dem 1. ebusd verbinden.
Gruß
Maik
Gesendet von meinem Aquaris_A4.5 mit Tapatalk
Zitat von: john30 am 22 Juli 2018, 11:59:55
ist der Adapter mit Poti und wenn ja, hast das schon justiert?
Ansonsten einfach mal die raw Bytes ausgeben lassen (--lograwdata=bytes) und schauen, ob 0xAA dabei ist.
Hi john
pi@ospi ~ $ ebusd -f -c /tmp --logareas bus --lograwdata=bytes --loglevel info -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889
2018-07-22 14:52:28.686 [bus notice] bus started with own address 31/36
2018-07-22 14:52:28.702 [bus notice] <aa
2018-07-22 14:52:28.702 [bus notice] signal acquired
2018-07-22 14:52:28.745 [bus notice] <aa
2018-07-22 14:52:28.788 [bus notice] <aa
2018-07-22 14:52:28.831 [bus notice] <aa
2018-07-22 14:52:28.873 [bus notice] <aa
2018-07-22 14:52:28.917 [bus notice] <aa
2018-07-22 14:52:28.960 [bus notice] <aa
2018-07-22 14:52:29.003 [bus notice] <aa
2018-07-22 14:52:29.046 [bus notice] <aa
2018-07-22 14:52:29.089 [bus notice] <aa
2018-07-22 14:52:29.132 [bus notice] <aa
2018-07-22 14:52:29.174 [bus notice] <aa
2018-07-22 14:52:29.217 [bus notice] <aa
2018-07-22 14:52:29.260 [bus notice] <aa
2018-07-22 14:52:29.302 [bus notice] <aa
2018-07-22 14:52:29.346 [bus notice] <aa
2018-07-22 14:52:29.388 [bus notice] <aa
2018-07-22 14:52:29.430 [bus notice] <aa
2018-07-22 14:52:29.473 [bus notice] <aa
2018-07-22 14:52:29.516 [bus notice] <aa
2018-07-22 14:52:29.559 [bus notice] <aa
2018-07-22 14:52:29.602 [bus notice] <aaaa kommt kontinuierlich ;)
Zitat von: istler am 22 Juli 2018, 12:20:22
Hallo Maik,
für jeden ebusd müssen auch die Service Ports festgelegt werden, über die z. B. ebusctl auf den ebusd zugreift. Ebenso musst du beim Aufruf von ebusctl dann auch den passenden Port vom ebusd angeben.
Standardmäßig sind die Ports mit Default Werten angegeben. Daher wird der erste ebusd korrekt starten und wenn du ebusctl aufrust, wird dies sich über die Defaultsports mit dem 1. ebusd verbinden.
Gruß
Maik
Gesendet von meinem Aquaris_A4.5 mit Tapatalk
die ports sind zugewiesen
EBUSD_OPTS1="--lograwdata=Bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTFOL-if00-port0 -p 8888 -l /var/log/ebusd.log"
EBUSD_OPTS2="--lograwdata=Bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 3.0.v3.0
signal: acquired
symbol rate: 24
max symbol rate: 24
reconnects: 0
masters: 1
messages: 15
conditional: 0
poll: 0
update: 7
address 04: slave #25, ebusd
address ff: master #25, ebusd
leider meldet sich die Lüftung nicht bei scan.
Dies hatte sie aber schon mal gemacht, bevor ich auf einen E-Bus Koppler umgebaut hatte.
Dort lief die Lüftung an einem V32 EBUS Adapter von Vaillant, da die Lüftung auch ein Energie Erzeuger des Typ's BAI00 darstellt. Damals lief Sie als BAI.... an dem zweiten EBUS Koppler.
nun muss ich halt wieder auf 2 separate Koppler umstellen.
MfG Maik
so......
hab einfach mal agressiv auf den BUS gefragt
mitpi@ospi ~ $ ebusctl -p 8889 hex 08b509030d8a03
0101
und siehe da, es Antwortet jemand ;D
2018-07-22 15:04:07.678 [bus info] send message: 3108b509030d8a03
2018-07-22 15:04:07.708 [bus notice] <aa
2018-07-22 15:04:07.709 [bus notice] >31
2018-07-22 15:04:07.715 [bus notice] <31
2018-07-22 15:04:07.716 [bus notice] >08
2018-07-22 15:04:07.723 [bus notice] <08
2018-07-22 15:04:07.723 [bus notice] >b5
2018-07-22 15:04:07.730 [bus notice] <b5
2018-07-22 15:04:07.731 [bus notice] >09
2018-07-22 15:04:07.737 [bus notice] <09
2018-07-22 15:04:07.738 [bus notice] >03
2018-07-22 15:04:07.744 [bus notice] <03
2018-07-22 15:04:07.745 [bus notice] >0d
2018-07-22 15:04:07.751 [bus notice] <0d
2018-07-22 15:04:07.752 [bus notice] >8a
2018-07-22 15:04:07.758 [bus notice] <8a
2018-07-22 15:04:07.759 [bus notice] >03
2018-07-22 15:04:07.765 [bus notice] <03
2018-07-22 15:04:07.766 [bus notice] >a1
2018-07-22 15:04:07.772 [bus notice] <a1
2018-07-22 15:04:07.778 [bus notice] <00
2018-07-22 15:04:07.788 [bus notice] <01
2018-07-22 15:04:07.792 [bus notice] <01
2018-07-22 15:04:07.796 [bus notice] <9a
2018-07-22 15:04:07.797 [bus notice] >00
2018-07-22 15:04:07.803 [bus notice] <00
2018-07-22 15:04:07.803 [bus notice] new master 03, master count 2
genialerweise wurde nun ein master (08) gefunden.
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 3.0.v3.0
signal: acquired
symbol rate: 23
max symbol rate: 39
reconnects: 0
masters: 2
messages: 0
conditional: 0
poll: 0
update: 0
address 03: master #11
address 08: slave #11
address 31: master #8, ebusd
address 36: slave #8, ebusd
pi@ospi ~ $ ebusctl -p 8889 scan result
08;Vaillant;recoV;0217;0203
beim start des ebusd wird aber nix gefunden und somit keine csv geladen, diese existiert bereits
pi@ospi /etc/ebusd/vaillant $ ls
08.bai.csv 38.v32.csv currentservice.inc hwcmode.inc roomtempoffset.inc tempsetpoints.inc timerhc.inc
08.recoV.csv bai.308523.inc errors.inc mcmode.inc scan.csv timercc.inc timerhwc.inc
15.470.csv broadcast.csv hcmode.inc quick.inc _templates.csv timercool.inc timer.inc
warum meldet der sich nicht beim start??
so weitere Test's
bei einem scan full von Hand, meldet sich die recoVair
2018-07-22 16:04:33.512 [bus info] scan 08 cmd: 3108070400
2018-07-22 16:04:33.988 [bus notice] <aa
2018-07-22 16:04:33.989 [bus notice] >31
2018-07-22 16:04:33.995 [bus notice] <31
2018-07-22 16:04:33.996 [bus notice] >08
2018-07-22 16:04:34.002 [bus notice] <08
2018-07-22 16:04:34.004 [bus notice] >07
2018-07-22 16:04:34.009 [bus notice] <07
2018-07-22 16:04:34.010 [bus notice] >04
2018-07-22 16:04:34.016 [bus notice] <04
2018-07-22 16:04:34.017 [bus notice] >00
2018-07-22 16:04:34.023 [bus notice] <00
2018-07-22 16:04:34.024 [bus notice] >d1
2018-07-22 16:04:34.031 [bus notice] <d1
2018-07-22 16:04:34.038 [bus notice] <00
2018-07-22 16:04:34.045 [bus notice] <0a
2018-07-22 16:04:34.049 [bus notice] <b5
2018-07-22 16:04:34.052 [bus notice] <72
2018-07-22 16:04:34.056 [bus notice] <65
2018-07-22 16:04:34.061 [bus notice] <63
2018-07-22 16:04:34.065 [bus notice] <6f
2018-07-22 16:04:34.069 [bus notice] <56
2018-07-22 16:04:34.073 [bus notice] <02
2018-07-22 16:04:34.078 [bus notice] <17
2018-07-22 16:04:34.082 [bus notice] <02
2018-07-22 16:04:34.086 [bus notice] <03
2018-07-22 16:04:34.091 [bus notice] <67
2018-07-22 16:04:34.092 [bus notice] >00
2018-07-22 16:04:34.098 [bus notice] <00
2018-07-22 16:04:34.098 [bus notice] new master 03, master count 2
2018-07-22 16:04:34.098 [bus notice] scan 08: ;Vaillant;recoV;0217;0203
einige Sekunde vorher ist eine Anfrage des ebusd zu sehen, aber ohne Antwort
2018-07-22 16:04:21.484 [bus info] send message: 31fe070400
2018-07-22 16:04:21.522 [bus notice] <aa
2018-07-22 16:04:21.523 [bus notice] >31
2018-07-22 16:04:21.529 [bus notice] <31
2018-07-22 16:04:21.530 [bus notice] >fe
2018-07-22 16:04:21.536 [bus notice] <fe
2018-07-22 16:04:21.537 [bus notice] >07
2018-07-22 16:04:21.543 [bus notice] <07
2018-07-22 16:04:21.544 [bus notice] >04
2018-07-22 16:04:21.550 [bus notice] <04
2018-07-22 16:04:21.551 [bus notice] >00
2018-07-22 16:04:21.557 [bus notice] <00
2018-07-22 16:04:21.558 [bus notice] >14
2018-07-22 16:04:21.565 [bus notice] <14
die recoVair scheint nicht auf die standart Frage zu antworten
nur wenn sie direkt angesprochen wird
pi@ospi ~ $ ebusctl -p 8889 hex fe070400
done broadcast
pi@ospi ~ $ ebusctl -p 8889 hex 08070400
0ab57265636f5602170203
hab das Problem mit dem scan erstmal behoben.
Indem ich --scanconfig=08 benutze beim ebusd start.
Die recoVair meldet sich nun, es wird aber keine csv geladen.
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 3.0.v3.0
signal: acquired
symbol rate: 42
max symbol rate: 108
reconnects: 0
masters: 2
messages: 17
conditional: 0
poll: 0
update: 7
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203"
address ff: master #25, ebusd
Interresant ist das INFO des anderen Adapters mir zusätzliche Meldungen bringt
pi@ospi ~ $ ebusctl -p 8888 info
version: ebusd 3.0.v3.0
update check: version 3.2 available, broadcast.csv: different version available, vaillant/08.bai.csv: different version available, vaillant/15.470.csv: different version available, vaillant/bai.308523.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different versio
signal: acquired
symbol rate: 22
max symbol rate: 256
reconnects: 0
masters: 3
messages: 461
conditional: 3
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004276']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Hier wird mir gesagt das es updates gibt.
Ist das normal oder ein Fehler?
PUSH
kann mir jemand sagen ob ich das laden einer CSV erzwingen kann, oder warum sie nicht geladen wird?
MfG Maik
Zitat von: TiPpFeHlEr am 29 Juli 2018, 10:24:08
kann mir jemand sagen ob ich das laden einer CSV erzwingen kann, oder warum sie nicht geladen wird?
für die recovair gibt es keine csv
Zitat von: john30 am 29 Juli 2018, 10:25:57
für die recovair gibt es keine csv
Ähm ich habe ja eine selber gemacht, die ging ja schon als ich es über einen Adapter laufen ließ.
Sie heißt 08.recoV.csv und liegt im Ordner vaillant!
Mfg Maik
Zitat von: TiPpFeHlEr am 29 Juli 2018, 15:01:49
Sie heißt 08.recoV.csv und liegt im Ordner vaillant!
ach so, dann einfach nur Kleinbuchstaben verwenden, sollte genügen.
AHHHHHH ::)
08.recov.csv geht :o
pi@ospi ~ $ ebusctl -p 8889 info
version: ebusd 3.0.v3.0
signal: acquired
symbol rate: 53
max symbol rate: 114
reconnects: 0
masters: 2
messages: 68
conditional: 0
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203", loaded "vaillant/08.recov.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
aber wieso geht
08.reco.csv nicht??
MfG Maik
Vorab mal ein riesen Dankeschön für diese super Arbeit :D
Ich möchte die Frage mit dem Config Laden nochmal aufnehmen, da es bei mir nicht wie erwartet funktioniert. Ich habe hier eine Vaillant AuroCompact und als Steuerung eine Multimatic VRC700.
Das Erste was mich wundert ist, dass die VRC700 offenbar gar nicht gefunden wird, aber über das BAI00 (vermutlich das kleinere Steuerdisplay) kann ich bisher fast alles gewünschte erledigen.
Das fast bezieht sich darauf, dass ich auf den Solarbereich der Anlage nicht komme, das wäre aber auch bei der VRC700 so.
Das Solarmodul ist das, was auf address 06 gefunden wird und hier beginnt nun mein Problem.
Für das VMS01 gibt es keine .csv. Ich habe mir aber mal die 06.pms.csv angesehen und einzelne Adressen daraus mal mit ebusctl hex ausprobiert. Die für mich relevanten Adressen konnte ich damit als korrekt bestätigen und wollte nun entsprechend die .csv verwenden, also habe ich diese kopiert und unter dem Namen 06.vms01.csv unter /etc/ebusd/vaillant abgelegt. Nach meinem Verständnis hätte diese Datei nun geladen werden müssen, doch das passiert nicht. Muss ich noch mehr an der Datei ändern als nur den Namen?
ebusctl i
version: ebusd 3.2.v3.2
update check: revision v3.2-2-g1737636 available, broadcast.csv: newer version available, vaillant/bai.0010015600.inc: newer version available, vaillant/broadcast.csv: newer version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: newer version available
signal: acquired
symbol rate: 50
max symbol rate: 100
min arbitration micros: 836
max arbitration micros: 1230
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 4
messages: 198
conditional: 2
poll: 0
update: 9
address 00: master #1
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=VMS01;SW=0116;HW=0303"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/bai.0010015600.inc" ([PROD='0010015609']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Ich dachte bisher, dass nur die ersten 3 Stellen der ID für die CSV benutzt werden - dadurch verstehe ich aber das "recov" im Beispiel oben nicht.
Definitiv wird bei meiner PMS02 aber die 06.pms.csv geladen:
address 06: slave #2, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
Also wäre mein Tipp, die Datei mal 02.vms.csv zu benennen!
Habe mal sowohl 2.vms.csv, 02.vms.csv, 6.vms.csv und 06.vms.csv ausprobiert, wurde aber nichts geladen.
Rechteproblem ?
LG
pah
Die Datei hat die gleichen Berechtigungen wie alle anderen im Verzeichnis.
Laut Log findet er keine passende Datei
2018-08-01 08:54:00.222 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-01 08:54:00.222 [update notice] store 06 ident: done
2018-08-01 08:54:00.222 [update notice] sent scan-read scan.06 QQ=31: Vaillant;VMS01;0116;0303
2018-08-01 08:54:00.222 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-01 08:54:00.317 [main error] unable to load scan config 06: no file from vaillant with prefix 06 matches ID "vms01", SW0116, HW0303
2018-08-01 08:54:00.317 [main error] scan config 06: ERR: element not found
So wie ich das verstanden habe, läd der aktuelle ebusd die csv aus dem Internet? Kann es dann sein, dass er meine lokale gar nicht sucht? Muss ich da noch eine Pfadangabe machen, der Daemon startet nur mit scanconfig und enablehex
Hallo,
no file from vaillant with prefix 06 matches ID "vms01", SW0116, HW0303
Wenn ich das richtig interpretiere:
4 Dinge müssen hier zusammen kommen, damit die Datei geladen wird:
1) Die Datei muss mit 06 anfangen
2) Die Datei muss einen Eintrag auf vms01 enthalten
3) in der Datei muss ein SW-Stand drin sein, der mit SW0116 kompatibel ist
4) in der Datei muss ein HW-Stand eingetragen sein, der mit HW0303 passt
hier scheint es so zu sein, dass es möglicherweise zwar eine Datei gibt, die den richtigen Namen hat (also im Dateisystem so zu sehen ist), aber nicht m it den Kriterien SOFTWARESTAND DER ANLAGE (SW0116), UND HARDWARESTAND DER ANLAGE (HW0303) übereinstimmt. Daher kann EBUSD die Datei nicht laden.
Die Frage ist nun: Sind die SW- und HW-Versionen so unterschiedlich, dass sich die vorhandene Datei gar nicht nutzen lässt oder kannst Du in der Datei "einfach" auf deine Stände umschreiben ?
Umschreiben sollte gehen, muss nur nachher mal schauen, wie ich das eintragen muss. Hatte es bisher nur so verstanden, dass ausschließlich der Dateiname relevant ist.
Ursprünglich hieß die Datei bei mir auch 06.vms01.csv, da wurde die aber auch nicht geladen.
Ich habe noch ein wenig probiert. Wie vermutet, läd die csv vom Server. Damit ist klar, dass er dann natürlich keine csv für das VMS01 findet. Solange ich mit scanconfig arbeite, verhält sich ebusd so. Wenn ich das scanconfig wegehme und mit -c ein Verzeichnis angebe, werden nur csv von Geräten geladen, die sofort erkannt werden. Das VMS01 wird zwar als Slave angezeigt, aber ohne ID. Erst ein ebusctl scan sorgt dafür, dass auch die ID erkann und angezeigt wird, laut Log gibt es dann aber keinen Versuch mehr, eine passende csv zu laden.
Ich bin mir nun bei diesem Verhalten nicht sicher, ob ich etwas falsch mache oder ob es einen allgemeinen Fehler gibt.
Installiert habe ich die aktuellste .deb für den Raspi mit libmosquitto1, habe also nicht selber kompiliert.
--- edit ---
Ich war jetzt mal am Laptop und konnte da ein Log erstellen:
[07:24:49] openhabian@openHABianPi:~$ sudo ebusd --loglevel=debug -c /etc/ebusd
[spoiler]2018-08-02 07:25:56.029 [main notice] ebusd 3.2.v3.2 started
2018-08-02 07:25:56.029 [main info] loading configuration files from /etc/ebusd
2018-08-02 07:25:56.029 [main info] reading templates /
2018-08-02 07:25:56.032 [main info] read templates in /
2018-08-02 07:25:56.032 [main info] reading file memory.csv
2018-08-02 07:25:56.034 [main info] successfully read file memory.csv
2018-08-02 07:25:56.034 [main info] reading file broadcast.csv
2018-08-02 07:25:56.036 [main info] successfully read file broadcast.csv
2018-08-02 07:25:56.036 [main info] reading dir vaillant
2018-08-02 07:25:56.037 [main info] reading templates vaillant
2018-08-02 07:25:56.044 [main info] read templates in vaillant
2018-08-02 07:25:56.044 [main info] reading file vaillant/06.vms01.csv
2018-08-02 07:25:56.054 [main info] successfully read file vaillant/06.vms01.csv
2018-08-02 07:25:56.054 [main info] reading file vaillant/scan.csv
2018-08-02 07:25:56.055 [main info] successfully read file vaillant/scan.csv
2018-08-02 07:25:56.055 [main info] reading file vaillant/broadcast.csv
2018-08-02 07:25:56.056 [main info] successfully read file vaillant/broadcast.csv
2018-08-02 07:25:56.056 [main info] reading file vaillant/general.csv
2018-08-02 07:25:56.057 [main info] successfully read file vaillant/general.csv
2018-08-02 07:25:56.057 [main info] reading file vaillant/08.bai.csv
2018-08-02 07:25:56.059 [main info] successfully read file vaillant/08.bai.csv
2018-08-02 07:25:56.059 [main info] successfully read dir vaillant
2018-08-02 07:25:56.059 [main info] reading dir old
2018-08-02 07:25:56.059 [main info] successfully read dir old
2018-08-02 07:25:56.059 [main info] read config files
2018-08-02 07:25:56.061 [bus notice] bus started with own address 31/36
2018-08-02 07:25:56.061 [main info] registering data handlers
2018-08-02 07:25:56.061 [main info] registered data handlers
2018-08-02 07:25:56.064 [bus debug] ERR: SYN received during no signal, switching to ready
2018-08-02 07:25:56.064 [bus notice] signal acquired
2018-08-02 07:25:59.441 [bus notice] new master 03, master count 2
2018-08-02 07:25:59.464 [bus notice] new master 01, master count 3
2018-08-02 07:25:59.464 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:25:59.464 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:02.824 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:04.705 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:04.784 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:04.788 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:04.848 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:26:06.062 [main debug] performing regular tasks
2018-08-02 07:26:06.065 [bus info] send message: 3108b5090124
2018-08-02 07:26:06.073 [bus debug] arbitration delay 1216 micros
2018-08-02 07:26:06.074 [bus info] arbitration delay 1216 - 1216 micros
2018-08-02 07:26:06.074 [bus debug] switching from ready to send command
2018-08-02 07:26:06.081 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.081 [bus info] send/receive symbol latency 6 - 6 ms
2018-08-02 07:26:06.088 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.095 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.095 [bus info] send/receive symbol latency 5 - 6 ms
2018-08-02 07:26:06.102 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.109 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.109 [bus debug] switching from send command to send command CRC
2018-08-02 07:26:06.116 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.116 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:26:06.121 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:26:06.170 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:26:06.174 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:26:06.181 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.181 [update info] sent MS cmd: 3108b5090124 / 09003231313732353030
2018-08-02 07:26:06.181 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:26:06.181 [bus debug] notify request: done
2018-08-02 07:26:06.181 [bus debug] read res: 09003231313732353030
2018-08-02 07:26:06.182 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:26:06.182 [bus info] send message: 3108b5090125
2018-08-02 07:26:06.188 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.240 [bus debug] arbitration delay 1226 micros
2018-08-02 07:26:06.240 [bus info] arbitration delay 1216 - 1226 micros
2018-08-02 07:26:06.240 [bus debug] switching from ready to send command
2018-08-02 07:26:06.247 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.254 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.261 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.268 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.275 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.275 [bus debug] switching from send command to send command CRC
2018-08-02 07:26:06.282 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.282 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:26:06.286 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:26:06.334 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:26:06.339 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:26:06.346 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.346 [update info] sent MS cmd: 3108b5090125 / 09313030313536303933
2018-08-02 07:26:06.347 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:26:06.347 [bus debug] notify request: done
2018-08-02 07:26:06.347 [bus debug] read res: 09313030313536303933
2018-08-02 07:26:06.347 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:26:06.347 [bus info] send message: 3108b5090126
2018-08-02 07:26:06.353 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.404 [bus debug] arbitration delay 845 micros
2018-08-02 07:26:06.405 [bus info] arbitration delay 845 - 1226 micros
2018-08-02 07:26:06.405 [bus debug] switching from ready to send command
2018-08-02 07:26:06.412 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.419 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.426 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.433 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.440 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.440 [bus debug] switching from send command to send command CRC
2018-08-02 07:26:06.447 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.447 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:26:06.453 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:26:06.499 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:26:06.503 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:26:06.510 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.510 [update info] sent MS cmd: 3108b5090126 / 09313030303035363739
2018-08-02 07:26:06.511 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:26:06.511 [bus debug] notify request: done
2018-08-02 07:26:06.511 [bus debug] read res: 09313030303035363739
2018-08-02 07:26:06.511 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:26:06.511 [bus info] send message: 3108b5090127
2018-08-02 07:26:06.517 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.568 [bus debug] arbitration delay 845 micros
2018-08-02 07:26:06.569 [bus debug] switching from ready to send command
2018-08-02 07:26:06.576 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.583 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.590 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.597 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.604 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.604 [bus debug] switching from send command to send command CRC
2018-08-02 07:26:06.611 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:26:06.611 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:26:06.616 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:26:06.664 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:26:06.668 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:26:06.675 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.675 [update info] sent MS cmd: 3108b5090127 / 094e343c3c3c3c3c3c3c
2018-08-02 07:26:06.675 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:26:06.676 [bus debug] notify request: done
2018-08-02 07:26:06.676 [bus debug] read res: 094e343c3c3c3c3c3c3c
2018-08-02 07:26:06.676 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:26:06.683 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:26:06.741 [main notice] found messages: 261 (2 conditional on 24 conditions, 0 poll, 9 update)
2018-08-02 07:26:09.691 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:09.691 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:12.883 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:14.550 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:14.630 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:14.634 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:14.694 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:26:16.741 [main debug] performing regular tasks
2018-08-02 07:26:19.874 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:19.874 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:22.936 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:23.461 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:24.380 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:24.459 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:24.463 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:24.524 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:26:26.741 [main debug] performing regular tasks
2018-08-02 07:26:30.092 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:30.093 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:32.983 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:34.260 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:34.340 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:34.344 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:34.404 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:26:36.742 [main debug] performing regular tasks
2018-08-02 07:26:40.318 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:40.318 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:43.073 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:44.091 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:44.169 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:44.173 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:44.233 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:26:46.742 [main debug] performing regular tasks
2018-08-02 07:26:50.537 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:50.537 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:26:53.082 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:53.620 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:53.876 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:54.030 [update info] received MS cmd: 0306b511020900 / 0700800000ff1020
2018-08-02 07:26:54.031 [update notice] received unknown MS cmd: 0306b511020900 / 0700800000ff1020
2018-08-02 07:26:54.376 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:26:54.381 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:26:54.420 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:54.682 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:55.144 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:55.377 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:55.618 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:55.855 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:56.326 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:26:56.742 [main debug] performing regular tasks
2018-08-02 07:27:00.746 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:00.746 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:03.155 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:03.825 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:03.903 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:27:03.907 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:27:03.968 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:27:06.743 [main debug] performing regular tasks
2018-08-02 07:27:10.964 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:10.964 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:13.203 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:13.657 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:13.736 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:27:13.740 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:27:13.800 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:27:16.743 [main debug] performing regular tasks
2018-08-02 07:27:18.361 [network info] [00001] client connection opened 127.0.0.1
2018-08-02 07:27:18.361 [main debug] >>> i
2018-08-02 07:27:18.361 [network debug] [00001] wait for result
2018-08-02 07:27:18.367 [main debug] <<< version: ebusd 3.2.v3.2
signal: acquired
symbol rate: 23
max symbol rate: 96
min arbitration micros: ...
2018-08-02 07:27:18.374 [network info] [00001] connection closed
2018-08-02 07:27:19.362 [network debug] dead connection removed - 0
2018-08-02 07:27:21.192 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:21.193 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:23.263 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:23.367 [main debug] performing regular tasks
2018-08-02 07:27:23.784 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:27:23.788 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:27:23.828 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:24.087 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:26.870 [network info] [00002] client connection opened 127.0.0.1
2018-08-02 07:27:26.870 [main debug] >>> scan
2018-08-02 07:27:26.871 [network debug] [00002] wait for result
2018-08-02 07:27:26.872 [bus info] scan 06 cmd: 3106070400
2018-08-02 07:27:26.872 [main debug] <<< done
2018-08-02 07:27:26.872 [network info] [00002] connection closed
2018-08-02 07:27:26.887 [bus debug] arbitration delay 1199 micros
2018-08-02 07:27:26.887 [bus debug] switching from ready to send command
2018-08-02 07:27:26.894 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:26.901 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:26.908 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:26.915 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:26.915 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:26.922 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:26.922 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:26.926 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:26.976 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:26.982 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:26.989 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:26.989 [update info] sent MS cmd: 3106070400 / 0ab5564d53303101160303
2018-08-02 07:27:26.989 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-02 07:27:26.990 [update notice] store 06 ident: done
2018-08-02 07:27:26.990 [update notice] sent scan-read scan.06 QQ=31: Vaillant;VMS01;0116;0303
2018-08-02 07:27:26.990 [bus debug] notify request: done
2018-08-02 07:27:26.990 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-02 07:27:26.990 [bus info] scan 06 cmd: 3106b5090124
2018-08-02 07:27:26.990 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:26.998 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.048 [bus debug] arbitration delay 1211 micros
2018-08-02 07:27:27.048 [bus debug] switching from ready to send command
2018-08-02 07:27:27.055 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.062 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.069 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.076 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.083 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.083 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:27.090 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.090 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:27.094 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:27.164 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:27.168 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:27.175 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.175 [update info] sent MS cmd: 3106b5090124 / 09ffffffffffffffffff
2018-08-02 07:27:27.176 [update notice] sent unknown MS cmd: 3106b5090124 / 09ffffffffffffffffff
2018-08-02 07:27:27.176 [bus debug] notify request: done
2018-08-02 07:27:27.176 [bus info] scan 06 cmd: 3106b5090125
2018-08-02 07:27:27.176 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:27.184 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.234 [bus debug] arbitration delay 1207 micros
2018-08-02 07:27:27.234 [bus debug] switching from ready to send command
2018-08-02 07:27:27.241 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.248 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.255 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.262 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.270 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.270 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:27.277 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.277 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:27.281 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:27.350 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:27.354 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:27.361 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.361 [update info] sent MS cmd: 3106b5090125 / 09ffffffffffffffffff
2018-08-02 07:27:27.363 [update notice] sent scan-read scan.06 id QQ=31:
2018-08-02 07:27:27.363 [bus debug] notify request: done
2018-08-02 07:27:27.363 [bus info] scan 06 cmd: 3106b5090126
2018-08-02 07:27:27.363 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:27.371 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.422 [bus debug] arbitration delay 1212 micros
2018-08-02 07:27:27.422 [bus debug] switching from ready to send command
2018-08-02 07:27:27.429 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.436 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.443 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.450 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.457 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.457 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:27.464 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.464 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:27.468 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:27.538 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:27.543 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:27.550 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.550 [update info] sent MS cmd: 3106b5090126 / 09ffffffffffffffffff
2018-08-02 07:27:27.552 [update notice] sent scan-read scan.06 id QQ=31:
2018-08-02 07:27:27.552 [bus debug] notify request: done
2018-08-02 07:27:27.552 [bus info] scan 06 cmd: 3106b5090127
2018-08-02 07:27:27.552 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:27.558 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.654 [bus debug] arbitration delay 1088 micros
2018-08-02 07:27:27.654 [bus debug] switching from ready to send command
2018-08-02 07:27:27.661 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.668 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.676 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.683 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.690 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.690 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:27.697 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.697 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:27.701 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:27.771 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:27.775 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:27.782 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:27.782 [update info] sent MS cmd: 3106b5090127 / 09ffffffffffffffffff
2018-08-02 07:27:27.784 [update notice] sent scan-read scan.06 id QQ=31: ??;??;??; ??? ??? ??? ?; ??? ?; ??? ??? ;??
2018-08-02 07:27:27.784 [bus debug] notify request: done
2018-08-02 07:27:27.784 [bus notice] scan 06: ;??;??;??; ??? ??? ??? ?; ??? ?; ??? ??? ;??
2018-08-02 07:27:27.784 [bus info] scan 08 cmd: 3108070400
2018-08-02 07:27:27.784 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:27.791 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.841 [bus debug] arbitration delay 1214 micros
2018-08-02 07:27:27.841 [bus debug] switching from ready to send command
2018-08-02 07:27:27.848 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.855 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.862 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.869 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.869 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:27.871 [network debug] dead connection removed - 0
2018-08-02 07:27:27.876 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.876 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:27.882 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:27.934 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:27.938 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:27.945 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:27.946 [update info] sent MS cmd: 3108070400 / 0ab5424149303002029602
2018-08-02 07:27:27.946 [bus notice] scan 08: ;Vaillant;BAI00;0202;9602
2018-08-02 07:27:27.946 [update notice] store 08 ident: done
2018-08-02 07:27:27.946 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0202;9602
2018-08-02 07:27:27.946 [bus debug] notify request: done
2018-08-02 07:27:27.946 [bus notice] scan 08: ;Vaillant;BAI00;0202;9602
2018-08-02 07:27:27.946 [bus info] scan 08 cmd: 3108b5090124
2018-08-02 07:27:27.946 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:27.953 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.004 [bus debug] arbitration delay 1199 micros
2018-08-02 07:27:28.004 [bus debug] switching from ready to send command
2018-08-02 07:27:28.004 [bus notice] max. symbols per second: 111
2018-08-02 07:27:28.011 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.018 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.025 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.032 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.039 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.039 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:28.046 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.046 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:28.052 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:28.097 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:28.102 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:28.109 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.109 [update info] sent MS cmd: 3108b5090124 / 09003231313732353030
2018-08-02 07:27:28.110 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:27:28.110 [bus debug] notify request: done
2018-08-02 07:27:28.110 [bus info] scan 08 cmd: 3108b5090125
2018-08-02 07:27:28.110 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:28.117 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.167 [bus debug] arbitration delay 1195 micros
2018-08-02 07:27:28.167 [bus debug] switching from ready to send command
2018-08-02 07:27:28.174 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.182 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.189 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.196 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.203 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.203 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:28.210 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.210 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:28.215 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:28.262 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:28.267 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:28.274 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:28.274 [update info] sent MS cmd: 3108b5090125 / 09313030313536303933
2018-08-02 07:27:28.275 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:27:28.275 [bus debug] notify request: done
2018-08-02 07:27:28.275 [bus info] scan 08 cmd: 3108b5090126
2018-08-02 07:27:28.275 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:28.282 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:28.333 [bus debug] arbitration delay 1193 micros
2018-08-02 07:27:28.334 [bus debug] switching from ready to send command
2018-08-02 07:27:28.340 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.347 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.354 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.361 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.368 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.368 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:28.375 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.375 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:28.381 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:28.427 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:28.431 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:28.438 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.439 [update info] sent MS cmd: 3108b5090126 / 09313030303035363739
2018-08-02 07:27:28.440 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:27:28.440 [bus debug] notify request: done
2018-08-02 07:27:28.440 [bus info] scan 08 cmd: 3108b5090127
2018-08-02 07:27:28.440 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:28.447 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.498 [bus debug] arbitration delay 1205 micros
2018-08-02 07:27:28.498 [bus debug] switching from ready to send command
2018-08-02 07:27:28.505 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.512 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.519 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.527 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:27:28.534 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.534 [bus debug] switching from send command to send command CRC
2018-08-02 07:27:28.541 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.541 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:27:28.547 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:27:28.595 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:27:28.599 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:27:28.606 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:28.607 [update info] sent MS cmd: 3108b5090127 / 094e343c3c3c3c3c3c3c
2018-08-02 07:27:28.608 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:27:28.608 [bus debug] notify request: done
2018-08-02 07:27:28.608 [bus notice] scan 08: ;21;17;25;0010015609;3100;005679;N4
2018-08-02 07:27:28.609 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:27:28.615 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:27:31.408 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:31.408 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:31.872 [main debug] performing regular tasks
2018-08-02 07:27:32.019 [network info] [00003] client connection opened 127.0.0.1
2018-08-02 07:27:32.019 [main debug] >>> i
2018-08-02 07:27:32.020 [main debug] <<< version: ebusd 3.2.v3.2
signal: acquired
symbol rate: 37
max symbol rate: 111
min arbitration micros ...
2018-08-02 07:27:32.020 [network debug] [00003] wait for result
2018-08-02 07:27:32.021 [network info] [00003] connection closed
2018-08-02 07:27:33.020 [network debug] dead connection removed - 0
2018-08-02 07:27:33.345 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:33.456 [update info] received MS cmd: 0306b511020900 / 0700800000ff1020
2018-08-02 07:27:33.456 [update notice] received unknown MS cmd: 0306b511020900 / 0700800000ff1020
2018-08-02 07:27:33.875 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:27:33.879 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:27:33.920 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:27:37.020 [main debug] performing regular tasks
2018-08-02 07:27:39.602 [main notice] SIGTERM received
2018-08-02 07:27:41.628 [update info] received MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:41.628 [update notice] received unknown MS cmd: 0306b511040ad60300 / 0100
2018-08-02 07:27:42.158 [main notice] ebusd stopped
[/spoiler]
Und hier noch mit [07:44:38] openhabian@openHABianPi:~$ sudo ebusd --loglevel=debug --scanconfig
[spoiler]
2018-08-02 07:45:57.201 [main notice] ebusd 3.2.v3.2 started with auto scan
2018-08-02 07:45:57.202 [main info] loading configuration files from http://ebusd.eu/config/
2018-08-02 07:45:57.373 [main info] reading templates /
2018-08-02 07:45:57.458 [main info] read templates in /
2018-08-02 07:45:57.458 [main info] reading file memory.csv
2018-08-02 07:45:57.542 [main info] successfully read file memory.csv
2018-08-02 07:45:57.542 [main info] reading file broadcast.csv
2018-08-02 07:45:57.627 [main info] successfully read file broadcast.csv
2018-08-02 07:45:57.627 [main info] read config files
2018-08-02 07:45:57.629 [bus notice] bus started with own address 31/36
2018-08-02 07:45:57.630 [main info] registering data handlers
2018-08-02 07:45:57.630 [main info] registered data handlers
2018-08-02 07:45:57.656 [bus debug] ERR: SYN received during no signal, switching to ready
2018-08-02 07:45:57.656 [bus notice] signal acquired
2018-08-02 07:45:59.497 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:00.039 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:00.294 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:00.599 [network info] [00001] client connection opened 127.0.0.1
2018-08-02 07:46:00.599 [network debug] [00001] wait for result
2018-08-02 07:46:00.599 [main debug] >>> i
2018-08-02 07:46:00.599 [main debug] <<< version: ebusd 3.2.v3.2
signal: acquired
symbol rate: 43
max symbol rate: 43
reconnects: 0
masters: ...
2018-08-02 07:46:00.600 [network info] [00001] connection closed
2018-08-02 07:46:00.794 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:01.600 [network debug] dead connection removed - 0
2018-08-02 07:46:05.599 [main debug] performing regular tasks
2018-08-02 07:46:05.667 [bus notice] new master 03, master count 2
2018-08-02 07:46:05.692 [bus notice] new master 01, master count 3
2018-08-02 07:46:05.692 [update info] received MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:05.692 [update notice] received unknown MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:07.026 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:07.104 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:46:07.110 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:46:07.170 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:46:09.542 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:15.599 [main debug] performing regular tasks
2018-08-02 07:46:15.600 [bus info] scan 06 cmd: 3106070400
2018-08-02 07:46:15.642 [bus debug] arbitration delay 1241 micros
2018-08-02 07:46:15.643 [bus info] arbitration delay 1241 - 1241 micros
2018-08-02 07:46:15.643 [bus debug] switching from ready to send command
2018-08-02 07:46:15.650 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:15.650 [bus info] send/receive symbol latency 6 - 6 ms
2018-08-02 07:46:15.657 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:15.657 [bus info] send/receive symbol latency 5 - 6 ms
2018-08-02 07:46:15.664 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:15.671 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:15.671 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:15.678 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:15.678 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:15.682 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:15.732 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:15.738 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:15.745 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:15.745 [update info] sent MS cmd: 3106070400 / 0ab5564d53303101160303
2018-08-02 07:46:15.745 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-02 07:46:15.745 [update notice] store 06 ident: done
2018-08-02 07:46:15.746 [update notice] sent scan-read scan.06 QQ=31: Vaillant;VMS01;0116;0303
2018-08-02 07:46:15.746 [bus debug] notify request: done
2018-08-02 07:46:15.746 [bus notice] scan 06: ;Vaillant;VMS01;0116;0303
2018-08-02 07:46:15.746 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:15.754 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:15.834 [main debug] found 1 matching scan config files from vaillant with prefix 06: done
2018-08-02 07:46:15.834 [main error] unable to load scan config 06: no file from vaillant with prefix 06 matches ID "vms01", SW0116, HW0303
2018-08-02 07:46:15.834 [main error] scan config 06: ERR: element not found
2018-08-02 07:46:15.905 [update info] received MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:15.905 [update notice] received unknown MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:16.894 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:16.972 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:46:16.976 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:46:17.037 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:46:17.834 [main debug] performing regular tasks
2018-08-02 07:46:17.835 [bus info] scan 08 cmd: 3108070400
2018-08-02 07:46:17.875 [bus debug] arbitration delay 1209 micros
2018-08-02 07:46:17.875 [bus info] arbitration delay 1209 - 1241 micros
2018-08-02 07:46:17.875 [bus debug] switching from ready to send command
2018-08-02 07:46:17.882 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.889 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.896 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.903 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.903 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:17.910 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.910 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:17.915 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:17.968 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:17.972 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:17.980 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:17.980 [update info] sent MS cmd: 3108070400 / 0ab5424149303002029602
2018-08-02 07:46:17.980 [bus notice] scan 08: ;Vaillant;BAI00;0202;9602
2018-08-02 07:46:17.980 [update notice] store 08 ident: done
2018-08-02 07:46:17.980 [update notice] sent scan-read scan.08 QQ=31: Vaillant;BAI00;0202;9602
2018-08-02 07:46:17.980 [bus debug] notify request: done
2018-08-02 07:46:17.980 [bus notice] scan 08: ;Vaillant;BAI00;0202;9602
2018-08-02 07:46:17.980 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:17.988 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.073 [main debug] found 3 matching scan config files from vaillant with prefix 08: done
2018-08-02 07:46:18.073 [main info] reading templates vaillant
2018-08-02 07:46:18.167 [main info] read templates in vaillant
2018-08-02 07:46:18.341 [main notice] read common config file vaillant/scan.csv
2018-08-02 07:46:18.422 [main notice] read common config file vaillant/general.csv
2018-08-02 07:46:18.504 [main notice] read common config file vaillant/broadcast.csv
2018-08-02 07:46:18.590 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0202, HW9602
2018-08-02 07:46:18.591 [bus info] send message: 3108b5090124
2018-08-02 07:46:18.602 [bus debug] arbitration delay 833 micros
2018-08-02 07:46:18.602 [bus info] arbitration delay 833 - 1241 micros
2018-08-02 07:46:18.602 [bus debug] switching from ready to send command
2018-08-02 07:46:18.609 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.616 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.623 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.630 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.637 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.637 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:18.644 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.644 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:18.649 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:18.699 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:18.702 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:18.709 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.709 [update info] sent MS cmd: 3108b5090124 / 09003231313732353030
2018-08-02 07:46:18.709 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:46:18.710 [bus debug] notify request: done
2018-08-02 07:46:18.710 [bus debug] read res: 09003231313732353030
2018-08-02 07:46:18.710 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:18.710 [bus info] send message: 3108b5090125
2018-08-02 07:46:18.716 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.767 [bus debug] arbitration delay 1195 micros
2018-08-02 07:46:18.768 [bus debug] switching from ready to send command
2018-08-02 07:46:18.775 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:18.782 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.789 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.796 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.803 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:18.803 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:18.816 [bus debug] notify request: ERR: wrong symbol received
2018-08-02 07:46:18.816 [bus debug] ERR: wrong symbol received during send command CRC, switching to skip
2018-08-02 07:46:18.816 [bus error] send to 08: ERR: wrong symbol received, retry
2018-08-02 07:46:19.379 [bus debug] arbitration delay 1205 micros
2018-08-02 07:46:19.379 [bus debug] switching from ready to send command
2018-08-02 07:46:19.386 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.394 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:19.401 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.408 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.415 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.415 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:19.422 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.422 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:19.427 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:19.472 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:19.476 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:19.483 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.483 [update info] sent MS cmd: 3108b5090125 / 09313030313536303933
2018-08-02 07:46:19.483 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:46:19.483 [bus debug] notify request: done
2018-08-02 07:46:19.483 [bus debug] read res: 09313030313536303933
2018-08-02 07:46:19.483 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:19.483 [bus info] send message: 3108b5090126
2018-08-02 07:46:19.490 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.635 [bus debug] arbitration delay 1228 micros
2018-08-02 07:46:19.636 [bus debug] switching from ready to send command
2018-08-02 07:46:19.642 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.649 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.656 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.663 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.670 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.671 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:19.677 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.678 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:19.683 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:19.729 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:19.733 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:19.740 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.741 [update info] sent MS cmd: 3108b5090126 / 09313030303035363739
2018-08-02 07:46:19.741 [update notice] sent scan-read scan.08 id QQ=31:
2018-08-02 07:46:19.741 [bus debug] notify request: done
2018-08-02 07:46:19.741 [bus debug] read res: 09313030303035363739
2018-08-02 07:46:19.741 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:19.741 [bus info] send message: 3108b5090127
2018-08-02 07:46:19.747 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.799 [bus debug] arbitration delay 1218 micros
2018-08-02 07:46:19.799 [bus debug] switching from ready to send command
2018-08-02 07:46:19.806 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:19.813 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.820 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.827 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.834 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.834 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:19.841 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.842 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:19.847 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:19.894 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:19.897 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:19.904 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:19.904 [update info] sent MS cmd: 3108b5090127 / 094e343c3c3c3c3c3c3c
2018-08-02 07:46:19.905 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:19.905 [bus debug] notify request: done
2018-08-02 07:46:19.905 [bus debug] read res: 094e343c3c3c3c3c3c3c
2018-08-02 07:46:19.905 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:19.911 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.243 [main notice] found messages: 197 (2 conditional on 24 conditions, 0 poll, 9 update)
2018-08-02 07:46:20.244 [bus info] scan 08 cmd: 3108b5090124
2018-08-02 07:46:20.271 [bus debug] arbitration delay 1100 micros
2018-08-02 07:46:20.271 [bus debug] switching from ready to send command
2018-08-02 07:46:20.278 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.285 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.292 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.299 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.306 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.306 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:20.313 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.313 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:20.319 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:20.367 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:20.372 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:20.379 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.379 [update info] sent MS cmd: 3108b5090124 / 09003231313732353030
2018-08-02 07:46:20.379 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:20.380 [bus debug] notify request: done
2018-08-02 07:46:20.380 [bus info] scan 08 cmd: 3108b5090125
2018-08-02 07:46:20.380 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:20.386 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.437 [bus debug] arbitration delay 1109 micros
2018-08-02 07:46:20.437 [bus debug] switching from ready to send command
2018-08-02 07:46:20.444 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.452 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.459 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.466 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.473 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.473 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:20.480 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.480 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:20.486 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:20.533 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:20.537 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:20.544 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.544 [update info] sent MS cmd: 3108b5090125 / 09313030313536303933
2018-08-02 07:46:20.545 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:20.545 [bus debug] notify request: done
2018-08-02 07:46:20.545 [bus info] scan 08 cmd: 3108b5090126
2018-08-02 07:46:20.545 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:20.551 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.601 [bus debug] arbitration delay 1135 micros
2018-08-02 07:46:20.601 [bus debug] switching from ready to send command
2018-08-02 07:46:20.609 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.616 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.623 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.630 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.637 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.637 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:20.644 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.644 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:20.649 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:20.697 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:20.701 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:20.708 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:20.708 [update info] sent MS cmd: 3108b5090126 / 09313030303035363739
2018-08-02 07:46:20.709 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:20.709 [bus debug] notify request: done
2018-08-02 07:46:20.709 [bus info] scan 08 cmd: 3108b5090127
2018-08-02 07:46:20.709 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:20.715 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.766 [bus debug] arbitration delay 1103 micros
2018-08-02 07:46:20.766 [bus debug] switching from ready to send command
2018-08-02 07:46:20.773 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.780 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.787 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.794 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.801 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.801 [bus debug] switching from send command to send command CRC
2018-08-02 07:46:20.808 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.808 [bus debug] switching from send command CRC to receive command ACK
2018-08-02 07:46:20.814 [bus debug] switching from receive command ACK to receive response
2018-08-02 07:46:20.862 [bus debug] switching from receive response to receive response CRC
2018-08-02 07:46:20.866 [bus debug] switching from receive response CRC to send response ACK
2018-08-02 07:46:20.873 [bus debug] send/receive symbol latency 5 ms
2018-08-02 07:46:20.873 [update info] sent MS cmd: 3108b5090127 / 094e343c3c3c3c3c3c3c
2018-08-02 07:46:20.874 [update notice] sent scan-read scan.08 id QQ=31: 21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:20.875 [bus debug] notify request: done
2018-08-02 07:46:20.875 [bus notice] scan 08: ;21;17;25;0010015609;3100;005679;N4
2018-08-02 07:46:20.875 [bus debug] switching from send response ACK to send SYN
2018-08-02 07:46:20.875 [main info] scan config 08 message received
2018-08-02 07:46:20.882 [bus debug] send/receive symbol latency 6 ms
2018-08-02 07:46:21.502 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-08-02 07:46:22.875 [main debug] performing regular tasks
2018-08-02 07:46:26.159 [update info] received MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:26.159 [update notice] received unknown MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:26.758 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:26.836 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:46:26.840 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:46:26.901 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:46:27.230 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-08-02 07:46:29.636 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:30.158 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:32.665 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-08-02 07:46:32.876 [main debug] performing regular tasks
2018-08-02 07:46:36.367 [update info] received MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:36.367 [update notice] received unknown MS cmd: 0306b511040ad30300 / 0100
2018-08-02 07:46:36.501 [network info] [00002] client connection opened 127.0.0.1
2018-08-02 07:46:36.502 [main debug] >>> i
2018-08-02 07:46:36.502 [main debug] <<< version: ebusd 3.2.v3.2
signal: acquired
symbol rate: 24
max symbol rate: 96
min arbitration micros: ...
2018-08-02 07:46:36.502 [network debug] [00002] wait for result
2018-08-02 07:46:36.503 [network info] [00002] connection closed
2018-08-02 07:46:36.617 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:36.695 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:46:36.699 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:46:36.760 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:46:37.503 [network debug] dead connection removed - 0
2018-08-02 07:46:38.041 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2018-08-02 07:46:39.714 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:41.502 [main debug] performing regular tasks
2018-08-02 07:46:43.984 [main notice] SIGTERM received
2018-08-02 07:46:46.444 [bus debug] ERR: read timeout during receive command, switching to skip
2018-08-02 07:46:46.522 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2018-08-02 07:46:46.527 [bus debug] ERR: NAK received during receive command ACK, switching to receive command
2018-08-02 07:46:46.587 [bus debug] ERR: CRC error during receive command CRC, switching to skip
2018-08-02 07:46:46.609 [main notice] ebusd stopped
[/spoiler]
Zitat von: fhem@pi am 02 August 2018, 19:34:35
Keiner mehr hier unterwegs ? :-[
Doch
Aber das gehoert hier nicht hin! Mach einen neuen thread auf in Anfaengerfragen, und Dir wird geholfen. Zudem sind alle im Hitzephlegma, da kann es etwas dauern!
Und ein list sagt mehr als tausend Codeschnipsel!
Gruss Christoph
Zitat von: Matze_Bln am 01 August 2018, 20:25:29
--- edit ---
Moin
Kannst Du das bitte in Codetags setzen! Das ist der " # " ueber den Smilies!
Das geht auch nachtraeglich!
Danke und Gruss
Christoph
Zitat von: TiPpFeHlEr am 29 Juli 2018, 17:57:24
aber wieso geht
08.reco.csv nicht??
wieso sollte das denn gehen? der Automatismus streicht nur abschließende Ziffern nacheinander, bis ein Treffer gefunden wurde. "v" ist keine Ziffer ;)
Zitat von: Matze_Bln am 01 August 2018, 20:25:29
Ich habe noch ein wenig probiert. Wie vermutet, läd die csv vom Server. Damit ist klar, dass er dann natürlich keine csv für das VMS01 findet.
richtig. Wenn Du mit eigens erstellten/erweiterten Files arbeiten willst, musst Du mit einer aktuellen ebusd Version zwingend auch die "--configpath=... (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options)" Option verwenden.
Zitat von: Matze_Bln am 01 August 2018, 20:25:29
Solange ich mit scanconfig arbeite, verhält sich ebusd so.
Das sind nun wieder zwei paar Stiefel. scanconfig sollte man eigentlich immer einsetzen, wenn es irgendwie geht, denn andernfalls musst Du das Verzeichnis komplett ausdünnen und auf ganz genau die CSVs reduzieren, die Du auch wirklich brauchst. Nur mit scanconfig kann ebusd das alleine.
Probleme nach umstieg von wheezy auf jessie.
hi folks,
habe mein system auf jessie umgestellt und gleichmal die neueste ebusd version installiert.
leider weiss ich nicht wie ich ebusd service richtig starten kann, ich verwende 2 ebusadapter.
mit dem alten start script (/etc/init.d/ebusd) konnte mann 2 $EBUSD_OPTS angeben.
das jetzige startscript in (/etc/systemd/system/ebusd.service) kann nur 1 ExecStart= /usr/bin/ebusd $EBUSD_OPTS
meine /etc/default/ebusd enthält aber 2 definitionen für 2 Adapter / ports
EBUSD_OPTS1="--lograwdata=bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig=08 -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Is$
EBUSD_OPTS2="--lograwdata=bytes --latency=100000 --receivetimeout=100000 -a ff --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_$
wie kann ich mit systemd beide ports starten??
MfG Maik
Zitat von: TiPpFeHlEr am 05 August 2018, 15:25:01
Probleme nach umstieg von wheezy auf jessie.
eins vorweg: mit systemd ist alles anders!
Zitat von: TiPpFeHlEr am 05 August 2018, 15:25:01
mit dem alten start script (/etc/init.d/ebusd) konnte mann 2 $EBUSD_OPTS angeben.
das geht im Prinzip mit systemd auch, aber man braucht dafür jeweils ein eigenes systemd Startscript pro Instanz. Also wenn Du 2 ebusd Instanzen haben willst, musst Du das /usr/lib/systemd/system/ebusd.service File kopieren und entsprechend editieren, siehe auch den Kommentar-Block ab Zeile 18 hier:
https://github.com/john30/ebusd/blob/master/contrib/debian/default/ebusd#L18
Zitat von: john30 am 05 August 2018, 17:13:01
eins vorweg: mit systemd ist alles anders!
::) ich habs mir gedacht
ich werds mal probieren.
MfG Maik
@john
also, im Prinzip geht es aber ......
1. ein Fehler trotz Funktion -> Problem oder ignorieren?
Job for ebusd_2.service failed because of unavailable resources or another system error.
See "systemctl status ebusd_2.service" and "journalctl -xe" for details.
pi@FHEM_RPI:~ $ systemctl start ebusd_2.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Starten von »ebusd_2.service« notwendig.
Multiple identities can be used for authentication:
1. ,,, (pi)
2. root
Choose identity to authenticate as (1-2): 1
Password:
==== AUTHENTICATION COMPLETE ===
Job for ebusd_2.service failed because of unavailable resources or another system error.
See "systemctl status ebusd_2.service" and "journalctl -xe" for details.
pi@FHEM_RPI:~ $ systemctl status ebusd_2.service
● ebusd_2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd_2.service; disabled; vendor preset: enabled)
Active: active (running) since Sun 2018-08-05 17:30:49 CEST; 14s ago
Process: 1637 ExecStart=/usr/bin/ebusd $EBUSD_OPTS2 (code=exited, status=0/SUCCESS)
Main PID: 1638 (ebusd)
CGroup: /system.slice/ebusd_2.service
└─1638 /usr/bin/ebusd --lograwdata=bytes --latency=100000 --receivetimeout=100000 -a ff --enablehex --scanconfig -d /dev/serial/by-id/usb-E-Se
Aug 05 17:30:49 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:30:49 FHEM_RPI systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
beide ports gehen (kein Signal weil ohne Adapter (Testsystem)
pi@FHEM_RPI:~ $ ebusctl -p 8889 info
version: ebusd 3.2.v3.2-5-g671c8d2
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
pi@FHEM_RPI:~ $ ebusctl -p 8888 info
version: ebusd 3.2.v3.2-5-g671c8d2
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 04: slave #25, ebusd
address ff: master #25, ebusd
2. Autostart geht nicht, beim boot vom PI wird der service nicht gestartet, er muss von Hand gestartet werden, inkl. einer neuen Rechteabfrage die ich noch nicht kenne.
pi@FHEM_RPI:~ $ systemctl start ebusd.service
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Legitimierung ist zum Starten von »ebusd.service« notwendig.
Multiple identities can be used for authentication:
1. ,,, (pi)
2. root
Choose identity to authenticate as (1-2): 1
Password:
==== AUTHENTICATION COMPLETE ===
MfG Maik
folgende Fehler beim Autostart
pi@FHEM_RPI:~ $ systemctl status ebusd.service
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-08-05 17:52:59 CEST; 3min 2s ago
Process: 476 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=22)
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Start request repeated too quickly.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
pi@FHEM_RPI:~ $ systemctl status ebusd_2.service
● ebusd_2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd_2.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sun 2018-08-05 17:52:59 CEST; 3min 30s ago
Process: 477 ExecStart=/usr/bin/ebusd $EBUSD_OPTS2 (code=exited, status=22)
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Start request repeated too quickly.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
pi@FHEM_RPI:~ $ journalctl | grep ebusd
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI ebusd[418]: 2018-08-05 17:52:58.414 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI ebusd[414]: 2018-08-05 17:52:58.414 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:58 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI ebusd[451]: 2018-08-05 17:52:58.709 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI ebusd[453]: 2018-08-05 17:52:58.730 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:58 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI ebusd[461]: 2018-08-05 17:52:58.855 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:58 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:58 FHEM_RPI ebusd[464]: 2018-08-05 17:52:58.899 [main error] invalid configPath URL
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:58 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:58 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:58 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:58 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:59 FHEM_RPI ebusd[470]: 2018-08-05 17:52:59.005 [main error] invalid configPath URL
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:59 FHEM_RPI ebusd[472]: 2018-08-05 17:52:59.052 [main error] invalid configPath URL
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:52:59 FHEM_RPI ebusd[476]: 2018-08-05 17:52:59.211 [main error] invalid configPath URL
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI ebusd[477]: 2018-08-05 17:52:59.222 [main error] invalid configPath URL
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Control process exited, code=exited status=22
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Service hold-off time over, scheduling restart.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Start request repeated too quickly.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd_2.service: Failed with result 'exit-code'.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Start request repeated too quickly.
Aug 05 17:52:59 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:52:59 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'exit-code'.
Danach von Hand gestartet
Aug 05 17:58:21 FHEM_RPI polkitd(authority=local)[690]: Operator of unix-process:1160:31563 successfully authenticated as unix-user:pi to gain ONE-SHOT authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.23 [systemctl start ebusd_2.service] (owned by unix-user:pi)
Aug 05 17:58:21 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:58:21 FHEM_RPI systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:58:31 FHEM_RPI polkitd(authority=local)[690]: Operator of unix-process:1188:32781 successfully authenticated as unix-user:pi to gain ONE-SHOT authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.26 [systemctl start ebusd.service] (owned by unix-user:pi)
Aug 05 17:58:31 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:58:31 FHEM_RPI systemd[1]: ebusd.service: Failed to read PID from file /var/run/ebusd.pid: Invalid argument
Aug 05 17:58:31 FHEM_RPI systemd[1]: ebusd.service: Daemon never wrote its PID file. Failing.
Aug 05 17:58:31 FHEM_RPI systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:58:31 FHEM_RPI systemd[1]: ebusd.service: Unit entered failed state.
Aug 05 17:58:31 FHEM_RPI systemd[1]: ebusd.service: Failed with result 'resources'.
Aug 05 17:58:31 FHEM_RPI systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Aug 05 17:58:31 FHEM_RPI systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
Aug 05 17:58:31 FHEM_RPI systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Aug 05 17:58:31 FHEM_RPI systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
MfG Maik
hmmm, ich muss bei mir EBUSD immer als Sudo starten, sonst will das nicht, du hast ihn als PI starten wollen, evtl. liegt da das Problem ?
Zitat von: john30 am 05 August 2018, 13:42:44
richtig. Wenn Du mit eigens erstellten/erweiterten Files arbeiten willst, musst Du mit einer aktuellen ebusd Version zwingend auch die "--configpath=... (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options)" Option verwenden.
Das sind nun wieder zwei paar Stiefel. scanconfig sollte man eigentlich immer einsetzen, wenn es irgendwie geht, denn andernfalls musst Du das Verzeichnis komplett ausdünnen und auf ganz genau die CSVs reduzieren, die Du auch wirklich brauchst. Nur mit scanconfig kann ebusd das alleine.
Irgendwas hatte ich falsch gemacht, da ich scanconfig und configpath bei meinen Versuchen nie gemeinsam starten konnte, nun geht es aber und die csv wird erkannt.
Zitat von: john30 am 05 August 2018, 13:42:44
Wenn Du mit eigens erstellten/erweiterten Files arbeiten willst, musst Du mit einer aktuellen ebusd Version zwingend auch die "--configpath=... (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options)" Option verwenden.
Hab das erst jetzt nochmal richtig gelesen... darf ich nachfragen, warum das so ist (und wo das dokumentiert ist)?
Oder meinte das nur, wenn man statt der vorgefertigten CSVs lieber eigene erstellt oder eine erweiterte Kopie irgendwo ablegt,
kann man in neueren Versionen mit "--configpath" arbeiten, statt die Originale zu ändern?
Zitat von: Sven77 am 07 August 2018, 12:57:39
Hab das erst jetzt nochmal richtig gelesen... darf ich nachfragen, warum das so ist (und wo das dokumentiert ist)?
Oder meinte das nur, wenn man statt der vorgefertigten CSVs lieber eigene erstellt oder eine erweiterte Kopie irgendwo ablegt, kann man in neueren Versionen mit "--configpath" arbeiten, statt die Originale zu ändern?
dokumentiert hier: https://github.com/john30/ebusd/blob/master/ChangeLog.md
dient der Vereinfachung für das Gros der Benutzer, die nicht an den CSVs rumschrauben wollen.
Zitat von: cs-online am 07 August 2018, 08:44:28
hmmm, ich muss bei mir EBUSD immer als Sudo starten, sonst will das nicht, du hast ihn als PI starten wollen, evtl. liegt da das Problem ?
OK?
ich dachte es wird als root gestartet, wie kann ich den Autostart als root volziehen??
Ich hatte einfach alles so wie im ebusd/wiki beschrieben gemacht.
ZitatStart ebusd automatically
To start ebusd automatically on startup on debian based system use this command to create the file ebusd.service:
sudo nano -w /etc/systemd/system/ebusd.service
Copy the following content inside the file:
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
[Install]
WantedBy=multi-user.target
vorher kann das jessie system nicht ein gesetzt werden. :(
MfG Maik
workaround für mein Problem
der ebusd.service konnte nicht starten und wollte erneut starten. Dies ging nicht weil der ebusd kein reload unterstützt?
systemctl show -p CanReload ebusd
CanReload=no
habe also folgendes zur ebusd.service hinzugefügt
StartLimitBurst=0
nun startet der ebusd beim boot automatisch
pi@FHEM_RPI:~ $ systemctl status ebusd
● ebusd.service - ebusd_1
Loaded: loaded (/etc/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2018-08-11 15:59:23 CEST; 47s ago
Process: 780 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
Main PID: 784 (ebusd)
CGroup: /system.slice/ebusd.service
└─784 /usr/bin/ebusd --lograwdata=bytes --latency=100000 --receivetimeout=100000 --enablehex --scanconfig=08 -d /dev/serial/by-id/usb-E-Servic
Aug 11 15:59:23 FHEM_RPI systemd[1]: Stopped ebusd_1.
Aug 11 15:59:23 FHEM_RPI systemd[1]: Starting ebusd_1...
Aug 11 15:59:23 FHEM_RPI systemd[1]: Started ebusd_1.
Die Frage ist immernoch was ihn beim ersten mal daran hindert richtig mit Status 0 zu starten!?
was braucht ebusd.service noch ausser network.target?
Sollte er auf noch einen service warten??
MfG Maik
update
so, neues sytem ist online (es ist nicht jessie sondern stretch ::))
nun lädt er allerdings wieder die csv nicht
2018-08-12 17:43:26.848 [main notice] ebusd 3.2.v3.2-5-g671c8d2 started with single scan
2018-08-12 17:43:28.441 [bus notice] bus started with own address 31/36
2018-08-12 17:43:28.443 [bus notice] signal acquired
2018-08-12 17:43:38.442 [main notice] starting initial scan for 08
2018-08-12 17:43:38.576 [bus notice] new master 03, master count 2
2018-08-12 17:43:38.576 [bus notice] scan 08: ;Vaillant;recoV;0217;0203
2018-08-12 17:43:38.576 [update notice] store 08 ident: done
2018-08-12 17:43:38.576 [update notice] sent scan-read scan.08 QQ=31: Vaillant;recoV;0217;0203
2018-08-12 17:43:38.577 [bus notice] scan 08: ;Vaillant;recoV;0217;0203
2018-08-12 17:43:38.653 [main error] unable to load scan config 08: no file from vaillant with prefix 08 matches ID "recov", SW0217, HW0203
2018-08-12 17:43:38.653 [main error] initial scan failed: ERR: element not found
die Datei existiert aber!
pi@OSPI:~ $ ls -l /etc/ebusd/vaillant/
insgesamt 120
-rw-r--r-- 1 pi pi 3317 Aug 5 16:08 08.bai.csv
-rw-r--r-- 1 pi pi 1958 Aug 5 16:08 08.recov.csv
-rw-r--r-- 1 pi pi 22168 Aug 5 16:08 15.470.csv
-rw-r--r-- 1 pi pi 1990 Aug 5 16:08 38.v32.csv
-rw-r--r-- 1 pi pi 17010 Aug 5 16:08 bai.308523.inc
-rw-r--r-- 1 pi pi 620 Aug 5 16:08 broadcast.csv
-rw-r--r-- 1 pi pi 245 Aug 5 16:08 currentservice.inc
-rw-r--r-- 1 pi pi 527 Aug 5 16:08 errors.inc
-rw-r--r-- 1 pi pi 738 Aug 5 16:08 hcmode.inc
-rw-r--r-- 1 pi pi 301 Aug 5 16:08 hwcmode.inc
-rw-r--r-- 1 pi pi 409 Aug 5 16:08 mcmode.inc
-rw-r--r-- 1 pi pi 316 Aug 5 16:08 quick.inc
-rw-r--r-- 1 pi pi 238 Aug 5 16:08 roomtempoffset.inc
-rw-r--r-- 1 pi pi 792 Aug 5 16:08 scan.csv
-rw-r--r-- 1 pi pi 2379 Aug 5 16:08 _templates.csv
-rw-r--r-- 1 pi pi 709 Aug 5 16:08 tempsetpoints.inc
-rw-r--r-- 1 pi pi 647 Aug 5 16:08 timercc.inc
-rw-r--r-- 1 pi pi 677 Aug 5 16:08 timercool.inc
-rw-r--r-- 1 pi pi 633 Aug 5 16:08 timerhc.inc
-rw-r--r-- 1 pi pi 647 Aug 5 16:08 timerhwc.inc
-rw-r--r-- 1 pi pi 979 Aug 5 16:08 timer.inc
wer hat jetze Recht ??
welchen Grund könnte er haben die Datei nicht zu finden??
MfG Maik
Ist das vielleicht der gleiche Fehler wie bei mir, dass configpath fehlt?
@ matze
wo finde ich dein Problem ? hier im Thread ?
welcher Post?
MfG Maik
Ja, in diesem Thread. Fehlermeldung steht z.B. in #2724 und John hat es in #2731 beantwortet.
@matze
Ahhh danke, werde es testen
Mfg Maik
hmmmm.....
hab jetze folgendes hinzugefügt
--configpath=/etc/ebusd/vaillant
dort drinn liegt die 08.recov.csv
leider gehts nicht folgendes steht jetze im log
2018-08-14 11:35:11.641 [main notice] ebusd 3.2.v3.2-5-g671c8d2 started with single scan
2018-08-14 11:35:11.645 [main error] error reading templates in /: ERR: element not found, last error: _templates.csv:36: ERR: element not found, field type TEMP in field 0
2018-08-14 11:35:11.650 [main error] error reading config files: ERR: element not found, last error: 38.v32.csv:25: ERR: element not found, field type TEMP in field 0
2018-08-14 11:35:11.654 [bus notice] bus started with own address 31/36
2018-08-14 11:35:11.689 [bus notice] signal acquired
2018-08-14 11:35:19.130 [main notice] starting initial scan for 08
2018-08-14 11:35:19.257 [bus notice] new master 03, master count 2
2018-08-14 11:35:19.257 [bus notice] scan 08: ;Vaillant;recoV;0217;0203
2018-08-14 11:35:19.257 [update notice] store 08 ident: done
2018-08-14 11:35:19.257 [update notice] sent scan-read scan.08 QQ=31: Vaillant;recoV;0217;0203
2018-08-14 11:35:19.258 [bus notice] scan 08: ;Vaillant;recoV;0217;0203
2018-08-14 11:35:19.258 [main error] unable to load scan config 08: list files in vaillant ERR: element not found
2018-08-14 11:35:19.258 [main error] initial scan failed: ERR: element not found
2018-08-14 11:37:17.730 [main notice] update check: revision v3.2-2-g1737636 available
2018-08-14 11:38:59.521 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:00.086 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:00.651 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:01.214 [bus error] send to 38: ERR: read timeout
2018-08-14 11:39:01.214 [bus error] send message part 0: ERR: read timeout
2018-08-14 11:39:01.781 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:02.345 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:02.909 [bus error] send to 38: ERR: read timeout, retry
2018-08-14 11:39:03.474 [bus error] send to 38: ERR: read timeout
2018-08-14 11:39:03.474 [bus error] send message part 0: ERR: read timeout
hab ich das mit --configpath falsch verstanden??
meine Start config sieht so aus
EBUSD_OPTS2="--configpath=/etc/ebusd/vaillant --latency=100000 --receivetimeout=100000 --enablehex --scanconfig=08 -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"
MfG Maik
Wenn ich die Doku richtig verstehe, probiere es nur mit /etc/ebusd also ohne vaillant
Deine Datei bleibt natürlich im Ordner Vaillant. Die Scanlogik geht aber ziemlich sicher vom Hauptverzeichnis aus, weshalb du den Fehler mit der template.csv jetzt noch zusätzlich hast. Den Hersteller ermittelt scanconfig alleine und ergänzt das im Pfad.
Wieso machst du eigentlich scanconfig=08? Ist das das einzige Gerät auf dem Bus? Ich würde nur --scanconfig da verwenden
@matze
Danke, das wars ;D
EBUSD_OPTS2="--configpath=/etc/ebusd --latency=100000 --receivetimeout=100000 --enablehex --scanconfig=08 -d /dev/serial/by-id/usb-E-Service_eBus_Coupler_Iso_12001_ALHTIL2-if00-port0 -p 8889 -l /var/log/ebusd2.log"
Resultat
pi@OSPI:~ $ ebusctl -p 8889 info
version: ebusd 3.2.v3.2-5-g671c8d2
update check: revision v3.2-2-g1737636 available, broadcast.csv: different version available, vaillant/broadcast.csv: different version available
signal: acquired
symbol rate: 23
max symbol rate: 121
min arbitration micros: 722
max arbitration micros: 901
min symbol latency: 5
max symbol latency: 7
reconnects: 0
masters: 2
messages: 70
conditional: 0
poll: 0
update: 11
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0217;HW=0203", loaded "vaillant/08.recov.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
warum den scan:08, weil:
1. nur ein Gerät (RecoVair) dran hängt
2. das Gerät auf den normalen scan nicht geantwortet hat.
MfG Maik
Ich habe mein System (Stretch) neu aufgesetzt und wollte jetzt ebusd zum laufen bringen, was auch soweit funktioniert, nur habe ich schon wieder Probleme, dass er die CSV-Dateien partout nicht finden will. Ich hatte damals auch schon Probleme und habe es irgendwie zum laufen bekommen.
Habe ebusd lt. Wiki compiliert und es läuft soweit. Die ebusd-configuration musste ich jedoch lt. Beschreibung bei Github nehmen, da die Einträge im FHEM-Wiki extrem veraltet erscheinen. Zumindest hat es so gar nicht richtig funktioniert.
Da ich jetzt auch nicht der Linux-Crack bin, habe ich die Befehle per Copy & Paste von der Github-Seite zur ebusd-configuration genommen. Nur warum werden diese dann nicht gefunden?
Ist dafür der Eintrag "--configpath" zuständig, welchen ich bei mir nicht in der etc/default/ebusd drin habe, weil ich diesbezüglich keine Doku gefunden habe?
Kommt mir das nur so vor, oder ist das größte Problem immer wieder das finden der CSV-Files? Im Log-File sehe ich auch nicht, wo danach gesucht wird.
Dort sehe ich nur, dass Daten von der ebus-Platine gesendet werden, aber nicht entschlüsselt werden können :(
Ich weiß, dass bei der Schnelllebigkeit von Software die Dokumentation meist hinten hinüber fällt. An dieser Stelle wäre es jedoch sicherlich sinnvoll, das WIKI anzupassen, da damit wohl einige nachfragen obsolet wären. Dort habe ich z.B. nix gefunden bzgl. der Konfiguration in /etc/default/ebusd (EBUSD_OPTS). Dafür musste ich in einem anderen Thread nachschauen, welcher dahingehend aber scheinbar auch schon wieder veraltet ist.
Weiß nicht, ob es nur mir so geht, aber ich muss mir die ganze Sachen an etlichen Stellen zusammen addieren. Und wenn dem so ist, dann ist das WIKI hinfällig und die Wahrscheinlichkeit das irgendetwas nicht zusammen spielt potenziert sich :(
Wo liegen denn deine csv und mit welchen Parametern startest du den Dienst?
Die CSV-Dateien liegen unter /etc/ebusd. Und ich habe ebusd ohne Parameter aufgerufen, sprich einfach "sudo service ebusd start".
Hier mal ein paar Ausgaben von der Console:
ebusd --scanconfig --checkconfig
2018-08-17 22:07:13.607 [main notice] ebusd 3.2.v3.2-5-g671c8d2 performing configuration check...
2018-08-17 22:07:13.878 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2018-08-17 22:07:13.878 [main notice] ebusd stopped
ebusctl info
version: ebusd 3.2.v3.2-5-g671c8d2
signal: acquired
symbol rate: 25
max symbol rate: 116
min arbitration micros: 68
max arbitration micros: 346
min symbol latency: 5
max symbol latency: 27
reconnects: 0
masters: 3
messages: 270
conditional: 0
poll: 1
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=V3x00;SW=0118;HW=9902"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
ebusctl find -d
470 YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0
broadcast outsidetemp = 14.750
broadcast vdatetime = 22:12:52;17.08.2018
scan.08 = Vaillant;V3x00;0118;9902
scan.15 = Vaillant;47000;0420;1403
scan.15 id = 21;16;13;0020184593;0082;005830;N6
Und hier aus der Konfigdatei:
EBUSD_OPTS="-d 192.168.1.40:8889 -l /var/log/ebusd.log --configpath=/etc/ebusd --scanconfig --latency=20000"
Und hier mal ein Auszug aus dem Logfile:
2018-08-17 22:08:26.705 [bus notice] bus started with own address 31/36
2018-08-17 22:08:26.713 [bus notice] signal acquired
2018-08-17 22:08:27.584 [bus notice] new master 10, master count 2
2018-08-17 22:08:27.648 [bus notice] new master 03, master count 3
2018-08-17 22:08:27.648 [update notice] received unknown MS cmd: 1008b5040100 / 0a00555816ffffffffc00e
2018-08-17 22:08:31.621 [update notice] received unknown MS cmd: 1008b5100900003d78ffff000000 / 0101
2018-08-17 22:08:35.755 [update notice] received unknown MS cmd: 1008b5110101 / 093c00c00e00490000ff
2018-08-17 22:08:36.833 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2018-08-17 22:08:36.833 [update notice] store 08 ident: done
2018-08-17 22:08:36.833 [update notice] sent scan-read scan.08 QQ=31: Vaillant;V3x00;0118;9902
2018-08-17 22:08:36.833 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2018-08-17 22:08:36.836 [main error] unable to load scan config 08: no file from vaillant with prefix 08 matches ID "v3x00", SW0118, HW9902
2018-08-17 22:08:36.836 [main error] scan config 08: ERR: element not found
2018-08-17 22:08:38.964 [bus notice] scan 15: ;Vaillant;47000;0420;1403
2018-08-17 22:08:38.965 [update notice] store 15 ident: done
2018-08-17 22:08:38.965 [update notice] sent scan-read scan.15 QQ=31: Vaillant;47000;0420;1403
2018-08-17 22:08:38.965 [bus notice] scan 15: ;Vaillant;47000;0420;1403
2018-08-17 22:08:38.985 [main notice] read common config file vaillant/scan.csv
2018-08-17 22:08:38.986 [main notice] read common config file vaillant/general.csv
2018-08-17 22:08:38.989 [main notice] read common config file vaillant/broadcast.csv
2018-08-17 22:08:39.035 [main notice] read scan config file vaillant/15.470.csv for ID "47000", SW0420, HW1403
2018-08-17 22:08:39.067 [main notice] found messages: 269 (0 conditional on 0 conditions, 1 poll, 8 update)
2018-08-17 22:08:39.180 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:40.043 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:40.231 [update notice] sent unknown MS cmd: 3115b5090124 / 09003231313631333030
2018-08-17 22:08:40.411 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:40.587 [update notice] sent scan-read scan.15 id QQ=31:
2018-08-17 22:08:40.760 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:40.948 [update notice] sent scan-read scan.15 id QQ=31:
2018-08-17 22:08:41.005 [bus notice] max. symbols per second: 108
2018-08-17 22:08:41.134 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:41.330 [update notice] sent scan-read scan.15 id QQ=31: 21;16;13;0020184593;0082;005830;N6
2018-08-17 22:08:41.330 [bus notice] scan 15: ;21;16;13;0020184593;0082;005830;N6
2018-08-17 22:08:41.518 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:42.549 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:42.734 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:42.929 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:43.111 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:43.295 [update notice] sent poll-read 470 YieldThisYear QQ=31:
2018-08-17 22:08:43.481 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:45.126 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:45.293 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:45.473 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:45.645 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:46.456 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:46.633 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:46.860 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:47.033 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:47.206 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:47.382 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:47.568 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:47.748 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:48.524 [update notice] received update-read broadcast vdatetime QQ=10: 22:11:52;17.08.2018
2018-08-17 22:08:48.728 [update notice] received unknown BC cmd: 10feb5160304f012
2018-08-17 22:08:48.951 [update notice] received unknown MS cmd: 1008b512020000 / 0101
2018-08-17 22:08:51.180 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:51.399 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:51.581 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:51.997 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:52.181 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:52.356 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:52.533 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:52.716 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:52.907 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:53.084 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:53.254 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:53.436 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:55.854 [update notice] received unknown MS cmd: 1008b5110101 / 093c00c00e00490000ff
2018-08-17 22:08:57.134 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:57.313 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:57.498 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:57.669 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
2018-08-17 22:08:57.894 [update notice] sent poll-read 470 YieldThisYear QQ=31: 0;0;0;0;0;0;0;0;0;0;0;0
EDIT sagt:
Ich habe jetzt mal ein wenig mit den Parameter auf der Console getestet und folgendes Ergebnis erzielt:
ebusd --scanconfig -c, --configpath=/etc/ebusd --checkconfig
2018-08-17 23:05:12.719 [main notice] ebusd 3.2.v3.2-5-g671c8d2 performing configuration check...
2018-08-17 23:05:15.676 [main notice] found messages: 11134 (437 conditional on 154 conditions, 17 poll, 64 update)
2018-08-17 23:05:15.827 [main notice] ebusd stopped
Nur was muss ich jetzt wo eintragen, damit diese dauerhaft gefunden werden?
Hallo Allodo,
deine CSV-Dateien müssten in einem vaillant-Ordner unter /etc/ebusd liegen. Der Inhalt des ebusd-Ordner sollte ungefähr so aussehen:
/etc/ebusd $ ls
broadcast.csv memory.csv _templates.csv vaillant wolf
Gruß
Maik
Da liegen sie ja auch. Sie werden ja auch gefunden (siehe meinen Auszug), wenn ich den configpath als Parameter vorgebe.
Nur werden sie eben scheinbar nicht gefunden, wenn ich den Pfad in der Konfigdatei vorgebe :(
@ allodo
warum startest du den service unter stretch mit sudo service ebusd start?
stretch verwendet doch jetze systemctl
also
systemctl start ebusd.service
ist die 08.3x00.csv wirklich vorhanden?
gib mal ein ls -l /etc/ebusd/vaillant/
MfG Maik
Hallo hat jemand eine Idee warum sich meine Vaillant VRC700/5 neustartet wenn ich die EBus Platine mit der EBus Schnittstelle verbinde?
Hallo Allodo,
guck doch mal mit welchen Parametern der ebusd läuft, wenn er automatisch nach dem Booten gestartet wurde. Dafür kannst du dieses Kommando in ein Terminal-Fenster / SSH-Fenster eingeben:
ps aux | grep ebusd
Als Ausgabe solltest du sowas erhalten:
root 580 1.0 0.4 80224 4320 ? Ssl Jul24 369:15 /usr/bin/ebusd --device=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI056B4F-if00-port0 --configpath=/etc/ebusd --scanconfig --httpport=8020 --htmlpath=/var/lib/ebusd/html_3.0 --generatesyn --sendretries=4 --acquireretries=5 --pollinterval=1 --lograwdatafile=/tmp/ebusd.raw.log --lograwdatasize=10240 --enablehex
pi 11020 0.0 0.0 4776 524 pts/0 R+ 20:44 0:00 grep --color=auto ebusd
Gruß
Maik
@ hr_lose
Busspannung bricht ein?
Mfg Maik
Zitat von: hr_lose am 18 August 2018, 19:29:52
Hallo hat jemand eine Idee warum sich meine Vaillant VRC700/5 neustartet wenn ich die EBus Platine mit der EBus Schnittstelle verbinde?
Moin
Und willkommen im forum!
Welche Platine setzt Du denn ein?
Gruss Christoph
Moin Christoph,
ich habe gerade eine Platine V 1.6 bestückt und das erste mal mit der Heizug verbunden. Die Vaillant Steuerung kommt gar nicht mehr an den start, solange die Platine mit dem USB Serial Adapter und meinem Raspberry verbunden ist.
Habe ich einen Fehler in der Platine oder brauche ich eine zusätzliche Spannungsversorgung für die EBus Platine?
EBUSD Version 2.1.28b50d2
Gruß
Ingo
@hr_lose
das kann mehrere Ursachen haben, sicher ist nur das die Schaltung zuviel Strom aufnimmt. Du solltest jetzt die Gründe ermitteln, ist alles richtig bestückt und vor allem die Dioden richtig gepolt? Der Fehler muss ja in der Nähe des Gleichrichters oder der Sendestufe zu suchen sein. Eventuell sind auch nur Lötbrücken zwischen den Leiterbahnen vorhanden.
Wenn du nur die Platine an die eBus Klemme anhängst, dann darf sich nichts an der Heizungsanlage ändern. Tut es das doch, dann liegt ein Fehler an der Platine vor. Ich würde dir empfehlen erst einen optischen Check mit der Lupe vornehmen und wenn du dadurch nicht fündig wirst musst du wohl oder übel einmal mit Messungen beginnen. zB: wieviel bricht die Spannung an der eBus Klemme zusammen?
Kannst du eventuell Bilder von vorne und hinten der Platine hier posten, das würde uns eventuell schon die Fehlersuche erleichtern?
LG
Reinhart
@Reinhard
Ich kann keine Lötbrücken finden. Werde mich jetzt mal mit dem Durchmessen versuchen. Anbei die gewünschten Bilder.
Mein USB to Serial Adapter hat einen Jumper (3,3V - 5V) welche Einstellung ist die Richtige.
Zusätzlich habe ich den Optokoppler U3 einmal entfernt -> dann tritt der Kurzschluß nicht auf.
Dann müßte der Fehler ja im Bereich C1, U4, T1, Z1 4x 1N4148, R6 oder R1 liegen oder?
Gruß
Ingo
...das mit dem scharf fotografieren üben wir aber nochmal, gelle ? da kann man nämlich so nichts erkennen, was wichtig wäre !
Zitat von: hr_lose am 20 August 2018, 21:59:51
Mein USB to Serial Adapter hat einen Jumper (3,3V - 5V) welche Einstellung ist die Richtige.
Gruß
Ingo
Moin
TTL Pegel ist 5V wenn ich mich recht erinnere! ;)
Aber was passiert denn, wenn Du den USB-Seriell nicht mit Spannung versorgst? Geht der VRC dann auch aus? Bei mir ist das auch so gewesen, hast Du schon mal ein paar Minuten gewartet? Die neuen Controller sind wohl etwas pingelig!
Gruss Christoph
Oh ja, das mit den Fotos da erkennen wir nicht wirklich viel bei der Tiefenschärfe.
Wenn du U3 entfernst und es geht dann die Therme, dann ist der Fehler tatsächlich im Sendezweig verborgen. Es gibt aber jetzt auch mehrere Möglichkeiten, setze U3 nochmals ein und messe die 5V vom Regler. Sind die da, dann messe die Spannung am eBus bei angehängter Platine, die sollte gleich sein wie ohne Platine.
Es kann auch sein, das der Transistor aus irgend einem Grund durchsteuert und den eBus auf Low Pegel zieht, dann würde der gesamte eBus für alle Teilnehmer blockiert! Kannst ja einmal die Zenerdiode an einem Ende auflöten und schauen ob der Fehler dann weg ist, das würde diese Theorie dann bestätigen. Dann können wir weiter schauen wo der Hund begraben ist.
LG
Sorry, bin erst heute dazu gekommen mich weiter damit zu beschäftigen.
Hier mal die Ausgaben:
ls -l /etc/ebusd/vaillant/
insgesamt 768
lrwxrwxrwx 1 root root 10 Aug 16 19:54 05.vd2.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 05.vd3.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5833 Aug 16 19:54 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 05.vd6.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 05.vl8.csv -> 05.vd4.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 05.vl9.csv -> 05.vd4.csv
-rw-r--r-- 1 root root 5350 Aug 16 19:54 06.pms.csv
-rw-r--r-- 1 root root 3723 Aug 16 19:54 08.bai.csv
-rw-r--r-- 1 root root 28639 Aug 16 19:54 08.ehp.csv
-rw-r--r-- 1 root root 2753 Aug 16 19:54 08.hmu.csv
-rw-r--r-- 1 root root 5656 Aug 16 19:54 0a.pmw.hwc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 15.140.csv -> 15.350.csv
-rw-r--r-- 1 root root 4822 Aug 16 19:54 15.350.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 15.360.csv -> 15.350.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 15.36p.csv -> 15.350.csv
-rw-r--r-- 1 root root 9886 Aug 16 19:54 15.370.csv
-rw-r--r-- 1 root root 8443 Aug 16 19:54 15.392.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 15.400.csv -> 15.350.csv
-rw-r--r-- 1 root root 15460 Aug 16 19:54 15.430.csv
-rw-r--r-- 1 root root 17160 Aug 16 19:54 15.470.csv
-rw-r--r-- 1 root root 19974 Aug 16 19:54 15.700.csv
-rw-r--r-- 1 root root 3949 Aug 16 19:54 15.e7f.csv
-rw-r--r-- 1 root root 9945 Aug 16 19:54 15.f37.csv
-rw-r--r-- 1 root root 14715 Aug 16 19:54 15.f43.csv
-rw-r--r-- 1 root root 16734 Aug 16 19:54 15.f47.csv
lrwxrwxrwx 1 root root 12 Aug 16 19:54 15.heb.csv -> 15.sdr_p.csv
lrwxrwxrwx 1 root root 12 Aug 16 19:54 15.hep.csv -> 15.sdr_p.csv
-rw-r--r-- 1 root root 2986 Aug 16 19:54 15.sdr_p.csv
-rw-r--r-- 1 root root 13608 Aug 16 19:54 15.ui.csv
-rw-r--r-- 1 root root 5908 Aug 16 19:54 15.uih.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 1c.rcc.4.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 1c.v81.4.csv -> 75.v81.csv
-rw-r--r-- 1 root root 539 Aug 16 19:54 23.ehp.cc.csv
-rw-r--r-- 1 root root 885 Aug 16 19:54 23.solsy.cc.csv
-rw-r--r-- 1 root root 886 Aug 16 19:54 23.vr630.cc.csv
-rwxr-xr-x 1 root root 913 Aug 16 19:54 23.zeo.cc.csv
-rw-r--r-- 1 root root 2196 Aug 16 19:54 25.ehp.hwc.csv
-rw-r--r-- 1 root root 2906 Aug 16 19:54 25.solsy.hwc.csv
-rw-r--r-- 1 root root 1944 Aug 16 19:54 25.vr630.hwc.csv
-rwxr-xr-x 1 root root 851 Aug 16 19:54 25.zeo.hwc.csv
-rw-r--r-- 1 root root 4203 Aug 16 19:54 26.solsy.hc.csv
-rw-r--r-- 1 root root 2187 Aug 16 19:54 26.vr630.hc.csv
-rw-r--r-- 1 root root 2447 Aug 16 19:54 26.vr_71.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 35.rcc.1.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 35.v81.1.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 3c.rcc.5.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 3c.v81.5.csv -> 75.v81.csv
-rw-r--r-- 1 root root 6424 Aug 16 19:54 50.ehp.mc.csv
-rw-r--r-- 1 root root 3794 Aug 16 19:54 50.solsy.mc.csv
-rw-r--r-- 1 root root 7583 Aug 16 19:54 50.v61.mc.csv
-rw-r--r-- 1 root root 2403 Aug 16 19:54 50.vr630.mc.csv
-rwxr-xr-x 1 root root 1599 Aug 16 19:54 50.zeo.mc.csv
-rw-r--r-- 1 root root 2446 Aug 16 19:54 51.vr630.mc.3.csv
-rw-r--r-- 1 root root 5359 Aug 16 19:54 52.mc2.mc.4.csv
-rw-r--r-- 1 root root 1349 Aug 16 19:54 52.vr_70.csv
-rw-r--r-- 1 root root 4957 Aug 16 19:54 53.mc2.mc.5.csv
lrwxrwxrwx 1 root root 15 Aug 16 19:54 54.mc2.mc.6.csv -> 52.mc2.mc.4.csv
lrwxrwxrwx 1 root root 15 Aug 16 19:54 55.mc2.mc.7.csv -> 53.mc2.mc.5.csv
-rw-r--r-- 1 root root 515 Aug 16 19:54 64.v65.csv
-rw-r--r-- 1 root root 713 Aug 16 19:54 75.rcc.csv
-rw-r--r-- 1 root root 2601 Aug 16 19:54 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 7c.rcc.6.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 7c.v81.6.csv -> 75.v81.csv
-rwxr-xr-x 1 root root 15147 Aug 16 19:54 84.zeo.csv
-rw-r--r-- 1 root root 3309 Aug 16 19:54 a0.sol.hwc.csv
-rw-r--r-- 1 root root 661 Aug 16 19:54 a1.sol.cc.csv
-rw-r--r-- 1 root root 14212 Aug 16 19:54 bai.0010002315.inc
-rw-r--r-- 1 root root 16921 Aug 16 19:54 bai.0010002465.inc
-rw-r--r-- 1 root root 16142 Aug 16 19:54 bai.0010003857.inc
-rw-r--r-- 1 root root 16494 Aug 16 19:54 bai.0010003886.inc
-rw-r--r-- 1 root root 22824 Aug 16 19:54 bai.0010004121.inc
-rw-r--r-- 1 root root 17089 Aug 16 19:54 bai.0010004150.inc
-rw-r--r-- 1 root root 17150 Aug 16 19:54 bai.0010005400.inc
-rw-r--r-- 1 root root 18344 Aug 16 19:54 bai.0010006101.inc
-rw-r--r-- 1 root root 16327 Aug 16 19:54 bai.0010006341.inc
-rw-r--r-- 1 root root 17863 Aug 16 19:54 bai.0010007508.inc
-rw-r--r-- 1 root root 17872 Aug 16 19:54 bai.0010010674.inc
-rw-r--r-- 1 root root 16963 Aug 16 19:54 bai.0010015600.inc
-rw-r--r-- 1 root root 5547 Aug 16 19:54 bai.0020066007.inc
-rw-r--r-- 1 root root 17001 Aug 16 19:54 bai.308523.inc
-rw-r--r-- 1 root root 620 Aug 16 19:54 broadcast.csv
-rw-r--r-- 1 root root 6658 Aug 16 19:54 e0.omu.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 e1.omu.1.csv -> e0.omu.csv
-rw-r--r-- 1 root root 5665 Aug 16 19:54 ec.sol.sc.csv
-rw-r--r-- 1 root root 6001 Aug 16 19:54 ec.solsy.sc.csv
-rwxr-xr-x 1 root root 1280 Aug 16 19:54 ec.zeo.sc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 ed.pms.sc.csv -> 06.pms.csv
-rw-r--r-- 1 root root 525 Aug 16 19:54 errors.inc
lrwxrwxrwx 1 root root 10 Aug 16 19:54 f5.rcc.3.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 f5.v81.3.csv -> 75.v81.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 fc.rcc.7.csv -> 75.rcc.csv
lrwxrwxrwx 1 root root 10 Aug 16 19:54 fc.v81.7.csv -> 75.v81.csv
-rw-r--r-- 1 root root 693 Aug 16 19:54 general.csv
-rw-r--r-- 1 root root 1010 Aug 16 19:54 hcmode.inc
-rw-r--r-- 1 root root 883 Aug 16 19:54 hwcmode.inc
-rw-r--r-- 1 root root 404 Aug 16 19:54 iotest620.inc
-rw-r--r-- 1 root root 407 Aug 16 19:54 iotest630.inc
-rw-r--r-- 1 root root 307 Aug 16 19:54 iotestact.inc
-rw-r--r-- 1 root root 348 Aug 16 19:54 iotestbmc.inc
-rw-r--r-- 1 root root 313 Aug 16 19:54 iotestbsol.inc
-rw-r--r-- 1 root root 423 Aug 16 19:54 iotesthp.inc
-rw-r--r-- 1 root root 1435 Aug 16 19:54 mcmode.inc
-rw-r--r-- 1 root root 316 Aug 16 19:54 quick.inc
-rw-r--r-- 1 root root 238 Aug 16 19:54 roomtempoffset.inc
-rw-r--r-- 1 root root 792 Aug 16 19:54 scan.csv
-rw-r--r-- 1 root root 530 Aug 16 19:54 service.inc
-rw-r--r-- 1 root root 3475 Aug 16 19:54 _templates.csv
-rw-r--r-- 1 root root 727 Aug 16 19:54 tempsetpoints.inc
-rw-r--r-- 1 root root 647 Aug 16 19:54 timercc.inc
-rw-r--r-- 1 root root 677 Aug 16 19:54 timercool.inc
-rw-r--r-- 1 root root 633 Aug 16 19:54 timerhc.inc
-rw-r--r-- 1 root root 647 Aug 16 19:54 timerhwc.inc
-rw-r--r-- 1 root root 979 Aug 16 19:54 timer.inc
-rw-r--r-- 1 root root 667 Aug 16 19:54 timertariff.inc
-rw-r--r-- 1 root root 606 Aug 16 19:54 yield3d43.inc
-rw-r--r-- 1 root root 606 Aug 16 19:54 yield3f40.inc
-rw-r--r-- 1 root root 606 Aug 16 19:54 yield4445.inc
-rw-r--r-- 1 root root 606 Aug 16 19:54 yield8485.inc
-rw-r--r-- 1 root root 630 Aug 16 19:54 yield8485r.inc
ps aux | grep ebusd
root 31622 0.3 0.1 31132 1708 ? Ssl 20:37 0:00 /usr/bin/ebusd -c --configpath=/etc/ebusd -d 192.168.1.40:8889 -l /var/log ebusd.log --scanconfig --latency=20000 --httpport=8889
pi 31994 0.0 0.0 4776 552 pts/1 S+ 20:38 0:00 grep --color=auto ebusd
@ Allodo
2018-08-17 22:08:36.833 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2018-08-17 22:08:36.836 [main error] unable to load scan config 08: no file from vaillant with prefix 08 matches ID "v3x00", SW0118, HW9902
ich sehe keine 08.v3x00.csv
-rw-r--r-- 1 root root 3723 Aug 16 19:54 08.bai.csv
-rw-r--r-- 1 root root 28639 Aug 16 19:54 08.ehp.csv
-rw-r--r-- 1 root root 2753 Aug 16 19:54 08.hmu.csv
hast du diese überhaupt?
wenn nicht musst du diese erst selbst für dieses Gerät erstellen.
was ist das für ein Gerät??
MfG Maik
Ich habe alles so gemacht, wie es im Github ebusd-configuration beschrieben ist.
git clone https://github.com/john30/ebusd-configuration.git
if [ -d /etc/ebusd ]; then sudo mv /etc/ebusd /etc/ebusd.old; fi
sudo ln -s $PWD/ebusd-configuration/ebusd-2.1.x/de /etc/ebusd
Selbst erstellen muss ich denke ich weniger, da ja alles schon einmal lief und ich auch Werte erhalten habe.
Nur jetzt nach dem Neu aufsetzen, leider nicht :(
Habe eine Vaillant ecoCompact mit 470er Bedienteil (dank Konverterplatine). Dort wurde damals die 15.470.csv geladen.
Hallo Reinhart,
Foto habe ich jetzt ausgetauscht besser kriege ich das mit dem Telefon scheinbar nicht hin.
Ich habe mich jetzt mit der Platine an den Testaufbau im Büro gesetzt.
Netzteil mit 24 V und 330 Ohm Vorwiderstand:
Messung am EBUS Anschluss:
EBUS 1 zu EBUS 2 = 21,22 V
Jetzt zum Vergleich mit 5V(USB)auf dem Seriell zu USB Adapter (kein Raspberry nur ein Netzteil) Jumper auf 5V
EBUS 1 zu EBUS 2 = 10,35 V
Messung am 78L08:
Pin 2(GND) zu 3 (OUT) = 5V -> OK
Im Anhang befindet sich der Schaltplan zur statischen Messung zusätzlich mit meinen Werten gelb hinterlegt.
Als GND habe ich für den rechten Teil GND vom 78L05 verwendet und für den linken Teil GND am Stecker J3. Ist hoffe das ist so korrekt?
Einige Werte sind OK Andere fallen völlig aus dem Rahmen. Leider fehlt mir das Wissen um dies zu bewerten.
Ach ja die LED zum Abstimmen wie genau geht das? Bei mir leuchtet sie immer.
Nun zum Lötkolben :o
Nach dem Auslöten der Z1 Diode bricht die Spannung am Bus nicht mehr ein und die Steuerung Heizung startet auch nicht mehr in einer Schleife.
ah, super, durch die Messungen haben wir den Fehler schon stark eingegrenzt. Es ist so wie vermutet, der Sendetransistor steuert durch und zieht den eBus auf logisch Low, daher die geringe Spannung von 10,35V bei angeschlossener Platine.
Der Grund warum der Transistor durchsteuert ist, weil auch der Optokoppler U3 durchsteuert, der wiederum bekommt seinen Pegel von U2-3 der eigentlich Low sein sollte. Es kommt daher jetzt nur mehr der Uart in Frage, der falsche Pegel liefert oder doch vielleicht irgendwie die Anschlüsse vertauscht worden sind oder einfach defekt ist. RxD und TxD vielleicht vertauscht?
Es wäre schön, wenn du einen anderen Uart zum Testen hättest, denn die Schaltung als solche scheint zu funktionieren. Gejumpert hast du den Uart schon auf 5V, denn die 2V die da vom Uart Txd kommen sind nicht richtig, müssten mehr sein damit der Sende Transistor über den Optokoppler nicht mehr angesteuert wird. Ein High (5V) an den Eingängen 8+9 des U2-3 muss zu einem sauberen Low auf U2-3 Pin 10 führen. Und ein Low sperrt dann den Transistor, das ist aber jetzt mit den 2V nicht so.
LG
gehört bei der Schaltung rx an rx oder rx/tx gekreuzt ?
Im Bild von hr_lose geht TXD direkt an einen Optokoppler, also muss dieser Anschluss an die Sendeseite des USB-TTL-Converters.
Sinnvollerweise sollten diese mit TX gekennzeichnet sein, aber vielleicht gibt es auch Typen, wo die Beschriftung vertauscht ist?!
Müsste man mal am abgezogenen Converter messen.
Zitat von: cs-online am 24 August 2018, 08:21:44
gehört bei der Schaltung rx an rx oder rx/tx gekreuzt ?
Auf der eBus-Platine/Zeichnung war das schon immer etwas kurz (verwirrend...) beschriftet, genau genommen ist das
da eben kein RXD-Anschluß, sondern nur ein "hier bitte RXD vom USB-Modul anschließen"-Anschluß. ;-)
Also, bei einem normalem (*) USB-Modul und der eBus-Platine:
RXD (des USB-Moduls) an RXD (auf der Platine)
TXD (des USB-Moduls) an TXD (auf der Platine)
(*) normales USB-Modul:
Aber wie ja auch schon Sven77 sagt,
Zitat von: Sven77 am 24 August 2018, 09:18:35...Sinnvollerweise sollten diese mit TX gekennzeichnet sein, aber vielleicht gibt es auch Typen, wo die Beschriftung vertauscht ist?!...
es soll wohl auch vereinzelte USB-Module geben, bei denen hat es jemand wohl besonders gut gemeint
und hat den ggf. je Anwendungsfall zu kreuzenden Anschluß RX mit TX (und umgekehrt) beschriftet,
"damit man eben nichts falsch macht" :-(
Ich denke aber, bei so 99% der USB-Module ist deren Beschriftung wohl techn. richtig, RXD ist RXD und TXD ist TXD,
und es ist damit ein "normales" USB-Modul. :-)
ja, das ist nämlich das verwirrende, ich kenn das von Arduino und co nämlich sonst auch so, dass rx (USB) an tx(arduino) und umgekehrt dran kommt...
Ja, die Bezeichnung auf der Platine war hier von Start an unglücklich gewählt und wurde daher auch oft erklärt wie es richtig sein muss.
Ich nehme jetzt an, hr_lose hat das einfach überlesen und hat jetzt ein vermeintliches Problem mit der Platine.
Warten wir jetzt einfach ab, bis uns hr_lose Bescheid gibt ob das die Ursache der Fehlfunktion seiner Platine war.
LG
Hallo
habe jetzt einen anderen USB Adapter bekommen leider mit dem selben Ergebnis. Jedoch habe ich dann einmal den EBUS an dem Warmwasserspeicher benutzt und nicht dem an der VRC700 (das war ja die Steuerung die immer neustartete).
Und siehe da kein Neustart mehr! Also kein Fehler an der Platine und auch kein Fehler an dem USB Adapter. :-X
ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 77
masters: 3
messages: 13
address 03: master #11
address 08: slave #11, scanned
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8
Jetzt geht es also weiter für mich.
Tut mir leid das ich Euch damit aufgehalten habe aber vieleicht hilft es ja jemand so einen Fehler zu vermeiden.
Anbei einmal meine EBUSD.log Datei vielleicht kann einmal jemand prüfen ob das so "normal" ist.
Hallo
kann mir bitte jemand auf die Sprünge helfen?
ich kann jetzt zumindest schon die Außentemperatur auslesen.
ebusctl r -c broadcast outsidetemp
21.250
Und mit ebusctl info wird mir schonmal ein Gerät angezeigt.
ebusctl info
version: ebusd 2.1.28b50d2
signal: acquired
symbol rate: 25
masters: 4
messages: 12
address 01: master #6
address 03: master #11
address 06: slave #6, scanned
address 08: slave #11, scanned
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403"
address 31: master #8, ebusd
address 36: slave #8
address ed: slave, scanned
Wie kann ich diese Gerät jetzt abfragen?
irgendwas stimmt noch nicht ganz, das Gerät 700 wird zwar gefunden aber keine csv geladen. Man sieht das auch bei den "messages:12", das sollten schon ein paar Hundert Definitionen (400-500) sein.
Deshalb funktionieren nur die Broadcast und die kommen automatisch daher.
es sollte so irgendwas ähnliches bei dir stehen:
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
Ich habe leider keine 700 und kann da nichts nachstellen, aber wenn du hier im Thread nach 15.700 filterst findest du viele Beiträge zu diesem Thema die ähnliche Probleme haben. Das Hauptproblem bei den Leuten ist, das die 700 nicht jedesmal gefunden wurde.
Du kannst das ja ein paarmal probieren und Stoppen/Starten ob sich da was ändert, aber immer einige Minuten dazwischen warten weil der Scan etwas dauern kann. Ich glaube aber das du mit der alten V1.5 hier ohnehin schlechtere Karten hast.
LG
Zitat von: Reinhart am 01 September 2018, 17:09:54
...irgendwas stimmt noch nicht ganz, das Gerät 700 wird zwar gefunden aber keine csv geladen...
Ist es in diesem Fall nicht eher so, daß das Gerät einwandfrei gefunden wird (700er...) , es wird aber keine csv geladen,
weil es eben für genau diese 700er:
... SW=0510;HW=6403noch keine csv gibt?
@hr_lose :
Unabhängig davon, Deine ebusd-Version 2.1.28b50d2 ist ja ziemlich sehr alt (gab es da die 700er schon?),
ich würde da zumindest 'mal die ebusd-Version 3.2 installieren (besser wäre wohl: neu auschecken/selbst kompilieren).
Beachte dabei aber, daß sich von der Version 2.1 bis zur Version 3.2 viele Dinge (Programmstart, Config usw.) manchmal
grundlegend geändert haben, das ebusd-wiki wäre dazu der richtige Ansprechpartner (https://github.com/john30/ebusd/wiki).
LG
Hallo sua danke für den Tipp.
Jetzt ist Ebusd Version 3.2 installiert.
ebusctl info
version: ebusd 3.2.v3.2-5-g671c8d2
signal: acquired
symbol rate: 90
max symbol rate: 99
min arbitration micros: 721
max arbitration micros: 1994
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 4
messages: 216
conditional: 3
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=VMS02;SW=0108;HW=1703"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0201;HW=9002", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ed: slave, scanned "MF=Vaillant;ID=VMS02;SW=0108;HW=1703"
Zumindest wird jetzt auch eine csv geladen.
Liegen die jetzt nur noch online?
Nun kann ich die Werte aus der bai.308523.inc auch abfragen!
ebusctl r StorageTemp
58.19;ok
Hat jemand die anderen Hardware Typen schon einmal abgefragt?
Ein besonders Interesse habe ich an Werten aus meiner WW Solar Anlage. (z.B. Speicher ist Temeratur und Solar Temeratur,auf dem Dach)
Weiß ja im Moment noch nicht eimal welches Device die Steuerung für die Solaranlage ist.
Hi,
ich bin neu im Ebus Thema und scheitere schon früh. Ich bekomme nichts lesbares. Oder suche ich im Log an der falschen Stelle?
ebusctl info
version: ebusd 3.2.v3.2
update check: revision v3.2-2-g1737636 available
signal: acquired
symbol rate: 24
max symbol rate: 99
reconnects: 0
masters: 3
messages: 14
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 71: master #9
address 76: slave #9
Im Log sehe ich nur folgendes:
2018-09-03 00:25:42.462 [main notice] ebusd 3.2.v3.2 started with auto scan
2018-09-03 00:25:42.893 [bus notice] bus started with own address 31/36
2018-09-03 00:25:42.929 [bus notice] signal acquired
2018-09-03 00:25:49.002 [bus notice] new master 10, master count 1
2018-09-03 00:25:49.061 [bus notice] new master 03, master count 2
2018-09-03 00:25:49.061 [update notice] received unknown MS cmd: 1008b5110101 / 094b43a014ff6c0000ff
2018-09-03 00:25:49.328 [bus notice] new master 71, master count 3
2018-09-03 00:25:49.328 [update notice] received unknown MS cmd: 1076b5110101 / 09ff43a014ff6c0000ff
2018-09-03 00:25:49.870 [update notice] received unknown MS cmd: 1008b51009000000ffffff070000 / 0101
2018-09-03 00:25:50.141 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2018-09-03 00:25:52.893 [main error] scan config 08: ERR: element not found
2018-09-03 00:25:54.894 [main error] scan config 15: ERR: element not found
2018-09-03 00:25:56.894 [main error] scan config 76: ERR: element not found
2018-09-03 00:25:59.030 [update notice] received unknown MS cmd: 1008b5110101 / 094b43a014ff6c0000ff
2018-09-03 00:25:59.297 [update notice] received unknown MS cmd: 1076b5110101 / 09ff43a014ff6c0000ff
2018-09-03 00:25:59.842 [update notice] received unknown MS cmd: 1008b51009000000ffffff070000 / 0101
2018-09-03 00:26:00.113 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2018-09-03 00:26:09.037 [update notice] received unknown MS cmd: 1008b5110101 / 094b43a014ff6c0000ff
2018-09-03 00:26:09.304 [update notice] received unknown MS cmd: 1076b5110101 / 09ff43a014ff6c0000ff
2018-09-03 00:26:09.848 [update notice] received unknown MS cmd: 1008b51009000000ffffff070000 / 0101
2018-09-03 00:26:10.119 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
2018-09-03 00:26:19.043 [update notice] received unknown MS cmd: 1008b5110101 / 094b43a014ff6c0000ff
2018-09-03 00:26:19.310 [update notice] received unknown MS cmd: 1076b5110101 / 09ff43a014ff6c0000ff
2018-09-03 00:26:19.855 [update notice] received unknown MS cmd: 1008b51009000000ffffff070000 / 0101
2018-09-03 00:26:20.126 [update notice] received unknown MS cmd: 1076b51009000000ffffff050000 / 0101
Muss ich an die Messages oder gehe ich ganz falsch ran?
Danke für eure Hilfe.
Zitat von: hr_lose am 02 September 2018, 14:57:46
Hat jemand die anderen Hardware Typen schon einmal abgefragt?
Ein besonders Interesse habe ich an Werten aus meiner WW Solar Anlage. (z.B. Speicher ist Temeratur und Solar Temeratur,auf dem Dach)
Weiß ja im Moment noch nicht eimal welches Device die Steuerung für die Solaranlage ist.
Die VMS02 (address 06+ed) ist das Solarmodul, 08/BAI ist der Wärmeerzeuger (hattest du den Typ schon mal genannt?) und 15 ist die VRC700/5.
Ich habe eine VPM 20/2 S, die meldet sich auf dem Bus aber als "PMS02" und lädt die "06.pms.csv" - vielleicht würden die Nachrichten von der auch auf diese VMS02 passen?! Dann müsste man aber die CSV entsprechend anpassen (mindestens umbenennen), siehe dabei auch "--configpath" in den neueren Versionen!
Adresse 31/36 sollte Ebusd selbst sein. Bei mir wird dieser aber nicht beim Scan angezeigt, kann aber versionsabhängig sein...
Wie startest du den ebusd? Bei mir sieht es so aus, wenn ich kein scanconfig verwende.
Hallo,
ich habe ebusd nun schon eine ganze Weile laufen.
Jetzt würde ich gerne die Zirkulationspumpe meiner Vaillant VWL 61/3 nur dann laufen lassen, wenn jemand zu Hause ist.
Anwesenheitserkennung habe ich laufen, jetzt ist nur die Frage - über welchen Befehl setze ich die Zirkulationspumpe auf "on"?
ebusctl r -f CirPump --> damit lese ich den Status aus.
Hat jemand einen Tipp?
Danke!
Zitat von: Peter1984 am 24 September 2018, 22:20:38
Jetzt würde ich gerne die Zirkulationspumpe meiner Vaillant VWL 61/3 nur dann laufen lassen, wenn jemand zu Hause ist.
Anwesenheitserkennung habe ich laufen, jetzt ist nur die Frage - über welchen Befehl setze ich die Zirkulationspumpe auf "on"?
ebusctl r -f CirPump --> damit lese ich den Status aus.
einfach mal schauen, welche Nachrichten so definiert sind, bspw. mit "ebusctl f -a cir" oder "ebusctl f -a pump" oder "ebusctl f -a|grep -i cir"
cc CirPumpED = no data stored
cc CirPumpED = no data stored
ehp CirPump = no data stored
ehp CirPump = off
mc CoolingCircuitStatesHc2 = no data stored
mc Hc1PumpSpeedControlDirectCircuit = no data stored
mc Hc1PumpSpeedControlDirectCircuitWhileO = no data stored
Das ist das Ergebnis. Wie steuere ich jetzt den Pumpe an? Ich bräuchte bitte den Befehl für das Terminal, da ich nicht mit FHEM arbeite und in IP-Symcon einen Terminal-Befehl absetze.
Also so ganz simpel mit "jetzt sagt mir doch bitte endlich jemand den Befehl" wirst du hier wohl nicht weiter kommen...
Die Nachricht "CirPump" ist in der 08.ehp.csv nur als Read und Update definiert. Beim Update werden darüber hinaus 2 Bytes ignoriert - und so wie ich das sehe kann ebusd Update-Nachrichten ohnehin nur lesen, also nicht als Write absetzen.
Du müsstest also entweder am Bus mitlesen, was deine Steuerung (ich gehe blind mal davon aus, dass du eine hast) als Nachricht schickt, um die Pumpe aus-/anzuschalten und dann könntest du diese Hex-Nachricht nachbilden. Alternativ könntest du in der CSV aus "r;u,,CirPump,..." einfach mal "r;u;w,,CirPump,..." machen und es mit "ebusctl w -c ehp CirPump on" versuchen, da mache ich dir aber keine große Hoffnung...
Das alles geht aber wahrscheinlich ohnehin nicht, WENN du eine externe Steuerung am Bus hast - bei mir schickt diese dann regelmäßig den von ihr gewünschten Zustand - dir bleibt also nur, der Steuerung einzuhämmern dass die Zirkulation an oder aus sein soll - wäre also ganz nett, wenn du hier etwas mehr zum Umfeld und den weiteren Komponenten schreiben könntest.
Hut ab Sven
Besser haette man den ersten Absatz nicht schreiben koennen.
Gruss Christoph
Zitat von: Sven77 am 26 September 2018, 07:47:47
Also so ganz simpel mit "jetzt sagt mir doch bitte endlich jemand den Befehl" wirst du hier wohl nicht weiter kommen...
Die Nachricht "CirPump" ist in der 08.ehp.csv nur als Read und Update definiert. Beim Update werden darüber hinaus 2 Bytes ignoriert - und so wie ich das sehe kann ebusd Update-Nachrichten ohnehin nur lesen, also nicht als Write absetzen.
Du müsstest also entweder am Bus mitlesen, was deine Steuerung (ich gehe blind mal davon aus, dass du eine hast) als Nachricht schickt, um die Pumpe aus-/anzuschalten und dann könntest du diese Hex-Nachricht nachbilden. Alternativ könntest du in der CSV aus "r;u,,CirPump,..." einfach mal "r;u;w,,CirPump,..." machen und es mit "ebusctl w -c ehp CirPump on" versuchen, da mache ich dir aber keine große Hoffnung...
Das alles geht aber wahrscheinlich ohnehin nicht, WENN du eine externe Steuerung am Bus hast - bei mir schickt diese dann regelmäßig den von ihr gewünschten Zustand - dir bleibt also nur, der Steuerung einzuhämmern dass die Zirkulation an oder aus sein soll - wäre also ganz nett, wenn du hier etwas mehr zum Umfeld und den weiteren Komponenten schreiben könntest.
Hallo Sven,
ich habe auch nicht erwartet, die Lösung hier auf dem Silbertablett serviert zu bekommen und bin bereit, selbst zu testen. Ich bin halt Anfänger und bei weitem nicht so tief in der Materie drin wie andere und werde wohl auch nie so tief reinkommen.
Ich hatte nur gehofft, dass jemand das schon umgesetzt hat, sofern möglich - man muss ja nicht jedes Mal das Rad neu erfinden. Über die Suche habe ich leider nichts gefunden.
Dann mal zu meiner Umgebung:
- Vaillant VWL 61/3
- esera EBUS-Koppler, der an der Vaillant Anlage und am Raspberry angeschlossen ist
- IP-Symcon auf Raspberry Pi, dort lese ich über die Skripte die Stati der Wärmepumpe aus und kann die Warmwasser-Bereitung starten (per hex-Befehl, hier aus dem Forum)
Die Steuerung ist also nicht extern, sondern in der Vaillant eingebaut. Wie kann ich hier den Bus mitlesen wenn ich die Zirkulationspumpe von "aus" auf "an" stelle?
Wäre super, wenn du mir hier weiterhelfen könntest.
Moin
Ich wuerde mal vermuten, dass das nicht geht! Normalerweise legst Du irgendwo fest, wann die Zirkulationspumpe laufen soll. Das ist eigentlich im Regler hinterlegt! Dieser wird das also froehlich auf den Bus legen, ob an oder aus ist egal.
Jetzt kann ich Dir aber einen Workaround geben, der bei mir laeuft.
Nimm die Pumpe von der Heizung weg, und steuere die ueber einen x-beliebigen Aktor!
Gruss Christoph
Okay, was ich auf die schnelle über die VWL 61/3 gefunden habe, ist dort kein Standard-(Ebus)-Regler verbaut, ob der die Nachrichten dann überhaupt über den Bus schickt, ist fraglich. Poste bitte mal die Ausgabe von 'ebusctl info', am besten einige Minuten nach einem 'ebusctl scan full'.
EDIT: Habe ich hier (https://forum.fhem.de/index.php/topic,46098.msg686474.html#msg686474) gefunden
Interessant wäre noch, mit welchem Hex-Kommando du die WW-Bereitung startest!
Insgesamt müsste man jedenfalls wohl eher Steuerung verklickern, dass die Zirkulation an sein (und bleiben) soll... da wird es schwierig, weil sonst niemand auf dem Bus mit der Steuerung spricht...
Schau doch einfach mal mit 'tail -f /var/log/ebusd.log' in die Logdatei, während du über die Steuerung die Zirkulation an- oder ausschaltest. Dort sollten dann entweder irgendwelche "update" messages auftauchen, oder aber "unknown MS" - auch die wären dann interessant zu erfahren.
Weiter könnte man sozusagen die Konfig der Steuerung (Adresse 15) auslesen, 2-3 Mal ohne eine Änderung um zu erkennen, welche Werte sich selbständig ändern - um dann die Zirkulation umzuschalten und zu suchen, was sich dadurch alles geändert hat.
Dazu ist Johns Script allregisters.sh (https://forum.fhem.de/index.php/topic,29737.msg497570/topicseen.html#msg497570) hilfreich!
PS: Ansonsten wäre natürlich Christophs Lösung einfacher - nimmt dann aber die Kontrolle komplett von Vaillant weg ;-)
PPS: Wenn du mir einen SSH-Zugang von außen öffnen kannst+willst, schreib mir eine PM, dann kann ich mir das nebenbei auch mal ansehen.
Zitat von: Sven77 am 26 September 2018, 15:02:54
Interessant wäre noch, mit welchem Hex-Kommando du die WW-Bereitung startest!
Hi Sven,
die WW-Bereitung startet über ebusctl --port=8889 hex 08b505020601.
Den Port muss ich mitgeben, weil auf dem Standard-Port 8888 ein anderer Dienst läuft.
Ansonsten ist glaube ich Christophs Vorschlag das einfachste, da ich gut an die Zirkulationspumpe ran komme...
Danke!
Zitat von: Peter1984 am 26 September 2018, 15:45:52
Ansonsten ist glaube ich Christophs Vorschlag das einfachste, da ich gut an die Zirkulationspumpe ran komme...
Man kann ja sogar beides kombinieren:
VWL (bzw. Regler) steuert die Zirkulation nach Zeit und ein externer (Umschalt-)Aktor trennt die Zirkulationspumpe ab, wenn niemand zu Hause ist.
Damit könnte man nachts die normale Timerprogrammierung von Vaillant nutzen, ohne tagsüber bzw. bei Abwesenheit unnötig zu zirkulieren.
[Offtopic]
Womit machst du die Anwesenheitserkennung?
Ich habe meine Ideen bisher alle wieder verworfen - Handys werden zu Hause vergessen oder bis zur kompletten Abschaltung entladen, Autoschlüssel werden eh nicht immer mitgenommen - allein (intelligente) Bewegungsmelder wären etwas sicherer, aber die wollte ich bisher nicht installieren oder gar überhaupt kaufen...
[/Offtopic]
Die Anwesenheitserkennung mache ich innerhalb IP-Symcon mit dem FritzBox-Project.
Dort erhalte ich zuverlässig den Online-Status unserer iPhones - die wir immer dabei haben wenn wir das Haus verlassen. :-)
Alle anderen Varianten waren für mich bis lang auch nicht zufriedenstellend, aber so läuft das bis jetzt ganz gut.
Aktuell nutze und logge ich das aber nur mit, ohne eine Funktion hinterlegt zu haben - was sich jetzt ja ändern soll.
Ich werde die Idee mit dem zwischengeschalteten Aktor auch weiterverfolgen, ansonsten über die per PN geschriebenen Förderleistung der Zirkulationspumpe, den ich in der Wärmepumpe setzen kann (0% ist aus, bei Anwesenheit wird der Wert auf > 0% gesetzt). Jetzt muss ich nur noch rausfinden, wie der Wert gesetzt werden kann falls möglich.
Danke euch für die Hilfe!
Das läuft bei mir seit 4 Jahren: Ein externer Aktor kann sowohl (trotz Ansteuerung durch die Heizung) die Pumpe abstellen, etwa, wenn die Rücklauftemperatur im WW-Kreislauf hoch genug ist. Als auch diese anstellen, wenn die Heizung sie nicht anschaltet (etwa, wenn Nachts sofort warmes Wasser gewünscht wird).
Schaltplan und einfacher Zustandsautomat hier: https://wiki.fhem.de/wiki/1W-WPump
Umfangreichere Doku in den SmartHome Hacks.
Sparpotenzial ca. 100 €/Jahr
LG
pah
Hallo zusammen,
mit Hilfe von Sven77 habe ich meine Anforderung mit den vorhandenen Mitteln gelöst.
Der Befehl
ebusctl r CirPumpED liefert mir den in der Wärmepumpe gesetzten Leistungswert der Zirkulationspumpe - bei mir aktuell 15%.
Übergebe ich den Befehl
ebusctl w -c cc CirPumpED 0 wird der Wert auf 0% gesetzt und damit die Zirkulationspumpe ausgeschaltet.
Sven kam über eine Zeile in den Config-Files drauf:
ZitatEs gibt in der 23.ehp.cc.csv folgende Zeile:
r;w,,CirPumpED,CirculationPumpED,,,,"E601",,,UCH,,,defines the percentage of a 10 minutes period to power the pump
Über die Anwesenheitserkennung ist nun realisiert, das die Pumpe ausgeschaltet wird, wenn niemand (kein WLAN-Handy) in der Gegend ist - ansonsten läuft die Pumpe auf 15% Leistung (was bei Vaillant heißt in 10 Minuten 1,5 Minuten Laufzeit).
Danke Sven. Ich denke das hilft einigen anderen auch noch weiter.
Kostenpunkt: 0 € ;D
Zufriedenheit der Ehefrau: 100% da jetzt immer sofort warmes Wasser da ist 8)
Zufriedenheit des Ehemanns: 100% da nur warmes Wasser da ist, wenn die Ehefrau auch da ist :P
Zitat von: Fantom am 17 Februar 2018, 10:40:31
Hi
I'm newbie in topic.
I connect ebus connector 1.6 to Vaillant ecoTec + VRC430F + V61
I installed ebusd (on RPi):
pi@raspberrypi:/usr/bin $ sudo ebusd -f -d /dev/ttyUSB2 --scanconfig
2018-02-15 18:13:27.033 [main notice] ebusd 3.1.v3.1-22-gdaf771e started with auto scan
2018-02-15 18:13:27.054 [bus notice] bus started with own address 31/36
2018-02-15 18:13:27.104 [bus notice] signal acquired
2018-02-15 18:13:37.962 [bus notice] new master 03, master count 2
2018-02-15 18:13:46.982 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2018-02-15 18:13:46.983 [update notice] store 08 ident: done
2018-02-15 18:13:46.984 [update notice] sent scan.08 QQ=31: Vaillant;BAI00;0518;7401
2018-02-15 18:13:46.985 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2018-02-15 18:13:47.014 [main notice] read common config file /etc/ebusd/vaillant/general.csv
2018-02-15 18:13:47.016 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2018-02-15 18:13:47.021 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
2018-02-15 18:13:47.029 [main notice] read scan config file /etc/ebusd/vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2018-02-15 18:13:47.114 [bus error] send to 08: ERR: read timeout, retry
2018-02-15 18:13:47.713 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:47.949 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:48.120 [update notice] sent scan.08 id QQ=31:
2018-02-15 18:13:48.295 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:13:48.383 [main notice] found messages: 200 (0 conditional on 23 conditions, 0 poll, 9 update)
2018-02-15 18:13:48.516 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:13:49.426 [update notice] sent scan.08 id QQ=31: 21;10;40;0010003869;3100;005327;N7
2018-02-15 18:15:47.814 [main notice] update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.1.v3.1-22-gdaf771e
update check: revision v3.1-1-g60a18d1 available, broadcast.csv: different version available, memory.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/general.csv: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 110
min arbitration micros: 780
max arbitration micros: 916
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 3
messages: 201
conditional: 0
poll: 0
update: 9
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010003857.inc" ([PROD='0010003869']), "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
regards
Fantom
Any idea Why I see only one master (vaillant) ?
Why ebusd don't find VRC430F and VR61 ?
How can I try find solution (looking into raw data etc)
Fantom
Zitat von: Fantom am 29 September 2018, 17:54:12
Any idea Why I see only one master (vaillant) ?
Why ebusd don't find VRC430F and VR61 ?
first of all, the scanconfig option takes some time to finish as only those devices are being queried, that are part of a communication seen on the bus. so if you VR61 never receives or sends any message, it won't be scanned at all. you can force the scan of everything by issuing "ebusctl scan full" in a separate terminal while ebusd is running (either in another terminal in foreground or as daemon in background).
afaik the VRC430F imposes additional latency, so you might need to increase the default latency by using --latency=... as additional argument to the start of ebusd.
Zitat von: john30 am 30 September 2018, 10:57:28
first of all, the scanconfig option takes some time to finish as only those devices are being queried, that are part of a communication seen on the bus. so if you VR61 never receives or sends any message, it won't be scanned at all. you can force the scan of everything by issuing "ebusctl scan full" in a separate terminal while ebusd is running (either in another terminal in foreground or as daemon in background).
afaik the VRC430F imposes additional latency, so you might need to increase the default latency by using --latency=... as additional argument to the start of ebusd.
Hi. I installed today board 2.0 (instead 1.6) and ebusd see all masters :)
Thanks
Fantom
ps. I have problem with esp8266 with software 2018 (but i wrote on github).
ps2. I connect board+extension to Rpi 2 (use converter usb->uart) and all time i have reset. Converter or RPI gives too litle power i think. When I take out esp8266 - ebusd work properly (but extension board not used).
Zitat von: piuser1 am 30 September 2018, 17:55:54
Hallo,
habe vor 2 Jahren den ebus-Adapter aufgebaut und die Version "ebusd 2.1.e408c94" auf einem separatem RaspberryPi installiert.
Jetzt sehe ich, dass es die ebusd-Version 3.2 sowie eine neue Platine gibt.
Funktioniert mittlerweile ebusd und fhem auf EINEM Raspi stabil (RPi 3B+) ? oder ist es immer noch erforderlich, fhem auf einem extra Rechner laufen zu lassen ?
Hintergrund ist, dass ich auf "Strech" umsteigen möchte und somit eine Neuinstallation ansteht.
Bei mir läuft schon seit Jahren EBUSD auf dem selben Raspi (2B) wie FHEM. Ich habe für alle meine Devices nur einen Raspi. Muss nur ausreichend USB-Ports haben, nicht alle Devices laufen am Hub...
Grüße
Christian
@cs-online: DANKE für Deine Rückmeldung ! *top* Werde das mal in Angriff nehmen ...
Zitat von: piuser1 am 30 September 2018, 17:55:54
Funktioniert mittlerweile ebusd und fhem auf EINEM Raspi stabil (RPi 3B+) ? oder ist es immer noch erforderlich, fhem auf einem extra Rechner laufen zu lassen ?
Hintergrund ist, dass ich auf "Strech" umsteigen möchte und somit eine Neuinstallation ansteht.
Jupp läuft auf Rpi 3B+ und stretch!
Bei mir seid einigen Monaten.
Mfg Maik
Moin,
bei mir läuft seit einiger Zeit der ebusd super! Danke für eure Hilfe!
Da nun so langsam die Heizperiode einsetzt wollte ich ein paar neue ECMDDevices anlegen um diese in FHEM darzustellen.
Das klappt soweit auch ganz gut nur einige mögen nicht so richtig, denke das liegt an der formatierunge,... blicke da nicht so durch mit dem "expect".
Der Reihe nach: Abfragen möchte ich z1DayTemp was manuell mittels
ebusctl r -f z1DayTemp
18.5
auch funktioniert. In meiner bai00.cfg habe ich nun folgendes:
# Raumsoll
get RaumSoll cmd {"r -f z1DayTemp\n"}
get RaumSoll expect "\d+\.\d+\n\n"
get RaumSoll postproc { sprintf("%5.1f",$_) }
und in der fhem.cfg:
define RaumSoll ECMDDevice bai00.class
attr RaumSoll IODev EBUS
attr RaumSoll group Vaillant
attr RaumSoll icon sani_supply_temp
attr RaumSoll room Heizung
aber es kommen nur ??? dabei heraus.
Denke es ist total simpel aber ich habe da vermutlich eine Wissenslücke... evtl bei "expect"?
Danke!
...hast du evtl. vergessen, die Bai00.cfg mit der Bai00.class zu verknüpfen ?
bei mir sieht das so aus in der fhem.cfg:
define EBUS ECMD telnet 192.168.2.22:8888
attr EBUS classdefs Heizungsfunktionen.class=/opt/fhem/FHEM/ebusd_Heizungsfunktionen.cfg
attr EBUS group eBus
attr EBUS requestSeparator �
attr EBUS room Heizung,Schnittstellen
attr EBUS verbose 0
define Heizungsfunktionen ECMDDevice Heizungsfunktionen.class
attr Heizungsfunktionen IODev EBUS
attr Heizungsfunktionen verbose 0
Ich würde aber auch nicht jeden abzufragenden Wert in eine eigene class bzw. .cfg packen. Ich habe bei mir in den Heizungsfunktionen alle Abfragen drin. D.h. das was ich oben angegeben habe ist alles zu den Heizungswerten. Einmal die Abfragen aktualisiert, dann kannst du mit readingsProxys die einzelnen Werte in einzelnen Devices darstellen...
Zitat von: cs-online am 02 Oktober 2018, 19:03:49
...hast du evtl. vergessen, die Bai00.cfg mit der Bai00.class zu verknüpfen ?
Sollte nicht sein, da die anderen Werte aus der bai00.cfg dargestellt werden.
define EBUS ECMD telnet 192.168.101.3:8888
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Heizung
...
define Vorlauf ECMDDevice bai00.class
attr Vorlauf IODev EBUS
attr Vorlauf group Vaillant
attr Vorlauf icon sani_supply_temp
attr Vorlauf room Heizung
...
define RaumSoll ECMDDevice bai00.class
attr RaumSoll IODev EBUS
attr RaumSoll group Vaillant
attr RaumSoll icon measure_power
attr RaumSoll room Heizung
...
Zitat von: piuser1 am 03 Oktober 2018, 19:33:18
Muss ich für einen TIPP PayPal bemühen ?
Antworten per PN, danke
Moin
Dir ist schon klar, dass gestern Feiertag war, dass in manchen Bundeslaendern Ferien sind, usw. !?
Und anstatt darauf zu pochen, dass es zwei Jahre her ist und hier gefaelligst einer antworten soll, koenntest du ja einfach mal versuchen im thread zu lesen. Gar nicht so weit zurueck steht, was Du wissen moechtest! https://forum.fhem.de/index.php/topic,29737.msg832413.html#msg832413
Und richtig aufgehoben bist Du hier https://github.com/john30/ebusd/wiki , wenn es um den ebusD geht!
Christoph
ZitatMuss ich für einen TIPP PayPal bemühen ?
Nur abgesehen davon, dass dieser User sich möglicherweise die Honorare hier gar nicht leisten kann, ist das eine ziemliche Frechheit. Soll er doch auf kommerzielle Software umsteigen.
LG
pah
Zitat von: piuser1 am 02 Oktober 2018, 19:13:21
wo werden bei der Version 3.2 die csv-Dateien abgelegt ? waren sonst immer unter /etc/default/ebusd zu finden ?
wie hier notiert (https://github.com/john30/ebusd/blob/master/ChangeLog.md#breaking-changes), werden ab ebusd 3.2 ohne Verwendung des Parameters "-c ..." bzw. "--configpath=..." (https://github.com/john30/ebusd/wiki/2.-Run#message-configuration-options) die CSVs direkt vom web service auf ebusd.eu abgeholt, womit die lästige Installation von ebusd-configuration für Normaluser entfällt. Der web service enthält den letzten Stand von ebusd-configuration/ebusd-2.1.x/de (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de), d.h. wenn Du die geladenen CSV files anschauen willst, dann genau dort.
Hallo,
ich habe mich nun einmal daran gemacht mein ebusd von 2.4 auf 3.2 zu updaten. Hardware ist die 1.6. Das Läuft soweit.
Was ich allerdings nicht hin bekomme ist, dass die Configuration auf dem aktuellen Stand ist.
ebusctl info
version: ebusd 3.2.v3.2
update check: revision v3.2-11-g18bd21f available, broadcast.csv: different version available, vaillant/15.430.csv: newer version available, vaillant/bai.0010006101.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 96
min arbitration micros: 1000
max arbitration micros: 1150
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 3
messages: 449
conditional: 16
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0516;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Ich habe den Ordner /etc/ebusd umbenannt und die /etc/default/ebusd mit dem Notwendigsten angepasst. Da Daten gelesen und auch geschrieben werden können gehe ich davon aus, dass die Konfig soweit in Ordnung ist und diese von "http://ebusd.eu/config" stammt und nicht von local gelesen wurde.
# /etc/default/ebusd:
# config file for ebusd service.
EBUSD_OPTS="--scanconfig --configpath=http://ebusd.eu/config/"
Aber warum zeigt der "update check" immer neue Versionen an? Und wie kann ich sehen welche ebusd-configuration ich benutze bzw. wie kann ich sicherstellen, dass die geladene ebusd-configuration die aktuellste ist?
Zitat von: majorshark am 23 Oktober 2018, 07:32:23
Aber warum zeigt der "update check" immer neue Versionen an? Und wie kann ich sehen welche ebusd-configuration ich benutze bzw. wie kann ich sicherstellen, dass die geladene ebusd-configuration die aktuellste ist?
indem Du den webservice benutzt, hast Du automatisch nach jedem Neustart von ebusd bzw. nach Absetzen des reload Kommandos die aktuellste Version.
Dass der Updatecheck immer unterschiedliche Versionen zu finden meint, ist in der Tat etwas skurril. Auf welchem OS bist Du?
Nach dem Neustart von eBusd ist alles ok. Nach etwa zwei Minuten dann der Update Check und es werden neuere Versionen gefunden.
Der eBusd läuft auf einem Rasberry Pi mit Jessie.
Es geht nicht, dass hier verhunzte Versionen meiner Bilder gepostet werden, bei denen mein Name aber in ursprünglicher Form verblieben ist. Bitte unterlassen.
Darüber hinaus ist nirgendwo die Rede von einem "Netzteil".
pah
Guten Tag,
@Prof. Dr. Peter Henning:
Habe den Beitrag gelöscht.
Hallo flmma,
bevor du jetzt nicht mehr weiter weisst, lies dich doch einmal hier ein:
https://forum.fhem.de/index.php/topic,75878.0.html (https://forum.fhem.de/index.php/topic,75878.0.html)
wenn du beim Ende angelangt bist wirst du feststellen dass es sehr bald etwas Neues geben wird...
Viellecht eine Alternative zum Breadboard?
Zitat von: flmma am 24 Oktober 2018, 18:11:55
Guten Tag,
@Prof. Dr. Peter Henning:
Habe den Beitrag gelöscht.
Moin
Das mit dem Netzteil hatte ich Dir auch schon geschrieben, habe es dann wieder durchgestrichen, da es im Wiki ja so steht, dass man es mit einem Netzteil testen kann. Die Antwort der LED bist du mir allerdings zweimal schuldig geblieben. Denn die hattest du in Deinem Ausschnitt nicht mit drauf, genausowenig wie den benoetigten Widerstand beim Test mit Netzteil.
Vielleicht faengst Du einfach noch mal an und erklaerst uns, warum Du nur den einen Teil der Schaltung in Betrieb nehmen moechtest?
@galileo: Von da kam er urspruenglich, aber ich habe Ihn hierher geschickt, da hier dann doch eher die richtige Stelle ist, wenn man kein V2.x hat.
Gruss Christoph
Hallo,
ok versuche meine Frage nochmals neu zu stellen:
Ich habe mir die Bauteile für die EBUS-Schaltung aus dem FHEM Wiki bestellt und wollte nun nur den lesenden Teil der Schaltung nachbauen. (bis dorthin wusste ich noch gar nicht, dass es bereits eine Version 2.1 der Schaltung gibt)
Im Wiki steht neben der Schaltung folgender Kommentar:
Achtung: Der Autor übernimmt keine Haftung für die Anwendung dieser Schaltung. Zur Vermeidung von Schäden durch unsachgemäße Bedienung des Heizungssystems wird ausdrücklich empfohlen, nur die lesende Hälfte des Interfaces nachzubauen und sich auf ein passives Lauschen auf dem EBUS zu beschränken. Dazu einfach den Zweig mit Darlington-Transistor aus der Schaltung nicht einbauen.
[Quelle: https://wiki.fhem.de/wiki/EBUS]
Somit versuchte ich nun den Zweig mit den Darlington-Transistor zu identifizieren und aus der Schaltung herauszunehmen und diese aufzubauen. (hier könnte bereits mein Fehler passiert sein...)
Folgte den Anweisungen der WIKI weiter und gelangte dann zum Punkt "Platine Messpunkte", hierzu habe ich folgende Schaltung, wobei ich den Zweig mit den Darlington-Transistor weggelassen habe, aufgebaut. (siehe Attachment)
(Den weggelassenen Teil habe ich im Bild ausradiert, damit dies auch ersichtlich wird)
Evtl. habe ich zuviel weggelassen?
Wenn ich nun das Breadboard mit dem RS232<->USB Adapter (5V Ausgangsspannung) verbinde, so leuchtet die LED ständig? Ich denke die sollte ja nur leuchten sobald an den EBUS-Klemmen eine Spannung über der Schaltschwelle z.b. 15V anliegt, oder? (High-Signal am EBUS)
Muss leider gestehen, dass meine elektrotechnischen Kenntnisse etwas eingerostet sind... wollte dies Umstand mit diesem Projekt wieder etwas ändern...:)
Danke!
@Prof. Dr. Peter A. Henning:
Habe nun Ihre Kennung herausgenommen, ich denke aus dem Text wird erkenntlich, dass es sich um keine von Ihnen veröffentlichte Schaltung handelt.
Sofern für Sie nicht tragbar, bitte um Bekanntgabe. Werde die Schaltung dann einfach per Hand zeichnen.
Danke!
Noch einmal: Hier wird kein Netzgerät verwendet. Derjenige, der dies als "zu Testzwecken" auf _mein Bild_ geschrieben hat, sollte das ebenfalls korrigieren.
Und ja, hier wurde zuviel "weggelassen". Nämlich der Teil mit der Spannungserzeugung für Stromversorgung der NAND-Gatter. Das kommt davon, wenn man ohne Verständnis in Schaltungen herumeditiert - also bitte auch das obige Bild löschen, es ist irreführend.
LG
pah
Vielen Danke, dass dürfte es gewesen sein, habe den 4011 leider nicht versorgt. (+5V, GND)
Bild habe ich gelöscht, ich glaube die Spannungsversorgung war auf der Wiki aber auch nicht eingezeichnet. (zumindest habe ich diese nicht wissentlich entfernt)
Danke!!!
lg
Michi
Hallo,
bin bereits weiter gekommen und habe nun die EBUS-Schnittstelle an einem ELCO LOGON M - Regler, welcher meinen Klöckner ÖL-Kessel bzw. Elco-Brenner steuert, angehängt.
Bekomme meines Erachtens bereits sinnvolle Daten:
...
2018-10-25 21:47:54.639 [bus notice] <104511130300241191
2018-10-25 21:47:54.994 [bus notice] <10451114030024110a
2018-10-25 21:47:55.323 [bus notice] <10fe080108fa2ae2280042008019 -> Kesseltemp usw.
2018-10-25 21:47:55.677 [bus notice] <104511150300241185
2018-10-25 21:47:56.032 [bus notice] <10451116030024118f
2018-10-25 21:47:56.388 [bus notice] <104511170300241100
2018-10-25 21:47:56.720 [bus notice] <10fe070009b40700452125100418bd ->Außentemp: 7,7°C Datum und Uhrzeit
2018-10-25 21:47:57.075 [bus notice] <104511180300241122
2018-10-25 21:47:57.430 [bus notice] <1045111903002411ad
...
Habe mal einige der Messages entschlüsselt, wisst Ihr ob es eine bereits vorhandenes Konfigurationsfile für diesen Regler gibt, oder muss ich dieses selbst schreiben? (suche nach ELCO oder LOGON M war leider nicht erfolgreich, dürften aber Standardtelegramme verwenden)
Danke!
lg
Michi
Moin
Bekannt ist mir das nicht. Der Satz mit dem nur lesen ist eventuell etwas uebervorsichtig definiert. Wenn Du die gesammte Platine/Schaltung aufbaust, dann kannst Du auch den eBus Daemon mal eine Abfrage (senden) schicken lassen, und man sieht dann auch welche Teilnehmer gefunden werden. Eventuell musst Du Dich dann doch auch im anderen Thread tummeln, oder gar einen Neuen aufmachen! Da Du aber Daten empfaengst, wirst du auf jeden Fall zum Ziel kommen. Irgendwo in diesem Thread ist auch beschrieben wie man sich die CSV selber bauen kann, wenn ich mich recht erinnere.
Gruss und viel Erfolg
Christoph
Hallo,
habe nun die gesamt Platine v1.6 aufgebaut.
Der Befehl ebusd --checkconfig --scanconfig liefert folgenden Output:
ebusd --checkconfig --scanconfig
2018-10-28 12:51:28.159 [main notice] ebusd 3.2.v3.2 performing configuration check...
2018-10-28 12:51:28.597 [main notice] found messages: 11 (0 conditional on 0 conditions, 0 poll, 4 update)
2018-10-28 12:51:28.597 [main notice] ebusd stopped
Im Service-Log fand ich folgende Einträge vor:
2018-10-28 12:28:49.077 [main notice] ebusd 3.2.v3.2 started with auto scan
2018-10-28 12:28:49.421 [bus notice] bus started with own address 31/36
2018-10-28 12:28:49.437 [bus notice] signal acquired
2018-10-28 12:28:49.739 [bus notice] new master 10, master count 2
2018-10-28 12:28:57.941 [update notice] received update-read broadcast datetime QQ=10: 10.742;12:26:00;28.10.2018
2018-10-28 12:28:59.000 [update notice] received unknown BC cmd: 10fe08010818225 a3a00420080
2018-10-28 12:28:59.475 [main error] scan config 15: ERR: read timeout
2018-10-28 12:29:08.912 [update notice] received unknown BC cmd: 10fe08010818225 e3a00420080
Finde ich heraus, woran es liegt, dass der Controller nichts retourniert? (Fehler Schaltung?)
Danke!
lg
Michi
Zitat von: flmma am 28 Oktober 2018, 12:55:16
Der Befehl ebusd --checkconfig --scanconfig liefert folgenden Output:
ebusd --checkconfig --scanconfig
Finde ich heraus, woran es liegt, dass der Controller nichts retourniert? (Fehler Schaltung?)
nur wenn dein Interface schreiben kann, klappt auch das abscannen der Geräte. Anonsten tappst Du mehr oder weniger im Dunkeln, aber Du wolltest ja eh nur mitlesen wenn ich es richtig verstanden habe und für Hardware Kennung 0x45 sind mir bis dato noch keine CSVs bekannt.
Hallo,
lesen kann ich, somit dürfte der schreibende Teil der Schaltung noch einen Fehler beinhalten.
Mein FTDI kann eine Spannung von 3,3V oder 5V ausgeben, welche Spannung soll ich wählen?
Danke!
@John30,
vielen Dank für deine Arbeit am ebus.
Stimmt zuerst wolle ich mich mit dem Auslesen der Daten zufrieden geben, nach den ersten Daten-Häppchen ist nun der Appetit nach mehr gekommen ;)
Konnte bereits die Brennertemp., Brauchwassertemp., Außentemp extrahieren... sofern ich das sauber abgebildet habe, kann ich gerne die Messagekonfiguration für den ELCO-Regler (Logon M) posten.
lg
Michi
Zitat von: flmma am 29 Oktober 2018, 19:11:41
Mein FTDI kann eine Spannung von 3,3V oder 5V ausgeben, welche Spannung soll ich wählen?
siehe hier: https://ebus.github.io/adapter/images/base-circuit-v21.png
also 3,3V
Zitat von: flmma am 29 Oktober 2018, 19:11:41
Konnte bereits die Brennertemp., Brauchwassertemp., Außentemp extrahieren... sofern ich das sauber abgebildet habe, kann ich gerne die Messagekonfiguration für den ELCO-Regler (Logon M) posten.
Grundsätzlich versuche ich, sämtliche configs hier zu sammeln: https://github.com/john30/ebusd-configuration
Zitat von: john30 am 30 Oktober 2018, 07:15:13
siehe hier: https://ebus.github.io/adapter/images/base-circuit-v21.png (https://ebus.github.io/adapter/images/base-circuit-v21.png)
also 3,3V
Sorry, ich glaube, das wäre bei ihm jetzt aber doch falsch.
Er benutzt doch die Originalschaltung lt. pah, die entspricht z.B. der Platinenversion v.1.6 (bzw. kleiner), da müßen es wegen der Spannungsversorgung und der Pegel des CMOS 4011 dann doch 5V aus dem FTDI (https://forum.fhem.de/index.php/topic,45127.msg370647.html#msg370647) sein?!
@flmma
In dem o.g. verlinkten Beiträgen (https://forum.fhem.de/index.php/topic,45127.msg378159.html#msg378159) sind auch weitere allg. Beschreibungen und Hinweise zur Schaltung und zur Platinenversion v.1.6 (z.B. unbelegter Eingänge des CMOS 4011 mit VDD brücken), Inbetriebnahme usw.
Stimmt auffallend - die Spannungsversorgung der Gatter auf der FTDI-Seite erfolgt mit 5V aus dem Adapter.
Ich gebe ja zu, dass ich die Weiterentwicklung der Schaltung nicht verfolgt habe. Aber wenn ich jetzt einen Blick auf die offenbar aktuelle Schaltung werfe, fällt mir auf, dass die Spannungsversorgung der Komparatoren auf der EBUS-Seite nicht aus dem EBUS gewonnen wird. Ist das tatsächlich so gemeint ?
Wenn ja, hebelt das natürlich die galvanische Trennung beider Seiten etwas aus. Ich fand an meinem alten Entwurf genau dieses wichtig, um im Fehlerfall auch gegenüber dem Hersteller der Heizung argumentieren zu können.
LG
pah
Zitat von: sua am 31 Oktober 2018, 03:36:04
Sorry, ich glaube, das wäre bei ihm jetzt aber doch falsch.
Er benutzt doch die Originalschaltung lt. pah, die entspricht z.B. der Platinenversion v.1.6 (bzw. kleiner), da müßen es wegen der Spannungsversorgung und der Pegel des CMOS 4011 dann doch 5V aus dem FTDI (https://forum.fhem.de/index.php/topic,45127.msg370647.html#msg370647) sein?!
ah okay, hatte ich nicht auf dem Schirm
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 06:05:10
Ich gebe ja zu, dass ich die Weiterentwicklung der Schaltung nicht verfolgt habe. Aber wenn ich jetzt einen Blick auf die offenbar aktuelle Schaltung werfe, fällt mir auf, dass die Spannungsversorgung der Komparatoren auf der EBUS-Seite nicht aus dem EBUS gewonnen wird. Ist das tatsächlich so gemeint ?
Wenn ja, hebelt das natürlich die galvanische Trennung beider Seiten etwas aus. Ich fand an meinem alten Entwurf genau dieses wichtig, um im Fehlerfall auch gegenüber dem Hersteller der Heizung argumentieren zu können.
nein, es gibt natürlich immer noch die galvanische Trennung, alles andere wäre Quatsch. Dazu verwenden wir entweder einen DC-DC Wandler oder eben doch direkt die Spannungsversorgung via eBUS (was allerdings zu viel Strom frisst - zumindest laut Spez.).
Hmmm.
Der DC-DC Wandler ist aber keine galvanische Trennung, egal, was dessen Hersteller sagt.
Jedes Gerät darf laut Spezifikation bis zu 18 mA aus dem Bus ziehen (es sei denn, beim Schreibvorgang. Da muss natürlich der Bus soweit runter gezogen werden, dass er zwischen 9 und 12 V liegt).
In meiner ursprünglichen Schaltung ist das gewährleistet, es wird ja nur der Optokoppler und der Darlingtontransistor angesteuert. Darum hatte ich auch einen L05-Regler vorgesehen.
Es wundert mich, dass diese einfachen Komparatoren mehr Saft brauchen sollen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 09:06:18
Der DC-DC Wandler ist aber keine galvanische Trennung, egal, was dessen Hersteller sagt.
"1kVDC Isolation" reichen Deiner Meinung nach nicht?
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 09:06:18
Jedes Gerät darf laut Spezifikation bis zu 18 mA aus dem Bus ziehen (es sei denn, beim Schreibvorgang. Da muss natürlich der Bus soweit runter gezogen werden, dass er zwischen 9 und 12 V liegt).
wir haben das mit Oszi angeschaut und festgestellt, dass es eben nicht innerhalb der Spez. ist.
Hmmm.
Wenn der Blitz einschlägt, sind 1 kV schnell erreicht. Optokoppler bieten typisch 5 kV. Wenn ich nach DC-DC-Wandlern suche, finde ich Modelle mit gesichertem Schutz nicht unter 20 €.
Bezüglich des Stromes würde mich interessieren, wo der hingehen soll. Der Optokoppler schluckt auf der LED_Seite nicht mehr als 10 mA, der 78L05 verbraucht für sich selbst ca. 1 mA, der Strom zur Ansteuerung des Darlington ist vernachlässigbar.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 15:26:59
Wenn der Blitz einschlägt, sind 1 kV schnell erreicht. Optokoppler bieten typisch 5 kV. Wenn ich nach DC-DC-Wandlern suche, finde ich Modelle mit gesichertem Schutz nicht unter 20 €.
also wenn der Blitz einschlägt, ist die Schaltung eh hinüber und diese kann m.E. die eBUS Seite für diesen use-case eh nicht absichern.
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 15:26:59
Bezüglich des Stromes würde mich interessieren, wo der hingehen soll. Der Optokoppler schluckt auf der LED_Seite nicht mehr als 10 mA, der 78L05 verbraucht für sich selbst ca. 1 mA, der Strom zur Ansteuerung des Darlington ist vernachlässigbar.
das Problem ist nicht die gesamte Stromaufnahme sondern das Delta I (zwischen L und H Pegel), welches selbst bei minimaler Teilnehmerzahl lt. Spec_Proto_12_V1_3_1 Kapitel 10.7 auf jeden Fall unter 5mA liegen muss, was bei 10mA bereits nicht mehr der Fall ist (Differenz LED on versus off).
Zitat von: Prof. Dr. Peter Henning am 31 Oktober 2018, 15:26:59
Optokoppler bieten typisch 5 kV.
Nun ja, aber der Rest der Signalführung auf der Lochrasterplatte (bzw. Leiterplatte) dann wohl doch nicht...
;-)
Selbst wenn, dürfte die Wahrscheinlichkeit eines Blitzeinschlags, der zwar über 1kV, aber unter 5kV liegt....... recht gering sein. ;D
ZitatSelbst wenn, dürfte die Wahrscheinlichkeit eines Blitzeinschlags, der zwar über 1kV, aber unter 5kV liegt....... recht gering sein.
Das Experiment spricht andere Worte, und das Grinsemännchen ist daher unangebracht. Ich hatte in diesem Jahr nach einem Gewitter den Ausfall diverser Sensoren und Aktoren zu beklagen, die auf einem außenliegenden 1-Wire Bus zu Gange waren, sowie eines ebenfalls außenliegenden Schaltnetzteils (das in etwa dieselbe Spannungsfestigkeit haben sollte, wie ein DC-DC Wandler). Der per Optokoppler angekoppelte Rechner dahinter hat aber überlebt. Sonnenklar, dass es sich nicht um einen direkten Einschalg handelte. Aber die induktiv eingekoppelte Spannung reichte aus.
Zitatdas Problem ist nicht die gesamte Stromaufnahme sondern das Delta I (zwischen L und H Pegel), welches selbst bei minimaler Teilnehmerzahl lt. Spec_Proto_12_V1_3_1 Kapitel 10.7 auf jeden Fall unter 5mA liegen muss, was bei 10mA bereits nicht mehr der Fall ist (Differenz LED on versus off).
Das ist ein Argument, das ich nicht auf dem Radar hatte. Allerdings würde mich dann interessieren, ob die real existierenden Hersteller sich daran halten.
LG
pah
Hi Zusammen,
ich habe mir in der letzten Wochen auch ein Ebuskoppler von Esera (Ethernet) geholt.
Ich habe den Koppler mittlerweile weitestgehend am Laufen.
Zu meiner Hardware:
VRS620/3 Steuerung
VPM 20 Frischwasserstation
EcoTec Heizgerät
VPS800/3-7 Speicher
VR60 (für 2ten Mischerkreis aktuell noch nicht in Betrieb)
Ich habe an der VRS620 einen Mischerkreis angeschlossen.
Ich kann die VRS620 sowie die Trinkwasserstation auslesen und schreiben.
Jedoch habe ich Probleme beim Erkennen der Mischer CSV und der Zirkulationspumpen csv. Soweit ich hier gelesen habe müsste die Addresse 50 für den Mischer vom Ebus erkannt werden. Für die Zirkulationspumpe der trinkwassserstation die Addresse 23
Erkannt werden jedoch die Addresse "12" und "fc" hier gibt es jedoch keine passenden CSV Dateien.
Ich habe jetzt auch nach Tagen Recherche hierzu leider nichts gefunden und wäre über jede Info dankbar.
MfG Matthias
pi@raspberrypi ~ $ ebusctl i
version: ebusd 3.2.v3.2
update check: revision v3.2-12-g45b9bad available, broadcast.csv: different version available, vaillant/0a.pmw.hwc.csv: different version available, vaillant/15.ui.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available
signal: acquired
symbol rate: 23
max symbol rate: 111
min arbitration micros: 158
max arbitration micros: 7340
min symbol latency: 0
max symbol latency: 21
reconnects: 0
masters: 3
messages: 304
conditional: 15
poll: 1
update: 8
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
Hi Matze1986,
also die VPM20W habe ich auch, bei mir ist sie auch auf den Adressen 0a, 12 und fc - aber ich frage nur 0a mit der bei dir ebenfalls geladenen CSV ab. Soweit ich die Vaillant Geräte kenne, antworten sie ohnehin auf allen Adressen gleich.
Die Zirkulationspumpe solltest du mit "ebusctl r -c hwc CircoPump" abfragen können: 100=an, 0=aus.
Zum Mischerkreis: kannst du denn den ersten soweit auslesen? Ich habe keine VRS620 und die CSV scheint recht mager. Vielleicht müsstest du dann doch mal von Hand suchen (Stichwort: readallvaillantregisters.sh (https://github.com/john30/ebusd/blob/master/contrib/scripts/readallvaillantregisters.sh))...
Den VR60 wirst du auf dem Bus wohl erst nach Anschluss finden - er sollte sich dann mit einer Adresse 50-55 oder 26(? =VR71) melden.
Hi Sven,
danke für die Info. Die Zirkulationspumpe habe ich hinbekommen.
Die VR60 ist klar, das ich die jetzt noch nicht sehe, hängt ja nicht am Bus aktuell.
Die VRS620/3 kann nur einen Mischerkreis. Diesen kann ich aber bereits nicht auslesen (in der VRS620 wird er korrekt angezeigt). Da beide Heizkreise bei mir über Mischer laufen sollen, ist die VR60 vorgesehen (aktuell ist nur der erste Heizkreis in Betrieb).
Gibt es denn eine Möglichkeit die erkannten Addressen manuell zu ändern, oder das laden der csv Dateien zu forcieren?
MfG Matthias
Ich würde mal mit einem 'ebusctl scan full' starten und dann nach 2-3 Minuten nochmal die Info ausgeben.
Ich denke aber ehrlich gesagt nicht, dass sich die Steuerung dann nochmal auf einer anderen Adresse meldet...
Und wie gesagt, selbst wenn, wird sie da keine anderen Informationen preisgeben als auf Adresse 15.
Hat denn jemand anderes hier vielleicht eine VRS620 und kann mit Erfahrungswerten aushelfen?
Sonst müsstest du mal schauen, ob bei den Werten schon irgendetwas brauchbares dabei ist - einfach mal ein 'ebusctl find | less' starten und im Kreis "ui" suchen. Da sollte es doch schon Werte zum "Hc" geben?!
Wenn dort überall nur "no data stored" kommt, habe ich mal einen Befehl zusammengefrickelt, der alle Werte einmalig ausliest. Einfach mal anstarten, dabei werden die Werte zusammenhangslos ausgegeben, aber danach sollte 'ebusctl find' mehr Inhalte liefern:
ebusctl find | grep -vE "^(broadcast|memory|scan[. ])" | cut -sd "=" -f 1 | sed "s/^/ebusctl read -c /" >/tmp/$$TMPFILE ; . /tmp/$$TMPFILE ; rm /tmp/$$TMPFILE
Noch einmal zum Thema delta-I: Man könnte auf der EBUS-Seite einfach einen zusätzlichen Transistor und eine LED vorsehen - die eingeschaltet wird, während die LED im Optokoppler aus ist. Damit wäre der gezogene Strom immer gleich, man hätte den Bus-Traffic in der Anzeige und würde dies auf der anderen Seite einsparen können. Und hätte damit die Spezifikation komplett erfüllt.
LG
pah
Hi Sven, danke für den Befehl.
ich habe es mal durchlaufen lassen, jedoch habe ich keine Werte zum Mischerkreis gefunden (Solltemp, Iistemp, Heizkurve etc.)
Ich habe folgende Positings hier im Thread gefunden zur VRS620. Wie gesagt wird sie zusätzlich als 25 und 50 erkannt. Bei mir jedoch nicht.
Kann es vielleicht daran liegen, das ich die neuste VRS620/3 habe, und hier die Addressen anders sind als bei den Vorgängermodellen?
MfG Matthias
Zitat von: Prof. Dr. Peter Henning am 03 Januar 2015, 20:48:57
Roland Jax hat jetzt noch ein paar Daten geschickt, diese sind aber noch nicht verifiziert. Hinzu kommt, dass für die vrs620 nicht nur unter der Adresse 15 Register existieren, sondern dass auch unter den Adressen 23 (Zirkulation) 25 (Hot Water Circuit HWC), 26 (Heating Circuit HC), 50 (Mixer Circuit) und EC (Solarkreis) eigene Register existieren (siehe meine Decodierung des Partymodus gestern...).
Bleibt also spannend...
LG
pah
Zitat von: realkeule am 19 November 2017, 12:09:54
trotz update auf die neuste version habe ich folgende ausgabe
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.0.595c7c0
update check: revision v3.0 available, broadcast.csv: newer version available, vaillant/08.ehp.csv: newer version available, vaillant/15.uih.csv: newer version available, vaillant/23.ehp.cc.csv: newer version available, vaillant/25.ehp.hwc.csv: newer version available, vaillant/50.ehp.mc.csv: newer version available, vaillant/broadcast.csv: different version
signal: acquired
symbol rate: 23
max symbol rate: 138
reconnects: 0
masters: 3
messages: 638
conditional: 285
poll: 2
update: 56
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/08.ehp.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UIH00;SW=0374;HW=6901", loaded "vaillant/15.uih.csv"
address 23: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/23.ehp.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/25.ehp.hwc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0419;HW=7201", loaded "vaillant/50.ehp.mc.csv"
pi@raspberrypi:~ $ ebusd --checkconfig
2017-11-19 12:04:37.102 [main notice] ebusd 3.0.595c7c0 performing configuration check...
/etc/ebusd/vaillant/15.heb.csv:6: ERR: duplicate entry, duplicate ID
2017-11-19 12:04:37.792 [main error] error reading config files: ERR: duplicate entry, last error: /etc/ebusd/vaillant/15.heb.csv:6: ERR: duplicate entry, duplicate ID
2017-11-19 12:04:37.975 [main notice] found messages: 484 (20 conditional on 12 conditions, 0 poll, 4 update)
2017-11-19 12:04:37.996 [main notice] ebusd stopped
pi@raspberrypi:~ $ ebusctl find -d
broadcast datetime = 7.312;12:04:02;19.11.2017
broadcast hwcStatus = off;23;off
broadcast outsidetemp = 7.312
broadcast vdatetime = 12:04:02;19.11.2017
cc Mode = 30;auto;00;off
cc Status = 0;off;-;0
ehp ActualEnvironmentPower = 0
ehp ActualEnvironmentPowerFine = 56
ehp ActualEnvironmentPowerPercentage = 0
ehp errorhistory = 9;2;20:31;17.11.2017;580
ehp FlowTemp = 23.94;ok
ehp HeatpumpType = brinetowater
ehp Mode = (ERR: invalid position for 1008b51009000232000000000002 / 00)
ehp OutsideTemp = 7.31;ok
ehp SourcePumpStatus = 0
ehp SourceTempInput = 17.12;ok
ehp Status02 = disabled;0;100.0;0;100.0
ehp Status = 23.88;1.592;1.123;03 08 00 00
hwc Mode = 44;auto;00;off
hwc Status = 80;off;49.12;44
mc CfgHeatSinkType = mixer
mc DateTime = ok;12:03:47;19.11.2017;7.312
mc Mode = 21;auto;00;off
mc Status = 25;off;23.94;21
scan.08 = Vaillant;EHP00;0419;7201
scan.08 id = ??;??;??;??????????;????;??????;??
scan.15 = Vaillant;UIH00;0374;6901
scan.15 id = 21;13;48;0020101780;0907;011188;N4
scan.23 = Vaillant;EHP00;0419;7201
scan.23 id = ??;??;??;??????????;????;??????;??
scan.25 = Vaillant;EHP00;0419;7201
scan.25 id = ??;??;??;??????????;????;??????;??
scan.50 = Vaillant;EHP00;0419;7201
scan.50 id = ??;??;??;??????????;????;??????;??
hier das update
pi@raspberrypi:~ $ sudo service ebusd stop
pi@raspberrypi:~ $ dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
dpkg: Fehler: Angeforderte Operation benötigt Superuser-Rechte
pi@raspberrypi:~ $ sudo dpkg -i --force-overwrite ebusd-configuration-2.1.*.deb
(Lese Datenbank ... 116031 Dateien und Verzeichnisse sind derzeit installiert.)
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) ...
ebusd-configuration (2.1.b143f39-de) wird eingerichtet ...
pi@raspberrypi:~ $ sudo service ebusd start
Moment.....
Tatsächlich schreibt pah vom Auftreten der VRS620 unter verschiedenen Adressen - hast du denn mal seine Konfiguration (https://forum.fhem.de/index.php/topic,29737.msg239220.html#msg239220) benutzt?
(wobei die CSV tatsächlich voraussetzt, dass es Geräte mit den Adressen 26 oder 50 gibt)
Die Ausgabe von realkeule hingegen zeigt dessen Brenner "MF=Vaillant;ID=EHP00;SW=0419;HW=7201" auf weiteren Adressen - und da fällt mir auch erst auf, dass man deine ecoTec gar nicht sieht!! Eigentlich sollte es noch ein Gerät auf Adresse 08 geben... Ist da vielleicht irgendwo ein Buskoppler verbaut, oder die VRS anderweitig am ecoTec angeschlossen? Oder hat das "scan full" weitere Adressen aufgespürt?
Meine Vermutung ist jetzt, dass auch bei dir eher der Mischerkreis am ecoTec angeschlossen ist...
Also bitte mal eine Aktuelle "info" nach "scan full" schicken - und was auch interessant wäre: welchen Brenner genau hast du und wie ist was angeschlossen/verdrahtet?
Die config habe ich nicht probiert. Aber in dieser sind auch keine Infos zum Mischerkreis enthalten. (Wie du sagst wird von der Adresse 50 ausgegangen, die er bei mir ja nicht findet)
Stimmt die EcoTec fehlt auch.
Ich habe die EcoTec plus VC266/5-5. Diese ist ja mit der VRS620 ziemlich "dumm" und gibt nur den Druck und die aktuelle Kesseltemperatur aus. Die Logik wird ja von der VRS 620 durchgeführt.
Einen separaten Buskoppler habe ich nicht.
Die Heizung, Trinkwasserstation und mein Buskoppler-Ethernet liegen alle an den Klemmen der VRS620/3
Der Mischerkreis ist direkt an der VRS620 angeschlossen!
Die Ecotec ist von exxtern nur mit Spannung und Ebus angeklemmt.
Kanne es sein, dass das Poti am Koppler vielleicht nicht richtig eingestellt ist, und nur einige Geräte erkennt?
full scan schreibt als sofortige antwort "done"
info liefert keine neuen Adressen.
pi@raspberrypi ~ $ ebusctl info
version: ebusd 3.2.v3.2
update check: revision v3.2-12-g45b9bad available, broadcast.csv: different version available, vaillant/0a.pmw.hwc.csv: different version available, vaillant/15.ui.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available
signal: acquired
symbol rate: 27
max symbol rate: 125
min arbitration micros: 158
max arbitration micros: 7297
min symbol latency: 0
max symbol latency: 67
reconnects: 6
masters: 3
messages: 304
conditional: 15
poll: 1
update: 8
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
ZitatKanne es sein, dass das Poti am Koppler vielleicht nicht richtig eingestellt ist, und nur einige Geräte erkennt?
Nein.
Edit: Wer lesen kann ist klar im Vorteil, sage ich mir selbst. Natürlich kann es sein, dass wegen einer _falschen_ Einstellung nicht alle Geräte erkannt werden. I stand corrected.
LG
pah
@matze1986
Um der Sache auf den Grund zu gehen, solltest du den Stromüberschuss am eBus einmal messen. Dieser bestimmt im wesentlichen die Flankensteilheit der Low und High Signale und sollte mindestens 30mA betragen. Wie man das misst ist ganz einfach in der Spezifikation (http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_12_v1_3_1.pdf) erklärt. Dort steht auch, das du mindestens 30mA haben solltest, sonst werden die Flanken verschliffen und die Detektierung und folgend die Arbitrierung der Platine versagt. Es geht vor allem um die Synchronisierung nach dem SYN und da haben wir schon viele Fehler beobachten können wenn hier Zeit Verschiebungen auftreten.
Zu hoch darf er aber auch nicht (>100mA) sein, das wird aber nicht der Fall sein. Wie du siehst, kann man nicht beliebig viele Geräte am Bus hängen und mit jedem zusätzlichen Gerät verändert sich der Stromüberschuß. Das kann dann soweit führen, dass man eine zusätzliche Busversorgung installieren muss, das muss aber vorher ausgemessen werden, denn Zuviel ist noch schlechter.
Wenn es dir möglich ist ein Gerät vom Bus zu entfernen und der Scan funktioniert dann, kann man auch Rückschlüsse ziehen wenn dir die Messung aus irgend einem Grund nicht möglich ist.
Wir haben uns in dieser Richtung schon intensiv auseinander setzen müssen, da die Flankensteilheit noch von anderen Faktoren abhängig ist.
Das sollte jetzt keine eierlegende Wollmichsau sein, sondern nur eine Gedankenanregung in welche Richtung man bei solchen Fehlern auch denken sollte.
Beispiel einer Stromüberflussmessung an meiner Vaillant ecoTec plus 246 mit angeschlossener Calormatic 430 und der Platine V2.1 = 41mA. Also schön im Rahmen. Somit ist ein sauberes und steiles Low und High möglich, das bestätigt auch das Oszilloskop.
LG
Reinhart
Hallo Reinhart, du schreibt genau in dem Moment, indem ich deine Nachrichten auf Seite 139 in diesem Thread gefunden habe. ;D
Ich habe eben die Verdrahtung des eBus nochmal überprüft, dabei festgestellt, das der Installateur ein Kabel nicht weitgenug abgesetzt hatte, und es über die Isolierung am TerminalBlock noch vorhanden war. Durch das Festschrauben wurde diese zwar zerquetscht und es hat ein Kontakt stattgefunden, jedoch hat sich nach Erneuerung der Verindung, die Blinkfrequenz meines Kopplers(Ethernet) der Data-LED stark geändert. (Komisch ist, das die Anlage an sich ja lief?)
Ich hatte vor der Maßnahme ein Flimmern in der LED und zwischendruch starkes blinken. Ich habe das Poti so eingestellt, dass das Flimmern nicht da war, sondern nur das starke Flimmern.
Jetzt gibt es kein Flimmern mehr wenn ich am Poti drehe, nur konstant an, oder aus, oder dazwischen starkes blinken.
und plötzlich bekomme ich bei ebusctl i mehr Addressen ;).
...
messages: 501
...
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0508;HW=6201", loaded "vaillant/15.ui.csv"
address 26: slave
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address ec: slave
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
Jedoch erhalte ich im Log auch folgende Einträge, welche mich auf deine Infos auf Seite 139 gebracht haben .
2018-11-01 20:50:19.465 [bus error] send to 08: ERR: arbitration lost, retry
2018-11-01 20:50:22.196 [bus error] send to 08: ERR: arbitration lost, retry
2018-11-01 20:50:24.930 [bus error] send to 08: ERR: arbitration lost, retry
2018-11-01 20:50:27.391 [bus error] poll ui YieldThisYear failed: ERR: arbitration lost
2018-11-01 20:50:30.429 [main error] scan config 26: ERR: ACK error
2018-11-01 20:50:35.671 [main error] scan config 50: ERR: arbitration lost
2018-11-01 20:50:37.000 [bus error] poll ui YieldThisYear failed: ERR: arbitration lost
2018-11-01 20:50:38.414 [main error] scan config ec: ERR: ACK error
2018-11-01 20:50:50.682 [main error] scan config 26: ERR: ACK error
2018-11-01 20:50:56.484 [main error] scan config 50: ERR: ACK error
2018-11-01 20:50:59.150 [main error] scan config ec: ERR: ACK error
2018-11-01 20:51:08.427 [bus error] poll ui YieldThisYear failed: ERR: arbitration lost
2018-11-01 20:51:12.909 [main error] scan config 26: ERR: ACK error
2018-11-01 20:51:15.390 [main error] scan config 50: ERR: ACK error
2018-11-01 20:51:20.420 [bus error] send to 15: ERR: arbitration lost, retry
2018-11-01 20:51:25.774 [main error] scan config ec: ERR: ACK error
2018-11-01 20:51:33.020 [bus error] send to 15: ERR: arbitration lost, retry
2018-11-01 20:51:41.011 [main error] scan config 26: ERR: arbitration lost
2018-11-01 20:51:47.130 [main error] scan config 50: ERR: ACK errorDein Beitrag ist vermutlich genau der Punkt, an dem ich ansetzen muss. Danke !!
Zitat von: Reinhart am 26 August 2016, 12:30:17
...
man sieht hier aber schön, das beim scan auf 08 (beim Schreibversuch um das Scan Kommando abzusetzen) ein ACK error kommt. Die Broadcast von der selben Platine kommen aber gleichzeitig schön herein, die müssen ja nicht extra angestoßen werden. Entweder verhalten sich die Pegel der Hauptplatine anders oder es ist wirklich ein kleiner Fehler bei der Abstimmung.
Ich werde aber trotzdem noch einen neuen eBus Konverter testen um alle Hardwarefehler auszuschließen.
LG
ZitatKanne es sein, dass das Poti am Koppler vielleicht nicht richtig eingestellt ist, und nur einige Geräte erkennt?
Zitat von: Prof. Dr. Peter Henning am 01 November 2018, 18:15:29
Nein.
LG
pah
Das NEIN ist schlicht und einfach falsch.
Verschiedene Teilnehmer am Bus haben verschiedene LOW Pegel (die aber alle innerhalb der Spec liegen) und zusätzlich (wegen der Delta-I Problematik) auch noch verschieden steil ansteigende Flanken in Richtung HIGH Pegel.
Wenn daher das Poti an einer Stelle steht, die nicht gerade alle Varianten gleichzeitig abdeckt, dann wird die Schaltung auch nicht alle Teilnehmer gleichzeitig erkennen.
Die Antwort muss daher JA lauten.
Warten wir es ab, das lässt sich leicht überprüfen. So lange nicht der Gegenbeweis erbracht wird, bleibe ich beim Nein.
LG
pah
Zitat von: matze1986 am 01 November 2018, 16:41:22
full scan schreibt als sofortige antwort "done"
Ja, das ist richtig - weil nur die Anforderung quittiert wird. Der Scan selbst läuft im Hintergrund und kann mit "scan result" überprüft werden, daher die Anregung einfach ein paar Minuten zu warten.
Aber letztlich lag es ja an der Verkabelung, schön dass das gefunden ist!
Zum Beheben der Arbitrierungsfehler, die bei so vielen Geräten offenbar wirklich "normal" sein können, habe hier hier (https://forum.fhem.de/index.php/topic,92230.msg848693.html#msg848693) etwas geschrieben. Die Werte sollten jedoch moderat vom default angehoben werden, da ebusctl bei mir bei zu hohen Werten irgendwann ganz blockiert - aber auch da bleibe ich am Ball. :-)
PS: Aktuell läuft meine Instanz mit "
--receivetimeout=100000 --acquiretimeout=12000 --acquireretries=5 --sendretries=2"...
Zitat von: Sven77 am 01 November 2018, 08:37:44
Wenn dort überall nur "no data stored" kommt, habe ich mal einen Befehl zusammengefrickelt, der alle Werte einmalig ausliest. Einfach mal anstarten, dabei werden die Werte zusammenhangslos ausgegeben, aber danach sollte 'ebusctl find' mehr Inhalte liefern:
ebusctl find | grep -vE "^(broadcast|memory|scan[. ])" | cut -sd "=" -f 1 | sed "s/^/ebusctl read -c /" >/tmp/$$TMPFILE ; . /tmp/$$TMPFILE ; rm /tmp/$$TMPFILE
genau dafür gibts readall.sh (https://github.com/john30/ebusd/blob/master/contrib/scripts/readall.sh), das als Parameter die "find" Argumente akzeptiert und zusätzlich
-p PORT für nicht-8888 Port, sowie
-R "readargs" für Argumente, die an jedes "read" zusätzlich gegeben werden sollen.
Somit kann man bspw. mit
./contrib/scripts/readall.sh -c uih in einem augecheckten lokalen ebusd repo alle Werte der Circuit "uih" auslesen lassen.
Voraussetzung für das Skript ist ein installiertes "netcat" (aka "nc") sowie dass ebusd auf dem localen Host läuft.
Zitat von: Prof. Dr. Peter Henning am 01 November 2018, 18:15:29
Nein.
doch! ich hatte das mit der alten Schaltung regelmäßig, weil eines der Geräte ganz am anderen Ende einer ca. 15m langen Leitung hängt. Das ließ sich reproduzierbar mit der Poti-Schaltung nie vernünftig auslesen, alle anderen Geräte, die näher dran waren jedoch schon.
Zitat von: matze1986 am 01 November 2018, 21:11:02
Ich habe eben die Verdrahtung des eBus nochmal überprüft, dabei festgestellt, das der Installateur ein Kabel nicht weitgenug abgesetzt hatte, und es über die Isolierung am TerminalBlock noch vorhanden war. Durch das Festschrauben wurde diese zwar zerquetscht und es hat ein Kontakt stattgefunden, jedoch hat sich nach Erneuerung der Verindung, die Blinkfrequenz meines Kopplers(Ethernet) der Data-LED stark geändert. (Komisch ist, das die Anlage an sich ja lief?)
Du darfst die Klemmverbindung nicht nur rein vom Widerstand betrachten, sondern eine schlechte Klemmstelle verändert da vor allem auch Kapazitiv sehr viel und gerade das verzerrt dann die Flanken selbst wenn das Poti stimmen würde.
Hauptsache du hast den Fehler gefundenes und es funktioniert jetzt!
LG
Zitatdoch! ich hatte das mit der alten Schaltung regelmäßig, weil eines der Geräte ganz am anderen Ende einer ca. 15m langen Leitung hängt
.
Hmmm. Das Argument verstehe ich nicht - denn das würde bedeuten, dass das Signal dieses "entfernten" Gerätes eben nicht mehr innerhalb der Spezifikation gelegen hat.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 02 November 2018, 18:35:35
.
Hmmm. Das Argument verstehe ich nicht - denn das würde bedeuten, dass das Signal dieses "entfernten" Gerätes eben nicht mehr innerhalb der Spezifikation gelegen hat.
LG
pah
Also damit es durch ein Beispiel verständlicher wird:
ebus Spezifikation: HIGH = 15V bis 24V, LOW = 9V bis 12V.
Angenommen, der Sender A sendet LOW = 10V (was O.K. ist)
Angenommen, Sender B sendet LOW = 12V (was auch O.K. ist) (immer gemessen am Ort des Empfängers)
Angenommen, das Poti steht auf einer Position, die den 4011 bei ungefähr 11V schalten lässt.
Dann wird der Sender A erkannt, der Sender B jedoch nicht.
Ich bitte doch zu bedenken, dass das Poti sich nicht um die Spec kümmert sondern von seinem Eigentümer irgendwohin gedreht werden kann. Dort steht es dann und erkennt vielleicht alle Teilnehmer, vielleicht aber nur die Hälfte.
Den "Beweis" dafür kann ich gerne erbringen, denn auch bei meiner Anlage war das lange Zeit mit der Poti Schaltung so.
Das ist übrigens der Grund warum wir in der V2.x eine Schaltung mit einem Komparator, einer festen Referenzspannung und einem festen Schwellwert gewählt haben. Die Hysterese ist eine Draufgabe zur Unterdrückung von kleineren Störungen.
Damit wird wirklich alles erkannt was sich innerhalb der Spec befindet.
LG
Nett gemeint, aber mit "verstehe ich nicht" war nicht gemeint, dass ich die Technik nicht verstehe.
Sondern es war das Argument gemeint - denn wie man an dem Beispiel erkennt, ließe sich das Poti so einstellen, dass die Schaltschwelle bei 13,5 V sitzt, dann würden beide Sender bestens erkannt.
Also noch einmal: Ich zweifele an, dass es Systeme gibt, die sich innerhalb der Spezifikation bewegen und bei denen keine Stellung des Potentiometers gefunden werden kann, die alle Sender erkennt.
Dass das umständlich ist, unbenommen. Unbenommen auch, dass die erste Schaltung ziemlich primitiv ist.
LG
pah
Huch - hier geht irgendwie einiges durcheinander!
Ich fasse nochmal zusammen...
Zitat von: Prof. Dr. Peter Henning am 01 November 2018, 18:15:29
Zitat von: matze1986 am 01 November 2018, 16:41:22
Kanne es sein, dass das Poti am Koppler vielleicht nicht richtig eingestellt ist, und nur einige Geräte erkennt?
Nein.
Zitat von: Prof. Dr. Peter Henning am 03 November 2018, 09:11:58
Also noch einmal: Ich zweifele an, dass es Systeme gibt, die sich innerhalb der Spezifikation bewegen und bei denen keine Stellung des Potentiometers gefunden werden kann, die alle Sender erkennt.
Somit sollten sich inzwischen alle einig sein: das erste "Nein" war definitiv falsch!
Es kann sehr wohl an einer falschen Poti-Einstellung liegen, und um nichts anderes ging es John und Galileo (so wie ich es verstanden habe).
(Niemand hat irgendwann behauptet, dass sich das Poti nicht richtig einstellen lässt, es ging lediglich um die Frage ob es bei diesem Fehlerbild eventuell falsch eingestellt ist.)
Ihr habt ja Recht - ich hätte vielleicht den Post besser lesen sollen, bevor ich einfach "Nein" hinschreibe.
I stand corrected.
LG
pah
Hallo Zusammen,
ich habe nun einige Tage am Poti gespielt, es rauf und runter gedreht in gefühlt 0,1° Schritten.
Leider ohne Zufriedenstellenden Erfolg. Ich habe die gesammte Ebus Verdrahtung nochmals erneuert und gegen CAT5 kabel getauscht.
Hier habe ich ein verdrilltes Pärchen verwendet. Dei Verdrahtung des Installateurs bestand aus den Überlängen der Temperaturfühler.
Die Leitungslängen sind bei mir wie folgt:
VRS-->Heizgerät 3m
VRS-->Trinkwasserstation 4m
VRS-->Zusatzmischer 1m
VRS--> EbusKoppler 2m
Den Stromüberschuss konnte ich noch nicht messen, da mein Multimeter wohl im Eimer ist. Jedoch laut Spezifikationen http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_12_v1_3_1.pdf (http://ebus-wiki.org/lib/exe/fetch.php/ebus/spec_prot_12_v1_3_1.pdf) sollte die minimale Teilnehmerzahl ja bei 14 Sein.
Folgendes Verhalten habe ich mit dem Poti festgestellt.
Ist es zu niedrig eingestellt, erkenne ich nur Adresse
0a
12
15
26
Diese laufen dann sauber, ohne das es im Log zu Fehlern kommt.
Drehe ich das Poti weiter, kommen erste Fehler auf Adresse 15 wie ERR: ACK error und ERR: arbitration lost.
Weitere Geräte werden jedoch noch nicht erkannt.
Drehe ich das Poti noch weiter, tauchen dann auch die restlichen Geräte auf.
50
52
53
ec
Diese generieren dann im Log auch Fehler: wie ERR: ACK error und ERR: arbitration lost.
Ich habe hierzu nach fast jeder Poti Justage die komplette Heizungsanlage sowie das RPI und den KOppler neu gestartet.Da ic festgestellt habe, dass die Geräte machmal nicht erkannt werden, aber nach einem Neustart dann plötzlich doch.
Einen Punkt an dem alles ohne ACK Error läuft, kann ich vermutlich nicht einstellen.
Meine aktuelle config:
EBUSD_OPTS="--configpath=/etc/ebusd/ --scanconfig=full --receivetimeout=100000 --acquiretimeout=12000 --acquireretries=5 --sendretries=2 -d udp:192.168.24.74:5000 --httpport=5000 --latency=100000 --loglevel=error"
Zitat von: matze1986 am 04 November 2018, 13:19:27
Ich habe die gesammte Ebus Verdrahtung nochmals erneuert und gegen CAT5 kabel getauscht...
Das CAT5-Kabel ist eher die schlechtere Wahl als eBus-Verbindungsleitung, weil das (sehr allg. gesprochen) "auf hohe Frequenzübertragung" und nicht für Spannungs- und Stromübertragung gedacht ist.
Mit einem "ordinären" J-Y(St)Y 2x2x0,8 ist man strommäßig (Leitungswiderstand) auf der besseren Seite, das hat 0,8 mm Aderdurchmesser, ein CAT5-Kabel kann durchaus nur 0,37 mm Aderdurchmesser (flexible, feindrähtig) haben.
Ob so etwas jetzt schon bei so 10m Leitungslänge und vier/fünf eBus-Geräten (+ Klemmstellen) eine Spezifikations-Beeinträchtigung bewirkt, könnte man ja 'mal ggf. lt. eBus-Spezifikationsgrenzen mit den jeweils schlechtesten zu erwartenden Grenzwerten der eBus-Geräte durchrechnen.
"Gefühl" würde ich mich bei J-Y(St)Y 2x2x0,8 oder auch 2x2x0,6 da aber "schon wohler" fühlen... ;-)
Edit:
~~~~
Oh, sehe gerade, die eBus-Spezifikationen sagt da ja auch:
10.1 Übertragungsmedium
Das Übertragungsmedium ist eine verdrillte Zweidraht-Leitung
mit mindesten 0,6mm Durchmesser.
Das würde damit CATx-Kabel ja wohl irgendwie ausschließen.
ZitatDas CAT5-Kabel ist eher die schlechtere Wahl als eBus-Verbindungsleitung
Stimmt auffallend. Die beschriebenen Symptome können durchaus daher rühren, dass _entfernte_ Busteilnehmer nicht mehr innerhalb der Spezifikation liegen, weil der Leitungswiderstand zu groß ist und es damit zu einem Spannungsabfall kommt.
LG
pah
Nur abgesehen davon, dass es nicht CAT-Kabel heißt, sondern UTP oder STP
Ich hatte in den Spezifikationen gelesen das bei einem Querschnitt von 0,28mm eine leitungslänge von >200m möglich ist bei max. 100mA.
Dann werde ich die Verkabelung noch mal anpacken wenn ich 2x2 habe :-\
Mfg Matthias
Zitat von: matze1986 am 04 November 2018, 15:45:26Ich hatte in den Spezifikationen gelesen das bei einem Querschnitt von 0,28mm
mm² ---> 0,28qmm Querschnitt (!) = 0,5971mm Durchmesser ;-)
OT:
Zitat von: Prof. Dr. Peter Henning am 04 November 2018, 15:35:35
Nur abgesehen davon, dass es nicht CAT-Kabel heißt, sondern UTP oder STP
Nun ja,
genauer gesagt, die richtige Kabel-Bezeichnung (für ein falsches eBus- aber CAT5/STP-Kabel) lautet z.B.:
J-LI02YS(ST)C H 2 x 2 x 26 AWG
UTP/STP sind nur (weitere) beschreibende Merkmale, die sich aber 'eh schon aus der Kabel-Bezeichnung ergeben, CAT5 ist dann z.B. nur die garantierte Eigenschaft (Zertifizierung) des Kabels.
Um es nun noch auf die Spitze zu treiben:
Um die "wahre Lehre" der eBus-Spezifikation 100% einzuhalten, ist auch ein Kabel:
J-Y(St)Y 2x2x0,8 bzw. J-Y(St)Y 2x2x0,6
nicht gut genug, denn ein 2x2-Kabel ist nicht paarig verdrillte, sondern nur paarig viererverseilt.
Ein paarig verdrilltes Kabel fängt bei J-Y(St)Y erst ab 3 Aderpaaren an, z.B.:
J-Y(St)Y 3x2x0,8 bzw. J-Y(St)Y 3x2x0,6
;-)
Hallo Zusammen,
Ich habe nochmal alles mit 2x2x0,8 verdrahtet. Jedoch ohne Erfolg.
Ich habe versucht den Stromüberschuss zu messen. ich habe festgestellt das ich 2 Stromquellen habe, einmal das Heizgerät VC266/5-5 (Anzeige im amperemeter zyklisch 0-100mA) und meine Steuerung VRS620/3 hat auch eine Stromquelle. Diese zeigt das gleiche Verhalten.
Schließe ich alles an habe ich Ströme weit über 100mA.
Die Frage ist nur, warum läuft der Bus Vaillant intern? und wie bekomme ich diesen unter 100mA Stromüberschuss.
Warum stellt sich kein konstanter Messstrom ein?
Meine Messschaltung weicht etwas von der vorgegebenen ab, da ich keine passende Z Diode hatte.
Aufbau: Reihenschaltung aus Diode(A->K), Zdiode 3,3V (K-->A), Zdiode 5,1V (K-->A), Amperemeter.
Damit komme ich mit 0,6V + 3,3V + 5,1V auf 9,0V bzw, bei 0,7V auf 9,1V ich habe auch die Diode mal testweise weggelassen und komme somit auf 8,4V.
Die Schaltung aus den Specs sollte ja bei Durchlass = 0,6V+0,6V+7,5V=8,7V bzw bei 0,7Durchlass bei 8,9V liegen, oder habe ich da etwas missverstanden?
MfG Matthias
die Zenerdiode soll ja einen Kurzschluß verhindern, muss aber tiefer als "Low" sein sonst kann man den Stromüberschuß (eigentlich die Reserve die das interne Netzteil noch hat) nicht messen. Ich habe genau die angegebene Zenerdiode mit 7,5V genommen. Bei mir stellt sich kein pulsierender Stromfluß ein sondern ist ziemlich konstant, das würde ja bedeuten das jemand am Bus den beim Senden weit unter das Low drückt.
Aber wenn jetzt deine Zenerspannung zu hoch ist (höher als das kleinste Low) wäre das theoretisch möglich, das der Stromfluß auf 0 geht. Das sagt uns so dann nicht besonders viel weil die Messung dann einfach nicht stimmt. Das einzige was du noch testen kannst, nimm die 5,1V und schalte noch zusätzlich 3 Dioden in Serie (insgesamt dann 5) dann müsste die Strommessung wieder halbwegs stimmen.
Aber eines zeigt sich schon, wenn du auf 100mA Überschuß kommst dann hat der Konverter schon leichte Probleme beim Senden (auf Low ziehen), bzw. wird er die Signale schon verzerren. Das wäre die maximale Obergrenze laut Spez. Gegen 0 dürfte es nie gehen, sonst läuft man Gefahr das die Platine nicht mehr mit genug Energie versorgt wird. Aber das wird auch nicht der Fall sein.
Alles in allem, ist es jetzt bei dir schwierig ohne Oszilloskop da weitere zielführende Aussagen zu machen. Aber ein komplettes RAW Log von einem Scan wäre interessant, vor allem was bei den Adressen passiert die laut Konverter nicht antworten.
PS: schau mal auf deine PN!
LG
Hallo zusammen,
Ich wollte einen kurzen Zwischenstand abgeben.
Ich Habe es bis heute noch nicht vollständig mit dem Ethernet-koppler zum Laufen bekommen. Mit einem Oszilloskop bekomme ich saubere Signale auf dem Bus. Hier sind die Spannungen auch stabil. Alle Geräte haben eine Low-Spannung <12V und high >20V.
Ich werde mir jetzt einen anderen Koppler (USB) besorgen und melde mich dann wieder mit den Ergebnissen.
Mfg Matthias
Es gibt wieder eine neue Adapterversion V2.2!
hier geht's zur Sammelbestellung V2.2! (https://forum.fhem.de/index.php/topic,93190.msg857894.html#msg857894)
LG
Reinhart
Hi Zusammen,
ich habe die Letzten Tage/ Wochen noch viel am Ethernetkoppler probiert, mit Esera telefoniert und ein paar Dinge zur Verbesserung ausprobiert (Bsp.: Widerstand in reihe zum Koppler um den Stromverbrauch zu senken (200-470 Ohm)) jedoch alles ohne Erfolg.
Der Service bei Esera ist echt gut. Es wird sich sofort Zeit genommen, wenn man anruft, und auf das Problem eingegangen und nach einer Lösung gesucht.
Aktueller Stand sieht so aus, das ich den Ethernet Koppler zurücksenden werde oder zu einem Gratis Hardwareupdate einschicke (Hardware jedoch immernoch mit Poti). Der Koppler ist ja nicht defekt, sondern arbeitet mit meinen Komponenten halt nicht vollständig.
Ich hatte die Möglichkiet einen USB Koppler von Reinhart auszuprobieren. https://forum.fhem.de/index.php/topic,93190.msg857894.html#msg857894 (https://forum.fhem.de/index.php/topic,93190.msg857894.html#msg857894) Vielen Dank Reinhart für deine Unterstützung!!
Die Platine kam, ans Rpi dran, kurz konfiguriert, nochmal geprüft ob der USB stimmt, da anfangs keine Daten kamen, alles mal neugestartet und dann...
Es lief & läuft perfekt!! ;D ;D ;D
Habe den Koppler jetzt auf Adresse ff laufen. Ohne Probleme, innerhalb von wenigen Minuten wurden alle Geräte erkannt und die passenden CSVs zugeordnet. Lesen und schreiben ist über GAEBUS problemlos möglich.
Vielen Dank an Alle die das Projekt vorantreiben und an alle die im Forum unterstützen!
Anbei meine Config:
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --loglevel=error"
Das System läuft jetzt seit knapp 2 Wochen stabil. Es gibt keine Probleme. Nur gelegentliche (1x pro h) Arbritierungsfehler, welche aber normal sind denke ich.
Ich habe nur noch ein Problem mit dem Autostart vom Ebus daemon. Seitdem ich das System auf einem Rpi 3B+ aufgesetzt habe, startet der Daemon nicht automatisch.
Ich habe eine ebusd Datei mit folgendem Inhalt im Ordner /etc/init.d/ jedoch ohne Erfolg
#!/bin/bash
#
### BEGIN INIT INFO
# Provides: ebusd
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $network $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: controls ebusd, the daemon for communication with eBUS heating systems.
### END INIT INFO
DAEMON=/usr/bin/ebusd
PIDFILE_PREFIX=/var/run/ebusd
PIDFILE_SUFFIX=.pid
. /lib/lsb/init-functions
[ -r /etc/default/ebusd ] && . /etc/default/ebusd
if [ ! -x $DAEMON ]; then
log_failure_msg "$DAEMON is not available or not executable."
exit 5
fi
ALL_OPTS=${!EBUSD_OPTS*}
if [ ${#ALL_OPTS[@]} -lt 1 ]; then
ALL_OPTS[0]=EBUSD_OPTS
fi
instance="EBUSD_OPTS$2"
instance=${!instance}
start_instance () {
local opts suffix
opts=$1
shift
suffix="${opts#EBUSD_OPTS}"
log_daemon_msg "Starting ebusd${suffix}" ebusd
pidfile=$PIDFILE_PREFIX${suffix}$PIDFILE_SUFFIX
start-stop-daemon --start --quiet --oknodo --pidfile $pidfile --exec $DAEMON -- --pidfile $pidfile ${!opts}
log_end_msg $?
}
stop_instance () {
local opts suffix
opts=$1
shift
suffix="${opts#EBUSD_OPTS}"
log_daemon_msg "Stopping ebusd${suffix}" ebusd
pidfile=$PIDFILE_PREFIX${suffix}$PIDFILE_SUFFIX
start-stop-daemon --stop --quiet --oknodo --pidfile $pidfile
log_end_msg $?
rm -f $PIDFILE_PREFIX${suffix}$PIDFILE_SUFFIX
}
case $1 in
start)
if [ -z "$2" ]; then
for opts in $ALL_OPTS; do
start_instance $opts
done
elif [ -z "$instance" ]; then
log_failure_msg "ebusd$2 is not configured"
else
start_instance EBUSD_OPTS$2
fi
;;
stop)
if [ -z "$2" ]; then
for opts in $ALL_OPTS; do
stop_instance $opts
done
else
if [ -z "$instance" ]; then
log_warning_msg "ebusd$2 is not configured"
fi
stop_instance EBUSD_OPTS$2
fi
;;
restart|force-reload)
ARGS=($@)
$0 stop ${ARGS[@]:1} && sleep 2 && $0 start ${ARGS[@]:1}
;;
status)
if [ -z "$2" ]; then
for opts in $ALL_OPTS; do
suffix=${opts#EBUSD_OPTS}
pidfile=$PIDFILE_PREFIX$suffix$PIDFILE_SUFFIX
status_of_proc -p $pidfile $DAEMON ebusd$suffix
done
else
if [ -z "$instance" ]; then
log_warning_msg "ebusd$2 is not configured"
fi
pidfile=$PIDFILE_PREFIX$2$PIDFILE_SUFFIX
status_of_proc -p $pidfile $DAEMON ebusd$2
fi
;;
*)
echo "Usage: $0 {start|stop|restart|force-reload|status} [instance]"
exit 2
;;
esac
MfG Matthias
Hallo matze1986!
Danke für deinen ausführlichen Bericht!
Betreffend Autostart, das kommt jetzt auf dein System drauf an, aber wenn du neu installiert hast nehme ich an läuft Stretch!
Dann solltest du den Dämon als Service starten, siehe hier. (https://forum.fhem.de/index.php/topic,84636.msg863087.html#msg863087)
LG
So, der Service startet jetzt auch von alleine.
Den Service musste ich nicht wie Reinhart verlinkt hat, starten, das Eintragen des configpath in meine Ebus config hat gereicht. (https://forum.fhem.de/index.php?topic=29737.2730 (https://forum.fhem.de/index.php?topic=29737.2730))
Meine nun funktionierende Config inkl. Starten des Daemon nach einem Neustart lautet:
EBUSD_OPTS="--configpath=/etc/ebusd -d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --latency=20000 --address=ff --loglevel=error"
Hallo liebes Forum,
nach Durchsicht gibt es anscheinend jede Menge unterschiedliche Themen und deshalb frage ich einfach mal folgendes:
Ich möchte bei meiner Weishaupt-Wärmepumpe den Sollwert Raumtemperatur auslesen und habe herausgefunden, das er sich unter:
30f150230924a706d2005d01000 versteckt im Byte mit dem Wert d2 (21.0°C). Ich habe eine CSV-Datei kreiert, die folgendermaßen aussieht:
# type (r[1-9];w;u),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment,field,part (m/s),type / templates,divider / values,unit,comment
*r,,,,,f1,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,ehp,Act1,Broadcast mit Istwerten,,,5023,24a7,Status1,,UCH,,, noch ungekannt 06,Solltemperatur,,UCH,,,Solltemperatur,unknown1,,UCH,,,noch unbekannt 00,unknown2,,UCH,,,noch unbekannt 5d,unknown3,,UCH,,,noch unbekannt 01,unknown4,,UCH,,,noch unbekannt 00,unknown5,,UCH,,,noch unbekannt 00
!include,sc.systemheatcontrol.inc,,System WÀrmesteuerung
Jetzt zu meiner Frage: Meine ID lautet ja 24a7. Es scheint, das das erste Byte sich verändert, wenn sich die Solltemperatur (jemand ändert die Temperatur an der Anlage) verändert. Also d2 ändert sich zum Beispiel in d7, aber auch meine ID ändert sich dann von 24a7 in z. B. 0fa7 und damit funktioniert das Ganze nicht mehr. Habe ich etwas falsch verstanden? Oder kann man die csv-Datei so anlegen, das bei der ID nur a7 berücksichtigt wird, also sowas wie ein wildcard, vielleicht ??a7?
Wäre schön, wenn mich hier einer aufklären könnte. Danke im Voraus
Zitat von: Alda am 01 Dezember 2018, 18:24:32
30f150230924a706d2005d01000 versteckt im Byte mit dem Wert d2 (21.0°C). Ich habe eine CSV-Datei kreiert, die folgendermaßen aussieht:
Jetzt zu meiner Frage: Meine ID lautet ja 24a7. Es scheint, das das erste Byte sich verändert, wenn sich die Solltemperatur (jemand ändert die Temperatur an der Anlage) verändert. Also d2 ändert sich zum Beispiel in d7, aber auch meine ID ändert sich dann von 24a7 in z. B. 0fa7 und damit funktioniert das Ganze nicht mehr. Habe ich etwas falsch verstanden? Oder kann man die csv-Datei so anlegen, das bei der ID nur a7 berücksichtigt wird, also sowas wie ein wildcard, vielleicht ??a7?
Zur ID gehört auch die Zieladresse sowie PBSB, also die ID wäre hier f1502324a7.
Ein Überspringen bzw. Auslassen eines Bytes im Datenteil ist derzeit in ebusd allerdings nicht möglich, d.h. Du müsstest schauen ob die ID nicht evtl einfach kürzer ist (nur bis inkl. PBSB), was nahe liegt wenn sich das erste Datenbyte inhaltlich mit den Daten ändern würde. Eine andere Möglichkeit ist, dass es sich bei ...24a7 doch eigentlich um eine andere Nachricht handelt, die aber genau gleich aufgebaut ist.
Hallo John30
also erst mal schönen Dank für Deine Antwort und vor allem für Deine Arbeit an Ebusd. Ich finde, eine Super-Arbeit! Selten findet man, das die Arbeit auch noch so super dokumentiert ist!
30f150230920ec06c8005d010000 = 16
30f1502309e8e70604005d010000 = 16
30f150230924a706d2005d010000 = 4: ehp Act1
30f1502309e8cd061f005d010000 = 16
30f150230930b406c8005d010000 = 64
30f1502309f8c60600005d010000 = 16
30f1502309fcde0605005d010000 = 16
30f150230958e506a1005d010000 = 16
30f1502309fcd00600005d010000 = 16
30f150230934f506c8005d010000 = 16
30f1502309f0f8060f005d010000 = 16
Ich habe mal ein paar Telegramme reinkopiert. 30f15023 ist immer gleich, dann kommt die Länge (9 Bytes), dann was ich als ID benannt habe (wobei ich ja jetzt weiß, das die länger ist) und zum Schluß immer 005d010000. Die ID zu verkürzen bringt also nichts, oder?
Wie meinst Du das
Zitat
..24a7 doch eigentlich um eine andere Nachricht handelt, die aber genau gleich aufgebaut ist.
?
Eigentlich soll ja auch der Sollwert als Broadcast gesendet werden, f1 ist aber wohl keine Broadcast-Adresse?
bei mir läuft das teil endlich auch recht gut. :)
danke für die tolle arbeit. :)
Hat jemand von euch die umwälzpumpe der heizung einen write befehl senden können?
ich würde diese gerne in einem hybrid system nutzen und daher außerhalb der vaillant wärmepumpe ansteuern können.
kann der pumpe zwar die write befehle senden, die werden aber nicht angenommen obwohl 'done' retour kommt.
pi@raspberrypi:~ $ ebusctl w -c 700 Hc1PumpStatus 1
done
pi@raspberrypi:~ $ ebusctl r -f Hc1PumpStatus
0
kann es sein dass man bestimmte geräte nicht mehr finden nachdem man -- enablehex in der EBUSD_OPTS hinzugefügt hat?
geht alles super aber nach dem neustart verschwindet immer die address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
Ich vermute mal, dass die VRC700 selbst einfach die Pumpe wieder abschaltet.
Wie hast du den Heizkreis im Regler definiert? Gibt es überhaupt einen "manuell", mit dem man selbst festlegen kann, ob die Pumpe an oder aus ist?
Du könntest mal versuchen, stattdessen "hc1Status" zu setzen.
"Sauberer" wäre es wohl aber, das über die Zone zu steuern (hex 03000600), bei mir heißt der Wert "hc1OpMode" und kann den Heizkreis konkret setzen: 0=off;1=auto;2=day;3=night
(Könnte sein, dass das in einigen Versionen umbenannt wurde, evtl. auch "z1OpMode" probieren oder nach dem Hexwert suchen)
Das mit dem Enablehex kann ich so nicht bestätigen, bei mir werden immer identische Geräte gefunden und enablehex habe ich davon abgesehen immer drin.
danke das hilft ein wenig weiter.
du kannst deiner 470 per terminal sagen wann sie heizen soll oder nicht?
bei meiner 470 sind einige dinge nie zu schreiben gegangen wie zb. die einmalige speicherladung 'HwcOPMode'
bei der 700 schreibt er mir den wert zwar als 'done' retour. das war es aber schon :)
es ist wahrscheinlich nicht vorgesen so weit in das system eindringen zu können.
das wird wohl mit dem regler nicht möglich sein weil es dort selber die funktion nicht gibt.
denkst du man könnte die hex werten am innengerät selber abhören an dem auch die pumpe dranhängt?
habe auch in keiner csv etwas über das kühlen nachlesen können.
kann man das alles über den 'raw' befehl abhören und dann durch drücken der jeweiligen option mit ein wenig übung auslesen
oder bin ich da komplett falsch unterwegs? :'(
Ich hatte nie eine 470, von Anfang an die 700.
Für das Setzen der Sonderfunktion(en) wie "Einmalige Speicherladung" muss man den SFMode setzen, bei manchen Funktionen werden auch mehrere Sachen gesetzt, zum Abbrechen der Funktion werden dann jeweils wieder andere Sachen gesendet. Ich hatte das mal irgendwo dokumentiert, bin aber aktuell unterwegs und finde es nicht...
Durch diesen "Verhau" war es jedenfalls nicht einfach möglich, ein Feld zu definieren das auf "Speicherladung an/aus" gesetzt werden kann.
Und ja - das mit dem Mitlesen habe ich ja getan:
Hier wird es aber wenig helfen, die Meldungen der 700 an die eigentlichen Aktoren mitzulesen, weil diese danach ja alles gleich wieder nach ihrer Logik überschreiben würde. Ich habe stattdessen mitgelesen, was die VR900 bei Nutzung der App an die 700 schickt.
Das RAW-Logging brauchst du dazu eigentlich nicht, weil alle identifizierten Meldungen im normalen Log als "write" oder "update" erscheinen müssten und alle anderen als "unknown MS".
@rob uboot Bei meiner Vail 610 funktioniert 1xSpeicherladen siehe
https://forum.fhem.de/index.php/topic,29737.msg744771.html#msg744771 (https://forum.fhem.de/index.php/topic,29737.msg744771.html#msg744771)
Wann sie heizen soll geht über die Zeitsteuerung, die ich verändern kann.
Modus umschalten on, off, auto eco ebenfalls (Heizen, WW, ..). Dieser steckt in einem array, d.h. man muss immer alle Felder schreiben sonst tut sich nichts.
Zitat von: Sven77 am 05 Dezember 2018, 17:07:25
Für das Setzen der Sonderfunktion(en) wie "Einmalige Speicherladung" muss man den SFMode setzen,
bei manchen Funktionen werden auch mehrere Sachen gesetzt, zum Abbrechen der Funktion werden
dann jeweils wieder andere Sachen gesendet. Ich hatte das mal irgendwo dokumentiert, bin aber aktuell
unterwegs und finde es nicht...
Hast Du Deine Aufzeichnungen wieder gefunden?
Könntest Du die dann hier einfach "einkippen", ggf. kann man damit ja doch noch etwas für
die 470er anpassen und dann austesten?
Danke schon 'mal.
LG
Zitat von: sua am 08 Dezember 2018, 20:59:59
Hast Du Deine Aufzeichnungen wieder gefunden?
Ja, aber ich glaube kaum dass das bei der 470 schon genauso gemacht wurde - allein schon, weil diese noch gar nicht mit 4-Byte-Registeradressen und B524-Nachrichten arbeitet.
Zum Setzen der Sonderfunktion, schreibt die VR900 immer das Register 00007400:
r;w,,SFMode,SFMode,,,,"00007400",mode,,UCH,,,0=auto 1=int.ventilation 2=party 3=quickveto,,,Da ich nicht genau weiß, ob das alle möglichen Funktionen sind, habe ich sie nur im Kommentar erwähnt, statt gleich eine Bezeichnung für die Zahlen einzuführen. Man müsste SFMode also auf 2 setzen, um den Party-Modus zu aktivieren.
Für "einmalige Speicherladung" wird hingegen direkt nur der hwcSFMode (Register 01000D00) auf 6 gesetzt:
r;w,,hwcSFMode,hwcSFMode,,,,"01000D00",mode,,UCH,,,0=auto 1=int.ventilation 2=party 6=loadonce,,,Das tut in meinem Hydraulikschema jedoch leider gar nichts, nicht einmal die Zirkulationspumpe wird eingeschaltet.
Wenn irgendeine dieser Funktionen aktiv ist, kann man am VRC700 und in der App jeweils nur "Abbrechen" wählen. Das setzt dann aus allen Funktionen heraus einfach das Register 00007800 zurück auf 0. Dieses kann auch während der Sonderfunktionen genutzt werden, um den Status auszulesen - es funktioniert aber nicht, allein damit eine der Sonderfunktionen zu aktivieren!
r;w,,DisplayedSFMode,DisplayedSFMode,,,,"00007800",mode,,UCH,,,0=auto 1=int.ventilation 3=party 7=holiday 9=loadonce 10=sys.off,,,Sehr verwirrend übrigens, dass die jeweiligen Sonderfunktionen in den verschiedenen Registern teilweise unterschiedlichen Werten zugeordnet sind. Wie man den Status "System AUS" aktiviert und ob man vielleicht irgendwie auch ohne den Timer (Setzen von Start und Ende) den Urlaubsmodus aktivieren kann, habe ich bisher nicht untersucht.
Hinweis: in neueren CSVs sind die Nachrichten in verschiedene Blöcke geteilt (Global = 0000) und die Nachrichtendefinition dementsprechend kürzer. Wenn man sich die Hex-Nachrichten aber von Hand zusammenbaut, findet man das hoffentlich in beiden, z.Bsp. 'ebusctl hex 15b52407020101000d0006' für einmalige Speicherladung.
danke für die antworten :)
damit kann man schon was anfangen.
hat irgendjemand schon mal die kühlfunktion aktivieren können?
Zitat von: Sven77 am 10 Dezember 2018, 08:11:01
Ja, aber ich glaube kaum dass das bei der 470 schon genauso gemacht wurde - allein schon, weil diese noch gar nicht mit 4-Byte-Registeradressen... arbeitet.
Jo, das befürchte ich auch...
Danke für das Teilen der Infos und auch auch für die weiteren Erläuterungen.
LG
Hallo Ihr eBus Experten,
ich habe den tollen RPi ebus Adapter von Reinhart bekommen (vielen Dank nochmal an alle Beteiligten für dieses super Projekt) und komme soweit sehr gut mit dem Auslesen von Werten meiner Vaillant VWS102/2 zurecht.
Nun meine Frage zum Schreiben:
(meine "zuständige" .csv ist diese hier: ebusd-configuration/ebusd-2.1.x/de/vaillant/08.ehp.csv)
Ich kann einen Wert auslesen, z.B.:
ebusctl read -c ehp comphysteresis
Da kommt die Antwort 7.00 zurück, wie erwartet.
Das Schreiben dieses Parameters klappt allerdings nicht:
ebusctl write -c ehp comphysteresis 10.0
ERR: element not found
Der Wert "comphysteresis" sollte laut .csv und nach meinem Verständnis ein schreibbarer Wert sein.
Ich vermute, dass mein Format des übergebenen Wertes "10" irgendwie falsch ist. Wird da ein String oder eine Zahl erwartet, mit oder ohne Komma ? Ich habe es mit und ohne Anführungszeichen und Dezimalpunkt versucht, aber ohne Erfolg.
Bei allen anderen möglichen Parametern aus der csv das gleiche Problem.
Ich weiss, dass die Probleme mit den .csv je nach angeschlossener Maschine sehr unterschiedlich liegen können, aber vielleicht gibt es grundsätzliche Hinweise zum ebusd Schreiben ?
Vielen Dank für Eure Hilfe
Gruß
Daniel
Das "wi" in der CSV steht für Install-Level, du musst also den Circuit ergänzen:
ebusctl write -c ehp#install comphysteresis 10.0
Womöglich musst du beim Starten des Daemon auch den Accesslevel setzen, also vorsorglich mal "--accesslevel=*" anhängen!
Hallo Sven77,
ganz große Klasse ! --accesslevel=* war genau der richtige Tip.
Dann braucht es auch kein ehp#install und ich kann alle Parameter schreiben.
Vielen Dank und schönen Abend
Gruß
Daniel
Zitat von: Jojo11 am 13 Dezember 2014, 10:07:37
Hallo Heiko,
ich habe exakt die gleiche Kombination (mit einer ecoTec Plus 206) bei mir laufen und überlege auch gerade, wo ich mich an den ebus ankopple und welchen Adapter ich dazu nehme. Evtl. können wir uns beim Entschlüsseln der Befehle austauschen, sobald die hardware bei mir läuft. Ich würde lieber gerne direkt an der Heizung an den ebus gehen, auch wenn die Einheit im Wohnzimmer einen Anschluss hat. Hast Du den Anschluss schon nach draußen gelegt?
schöne Grüße
Jo
Nachtrag: Meine ecoTec hat laut Installationsanleitung auf den Platine eine RJ1x (ist es RJ10 oder RJ11?) Buchse "Diagnosis über eBus, vrnetDIALOG" sowie zwei Schraubklemmen "Anschluss für externen eBus Regler". Ist es egal, an welchen dieser Anschlüsse ich mich ankopple? Die RJ-Buchse ist noch unbelegt und bietet sich eigentlich an.
@jojo11:
Ist zwar schon ein paar Jährchen her, aber Du hattest damals wohl den eBus über eine RJ10-Buchse angeschlossen.
Ich habe jetzt das gleiche Problem mit dem Anzapfen des eBuses über die Diagnosebuchse des Vaillant-Reglers VR70, wie ich schon in einem anderen Thread berichtete.
Kannst Du mir sagen, wie Du welche Kontakte der RJ10-Buchsen/Stecker Kombination genutzt hast?
Vielen Dank im Voraus.
Vom kalten Strand
Det :)
Hallo eBus-Gemeinde,
ich stelle bei mir (ebus Adapter V2 für Raspberry) fest, dass beim Auslesen mit "ebusctl read xxx" der gelesene Wert manchmal "hängenbleibt".
Das heißt, es wird bei mehrfachem Aufruf von "ebusctl read xxx" (mit mehreren Minuten Abstand) immer wieder der gleiche Wert ausgegeben, obwohl er sich eigentlich schon verändert hat.
Davon können nach dem Zufallsprinzip wohl alle auszulesenden Parameter betroffen sein.
Festsitzende Werte werden dann scheinbar unvorhersehbar irgendwann doch wieder aktualisiert. Die sicherste Variante, alle zu aktualisieren, ist das Beenden und Neustarten des ebusd Dienstes. (mit sudo service ebusd stop und sudo service ebusd start).
Ist dieses "Steckenbleiben" von ausgelesenen Werten schon jemandem untergekommen ?
Danke und Gruß
Daniel
Zitat von: daniel1976 am 16 Dezember 2018, 20:22:58
ich stelle bei mir (ebus Adapter V2 für Raspberry) fest, dass beim Auslesen mit "ebusctl read xxx" der gelesene Wert manchmal "hängenbleibt".
ebusd cached die Werte, damit nicht jedes Mal ein Buszugriff erfolgt. Möchtest Du das nicht, dann forciere einfach das lesen vom Slave mittels "ebusctl read -f xxx".
Aus gegebenem Anlass:
Bitte sorgt dafür, dass ein /dev/ttyUSBx für ebusd nicht gleichzeitig von anderen Tools verwendet wird, wie bspw. fhem. Das kann zu Schaden an der Heizung führen!
fhem hat zudem einen Modus, in welchem USB Geräte beim Start automatisch abgescannt werden (Stichwort initialUsbCheck) und dann als Device in die fhem.cfg eingetragen werden. Auch das ist fahrlässig und sollte unbedingt vermieden werden, wenn fhem und ebusd auf dem gleichen Host laufen.
Hallo john30,
danke für Deine aufschlussreiche Antwort, ich hatte gehofft, dass es so einfach ist. Jetzt funktioniert das Auslesen wie gewünscht.
Und Danke für Deine Arbeit am ebusd !
Gruß
Daniel
Zitat von: Schlauer Det am 16 Dezember 2018, 10:51:15
Kannst Du mir sagen, wie Du welche Kontakte der RJ10-Buchsen/Stecker Kombination genutzt hast?
Lt. pah (https://books.google.de/books?id=f6Z4DwAAQBAJ&lpg=PT14&ots=1W-sYwxe0p&dq=henning%20hacks%20f%C3%BCr%20die%20heizung%20kapitel%205&hl=de&pg=PT178#v=onepage&q=rj10&f=false) sollten es die beiden mittleren PINs eines RJ10-Steckers sein.
@Sven77:
Vielen Dank, das hilft.
Grüße von der veregneten Küste
Det :)
EDIT:
Habe nach Durchlesen dieses gesamten Threads in
https://forum.fhem.de/index.php/topic,29737.msg433114.html#msg433114 (https://forum.fhem.de/index.php/topic,29737.msg433114.html#msg433114)
die gesuchte Information gefunden :D :D :D.
Jetzt muss nur noch die RPi-Platine kommen, dann geht es los.
Aus dem hohen Norden
Det :)
Hallo eBus User,
nach diversen Suchen im Web und lesen diverser Posts hier im Forum, bin ich leider mit meiner eBus Anbindung nicht weiter gekommen.
Ich hoffe jemand kann mir ein paar Tipps geben.
Ich habe eine Ochsner Wärmepumpe mit OTE3 und habe den eBus mittels esera USB Adapter an meinem Pi per USB angebunden.
Egal was ich auch anstelle, ich erhalte nicht wirklich irgendwelche Werte der Wärmepumpe.
Wo könnte das Problem liegen? Bin für jeden Tipp dankbar.
Frohe Weihnachten und schon mal einen Guten Rutsch ins neue Jahr.
Gruß
Rene
Anbei meine config und diverse Ausgaben:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
# EBUSD_OPTS="--scanconfig"
EBUSD_OPTS="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A906RN9K-if00-port0 --configpath=/etc/ebusd --enablehex --receivetimeout=100000 --acquiretimeout=12000 --acquireretries=5 --sendretries=2"
# MULTIPLE EBUSD INSTANCES WITH SYSV
root@raspberrypi:/etc/ebusd# ebusctl info
version: ebusd 3.2.v3.2
update check: revision v3.2-12-g45b9bad available, broadcast.csv: newer version available
signal: acquired
symbol rate: 60
max symbol rate: 121
min arbitration micros: 710
max arbitration micros: 865
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 5
messages: 16
conditional: 0
poll: 0
update: 4
address 01: master #6
address 03: master #11
address 10: master #2
address 13: master #12
address 15: slave #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 91: slave
root@raspberrypi:/etc/default# ebusctl find -d
broadcast datetime = 2.000;10:54:00;24.12.2018
broadcast error = SE60 E OK
root@raspberrypi:/etc/default# ebusctl grab result
1003050a00 = 14
1013050a00 = 14
1091103100 / 070000004a80007f = 48
100305020101 = 14
101305020101 = 14
10fe050d0a0000800000800080ffff = 5
10fe080109002600800008002100 = 1
10fe080109192800800008002400 = 5
10fe080109332700800008002200 = 2
10fe0801094d2700800008002300 = 8
10fe080109662700800008002300 = 4
10fe080109802700800008002300 = 3
10fe0801099a2700800008002300 = 4
10fe080109b32700800008002300 = 3
10fe080109cd2600800008002200 = 2
10fe080109e62700800008002300 = 5
10fe0802080041003300000046 = 12
10fe10150b02010601020000d5002900 = 5
1091101203000601 / 087fff0080d5002900 = 111
101305010a00213302000001000100 = 6
10911031071f05021e000900 / 070405004a22017f = 1
109110310b0804800d02e8030000e401 / 073f7f000000007f = 1
109110310b0246410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b0a01800d02f4010000d500 / 073f7f000000007f = 1
109110310b0c4841042a9f0500008202 / 073f7f000000007f = 1
109110310b0402800d02e80300005401 / 073f7f000000007f = 1
109110310b0e46410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b0600800d02f4010cfe1400 / 073f7f000000007f = 1
109110310b1d00800d02f4010cfe1400 / 070405004a1f007f = 1
109110310b1546410428ffff0000c1a9 / 070248004a17007f = 1
109110310b174841042a9f0500008402 / 070001004a19007f = 1
109110310b1901800d02f4010000d600 / 070002004a1b007f = 1
109110310b104841042a9f0500008302 / 073f7f000000007f = 1
109110310b1b02800d02e80300005101 / 070000004a1d007f = 1
109110310b1404800d02e8030000e401 / 070246004a15007f = 1
109110310b258442000250003c003c00 / 070556004e27007f = 1
109110310b27d64200023c000a000a00 / 070533004e29007f = 1
109110310b2bb0410002280002012800 / 070324004a2d007f = 1
109110310b2da44101025000ec012800 / 070315004a2f007f = 1
109110310b24b2410900b30100000100 / 070504004e25007f = 1
109110310b3d04800d02e8030000e401 / 070102004a3f007f = 1
109110310b318d410002b4003c014c00 / 070338004a33007f = 1
109110310b3f82800d02e80300004e01 / 070101004a41007f = 1
109110310b3b84800d02e8030000fe01 / 070004004e3d007f = 1
109110310b454841042a9f0500008502 / 070246004047007f = 1
109110310b4333810000ff0000000100 / 070248004045007f = 1
109110310b4746410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b4a04800d02e8030000e401 / 073f7f000000007f = 1
109110310b4c46410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b4e4841042a9f0500008602 / 073f7f000000007f = 1
109110310b4181800d02e8030000cd00 / 070233004a43007f = 1
109110310b5400800d02f4010cfe1400 / 073f7f000000007f = 1
109110310b5d46410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b5604800d02e8030000e401 / 073f7f000000007f = 1
109110310b5846410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b5001800d02f4010000d500 / 073f7f000000007f = 1
109110310b5a4841042a9f0500008802 / 073f7f000000007f = 1
109110310b5202800d02e80300005201 / 073f7f000000007f = 1
109110310b6c01800d02f4010000d500 / 073f7f000000007f = 1
109110310b2f95414d022c019cff9600 / 07030d004a31007f = 1
109110310b6e02800d02e80300005201 / 073f7f000000007f = 1
109110310b6400800d02f4010cfe1400 / 073f7f000000007f = 1
109110310b6604800d02e8030000e401 / 073f7f000000007f = 1
109110310b684841042a9f0500008a02 / 073f7f000000007f = 1
109110310b6001800d02f4010000d500 / 073f7f000000007f = 1
109110310b6a46410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b6202800d02e80300005201 / 073f7f000000007f = 1
109110310b744841042a9f0500008c02 / 073f7f000000007f = 1
109110310b7c01800d02f4010000d600 / 073f7f000000007f = 1
109110310b7646410428ffff0000c1a9 / 073f7f000000007f = 1
109110310b7e02800d02e80300004e01 / 073f7f000000007f = 1
109110310b39b3414d022c016400cd00 / 070104004e3b007f = 1
109110310b35b6414d022c016400f000 / 070335004a37007f = 1
109110310b78ff9f0000000000000000 / 070248004a79007f = 1
109110310b37b5414d022c016400c800 / 070333004a39007f = 1
109110310b7000800d02f4010cfe1400 / 073f7f000000007f = 1
109110310b794841042a9f0500008d02 / 073f7f000000007f = 1
109110310b33b8414d022c016400e600 / 070336004a35007f = 1
109110310b7204800d02e8030000e301 / 073f7f000000007f = 1
109110310b8000800d02f4010cfe1400 / 073f7f000000007f = 1
109110310b29b3428d0258026400fe01 / 070330004a2b007f = 1
109110310bed01800d02f4010000d500 / 073f7f000000007f = 1
109110310be900800d02f4010cfe1300 / 073f7f000000007f = 1
109110310beb04800d02e8030000e501 / 073f7f000000007f = 1
109110310be702800d02e80300005701 / 073f7f000000007f = 1
109110310bef46410428ffff0000c1a9 / 073f7f000000007f = 1
109110310bfd01800d02f4010000d500 / 073f7f000000007f = 1
109110310bf446410428ffff0000c1a9 / 073f7f000000007f = 1
109110310bf900800d02f4010cfe1300 / 073f7f000000007f = 1
109110310bf14841042a9f0500007e02 / 073f7f000000007f = 1
109110310bfb04800d02e8030000e501 / 073f7f000000007f = 1
109110310bf702800d02e80300005601 / 073f7f000000007f = 1
109110310bff4841042a9f0500008002 / 073f7f000000007f = 1
109110320b224845495a4b5245495320 / 070405014a23017f = 1
011506210400800040 / 0a00800d02f4010cfe1400 = 15
011506210400840040 / 0a04800d02e8030000e301 = 20
011506210400e00040 / 0a60800d02e80300009101 = 19
011506210400800042 / 0a00800d02f4010cfe1400 = 2
011506210400880042 / 0a08800d02e80300003e01 = 1
011506210402b50040 / 0a35810000ff0000000100 = 15
011506210400c60042 / 0a46800d02e80300000500 = 2
011506210400c70042 / 0a47800d02e80300002600 = 1
011506210402c80040 / 0a4841042a9f0500008d02 = 24
01150621040080004e / 0a00800d02f4010cfe1400 = 1
01150621046581000e / 0ab3428d0258026400fe01 = 1
01150621047d800002 / 0a35810000ff0000000100 = 2
01150621047d830002 / 0a46800d02e80300000600 = 1
01150621047d890002 / 0ada8a0d34e8030000e900 = 1
01150621047d8c0002 / 0a868b0d120f2700001f0d = 1
031005030c010148645124ff3f00000900 = 139
131005030c010000004fffff3f43000101 = 2
Zitat von: PavelCoast am 24 Dezember 2018, 10:54:18
Ich habe eine Ochsner Wärmepumpe mit OTE3 und habe den eBus mittels esera USB Adapter an meinem Pi per USB angebunden.
Egal was ich auch anstelle, ich erhalte nicht wirklich irgendwelche Werte der Wärmepumpe.
Wo könnte das Problem liegen? Bin für jeden Tipp dankbar.
welche configs hast Du denn installiert? Im letzten ebus-2.1.x Zweig (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x) sind keine Ochsner Configs drin, d.h. du müsstest bspw. den ebus-1.x.x Zweig (https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x) nehmen
Hallo,
danke für die Rückmeldung, habe jetzt eine 22420.txt gefunden und als _templates.csv benutzt.
Die outsidetemp wird schon mal korrekt angezeigt, aber noch keine weiteren Werte.
Dauert es immer eine Weile bis etwas angezeigt wird?
Gruß
René
Zitat von: PavelCoast am 25 Dezember 2018, 17:00:18
danke für die Rückmeldung, habe jetzt eine 22420.txt gefunden und als _templates.csv benutzt.
Die outsidetemp wird schon mal korrekt angezeigt, aber noch keine weiteren Werte.
Dauert es immer eine Weile bis etwas angezeigt wird?
nicht als _templates benutzen, da stehen ja nur shortcuts drin, um nicht bei jedem Feld nen Roman hinschreiben zu müssen. Und woher hast Du die und wieso nimmst Du nicht meinen Vorschlag?
Naja, ich bin off für heute
danke nochmals, habe jetzt die Dateien aus dem Link genommen, mal sehen, ob ich nun mehr Daten erhalte.
Hallo,
leider wird bis auf outsidetemp nichts weiter erkannt.
Wie kann ich da weiter machen?
Gruß
Rene
ebusctl find -d
broadcast datetime = 7.301;17:31:00;27.12.2018
broadcast error = SE60 E OK
Hallo,
in der csv sind auf jeden Fall messages definiert, die auch bei deinem grab log auftauchen. Diese z.B. https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv#L30
Starte ein grab, browse durch das menü deines controllers und dann sollten 1015.... / ... messages auftauchen, die dekodiert werden - falls definiert.
Gruß Andreas
Habe noch eine Frage zu zwei Registern.
Mit ebusctl find sehe ich bei beiden folgenden Inhalt:
mc Status0a = 35.00;open;on;off;39
mc Status = 39;off;33.19;22
Da stehen also die Werte drin, die ich haben möchte.
Frage ich dann aber so ab, sind die Register leer.
pi@raspberrypi:~ $ ebusctl r -f Status0a
-;off;off;off;0
pi@raspberrypi:~ $ ebusctl r -f Status
0;off;-;0
Oder ist meine händische Anfrage falsch?
Zitat von: theotherhalf am 27 Dezember 2018, 23:31:01
mc Status0a = 35.00;open;on;off;39
mc Status = 39;off;33.19;22
Frage ich dann aber so ab, sind die Register leer.
pi@raspberrypi:~ $ ebusctl r -f Status0a
-;off;off;off;0
da fehlt die Angabe der circuit mit "-c mc".
Zitat von: rellla am 27 Dezember 2018, 17:57:30
Hallo,
in der csv sind auf jeden Fall messages definiert, die auch bei deinem grab log auftauchen. Diese z.B. https://github.com/john30/ebusd-configuration/blob/master/ebusd-1.x.x/ochsner/22102.csv#L30
Starte ein grab, browse durch das menü deines controllers und dann sollten 1015.... / ... messages auftauchen, die dekodiert werden - falls definiert.
Gruß Andreas
Sorry, wenn ich nachfrage.
Was soll mit dieser csv getan werden?
Ich habe einzelne Werte zum Testen in die broadcast.csv aufgenommen, aber es werden trotzdem keine weiteren Werte erkannt. In dem File steht auch OTE 2, dies trifft bei mir nicht zu, es ist OTE 3.
Gruß
Rene
Hallo,
kopiere die 2 csv dateien von https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x/ochsner nach z.B. /etc/ebusd und starte ebusd mit --configpath=/etc/ebusd
Dann schau, ob er was findet. Starte vorher auch mal mit --checkconfig und --dumpconfig , siehe https://github.com/john30/ebusd/wiki/2.-Run
Ich weiß nicht, wie kompatibel die csv der 1.* versionen mit der aktuellen sind, evtl. musst du die noch anpassen. Jedenfalls sind ein ganzer Schwung messages identifiziert. OTE2 oder OTE3 sollte keine Rolle spielen. Lies dich einfach mal in die message definition bzw. den Aufbau der HEX codes ein, dann wirst du feststellen, dass in deinem log Nachrichten auftauchen, für die es bereits eine definition gibt. Die oben angegebene z.B. ist der status, der bei dir mit 0100, also 1 zurückgegeben wird, was vermutlich "Heizbetrieb" entspricht.
Gruß
Andreas
@rellla
Danke
Zitat von: Reinhart am 23 September 2015, 10:29:43
@jojo11
Das Logfile solltest du in /etc/logrotate.d/ebusd konfigurieren. Ich habe es so eingestellt.
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
hier wird alle 7 Tage rotiert und komprimiert, das aktuelle ist normal lesbar. ZB: kannst rotate auf 2 stellen, wenn dir die Anzahl der Files zuviel ist.
Da sieht dann wie im Bild aus und wächst NICHT mehr!
LG
Reinhart
Hallo,
bin beim stöbern über diesen Post gestolpert.
Ist das unter den neuen Versionen von ebusd (3.2 bzw. 3.3) nicht mehr so?
Bei mir gibt es unter /etc/logrotate.d/ keine ebusd, wo ich das festlegen kann.
doch, das ist immer noch so!
John hat das alles im Git so hinterlegt. Wenn du selber compiliert hast, dann siehst du unter "/home/pi/ebusd/contrib/etc/logrotate.d" die Datei, welche mit "make install" (make_debian.sh) ja auch installiert wird.
cp contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Du kannst sie aber auch selber dort anlegen.
/var/log/ebusd*.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
postrotate
/usr/bin/killall -HUP ebusd
endscript
}
LG
Hallo,
bekomme nun dank Eurer Hilfe mehr Werte ausgelesen.
Wie kann ich den Fehler bei heatpump cycles beheben?
Gruß
René
ebusctl find -d
heatpump cycles = 80;1;1d;00;1;1320 (ERR: invalid position for 01150621047d860002 / 0a50811d00010028050000)
heatpump mode = 53;1;00;00;255;0;Heizbetrieb
heatpump volume1 = 130;10;0d;34;1000;0;18.2
heatpump volume2 = 218;10;0d;34;1000;0;23.3
master data1 = 44.699;-;0;1;0;1;0;0;0;40.000
master data2 = 65.000;60.000;-100;0;0
master datetime = 6.699;12:19:29;30.12.2018
temperature buffer = 96;0;0d;02;1000;0;44.5
temperature outside = 0;0;0d;02;500;-500;6.6
temperature water = 4;0;0d;02;1000;0;49.7
Zitat von: PavelCoast am 30 Dezember 2018, 12:19:00
Wie kann ich den Fehler bei heatpump cycles beheben?
ebusctl find -d
heatpump cycles = 80;1;1d;00;1;1320 (ERR: invalid position for 01150621047d860002 / 0a50811d00010028050000)
der Wert "0000" passt nicht zum Datentyp HCD des Feldes "cycles". Das müssten eigentlich 4 Bytes sein, aber die Antwort enthält nur 2. Also ist die Definition zumindest für Dein Device nicht korrekt.
Jetzt könnte man mutmaßen, dass es bei Deinem einfach eine verkürzte Version ist und cycles in den _templates von HCD auf HCD:2 umdefinieren. Ob das dann für andere Devices noch passt, ist fraglich.
Zitat von: Reinhart am 30 Dezember 2018, 06:09:29
doch, das ist immer noch so!
John hat das alles im Git so hinterlegt. Wenn du selber compiliert hast, dann siehst du unter "/home/pi/ebusd/contrib/etc/logrotate.d" die Datei, welche mit "make install" (make_debian.sh) ja auch installiert wird.
cp contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Du kannst sie aber auch selber dort anlegen.
/var/log/ebusd*.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
postrotate
/usr/bin/killall -HUP ebusd
endscript
}
LG
Super, danke für deine Hilfe!
Allerdings musste ich deine copy-Zeile noch wie folgt ergänzen, sonst ging es nicht.
Deine Befehlszeile brachtebei mir immer einen Fehler.
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/Hinter cp musste ich "ebusd" vor contrib noch einfügen.
Dann hat er das kopieren durchgeführt.
Gruß Peter
ja ist klar, weil bei "make install" man ja im Verzeichnis /home/pi/ebusd" steht!
Hauptsache es klappt jetzt!
LG
Hallo Rene,
ich gehe davon aus, dass bei dir ein TEM-Controller verbaut ist? Dann kannst du mal versuchen, in der templates.csv die command definition gegen https://github.com/rellla/ebusd-configuration/blob/for_upstream/ebusd-2.1.x/de/tem/_templates.csv#L11 auszutauschen.
Bei mir (Bartl/TEM) wird dann der TEM-Code des jeweiligen Parameters ausgegeben, wie er im Display bzw. in der Anleitung aufgeführt ist. Vorausgesetzt natürlich bei dir (Ochsner) gibts das auch. Das würde dir die Zuordnung erleichtern.
Ansonsten solltest du das hier nochmal durchstöbern: https://github.com/john30/ebusd-configuration/issues/4
Gruß
Andreas
Zitat von: Peter0961 am 30 Dezember 2018, 15:53:53
Super, danke für deine Hilfe!
Allerdings musste ich deine copy-Zeile noch wie folgt ergänzen, sonst ging es nicht.
Deine Befehlszeile brachtebei mir immer einen Fehler.
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/
Hinter cp musste ich "ebusd" vor contrib noch einfügen.
Dann hat er das kopieren durchgeführt.
Gruß Peter
Hallo,
ich habe heute einmal wieder nach den Log-Dateien geschaut,
da ich ja letzte Woche die ebusd nach /etc/logrotate.d kopiert habe.
Da scheint aber irgendetwas nicht zu funktionieren.
Es gibt nur die aktuelle ebusd.log im Ordner /var/log.
Es wurden keine Backups angelegt in den letzten Tagen.
Kopiert habe ich die ebusd mit folgendem Befehl:
cp ebusd/contrib/etc/logrotate.d/ebusd $RELEASE/etc/logrotate.d/Das hat auch geklappt, die Datei ist jetzt im Ordner /var/log und sieht aus wie folgt:
/var/log/ebusd*.log {
rotate 7
size 1M
copytruncate
compress
missingok
notifempty
daily
postrotate
/usr/bin/killall -HUP ebusd
endscript
}Wenn ich das script versuche mit admin-Berechtigung manuell auzuführen,
bekomme ich folgende Fehlermeldung:
2019-01-05 00:43:25.601 [main error] invalid configpath without scanconfigIch weiß aber nicht woran es liegt!
ah, nicht versuchen den ebusd aufrufen!
Du kannst Logrotate so testen.
sudo logrotate /etc/logrotate.d -v
und checke einmal die Rechte von der Logrotate config "ebusd", die sollte 644 sein!
sudo chmod 644 /etc/logrotate.d/ebusd
rotating pattern: /var/log/ebusd*.log after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/ebusd.log
Now: 2019-01-05 21:18
Last rotated at 2018-12-03 06:25
log needs rotating
rotating log /var/log/ebusd.log, log->rotateCount is 7
dateext suffix '-20190105'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/ebusd.log.7.gz to /var/log/ebusd.log.8.gz (rotatecount 7, logs tart 1, i 7),
renaming /var/log/ebusd.log.6.gz to /var/log/ebusd.log.7.gz (rotatecount 7, logs tart 1, i 6),
renaming /var/log/ebusd.log.5.gz to /var/log/ebusd.log.6.gz (rotatecount 7, logs tart 1, i 5),
renaming /var/log/ebusd.log.4.gz to /var/log/ebusd.log.5.gz (rotatecount 7, logs tart 1, i 4),
renaming /var/log/ebusd.log.3.gz to /var/log/ebusd.log.4.gz (rotatecount 7, logs tart 1, i 3),
renaming /var/log/ebusd.log.2.gz to /var/log/ebusd.log.3.gz (rotatecount 7, logs tart 1, i 2),
renaming /var/log/ebusd.log.1.gz to /var/log/ebusd.log.2.gz (rotatecount 7, logs tart 1, i 1),
renaming /var/log/ebusd.log.0.gz to /var/log/ebusd.log.1.gz (rotatecount 7, logs tart 1, i 0),
old log /var/log/ebusd.log.0.gz does not exist
copying /var/log/ebusd.log to /var/log/ebusd.log.1
truncating /var/log/ebusd.log
running postrotate script
compressing log with: /bin/gzip
so in etwa sollte das Ergebnis aussehen!
LG
Zitat von: Reinhart am 05 Januar 2019, 21:25:26
ah, nicht versuchen den ebusd aufrufen!
Du kannst Logrotate so testen.
sudo logrotate /etc/logrotate.d -v
und checke einmal die Rechte von der Logrotate config "ebusd", die sollte 644 sein!
sudo chmod 644 /etc/logrotate.d/ebusd
rotating pattern: /var/log/ebusd*.log after 1 days (7 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/ebusd.log
Now: 2019-01-05 21:18
Last rotated at 2018-12-03 06:25
log needs rotating
rotating log /var/log/ebusd.log, log->rotateCount is 7
dateext suffix '-20190105'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
renaming /var/log/ebusd.log.7.gz to /var/log/ebusd.log.8.gz (rotatecount 7, logs tart 1, i 7),
renaming /var/log/ebusd.log.6.gz to /var/log/ebusd.log.7.gz (rotatecount 7, logs tart 1, i 6),
renaming /var/log/ebusd.log.5.gz to /var/log/ebusd.log.6.gz (rotatecount 7, logs tart 1, i 5),
renaming /var/log/ebusd.log.4.gz to /var/log/ebusd.log.5.gz (rotatecount 7, logs tart 1, i 4),
renaming /var/log/ebusd.log.3.gz to /var/log/ebusd.log.4.gz (rotatecount 7, logs tart 1, i 3),
renaming /var/log/ebusd.log.2.gz to /var/log/ebusd.log.3.gz (rotatecount 7, logs tart 1, i 2),
renaming /var/log/ebusd.log.1.gz to /var/log/ebusd.log.2.gz (rotatecount 7, logs tart 1, i 1),
renaming /var/log/ebusd.log.0.gz to /var/log/ebusd.log.1.gz (rotatecount 7, logs tart 1, i 0),
old log /var/log/ebusd.log.0.gz does not exist
copying /var/log/ebusd.log to /var/log/ebusd.log.1
truncating /var/log/ebusd.log
running postrotate script
compressing log with: /bin/gzip
so in etwa sollte das Ergebnis aussehen!
LG
Hallo Reinhart,
danke für deine super Hilfe!
Das mit den Rechten scheint es gewesen zu sein.
Nach ausführen von:
sudo logrotate /etc/logrotate.d -vzeigt er mir jetzt bei ebusd keinen Fehler mehr an.
Aber wie kann das sein.
Ich habe mich vorab sehr viel im Forum eingelesen und auch ins Wiki von John geschaut,
aber über ein Problem mit den Rechten und das da was geändert werden muss, habe ich nichts gelesen.
Auch das man den ebusd erst in das Verzeichnis logrotate.d kopieren muss, damit das funktioniert war mir neu.
Ich habe mich eigentlich genau an die Anleitungen gehalten,
stoße aber immer wieder auf solche kleinen Hürden, wo es dann stockt.
Gruß Peter
normalerweise braucht man das auch nicht durchführen, weil das in den Installationspaketen ja alles enthalten ist, egal ob du selber compilierst oder das Installationsfile aus dem Git holst. Eventuell wurde was nicht mit sudo ausgeführt, dann könnte sowas schon passieren.
Hauptsache es funktioniert jetzt.
LG
Hallo Zusammen,
gestern ist mein ebus adapter angekommen (@John30: Vielen Dank). Ich habe ihn angeschlossen und ebusd hat direkt Daten geliefert. 8)
Leider können nicht alle Vaillant Geräte ausgelesen werden:
Ich bekomme folgende Fehlermeldung:
2019-01-09 21:11:49.474 [update error] unable to parse scan-read scan.76 id from 3176b5090124 / 00: ERR: invalid position
2019-01-09 21:11:49.585 [update error] unable to parse scan-read scan.76 id from 3176b5090125 / 00: ERR: invalid position
2019-01-09 21:11:49.697 [update error] unable to parse scan-read scan.76 id from 3176b5090126 / 00: ERR: invalid position
2019-01-09 21:11:49.812 [update error] unable to parse scan-read scan.76 id from 3176b5090127 / 00: ERR: invalid position
2019-01-09 21:11:49.812 [main error] scan config 76: ERR: invalid position
Ein paar Infos:
root@d1609b55823a:/tmp# ebusctl info
version: ebusd 3.3.v3.3
signal: acquired
symbol rate: 23
max symbol rate: 121
min arbitration micros: 626
max arbitration micros: 938
min symbol latency: 4
max symbol latency: 5
reconnects: 0
masters: 4
messages: 465
conditional: 0
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0211;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0211;HW=0403"
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103"
Ich habe schon folgende Sachen ausprobiert:
Script https://raw.githubusercontent.com/john30/ebusd/master/contrib/scripts/readall.sh ausgeführt. Die ganzen Werte für die Vaillant 700 werden ausgelesen und enige Werte von der hmu. Bei ein paar der Werten von der HMU bekomme ich wieder den Fehlermeldung:
...
hmu SetMode = auto;0.0;-;-;1;1;1;0;0;0
hmu State = 0;384;24;ready
hmu Status = ERR: invalid position in decode
hmu Status01 = 22.0;21.0;1.312;-;36.5;off
hmu Status02 = auto;40;65.5;40;65.5
hmu Status16 = ERR: invalid position in decode
hmu YieldThisYear1 = ERR: invalid position in decode
hmu YieldThisYear10 = ERR: invalid position in decode
hmu YieldThisYear11 = ERR: invalid position in decode
hmu YieldThisYear12 = ERR: invalid position in decode
hmu YieldThisYear2 =
hmu YieldThisYear3 = ERR: invalid position in decode
...
Der ebusd läuft mit folgenden Parametern "ebusd --scanconfig=full -d /dev/ttyUSB0 --latency=100000 --receivetimeout=100000 --enablehex"
Kann sich jemand vielleicht erklären, warum ich diese Fehlermeldungen bekomme?
ps. Ich habe die Vaillant Wärmepumpe Flexotherm Compact VWF 58/4
Zitat von: iglo36 am 09 Januar 2019, 22:29:12
Leider können nicht alle Vaillant Geräte ausgelesen werden:
stimmt nicht ganz, lediglich die 76 antwortet nicht wie erwartet auf den Vaillant spezifischen Produkt-Scan. Dennoch erscheint die HW/SW ID im info Ergebnis. Also das ist ok.
Zitat von: iglo36 am 09 Januar 2019, 22:29:12
Bei ein paar der Werten von der HMU bekomme ich wieder den Fehlermeldung:
...
hmu Status = ERR: invalid position in decode
...
das beudeutet im Endeffekt, dass für deine HMU ein paar Nachrichtendefinitionen nicht ganz stimmen, vermutlich weil diese eine neuere HW oder SW hat.
D.h. man müsste jetzt für diese Variante eine angepasste Version der 08.hmu.csv zusammenstricken. Mit heißer Nadel versteht sicht :)
Zitat von: john30 am 10 Januar 2019, 08:24:34
D.h. man müsste jetzt für diese Variante eine angepasste Version der 08.hmu.csv zusammenstricken. Mit heißer Nadel versteht sicht :)
O.k. wie kann ich das machen?
Ich hätte auch so ein Internetmodul VR 920. Dieses läuft auch über den ebus und schickt die ganzen Daten zu Vaillant. (Aus dem Grunde hatte ich es nur kurz in Betrieb). Vielleicht könnte damit die ganze Komunikation aufgezeichnet werden.
Das hört sich doch gut an!
Genau so habe ich damals die meisten Sachen der VRC700 "entdeckt": mit der App bei angeschlossenem VR900 alles mögliche abgefragt und geändert, dabei hat Ebusd dann alle möglichen "unknown MS" im Log gemeldet. Mit viel Handarbeit findet man dann im günstigsten Fall, welche Meldung was beinhaltet.
Aber in meinem Fall spricht die VR900 fast ausschließlich mit der VRC700, den Brenner selbst (08) fragt sie soweit ich mich erinnere nur nach dem Fehlerzustand ab.
Unabhängig davon müsste ja aber deine Steuerung mit der HMU kommunizieren.
Darüberhinaus gibt es natürlich Werte, die weder die Steuerung noch das Internetmodul interessieren, hier hilft dann nur schnüffeln mit dem Script (https://github.com/john30/ebusd/blob/master/contrib/scripts/readallvaillantregisters.sh) von John. Dieses ist so natürlich nur für b509/0d-Abfragen ausgelegt, evtl. nutzt Vaillant hier (wie bei der VRC700) auch andere Nachrichten, dann musst du das im Script anpassen.
Hallo Zusammen,
als begeisterter Leser dieses Forums, komme ich leider nicht mehr weiter und muss auch mal eine Frage stellen:
Ich versuche meine Vaillant Heizung mit calormatic 430 auszulesen, habe die 1.6 Platine, einen FTDI32 Adapter sowie eine Raspberry wo meine ebusd SW drauf läuft, ich bekomme leider im var/log/ebusd Log nur die Meldungen
2019-01-18 16:36:06.597 [update notice] received unknown MS cmd: 1008b5110101 / 095e545000ff660000ff
2019-01-18 16:36:08.599 [update notice] received unknown BC cmd: 10feb5160301500 0
2019-01-18 16:36:12.690 [update notice] received unknown MS cmd: 1008b5100900006 378ffff00ff00 / 0101
2019-01-18 16:36:16.746 [update notice] received unknown MS cmd: 1008b5110101 / 09584e5000ff660000ff
2019-01-18 16:36:18.688 [update notice] received unknown MS cmd: 1008b5110102 / 05033c96506e
2019-01-18 16:36:22.739 [update notice] received unknown MS cmd: 1008b5100900006 378ffff00ff00 / 0101
2019-01-18 16:36:26.788 [update notice] received unknown MS cmd: 1008b5110101 / 09524a5000ff660000ff
2019-01-18 16:36:28.845 [update notice] received unknown MS cmd: 1008b5040100 / 0a03303616180105195000
2019-01-18 16:36:29.072 [update notice] received unknown BC cmd: 10feb505020400
2019-01-18 16:36:32.887 [update notice] received unknown MS cmd: 1008b5100900006 378ffff00ff00 / 0101
2019-01-18 16:36:36.927 [update notice] received unknown MS cmd: 1008b5110101 / 094e465000ff660000ff
*****************************************************************************
mit ebusctl info
root@raspberrypi:/var/log# ebusctl info
version: ebusd 3.3.v3.3-4-g212b22d
update check: OK, broadcast.csv: different version available
signal: acquired
symbol rate: 41
max symbol rate: 60
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
***************************************************************************************
Ergebnis :ebusctl scan result
done (mehr steht da leider nicht))
*****************************************************************************************
mir fehlt da irgendwie die Vaillant Auflösung, hier im Forum sehen die Ergebnisse immer anders aus, ich denke ich habe irgendwie ein Problem mit den csv's, die habe ich aber ordnungsgemäß runtergladen und verteilt.
also auch erst auf raspi entpackt usw.
Bin total ratlos
Vielen dank im vorraus
Bitte in Zukunft solche Logs in einem Code Tag ( # Symbol ) einfügen dann sieht man es besser!
Bei dir werden absolut keine CSV geladen und die Calormatic 430 auf Adresse 15 fehlt komplett. Der Rest sieht ja schon gut aus.
Poste doch einmal deine config ( etc/default/ebusd )
Ich habe dieselbe Umgebung wie du und da sieht es so aus.
pi@raspberrypi:~ $ ebusctl i
version: ebusd 3.3.v3.3-5-g2f6b2bb
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 145
min arbitration micros: 31
max arbitration micros: 5390
min symbol latency: 1
max symbol latency: 15
reconnects: 0
masters: 4
messages: 450
conditional: 16
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Ich bin mir nicht ganz sicher ob das Poti schon optimal ist, eventuell ganz ganz leicht oder rechts probieren da ja der Rest schon kommt. Die V 1.6 hatte ja noch ein paar Probleme bei der Abstimmung.
LG
Hallo Reinhart,
danke für die schnelle Hilfe :)
hier das file, das mit dem Poti probier ich gleich mal aus
root@raspberrypi:/etc/default# more ebusd
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/l
og/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/l
og/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/l
og/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Zitat von: Sunnyvale am 18 Januar 2019, 18:25:30
root@raspberrypi:/etc/default# more ebusd
...
EBUSD_OPTS="--scanconfig"
...
mit dieser Einstellung bezieht ebusd die configs vom webservice unter ebusd.eu, d.h. wenn Dein Rechner z.B. keine Internetverbindung hat, dann klappt das natürlich nicht.
für die lokalen CSVs einfach noch " -c /etc/ebusd" hinter scanconfig hängen.
@Sunnyvale
wie John30 schon geschrieben hat, du brauchst dann am Poti nichts mehr einstellen, weil du ja minimale Konfiguration eingestellt hast. Entweder du konfigurierst die Config, oder füge wenigsten den Eintrag hinzu den John gepostet hat, dann solltest du die CSV laden können.
LG
:) :) Danke für die schnellen Anworten
root@raspberrypi:~# ps -ef |grep ebusd
root 3870 1542 0 17:56 pts/1 00:00:00 tail -f ebusd.log
root 5796 1 0 19:19 ? 00:00:01 /usr/bin/ebusd --scanconfig -c /etc/ebusd
root 6021 5923 0 19:26 pts/3 00:00:00 grep ebusd
habe danach nochmal neu gestartet leider immer noch
2019-01-18 19:30:22.495 [update notice] received unknown MS cmd: 1008b5100900006978ffff00ff00 / 0101
2019-01-18 19:30:26.535 [update notice] received unknown MS cmd: 1008b5110101 / 096c62a0fcff680000ff
2019-01-18 19:30:28.547 [update notice] received unknown BC cmd: 10feb516080028301918010519
2019-01-18 19:30:28.802 [update notice] received unknown MS cmd: 1008b512020064 / 00
2019-01-18 19:30:32.620 [update notice] received unknown MS cmd: 1008b5100900006978ffff00ff00 / 0101
2019-01-18 19:30:36.619 [update notice] received unknown MS cmd: 1008b5110101 / 09645c50fcff680000ff
2019-01-18 19:30:38.674 [update notice] received unknown MS cmd: 1008b5040100 / 0a034030191801051950fc
2019-01-18 19:30:38.947 [update notice] received unknown MS cmd: 1008b5110102 / 05033c96506e
2019-01-18 19:30:42.709 [update notice] received unknown MS cmd: 1008b5100900006a78ffff00ff00 / 0101
Zitat von: Sunnyvale am 18 Januar 2019, 19:31:37
habe danach nochmal neu gestartet leider immer noch
dann wird dein interface wohl nicht auf den Bus schreiben können...
Habe alle csv's auch noch mal unter /etc/ebusd/ direkt kopiert
root@raspberrypi:/etc/ebusd# ls -al
insgesamt 2936
drwxr-xr-x 4 root root 4096 Jan 18 00:12 .
drwxr-xr-x 114 root root 4096 Jan 9 16:41 ..
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vd2.csv
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vd3.csv
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vd4.csv
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vd6.csv
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vl8.csv
-rw-r--r-- 1 root root 5833 Jan 18 00:12 05.vl9.csv
-rw-r--r-- 1 root root 5350 Jan 18 00:12 06.pms.csv
-rw-r--r-- 1 root root 3749 Jan 18 00:12 08.bai.csv
-rw-r--r-- 1 root root 28639 Jan 18 00:12 08.ehp.csv
-rw-r--r-- 1 root root 2753 Jan 18 00:12 08.hmu.csv
-rw-r--r-- 1 root root 5656 Jan 18 00:12 0a.pmw.hwc.csv
-rw-r--r-- 1 root root 4822 Jan 18 00:12 15.140.csv
-rw-r--r-- 1 root root 4822 Jan 18 00:12 15.350.csv
-rw-r--r-- 1 root root 4822 Jan 18 00:12 15.360.csv
-rw-r--r-- 1 root root 4822 Jan 18 00:12 15.36p.csv
-rw-r--r-- 1 root root 9886 Jan 18 00:12 15.370.csv
-rw-r--r-- 1 root root 8443 Jan 18 00:12 15.392.csv
-rw-r--r-- 1 root root 4822 Jan 18 00:12 15.400.csv
-rw-r--r-- 1 root root 15460 Jan 18 00:12 15.430.csv
-rw-r--r-- 1 root root 17160 Jan 18 00:12 15.470.csv
-rw-r--r-- 1 root root 23682 Jan 18 00:12 15.700.csv
-rw-r--r-- 1 root root 3949 Jan 18 00:12 15.e7f.csv
-rw-r--r-- 1 root root 9945 Jan 18 00:12 15.f37.csv
-rw-r--r-- 1 root root 14715 Jan 18 00:12 15.f43.csv
-rw-r--r-- 1 root root 16734 Jan 18 00:12 15.f47.csv
-rw-r--r-- 1 root root 2986 Jan 18 00:12 15.heb.csv
-rw-r--r-- 1 root root 2986 Jan 18 00:12 15.hep.csv
-rw-r--r-- 1 root root 2986 Jan 18 00:12 15.sdr_p.csv
-rw-r--r-- 1 root root 13608 Jan 18 00:12 15.ui.csv
-rw-r--r-- 1 root root 5908 Jan 18 00:12 15.uih.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 1c.rcc.4.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 1c.v81.4.csv
-rw-r--r-- 1 root root 539 Jan 18 00:12 23.ehp.cc.csv
-rw-r--r-- 1 root root 885 Jan 18 00:12 23.solsy.cc.csv
-rw-r--r-- 1 root root 886 Jan 18 00:12 23.vr630.cc.csv
-rwxr-xr-x 1 root root 913 Jan 18 00:12 23.zeo.cc.csv
-rw-r--r-- 1 root root 2196 Jan 18 00:12 25.ehp.hwc.csv
-rw-r--r-- 1 root root 2906 Jan 18 00:12 25.solsy.hwc.csv
-rw-r--r-- 1 root root 1944 Jan 18 00:12 25.vr630.hwc.csv
-rwxr-xr-x 1 root root 851 Jan 18 00:12 25.zeo.hwc.csv
-rw-r--r-- 1 root root 4203 Jan 18 00:12 26.solsy.hc.csv
-rw-r--r-- 1 root root 2187 Jan 18 00:12 26.vr630.hc.csv
-rw-r--r-- 1 root root 2447 Jan 18 00:12 26.vr_71.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 35.rcc.1.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 35.v81.1.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 3c.rcc.5.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 3c.v81.5.csv
-rw-r--r-- 1 root root 6424 Jan 18 00:12 50.ehp.mc.csv
-rw-r--r-- 1 root root 3794 Jan 18 00:12 50.solsy.mc.csv
-rw-r--r-- 1 root root 7583 Jan 18 00:12 50.v61.mc.csv
-rw-r--r-- 1 root root 2403 Jan 18 00:12 50.vr630.mc.csv
-rwxr-xr-x 1 root root 1599 Jan 18 00:12 50.zeo.mc.csv
-rw-r--r-- 1 root root 2446 Jan 18 00:12 51.vr630.mc.3.csv
-rw-r--r-- 1 root root 5359 Jan 18 00:12 52.mc2.mc.4.csv
-rw-r--r-- 1 root root 1349 Jan 18 00:12 52.vr_70.csv
-rw-r--r-- 1 root root 4957 Jan 18 00:12 53.mc2.mc.5.csv
-rw-r--r-- 1 root root 5359 Jan 18 00:12 54.mc2.mc.6.csv
-rw-r--r-- 1 root root 4957 Jan 18 00:12 55.mc2.mc.7.csv
-rw-r--r-- 1 root root 515 Jan 18 00:12 64.v65.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 75.rcc.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 75.v81.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 7c.rcc.6.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 7c.v81.6.csv
-rwxr-xr-x 1 root root 15147 Jan 18 00:12 84.zeo.csv
-rw-r--r-- 1 root root 3309 Jan 18 00:12 a0.sol.hwc.csv
-rw-r--r-- 1 root root 661 Jan 18 00:12 a1.sol.cc.csv
-rw-r--r-- 1 root root 14212 Jan 18 00:12 bai.0010002315.inc
-rw-r--r-- 1 root root 16921 Jan 18 00:12 bai.0010002465.inc
-rw-r--r-- 1 root root 16142 Jan 18 00:12 bai.0010003857.inc
-rw-r--r-- 1 root root 16494 Jan 18 00:12 bai.0010003886.inc
-rw-r--r-- 1 root root 22824 Jan 18 00:12 bai.0010004121.inc
-rw-r--r-- 1 root root 17089 Jan 18 00:12 bai.0010004150.inc
-rw-r--r-- 1 root root 17150 Jan 18 00:12 bai.0010005400.inc
-rw-r--r-- 1 root root 18344 Jan 18 00:12 bai.0010006101.inc
-rw-r--r-- 1 root root 16327 Jan 18 00:12 bai.0010006341.inc
-rw-r--r-- 1 root root 17863 Jan 18 00:12 bai.0010007508.inc
-rw-r--r-- 1 root root 17872 Jan 18 00:12 bai.0010010674.inc
-rw-r--r-- 1 root root 16969 Jan 18 00:12 bai.0010015600.inc
-rw-r--r-- 1 root root 5547 Jan 18 00:12 bai.0020066007.inc
-rw-r--r-- 1 root root 17001 Jan 18 00:12 bai.308523.inc
-rw-r--r-- 1 root root 1253 Jan 18 16:24 broadcast.csv
-rw-r--r-- 1 root root 6658 Jan 18 00:12 e0.omu.csv
-rw-r--r-- 1 root root 6658 Jan 18 00:12 e1.omu.1.csv
drwxr-xr-x 8 root root 4096 Dez 25 12:26 ebusd-configuration-master
-rw-r--r-- 1 root root 2030889 Jan 17 22:13 ebusd-configuration-master.zip
-rw-r--r-- 1 root root 5665 Jan 18 00:12 ec.sol.sc.csv
-rw-r--r-- 1 root root 6001 Jan 18 00:12 ec.solsy.sc.csv
-rwxr-xr-x 1 root root 1280 Jan 18 00:12 ec.zeo.sc.csv
-rw-r--r-- 1 root root 5350 Jan 18 00:12 ed.pms.sc.csv
-rw-r--r-- 1 root root 525 Jan 18 00:12 errors.inc
-rw-r--r-- 1 root root 713 Jan 18 00:12 f5.rcc.3.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 f5.v81.3.csv
-rw-r--r-- 1 root root 713 Jan 18 00:12 fc.rcc.7.csv
-rw-r--r-- 1 root root 2601 Jan 18 00:12 fc.v81.7.csv
-rw-r--r-- 1 root root 693 Jan 18 00:12 general.csv
-rw-r--r-- 1 root root 1010 Jan 18 00:12 hcmode.inc
-rw-r--r-- 1 root root 883 Jan 18 00:12 hwcmode.inc
-rw-r--r-- 1 root root 404 Jan 18 00:12 iotest620.inc
-rw-r--r-- 1 root root 407 Jan 18 00:12 iotest630.inc
-rw-r--r-- 1 root root 307 Jan 18 00:12 iotestact.inc
-rw-r--r-- 1 root root 348 Jan 18 00:12 iotestbmc.inc
-rw-r--r-- 1 root root 313 Jan 18 00:12 iotestbsol.inc
-rw-r--r-- 1 root root 423 Jan 18 00:12 iotesthp.inc
-rw-r--r-- 1 root root 1435 Jan 18 00:12 mcmode.inc
-rw-r--r-- 1 root root 754 Jan 18 16:24 memory.csv
-rw-r--r-- 1 root root 316 Jan 18 00:12 quick.inc
-rw-r--r-- 1 root root 238 Jan 18 00:12 roomtempoffset.inc
-rw-r--r-- 1 root root 792 Jan 18 00:12 scan.csv
-rw-r--r-- 1 root root 530 Jan 18 00:12 service.inc
-rw-r--r-- 1 root root 1228 Jan 18 16:24 _templates.csv
-rw-r--r-- 1 root root 727 Jan 18 00:12 tempsetpoints.inc
-rw-r--r-- 1 root root 647 Jan 18 00:12 timercc.inc
-rw-r--r-- 1 root root 677 Jan 18 00:12 timercool.inc
-rw-r--r-- 1 root root 633 Jan 18 00:12 timerhc.inc
-rw-r--r-- 1 root root 647 Jan 18 00:12 timerhwc.inc
-rw-r--r-- 1 root root 979 Jan 18 00:12 timer.inc
-rw-r--r-- 1 root root 667 Jan 18 00:12 timertariff.inc
drwxr-xr-x 2 root root 4096 Jan 17 22:57 vaillant
-rw-r--r-- 1 root root 606 Jan 18 00:12 yield3d43.inc
-rw-r--r-- 1 root root 606 Jan 18 00:12 yield3f40.inc
-rw-r--r-- 1 root root 606 Jan 18 00:12 yield4445.inc
-rw-r--r-- 1 root root 606 Jan 18 00:12 yield8485.inc
-rw-r--r-- 1 root root 630 Jan 18 00:12 yield8485r.inc
Hi John,
du meinst ich müsste die Platine noch mal checken ?
VG
Zitat von: Sunnyvale am 18 Januar 2019, 19:42:31
du meinst ich müsste die Platine noch mal checken ?
ja ich denke schon. Du kannst mal im ebusd.log schauen, was passiert wenn ebusd versucht auf den Bus zu schreiben. Oder gleich mit "ebusctl raw" schauen, was an Bytes erfolgreich ausgehend transportiert wird. das würde dann mit ">" protokolliert werden.
Moin,
anscheinend schreibt er nicht , ich habe ihn noch mal neu gestartet, bekomme aber jetzt eine neue Fehlermeldung bezüglich csv error und TEMPSENSOR das hatte ich vorher noch gar nicht
root@raspberrypi:/var/log# more ebusd.log
2019-01-19 10:18:18.562 [main notice] ebusd 3.3.v3.3-4-g212b22d started with auto scan
2019-01-19 10:18:18.566 [main error] error reading config files: ERR: element not found, last error: ec.sol.sc.csv:7: ERR:
element not found, field type TEMPSENSOR in field 0
2019-01-19 10:18:18.569 [bus notice] bus started with own address 31/36
2019-01-19 10:18:18.573 [bus notice] signal acquired
2019-01-19 10:18:21.632 [bus notice] new master 10, master count 2
2019-01-19 10:18:21.668 [bus notice] new master 03, master count 3
2019-01-19 10:18:21.668 [update notice] received unknown MS cmd: 1008b5100900006a78ffff00ff00 / 0101
2019-01-19 10:18:27.715 [update notice] received unknown MS cmd: 1008b5110101 / 099e8850fcff680400ff
2019-01-19 10:18:28.585 [main error] scan config 08: ERR: read timeout
2019-01-19 10:18:29.769 [update notice] received unknown BC cmd: 10feb516080032181019010619
2019-01-19 10:18:30.026 [update notice] received unknown MS cmd: 1008b512020064 / 00
VG
Ich hatte die csv's vom ebusd 2.1.x genommen,liegt es vielleicht daran ? Habe ja den ebusd 3.3 laufen
kannst du mal ein Foto von der Oberseite und Unterseite hier posten?
Eventuell erkennt man was nicht passt!
Es hat ja den Anschein das mit dem Sender was nicht stimmt, deshalb gibt es auch keine Anzeige der min/max Arbitration. Wenn du dich mit der Elektronik etwas auskennst, kannst ja den Fehler laut Messplan selber leicht finden und gerade bei der Sendeeinheit ist es nicht so kompliziert. Optokoppler, Sendetransistor Zenerdiode, hier irgendwo dazwischen liegt der Fehler.
Sieht man den wenigstens am Uart die Tx-Led kurz nach dem Starten des Dämons (so etwa 15-30 Sekunden) flackern? Das ist der Augenblick wo der ebusd den Scanvorgang startet.
PS: das mit den CSV ist jetzt sekundär.
LG
moin moin,
anbei mal ein paar Fotos
VG
Zum abgleichen hatte ich eine LED zwischen GND und RXD gesetzt , damit habe ich das Poti eingestellt und auch jetzt flackert die RXD LED am FTDI schön
sieht soweit gut aus und es ist soweit kein Fehler auf der Platine erkennbar.
Da wird dir leider eine Messung nicht ausbleiben, es geht ohnehin nur um den Sendeweg!
Wenn alle Stricke reißen, noch haben wir Platinen der V2.2.
LG
Reinhart
Danke für die Unterstützung, dann werde ich nochmal alles durchmessen, hätte aber die Empfängerseite nicht auch alleine laufen müssen ? Zumal ich ja irgendwie Telegramme vom ebus erhalte, oder sehe ich da was komplett falsch ? Hast du bei deiner Installation auch die csv's vom ebusd 2.1x genommen ?
VG
Dein Adapter kann alles empfangen, das sind in deinem Fall alle Broadcast. Beim Scanvorgang muss aber sendeseitig die Anfrage abgesetzt werden und das geht schief.
Als Tipp zur Fehlersuche, tausche einmal die beiden Optokoppler gegeneinander aus, wenn das nichts bringt könntest die Zenerdiode tauschen sofern du noch eine hast. Der Transistor wird eher selten defekt.
Und ja, die V2.1 CSV sollten funktionieren, das ist aber jetzt nicht dein Problem.
LG
Reinhart
Hallo zusammen,
ich habe das Problem, dass ich Hc1ActualFlowTempDesired aus 15.470.csv immer mal wieder den Wert 90 lese. So wie ich das beobachtet habe ist das immer beim ab tauen der Wärmepumpe (Vaillant Arotherm).
Jetzt war meine Idee, Werte >=90 direkt über Conditions zu filtern, und zwar so:
#*[CONDITIONNAME],MESSAGECIRCUIT,MESSAGENAME,COMMENT,FIELDNAME,ZZ,VALUES
*[temp1<90],,Hc1ActualFlowTempDesired,,,,0-89
#TYPE,CIRCUIT,NAME,COMMENT,QQ,ZZ,PBSB,ID,fields
[temp1<90]r3,,Hc1ActualFlowTempDesired,Aktuelle Vorlauftemperatur Soll Heizkreis 1,,,,"3E00",,,temp1,,,current flow temperatu
Das Problem, der Wert wird so überhaupt nicht mehr gelesen ( ERR: element not found ). Ich werde den Verdacht nicht los, dass ich mit den Conditions grundsätzlich was falsch verstanden habe. Jemand ne Idee?
LG
Hallo Reinhart,
habe die Optokoppler getauscht, gleiches Problem, ich würde daher gerne von deinem Angebot gebrauch machen bzgl der 2.2 er Platine, die vielen Stunden im Heizungskeller haben mich mürbe gemacht ;-) ,kann ich die über dich beziehen ?
VG
Zitat von: Sunnyvale am 19 Januar 2019, 11:11:08
moin moin,
anbei mal ein paar Fotos
VG
Ist Deine Platine durchkontaktiert?
Ansonst fehlt Dir hier wohl die Durchkontaktierung ('via' ;) ) vom R2 zum R3-Poti?!
Hi,
habe durchgemessen Verbindung ist "leider" vorhanden :(
VG
Zitat von: Sunnyvale am 19 Januar 2019, 20:54:57
Hallo Reinhart,
habe die Optokoppler getauscht, gleiches Problem, ich würde daher gerne von deinem Angebot gebrauch machen bzgl der 2.2 er Platine, die vielen Stunden im Heizungskeller haben mich mürbe gemacht ;-) ,kann ich die über dich beziehen ?
VG
Ja kannst du, es gibt verschiedene Varianten, für Raspberry zum Aufstecken oder als Basisplatine mit Uart (so wie die V1.6). Indem du dort schon einen Raspi mit Netzwerk hast, empfiehlt sich die RPI Variante.
RPI Platine einzeln 2,50.-
RPI als Bausatz 22,80.- (inkl. Porto)
RPI gelötet und gestestet 32.- (inkl. Porto)
Basis als Bausatz 24,30.- (inkl. Porto)
Basis gelötet und gestestet 35,.- (von John30, inkl. Porto)
LG
Zitat von: john30 am 18 Januar 2019, 18:31:32
mit dieser Einstellung bezieht ebusd die configs vom webservice unter ebusd.eu, d.h. wenn Dein Rechner z.B. keine Internetverbindung hat, dann klappt das natürlich nicht.
für die lokalen CSVs einfach noch " -c /etc/ebusd" hinter scanconfig hängen.
Ich habe genau das gleiche Problem. Habe den Raspberry jetzt auch nochmal komplett neu aufgesetzt, dadran liegt es nicht. Ganz selten lädt er mal für die Adresse 15 zumindestens die HW und SW ID...aber keine csv. Egal ob ich den configpath lokal oder im Internet nehme.
/etc/default/ebusd
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="--scanconfig -c /etc/ebusd"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
ebusctl i
[12:07:22] openhabian@openHABianPi:~$ ebusctl i
version: ebusd 3.3.v3.3-10-gfa434e5
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
signal: acquired
symbol rate: 23
max symbol rate: 59
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=35000;SW=0114;HW=7102"
address 31: master #8, ebusd
address 36: slave #8, ebusd[12:09:59] openhabian@openHABianPi:~$ ebusctl grab result
1008b5040100 / 0a00ffffffffffffff0080 = 12
1008b5110101 / 0945460080454b0000ff = 36
1008b5110102 / 06033c96468270 = 12
10feb516080058101220010719 = 7
1008b512020000 / 00 = 7
1008b51009000000ffffff45ff00 / 0101 = 37Ich habe eine Vaillant VCW206/5 und ein Calormatic 350. in diesem Post erkennt ebusd diese korrekt: https://forum.fhem.de/index.php/topic,46098.msg680644.html#msg680644
Ich komme bei mir nicht weiter. Liegt es wirklich am Poti?
Ich bin für jede Hilfe dankbar.
Zitat von: Sunnyvale am 20 Januar 2019, 11:19:03
habe durchgemessen, Verbindung ist "leider" vorhanden :(
Je nach USB/TTL-Modul könnte auch der R7 (unbezeichnet auf der Platine, waagerecht unterhalb
R2/R4) Probleme bereiten (unabhängig davon: besonders dann, wenn TX nicht angeschlossen wird...) (https://forum.fhem.de/index.php/topic,46098.msg428911.html#msg428911).
Wenn Du Deine Platine v.1.6 nicht nach der sehr guten Anleitung von Reinhart komplett durchmessen
kannst/willst, dann wäre das probeweise einseitig Auslöten des R7 ja noch ein Test wert.
Moin
Noch mal schnell eine Frage! Wie war das bei der V1.6? Sind da die Bruecken schon auf der Platine? Koennen die diesen Fehler bewirken?
Gruss Christoph
Zitat von: nuccleon am 19 Januar 2019, 19:55:55
Jetzt war meine Idee, Werte >=90 direkt über Conditions zu filtern, und zwar so:
#*[CONDITIONNAME],MESSAGECIRCUIT,MESSAGENAME,COMMENT,FIELDNAME,ZZ,VALUES
*[temp1<90],,Hc1ActualFlowTempDesired,,,,0-89
#TYPE,CIRCUIT,NAME,COMMENT,QQ,ZZ,PBSB,ID,fields
[temp1<90]r3,,Hc1ActualFlowTempDesired,Aktuelle Vorlauftemperatur Soll Heizkreis 1,,,,"3E00",,,temp1,,,current flow temperatu
Das Problem, der Wert wird so überhaupt nicht mehr gelesen ( ERR: element not found ). Ich werde den Verdacht nicht los, dass ich mit den Conditions grundsätzlich was falsch verstanden habe.
das ist so nicht der Hintergedanke bei conditions. Diese sind dafür da, die Verfügbarkeit einer Messagedefinition von einer anderen abhängig zu machen. Also so geht das nicht.
Ja die 1.6er Platine hat die Brücken schon drin
Hello Leute,
nachdem bei mir jetzt grundsätzlich die Platine und die Programmierung läuft steh ich vor einem kleinen Problem, das schon öfters diskutiert wurde aber so wie ich sehe noch nicht gelöst wurde ?
Oder doch und ich übersehe etwas ?
Bei mir ist, richtigerweise die 15.700.csv importiert mir fehlt jedoch die Funktionalität, oder besser gesagt der Befehl für den Modus "1x Speicherladung".
Gibts hierzu bereits neue Infos ?
Danke im Voraus!
BG
Hiermit funktioniert es bei mir:
ebusctl w -c 700 HwcSFMode 6
Nach einer Stunde schaltet die Regelung wieder in den auto-Modus.
VG
Günter
Liebe Ebusd Mitstreiter,
Ich klinke mich hier kurz mal ein: Habe ebusd über einen Esera EBUS Koppler an meiner Vaillant Luft/Wärmepumpe laufen. Daten übertrage ich per MQTT and Mosquitto dann auf Fhem. Encoding ist Json. Klappt alles soweit ganz gut bis auf folgende Unstimmigkeiten die mir nicht gefallen, respektive wo ich hänge:
a.) Ich habe immer die Meldungen
ebusd/global/updatecheck "revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/08.ehp.csv: different version available, vaillant/15.uih.csv: different version available, vaillant/23.ehp.cc.csv: different version available, vaillant/25.ehp.hwc.csv: different version available, vaillant/50.ehp.mc.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available, vaillant/iotesthp.inc: different version available"
sowohl im ebusd.log als auch über MQTT. Nirgends konnte ich schlüssig finden wie ich meine Definitionen updaten kann?? Ich benutze den letzten EBUSD binary package von https://github.com/john30/ebusd/releases/tag/v3.3 ... Ich verstehe das die Software automatisch die configs von ebusd.eu holt und ich sie aber auch lokal ablegen kann ... ein versuch die Config Packages runterzuladen von github und diese Lokal unter /etc/ebusd abzulegen scheiterte aber kläglich.
Was ist hier die empfohlene Vorgangsweise?
2.) Anbindung über MQTT: Ich bekomme tonnenweise Daten, nur die die ich will kriege ich nicht. Ich will folgende Daten:
+ Kompressor Status (ein/aus)
+ Aktuelles Energieintegral
+ Warmwasser Temperatur
+ Aktuelle Vorlauftemperatur
+ Aktuellel Rücklauftemperatur
+ Aktuelle Quellentemperatur
Das würde mir schon reichen. Vorlauftemperatur krieg ich ja noch, aber der Rest scheint in den Tiefen der Daten verborgen zu sein.
Durch Reverse Engineering hab ich folgende ReadingList erstellt:;
ebusd/broadcast/datetime:.* { json2nameValue($EVENT, 'datetime_', ) }
ebusd/broadcast/hwcStatus:.* { json2nameValue($EVENT, 'hwcStatus_', ) }
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', ) }
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', ) }
ebusd/cc/Mode:.* { json2nameValue($EVENT, 'ccMode_', ) }
ebusd/cc/Status:.* { json2nameValue($EVENT, 'ccStatus_', ) }
ebusd/cc/Timer.Monday:.* { json2nameValue($EVENT, 'ccTimer_', ) }
ebusd/ehp/ActualEnvironmentPower:.* { json2nameValue($EVENT, 'ehpActualEnvironmentPower_', ) }
ebusd/ehp/ActualEnvironmentPowerPercentage:.* { json2nameValue($EVENT, 'ehpActualEnvironmentPowerPercentage_', ) }
ebusd/ehp/currenterror:.* { json2nameValue($EVENT, 'ehpcurrenterror_', ) }
ebusd/ehp/EnergyBalancingRelease:.* { json2nameValue($EVENT, 'ehpEnergyBalancingRelease_', ) }
ebusd/ehp/errorhistory:.* { json2nameValue($EVENT, 'ehperrorhistory_', ) }
ebusd/ehp/FlowTemp:.* { json2nameValue($EVENT, 'ehpFlowTemp_', ) }
ebusd/ehp/HeatPumpStatus:.* { json2nameValue($EVENT, 'ehpHeatPumpStatus_', ) }
ebusd/ehp/HeatpumpType:.* { json2nameValue($EVENT, 'ehpHeatpumpType_', ) }
ebusd/ehp/HwcTemp:.* { json2nameValue($EVENT, 'ehpHwcTemp_', ) }
ebusd/ehp/PowerCutPreloading:.* { json2nameValue($EVENT, 'ehpPowerCutPreloading_', ) }
ebusd/ehp/SourceTempInput:.* { json2nameValue($EVENT, 'ehp_SourcetempInput_', ) }
ebusd/ehp/Status:.* { json2nameValue($EVENT, 'ehp_Status_', ) }
ebusd/ehp/Status02:.* { json2nameValue($EVENT, 'ehp_Status02_', ) }
ebusd/ehp/TimeOfNextPredictedPowerCut:.* { json2nameValue($EVENT, 'ehp_TimeOfNextPredictedPowerCut_', ) }
ebusd/ehp/YieldTotal:.* { json2nameValue($EVENT, 'ehp_YieldTotal_', ) }
ebusd/global/running:.* running
ebusd/global/signal:.* signal
ebusd/global/updatecheck:.* updatecheck
ebusd/global/version:.* version
ebusd/hwc/Mode:.* { json2nameValue($EVENT, 'hwc_Mode_', ) }
ebusd/hwc/Status:.* { json2nameValue($EVENT, 'hwc_Status_', ) }
ebusd/hwc/Timer.Monday:.* { json2nameValue($EVENT, 'hwc_Timer_Monday_', ) }
ebusd/mc/CfgHeatSinkType:.* { json2nameValue($EVENT, 'mc_CfgHeadSinktype_', ) }
ebusd/mc/DateTime:.* { json2nameValue($EVENT, 'mc_DateTime_', ) }
ebusd/mc/FlowTempDesired:.* { json2nameValue($EVENT, 'mc_FlowTempDesired_', ) }
ebusd/mc/Mode:.* { json2nameValue($EVENT, 'mc_Mode_', ) }
ebusd/mc/OperatingMode:.* { json2nameValue($EVENT, 'mc_OperatingMode_', ) }
ebusd/mc/Status:.* { json2nameValue($EVENT, 'mc_Status_', ) }
ebusd/mc/TempDesired:.* { json2nameValue($EVENT, 'mc_TempDesired_', ) }
ebusd/mc/TempDesiredLow:.* { json2nameValue($EVENT, 'mc_TempDesiredLow_', ) }
ebusd/mc/Timer.Friday:.* { json2nameValue($EVENT, 'mc_Timer_Friday_', ) }
ebusd/mc/Timer.Monday:.* { json2nameValue($EVENT, 'mc_Timer_Monday_', ) }
ebusd/mc/Timer.Saturday:.* { json2nameValue($EVENT, 'mc_Timer_Saturday_', ) }
ebusd/mc/Timer.Sunday:.* { json2nameValue($EVENT, 'mc_Timer_Sunday_', ) }
ebusd/scan.05/:.* { json2nameValue($EVENT, 'scan_05_', ) }
ebusd/scan.05/id:.* { json2nameValue($EVENT, 'scan_05_id_', ) }
ebusd/scan.08/:.* { json2nameValue($EVENT, 'scan_08_', ) }
ebusd/scan.15/:.* { json2nameValue($EVENT, 'scan_15_', ) }
ebusd/scan.15/id:.* { json2nameValue($EVENT, 'scan_15_id_', ) }
ebusd/scan.23/:.* { json2nameValue($EVENT, 'scan_23_', ) }
ebusd/scan.23/id:.* { json2nameValue($EVENT, 'scan_23_id_', ) }
ebusd/scan.25/:.* { json2nameValue($EVENT, 'scan_25_', ) }
ebusd/scan.25/id:.* { json2nameValue($EVENT, 'scan_25_id_', ) }
ebusd/scan.50/:.* { json2nameValue($EVENT, 'scan_50_', ) }
ebusd/scan.50/id:.* { json2nameValue($EVENT, 'scan_50_id_', ) }
ebusd/uih/YieldThisYear:.* { json2nameValue($EVENT, 'uih_YieldThisYear_', ) }
Die Werte die ich brauche, also hauptsächlich KompressorStatus, Energieintegral etc. etc. finde ich aber im ganzen Datenwulst nirgends.
Gibt es irgendwo eine Dokumentation über alle diese Variablen?? Ich finde nichts!!
3.) Ich verstehe das man einzelne Daten abfragen kann per MQTT indem man z.B.
mosquitto_pub -m '' -t 'ebusd/ehp/FlowTemp/get'
absetzt. Hat schon jemand eine entsprechende getList für MQTT/FHEM definiert um vernünftige Werte abzufragen?
Nachdem ja einige Leute hier an selbigem arbeiten, wäre ich an einem Erfahrungs/Config Austausch interessiert.
Danke und schöne Grüße // Tom
... viele Fragen.
Du musst unterscheiden zwischen Broadcast (alle Status Meldungen etc.) und selbst angeforderten Daten. Eine Liste was es gibt, siehst du ja im CSV, schau dazu einfach welche geladen wurden. Werte die du willst aber nicht bekommst musst einfach nur holen sofern sie in der CSV vorhanden/definiert sind!
Updaten kannst du indem du aus dem Git herunter lädst und selbst compilierst, dann hast die letzte Version. Die fertigen Packages hinken mit der Version immer hinten nach. Die Configs kannst ebenfalls aus denm Git installieren, hat John hier beschrieben (https://github.com/john30/ebusd-configuration) wie das geht.
Bei deinen Tests empfiehlt sich die Verwendung der neuen MQTT2 Module (https://forum.fhem.de/index.php/topic,79600.msg878716.html#msg878716), da diese wesentlich komfortabler zu handeln sind und Funktionen wie Autocreate und Templates dem Anwender unter die Arme greifen. Wenn du dann mit Mosquitto in der Konsole einmal deine Werte abfragst, wird automatisch dazu ein Reading erstellt, einfacher geht's nicht.
Vernünftige Werte abfragen sieht jeder anders, dem Einen genügen die Statusmeldungen, Andere wollen eine komplexe Steuerung aufbauen, daher wirst du keine Liste ala der eierlegenden Wollmilchsau bekommen. Was für mich vernünftig ist, kann für deine Zwecke sinnlos sein.
LG
Danke Reinhart für die ausführliche Antwort.
Mittlerweile habe ich die Integration in FHEM ganz gut hinbekommen und ein schönes Diagramm der für mich interessanten Betriebszustände erzeugt (siehe Anhang). Das Polling einiger Werte habe ich mit einer getList über MQTT gemacht und einem AT das jede Minute ein "get Heating xxxx; get Heating yyyyy" macht.
Der nächste Schritt wird sein einige Optimierungen in der Wärmepumpe vorzunehmen: Ich habe ja eine Luft/Wasser WP, sowie eine Photovoltaik Anlage mit Batteriespeicher (12kWh) und eine Solarthermie Anlage. Letzere ist noch NICHT in FHEM eingebunden. Die Idee ist nun, folgende Steuerungen zu implementieren:
a.) Wenn Solarthermie läuft, Absenkung der Min. Wassertemp in der WP auf ein Minimum für eine bestimmte Zeit (z.B. 1 Stunde) um zu vermeiden dass die WP ebenfalls anläuft und beginnt Warmwasser zu heizen. Das würde mir einige WW Heizzyklen sparen.
b.) Wenn die Inntentemp. über einem bestimmten Wert ist, Abschaltung des Heizmodus in der WP. Es hat ja keinen Sinn zu heizen wenn es eh warm genug ist im Haus. Das macht die WP nämlich aktuell...
Kommentare jemand? Hat sich schon mal jemand in diese Richtung gespielt?
Danke.
Tom
Hallo,
Die ebus adapter läuft bei mir schon
Aber kann jemand mir die ebusctl info erklaren?
Beispiel E7C00 ist meine zimmerthermostat welche Adresse gehört dazu und ist der eine master oder eine slave?
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 23
max symbol rate: 135
min arbitration micros: 1116
max arbitration micros: 7133
min symbol latency: 4
max symbol latency: 16
reconnects: 0
masters: 4
messages: 141
conditional: 2
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0302;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=SBX00;SW=0326;HW=4802", loaded "vaillant/15.sbx.csv"
address 30: master #3
address 31: master #8, ebusd
address 35: slave #3, scanned "MF=Vaillant;ID=E7C00;SW=0206;HW=7402", loaded "vaillant/35.e7c.csv"
address 36: slave #8, ebusd
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0202;HW=6502"
Zitat von: piacco am 13 Februar 2019, 15:00:15
Aber kann jemand mir die ebusctl info erklaren?
Beispiel E7C00 ist meine zimmerthermostat welche Adresse gehört dazu und ist der eine master oder eine slave?
der e7c ist sowohl master wie auch slave ("#3"), aber direkt ansprechen am besten immer über die slave adresse, also 35
Hi John
ich habe mal wieder Probleme mit meinen beiden EBUS(sen)
Immer nach eine sporadischen Zeit funktioniert der 2te EBUS nicht.
Ich konnte den Fehler eingrenzen.
1. EBUSD läuft
2. HEX Abfrage ist möglich
3. Konfiguration in FHEM hat sich nicht geändert
4. nun ist mir Aufgefallen das, die ECMDDevice's des 2ten Ebusses zusätzliche internals aufweisen.
IODev EBUS
IODevMissing 1
IODevName EBUS_2
bei IODev müsste "EBUS_2" stehen
wenn ich das Attribut IODev mit EBUS_2 neu setze geht das ECMDDevice wieder.
bei den funktionierendem EBUS (1) die mit IODev "EBUS" definiert sind gibts keine Probleme.
hier taucht auch nur
IODev EBUS
auf.
die Definitionen in FHEM lauten
geht nur manchmal
define DayKwh ECMDDevice bai00.class
attr DayKwh IODev EBUS_2
attr DayKwh alias Ertrag Tag
attr DayKwh group heatingControl
attr DayKwh room Lueftung
attr DayKwh stateFormat {sprintf('%.1f',ReadingsVal($name,$name,0))." kwh"}
geht immer
define Wartung_HZ ECMDDevice bai00.class
attr Wartung_HZ IODev EBUS
attr Wartung_HZ alias Heizung Wartung
attr Wartung_HZ group Wartung
attr Wartung_HZ icon sani_heating
attr Wartung_HZ room Vaillant
attr Wartung_HZ stateFormat Wartung_HZ
kannst du dir erklären wieso er die IODev im laufenden Betrieb ändert von EBUS_2 auf EBUS ?
mfg Maik
Zitat von: TiPpFeHlEr am 21 Februar 2019, 16:20:46
kannst du dir erklären wieso er die IODev im laufenden Betrieb ändert von EBUS_2 auf EBUS ?
da habe ich keine Ahnung, das scheint ein reines fhem Problem zu sein
Zitat von: TiPpFeHlEr am 21 Februar 2019, 16:20:46
kannst du dir erklären wieso er die IODev im laufenden Betrieb ändert von EBUS_2 auf EBUS ?
mfg Maik
Moin
Das sieht mir nach der dynamischen Umschaltung à la VCCU aus. Ich habe ein aehnliches Phaenomen bei anderen IODev's auch schon beobachtet! Waere ja mal einen Thread wert.
Gruss Christoph
@John
das berühigt mich schonmal ;)
@Christoph
Ich werds mal woanders posten.
MfG Maik
@tomleitner: Die Frage ist, wieviel man damit einsparen kann - ich tippe auf einen niedrigen einstelligen Prozentbereich.
LG
pah
Ich hoffe, mir kann jemand bei dieser Problemstellung helfen: Ich habe eine Vaillant atmoTEC plus VCW DE 194/4-5-HL R1 mit einem Calormatic 332 Raumgerät, die als bai und 350 erkannt werden. Lesen und Schreiben funktioniert.
Allerdings frage ich mich, ob es möglich ist, die Uhrzeit und das Datum entweder über bai oder 350 zu setzen.
Ich habe keinen DCF-Empfänger, und da ich in dieser Wohnung nur zwei Nächte die Woche bin, schalte ich die Heizung immer aus, wenn ich wieder fahre (bitte keine Diskussion darüber, ob das Sinn macht oder nicht, es macht Sinn). Um mir wenigstens beim Wiederkommen das Neustellen der Uhrzeit zu sparen, wäre ein Setzen der Uhrzeit und des Datums, das ich dann periodisch absetzen könnte, eine große Hilfe.
Zitat von: freetz am 28 Februar 2019, 10:41:39
Ich hoffe, mir kann jemand bei dieser Problemstellung helfen: Ich habe eine Vaillant atmoTEC plus VCW DE 194/4-5-HL R1 mit einem Calormatic 332 Raumgerät, die als bai und 350 erkannt werden. Lesen und Schreiben funktioniert.
Allerdings frage ich mich, ob es möglich ist, die Uhrzeit und das Datum entweder über bai oder 350 zu setzen.
Ich habe keinen DCF-Empfänger, und da ich in dieser Wohnung nur zwei Nächte die Woche bin, schalte ich die Heizung immer aus, wenn ich wieder fahre (bitte keine Diskussion darüber, ob das Sinn macht oder nicht, es macht Sinn). Um mir wenigstens beim Wiederkommen das Neustellen der Uhrzeit zu sparen, wäre ein Setzen der Uhrzeit und des Datums, das ich dann periodisch absetzen könnte, eine große Hilfe.
Bei der 350 gibt es diese Register:
r;wi,,ActualWeekday,,,,,"1600",,,bday,,,
r;wi,,Time,,,,,"1700",,,time,,,
r;wi,,Date,,,,,"2000",,,date,,,
Da die aber mit Rechte "Installer" (wi) sind, solltest in der Config diesen Parameter setzen damit du Schreiben darfst.
--accesslevel=*Versuche einfach einmal die Werte auszulesen ob das klappt.
pi@raspberrypi:~ $ ebusctl r -f time
19:43:54
pi@raspberrypi:~ $ ebusctl r -f date
28.02.2019
LG
Vielen Dank für die schnelle und hilfreiche Antwort, Reinhart!
Leider bekomme ich bei beiden ebusctl Befehlen nur
ERR: invalid position in decode
als Antwort.
Im Log findet sich Folgendes:
2019-02-28 20:13:36.012 [update error] unable to parse read 350 Time from 3115b509030d1700 / 0100: ERR: invalid position
2019-02-28 20:13:36.013 [main error] read 350 Time: decode ERR: invalid position
2019-02-28 20:13:38.077 [update error] unable to parse read 350 Date from 3115b509030d2000 / 020000: ERR: invalid position
2019-02-28 20:13:38.077 [main error] read 350 Date: decode ERR: invalid position
Mein ebusd ist so konfiguriert:
EBUSD_OPTS="--scanconfig --device=/dev/ttyebus --httpport=8889 --accesslevel=* --mqtthost=local.code-it.de --mqttjson --mqttport=18883 --mqtttopic=vaillant/%cir
cuit/%name"
Kann man da noch was machen oder muss ich mich damit abfinden, dass es dann bei meiner Therme nicht geht?
Interessanterweise bekomme ich bei vdate mit "broadcast vdatetime = 21:14:51;28.02.2019" die richtige Zeit, nur halt nicht in den o.g. Feldern...
Moin freetz
Ich mache das ueber das Modul Gaebus. Da meine Hauptplatine wohl ne Macke hat, und die DCF-Zeit je nach Laune interpretiert. (Habe mir schon einen zweiten Aussenfuehler geholt, da ich dachte, dass der kaputt ist.)
Ein DOIF stellt dann die Uhrzeit, wenn sie zu sehr vom fhem abweicht.
Gruss Christoph
Das ist genau das, was ich suche, und GAEBUS habe ich auch im Einsatz, nur bekomme ich bei den Feldern Date und Time eben o.g. Fehlermeldungen. Aber da ja immerhin eine Antwort kommt, habe ich noch Hoffnung...
Bleibt denn dann die richtige Zeit erhalten oder überschreibt bei Dir dann die ungenaue Funk-Zeit die von FHEM übermittelte?
Moin
Nein den DCF habe ich abgeklemmt, das nervt nur.
Mit dem Gaebus-modul musst Du ja erst die gewuenschten Datenpunkte definieren, damit Du sie lesen/schreiben kannst. Evtl. habe ich heute abend mal Zeit zu gucken, ist jetzt alles aus dem Kopf!
Gruss Christoph
Hallo,
kann mir jemand sagen wo die Werte für den jeweiligen Status der Heizung stehen, sind sie überhaupg abrufbar, werd nicht so recht fündig.
Hätte gerne die Werte für Warmwasserbetrieb oder Heizbetrieb, Sommerbetrieb oder Winterbetrieb, Störung (Fehlercodes).
Gruß
Thomas
edit: HeatingSwitch und currenterror bzw. errorhistory hab ich jetzt gefunden
Muss ich den Warmwasserbetrieb anhand von Storageloadpump ableiten ?
Zitat von: pc1246 am 01 März 2019, 11:17:14
Mit dem Gaebus-modul musst Du ja erst die gewuenschten Datenpunkte definieren, damit Du sie lesen/schreiben kannst. Evtl. habe ich heute abend mal Zeit zu gucken, ist jetzt alles aus dem Kopf!
Das hier ist das, was kommt, wenn ich Date und Time von r-350 mit "get" abfrage (s. Screenshots), im FHEM-Log kommt Folgendes:
2019.03.04 17:47:53 3: Vaillant get cmd v r~350~Date~
2019.03.04 17:47:53 3: Vaillant execute r -f -v -c 350 Date
2019.03.04 17:47:53 3: Vaillant answer v ERR: invalid position in decode
2019.03.04 17:48:14 3: Vaillant get cmd v r~350~Time~
2019.03.04 17:48:14 3: Vaillant execute r -f -v -c 350 Time
2019.03.04 17:48:14 3: Vaillant answer v ERR: invalid position in decodeDa hab' ich dann wohl keine Chance, oder?
Sorry
Ich bin derzeit beruflich stark eingebunden. Heute abend sollte ich aber mal schauen koennen. Muss eh mal dran, da sich unsere Heizzeiten komplett geaendert haben.
Gruss Christoph
Zitat von: TomLee am 03 März 2019, 15:48:32
Hallo,
kann mir jemand sagen wo die Werte für den jeweiligen Status der Heizung stehen, sind sie überhaupg abrufbar, werd nicht so recht fündig.
Hätte gerne die Werte für Warmwasserbetrieb oder Heizbetrieb, Sommerbetrieb oder Winterbetrieb, Störung (Fehlercodes).
Gruß
Thomas
edit: HeatingSwitch und currenterror bzw. errorhistory hab ich jetzt gefunden
Muss ich den Warmwasserbetrieb anhand von Storageloadpump ableiten ?
HeatingSwitch als Status für Winter/Sommerbetrieb heranzuziehen ging in die Hose, gestern war der erste Tag (mein ich) an dem die eingestellte Abschalttemperatur überschritten wurde. Das Reading blieb weiterhin auf on. Auf dem Display der Therme stand kein Wärmebedarf und Sommerbetrieb.
Kann mir bitte jemand sagen ob und in welcher Datei diese zwei Statusmeldungen auszulesen sind.
Gruß
Thomas
@tomlee Welches Heizsystem hast du? Dann kann ev. jemand helfen.
Zitat von: TomLee am 07 März 2019, 17:50:41
HeatingSwitch als Status für Winter/Sommerbetrieb heranzuziehen ging in die Hose, gestern war der erste Tag (mein ich) an dem die eingestellte Abschalttemperatur überschritten wurde. Das Reading blieb weiterhin auf on. Auf dem Display der Therme stand kein Wärmebedarf und Sommerbetrieb.
Kann mir bitte jemand sagen ob und in welcher Datei diese zwei Statusmeldungen auszulesen sind.
Gruß
Thomas
Hi Tommy,
bei mir ist die 470 als Steuerung verbaut an einer Ecotec Exclusive. Ich kann mit (Auszug aus meiner Heizungsklasse)
set Sommerbetrieb cmd {"w -c 470 hc1opmode 5\n"}
set Heizautomatik cmd {"w -c 470 hc1opmode 2\n"}den Betrieb umschalten und auch mit
r -f hc1opmodeden Status abfragen. Aktuell spuckt ebusctl da "auto" aus...
Vielleicht hilft das ?
Zitat von: cs-online am 08 März 2019, 22:00:33
Hi Tommy,
bei mir ist die 470 als Steuerung verbaut an einer Ecotec Exclusive. Ich kann mit (Auszug aus meiner Heizungsklasse)
set Sommerbetrieb cmd {"w -c 470 hc1opmode 5\n"}
set Heizautomatik cmd {"w -c 470 hc1opmode 2\n"}
den Betrieb umschalten und auch mit
r -f hc1opmode
den Status abfragen. Aktuell spuckt ebusctl da "auto" aus...
Vielleicht hilft das ?
Danke. Bei mir ist eine VRC 700 in der Therme verbaut. opmode dacht ich ist ein guter Hinweis und day, night,summer hört sich vielversprechend an. In der 15.700.csv nachgeschaut find ich OpMode, OpModeEffect, HwcOpMode, zxOpMode. z1OpMode gibt mir den Wert day aus. Zum testen hab ich die AT-Abschalttemp. mal auf einen niedrigeren Wert als die aktuelle AT gestellt, die Therme geht in den Sommerbetrieb und zeigt kein Wärmebedarf an z1OpMode gibt mir aber weiterhin nach dem abrufen day aus. ::)
hi freetz,
Zitat von: freetz am 28 Februar 2019, 10:41:39
Ich hoffe, mir kann jemand bei dieser Problemstellung helfen: Ich habe eine Vaillant atmoTEC plus VCW DE 194/4-5-HL R1 mit einem Calormatic 332 Raumgerät, die als bai und 350 erkannt werden. Lesen und Schreiben funktioniert.
dein CalorMatic 332 ist ein rein Analoger Raumregler!
Dieser hat noch die 7-8-9 Klemmen, und kein BUS.
deine Therme allerdings hat einen BUS sowie die alten 7-8-9 Anschlüsse.
wenn du nur einen CalorMatic 332 dran hast, kannst du diesen nicht auslesen.
Zitat von: VaillantRaumthermostat 24 V:
Anschluss 7, 8 und 9
keine bidirektionale
Schnittstelle (nur analog)
bist du sicher das nur ein VRT332 verbaut ist?
Wo befindet sich der VRT332 ? im Gerät(rechts) oder im Wohnzimmer an der Wand?
Gibt es evtl. im Gerät (rechts) noch einen weiteren CaloMatic 350?
Der VRT350 allerdings besitzt eine EBus Schnittstelle.
einmal sagst du, die lesen und schreiben funktioniert, ein anderesmal nicht.
kannst du mal vom ebusd ein
ebusctl -p 8888 info
geben?
MfG Maik
Also mein Raumgerät hängt im Wohnzimmer und ist an die Therme über den Bus- und nicht den 789-Anschluss angeschlossen. Der 789 ist nicht belegt, es ist auch keine 350 in der Therme selber installiert.
Das Raumgerät hat an der rechten Seite einen Western-Stecker, an dem ich die Platine angeschlossen habe. Lesen und Schreiben klappt wie gesagt prinzipiell, u.a. kann ich FlowsetHcMax (leider nur bis 40 Grad) setzen.
Ich dachte zuerst, dass ich eine 350 hätte, aber auf dem Aufkleber im Gehäuse steht 332.
Hier die Ausgabe von ebusctl info:
pi@retropie:~$ ebusctl -p 8888 info
version: ebusd 3.3.v3.3-13-gd366bb
b
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.350.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillantbroadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 115
min arbitration micros: 14
max arbitration micros: 118
min symbol latency: 4
max symbol latency: 8
reconnects: 0
masters: 3
messages: 429
conditional: 4
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='0010006110']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=35000;SW=0109;HW=7102", loaded "vaillant/15.350.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
hi freetz,
ein VRT 332 hat kein BUS!
evtl ist der Aufkleber falsch.
Auf der Rückseite des Reglers auf der Platine ist ein Aufkleber -> dort steht die Bezeichnung.
Du hast also warscheinlich einfach einen VRT350 mit EBus!
das wäre dann auch logisch das du diesen erkennst und das er über BUS angeschlossen ist.
Ich hab jetze nicht ganz verstanden, wie dein Raumregler mit der Therme verbunden ist.
An der Seite die Buchse ist für den Vaillant KD, also evtl. ne EBus Schnittstelle.
Der 332 hat aber im Sockel nur die Klemmen für 7-8-9
Der Sockel für den 350 hat nur die Klemmen BUS
MfG Maik
Ich weiß nicht, ob der Aufkleber falsch ist oder nicht, Fakt ist das, was ich oben beschrieben habe. Das Raumgerät ist über ein Kabel mit der Therme an deren Bus-Anschluss verbunden. Nachdem ich ausgemessen hatte, dass der Service-Port an der rechten Seite mit null Ohm Widerstand mit dem Wandanschluss durchgeht, war mir klar, dass dort auch Ebus anliegt, weswegen ich den Raspi darüber angeschlossen habe. Beim Durchmessen der Platine bin ich auf den Aufkleber gestoßen, wo eben 332 und nicht 350 steht.
Im Übrigen liegst Du wohl falsch, dass das 332 keine Service Buche hat, schau' mal hier unter Punkt 3.1, da ist sie zu sehen und auch so beschriftet:
https://www.vaillant.de/documents/download/280030
Moin
Also ich mische mich mal ein.
Die Klemmen 7/8/9 sind auch ein Bus, sonst koennten die Regler gar nicht alles darstellen. Dies ist aber kein eBus!
Das jetzt der VRT332 aus dem 7/8/9-Bus einen eBus macht, und an der Serviceschnittstelle zur Verfuegung stellt, waere sehr verwunderlich. Ich habe mir hierzu eine Zusatzplatine, die in die Therme kommt, gekauft. Und mir dann einen eBus-Regler dazu.
Gruss Christoph
Wie gesagt, der 7/8/9 ist an der Therme unbelegt (das ist ein eigener Konnektor), die 332 ist über den dortigen "Bus"-Konnektor verbunden, daran liegt zweifelsfrei ein Ebus-Signal an, sonst würde der Pi ja gar keine Daten (sowohl vom Raumgerät als auch von der Therme) bekommen/setzen können. In der Therme ist auch keine Zusatzplatine, sondern die Pfostenleisten sind direkt auf dem "Mainboard".
Hallo zusammen,
ich habe mal zwei Fragen:
1) was bedeutet denn wohl "bai StartPeakEnable = on" bei einer Ecotec Exclusive ? (finde ich leider weder im Internet noch in John's Kommentaren)
2) meine Therme hat aktuell 5 gespeicherte Fehler mit verschiedenen Einträgen, ich bekomme aber "bai currenterror = - - - - -", wo aktuell kein Fehler drin steht. Gestern ist die Therme mit F64 ausgefallen, da stand dann statt des ersten "-" dann "64", aber die anderen Striche blieben. Weiß jemand, ob man alle 10 Fehlerplätze der Therme irgendwie auslesen kann ?
Grüße
Christian
Zu 1 kann ich nichts sagen.
Mit Fehlern hatte ich mich auch mal beschäftigt, es dann aber doch weider verworfen. Hab mir gerade nochmal die ERRORS.INC angesehen:
*r,,,,,,"B503","01",,,,,,,,,
r,,errorhistory,Fehlerhistorie,,,,01,index,m,UCH,,,,,,errorhistory
Wenn ich das nun richtig verstehe, müsste man wohl mit ebusctl r -c bai -i 0..9 errorhistory die 10 Einträge des Fehlerspeichers lesen können.
Klappte bei mir aber nicht - wenn ich mir die Hex-Nachrichten von Hand gebastelt habe, ging es aber.
Nachtrag:
Der Cache scheint hier den übergebenen Index zu ignorieren, mit einem -f bzw. -m 0 scheint es aber zu gehen:
# ebusctl r -f -c bai -i 1 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=29 [Fehlernummer]
# ebusctl r -f -c bai -i 0 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=49 [Fehlernummer]
# ebusctl r -f -c bai -i 2 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=254 [Fehlernummer]
# ebusctl r -c bai -i 0 -V errorhistory
bai errorhistory index=2;status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=254 [Fehlernummer]
Beim letzten Read ist schön zu sehen, dass nicht Index 0 (wie angefordert) gelesen wird, sondern "index=2" noch im Cache steht.
Zitat von: freetz am 11 März 2019, 12:03:38
Wie gesagt, der 7/8/9 ist an der Therme unbelegt (das ist ein eigener Konnektor), die 332 ist über den dortigen "Bus"-Konnektor verbunden, daran liegt zweifelsfrei ein Ebus-Signal an, sonst würde der Pi ja gar keine Daten (sowohl vom Raumgerät als auch von der Therme) bekommen/setzen können. In der Therme ist auch keine Zusatzplatine, sondern die Pfostenleisten sind direkt auf dem "Mainboard".
Moin
Das klingt alles seltsam. Ich habe keine 332 gefunden die eBus hat. Hast Du mal zwei drei Fotos? Den Regler kann man ziemlich einfach von dem Wandhalter abnehmen. Dann kann man auch die innere Kontaktleiste sehen. Aber letztendlich ist es ja nicht Dein eigentliches Problem. Andererseits kommt die Funktionalitaet vom Regler, und was der Regler nicht kann, kommt nicht auf den Bus. Ausser es findet sich jemand der einen Regler simuliert, wobei das dann schon sehr grenzwertig wird.
Gruss Christoph
Hi Christoph,
da die Heizung in meiner Arbeitswohnung in Berlin ist und ich die nächsten Wochen nicht dort bin, kann ich leider auf die Schnelle kein Foto machen. Aber wie oben schon geschrieben, ist hier der Link für die Anleitung der 332:
https://www.vaillant.de/documents/download/280030
Und da sieht man unter 3.1 die auch als solche beschriftete Servicebuchse, die erprobter- und nachgewiesenermaßen EBus liefert.
Meine Hoffnung wäre ja, dass der Regler gar nicht so wichtig ist, denn der sendet doch auch nur Kommandos an die Therme (bai). Meine Idee wäre jetzt gewesen, die Kommandos direkt an die bai zu schicken, also z.B. das Ändern der Betriebsart, der Soll-Temperatur etc. So läuft es jedenfalls bei den Brötje-Heizungen und unserem BSB-LAN Projekt. Da simulieren wir quasi auf dem Arduino ein Raumgerät, so dass man völlig ohne Raumgerät alle Funktionen rein per FHEM steuern kann.
Ginge so etwas auch bei EBus oder ist da die ganze Intelligenz in den Reglern und nicht in der Therme? Wobei sich auch dann ja ein Raumgerät simulieren lassen müsste, oder?
Moin freetz
Wenn Du mal diese Anleitung https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=2ahUKEwiyqsrRvv7gAhXOZ1AKHdMBBgMQFjAAegQIChAC&url=https%3A%2F%2Fwww.vaillant.at%2Fdownloads%2Finstallationsanleitungen%2Fregelung-1%2Fi-vrt332-0020131926-00-360450.pdf&usg=AOvVaw24gb9cY-6VpxDmwb2IRfcC liest, dann wirst du unsere Verwunderung verstehen.
Und nur weil da Servicebuchse dransteht bedeutet das nicht, dass es eine eBus Schnittstelle ist!
Ob man einen Raumregler simulieren kann, kann ich dir nicht beantworten. Soweit ich es bis jetzt verstanden hatte, geht der eBus-d aber nur, wenn auch ein Regler an der Therme angeschlossen ist. Wo genau die Intelligenz ist sollte Reinhart/John/Chons sagen koennen. Je nach Regler kann die Therme auch andere Funktionen. Nachdem ich meine 420 gegen eine 470 ersetzt hatte, konnte ich auf einmal neue Funktionen einstellen.
Gruss Christoph
...interessant, dann scheint es wohl unterschiedliche Versionen zu geben - wenn man hier auf der Seite ganz unten schaut, scheint es 2015 eine neue Revision gegeben zu haben:
https://www.vaillant.at/privatanwender/produkte/calormatic-332-10816.html
Ich frage mich nur, wie dann bei den alten Geräten die Service-Buchse umgesetzt wurde, denn das Vaillant vrDialog-Dongle scheint ja auch ebus-basiert zu sein.
Aber wie dem auch sei, bei neueren 332ern ist die Service-Buchse auf jeden Fall ebus, genau so wie die Anbindung an die Therme. Die Frage für mich bleibt nur, ob/was ich tun kann, um Betriebsmodus und/oder Soll-Temperaturen oder auch das Datum/Zeit umzustellen, denn all diese Werte muss die 332 ja irgendwie über eBus an die Therme kommunizieren, denn wie soll die sonst wissen, ob sie heizen muss, und wenn ja, wie lange? Wenn mir da noch jemand weiterhelfen könnte, wäre ich sehr dankbar...
Nachdem nun die Frage "Ebus oder nicht" geklärt sein sollte (auch wenn ich das mit den Versionen auch nicht verstehe, das Dokument von 2015 ist nur eine Konformitätserklärung), mal zurück zum eigentlichen Problem:
Zitat von: freetz am 28 Februar 2019, 21:16:02
Vielen Dank für die schnelle und hilfreiche Antwort, Reinhart!
Leider bekomme ich bei beiden ebusctl Befehlen nur
ERR: invalid position in decode
als Antwort.
Im Log findet sich Folgendes:
2019-02-28 20:13:36.012 [update error] unable to parse read 350 Time from 3115b509030d1700 / 0100: ERR: invalid position
2019-02-28 20:13:36.013 [main error] read 350 Time: decode ERR: invalid position
2019-02-28 20:13:38.077 [update error] unable to parse read 350 Date from 3115b509030d2000 / 020000: ERR: invalid position
2019-02-28 20:13:38.077 [main error] read 350 Date: decode ERR: invalid position
Mein ebusd ist so konfiguriert:
EBUSD_OPTS="--scanconfig --device=/dev/ttyebus --httpport=8889 --accesslevel=* --mqtthost=local.code-it.de --mqttjson --mqttport=18883 --mqtttopic=vaillant/%cir
cuit/%name"
Kann man da noch was machen oder muss ich mich damit abfinden, dass es dann bei meiner Therme nicht geht?
Interessanterweise bekomme ich bei vdate mit "broadcast vdatetime = 21:14:51;28.02.2019" die richtige Zeit, nur halt nicht in den o.g. Feldern...
Ich denke, da ist dann eben die CSV der 350 für den 332 unpassend. Was ich noch nicht ganz verstanden habe: kommt nur der Fehler im "decode" und die Zeit wird dennoch richtig gesetzt?
Man müsste mal ein "readallregisters.sh" laufen lassen, zu verschiedenen Uhrzeiten - dann sollte man die Position von Datum/Uhrzeit schnell finden und könnte die CSV entsprechend abändern.
Alternativ könnte man versuchen, einfach Broadcasts über den Ebus zu schicken - in meinem Fall habe ich das mal mit der Außentemperatur gemacht und die VRC700 hat diese auch brav als gültig betrachtet, bis sie das nächste Mal aktiv die AT vom BAI angefordert hat...
Hi Sven,
das Setzen hatte ich bisher noch nicht probiert, weil mir nicht klar ist, wie da das Zeitformat auf der Kommandozeile aussehen muss. Die zitierten Fehlermeldungen beziehen sich auf die weiter oben (von Reinhart glaube ich) vorgeschlagenen ebusctl-Befehle
ebusctl r -f date
und
ebusctl r -f time
Und wegen des Überprüfens, meinst Du "readall.sh" oder "readallvaillantregisters.sh"? Letzteres gibt von 1 bis 511 durchweg "ERR: command not enabled" aus, nur bei 244 und 489 kommt stattdessen eine leere Zeile.
Bei readall.sh kommt folgendes Ergebnis, aber bei den nicht dekodierbaren Parametern leider keine Rohdaten:
350 ActualPumpPower = ERR: invalid position in decode
350 ActualRoomTempDesired = ERR: invalid position in decode
350 ActualTempDesired = 0
350 ActualWeekday = Mon
350 BypassValve = on
350 C1C2State = off
350 CirPump = off
350 ClockSwitchSummerWinterDone = 30
350 CMResetCnt = ERR: invalid position in decode
350 CollPumpHRuntime = ERR: invalid position in decode
350 COMErrorCnt = 8736
350 ComfTempDesired = ERR: invalid position in decode
350 ComfTempEnabled = on
350 ControlMode = 8
350 Date = ERR: invalid position in decode
350 DcfDaten = ERR: invalid position in decode
350 DisableAutoSync = 0
350 eBUSCRC = 0
350 eBUSFifoDiffCntMax = 0
350 EDControlEnabled = off
350 EEpromMaxInkonsCnt = ERR: invalid position in decode
350 ElectronicCartridge = off
350 FillmodeStartTime = 2
350 FlowTempMin = 0.00
350 FrostProtectDelay = 27
350 HeatingCurve = ERR: invalid position in decode
350 HwcState = 0
350 HwcTempDesired = 0.00
350 HydraulicMixer = 32
350 HydraulicScheme = 0
350 IsInFloorPavingDrying = 32
350 IsInHoliday = 0
350 IsInParty = 81
350 IsInQuickVeto = 120
350 IsInSavingsFunction = off
350 IsInSingleHwcLoadingMode = off
350 IsInTeleSwitch = 2
350 LegioProtectionEnabled = no
350 LegioProtectionState = on
350 LegioPump = off
350 LoadingDelayEnabled = 50
350 LVResetCnt = ERR: invalid position in decode
350 NumCollPanels = 120
350 OffDiff = 10
350 OffsetDesTemp = 16.06
350 ONDiff = 72
350 ONMAXDiff = 1
350 ONMINDiff = 0
350 OperatingMode = 227
350 OperatingModeHwc = on
350 OperatingmodeStartTime = 0
350 OtShutdownLimit = ERR: invalid position in decode
350 OutsideTemp = 80.69;17
350 OutsideTempOffset = ERR: invalid position in decode
350 POCResetCnt = ERR: invalid position in decode
350 PrevOperatingMode = 11
350 PumpPower = 0
350 QuickVetoTemp = ERR: invalid position in decode
350 ReducedNightTemp = ERR: invalid position in decode
350 ResetOperatingTimes = off
350 ResetYield = 7
350 RestoreOpModeAfterHoliday = on
350 resvdColl1Sensor = 1590.19;99
350 resvdColl2Sensor = ERR: invalid position in decode
350 resvdCollPump1 = 0
350 resvdCollPump2 = 0
350 resvdStorage1Sensor = 13.94;ok
350 resvdStorage2Sensor = ERR: invalid position in decode
350 resvdStorage3Sensor = ERR: invalid position in decode
350 ROCRoomSet = 16.06
350 RoomTemp = ERR: invalid position in decode
350 RoomTempOffset = 80.56
350 RoomTempOffsetSelfWarming = ERR: invalid position in decode
350 RoomTempSwitchOn = modulating
350 RTCAdjustment = ERR: invalid position in decode
350 SavingsFunctionTime = ERR: invalid position in decode
350 SolFlowRate = ERR: invalid position in decode
350 SolHwcMaxLoadTemp = ERR: invalid position in decode
350 SolPumpBlockingTime = 0
350 StackeBUSTaskMax = 0
350 StackLifeCheckTaskMax = 30
350 StackMainTaskMax = 0
350 StartCircuitAeration = off
350 StateOfRoomCon = 1
350 StatusDcf = ok
350 SwitchOffParty = on
350 TeleSwOperatingMode = eco
350 Time = ERR: invalid position in decode
350 TimeWindows = ERR: invalid position in decode
350 UV1State = 0
350 Variant = ERR: invalid position in decode
350 VariantDKRefreshCnt = 13
350 WDResetCnt = ERR: invalid position in decode
350 WeekDayProgSwitch = off
350 YearCalendarActive = off
350 Yield = ERR: invalid position in decode
350 YieldSensor = ERR: invalid position in decode
350 ZweipunktAnalogSlct = -
bai AATemp = 17.25;65259;ok
bai AccessoriesOne = fluegasflapextractorhood
bai AccessoriesTwo = fluegasflapextractorhood
bai ACRoomthermostat = on
bai AircontrolOk = off
bai AITemp = 17.81;65250;ok
bai AntiCondensValue = 8
bai averageIgnitiontime = 1.8
bai BlockTimeHcMax = 60
bai BoilerType = 0
bai BoilerType2 = ERR: invalid position in decode
bai ChangesDSN = 0
bai CirPump = on
bai CounterStartattempts1 = 31
bai CounterStartattempts2 = 2
bai CounterStartAttempts3 = 0
bai currenterror = -;-;-;-;-
bai DateTime = nosignal;23:16:37;-.-.-;-
bai dcfState = nosignal
bai DCFTimeDate = 10:10:14;17.01.2050
bai DCRoomthermostat = off
bai DeactivationsIFC = 1
bai DeactivationsTemplimiter = 0
bai DeltaFlowReturnMax = 15.94
bai DisplayMode = 146
bai DSN = 5181
bai DSNOffset = 61
bai DSNStart = 5120
bai EBusHeatcontrol = yes
bai EbusSourceOn = on
bai EbusVoltage = on
bai errorhistory = ERR: end of input reached
bai ExhaustCurve = 1
bai exhaustWayBlockCounter = 81
bai expertlevel_ReturnTemp = -1.81;cutoff
bai ExternalFaultmessage = off
bai externalFlowTempDesired = 90.00
bai externalHwcSwitch = off
bai ExternGasvalve = 240
bai ExtFlowTempDesiredMin = 0.00
bai extWP = off
bai FanHours = 0
bai FanMaxSpeedOperation = 0
bai FanMinSpeedOperation = 0
bai FanPWMSum = 0
bai FanPWMTest = 0
bai FanSpeed = 0
bai FanStarts = 0
bai Flame = off
bai FlameSensingASIC = 579
bai FloorHeatingContact = off
bai FlowsetHcMax = 40.00
bai FlowsetHwcMax = 80.00
bai FlowSetPotmeter = 40.00
bai FlowTemp = 13.44;ok
bai FlowTempDesired = 0.00
bai Fluegasvalve = off
bai Gasvalve = off
bai Gasvalve3UC = off
bai GasvalveASICFeedback = off
bai GasvalveUC = off
bai GasvalveUCFeedback = off
bai GVStepOffsetMax = -25
bai GVStepOffsetMin = 58
bai HcHours = 3152
bai HcPumpMode = post run
bai HcPumpStarts = 24641
bai HcStarts = 143000
bai HcUnderHundredStarts = 85
bai HeatingSwitch = on
bai HoursTillService = 3010
bai HwcDemand = no
bai HwcHours = 437
bai HwcImpellorSwitch = no
bai HwcPostrunTime = 20
bai HwcSetPotmeter = 61.44
bai HwcStarts = 36600
bai HwcSwitch = on
bai HwcTemp = -13.50;cutoff
bai HwcTempDesired = 0.00
bai HwcTempMax = 65.00
bai HwcTypes = 80
bai HwcUnderHundredStarts = 10
bai HwcWaterflow = 0.00
bai HwcWaterflowMax = 6.58
bai Ignitor = off
bai IonisationVoltageLevel = 46.9
bai maintenancedata_HwcTempMax = 116.06
bai maxIgnitiontime = 2.7
bai minIgnitiontime = 1.1
bai ModulationTempDesired = 40.0
bai OutdoorstempSensor = -60.44;cutoff
bai OverflowCounter = yes
bai ParamToken = 3
bai PartloadHcKW = 8
bai PartloadHwcKW = 20
bai PartnumberBox = 00 20 04 55 16
bai PositionValveSet = 0
bai PowerValue = 28 08 64 14 64 14
bai PrAPSCounter = 0
bai PrAPSSum = 0
bai PredCombustionDecrementTime = ERR: invalid position in decode
bai PredCombustionPredCounter = ERR: invalid position in decode
bai PredCombustionSwitchingPoint = ERR: invalid position in decode
bai PredFanPWMDevThreshold = ERR: invalid position in decode
bai PredFanPWMPredCounter = ERR: invalid position in decode
bai PredFanPWMRefPWMcounter = ERR: invalid position in decode
bai PredFanPWMRefPWMsum = ERR: invalid position in decode
bai PredFanPWMSwitchingPoint = ERR: invalid position in decode
bai PredIgnitionPredCounter = ERR: invalid position in decode
bai PredIgnitionSwitchingPoint = ERR: invalid position in decode
bai PredSourcePressureDevThreshold = ERR: invalid position in decode
bai PredSourcePressurePredCounter = ERR: invalid position in decode
bai PredSourcePressureSwitchingPoint = ERR: invalid position in decode
bai PredWaterflowDevThreshold = ERR: invalid position in decode
bai PredWaterflowSwitchingPoint = ERR: invalid position in decode
bai PredWaterpressureMaxPressure = ERR: invalid position in decode
bai PredWaterpressureMinPressure = ERR: invalid position in decode
bai PredWaterpressureSwitchingPoint = ERR: invalid position in decode
bai PrEnergyCountHc1 = 11298820
bai PrEnergyCountHc2 = 39646
bai PrEnergyCountHc3 = 298996
bai PrEnergyCountHwc1 = 530557
bai PrEnergyCountHwc2 = 390525
bai PrEnergyCountHwc3 = 556805
bai PrEnergySumHc1 = 455456923
bai PrEnergySumHc2 = 2764747
bai PrEnergySumHc3 = 29490709
bai PrEnergySumHwc1 = 23542761
bai PrEnergySumHwc2 = 27702589
bai PrEnergySumHwc3 = 51153556
bai PumpHours = 17038
bai PumpHwcFlowNumber = -
bai PumpHwcFlowSum = 0
bai ReduceModulationBlocktime = -
bai RemainingBoilerblocktime = 0
bai ReturnRegulation = off
bai ReturnTemp = 13.31;65322;ok
bai ReturnTempMax = 0.00
bai SecondPumpMode = 2
bai SerialNumber = 30 30 30 30 37 35 37 34
bai SetFactoryValues = no
bai SetMode = auto;0.0;-;-;1;0;1;0;0;0
bai SHEMaxDeltaHwcFlow = 0.00
bai SHEMaxFlowTemp = 0.00
bai SolPostHeat = 2
bai SpecialAdj = 1
bai Statenumber = 31
bai Status = ERR: invalid position in decode
bai Status01 = 13.0;13.0;-;-;13.0;off
bai Status02 = auto;60;40.0;70;61.0
bai Status16 = ERR: invalid position in decode
bai Storageloadpump = 0
bai StorageLoadPumpHours = 949
bai StorageloadPumpStarts = 28019
bai StorageLoadTimeMax = 45
bai StoragereleaseClock = no
bai StorageTemp = 13.00;ok
bai StorageTempDesired = 61.00
bai StorageTempMax = 66.62
bai TargetFanSpeed = 0
bai TargetFanSpeedOutput = 0
bai TempDiffBlock = 0
bai TempDiffFailure = 0
bai TempGradientFailure = 0
bai Templimiter = off
bai TemplimiterWithNTC = yes
bai TempMaxDiffExtTFT = 0.00
bai TimerInputHc = on
bai ValveMode = 0
bai ValveStarts = 29138
bai VolatileLockout = no
bai WarmstartDemand = yes
bai WarmstartOffset = 0.00
bai WaterHcFlowMax = 0
bai WaterPressure = 1.213;ok
bai WaterpressureBranchControlOff = off
bai WaterpressureMeasureCounter = 105
bai WaterpressureVariantSum = 65531
bai WP = off
bai WPPostrunTime = 15
bai WPPWMPower = 0
bai WPPWMPowerDia = 0
bai WPSecondStage = 0
broadcast datetime = ERR: no data stored
broadcast error = ERR: no data stored
broadcast hwcStatus = ERR: no data stored
broadcast id = ERR: invalid address
broadcast load = ERR: no data stored
broadcast outsidetemp = ERR: no data stored
broadcast signoflife = ERR: no data stored
broadcast vdatetime = 10:37:44;13.03.2019
general valuerange = ERR: invalid address
memory eeprom = ERR: invalid address
memory ram = ERR: invalid address
scan.08 id = 21;12;36;0010006110;0001;012873;N3
scan.15 id = 21;12;34;0020124472;0082;006074;N9
Die in broadcast vdatetime übertragene Zeit ist korrekt, aber 350 Date und 350 Time antworten eben mit "ERR: invalid position in decode".
Zitat von: Sven77 am 12 März 2019, 14:34:11
Zu 1 kann ich nichts sagen.
Mit Fehlern hatte ich mich auch mal beschäftigt, es dann aber doch weider verworfen. Hab mir gerade nochmal die ERRORS.INC angesehen:
*r,,,,,,"B503","01",,,,,,,,,
r,,errorhistory,Fehlerhistorie,,,,01,index,m,UCH,,,,,,errorhistory
Wenn ich das nun richtig verstehe, müsste man wohl mit ebusctl r -c bai -i 0..9 errorhistory die 10 Einträge des Fehlerspeichers lesen können.
Klappte bei mir aber nicht - wenn ich mir die Hex-Nachrichten von Hand gebastelt habe, ging es aber.
Nachtrag:
Der Cache scheint hier den übergebenen Index zu ignorieren, mit einem -f bzw. -m 0 scheint es aber zu gehen:
# ebusctl r -f -c bai -i 1 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=29 [Fehlernummer]
# ebusctl r -f -c bai -i 0 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=49 [Fehlernummer]
# ebusctl r -f -c bai -i 2 -V errorhistory
bai errorhistory status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=254 [Fehlernummer]
# ebusctl r -c bai -i 0 -V errorhistory
bai errorhistory index=2;status=1 [Status];time2=-:- [Zeit];date=-.-.- [Datum];error=254 [Fehlernummer]
Beim letzten Read ist schön zu sehen, dass nicht Index 0 (wie angefordert) gelesen wird, sondern "index=2" noch im Cache steht.
Das ist cool, das werde ich mal ausprobieren. Werde euch berichten.
Grüße
Christian
Super, das funktioniert, ich kann damit (nacheinander) die 10 Speicherplätze auslesen ! :-)
Gibt's eigentlich auch eine Möglichkeit, die Fehler per Ebus wieder zu löschen ?
Ja, es gibt auch ein Schreibkommando 'clearerrorhistory', was aber eben nur die Fehlerliste löscht - und leider nicht (wie von mir vergeblich gesucht) den Fehlerstatus zurücksetzt.
Letzteres kann die VRC700 offenbar mit manchen Wärmeerzeugern machen - mit meinem leider nicht.
Zitat von: freetz am 13 März 2019, 10:40:24
Und wegen des Überprüfens, meinst Du "readall.sh" oder "readallvaillantregisters.sh"? Letzteres gibt von 1 bis 511 durchweg "ERR: command not enabled" aus, nur bei 244 und 489 kommt stattdessen eine leere Zeile.
Wenn das so ist, fehlt dem Ebusd die Kommandozeilenoption
--enablehex.
Zitat von: freetz am 13 März 2019, 10:40:24
Die in broadcast vdatetime übertragene Zeit ist korrekt, aber 350 Date und 350 Time antworten eben mit "ERR: invalid position in decode".
Das deutet nur einmal mehr auf eine nicht passende CSV hin. Zeigt denn aber die 332 die richtige Zeit an?
Ich würde mich um die Korrektur der CSV wohl nur sekundär kümmern, wenn ich denn über ein Broadcast die Zeit im Zweifelsfall korrigieren kann...
Ich dachte, dass --enablehex dafür gut ist, um selber HEX-Telegramme auf den Bus zu schicken?
Bei readall.sh kommt jedenfalls weiterhin nur die Fehlermeldung, in der ebusd.log findet sich die bereits schon oben aufgeführten Fehlermeldungen (mit einem kurzen Hex-Dump):
2019-03-13 12:37:42.528 [update error] unable to parse read 350 Date from 3115b509030d2000 / 020000: ERR: invalid position
2019-03-13 12:37:47.327 [update error] unable to parse read 350 Time from 3115b509030d1700 / 0100: ERR: invalid position
Diese bleiben auch identisch, egal, wann/wie oft ich die beiden Parameter abfrage.
Wenn das mit dem Broadcast über vdatetime klappen würde, wäre das natürlich schon mal prima, ich habe leider nicht gefunden, wie ich einen solchen Broadcast senden würde, bzw. wie ich Datum und Uhrzeit formatieren müsste. Hast Du da einen Tipp?
Das Setzen von 350 Time und 350 Date ergibt übrigens einen "read timeout":
ebusctl write -c 350 Date "14:44:50"
2019-03-13 13:28:14.979 [bus error] send to 15: ERR: read timeout, retry
2019-03-13 13:28:15.541 [bus error] send to 15: ERR: read timeout, retry
2019-03-13 13:28:16.101 [bus error] send to 15: ERR: read timeout, retry
2019-03-13 13:28:16.659 [bus error] send to 15: ERR: read timeout
2019-03-13 13:28:16.659 [bus error] send message part 0: ERR: read timeout
Das Senden des Broadcasts schlägt ebenfalls fehl (was aber an meiner Unkenntnis liegen kann, wie Broadcasts adressiert werden müssen):
ebusctl write -c bai vdatetime "14:44:50;13.03.2019"
ERR: element not found
(Gleiches Ergebnis mit -c 350 und -c broadcast)
Ich bin kürzlich über ein nettes Feature gestolpert, was ich bisher nicht kannte (Danke, john30!!):
Wenn man Ebusd mit --enabledefine startet, kann man sich eine Messagedefinition selbst basteln und beim Schreiben mit übergeben - so kann man auf wohl einfachste Weise Broadcast-Meldungen schicken, ohne die Umrechnung in die Ebus-Datentypen bzw. nötigen Hexfolgen selbst zu übernehmen:
ebusctl w -def "w,broadcast,BCvdatetime,,,FE,B516,00,time,m,BTI,,,,date,m,BDA,,," "14:27:50;13.03.2019"
Im Log landet dann:
2019-03-13 14:27:42.729 [update notice] sent update-read broadcast vdatetime QQ=31: 14:27:50;13.03.2019
Und das mit --enablehex stimmt schon so, weil "readallvaillantregisters.sh" Hex-Nachrichten an die gewünschte Zieladresse schickt - es geht ja gerade darum, Nachrichten zu identifizieren, die noch unbekannt sind.
Aus deinem Log geht aber schon hervor, dass die 332 darauf offenbar gar nichts antwortet - entweder sie kennt gar kein Datum und Uhrzeit (zeigt sie das an?) oder es sind eben andere IDs, die man dann mit dem Script alle auslesen und die Antworten wegschreiben muss, um sie etwas später erneut auszulesen und die Antworten vergleichen...
Wäre aber zweitrangig, wenn das mit dem Broadcast schon so funktioniert.
Sehr gut, danke sehr! Jetzt spuckt readallvaillantregisters.sh etwas aus, was ich dann mit ein paar weiteren Läufen vergleichen kann :).
Ebenso danke für den Tipp mit den on-the-fly Definitionen, Deine Kommandozeile konnte ich 1:1 übernehmen und wenn ich dann vdatetime abfrage, kommt auch die entsprechend aktualisierte Zeit :). Die Frage ist jetzt nur, ob die 332 die Zeit auch übernommen hat und nicht selber (ähnlich wie bei der Vorlauftemperatur) ihre eigene Zeit wieder über den Bus schickt. Da ich die nächsten Wochen nicht in der Wohnung bin, kann ich das jetzt nicht direkt überprüfen, aber es ist auf jeden Fall schon mal ein wichtiger Schritt.
Was ich mich jetzt noch frage, ist, ob man diesen Broadcast auch "schöner" setzen kann, denn nach dem Aufruf Deiner Zeile steht im Log
2019-03-13 14:57:44.246 [update notice] sent update-read broadcast vdatetime QQ=31: 14:27:50;13.03.2019
2019-03-13 14:57:44.246 [main notice] write broadcast BCvdatetime: decode empty
Da das Log direkt von "broadcast vdatetime" spricht, frage ich mich, ob es dann auch direkt mit ebusctl write (ohne -def) eine Möglichkeit gibt, diesen Broadcast zu senden.
Dank' Dir auf jeden Fall für die wertvollen Hinweise und VG,
F.
Soweit ich weiß, geht das im Standard nicht, da Broadcast-Nachrichten nicht für "write" verfügbar sind - aber hier kann John ggf. mehr sagen.
Das Auslesen von "vdatetime" bringt nicht viel, weil Ebusd die selbst verschickte Nachricht auch im Cache ablegt und nur diese wieder ausgibt, ohne überhaupt auf den Bus zuzugreifen (Broadcasts können per Definition ja nie aktiv gelesen werden).
Zur Überprüfung würde ich empfehlen, mal aktiv die atmoTEC auszulesen:
ebusctl r -f -c bai DateTime
Und wenn die diese Zeit übernommen hat, nach einer halben Stunde nochmals zu prüfen (also vielleicht mal bewusst um 10 Minuten oder eine Stunde falsch stellen, sofern nicht irgendein Busteilnehmer zwischendurch ein DCF-Signal empfängt).
Das mit dem Cache stimmt, und wenn man vdatetime in kurzen Abständen abruft, bleibt die Uhrzeit auch gleich. Aber die 332 scheint jede Minute ihre Uhrzeit als Broadcast über den Bus zu schicken, denn nach ca. einer Minute bekomme ich beim Auslesen von vdatetime eine aktualisierte Uhrzeit, die dem entspricht, was ich vorher über den Broadcast eingestellt habe.
DateTime von bai auslesen bringt leider (bei mir) wenig, weil dort eine ganz andere (falsche) Zeit übermittelt wird ( nosignal;06:19:20;-.-.-;- ). Die Zeit ist aber auch nicht die, anhand derer die Zeitprogramme aktiviert werden - was auch Sinn macht, weil ich an der Therme auch gar keine Zeit einstellen kann, das geht nur an der 332.
@john30: Wenn vdatetime für anscheinend mehr Systeme verfügbar ist, als DateTime und Co., wäre es dann nicht sinnvoll, diesen Broadcast auf schreibbar zu stellen, wenn damit die Uhrzeit und das Datum problemlos eingestellt werden können?
So, nachdem ich nun mit readallvaillantregisters.sh eine Menge Werte auslesen konnte, die mit der 15.350.csv nur begrenzt übereinstimmen, habe ich diese Werte mal mit anderen CSVs verglichen und bin dabei zu dem Ergebnis gekommen, dass es mit 15.430.csv sehr große Übereinstimmungen gibt. U.a. würde hier nicht nur das Datum, sondern auch die Raumtemperatur, die Betriebsart, das Ferienprogramm u.v.m. passen.
@john30: Wäre es möglich, eine Kopie der 15.430.csv als 15.332.csv anzulegen, so dass diese dann mit --scanconfig von meiner Heizung aus erkannt wird? Dann könnte ich alle weiteren Parameter überprüfen und diesen Regler vervollständigen.
Falls das nicht (so schnell) geht, gibt es eine Möglichkeit, die Erkennung, die bei mir ja jetzt auf 15.350.csv springt, zu übergehen und stattdessen die 15.430.csv auszuwählen? Möglichst so, dass die bai bei mir immer noch erkannt wird? Oder wie sollte ich da vorgehen?
EDIT: Hier noch meine ebusctl info, die vielleicht für die Erkennung gebraucht wird:
version: ebusd 3.3.v3.3-13-gd366bbb
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.350.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 161
min arbitration micros: 10
max arbitration micros: 432
min symbol latency: 3
max symbol latency: 10
reconnects: 0
masters: 3
messages: 429
conditional: 4
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='0010006110']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=35000;SW=0109;HW=7102", loaded "vaillant/15.350.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Freue mich jedenfalls sehr, dass ich dank Eurer Hilfe auf jeden Fall ein großes Stück weiter gekommen bin und hoffe, dass es anderen 332er-Besitzern auch etwas bringt...
...so, habe jetzt quick&dirty das ebusd-configuration Repo gecloned, dort die 15.350.csv gegen die 15.430.csv ausgetauscht und entsprechend den ebusd mit --configpath gestartet - und das Ergebnis ist hervorragend, fast alle Parameter werden auch bei mir erkannt, so dass bei mir jetzt eine sehr umfangreiche Steuerung möglich ist :). Vielen Dank nochmals für die ganze Unterstützung; für den Moment kann ich mit diesem Workaround gut leben, aber andere 332er-Besitzer werden sich sicher freuen, wenn die CSV entsprechend erkannt wird.
Hier noch mal der schön gefüllte Output nach einem readall.sh Aufruf, man sieht nur wenige Parameter, die anscheinend entweder nicht vorhanden sind oder (noch) nicht korrekt dekodiert werden:
350 ACTOstorDetected = no
350 actoSTOROPMode = 0
350 ActualRoomTempDesiredHc1 = 5.00
350 ActualWeekday = Thu
350 adpPreHActive = on
350 adpPreHCurrentRoomTemp = 0.00
350 adpPreHInSideTW = 5
350 adpPreHMinutesBeforeFirstTW = 0
350 adpPreHOutdoorTemp = ERR: invalid position in decode
350 adpPreHOutdoorTempStart = ERR: invalid position in decode
350 adpPreHPreheatingTime = ERR: invalid position in decode
350 adpPreHRamp = ERR: invalid position in decode
350 adpPreHRoomTempDesired = 514.00
350 adpPreHRoomTempStart = ERR: invalid position in decode
350 adpPreHStarttime = ERR: invalid position in decode
350 AutoOffMode = eco
350 B50418actDesFlowTemp = 0.0
350 B51000FlowSetMonitor = 0.0
350 B51000HcDisableMonitor = 1
350 B51000TempDesiredLoadingPump = -
350 BaseDisplay = HC1
350 BMUB51101BoilerFlowTemp = 13.0
350 BMUB51101ErrorStatus = 0
350 BMUB51101HwcState = off
350 BMUB51101StorageTemp = 12.0
350 BMUFlowTempOrVF1 = 13.00;ok
350 CalculatedKickStopTime = 0
350 ccTimer.Friday = 06:00;22:00;22:00;22:00;22:00;22:00;Sa-So
350 ccTimer.Monday = 06:00;22:00;22:00;22:00;22:00;22:00;Sa-So
350 ccTimer.Saturday = 07:30;23:30;23:30;23:30;23:30;23:30;selected
350 ccTimer.Sunday = 07:30;22:00;22:00;22:00;22:00;22:00;selected
350 ccTimer.Thursday = 06:00;22:00;22:00;22:00;22:00;22:00;Sa-So
350 ccTimer.Tuesday = 06:00;22:00;22:00;22:00;22:00;22:00;Sa-So
350 ccTimer.Wednesday = 06:00;22:00;22:00;22:00;22:00;22:00;Sa-So
350 ChimneySweepModeActive = no
350 CirPump = off
350 ContinuosHeating = -26
350 CountryVariant = 0
350 CPLPLast24started = no
350 currenterror = -;-;-;-;-
350 Date = 14.03.2019
350 DisplayedHc1RoomTempDesired = 0.0
350 DisplayedRoomTemp = 11.88
350 EepromUpdateActive = on
350 EnermanState = 0
350 errorhistory = ERR: end of input reached
350 ExcessTemp = 0.0
350 FrostOverRideTime = 4
350 FrostProtectDelayMonitor = no
350 FrostProtectionRequiredMonitor = no
350 FrostProtectStateMonitor = 0
350 Hc1ActualFlowTempDesired = 0.0
350 Hc1HcType = burnercircuit
350 Hc1HeatCurve = 1.20
350 Hc1ManualOPRoomTempDesired = 0.0
350 Hc1MinimalFlowTempDesired = 15.0
350 Hc1NightTemp = 16.0
350 Hc1OPMode = auto
350 Hc1PreOrContinuosHeatingActive = no
350 Hc1Pump = off
350 Hc1PumpLast24started = no
350 Hc1QuickVetoActive = no
350 Hc1QuickVetoTemp = 0.0
350 Hc1RoomTempSwitchOn = off
350 Hc1SummerOffset = 1.0
350 Hc2HcType = mixing
350 HcMc1ConfigCPLPAsLP = CP
350 HcMc1CPLPState = off
350 HcMc1Detected = no
350 hcTimer.Friday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Monday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Saturday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Sunday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Thursday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Tuesday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 hcTimer.Wednesday = 18:00;23:00;23:20;23:20;23:20;23:20;Mo-Fr
350 HolidayEndPeriod = 11.05.2017
350 HolidayRoomTemp = 5.0
350 HolidayStartPeriod = 09.05.2017
350 HRUDetected = no
350 HwcActualTempDesired = 0.0
350 HwcCircuitActive = no
350 HwcLegioStartDay = off
350 HwcLegioStartTime = 04:00:00
350 HwcLoadingIn430Active = no
350 HwcLoadingOffset = 25.0
350 HwcManualOPTempDesired = 0.0
350 HwcOPMode = auto
350 HwcParallelLoading = off
350 HwcPressLowpostrunningtime = 5
350 HwcQuickVetoActive = no
350 HwcQuickVetoTemp = 0.0
350 HwcTempDesired = 60.0
350 hwcTimer.Friday = 05:30;22:00;22:00;22:00;22:00;22:00;Sa-So
350 hwcTimer.Monday = 05:30;22:00;22:00;22:00;22:00;22:00;Sa-So
350 hwcTimer.Saturday = 07:00;23:30;23:30;23:30;23:30;23:30;selected
350 hwcTimer.Sunday = 07:00;22:00;22:00;22:00;22:00;22:00;selected
350 hwcTimer.Thursday = 05:30;22:00;22:00;22:00;22:00;22:00;Sa-So
350 hwcTimer.Tuesday = 05:30;22:00;22:00;22:00;22:00;22:00;Sa-So
350 hwcTimer.Wednesday = 05:30;22:00;22:00;22:00;22:00;22:00;Sa-So
350 IsInHoliday = no
350 KeyCodeforConfigMenu = ERR: invalid position in decode
350 LcdContrastValue = 12
350 LegioProtectActive = no
350 MaintenanceDate = 01.01.2011
350 NameHc1 = HEIZKREIS1
350 NameHc2 = HEIZKREIS2
350 NameHwc = 5
350 OutsideTemp = 0.00;cutoff
350 OutsideTempOffset = 0.0
350 PhoneNumber1 =
350 PhoneNumber2 =
350 PreheatingTime = 0
350 PreStopTime = 0
350 PumpBlockingTimeMax = 0
350 PumpEnergySaveCalculatedTimeMonitor = 0
350 PumpEnergySaveStateMonitor = 1
350 RoomTemp = 13.69;ok
350 RoomTempCorrection = 0.0
350 RoomTempOffsetSelfWarming = -1.81
350 Setpoints.Friday = ERR: invalid position in decode
350 Setpoints.Monday = ERR: invalid position in decode
350 Setpoints.Saturday = ERR: invalid position in decode
350 Setpoints.Sunday = ERR: invalid position in decode
350 Setpoints.Thursday = ERR: invalid position in decode
350 Setpoints.Tuesday = ERR: invalid position in decode
350 Setpoints.Wednesday = ERR: invalid position in decode
350 SolModuleDetected = no
350 StartEepromUpdate = off
350 StatusDcf = nosignal
350 SummerWinterTimeAdjust = on
350 Time = 22:39:09
350 VF1 = 0.00;cutoff
Hallo freetz,
das Problem ist nur, dass dein Regler sich als 350er meldet, deshalb wird ja die 350-Konfigdatei verwendet:
Zitat von: freetz am 14 März 2019, 22:46:37
address 15: slave #2, scanned "MF=Vaillant;ID=35000;SW=0109;HW=7102", loaded "vaillant/15.350.csv"
Evtl kann man dies noch über die SW-Version oder Hardware-Kennung differenzieren.
Gruß
Maik
Ah, ok - das Problem haben wir beim BSB-Bus auch, da gibt es neben der Gerätefamilie (an der wir lange alles ausgerichtet hatten) auch noch eine Gerätevariante, die bei steigender Anzahl an unterstützten Geräten dann auch notwendigerweise mit bei der Autodetection mit einbezogen werden musste. Nervig...
Über welchen Befehl wird denn die Kennung von der Heizung ausgelesen? Seltsam ist das ja schon, dass es eine 332 ist, die sich als 350 ausgibt, aber die Konfiguration der 430 benötigt...
Moin
Du hast halt ein Sonntagsmodell. Da sind wir uns doch schon lange einig!
Gruss Christoph
Zitat von: freetz am 15 März 2019, 09:35:14
Über welchen Befehl wird denn die Kennung von der Heizung ausgelesen?
das wird über die 0704 Message gefolgt von anschließendem Vaillant Produkt-Code lesen gelöst. Damit stehen dann ID;SW,HW und noch ein paar andere Werte aus scan (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/scan.csv) zur Verfügung, um eine Variante von anderen abzugrenzen. Wie das funktioniert ist bspw. in der bai (https://github.com/john30/ebusd-configuration/blob/master/ebusd-2.1.x/de/vaillant/08.bai.csv) zu finden.
Danke, john30, dann gibt sich das Teil laut ebusctl hex 1507040100 wirklich als 3500 / 0109 / 7102 aus :(.
Ich habe jetzt noch einmal die 15.470.csv ausprobiert, weil da im Gegensatz zur 15.430.csv auch noch Hc1DayTemp verfügbar war, und die scheint sogar noch besser zu passen. Kann natürlich sein, dass dieser und andere Parameter auch bei der 430 passen würden, denn es macht ja wenig Sinn, dass z.B. die 430 Hc1NightTemp kennt, aber nicht Hc1DayTemp. Aber das kann ich ohne weitere Hardware natürlich nicht überprüfen.
Wie dem auch sei, für meine "Sonntags"-332 habe ich jetzt eine sehr umfangreiche Parametersammlung, bei der zwar ein Gutteil der verfügbaren/lesbaren Parameter keine Anwendung finden werden (weil ich keinen 2. HK habe etc.), aber falls jemand anderes auch so ein Gerät haben sollte, hänge ich die gemergete CSV hier einmal an. Wenn die neueren 332 sich alle als 350 ausgeben, muss man dann wie bei mir die Datei in 15.350.csv umbennenen.
Eine Übernahme in ebusd-configuration würde vermutlich wohl nur Sinn machen, wenn anhand der HW-ID (7102) eine sichere Differenzierung gegenüber einer echten 350 gemacht werden könnte.
Danke noch mal und VG, F.
Eine (hoffentlich letzte) Frage hätte ich noch:
Bevor ich jetzt für mehrere Wochen nicht mehr in der Wohnung sein werde, hatte ich die Heizung auf Frostschutz (5 Grad) an der 332 gestellt. Das führt natürlich dazu, dass ich jetzt keine Soll-Temperaturveränderungen vornehmen kann, wenn ich dann wieder in die Wohnung zurück komme und es dann gerne warm hätte.
Folgende Parameter fallen mir bei ebusctl find auf, die damit zu tun haben könnten, aber mit welchem (oder anderem) kann ich die Heizung wieder zum normalen Heizen bewegen?
350 ActualRoomTempDesiredHc1 = 5.00
350 GlobalSystemOff = on
350 Hc1AutoOffMode = eco
350 Hc1RoomTempSwitchOn = off
350 Hc1OPMode = auto
Dank' Euch und VG, F.
Moin
Kannst du denn "ActualRoomTempDesiredHc1" nicht auch verstellen?
Zudem wundere ich mich, dass Du einen 2. Heizkreis in dem "322" hast. Der kann laut Anleitung nur einen Heizkreis. Der "350" kann einen Heizkreis und einen Warmwasserkreis. Soweit ich weiss, koennen nur die 400er 2 Kreise.
Gruss Christoph
ActualRoomTempDesiredHc1 ist read-only, habe es testweise mal auf writeable gesetzt, Änderung liegt aber nur im Cache und wird dann wieder mit dem alten Wert überschrieben.
Das mit dem 2. HK, den das Gerät eigentlich gar nicht kann, kenne ich auch von meiner Elco Thision. Da kann ich auch über BSB-LAN alle möglichen Infos zum HK2 und sogar zu einem nicht vorhandenen Kühlkreis auslesen und schreiben, aber das hat natürlich keine Auswirkung. Die Hersteller schreiben meist nur eine Software und blenden dann in den Menüs die entsprechenden Funktionen aus, die die darüberliegende Hardware nicht kann.
Hallo,
ich lese das eBus Protokoll meiner Vaillant VC136 schon seit über 5 Jahren aus. Schon vor 2009 gab es da Aktivitäten im Forum von symcon.de. Aber erst ca. 2 Jahre später wurde der properitäte Code von Vaillant halbwegs geknackt.
Es folgte ein eBus Manager, ein PHP-Script, daß wirklich sauber und gut lesebar ist.
https://www.symcon.de/forum/threads/20547-eBus-Manager?p=185924#post185924
Jetzt zu meinem Problem.
Es traten in der ganzen Zeit nur wenige Fehler auf. Jetzt habe ich wieder mal einen, den F.75 "Beim Einschalten der Pumpe wurde kein Drucksprung erkannt". Der Fehlertext lautet an der VCR430 "Fehler Heizgerät". Auf dem Display des Kessels steht nur die "F.75"
Ich kann leider nicht die Statuszeile, bzw. die Meldungen auslesen. Die Frage ist ja eigentlich, wie wird der Text in der VCR430 und im Display des Kessels generiert? Läuft dies überhaupt über den eBus? Ein Statusflag, der abrufbar ist, wäre ja auch eine Lösung.
https://www.mikrocontroller.net/attachment/407233/P1000271k.jpg (https://www.mikrocontroller.net/attachment/407233/P1000271k.jpg)
mfg klaus
Ich hatte mit meinem icoVIT 156 und VRC 700 schon einige Fehler!
Es gab aber nie irgendwelche Textmeldungen auf dem Bus, es ist lediglich die Fehlernummer und teilweise der Zeitpunkt abfragbar. Im Display des Kessels ist halt nicht mehr Platz, außerdem steht die Bedeutung ja in der Anleitung in der jeweiligen Sprache. Und dem Regler ist der genaue Fehler ja im Grunde komplett egal - daher meldet er nur, welches Gerät über den Bus einen Fehler meldet.
Ich kann jetzt den Sinn deiner Anfrage nur erraten:
a) "Kann ich über den Bus die Fehlermeldung lesen?" --> nein, nur im Handbuch
b) "Kann ich steuern, was der Regler anzeigt?" --> nein
c) "Kann ich in FHEM eine Textmeldung ausgeben?" --> ja, Fehlernummer vom Bus lesen und die Texte der Bedienungsanleitung hinterlegen
Ich bin leider kein FHEM-Fuchs, wie man die Zahlen in Text wandeln kann - ich persönlich würde es über eine Optionsliste in HTML umsetzen. ;)
Hallo Sven,
ich meinte nicht das der Text von Meldungen über den eBus gesendet werden, bestenfalls wird da ein Code, ein Byte gesendet.
ZitatUnd dem Regler ist der genaue Fehler ja im Grunde komplett egal - daher meldet er nur, welches Gerät über den Bus einen Fehler meldet.
Genau da möchte ich einhaken.
Zitatc) "Kann ich in FHEM eine Textmeldung ausgeben?" --> ja, Fehlernummer vom Bus lesen und die Texte der Bedienungsanleitung hinterlegen
Mir genügt es ja die Fehlernummer vom Bus zu lesen. Wie sieht der entsprechende Code auf dem eBus aus?
In den Sourcen stoße ich z.B. bei ebusd-configuration-2.1.b143f39-en_all im Verzeichnis vaillant auf csv-Daten die etwas zum Vaillant-Code beinhalten. Wie komme ich da zu meiner Fehlermedung, bzw., auf den Code-Schlüssel der die Fehlermeldung transportiert?
mfg Klaus
Hallo,
bei meiner Ectotec geht das mit
r -f -c bai currenterror
für den aktuellen Fehler und z.B.
r -f -c bai -i 0 -V errorhistory
für den ersten gespeicherten Fehler in der Fehlerhistorie (in Summe 10 Plätze, mit Index 0 vor dem "-V" für den ersten bis 9 für den 10. Platz)
Das ganze habe ich in einer EMCD-Klasse drin (da wo ich alles vom eBus abfrage) und dann mit einem Timer alle 60s aktualisiert. ReadingsProxy auf den Eintrag in der Klasse zum Anzeigen
Grüße
Christian
Richtig, dazu muss man sich schon die Mühe machen, die letzten 2 Seiten mal zu überfliegen:
https://forum.fhem.de/index.php/topic,29737.msg918132.html#msg918132
Hallo Christian,
ZitatDas ganze habe ich in einer EMCD-Klasse drin (da wo ich alles vom eBus abfrage)
Wo finde ich diese EMCD-Klasse? Ist das Teil des ebusd?
Für mich ist es schwierig selbst die Bedeutung von bai zu ermitteln. Kannst Du mir Beispiele für eine eBus-Code-Sequenz für eine Fehlermeldung geben? Also auf native - Ebene dieser Art?
Zitat10 08 B5 10 09 00 00 00 78 FF FF 01 FF 00 F8 00 01 01 9A 00
00 15 B5 09 03 0D 31 00 7D 00 02 64 00 41
00 08 B5 09 03 0D 38 00 E1 00 01 1F 84
mfg Klaus
Okay, das lässt vermuten, dass du weder FHEM noch EBUSD nutzt, somit bist du hier eigentlich falsch!
Die Abfrage der Fehlerhistory des Kessels sollte mit der Hex-Nachricht 08b50303010100 (letztes Byte 0-9 für 10 Fehlerspeicher), Antwort dann 1 Byte Status, 2 Bytes Zeit, 3 Bytes Datum und 2 Bytes Fehlernummer, also z.Bsp.:
Zitat31 08 b5 03 03 01 01 00 08 01 ff ff ff ff ff 31 00
Darin stehen dann aber alle Fehler, die in der Vergangenheit aufgetreten sind - alle aktuellen Fehler bekommt man mit Hex 08b503020001, was wiederum bis zu 5 Doppelbytes mit aktuell anliegenden Fehlern meldet:
Zitat31 08 b5 03 02 00 01 0a ff ff ff ff ff ff ff ff ff ff
Ich hoffe, das hilft etwas...
Hallo Sven,
leider nicht wirklich. Bei mir erscheint ein Broadcast gemäß eBus-Spezifikation. Die Nachricht wurde bei mir nicht weiter behandelt, passt aber zeitlich. Adresse 31 soll demnach ein Businterface sein. Ist bei mir im Protokoll nicht zu finden.
Zitat03 FE FE 01 0A 42 41 49 03 01 00 00 00 00 00 58
Allerdings zeigt es sich, daß es zukunftssicherer ist sich einer Plattform wie FHEM anzuschließen. Mein EcoTec ist aus dem Jahr 2007 und war damals eines der ersten dieser Modellreihe. Inzwischen mußte einmal die Basisplatine getauscht werden. Danach war auf einmal die Modulation wesentlich besser. Irgendwann ist vielleicht auch ein neues Brennwertgerät selber notwendig. Dann stehe ich natürlich auf dem Schlauch. Das Know How zu Anpassung habe ich nicht. Ich habe ja einen kleinen Anblick in die Vielfalt der Konfigurationen machen können.
Hast Du ein Tipp für einen raschen Einstieg? Als Hardware wäre mir ein Rasberry PI schon ganz angenehm.
mfg Klaus
Also ob nun FHEM (nutze ich selbst auch nicht) oder etwas anderes, sei mal dahin gestellt.
Aber Ebusd nimmt dir schon einen erheblichen Aufwand ab - John investiert hier richtig viel Hirnschmalz, Zeit und Arbeit - an dieser Stelle auch mal ein dickes DANKESCHÖN von mir!
Ebenso zur Dokumentation wird hier viel getan, einen Einstieg findest du z.Bsp. unter: https://github.com/john30/ebusd/wiki
Dort stehen auch viele Basics zum Ebus selbst, hier nur in aller Kürze zur Erklärung der geposteten Bytes:
Das erste Byte ist die Quelladresse, da ich aktiv eine Nachricht mit Ebusd geschickt habe, ist diese 31 (Adresse von Ebusd). Wenn du auf dem Bus nur mithörst, müsstest du schauen, wer sonst noch die 08 nach einem Fehler abfragt - oder ignorierst das erste Byte und wartest einfach auf "08 b5 03 ...".
Wenn der Fehler auf der Steuerung erscheint, muss eigentlich irgendwann mal die 10 als Quelle aufgetaucht sein.
Es ist natürlich auch denkbar, dass es noch weitere Nachrichten gibt, um den Fehlerzustand abzufragen. In diesem Fall müsste man in den Nachrichten nach der Fehlernummer (4b) suchen, oder (noch schlimmer) es gibt sogar einfach ein Flag "Fehler oder nicht", dann kommst du um das aktive Abfragen nicht herum.
Aber meine Empfehlung wäre ohnehin, dich in Ebusd einzuarbeiten, das macht die ganze Sache erheblich leichter!
Zitat von: KlaRa am 25 März 2019, 19:50:40
Hallo Christian,
Wo finde ich diese EMCD-Klasse? Ist das Teil des ebusd?
Für mich ist es schwierig selbst die Bedeutung von bai zu ermitteln. Kannst Du mir Beispiele für eine eBus-Code-Sequenz für eine Fehlermeldung geben? Also auf native - Ebene dieser Art?
mfg Klaus
Hallo,
die Klassendefinition (in FHEM) findest du auf Seite 1 dieses Threads. In native kann ich dir leider nicht helfen, sorry
John hat eine sehr aufwendige Doku erstellt, am besten dort erst mal einlesen.
Grüße
Christian
Hallo Sven,
vielen Dank. Dann werde ich mich in aller Ruhe einlesen.
@Christian
Ebenfalls vielen Dank.
mfg Klaus
Guten Abend,
weiß jemand, wie ich an die Rücklauf-SOLL-Temperatur des HK2 rankomme, und zwar die, die im Register C2 der Calormatic 430 angezeigt wird?
Die dazugehörige IST-Temperatur bekomme ich mit ebusctl r Flow1Sensor, aber die an der Calormatic direkt darüber angezeigte SOLL-Temperatur kann ich nirgendwo finden.
Kann jemand helfen?
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.3.v3.3-13-gd366bbb
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available, vaillant/15.430.csv: different version available, vaillant/50.v61.mc.csv: different version available, vaillant/bai.0010003857.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 22
max symbol rate: 157
min arbitration micros: 6
max arbitration micros: 237
min symbol latency: 3
max symbol latency: 19
reconnects: 0
masters: 3
messages: 526
conditional: 20
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010003857.inc" ([PROD='0010009343']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=V6100;SW=0119;HW=1902", loaded "vaillant/50.v61.mc.csv"
Hello
sorry if my German search skills are not good, but I didn't immediately find an answer (it's a bit of a spider web to find information :) ).
I can read all the parameters from my vaillant heater and its thermostat thanks to your great ebus adapter.
But the next step is to take over control from my thermostat, so my questions:
- are there any (github)repositories that would be a good start for this and have already implemented a smart room temperature control using ebus commands?
- are there examples of completely eliminating the thermostat or do we have to keep the thermostat active and intervene the messages in some way?
My first goal is to find a way to turn my heater off if the house is empty instead of following the fixed thermostat schedule :).
ebusctl info
version: ebusd 3.3.v3.3
update check: revision v3.3-4-g212b22d available
signal: acquired
symbol rate: 23
max symbol rate: 125
min arbitration micros: 1188
max arbitration micros: 3150
min symbol latency: 4
max symbol latency: 6
reconnects: 0
masters: 5
messages: 351
conditional: 2
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0202;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 11: master #7
address 15: slave #2, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102", loaded "vaillant/15.f37.csv"
address 16: slave #7, scanned "MF=Vaillant;ID=B7000;SW=0120;HW=6202"
address 26: slave, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Vaillant;ID=F3700;SW=0114;HW=6102"
Frage: Haben häufige Abfragen über den ebus Einfluss auf die Lebensdauer der Platine einer Therme?
Hintergrund: Vaillant ecoTEC plus gut 9 Jahre alt, kommerzieller ebus, seit fast 4 Jahren FHEM mit ebusd (2.).
Die Therme hatte in den letzten Monaten gelegentlich timeouts und crc-Fehler. Nun ist sie mit Fehler F27 Flammenwächter ganz ausgefallen. Der HB hat die Platine ersetzt.
In der Periode ohne Heizung reduziere ich die Abfragen. Frage ohne f ab. Update von Einstellungen sehr selten bzw. Änderungen an der auroMATIC 620.
Nein. Du solltest nur nicht den internen Verkehr auf dem eBus durch zu häufige Anfragen stören. In der Regel macht man das nicht. Man hört ja erst einmal den Verkehr ab und nutzt die nächste Pause.
mfg klaus
ZitatIn der Regel macht man das nicht. Man hört ja erst einmal den Verkehr ab und nutzt die nächste Pause.
Das halte ich für grandiosen Unsinn. Der eBus ist für Multi-Master-Betrieb vorgesehen, und das "Warten auf Pause" ist eben nicht Bestandteil des normalen Betriebs.
@goosst: This is not a good idea, nor is it good practice. A software system driving your heater should be autonomous and certified for safety by third party testers - which is the case in every commercial system. Using your own software to drive the heater might severely shorten the lifetime of the heater, might be environmentally harmful and might even cause fatal accidents to persons. For very good reason it is even unlawful to tinker with the central heating control in several countries of the European Union.
This does in no way prevent you from influencing your heater system by using external commands. One may even trick the "safe" commercial system into believing really weird stuff - some examples are presented in the
Smart Home Hacks.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 04 Mai 2019, 20:02:42
Das halte ich für grandiosen Unsinn. Der eBus ist für Multi-Master-Betrieb vorgesehen, und das "Warten auf Pause" ist eben nicht Bestandteil des normalen Betriebs.
abgesehen davon, dass es Teil des eBUS Protokolls ist, auf das nächste SYN Zeichen zu warten ;)
zu meiner Frage: Lebensdauer und ebusd-Abfragen, vielen Dank für die Antworten.
Ich lese daraus, dass häufige Abfragen über ebusd (ECMD) keinen Einfluss auf die Lebensdauer der Therme-Platine haben.
Und folgere: Die Gründe liegen vermutlich wo anders, an der Umgebung: Heizungskeller, sowie Luftfeuchte und dgl.
Derzeit habe ich humidity: 41% (HM...EU), 43% (Xiaomi), Temp 19,2 °C
Die Platinen sind halt empfindlich, sitzen in der Therme eben auch im Thermisch belasteten Bereich. Meine Therme ist nun 8 Jahre alt und macht auch Zicken. Gerne gehen da Elkos und dergleichen kaputt. Teilweise sind die aber auch reparabel...
Grüße
Christian
Guten Morgen zusammen,
ich versuche gerade die Weishaupt-Definitionen von J0EK3R an meine Anlage zu adaptieren. Dabei bin ich auf folgendes Problem gestoßen, was ich mir im Moment null erklären kann. Ich würde gerne die Zeitprogramme der Anlage auslesen, das hat J0EK3R auch für seine Anlage definiert und rein grundsätzlich funktioniert das auch für meine Anlage, das Problem ist aber, dass eigentlich in der EBUS-Antwort die Ende-Zeit des Programmes, sowie die Start-Zeit des Programmes jeweils in einem Byte geschickt werden (zuerst Ende, dann Start). Das ganze dann als vielfaches von 15 Minuten.
Damit bekomme ich z.B. folgendes zurück:
31355022021014 / 025c17 = 1: hc1 HP1.Mo.1 Das wäre nun mein 1. Heizprogramm für Montag 5c steht für 23:00 Ende und 17 für 5:45 start.
Die Definition von JOEK3R sieht nun folgendermaßen aus (Auszug):
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field1,part (m;s),type / templates,divider / values,unit,comment,field2,p$
#,,Zeitprogramme Heizkreis,,,,,,,,,,,
*r,,,,,"35","5022",,,,,,,
r,,HP1.Mo.1,Heizprogramm 1 Mo 1 Start/Ende (Anwender 121) ,,,,"1014",,,_8_TimeStart,,, ,,,_8_TimeEnd,,,
Template Definition:
# Field Templates für Start/Ende-Zeit der Programme,,,,
_8_TimeStart:Start,TTQ,,,Startzeit
_8_TimeEnd:End,TTQ,,,Endezeit
Jetzt zu meinem Problem: Ich bekomme vom EBUSD immer nur die Endzeit ausgewertet, also die vollständige Rückmeldung zu dem Telegram sieht dann so aus:
localhost: r -c hc1 HP1.Mo.1
23:00;23:00
Das evtl. Start und Ende oben noch verdreht sind, würde ich verstehen, aber ich verstehe nicht, dass ich obwohl ja 2 Bytes zurückkommen bei der Template-Definition von oben nur das erste, und dann auch noch für beide Werte genutzt wird. Habt ihr da noch nen Tip für mich?
VG und Danke!
Zitat von: Wardancer am 29 Juni 2019, 06:54:43
Jetzt zu meinem Problem: Ich bekomme vom EBUSD immer nur die Endzeit ausgewertet, also die vollständige Rückmeldung zu dem Telegram sieht dann so aus:
da hast du eine gute Lücke gefunden, ist mit commit c26f7b3 (https://github.com/john30/ebusd/commit/c26f7b3b07f61af17771b9234088eabf089388df) gelöst.
Hintergrund der Problematik ist, dass der Datentyp weniger als ein ganzes byte verbraucht.
Narbend,
Ich Dreh durch... jetzt gehts :)
Danke!
Wäre das auch beim Schreiben nen Problem, oder hast du es da direkt mit gefixt?
Zitat von: Wardancer am 30 Juni 2019, 00:07:07
Wäre das auch beim Schreiben nen Problem, oder hast du es da direkt mit gefixt?
sollte beim Schreiben jetzt auch klappen
Moin zusammen,
ich beschäftige mich gerade wieder mal mit dem Schreiben.
Jetzt ist es so, dass meine Weishaupt-Therme gerne Telegramme empfangen würde, die beim Schreiben immer einen festen Suffix haben, nämlich:
05d010000
Bisher sind die Befehle und auch das Payload in den Template-Definitionen ziemlich sinnvoll geblockt. Ich hab nur leider keine Ahnung, wie ich da jetzt noch einen festen Wert dahinter bekommen würde.
Gibt es einen geschickten Weg sowas in die Template-Definitionen hereinzubekommen?
Ein vollständiges Telegram sieht z.B. so aus:
Quelle:Ziel:Befehl:Länge:Adresse:Payload:Suffix
ff3050230994221480805d010000
Die Definition dazu in meinen Configs sieht bisher so aus. Hinten müsste halt noch irgendwie das 05d010000 ran....
w,,HP1.Di.3,Heizprogramm 1 Di 3 Start/Ende (Anwender 122) ,,,,"942214",,,_8_TimeEnd,,, ,,,_8_TimeStart,,,
Zitat von: Wardancer am 19 Juli 2019, 08:19:07
Die Definition dazu in meinen Configs sieht bisher so aus. Hinten müsste halt noch irgendwie das 05d010000 ran....
w,,HP1.Di.3,Heizprogramm 1 Di 3 Start/Ende (Anwender 122) ,,,,"942214",,,_8_TimeEnd,,, ,,,_8_TimeStart,,,
feste Suffixe gehen derzeit noch nicht
Hmm, gibt es denn eine andere Variante? Könnte ich z.B. einfach ein drittes Payload schicken, nach dem 8_TimeStart? Dann wäre ich ja fast fein raus...
Zitat von: Wardancer am 21 Juli 2019, 10:07:14
Hmm, gibt es denn eine andere Variante? Könnte ich z.B. einfach ein drittes Payload schicken, nach dem 8_TimeStart? Dann wäre ich ja fast fein raus...
nein, das muss ja in eine einzige Message rein. Du könntest aber noch ein letztes Feld an die Defintion anhängen, bspw. mit HEX:4 und dem konstanten Wert in der Spalte values ("=5d010000")
Na,
ich denke das trifft es ja eigentlich ziemlich genau. Ist zwar etwas Tiparbeit, da es wohl bei jedem Write mit dazu müsste, aber was solls.
Ich habe aber, bevor ich mich da wirklich reinstürzen kann irgendwie noch ein grundsätzlicheres Problem:
Es scheint egal zu sein, was ich schreiben will, EBUSD quittiert das mit einem
"ERR: element not found". Ich hab auch schon geschaut, ich hab in der ebusd-config den Acceslevel mit --accesslevel=* frei geschaltet.
Bei den w und r Kommandos hab ich hier mal ein Beispiel eingefügt:
localhost: r -c hc1 StartOfHoliday.Year
19
localhost: w -c hc1 StartOfHoliday.Year 18
ERR: element not found
Die Definition dazu müsste eigentlich passen:
r,,StartOfHoliday.Year,Urlaubsanfang Jahr (181) ,,,,"1d0102",,,_16_HolidayDay,,,
w,,StartOfHoliday.Year, ,,,,"1d01",,,_16_HolidayDay,,,
per Hex könnte ich die Sachen setzen, aber ich wollte das ganze eigentlich per MQTT weitertragen.
Hier noch der Vollständigkeit halber die Ausgabe vom Info:
version: ebusd 3.3.v3.3-23-gf3bfe77
update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 107
min arbitration micros: 3
max arbitration micros: 412
min symbol latency: 4
max symbol latency: 13
reconnects: 0
masters: 5
messages: 361
conditional: 0
poll: 0
update: 8
address 03: master #11
address 04: slave #25, ebusd, conflict, scanned "MF=Kromschroeder;ID=;SW=0376;HW=-", loaded "kromschroeder/04..EA.csv"
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=1200;HW=0302", loaded "kromschroeder/08..sc.csv"
address 0c: slave #16, scanned "MF=-;ID=??;SW=-;HW=-"
address 30: master #3
address 35: slave #3, scanned "MF=Kromschroeder;ID=W ;SW=2730;HW=-", loaded "kromschroeder/35..hc1.csv"
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302", loaded "kromschroeder/f6..sc.csv"
address ff: master #25, ebusd, conflict
Hab ich da was übersehen? Danke für einen Gedankenanstoss ....
Zitat von: Wardancer am 22 Juli 2019, 23:10:40
Die Definition dazu müsste eigentlich passen:
r,,StartOfHoliday.Year,Urlaubsanfang Jahr (181) ,,,,"1d0102",,,_16_HolidayDay,,,
w,,StartOfHoliday.Year, ,,,,"1d01",,,_16_HolidayDay,,,
schau doch einfach mal, ob ein "find" das auch liefert, also bspw. "ebusctl find -f -w StartOfHoliday.Year"
Hi,
also es wird was gefunden:
localhost: find -f -w StartOfHoliday.Year
w,hc1,StartOfHoliday.Year, ,,35,0903,1d01,_16_HolidayDay,m,UIN,0=Off,,Tag
sieht für mich eigentlich schlüssig aus.
Was bei mir auch nicht funktioniert ist, per write -h XXXXXXX hex zu schicken. ebusctl zeigt mir dann immer wieder die Syntax-Hilfe zum write.Den gleichen String per hex-Kommando zu schicken geht aber ohne Probleme. Kann das was miteinander zu tun haben?
Zitat von: Wardancer am 23 Juli 2019, 18:23:21
localhost: find -f -w StartOfHoliday.Year
w,hc1,StartOfHoliday.Year, ,,35,0903,1d01,_16_HolidayDay,m,UIN,0=Off,,Tag
sieht für mich eigentlich schlüssig aus.
merkwürdig. Versuch bitte mal den Punkt aus dem Namen in der Definition rauszunehmen.
Zitat von: Wardancer am 23 Juli 2019, 18:23:21
Was bei mir auch nicht funktioniert ist, per write -h XXXXXXX hex zu schicken. ebusctl zeigt mir dann immer wieder die Syntax-Hilfe zum write.Den gleichen String per hex-Kommando zu schicken geht aber ohne Probleme. Kann das was miteinander zu tun haben?
das liegt dann daran, dass die Nachricht mit dem Namen nicht gefunden wird. wie gesagt, probier mal den Punkt zu entfernen
Punkt raus ... aber leider bleibt das Verhalten gleich:
localhost: r -c hc1 StartOfHolidayDay
18
localhost: w -c hc1 StartOfHolidayDay 19
ERR: element not found
localhost: find -f -w StartOfHolidayDay
w,hc1,StartOfHolidayDay, ,,35,0903,1b01,_16_HolidayDay,m,UIN,0=Off,,Tag
Zitat von: Wardancer am 24 Juli 2019, 09:03:02
Punkt raus ... aber leider bleibt das Verhalten gleich:
localhost: r -c hc1 StartOfHolidayDay
18
localhost: w -c hc1 StartOfHolidayDay 19
ERR: element not found
localhost: find -f -w StartOfHolidayDay
w,hc1,StartOfHolidayDay, ,,35,0903,1b01,_16_HolidayDay,m,UIN,0=Off,,Tag
ach je, da war ich aber auch blind... du hast eine Werteliste definiert mit 0=Off, d.h. das einzig gültige Argument hinter "w -c hc1 StartOfHolidayDay " wäre "Off"...
Danke!
genau so hats geklappt ... da war ich wohl auch etwas blind!
Hi John,
ich habe nochmal eine Frage zum Abfragezyklus, verwendete Version ist ebusd 3.0pre.c57c3e7 und weil das eigentlich ganz gut läuft würde ich ungern daran was ändern (never change a running system...). Bislang habe ich alle Werte nacheinander mittels Klasse, wie von PAH beschrieben ca. alle 30s abgefragt, dann in Readingsproxys angezeigt. Soweit alles prima, führt aber zu Freeze-Zeiten. Nicht viel, aber eben ein wenig. Nun hab ich von Reinhardt das Find-Script mal probiert und mir das so hingestrickt, dass die Werte alle in die Readings aufgespalten werden, statt das einfach zeilenweise untereinander zu schreiben. Darauf könnte ich wiederum Readingsproxys setzen, so dass sich optisch zum Vorstand nichts ändert. Ich hatte mit 60s und mit 30s Timer für abrufen des Find -d aus FHEM heraus probiert. Ich habe auch bei den Werten in der bai...inc jeweils bei den benötigten aus r dann r1 gemacht, damit die möglichst häufig refresht werden. Ich hatte verstanden, dass die dann bei jedem Zyklus, den der EBUS durchläuft refresht werden. Aber ich bekomme damit nicht die Auflösung hin, die ich vorher mit den Einzelabfragen hatte. So kann ich z.B. teilweise am Vorlauf nicht mehr sehen, wann der Brenner gestartet ist.
Frage: Mach ich da was falsch oder kann ich irgendwie anders noch die Abfrageintervalle in EBUSD beeinflussen ? Oder gibt es sonst eine Möglichkeit in FHEM die Werte non-blocking abzufragen ?
Schöne Grüße
Christian
um das Problem "blocking" elegant zu umgehen kannst du ja einmal testweise MQTT2 einsetzen!
Das hat den Vorteil, dass die wichtigsten Daten wie Vorlauf, Rücklauf ja über die Statusmeldungen alle paar Sekunden über den Bus kommen und die kannst du dann beliebig auswerten. MQTT2 ist ja soweit weiter entwickelt, dass auch kein Mosquitto Server mehr benötigt wird und du auch bequem Templates einsetzen kannst. Mit autocreate wird auch alles automatisch angelegt un du kannst beliebig experimentieren, weil du damit die ECMD Abfragen nicht beeinflusst und das alles zum Test parallel laufen lassen kannst.
Internals:
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
FUUID 5c9144bc-f33f-27bd-8f79-fe0e0b9e014cc7ee
IODev ebusMQTT
NAME MQTT2_ebusd_bai
NR 2748
STATE ???
TYPE MQTT2_DEVICE
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
Status02_0_value _HWCMode
Status02_1_value _Maximaltemperatur
Status02_2_value _ReglerMaxTEMP
Status02_3_value _ReglerCurrentTemp
READINGS:
2019-07-29 05:09:07 CounterStartattempts1_temp0_value 29
2019-07-29 10:56:44 DateTime_bdate_value -.-.-
2019-07-29 10:56:44 DateTime_btime_value 07:06:52
2019-07-29 10:56:44 DateTime_dcfstate_value nosignal
2019-07-29 10:56:44 DateTime_temp2_value 18.000
2019-07-29 05:09:06 DeactivationsIFC_0_name
2019-07-29 05:09:06 DeactivationsIFC_0_value 18
2019-07-29 05:09:06 FanHours_hoursum2_value 6692
2019-07-29 10:45:08 FanSpeed_0_name
2019-07-29 10:45:08 FanSpeed_0_value 2271
2019-07-29 10:45:08 FlowTempDesired_temp_value 21.50
2019-07-29 10:45:08 FlowTemp_sensor_value ok
2019-07-29 10:45:08 FlowTemp_temp_value 58.38
2019-07-29 05:09:06 HcHours_hoursum2_value 5703
2019-07-29 05:09:05 HcStarts_0_name
2019-07-29 05:09:05 HcStarts_0_value 42300
2019-07-29 05:09:06 HwcHours_hoursum2_value 746
2019-07-29 05:09:07 HwcSetPotmeter_temp_value 48.94
2019-07-29 05:09:05 HwcStarts_0_name
2019-07-29 05:09:05 HwcStarts_0_value 98600
2019-07-29 10:45:02 OutdoorstempSensor_sensor_value ok
2019-07-29 10:45:02 OutdoorstempSensor_temp_value 18.00
2019-07-29 05:09:11 PartloadHcKW_power_value 18
2019-07-29 10:45:08 ReturnTemp_sensor_value ok
2019-07-29 10:45:08 ReturnTemp_temp_value 59.25
2019-07-29 10:45:08 ReturnTemp_tempmirror_value 64587
2019-07-29 10:56:48 SetMode_disablehc_value 0
2019-07-29 10:56:48 SetMode_disablehwcload_value 1
2019-07-29 10:56:48 SetMode_disablehwctapping_value 0
2019-07-29 10:56:48 SetMode_flowtempdesired_value 21.5
2019-07-29 10:56:48 SetMode_hcmode_value auto
2019-07-29 10:56:48 SetMode_releaseBackup_value 0
2019-07-29 10:56:48 SetMode_releaseCooling_value 0
2019-07-29 10:56:48 SetMode_remoteControlHcPump_value 0
2019-07-29 10:56:49 Status01_0_name temp1
2019-07-29 10:56:49 Status01_1_name temp1
2019-07-29 10:56:49 Status01_2_name temp2
2019-07-29 10:56:49 Status01_3_name temp1
2019-07-29 10:56:49 Status01_4_name temp1
2019-07-29 10:56:49 Status01_5_name pumpstate
2019-07-29 10:56:49 Status02_0_name hwcmode
2019-07-29 10:56:49 Status02_1_name temp0
2019-07-29 10:56:49 Status02_2_name temp1
2019-07-29 10:56:49 Status02_3_name temp0
2019-07-29 10:56:49 Status02_4_name temp1
2019-07-29 10:56:49 Status02_4_value 48.0
2019-07-29 10:45:08 WPPWMPower_percent0_value 100
2019-07-29 10:45:07 WaterPressure_press_value 1.559
2019-07-29 10:45:07 WaterPressure_sensor_value ok
2019-07-29 10:56:49 _Aussentemp 18.000
2019-07-29 10:56:49 _HWCMode auto
2019-07-29 10:56:49 _Maximaltemperatur 60
2019-07-29 10:56:49 _Pumpenstatus off
2019-07-29 10:56:49 _ReglerCurrentTemp 70
2019-07-29 10:56:49 _ReglerMaxTEMP 70.0
2019-07-29 10:56:49 _Ruecklauf 52.0
2019-07-29 10:56:49 _Vorlauf 52.0
2019-07-29 10:56:49 _WWSpeicher 47.0
2019-07-29 10:56:49 _Warmwasser 49.0
2019-07-29 10:56:47 outsidetemp_temp2_value 16.000
2019-07-29 10:56:45 vdatetime_date_value 28.07.2019
2019-07-29 10:56:45 vdatetime_time_value 10:47:17
Attributes:
DbLogExclude .*
IODev ebusMQTT
devStateStyle style="text-align:right"
icon sani_boiler_temp
jsonMap Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
Status02_0_value:_HWCMode
Status02_1_value:_Maximaltemperatur
Status02_2_value:_ReglerMaxTEMP
Status02_3_value:_ReglerCurrentTemp
Ich habe alles auf MQTT2 (Server ohne Mosquitto) umgestellt weil ich es einfacher und transparenter finde. eBusd kann das ja schon lange wenn du die config erweiterst.
Im Anhang ein paar Möglichkeiten der Darstellung wie sie von den Templates automatisch erzeugt werden.
LG
Hallo Reinhart,
um MQTT(2) hab ich bislang einen großen Bogen gemacht, das war für mich irgendwie nicht so selbsterklärend. Trotzdem hab ich z.B. einen Dimmer, der damit arbeitet... Aber: Kann meine Version denn überhaupt schon MQTT2 ? Oder brauche ich dafür eine (neue) andere Version ?
Grüße Christian
nein, eBusd kann das schon lange. Bei MQTT2 geht es um eine komplett überarbeitete Version die gegenüber MQTT eigentlich nur Vorteile hat.
Es gibt auch ein Wiki (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele#eBus)wo das wesentliche über MQTT2 geschrieben steht.
Hier das Wiki speziell zum eBus (https://wiki.fhem.de/wiki/EBUS-MQTT2).
LG
Ich brauche also keine spezielle MQTT-Version vom EBUSD ? Ich frage, weil ich bei John schon Packages gesehen habe, wo im Dateinamen MQTT drin ist...ähm, sicherlich eine blöde Frage, aber wie bekomm ich denn mein EBUSd dazu, an MQTT zu senden ?
das ist natürlich klar und da hast du auch mit deiner Frage recht, entweder du nimmst die Version inkl. Mqtt oder compilierst sie selber.
Ich meinte nur damit das es schon lange von John so implementiert wurde.
LG
...ah mist... ich dachte mir sowas... da kommt die Frage auf: Wie kann man denn auf eine solche Version updaten ? Vorhandene über remove entfernen und dann die MQTT-Version installieren oder gibt's da einen eleganteren Weg ?
Offtopic Frage:
Seit ca. 10 Tagen will meine Gastherme nicht mehr, leider erst gestern gemerkt (da Warmwasser über Solar lief).
In den eBUS Logs sieht man gut, daß auf einmal keine Werte mehr vom Wasserdruck, HK-Vorlauf, HK-Rücklauf, Flammenstatus geliefert wurden.
Hardware: Vaillant ecoTEC plus VC DE 126/3-5 Gastherme (BJ 2013)
230V liegen an; Feinsicherung in Ordnung; 24V an der eBus Schnittstelle. Aber kein Display, keine Fehlercodes, keine Brennerstarts
In Foren liest man teilweise von defekten 470uF/35V/85° Kondensatoren.
Bei mir sind aber bereits 105° Modelle verbaut. Optisch sehen sie i.O. aus.
Hat jemand eine Idee wo ich den Fehler suchen kann?
Wenn sich da gar nichts mehr beim Einschalten bewegt, könnte ggf. auch die runde Sicherung T4A (ESKA steht da drauf) durch sein, die da neben dem einen Kondensator ist...
Zitat von: cs-online am 28 September 2019, 21:32:17
...ah mist... ich dachte mir sowas... da kommt die Frage auf: Wie kann man denn auf eine solche Version updaten ? Vorhandene über remove entfernen und dann die MQTT-Version installieren oder gibt's da einen eleganteren Weg ?
mehr oder weniger geht es eh nur um die Binary, einfach die austauschen und die config erweitern. Du hast ja eh schon eine der letzten Versionen drauf.
--mqttport=1883 --mqttjson --mqtthost=ip-address --mqtttopic=ebusd/%circuit/%nameLG
Jo und schon geht der Ärger los, auf neueste Version upgedatet, configfile angepasst:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
# In order to run multiple ebusd instances, simply define several EBUSD_OPTS
# with a unique suffix for each.
# Recommended is using a number as suffix for all EBUSD_OPTS settings.
# That number can then be used as additional "instance" parameter to the init.d
# script in order to start/stop an individual ebusd instance instead of all
# instances.
# Example (uncomment the EBUSD_OPTS above):
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
#EBUSD_OPTS1="--scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log --mqttport=1883 --mqttjson --mqtthost=192.168.2.22 --mqtttopic=ebusd/%circuit/%name"
#EBUSD_OPTS2="--scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log --mqttport=1883 --mqttjson --mqtthost=192.168.2.22 --mqtttopic=ebusd/%circuit/%name"
EBUSD_OPTS1="--configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log"
die CSVs im Vailllant-Ordner liegen unter
/etc/ebusd
kommt trotzdem (wenn ich im Terminal "ebusd" eingebe) diese Fehlermeldung:
2019-09-29 12:45:51.583 [main error] invalid configpath without scanconfig
wenn ich versuche, ebusd mit ebusd -- und dann die Zeile aus der Config zu starten, kommt kein Fehler, aber wenn ich dann ebusctl aufrufe kommt:
error connecting to localhost:8888
Der WAF ist grad voll im Keller, was mach ich denn da nun falsch ?
Grüße
Christian
Zitat von: cs-online am 29 September 2019, 12:52:11
Jo und schon geht der Ärger los, auf neueste Version upgedatet, configfile angepasst:
was hast du denn im configfile angepasst? Idealerweise wäre da ja nichts zu ändern gewesen.
Zitat von: cs-online am 29 September 2019, 12:52:11
kommt trotzdem (wenn ich im Terminal "ebusd" eingebe) diese Fehlermeldung:
also "ebusd" ohne was im Terminal einzugeben kann ja nun per Defitinion nichts bringen. ebusd ist ein Dienst und ein Dienst will konfiguriert werden. Das Starten des Diensts übernimmt ein Script, das wiederum die Konfiguration aus /etc/default/ebusd liest.
Also wenn dann bitte den Dienst ordentlich beenden und wieder starten (bspw. "service ebusd restart") oder sämtliche Parameter an "ebusd ..." übergeben (das ist aber nur zum kurzen Debugging geeignet).
Hi John,
die einzige Zeile, die ich im config-File praktisch drin habe (neben vielem auskommentiertem) wäre
EBUSD_OPTS1="--configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log"
Ich habe sonst eigentlich noch eine zweite Instanz drin gehabt, die habe ich nun erst zum testen, bis es läuft auskommentiert
Und ich würde gerne die alten CSVs weiter nutzen, weil ich da diverse Sachen angepasst habe. Sind die von der 3.0 eigentlich noch kompatibel zur neuen Version ?
Aber auch, wenn ich mit
ebusd --configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log
zum Probieren starte (zumindest meine ich, dass ich früher immer so testen konnte), kommt beim Aufruf von ebusctl
error connecting to localhost:8888
Zitat von: cs-online am 29 September 2019, 16:58:28
Und ich würde gerne die alten CSVs weiter nutzen, weil ich da diverse Sachen angepasst habe. Sind die von der 3.0 eigentlich noch kompatibel zur neuen Version ?
ja
prüfe doch mal, ob noch eine Instanz auf dem Port läuft, bspw mit "ps aux|grep ebusd".
Und was steht denn in /var/log/ebusd1.log so drin?
Hi John,
fast geschafft, ich habe EBUSD jetzt nochmal deinstalliert und nochmal neu installiert (System läuft auf RPI2 mit Jessie), aber das Log in ebusd1-log war leer und in ebusd.log war auch nur das hier drin:
2019-10-01 19:01:55.584 [main notice] ebusd 3.3.v3.3 started with auto scan
2019-10-01 19:01:55.838 [bus notice] bus started with own address 31/36
2019-10-01 19:04:03.885 [main notice] update check: revision v3.3-4-g212b22d available, broadcast.csv: different version available
2019-10-01 19:10:32.870 [main notice] SIGTERM received
2019-10-01 19:10:35.931 [main notice] ebusd stopped
dann aber unter
pi@FHEM-Jessie:~ $ systemctl status ebusd.service
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd.service; enabled)
Active: active (running) since Di 2019-10-01 19:16:49 CEST; 45s ago
Process: 7178 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 7179 (ebusd)
CGroup: /system.slice/ebusd.service
└─7179 /usr/bin/ebusd --configpath=/etc/ebusd --scanconfig --acces...
gesehen, dass der aus EBUSD_OPTS und nicht aus EBUSD_OPTS1 die Configzeile nimmt. Das dann bei der Configzeile auf ohne 1 geändert und voila, nun YIPPIE !!! klappt das schon mal.
Erst mal super vielen Dank, du hast mir wie immer sehr geholfen !!!!!!
Schöne Grüße
Christian
ähm, eine Frage habe ich noch:
muss ich, wenn ich die Daten per MQTT senden lassen möchte noch angeben, welche Daten gesendet werden sollen oder werden immer alle gesendet, die auf dem Bus auflaufen ? Ich habe das jetzt ca. 15 Minuten laufen lassen und bekomme nur diese Readings:
associatedWith
MQTT2_ebusd
2019-10-01 20:24:21
formatedUptime
0 000 00:13
2019-10-01 20:34:58
running
true
2019-10-01 20:21:06
scan.08_HW_value
7401
2019-10-01 20:21:18
scan.08_ID_value
BAI00
2019-10-01 20:21:18
scan.08_MF_value
Vaillant
2019-10-01 20:21:18
scan.08_SW_value
0703
2019-10-01 20:21:18
scan.15_HW_value
6002
2019-10-01 20:21:21
scan.15_ID_value
47000
2019-10-01 20:21:21
scan.15_MF_value
Vaillant
2019-10-01 20:21:21
scan.15_SW_value
0126
2019-10-01 20:21:21
signal
true
2019-10-01 20:21:22
state
getKnown
2019-10-01 20:32:22
updatecheck
"revision v3.3-4-g212b22d available, broadcast.csv: newer version available, vaillant/08.bai.csv: newer version available, vaillant/15.470.csv: newer version available, vaillant/bai.0010004121.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: newer version available"
2019-10-01 20:23:29
uptime
832
2019-10-01 20:34:58
vdatetime_date_value
01.10.2019
2019-10-01 20:31:31
vdatetime_time_value
20:31:30
2019-10-01 20:31:31
version
"ebusd 3.3.v3.3"
Wenn ich ein find -d sende, dann bekomme ich eine Menge mehr Daten...
Laut Wiki müssten dann auch neben den RedingList-Einträgen auch MQTT2-Devices angelegt werden, obwohl sowohl im MQTT2_DEVICE autocreate auf 1, als auch im MQTT2_CLIENT autocreate auf complex steht, werden (soweit ich das sehen kann) keine weiteren Devices angelegt...
Moin eBusd-Gemeinde,
da ich auch vorhabe, auf MQTT2 umzusteigen, weil mir der jetzt bei mir laufende GAEBUS doch zu unflexibel ist (u.a. keine Broadcast-Daten), verfolge ich die letzten Beiträge in diesem Thread mit viel Interesse.
Dabei bleiben bei mir aber noch einige Fragezeichen ?????????
1. Gemäß Wiki EBUS-MQTT2 brauche ich nur einen laufenden eBus-Daemon und eine Anpassung der Config, damit der EBus seine Daten auch an den MQTT2 senden kann. Derzeit läuft bei mir "version: ebusd 3.3.v3.3". Reicht das aus?
2. Ich möchte mein derzeitiges System an meiner Vaillant EcoCompact zunächst weiter als Produktivsystem auf der bisherigen Implementation laufen lassen und den MQTT2-Teil sowie FHEM auf einem weiteren Raspi realisieren, weil ich das funktionierende System nicht abhängen will, und auch den Ebus für MQTT2 aus topografischen Gründen nicht direkt am Heizgerät nochmal anzapfen kann und will.
Geht das prinzipiell und wie gehe ich dabei am besten vor?
Es wäre sehr hilfreich, wenn mir die Wissenden hier im Forum etwas auf die Sprünge helfen und die Anzahl meiner Fragezeichen etwas verringern könnten. 8)
Greetz von der Küste
Det :)
Hallo,
die erste Frage kann ich dir beantworten, weil ich das gerade durch habe: Du brauchst die Version mit MQTT im Dateinamen. Wenn du die hast, dann klappt das schon mal, die habe ich nämlich auch gerade installiert. Wenn du nicht genau weißt, ob deine mit MQTT oder ohne ist, kannst du in der config vom ebusd unter /etc/Default/ebusd mal testweise analog den Eintrag hinten an die EBUSD_OPT anhängen und schauen, ob der dann mit oder ohne Fehler startet, bei mir gab's einen Fehler, weil MQTT nicht im Paket war (hatte die 3.0pre)
--mqttjson --mqtthost=IPVOM EBUSD --mqtttopic=ebusd/%circuit/%name
Grüße
Christian
Christian,
vielen Dank für die schnelle Antwort. Hatte zwar Deine Konversation mit Reinhart und John gelesen, wurde aber daraus nicht so ganz schlau (geht ja gar nicht für den Schlauen Det ;)).
Hast Du die Version mit mit mqtt0 oder mit mqtt1 genommen?
Cheers
Det :)
Ich habe das auf dem RPI mit Jessie laufen, also die armhf-Variante und da gabs nur eine mit MQTT...
Wenn du dir aber nicht ganz sicher bist, kannst du hier lesen, wie du per update die richtige Version bekommst und istallierst:
https://github.com/john30/ebusd-debian/blob/master/README.md
Thnx Christian,
mein Raspi läuft auf Stretch und ich sehe gerade, dass es da auch nur eine <ebusd-3.3_armhf-stretch_mqtt1.deb> gibt.
Hatte wohl vorher irgendwie bei den anderen Packages geschaut, wo es auch die Nuller-Versionen für mqtt gibt.
Ist ja alles ziemlich kompliziert für einen alten Mann ;) ;D
Ciao
Det :)
Also es kommen "von selbst" nur die Broadcast per MQTT2 an. Wenn du weitere Daten benötigst, verhält sich das gleich wie bei ECMD, also du musst die Daten anfordern.
Das geht bei MQTT so wie im Wiki beschrieben (https://wiki.fhem.de/wiki/EBUS-MQTT2#Regelm.C3.A4.C3.9Fige_Werteabfrage). Also einen "get" Befehl mit deiner Topic und dem gewünschten Datensatz absetzen. Hier ist der Timer auf 10 Minuten gesetzt.
+*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/Status02/get;
set ebusMQTT publish ebusd/bai/HcHours/get;
set ebusMQTT publish ebusd/bai/HwcStarts/get
hier ein Beispiel.
Im Prinzip also ähnlich wie bei ECMD nur das Protokoll ist ein anderes und es entfällt natürlich der Perl Code in der erweiterten Utils (bai00.cfg).
LG
hmmm.... aber in der Hilfe vom EBUSD steht doch
--mqttretain Retain all topics instead of only selected global ones
Ich hätte gedacht, dass dann wirklich alle gesendet werden, ohne dass man die aktiv abfragen muss oder ?
Grüße
Christian
@Reinhart:
Jetzt mischen sich die Beiträge vielleicht etwas. Deshalb mein derzeitiger Stand:
Zitat von: Schlauer Det am 02 Oktober 2019, 09:49:01
Moin eBusd-Gemeinde,
da ich auch vorhabe, auf MQTT2 umzusteigen, weil mir der jetzt bei mir laufende GAEBUS doch zu unflexibel ist (u.a. keine Broadcast-Daten), verfolge ich die letzten Beiträge in diesem Thread mit viel Interesse.
Dabei bleiben bei mir aber noch einige Fragezeichen ?????????
1. Gemäß Wiki EBUS-MQTT2 brauche ich nur einen laufenden eBus-Daemon und eine Anpassung der Config, damit der EBus seine Daten auch an den MQTT2 senden kann. Derzeit läuft bei mir "version: ebusd 3.3.v3.3". Reicht das aus?
Gemäß der Information von Christian (@cs-online) reicht das aber nicht aus und ich brauche einen neuen eBus-Daemon.
In meinem Fall schätze ich mal, dass ich mit dem hier gut bedient bin: https://github.com/john30/ebusd/releases/download/v3.3/ebusd-3.3_armhf-stretch_mqtt1.deb (https://github.com/john30/ebusd/releases/download/v3.3/ebusd-3.3_armhf-stretch_mqtt1.deb).
Kann das bitte einer der Erfahrungsträger hier im Forum bestätigen?
Zitat
2. Ich möchte mein derzeitiges System an meiner Vaillant EcoCompact zunächst weiter als Produktivsystem auf der bisherigen Implementation laufen lassen und den MQTT2-Teil sowie FHEM auf einem weiteren Raspi realisieren, weil ich das funktionierende System nicht abhängen will, und auch den Ebus für MQTT2 aus topografischen Gründen nicht direkt am Heizgerät nochmal anzapfen kann und will.
Geht das prinzipiell und wie gehe ich dabei am besten vor?
Das bleibt die Nuss, die ich jetzt noch knacken muss:
Wenn ich auf dem zweiten Raspi den neuen eBus-Daemon mit MQTT-Eigenschaft laufen habe, sollte es wohl ausreichen, wenn ich die config entsprechend anspasse, damit die Broadcasts (und mehr brauche ich derzeit für ein proof of concept nicht) über eine IP-Verbindung und den auf Raspi 2 installierten MQTT-Server an FHEM weitergeleitet werden.
Es würde mich sehr freuen, wenn die Spezialisten mir da etwas Unterstützung angedeien lassen könnten.
Cheers aus dem windigen Nordland
Det :)
@Reinhart: Aber einfach nur den Timer mit den Publishes erstellen und laufen lassen bringt mir noch keine Readings mehr:
set MQTT_via_mosquitto publish ebusd/bai/HwcOPMode/get;
set MQTT_via_mosquitto publish ebusd/bai/errorhistory/get;
set MQTT_via_mosquitto publish ebusd/bai/currenterror/get;
set MQTT_via_mosquitto publish ebusd/bai/primarycircuitflowrate/get;
set MQTT_via_mosquitto publish ebusd/bai/wppwmPower/get;
set MQTT_via_mosquitto publish ebusd/bai/HwcHours/get;
set MQTT_via_mosquitto publish ebusd/bai/HcHours/get;
set MQTT_via_mosquitto publish ebusd/bai/Hc1HeatCurve/get;
set MQTT_via_mosquitto publish ebusd/bai/RemainingBoilerblocktime/get;
set MQTT_via_mosquitto publish ebusd/bai/CounterStartattempts2/get;
set MQTT_via_mosquitto publish ebusd/bai/CounterStartattempts1/get;
set MQTT_via_mosquitto publish ebusd/bai/PartloadHwcKW/get;
set MQTT_via_mosquitto publish ebusd/bai/FlowTemp/get;
set MQTT_via_mosquitto publish ebusd/bai/WaterPressure/get;
ich habe es auch hiermit probiert:
+*00:00:30 set myBroker publish ebusd/bai/HwcOPMode/get;
set myBroker publish ebusd/bai/errorhistory/get;
set myBroker publish ebusd/bai/currenterror/get;
set myBroker publish ebusd/bai/primarycircuitflowrate/get;
set myBroker publish ebusd/bai/wppwmPower/get;
set myBroker publish ebusd/bai/HwcHours/get;
set myBroker publish ebusd/bai/HcHours/get;
set myBroker publish ebusd/bai/Hc1HeatCurve/get;
set myBroker publish ebusd/bai/RemainingBoilerblocktime/get;
set myBroker publish ebusd/bai/CounterStartattempts2/get;
set myBroker publish ebusd/bai/CounterStartattempts1/get;
set myBroker publish ebusd/bai/PartloadHwcKW/get;
set myBroker publish ebusd/bai/FlowTemp/get;
set myBroker publish ebusd/bai/WaterPressure/get
Was muss ich denn nun wirklich tun, damit zumindest alle relevanten Readings ankommen ?
Zitat von: cs-online am 02 Oktober 2019, 19:49:45
hmmm.... aber in der Hilfe vom EBUSD steht doch
--mqttretain Retain all topics instead of only selected global ones
Ich hätte gedacht, dass dann wirklich alle gesendet werden, ohne dass man die aktiv abfragen muss oder ?
das hat damit gar nichts zu tun. Hier geht es nur darum, wie ebusd die Nachrichten an den MQTT Broker weiterleitet. Mittels retain sagt ebusd dem Broker, dass er alle Nachrichten für immer behalten soll, bis ebusd was anderes sagt.
OK, das hatte ich anders verstanden. MQTT ist nicht meins, sorry... Gibt's denn eine Möglichkeit, in kurzen Abständen alle Werte zu aktualisieren und zu senden ? Und gibt's auf der FHEM-Seite noch andere Möglichkeiten, als über Timer zu aktualisieren ? Das führt bei mir nämlich zu ähnlichen Freeze-Zeiten wie über ECMD... dabei für mich mal zum besseren Verständnis ein paar Fragen:
- wie lange dauert eigentlich ein Zyklus auf dem Bus, bis alle Werte einmal durchlaufen sind ?
- wenn in der CSV r1 angezogen ist, dann müsste doch bei jedem Zyklus der Wert refresht werden oder ? Wenn ich aber mit Find -d dann alle Daten abziehe, sind die teilweise schon mehrere Minuten alt
- gibt es einen Befehl, mit dem man r -f für alle Werte auf einmal aufrufen kann ?
mach es doch einmal schrittweise und erzähle was jetzt bei dir unter MQTT2 schon läuft.
Hast du den MQTT2 Server oder MQTT2 Client aktiviert? Hast du die Topic gesetzt und was legt "autocreate" an? Welche MQTT2_Devices werden automatisch angelegt? Es müssen zumindest alle Devices automatisch angelegt worden sein die über Broadcasts kommen.
Wenn die MQTT2_Server hast (also ohne Mosquitto), wie hast du den autocreate eingestellt (no, simple oder complex). Diese Einstellung ist primär entscheidend für die Readings die dann angelegt werden sollen. Ich empfehle dir "complex" zu verwenden, sonst kannst du Status01 und Status02 nicht unterscheiden.
Eigentlich sind es ja nur wenige Schritte (siehe Wiki) die notwendig sind das die Devices automatisch angelegt werden, erst wenn die Basis funktioniert kannst du dir Gedanken über die Abfragen machen und da auch überlegen was wirklich notwendig ist. Es macht ja nicht viel Sinn die gesamte Brennerlaufzeit alle 2 Minuten abzufragen, einmal am Tag ist doch da genug. Wobei der Vorlauf ist da schon interessanter und der kommt eh automatisch über den Broadcast an.
Es gibt beim eBus keinen zyklischen "Durchlauf", was sollte das der Kommunikation der Geräte untereinander bringen. Es kommen nur jede Daten über den Bus die gerade für Steuerzwecke dem anderen Gerät mitgeteilt werden. zB: ein interner Timer wird aktiv oder ein Alarm tritt auf. Wenn du am Steuergerät (Calormatic etc.) hantierst, werden eben mehr Daten über den Bus kommen, je nachdem was du da einstellst.
LG
Zitat von: Reinhart am 03 Oktober 2019, 20:15:58
mach es doch einmal schrittweise und erzähle was jetzt bei dir unter MQTT2 schon läuft.
Hast du den MQTT2 Server oder MQTT2 Client aktiviert? Hast du die Topic gesetzt und was legt "autocreate" an? Welche MQTT2_Devices werden automatisch angelegt? Es müssen zumindest alle Devices automatisch angelegt worden sein die über Broadcasts kommen.
Wenn die MQTT2_Server hast (also ohne Mosquitto), wie hast du den autocreate eingestellt (no, simple oder complex). Diese Einstellung ist primär entscheidend für die Readings die dann angelegt werden sollen. Ich empfehle dir "complex" zu verwenden, sonst kannst du Status01 und Status02 nicht unterscheiden.
Eigentlich sind es ja nur wenige Schritte (siehe Wiki) die notwendig sind das die Devices automatisch angelegt werden, erst wenn die Basis funktioniert kannst du dir Gedanken über die Abfragen machen und da auch überlegen was wirklich notwendig ist. Es macht ja nicht viel Sinn die gesamte Brennerlaufzeit alle 2 Minuten abzufragen, einmal am Tag ist doch da genug. Wobei der Vorlauf ist da schon interessanter und der kommt eh automatisch über den Broadcast an.
Es gibt beim eBus keinen zyklischen "Durchlauf", was sollte das der Kommunikation der Geräte untereinander bringen. Es kommen nur jede Daten über den Bus die gerade für Steuerzwecke dem anderen Gerät mitgeteilt werden. zB: ein interner Timer wird aktiv oder ein Alarm tritt auf. Wenn du am Steuergerät (Calormatic etc.) hantierst, werden eben mehr Daten über den Bus kommen, je nachdem was du da einstellst.
LG
ich versuche mal Antworten auf deine Fragen zu finden:
- ich habe den MQTT-Broker (DEF: myBroker MQTT 127.0.0.1:1883), MQTT_via_mosquitto (defmod MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto autocreate complex) und MQTT2_ebusd, das ist wie folgt definiert:
defmod MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd DbLogInclude *
attr MQTT2_ebusd IODev MQTT_via_mosquitto
attr MQTT2_ebusd autocreate 1
attr MQTT2_ebusd bridgeRegexp (ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"\
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"
attr MQTT2_ebusd devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
attr MQTT2_ebusd group MQTT
attr MQTT2_ebusd icon sani_boiler_temp
attr MQTT2_ebusd model eBus_daemon_splitter
attr MQTT2_ebusd readingList ebusd/global/uptime:.* uptime\
ebusd/global/running:.* running\
ebusd/global/version:.* version\
ebusd/scan\.08/:.* { json2nameValue($EVENT, 'scan.08_', $JSONMAP) }\
ebusd/scan\.15/:.* { json2nameValue($EVENT, 'scan.15_', $JSONMAP) }\
ebusd/global/signal:.* signal\
ebusd/global/updatecheck:.* updatecheck\
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }\
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }\
attr MQTT2_ebusd room Schnittstellen
attr MQTT2_ebusd setList getKnown:noArg ebusd/list\
getAll:noArg ebusd/list
attr MQTT2_ebusd stateFormat Status: \
1:running\
Signal: \
2:signal\
<br>Uptime: formatedUptime
attr MQTT2_ebusd userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;;;; return sprintf "0 000 00:%02d", $m if $m < 60;;;; my $h = $m / 60;;;; $m %= 60;;;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;;;; my $d = $h / 24;;;; $h %= 24;;;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;;;; my $y = $d / 365;;;; $d %= 365;;;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}
Also alles im Prinzip streng nach Wiki.
Diese Readings kamen "automatisch"
running
true
2019-10-03 07:26:27
scan.08_HW_value
7401
2019-10-03 07:26:27
scan.08_ID_value
BAI00
2019-10-03 07:26:27
scan.08_MF_value
Vaillant
2019-10-03 07:26:27
scan.08_SW_value
0703
2019-10-03 07:26:27
scan.15_HW_value
6002
2019-10-01 20:21:21
scan.15_ID_value
47000
2019-10-01 20:21:21
scan.15_MF_value
Vaillant
2019-10-01 20:21:21
scan.15_SW_value
0126
2019-10-01 20:21:21
signal
true
2019-10-03 07:26:27
state
getAll
2019-10-02 21:19:17
updatecheck
"revision v3.3-4-g212b22d available, broadcast.csv: newer version available, vaillant/08.bai.csv: newer version available, vaillant/15.470.csv: newer version available, vaillant/bai.0010004121.inc: different version available, vaillant/broadcast.csv: different version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: newer version available"
2019-10-03 07:26:27
uptime
92394
2019-10-03 20:56:03
vdatetime_date_value
03.10.2019
2019-10-03 20:54:51
vdatetime_time_value
20:54:50
2019-10-03 20:54:51
version
"ebusd 3.3.v3.3"Angelegt wurde ein MQTT2-Device "MQTT2_ebusd_bai", das hat folgende Readings:
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_bdate_value 03.10.2019
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_btime_value 21:00:04
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_dcfstate_value valid
setstate MQTT2_ebusd_bai 2019-10-03 21:00:07 DateTime_temp2_value 12.062
setstate MQTT2_ebusd_bai 2019-10-03 21:07:43 IonisationVoltageLevel_0_name
setstate MQTT2_ebusd_bai 2019-10-03 21:07:43 IonisationVoltageLevel_0_value 74.4
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 OutdoorstempSensor_sensor_value ok
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 OutdoorstempSensor_temp_value 12.06
setstate MQTT2_ebusd_bai 2019-10-03 21:10:36 PrimaryCircuitFlowrate_0_name
setstate MQTT2_ebusd_bai 2019-10-03 21:10:36 PrimaryCircuitFlowrate_0_value 1352
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_0_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_0_value 24.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_1_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_1_value 24.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_2_name temp2
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_2_value 12.062
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_3_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_4_name temp1
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_4_value 29.0
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_5_name pumpstate
setstate MQTT2_ebusd_bai 2019-10-03 20:59:21 Status01_5_value off
setstate MQTT2_ebusd_bai 2019-10-03 21:00:32 associatedWith MQTT2_ebusd2Die Readings kommen nun ohne den Timer sporadisch, mit Timer freezed das System genauso wie mit dem ECMD-Devices.
Ich bräuchte diese Werte kurzzyklisch, sagen wir mal mindestens alle 30 Sekunden, um ein Problem, das es mit der Anlage gibt, weiter eingrenzen zu können:
- Soll, Vor- und Rücklauf
- Ionisationsspannung und ein paar andere interne Werte
- Volumenstrom um darüber die tatsächlich abgegebene Leistung zu berechnen
- Speichertemperaturen vom Solarspeicher oben und unten.
Alles andere könnte wegen mir ca.10 Minütlich kommen.
Lt. Doku fragt EBUSD doch aktiv diejenigen Werte ab, bei denen man eine Prio von 1-9 vergibt, also z.B. r1 (soll dann den Wert bei jedem Zyklus abfragen, daher die Frage, wie lange denn ein Zyklus wäre, weil das bei mir u.U. mehrere Minuten dauert, bis neue Daten kommen)
Deshalb war das Skript mit dem Find -d von dir schon super, das habe ich dann in Readings splitten lassen. Wenn nun also damit im Bereich von ca. 30 Sekunden Daten gekommen wären, wäre das super gewesen... Für "ich schau mal, was es alles gibt" reicht das für normale User sicher aus, aber für die Fehlereingrenzung reicht das leider gar nicht, weil die Anlage teilweise schon wieder abschaltet, bevor Werte angekommen sind.
Also bleibt die Frage: Wie bekomme ich EBUSD dazu, mindestens mal die wichtigen Werte kurzzyklisch zu aktualisieren ohne FHEM zu blocken ?
Und bevor ich es vergesse und ein falscher Eindruck entsteht: Ich bin besonders euch beiden sehr dankbar, dass Ihr versucht zu helfen !!!
Grüße Christian
ah, sehr schön, da funktioniert eh schon sehr viel.
Wenn du dann später einfach auf MQTT2_Server umsteigst und den Mosquitto deaktivierst dann hast eh alles auf MQTT2.
Warum du bei der Timerabfrage jetzt Freezer bekommst kann ich dir auch nicht sagen. Da du die Daten für deine Recherche benötigst, nehme ich an du Logst die fleißig in eine DB. Vielleicht einmal "plotfork 1" in der WEB define setzen. Ich kenne jetzt deine Umgebung nicht, aber wenn du da einen eigenen Raspi hast, kannst ja dort entweder ein Abfragescript per ebusctl oder eine kleine Fheminstanz mit genau den Timern die du brauchst konfigurieren und schauen ob es da auch so schlimm mit den Freezern ist.
Ich habe das jetzt bei mir mit den Timern ein paarmal hintereinander getestet, bekomme aber keine Freezer. Hast du die Freezer auch, wenn du das Kommando direkt in der Fhem Kommandozeile eingibst ( zB: "set ebusMQTT publish ebusd/430/HwcTempDesired/get" ) ?
LG
...ja es wird in eine DB geloggt (seit kurzem), die auf einem NAS liegt, das spart schon mal Rechenleistung auf dem RASPI, auf dem ansonsten alles drauf läuft, also 2x EBUS-Adapter mit jeweils EBUSD, HM-Gateway, Lacrosse-Gateway, Culs und Signaduinos, Alexa und und und.... daher sind Freeze-Zeiten dann recht störend... Ich habe jetzt mal testweise die wichtigsten Werte über ein bash-Skript, das ich aktuell noch über einen Timer aus FHEM heraus triggere, abgefragt. Dann kann ich im gleichen Takt die find -d Geschichte abfragen. Da habe ich alle relevanten Readings drin und im Moment sieht das noch recht gut aus... Ich teste mal weiter...
Danke für deine Anregungen !!!
BTW (OT): Ich war mal am überlegen, meinen RPI2B gegen einen 4er mit 4GB zu tauschen, aber die Berichte, dass der recht heiss würde und mehr Strom ziehen würde, haben mich bislang abgehalten. In deiner Signatur steht, dass du einen 4er hast, wie sind deine Erfahrungen ?
es gibt wieder Bausätze für den RPI Adapter (https://forum.fhem.de/index.php/topic,104259.msg980659.html#msg980659)!
LG
Reinhart
Basis- und Erweiterungsplatinen sind unterwegs und können dann hier bestellt werden (https://forum.fhem.de/index.php/topic,104268.0.html).
Zitat von: galileo am 28 Oktober 2016, 19:06:32
Nie wieder Poti einstellen !
Nachdem ich tagelang einen Fehler gesucht habe und sich danach herausgestellt hat, dass bloß das Potentiometer nicht richtig eingestellt war (obwohl ich mich an die Einstellanleitung im WIKI genau gehalten habe) habe ich mich ein wenig mit der gegenwärtigen Schaltung auseinandergesetzt. Primär war da die Frage, wieso Vaillant, der ja mit seiner Hardware auch am Bus spricht, nicht alle 2 Wochen ausrücken muss um
Auch wenn ich den ebus-Koppler 2.2 über Reinhard bestellt habe und diese sicher auch verwenden werden, so hab ich bei esera mal nachgefragt, warum die nicht den Comperator bei sich einbauen. Hierzu die Aussage:
Zitat...wie der Autor selbst geschrieben hat, hat er Übersehen den eBus Koppler richtig einzustellen. Von daher verstehe ich das Problem des Autor nicht wirklich. Die Aussagen beziehen sich alle nur auf eine, seine eigene Anlage. Wie geschrieben, wir fertigen das Gerät für sehr viele Kunden mit unterschiedlichen Heizungen. Die Qualität eines eBus Kopplers hängt nicht davon ab, ob das Gerät universell anpassbar ist. Leider hat der Autor erreicht, Sie sehr zu verunsichern. Wäre es ein wirkliches Problem, hätte es sicherlich einige Antworten auf den Beitrag gegeben.
Zitat von: msfox am 23 Oktober 2019, 09:12:10
Auch wenn ich den ebus-Koppler 2.2 über Reinhard bestellt habe und diese sicher auch verwenden werden, so hab ich bei esera mal nachgefragt, warum die nicht den Comperator bei sich einbauen. Hierzu die Aussage:
Zitat...wie der Autor selbst geschrieben hat, hat er Übersehen den eBus Koppler richtig einzustellen. Von daher verstehe ich das Problem des Autor nicht wirklich. Die Aussagen beziehen sich alle nur auf eine, seine eigene Anlage. Wie geschrieben, wir fertigen das Gerät für sehr viele Kunden mit unterschiedlichen Heizungen. Die Qualität eines eBus Kopplers hängt nicht davon ab, ob das Gerät universell anpassbar ist. Leider hat der Autor erreicht, Sie sehr zu verunsichern. Wäre es ein wirkliches Problem, hätte es sicherlich einige Antworten auf den Beitrag gegeben.
manche Hersteller machen es sich schon arg leicht >:(
anyway, ich bin heilfroh dass ich kein Poti mehr einstellen muss und erst mit der Komparator Lösung waren bei meiner Anlage endlich alle Geräte zuverlässig ansprechbar. :)
Moin,
ich habe eine Vaillant ecoTEC plus VC146/5-5 E mit der Regelung multiMATIC VRC 700/4 und seit knapp einem Jahr erfolgreich mit dem ebusd gekoppelt. Erst einmal vielen Dank für die Arbeit hier im Forum und an diejenigen, die die Platine entwickelt und gelötet haben.
Bei dem Versuch, die Heizungsteillast auszulesen erhalte ich eine Fehlermeldung.
Meine Konfiguration:
version: ebusd 3.2.v3.2-21-g7d10104
update check: version 3.3 available
signal: acquired
symbol rate: 23
max symbol rate: 192
min arbitration micros: 5
max arbitration micros: 40
min symbol latency: 4
max symbol latency: 5
reconnects: 4
masters: 3
messages: 620
conditional: 3
poll: 0
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=70000;SW=0510;HW=6403"
Ich erhalte den Fehler "ERR: inavlid Position" bei dem Kommando "ebusctl r PartloadHcKW".
Auszug aus der ebsud.log:
2019-10-25 11:54:17.810 [update error] unable to parse read bai PartloadHcKW from 3108b509030d0704 / 00: ERR: invalid position
Mache ich irgendetwas falsch oder liefert meine Heizung einfach nicht diesen Wert?
VG
Günni
Zitat von: guenni am 25 Oktober 2019, 11:52:36
Ich erhalte den Fehler "ERR: inavlid Position" bei dem Kommando "ebusctl r PartloadHcKW".
Auszug aus der ebsud.log:
2019-10-25 11:54:17.810 [update error] unable to parse read bai PartloadHcKW from 3108b509030d0704 / 00: ERR: invalid position
Mache ich irgendetwas falsch oder liefert meine Heizung einfach nicht diesen Wert?
da Deine Hz mit "00" antwortet, kann sie den Wert wohl nicht liefern.
Schade, aber vielen Dank für die schnelle Antwort.
Eine weitere Frage habe ich noch.
In der Regelung VRC 700 kann ich den Legionellenschutz konfigurieren, d.h. einem Tag der Woche zu einer definierbaren Uhrzeit wird der Warmwasserspeciher auf 70° aufgeheizt. Ich kann das ganze auch komplett ausschalten.
In der entsprechenden Konfigurationsdatei finde ich aber keine Parameter hierfür.
Hat evtl. jemand diesbezüglich neuere Erkenntnisse?
VG
Günni
Zitat von: guenni am 25 Oktober 2019, 12:26:47
In der Regelung VRC 700 kann ich den Legionellenschutz konfigurieren, d.h. einem Tag der Woche zu einer definierbaren Uhrzeit wird der Warmwasserspeciher auf 70° aufgeheizt. Ich kann das ganze auch komplett ausschalten.
In der entsprechenden Konfigurationsdatei finde ich aber keine Parameter hierfür.
du kannst helfen, die messages zu finden, indem du folgendes tust:
- "ebusctl grab result" aufrufen und das Ergebnis als Datei abspeichern
- An der VRC 700 den Legionennschutz umkonfigurieren und die verwendeten Werte notieren.
- "ebusctl grab result" erneut aufrufen und das Ergebnis als zweite Datei abspeichern
- die beiden Files (oder nur die Differenzen) und die verwendeten Werte posten, dann kann man darauf wahrscheinlich eine CSV Definition bauen
Danke. Das werde ich doch mal ausprobieren und dann berichten, was das gebracht hat.
VG
Günni
In den SmartHome Hacks habe ich mich ausführlich zum Thema Legionellenschutz geäußert...
Reine Geschäftemacherei, und damit für Privathäuser vollkommen unsinnig.
LG
pah
Zitat von: guenni am 25 Oktober 2019, 14:03:35
Danke. Das werde ich doch mal ausprobieren und dann berichten, was das gebracht hat.
VG
Günni
Hi Guenni,
habe eine VSC 206/4-5 90 ecoCOMPACT und gerade sowohl in meiner bai.0010015600.inc als auch in Deiner bai.308523.inc den folgenden Wert gefunden:
[SW>=413]r;wi,,APCLegioProtection,d.74
Über den eBus/FHEM finde ich den Paramter aber nicht in meiner laufenden Anlage. Vielleicht kommst Du da weiter oder john30 gibt uns noch einen weiteren Hinweis???
Grüße von der windigen See
Det :)
@pah: hast Du mal einen Link zu den SmartHome Hacks - auf die Schnelle hab ich das hier im Forum nicht gefunden.
@det: ich glaube, ein Wert in der bai....inc hilft mir nicht weiter, da ich ja die Regelung und nicht den Brenner verändern/auslesen möchte. Denn wenn ich das im Brenner ändern würde, würde ja die Regelung mit den alten Werten den Brenner entsprechend steuern, d.h. das Legionellenschutzprogramm zu der Zeit an dem Tag, so wie das in der Regelung eingestellt ist, starten. Oder irre ich mich diesbezüglich?
VG Günni
Smarthome hacks:
https://www.thalia.de/shop/home/artikeldetails/ID53525241.html?ProvID=11000523&gclid=EAIaIQobChMIia6SwPm35QIVx-N3Ch3OmQp0EAQYAyABEgIK4vD_BwE (https://www.thalia.de/shop/home/artikeldetails/ID53525241.html?ProvID=11000523&gclid=EAIaIQobChMIia6SwPm35QIVx-N3Ch3OmQp0EAQYAyABEgIK4vD_BwE)
leider nicht ganz billig, aber ist für nen guten Zweck ;-)
Grüße
Christian
Mein Stundenlohn für die Arbeit an dem Buch liegt unter einem Euro - und die meisten Dinge daraus gibt es auch ohne Buch. Aber eben nicht an einem Ort...
Und betreffend die Legionellen: Im Buch ist - mit ordentlichen Zitaten - belegt, dass die so genannte Legionellenschutzschaltiung keineswegs die Legionellen abtötet. Da sie außerdem überall in der Umwelt vorkommen, meine oben genannte Schlussfolgerung.
Als Vermieter muss man aber den gesetzlichen Regelungen genügen. Egal, wie schwachsinnig die sind.
LG
pah
Hi zusammen,
ich wollte in den letzten Tagen meinen neuen ebus 2.2 RPi Adapter (auf RPi1) in Betrieb genommen. Leider bekomme ich keine Daten interpretiert und ein scanconfig scheint zu einem Timeout zu führen.
In einem Thread vom ebusd heißt es, dass der ebus-Adapter wohl nicht auf dem Bus schreiben kann, da keine Antwort erhalten wird - was am "> 31" zu erkennen wäre.
Bei der Heizungssteuerung handelt es sich um
- auroMATIC Steuerung
- ecoTEC plus VC Gas-Therme
Kann mir irgendwer ggf. einen Tipp geben, was ich übersehen habe?
Vielen Dank
ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyAMA0
2019-10-25 22:20:01.942 [main notice] ebusd 3.3.v3.3-40-gd9d1b9a started with full scan
2019-10-25 22:20:02.173 [bus notice] bus started with own address 31/36
2019-10-25 22:20:02.202 [bus notice] signal acquired
2019-10-25 22:20:02.220 [bus notice] <d48003830000f700
2019-10-25 22:20:03.438 [bus notice] new master 10, master count 2
2019-10-25 22:20:03.512 [bus notice] <1026b5040101d80009160400000385000000e500
2019-10-25 22:20:03.953 [bus notice] <1026b505072b0f01000000003200000000
2019-10-25 22:20:05.248 [bus notice] <10ecb5040112da000a440000ff1f0080000000dd00
2019-10-25 22:20:05.470 [bus notice] <103f050105a90116160900e600
2019-10-25 22:20:05.803 [bus notice] <103fb509040e7d00006900
2019-10-25 22:20:06.259 [bus notice] <10ecb504010fc7000a31036d0221ff21ff0000ef00
2019-10-25 22:20:06.875 [bus notice] <1044b5070104b90001009b00
2019-10-25 22:20:09.245 [bus notice] <1026b509030d7c000b0001009b00
2019-10-25 22:20:09.512 [bus notice] <1050b5040101fe00091603000003810000008900
2019-10-25 22:20:09.748 [bus notice] <1050b504010df200051b002802137e00
2019-10-25 22:20:09.983 [bus notice] <1026b509030d04008c00037f03004a00
2019-10-25 22:20:10.198 [bus notice] <1050b505042d0000003200000000
2019-10-25 22:20:11.498 [bus notice] <10feb505042700370032
2019-10-25 22:20:11.991 [bus notice] <10feb5160800032022251005194c
2019-10-25 22:20:12.178 [main notice] starting initial full scan
2019-10-25 22:20:12.262 [bus notice] >31
2019-10-25 22:20:12.325 [bus notice] >31
2019-10-25 22:20:12.385 [bus notice] >31
2019-10-25 22:20:12.445 [bus notice] >31
2019-10-25 22:20:12.504 [bus notice] >31
2019-10-25 22:20:12.562 [bus notice] >31
2019-10-25 22:20:12.620 [bus notice] >31
2019-10-25 22:20:12.679 [bus notice] >31
2019-10-25 22:20:12.737 [bus notice] >31
2019-10-25 22:20:12.796 [bus notice] >31
2019-10-25 22:20:12.854 [bus notice] >31
2019-10-25 22:20:12.912 [bus notice] >31
2019-10-25 22:20:12.971 [bus notice] >31
2019-10-25 22:20:13.029 [bus notice] >31
2019-10-25 22:20:13.087 [bus notice] >31
2019-10-25 22:20:13.146 [bus notice] >31
2019-10-25 22:20:13.204 [bus notice] >31
2019-10-25 22:20:13.263 [bus notice] >31
2019-10-25 22:20:13.321 [bus notice] >31
2019-10-25 22:20:13.379 [bus notice] >31
2019-10-25 22:20:13.438 [bus notice] >31
2019-10-25 22:20:13.496 [bus notice] >31
2019-10-25 22:20:13.554 [bus notice] >31
2019-10-25 22:20:13.613 [bus notice] >31
2019-10-25 22:20:13.671 [bus notice] >31
2019-10-25 22:20:13.729 [bus notice] >31
2019-10-25 22:20:13.788 [bus notice] >31
2019-10-25 22:20:13.846 [bus notice] >31
2019-10-25 22:20:13.905 [bus notice] >31
2019-10-25 22:20:13.963 [bus notice] >31
2019-10-25 22:20:14.021 [bus notice] >31
2019-10-25 22:20:14.080 [bus notice] >31
2019-10-25 22:20:14.138 [bus notice] >31
2019-10-25 22:20:14.196 [bus notice] >31
2019-10-25 22:20:14.255 [bus notice] >31
2019-10-25 22:20:14.313 [bus notice] >31
2019-10-25 22:20:14.372 [bus notice] >31
2019-10-25 22:20:14.430 [bus notice] >31
2019-10-25 22:20:14.488 [bus notice] >31
2019-10-25 22:20:14.547 [bus notice] >31
2019-10-25 22:20:14.605 [bus notice] >31
2019-10-25 22:20:14.663 [bus notice] >31
2019-10-25 22:20:14.722 [bus notice] >31
2019-10-25 22:20:14.780 [bus notice] >31
2019-10-25 22:20:14.840 [bus notice] >31
2019-10-25 22:20:14.898 [bus notice] >31
2019-10-25 22:20:14.956 [bus notice] >31
2019-10-25 22:20:15.015 [bus notice] >31
2019-10-25 22:20:15.073 [bus notice] >31
2019-10-25 22:20:15.131 [bus notice] >31
2019-10-25 22:20:15.190 [bus notice] >31
2019-10-25 22:20:15.249 [bus notice] >31
2019-10-25 22:20:15.308 [bus notice] >31
2019-10-25 22:20:15.368 [bus notice] >31
2019-10-25 22:20:15.426 [bus notice] >31
2019-10-25 22:20:15.485 [bus notice] >31
2019-10-25 22:20:15.543 [bus notice] >31
2019-10-25 22:20:15.601 [bus notice] >31
2019-10-25 22:20:15.660 [bus notice] >31
2019-10-25 22:20:15.718 [bus notice] >31
2019-10-25 22:20:15.777 [bus notice] >31
2019-10-25 22:20:15.835 [bus notice] >31
2019-10-25 22:20:15.893 [bus notice] >31
2019-10-25 22:20:15.952 [bus notice] >31
2019-10-25 22:20:16.010 [bus notice] >31
2019-10-25 22:20:16.068 [bus notice] >31
2019-10-25 22:20:16.127 [bus notice] >31
2019-10-25 22:20:16.185 [bus notice] >31
2019-10-25 22:20:16.244 [bus notice] >31
2019-10-25 22:20:16.302 [bus notice] >31
2019-10-25 22:20:16.360 [bus notice] >31
2019-10-25 22:20:16.419 [bus notice] >31
2019-10-25 22:20:16.478 [bus notice] >31
2019-10-25 22:20:16.536 [bus notice] >31
2019-10-25 22:20:16.595 [bus notice] >31
2019-10-25 22:20:16.653 [bus notice] >31
2019-10-25 22:20:16.711 [bus notice] >31
2019-10-25 22:20:16.770 [bus notice] >31
2019-10-25 22:20:16.828 [bus notice] >31
2019-10-25 22:20:16.888 [bus notice] >31
2019-10-25 22:20:16.946 [bus notice] >31
2019-10-25 22:20:17.004 [bus notice] >31
2019-10-25 22:20:17.063 [bus notice] >31
2019-10-25 22:20:17.121 [bus notice] >31
2019-10-25 22:20:17.179 [bus notice] >31
2019-10-25 22:20:17.238 [bus notice] >31
2019-10-25 22:20:17.297 [bus notice] >31
2019-10-25 22:20:17.356 [bus notice] >31
2019-10-25 22:20:17.414 [bus notice] >31
2019-10-25 22:20:17.472 [bus notice] >31
2019-10-25 22:20:17.531 [bus notice] >31
2019-10-25 22:20:17.589 [bus notice] >31
2019-10-25 22:20:17.647 [bus notice] >31
2019-10-25 22:20:17.707 [bus notice] >31
2019-10-25 22:20:17.765 [bus notice] >31
2019-10-25 22:20:17.824 [bus notice] >31
2019-10-25 22:20:17.882 [bus notice] >31
2019-10-25 22:20:17.940 [bus notice] >31
2019-10-25 22:20:17.999 [bus notice] >31
2019-10-25 22:20:18.057 [bus notice] >31
2019-10-25 22:20:18.115 [bus notice] >31
2019-10-25 22:20:18.174 [bus notice] >31
2019-10-25 22:20:18.232 [bus notice] >31
2019-10-25 22:20:18.290 [bus notice] >31
2019-10-25 22:20:18.349 [bus notice] >31
2019-10-25 22:20:18.407 [bus notice] >31
2019-10-25 22:20:18.466 [bus notice] >31
2019-10-25 22:20:18.524 [bus notice] >31
2019-10-25 22:20:18.582 [bus notice] >31
2019-10-25 22:20:18.641 [bus notice] >31
2019-10-25 22:20:18.699 [bus notice] >31
2019-10-25 22:20:18.757 [bus notice] >31
2019-10-25 22:20:18.816 [bus notice] >31
2019-10-25 22:20:18.874 [bus notice] >31
2019-10-25 22:20:18.933 [bus notice] >31
2019-10-25 22:20:18.991 [bus notice] >31
2019-10-25 22:20:19.049 [bus notice] >31
2019-10-25 22:20:19.108 [bus notice] >31
2019-10-25 22:20:19.166 [bus notice] >31
2019-10-25 22:20:19.224 [bus notice] >31
2019-10-25 22:20:19.283 [bus notice] >31
2019-10-25 22:20:19.341 [bus notice] >31
2019-10-25 22:20:19.399 [bus notice] >31
2019-10-25 22:20:19.458 [bus notice] >31
2019-10-25 22:20:19.516 [bus notice] >31
2019-10-25 22:20:19.575 [bus notice] >31
2019-10-25 22:20:19.633 [bus notice] >31
2019-10-25 22:20:19.691 [bus notice] >31
2019-10-25 22:20:19.750 [bus notice] >31
2019-10-25 22:20:19.808 [bus notice] >31
2019-10-25 22:20:19.866 [bus notice] >31
2019-10-25 22:20:19.925 [bus notice] >31
2019-10-25 22:20:19.983 [bus notice] >31
2019-10-25 22:20:20.041 [bus notice] >31
2019-10-25 22:20:20.100 [bus notice] >31
2019-10-25 22:20:20.158 [bus notice] >31
2019-10-25 22:20:20.217 [bus notice] >31
2019-10-25 22:20:20.275 [bus notice] >31
2019-10-25 22:20:20.333 [bus notice] >31
2019-10-25 22:20:20.392 [bus notice] >31
2019-10-25 22:20:20.450 [bus notice] >31
2019-10-25 22:20:20.509 [bus notice] >31
2019-10-25 22:20:20.567 [bus notice] >31
2019-10-25 22:20:20.625 [bus notice] >31
2019-10-25 22:20:20.684 [bus notice] >31
2019-10-25 22:20:20.742 [bus notice] >31
2019-10-25 22:20:20.800 [bus notice] >31
2019-10-25 22:20:20.859 [bus notice] >31
2019-10-25 22:20:20.917 [bus notice] >31
2019-10-25 22:20:20.975 [bus notice] >31
2019-10-25 22:20:21.034 [bus notice] >31
2019-10-25 22:20:21.092 [bus notice] >31
2019-10-25 22:20:21.150 [bus notice] >31
2019-10-25 22:20:21.209 [bus notice] >31
2019-10-25 22:20:21.267 [bus notice] >31
2019-10-25 22:20:21.326 [bus notice] >31
2019-10-25 22:20:21.384 [bus notice] >31
2019-10-25 22:20:21.442 [bus notice] >31
2019-10-25 22:20:21.501 [bus notice] >31
2019-10-25 22:20:21.559 [bus notice] >31
2019-10-25 22:20:21.617 [bus notice] >31
2019-10-25 22:20:21.676 [bus notice] >31
2019-10-25 22:20:21.734 [bus notice] >31
2019-10-25 22:20:21.793 [bus notice] >31
2019-10-25 22:20:21.851 [bus notice] >31
2019-10-25 22:20:21.909 [bus notice] >31
2019-10-25 22:20:21.968 [bus notice] >31
2019-10-25 22:20:22.026 [bus notice] >31
2019-10-25 22:20:22.084 [bus notice] >31
2019-10-25 22:20:22.143 [bus notice] >31
2019-10-25 22:20:22.201 [bus notice] >31
2019-10-25 22:20:22.259 [bus notice] >31
2019-10-25 22:20:22.270 [main error] scan config 15: ERR: read timeout
2019-10-25 22:20:22.318 [bus notice] >31
2019-10-25 22:20:22.376 [bus notice] >31
2019-10-25 22:20:22.435 [bus notice] >31
2019-10-25 22:20:22.493 [bus notice] >31
2019-10-25 22:20:22.551 [bus notice] >31
Zitat von: dnlGrande am 25 Oktober 2019, 22:29:57
ich wollte in den letzten Tagen meinen neuen ebus 2.2 RPi Adapter (auf RPi1) in Betrieb genommen. Leider bekomme ich keine Daten interpretiert und ein scanconfig scheint zu einem Timeout zu führen.
In einem Thread vom ebusd heißt es, dass der ebus-Adapter wohl nicht auf dem Bus schreiben kann, da keine Antwort erhalten wird - was am "> 31" zu erkennen wäre.
ja so sieht es aus. Hast du den Adapter selbst gelötet?
LEDs vergessen oder falsch rum drin?
Hi john30,
vielen Dank für die schnelle Antwort.
Es ist das fertige und geprüfte Modul hier aus der Oktober Bestellung von Reinhart.
LEDs sind alle drauf und die funktionieren auch alle...
Hab gerade noch einen anderen RPi3 ausprobiert und hier erhalte ich komischerweise gar keine ebus Informationen.
Muss man noch etwas bei den ebus-Anschlussleitungen beachten? Hab hierzu nicht wirklich Hinweise gefunden... auch wenn ich nicht glaube, dass es daran liegt, da ja grundsätzlich Daten rein kommen.
Danke
sudo ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyAMA0 --mqtthost=ubuntuserv1 --httpport=8080 --mqttport=1883
2019-10-26 08:58:15.855 [main notice] ebusd 3.3.v3.3-42-g67a4254 started with full scan
2019-10-26 08:58:16.071 [bus notice] bus started with own address 31/36
2019-10-26 08:58:16.156 [mqtt notice] connection established
2019-10-26 09:00:26.201 [main notice] update check: revision v3.3-40-gd9d1b9a available
Zitat von: dnlGrande am 26 Oktober 2019, 09:02:34
...
sudo ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d [color=red][b]/dev/ttyAMA0[/b][/color] --mqtthost=ubuntuserv1 --httpport=8080 --mqttport=1883
...
Hi dnlGrande,
bist Du sicher, dass /dev/ttyAMAO richtig ist???
Bei mir ist es: EBUSD_OPTS="-c http://ebusd.eu/config/ -d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --httpport=8080 --scanconfig"
Grüße von der stürmischen Küste
Det :)
Hi Det,
vielen Dank für den Tipp - auf dem RPi3 scheint es bei mir /dev/ttyS0 zu sein.
Hier passiert zumindest etwas mehr, aber leider immer noch kein Erfolg... Bei dem Scan >31 scheint zumindest hier eine Antwort <cc (bzw. teilweise auch <20) zu kommen. Ein DCF77 time stamp broadcast wurde auch richtig erkannt.
Nachdem ich jetzt die Heizungssteuerung mal neu gestartet habe während der ebusd läuft scheinen jetzt korrekte Daten zu kommen...
Allerdings treten immer wieder weitere Fehler auf - z.B. "scan config 15: ERR: arbitration lost".
Ist das "normal"?
Und es scheint auch nur zu funktionieren, wenn man die Heizungssteuerung erst nach dem ebusd startet...?
Nochmals vielen Dank für die schnelle Hilfe
Hier das log "erst ebusd anschl. Steuerung":
sudo ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyS0 --mqtthost=ubuntuserv1 --mqttport=1883
2019-10-26 09:48:54.810 [main notice] ebusd 3.3.v3.3-42-g67a4254 started with full scan
2019-10-26 09:48:55.027 [bus notice] bus started with own address 31/36
2019-10-26 09:48:55.030 [bus notice] signal acquired
2019-10-26 09:48:55.054 [mqtt notice] connection established
2019-10-26 09:48:58.002 [bus notice] max. symbols per second: 250
2019-10-26 09:49:05.051 [main notice] starting initial full scan
2019-10-26 09:49:13.021 [bus notice] <000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c0
2019-10-26 09:49:13.066 [bus notice] >31<02
2019-10-26 09:49:13.204 [bus notice] >31<cc
2019-10-26 09:49:13.351 [bus notice] >31<cc
2019-10-26 09:49:13.486 [bus notice] >31<cc
2019-10-26 09:49:13.620 [bus notice] >31<18
2019-10-26 09:49:13.733 [bus notice] new master 3f, master count 2
2019-10-26 09:49:13.733 [bus notice] scan 44: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:13.733 [update notice] store broadcast ident: done
2019-10-26 09:49:13.733 [update notice] received update-read broadcast id QQ=3f: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:13.737 [bus notice] <3ffe07040ab5534f4c535903066301e6
2019-10-26 09:49:13.784 [bus notice] >31<cc
2019-10-26 09:49:13.929 [bus notice] >31<cc
2019-10-26 09:49:14.067 [bus notice] >31<cc
2019-10-26 09:49:14.202 [bus notice] >31<cc
2019-10-26 09:49:14.339 [bus notice] >31<cc
2019-10-26 09:49:14.474 [bus notice] >31<cc
2019-10-26 09:49:14.615 [bus notice] >31<cc
2019-10-26 09:49:14.752 [bus notice] >31<cc
2019-10-26 09:49:14.885 [bus notice] >31<cc
2019-10-26 09:49:15.020 [bus notice] >31<cc
2019-10-26 09:49:15.110 [main error] unable to load scan config 44: no file from vaillant with prefix 44 found
2019-10-26 09:49:15.110 [main error] scan config 44: ERR: element not found
2019-10-26 09:49:15.154 [bus notice] >31<cc
2019-10-26 09:49:15.293 [bus notice] >31<cc
2019-10-26 09:49:15.433 [bus notice] >31<cc
2019-10-26 09:49:15.567 [bus notice] >31<cc
2019-10-26 09:49:15.684 [bus notice] new master 10, master count 3
2019-10-26 09:49:15.744 [bus notice] scan 26: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:15.744 [update notice] store 26 ident: done
2019-10-26 09:49:15.744 [update notice] received scan-read scan.26 QQ=10: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:15.748 [bus notice] >31<1026070400fa000ab5534f4c5359030663017800
2019-10-26 09:49:15.884 [bus notice] >31<cc
2019-10-26 09:49:16.064 [bus notice] scan 50: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:16.064 [update notice] store 50 ident: done
2019-10-26 09:49:16.064 [update notice] received scan-read scan.50 QQ=10: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:16.068 [bus notice] >31<1050070400b5000ab5534f4c5359030663017800
2019-10-26 09:49:16.203 [bus notice] >31<cc
2019-10-26 09:49:16.339 [bus notice] >31<cc
2019-10-26 09:49:16.474 [bus notice] >31<cc
2019-10-26 09:49:16.636 [bus notice] >31<1051070400eb
2019-10-26 09:49:16.774 [bus notice] >31<cc
2019-10-26 09:49:16.908 [bus notice] >31<cc
2019-10-26 09:49:17.045 [bus notice] >31<cc
2019-10-26 09:49:17.205 [bus notice] >31<1051070400eb
2019-10-26 09:49:17.340 [main notice] read common config file vaillant/scan.csv
2019-10-26 09:49:17.348 [bus notice] >31<cc
2019-10-26 09:49:17.392 [main notice] read common config file vaillant/general.csv
2019-10-26 09:49:17.445 [main notice] read common config file vaillant/broadcast.csv
2019-10-26 09:49:17.486 [bus notice] >31<cc
2019-10-26 09:49:17.509 [main notice] read scan config file vaillant/50.solsy.mc.csv for ID "solsy", SW0306, HW6301
2019-10-26 09:49:17.648 [bus notice] >31<1051070400eb
2019-10-26 09:49:17.783 [bus notice] >31<cc
2019-10-26 09:49:17.830 [main notice] found messages: 103 (4 conditional on 3 conditions, 0 poll, 8 update)
2019-10-26 09:49:17.917 [bus notice] >31<cc
2019-10-26 09:49:18.063 [bus notice] >31<cc
2019-10-26 09:49:18.200 [bus notice] >31<cc
2019-10-26 09:49:18.360 [bus notice] >31<105207040009
2019-10-26 09:49:18.494 [bus notice] >31<cc
2019-10-26 09:49:18.629 [bus notice] >31<cc
2019-10-26 09:49:18.795 [bus notice] >31<105207040009
2019-10-26 09:49:18.934 [bus notice] >31<cc
2019-10-26 09:49:19.068 [bus notice] >31<cc
2019-10-26 09:49:19.206 [bus notice] >31<cc
2019-10-26 09:49:19.345 [bus notice] >31<cc
2019-10-26 09:49:19.483 [bus notice] >31<cc
2019-10-26 09:49:19.645 [bus notice] >31<105207040009
2019-10-26 09:49:19.782 [bus notice] >31<cc
2019-10-26 09:49:19.917 [bus notice] >31<cc
2019-10-26 09:49:20.056 [bus notice] >31<cc
2019-10-26 09:49:20.196 [bus notice] >31<cc
2019-10-26 09:49:20.330 [bus notice] >31<cc
2019-10-26 09:49:20.464 [bus notice] >31<cc
2019-10-26 09:49:20.599 [bus notice] >31<cc
2019-10-26 09:49:20.741 [bus notice] >31<cc
2019-10-26 09:49:20.902 [bus notice] >31<105307040057
2019-10-26 09:49:21.037 [bus notice] >31<cc
2019-10-26 09:49:21.172 [bus notice] >31<cc
2019-10-26 09:49:21.307 [bus notice] >31<00
2019-10-26 09:49:21.378 [bus notice] <105307040057
2019-10-26 09:49:21.472 [bus notice] >31<cc
2019-10-26 09:49:21.607 [bus notice] >31<cc
2019-10-26 09:49:21.741 [bus notice] >31<cc
2019-10-26 09:49:21.903 [bus notice] >31<105307040057
2019-10-26 09:49:22.040 [bus notice] >31<cc
2019-10-26 09:49:22.185 [bus notice] >31<cc
2019-10-26 09:49:22.319 [bus notice] >31<cc
2019-10-26 09:49:22.455 [bus notice] >31<cc
2019-10-26 09:49:22.615 [bus notice] >31<105407040056
2019-10-26 09:49:22.755 [bus notice] >31<cc
2019-10-26 09:49:22.896 [bus notice] >31<cc
2019-10-26 09:49:23.056 [bus notice] >31<105407040056
2019-10-26 09:49:23.193 [bus notice] >31<cc
2019-10-26 09:49:23.327 [bus notice] >31<cc
2019-10-26 09:49:23.494 [bus notice] >31<105407040056
2019-10-26 09:49:23.634 [bus notice] >31<cc
2019-10-26 09:49:23.771 [bus notice] >31<cc
2019-10-26 09:49:23.905 [bus notice] >31<cc
2019-10-26 09:49:24.042 [bus notice] >31<cc
2019-10-26 09:49:24.209 [bus notice] >31<105507040008
2019-10-26 09:49:24.345 [bus notice] >31<cc
2019-10-26 09:49:24.480 [bus notice] >31<cc
2019-10-26 09:49:24.640 [bus notice] >31<105507040008
2019-10-26 09:49:25.313 [bus notice] >311c07040088<a2fd
2019-10-26 09:49:26.362 [bus notice] >311d070400d6<0afd
2019-10-26 09:49:26.898 [bus notice] >311e07040034
2019-10-26 09:49:26.942 [bus notice] >31<20
2019-10-26 09:49:27.014 [bus notice] <105507040008
2019-10-26 09:49:27.099 [bus notice] >31<cc
2019-10-26 09:49:27.224 [bus notice] >31<cc
2019-10-26 09:49:27.349 [bus notice] >31<cc
2019-10-26 09:49:27.474 [bus notice] >31<cc
2019-10-26 09:49:27.599 [bus notice] >31<cc
2019-10-26 09:49:27.724 [bus notice] >31<cc
2019-10-26 09:49:27.849 [bus notice] >31<cc
2019-10-26 09:49:27.973 [bus notice] >31<cc
2019-10-26 09:49:28.097 [bus notice] >31<00
2019-10-26 09:49:28.168 [bus notice] <1056070400ea
2019-10-26 09:49:28.254 [bus notice] >31<cc
2019-10-26 09:49:28.379 [bus notice] >31<cc
2019-10-26 09:49:28.504 [bus notice] >31<cc
2019-10-26 09:49:28.656 [bus notice] >31<1056070400ea
2019-10-26 09:49:28.780 [bus notice] >31<cc
2019-10-26 09:49:28.905 [bus notice] >31<cc
2019-10-26 09:49:29.057 [bus notice] >31<1056070400ea
2019-10-26 09:49:29.182 [bus notice] >31<cc
2019-10-26 09:49:29.307 [bus notice] >31<cc
2019-10-26 09:49:29.432 [bus notice] >31<cc
2019-10-26 09:49:29.557 [bus notice] >31<cc
2019-10-26 09:49:29.681 [bus notice] >31<cc
2019-10-26 09:49:29.805 [bus notice] >31<cc
2019-10-26 09:49:29.957 [bus notice] >31<1057070400b4
2019-10-26 09:49:30.082 [bus notice] >31<cc
2019-10-26 09:49:30.207 [bus notice] >31<cc
2019-10-26 09:49:30.332 [bus notice] >31<cc
2019-10-26 09:49:30.457 [bus notice] >31<cc
2019-10-26 09:49:30.582 [bus notice] >31<cc
2019-10-26 09:49:30.707 [bus notice] >31<cc
2019-10-26 09:49:30.858 [bus notice] >31<1057070400b4
2019-10-26 09:49:30.983 [bus notice] >31<cc
2019-10-26 09:49:31.108 [bus notice] >31<cc
2019-10-26 09:49:31.259 [bus notice] >31<1057070400b4
2019-10-26 09:49:31.384 [bus notice] >31<cc
2019-10-26 09:49:31.509 [bus notice] >31<cc
2019-10-26 09:49:31.661 [bus notice] >31<1058070400e8
2019-10-26 09:49:31.786 [bus notice] >31<cc
2019-10-26 09:49:31.870 [main error] scan config 15: ERR: arbitration lost
2019-10-26 09:49:31.911 [bus notice] >31<cc
2019-10-26 09:49:32.036 [bus notice] >31<cc
2019-10-26 09:49:32.161 [bus notice] >31<cc
2019-10-26 09:49:32.286 [bus notice] >31<cc
2019-10-26 09:49:32.437 [bus notice] >31<0058070400e8
2019-10-26 09:49:32.562 [bus notice] >31<cc
2019-10-26 09:49:32.687 [bus notice] >31<cc
2019-10-26 09:49:32.839 [bus notice] >31<1058070400e8
2019-10-26 09:49:32.964 [bus notice] >31<cc
2019-10-26 09:49:33.088 [bus notice] >31<cc
2019-10-26 09:49:33.240 [bus notice] >31<1059070400b6
2019-10-26 09:49:33.365 [bus notice] >31<cc
2019-10-26 09:49:33.490 [bus notice] >31<cc
2019-10-26 09:49:33.615 [bus notice] >31<cc
2019-10-26 09:49:33.740 [bus notice] >31<cc
2019-10-26 09:49:33.865 [bus notice] >31<cc
2019-10-26 09:49:33.990 [bus notice] >31<cc
2019-10-26 09:49:34.141 [bus notice] >31<1059070400b6
2019-10-26 09:49:34.265 [bus notice] >31<cc
2019-10-26 09:49:34.390 [bus notice] >31<cc
2019-10-26 09:49:34.515 [bus notice] >31<cc
2019-10-26 09:49:34.640 [bus notice] >31<cc
2019-10-26 09:49:34.765 [bus notice] >31<cc
2019-10-26 09:49:34.849 [main error] scan config 26: ERR: arbitration lost
2019-10-26 09:49:34.890 [bus notice] >31<cc
2019-10-26 09:49:35.015 [bus notice] >31<cc
2019-10-26 09:49:35.166 [bus notice] >31<1059070400b6
2019-10-26 09:49:35.291 [bus notice] >31<cc
2019-10-26 09:49:35.415 [bus notice] >31<cc
2019-10-26 09:49:35.540 [bus notice] >31<cc
2019-10-26 09:49:35.665 [bus notice] >31<cc
2019-10-26 09:49:35.790 [bus notice] >31<cc
2019-10-26 09:49:35.915 [bus notice] >31<cc
2019-10-26 09:49:36.039 [bus notice] >31<cc
2019-10-26 09:49:36.190 [bus notice] >31<1027070400a4
2019-10-26 09:49:36.315 [bus notice] >31<cc
2019-10-26 09:49:36.440 [bus notice] >31<cc
2019-10-26 09:49:36.565 [bus notice] >31<cc
2019-10-26 09:49:36.690 [bus notice] >31<cc
2019-10-26 09:49:36.815 [bus notice] >31<cc
2019-10-26 09:49:36.940 [bus notice] >31<cc
2019-10-26 09:49:37.065 [bus notice] >31<cc
2019-10-26 09:49:37.190 [bus notice] >31<cc
2019-10-26 09:49:37.341 [bus notice] >31<1027070400a4
2019-10-26 09:49:37.465 [bus notice] >31<cc
2019-10-26 09:49:37.590 [bus notice] >31<cc
2019-10-26 09:49:37.715 [bus notice] >31<cc
2019-10-26 09:49:37.840 [bus notice] >31<cc
2019-10-26 09:49:37.965 [bus notice] >31<cc
2019-10-26 09:49:38.090 [bus notice] >31<cc
2019-10-26 09:49:38.215 [bus notice] >31<cc
2019-10-26 09:49:38.366 [bus notice] >31<1027070400a4
2019-10-26 09:49:38.490 [bus notice] >31<cc
2019-10-26 09:49:38.615 [bus notice] >31<cc
2019-10-26 09:49:38.740 [bus notice] >31<cc
2019-10-26 09:49:38.865 [bus notice] >31<cc
2019-10-26 09:49:38.990 [bus notice] >31<cc
2019-10-26 09:49:39.115 [bus notice] >31<cc
2019-10-26 09:49:39.240 [bus notice] >31<cc
2019-10-26 09:49:39.365 [bus notice] >31<cc
2019-10-26 09:49:39.489 [bus notice] >31<00
2019-10-26 09:49:39.561 [bus notice] <1028070400f8
2019-10-26 09:49:39.646 [bus notice] >31<cc
2019-10-26 09:49:39.771 [bus notice] >31<cc
2019-10-26 09:49:39.895 [bus notice] >31<cc
2019-10-26 09:49:40.019 [bus notice] >31<cc
2019-10-26 09:49:40.144 [bus notice] >31<cc
2019-10-26 09:49:40.269 [bus notice] >31<cc
2019-10-26 09:49:40.394 [bus notice] >31<cc
2019-10-26 09:49:40.519 [bus notice] >31<cc
2019-10-26 09:49:40.670 [bus notice] >31<1028070400f8
2019-10-26 09:49:40.795 [bus notice] >31<cc
2019-10-26 09:49:40.920 [bus notice] >31<cc
2019-10-26 09:49:41.045 [bus notice] >31<cc
2019-10-26 09:49:41.170 [bus notice] >31<cc
2019-10-26 09:49:41.294 [bus notice] >31<cc
2019-10-26 09:49:41.419 [bus notice] >31<cc
2019-10-26 09:49:41.544 [bus notice] >31<cc
2019-10-26 09:49:41.695 [bus notice] >31<1028070400f8
2019-10-26 09:49:41.820 [bus notice] >31<cc
2019-10-26 09:49:41.945 [bus notice] >31<cc
2019-10-26 09:49:42.070 [bus notice] >31<cc
2019-10-26 09:49:42.195 [bus notice] >31<cc
2019-10-26 09:49:42.320 [bus notice] >31<cc
2019-10-26 09:49:42.445 [bus notice] >31<cc
2019-10-26 09:49:42.570 [bus notice] >31<cc
2019-10-26 09:49:42.694 [bus notice] >31<10
2019-10-26 09:49:42.765 [bus notice] <1029070400a6
2019-10-26 09:49:42.850 [bus notice] >31<cc
2019-10-26 09:49:42.975 [bus notice] >31<cc
2019-10-26 09:49:43.100 [bus notice] >31<cc
2019-10-26 09:49:43.251 [bus notice] >31<1029070400a6
2019-10-26 09:49:43.377 [bus notice] >31<cc
2019-10-26 09:49:43.501 [bus notice] >31<cc
2019-10-26 09:49:43.652 [bus notice] >31<1029070400a6
2019-10-26 09:49:43.778 [bus notice] >31<cc
2019-10-26 09:49:43.903 [bus notice] >31<cc
2019-10-26 09:49:44.028 [bus notice] >31<cc
2019-10-26 09:49:44.153 [bus notice] >31<cc
2019-10-26 09:49:44.278 [bus notice] >31<cc
2019-10-26 09:49:44.403 [bus notice] >31<cc
2019-10-26 09:49:44.554 [bus notice] >31<002a07040044
2019-10-26 09:49:44.679 [bus notice] >31<cc
2019-10-26 09:49:44.804 [bus notice] >31<cc
2019-10-26 09:49:44.929 [bus notice] >31<cc
2019-10-26 09:49:45.054 [bus notice] >31<cc
2019-10-26 09:49:45.179 [bus notice] >31<cc
2019-10-26 09:49:45.304 [bus notice] >31<cc
2019-10-26 09:49:45.429 [bus notice] >31<cc
2019-10-26 09:49:45.580 [bus notice] >31<102a07040044
2019-10-26 09:49:45.705 [bus notice] >31<cc
2019-10-26 09:49:45.830 [bus notice] >31<cc
2019-10-26 09:49:45.955 [bus notice] >31<cc
2019-10-26 09:49:46.080 [bus notice] >31<cc
2019-10-26 09:49:46.205 [bus notice] >31<cc
2019-10-26 09:49:46.329 [bus notice] >31<cc
2019-10-26 09:49:46.454 [bus notice] >31<cc
2019-10-26 09:49:46.605 [bus notice] >31<102a07040044
2019-10-26 09:49:46.730 [bus notice] >31<cc
2019-10-26 09:49:46.854 [bus notice] >31<cc
2019-10-26 09:49:46.979 [bus notice] >31<cc
2019-10-26 09:49:47.104 [bus notice] >31<cc
2019-10-26 09:49:47.229 [bus notice] >31<cc
2019-10-26 09:49:47.354 [bus notice] >31<cc
2019-10-26 09:49:47.479 [bus notice] >31<cc
2019-10-26 09:49:47.604 [bus notice] >31<cc
2019-10-26 09:49:47.771 [bus notice] scan 25: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:47.771 [update notice] store 25 ident: done
2019-10-26 09:49:47.771 [update notice] received scan-read scan.25 QQ=10: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:47.775 [bus notice] >31<102507040018000ab5534f4c5359030663017800
2019-10-26 09:49:47.860 [main error] scan config 15: ERR: arbitration lost
2019-10-26 09:49:47.901 [bus notice] >31<cc
2019-10-26 09:49:48.068 [bus notice] scan 23: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:48.068 [update notice] store 23 ident: done
2019-10-26 09:49:48.068 [update notice] received scan-read scan.23 QQ=10: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:48.072 [bus notice] >31<102307040047000ab5534f4c5359030663017800
2019-10-26 09:49:48.198 [bus notice] >31<cc
2019-10-26 09:49:48.365 [bus notice] scan ec: ;Vaillant;SOLSY;0306;6301
2019-10-26 09:49:48.365 [update notice] store ec ident: done
2019-10-26 09:49:48.365 [update notice] received scan-read scan.ec QQ=10: Vaillant;SOLSY;0306;6301
2019-10-26 09:49:48.369 [bus notice] >31<10ec070400d4000ab5534f4c5359030663017800
2019-10-26 09:49:48.495 [bus notice] >31<cc
2019-10-26 09:49:48.646 [bus notice] >31<10a00704002f
2019-10-26 09:49:48.772 [bus notice] >31<cc
2019-10-26 09:49:48.897 [bus notice] >31<cc
2019-10-26 09:49:49.022 [bus notice] >31<cc
2019-10-26 09:49:49.147 [bus notice] >31<cc
2019-10-26 09:49:49.272 [bus notice] >31<cc
2019-10-26 09:49:49.397 [bus notice] >31<cc
2019-10-26 09:49:49.549 [bus notice] >31<10a00704002f
2019-10-26 09:49:49.674 [bus notice] >31<cc
2019-10-26 09:49:49.798 [bus notice] >31<cc
2019-10-26 09:49:49.923 [bus notice] >31<cc
2019-10-26 09:49:50.048 [bus notice] >31<cc
2019-10-26 09:49:50.173 [bus notice] >31<cc
2019-10-26 09:49:50.298 [bus notice] >31<cc
2019-10-26 09:49:50.423 [bus notice] >31<cc
2019-10-26 09:49:50.574 [bus notice] >31<10a00704002f
2019-10-26 09:49:50.699 [bus notice] >31<cc
2019-10-26 09:49:50.784 [main error] scan config 23: ERR: arbitration lost
2019-10-26 09:49:50.824 [bus notice] >31<cc
2019-10-26 09:49:50.949 [bus notice] >31<cc
2019-10-26 09:49:51.074 [bus notice] >31<cc
2019-10-26 09:49:51.199 [bus notice] >31<cc
2019-10-26 09:49:51.323 [bus notice] >31<cc
2019-10-26 09:49:51.448 [bus notice] >31<cc
2019-10-26 09:49:51.572 [bus notice] >31<10
2019-10-26 09:49:51.643 [bus notice] <10a107040071
2019-10-26 09:49:51.728 [bus notice] >31<cc
2019-10-26 09:49:51.853 [bus notice] >31<cc
2019-10-26 09:49:51.978 [bus notice] >31<cc
2019-10-26 09:49:52.129 [bus notice] >31<10a107040071
2019-10-26 09:49:52.255 [bus notice] >31<cc
2019-10-26 09:49:52.379 [bus notice] >31<cc
2019-10-26 09:49:52.530 [bus notice] >31<00a107040071
2019-10-26 09:49:52.655 [bus notice] >31<cc
2019-10-26 09:49:52.780 [bus notice] >31<cc
2019-10-26 09:49:52.904 [bus notice] >31<cc
2019-10-26 09:49:53.029 [bus notice] >31<cc
2019-10-26 09:49:53.196 [update notice] received unknown MS cmd: 1026b50909323f00446f49744300 / 0101
2019-10-26 09:49:53.201 [bus notice] >31<1026b50909323f00446f49744300a50001019a00
2019-10-26 09:49:53.325 [bus notice] >31<cc
2019-10-26 09:49:53.493 [update notice] received unknown MS cmd: 1026b50909327f00446f49744300 / 0101
2019-10-26 09:49:53.497 [bus notice] >31<1026b50909327f00446f49744300290001019a00
2019-10-26 09:49:53.623 [bus notice] >31<cc
2019-10-26 09:49:53.802 [bus notice] new master 03, master count 4
2019-10-26 09:49:53.802 [bus notice] scan 08: ;Vaillant;BAI00;0518;7401
2019-10-26 09:49:53.802 [update notice] store 08 ident: done
2019-10-26 09:49:53.803 [update notice] received scan-read scan.08 QQ=10: Vaillant;BAI00;0518;7401
2019-10-26 09:49:53.806 [bus notice] >31<100807040017000ab54241493030051874012f00
2019-10-26 09:49:53.891 [main error] scan config 25: ERR: arbitration lost
2019-10-26 09:49:53.931 [bus notice] >31<cc
2019-10-26 09:49:54.122 [bus notice] >31<1018070400ad
2019-10-26 09:49:54.287 [bus notice] >31<cc
2019-10-26 09:49:54.439 [bus notice] <1018070400ad
2019-10-26 09:49:54.975 [bus notice] >315407040090
2019-10-26 09:49:55.511 [bus notice] >3155070400ce
2019-10-26 09:49:56.048 [bus notice] >31560704002c
2019-10-26 09:49:56.092 [bus notice] >31<20
2019-10-26 09:49:56.163 [bus notice] <1018070400ad
2019-10-26 09:49:56.288 [bus notice] >31<cc
2019-10-26 09:49:56.453 [bus notice] >31<cc
2019-10-26 09:49:56.618 [bus notice] >31<cc
2019-10-26 09:49:56.809 [bus notice] >31<103807040042
2019-10-26 09:49:56.974 [bus notice] >31<cc
2019-10-26 09:49:57.126 [bus notice] <103807040042
2019-10-26 09:49:57.662 [bus notice] >315707040072
2019-10-26 09:49:57.874 [main notice] read scan config file vaillant/26.solsy.hc.csv for ID "solsy", SW0306, HW6301
2019-10-26 09:49:58.090 [main notice] found messages: 179 (9 conditional on 6 conditions, 0 poll, 9 update)
2019-10-26 09:49:58.206 [bus notice] >3126b5090124ac<00
2019-10-26 09:49:58.250 [bus notice] >31<cc
2019-10-26 09:49:58.415 [bus notice] >31<cc
2019-10-26 09:49:58.580 [bus notice] >31<cc
2019-10-26 09:49:58.771 [bus notice] >31<103807040042
2019-10-26 09:49:58.935 [bus notice] >31<cc
2019-10-26 09:49:59.087 [bus notice] <107807040007
2019-10-26 09:49:59.131 [bus notice] >31<cc
2019-10-26 09:49:59.322 [bus notice] >31<007807040007
2019-10-26 09:49:59.487 [bus notice] >31<cc
2019-10-26 09:49:59.652 [bus notice] >31<cc
2019-10-26 09:49:59.817 [bus notice] >31<cc
2019-10-26 09:50:00.008 [bus notice] >31<107807040007
2019-10-26 09:50:00.173 [bus notice] >31<cc
2019-10-26 09:50:00.338 [bus notice] >31<cc
2019-10-26 09:50:00.503 [bus notice] >31<cc
2019-10-26 09:50:00.694 [bus notice] >31<10f80704008d
2019-10-26 09:50:00.859 [bus notice] >31<cc
2019-10-26 09:50:01.024 [bus notice] >31<cc
2019-10-26 09:50:01.189 [bus notice] >31<cc
2019-10-26 09:50:01.314 [main error] scan config ec: ERR: arbitration lost
2019-10-26 09:50:01.354 [bus notice] >31<cc
2019-10-26 09:50:01.545 [bus notice] >31<10f80704008d
2019-10-26 09:50:01.710 [bus notice] >31<cc
2019-10-26 09:50:01.861 [bus notice] <10f80704008d
2019-10-26 09:50:01.906 [bus notice] >31<cc
2019-10-26 09:50:02.097 [bus notice] >31<002407040046
2019-10-26 09:50:02.262 [bus notice] >31<cc
2019-10-26 09:50:02.427 [bus notice] >31<cc
2019-10-26 09:50:02.592 [bus notice] >31<cc
2019-10-26 09:50:02.757 [bus notice] >31<00
2019-10-26 09:50:02.829 [bus notice] <102407040046
2019-10-26 09:50:02.954 [bus notice] >31<cc
2019-10-26 09:50:03.145 [bus notice] >31<102407040046
2019-10-26 09:50:03.309 [bus notice] >31<cc
2019-10-26 09:50:03.460 [bus notice] <1044070400ec
2019-10-26 09:50:03.996 [bus notice] >315e07040071
2019-10-26 09:50:04.533 [bus notice] >315f0704002f
2019-10-26 09:50:05.069 [bus notice] >316007040026
2019-10-26 09:50:05.606 [bus notice] >316107040078
2019-10-26 09:50:06.125 [bus notice] >31<20
2019-10-26 09:50:06.196 [bus notice] <1044070400ec
2019-10-26 09:50:06.322 [bus notice] >31<cc
2019-10-26 09:50:06.485 [bus notice] >31<cc
2019-10-26 09:50:06.650 [bus notice] >31<cc
2019-10-26 09:50:06.815 [bus notice] >31<cc
2019-10-26 09:50:07.007 [bus notice] >31<008407040023
2019-10-26 09:50:07.171 [bus notice] >31<cc
2019-10-26 09:50:07.336 [bus notice] >31<cc
2019-10-26 09:50:07.501 [bus notice] >31<cc
2019-10-26 09:50:07.665 [bus notice] >31<20
2019-10-26 09:50:07.736 [bus notice] <108407040023
2019-10-26 09:50:07.862 [bus notice] >31<cc
2019-10-26 09:50:08.027 [bus notice] >31<cc
2019-10-26 09:50:08.191 [bus notice] >31<cc
2019-10-26 09:50:08.356 [bus notice] >31<cc
2019-10-26 09:50:08.521 [bus notice] >31<00
2019-10-26 09:50:08.592 [bus notice] <108407040023
2019-10-26 09:50:08.718 [bus notice] >31<cc
2019-10-26 09:50:08.882 [bus notice] >31<10
2019-10-26 09:50:08.953 [bus notice] <1035070400a2
2019-10-26 09:50:09.078 [bus notice] >31<cc
2019-10-26 09:50:09.270 [bus notice] >31<1035070400a2
2019-10-26 09:50:09.435 [bus notice] >31<cc
2019-10-26 09:50:09.599 [bus notice] >31<cc
2019-10-26 09:50:09.764 [bus notice] >31<cc
2019-10-26 09:50:09.955 [bus notice] >31<1035070400a2
2019-10-26 09:50:10.121 [bus notice] >31<cc
2019-10-26 09:50:10.272 [bus notice] <1075070400e7
2019-10-26 09:50:10.316 [bus notice] >31<cc
2019-10-26 09:50:10.507 [bus notice] >31<1075070400e7
2019-10-26 09:50:10.673 [bus notice] >31<cc
2019-10-26 09:50:10.837 [bus notice] >31<cc
2019-10-26 09:50:11.002 [bus notice] >31<cc
2019-10-26 09:50:11.194 [bus notice] >31<1075070400e7
2019-10-26 09:50:11.359 [bus notice] >31<cc
2019-10-26 09:50:11.523 [bus notice] >31<cc
2019-10-26 09:50:11.688 [bus notice] >31<cc
2019-10-26 09:50:11.853 [bus notice] >31<cc
2019-10-26 09:50:12.045 [bus notice] >31<10f50704006d
2019-10-26 09:50:12.210 [bus notice] >31<cc
2019-10-26 09:50:12.374 [bus notice] >31<cc
2019-10-26 09:50:12.539 [bus notice] >31<cc
2019-10-26 09:50:12.730 [bus notice] >31<10f50704006d
2019-10-26 09:50:12.896 [bus notice] >31<cc
2019-10-26 09:50:13.047 [bus notice] <10f50704006d
2019-10-26 09:50:13.583 [bus notice] >316c07040098
2019-10-26 09:50:14.119 [bus notice] >316d070400c6
2019-10-26 09:50:14.163 [bus notice] >31<cc
2019-10-26 09:50:14.354 [bus notice] >31<101c0704004e
2019-10-26 09:50:14.520 [bus notice] >31<cc
2019-10-26 09:50:14.671 [bus notice] <101c0704004e
2019-10-26 09:50:14.715 [bus notice] >31<cc
2019-10-26 09:50:14.907 [bus notice] >31<101c0704004e
2019-10-26 09:50:15.072 [bus notice] >31<cc
2019-10-26 09:50:15.223 [bus notice] <103c070400a1
2019-10-26 09:50:15.396 [main notice] read scan config file vaillant/08.bai.csv for ID "bai00", SW0518, HW7401
2019-10-26 09:50:15.763 [bus notice] >3108b509012448
2019-10-26 09:50:16.299 [bus notice] >316e07040024
2019-10-26 09:50:16.354 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:16.840 [bus notice] >3108b509012448
2019-10-26 09:50:16.884 [bus notice] >31<20
2019-10-26 09:50:16.956 [bus notice] <103c070400a1
2019-10-26 09:50:17.081 [bus notice] >31<cc
2019-10-26 09:50:17.272 [bus notice] >31<103c070400a1
2019-10-26 09:50:17.437 [bus notice] >31<cc
2019-10-26 09:50:17.589 [bus notice] <107c070400e4
2019-10-26 09:50:18.125 [bus notice] >316f0704007a
2019-10-26 09:50:18.180 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:18.666 [bus notice] >3108b509012448
2019-10-26 09:50:19.203 [bus notice] >317207040020
2019-10-26 09:50:19.257 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:19.743 [bus notice] >3108b509012448
2019-10-26 09:50:19.787 [bus notice] >31<20
2019-10-26 09:50:19.858 [bus notice] <107c070400e4
2019-10-26 09:50:19.984 [bus notice] >31<cc
2019-10-26 09:50:20.175 [bus notice] >31<007c070400e4
2019-10-26 09:50:20.340 [bus notice] >31<cc
2019-10-26 09:50:20.491 [bus notice] <10fc0704006e
2019-10-26 09:50:20.536 [bus notice] >31<cc
2019-10-26 09:50:20.727 [bus notice] >31<10fc0704006e
2019-10-26 09:50:20.892 [bus notice] >31<cc
2019-10-26 09:50:21.043 [bus notice] <10fc0704006e
2019-10-26 09:50:21.098 [bus error] send to 08: ERR: read timeout
2019-10-26 09:50:21.098 [bus error] send message part 0: ERR: read timeout
2019-10-26 09:50:21.098 [main error] error reading message scan.08 id: ERR: read timeout
2019-10-26 09:50:21.584 [bus notice] >3108b509012448
2019-10-26 09:50:22.121 [bus notice] >317507040021
2019-10-26 09:50:22.175 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:22.662 [bus notice] >3108b509012448
2019-10-26 09:50:23.198 [bus notice] >3176070400c3
2019-10-26 09:50:23.242 [bus notice] >31<20
2019-10-26 09:50:23.314 [bus notice] <100607040015
2019-10-26 09:50:23.439 [bus notice] >31<cc
2019-10-26 09:50:23.630 [bus notice] >31<100607040015
2019-10-26 09:50:23.795 [bus notice] >31<cc
2019-10-26 09:50:23.947 [bus notice] <100607040015
2019-10-26 09:50:23.991 [bus notice] >31<cc
2019-10-26 09:50:24.156 [bus notice] >31<cc
2019-10-26 09:50:24.280 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:24.321 [bus notice] >31<cc
2019-10-26 09:50:24.528 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000000
2019-10-26 09:50:24.532 [bus notice] >31<1026b5040101d80009160400000385000000e500
2019-10-26 09:50:24.697 [bus notice] >31<cc
2019-10-26 09:50:24.866 [update notice] received read mc Mode QQ=10: 22;auto;0;0;auto;mixer;night
2019-10-26 09:50:24.869 [bus notice] <1050b5040101fe00091603000003810000008900
2019-10-26 09:50:24.914 [bus notice] >31<cc
2019-10-26 09:50:25.122 [update notice] received unknown MS cmd: 1025b5040101 / 09370300000303000000
2019-10-26 09:50:25.126 [bus notice] >31<1025b5040101d200093703000003030000008600
2019-10-26 09:50:25.334 [update notice] received unknown MS cmd: 1023b5040101 / 09140300000306000000
2019-10-26 09:50:25.338 [bus notice] >31<1023b5040101c60009140300000306000000a300
2019-10-26 09:50:25.503 [bus notice] >31<cc
2019-10-26 09:50:25.670 [update notice] received unknown MS cmd: 10ecb5040101 / 09000300000307000100
2019-10-26 09:50:25.674 [bus notice] <10ecb5040101c90009000300000307000100ed00
2019-10-26 09:50:26.211 [bus notice] >31790704009f
2019-10-26 09:50:26.265 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:26.751 [bus notice] >3108b509012448
2019-10-26 09:50:27.288 [bus notice] >317a0704007d
2019-10-26 09:50:27.332 [bus notice] >31<20
2019-10-26 09:50:27.417 [update notice] received unknown MS cmd: 1008b50903295e00 / 035e0006
2019-10-26 09:50:27.422 [bus notice] <1008b50903295e003700035e00060100
2019-10-26 09:50:27.547 [bus notice] >31<cc
2019-10-26 09:50:27.712 [bus notice] >31<cc
2019-10-26 09:50:27.863 [update notice] received unknown MS cmd: 1026b504010d / 050000bd0205
2019-10-26 09:50:27.867 [bus notice] <1026b504010dd400050000bd0205a800
2019-10-26 09:50:27.912 [bus notice] >31<cc
2019-10-26 09:50:28.077 [bus notice] >31<cc
2019-10-26 09:50:28.259 [update notice] received update-read broadcast vdatetime QQ=10: 09:50:19;26.10.2019
2019-10-26 09:50:28.263 [bus notice] >31<10feb516080019500926100619d9
2019-10-26 09:50:28.387 [bus error] send to 08: ERR: arbitration lost
2019-10-26 09:50:28.388 [bus error] send message part 0: ERR: arbitration lost
2019-10-26 09:50:28.388 [main error] error reading message scan.08 id: ERR: arbitration lost
2019-10-26 09:50:28.427 [bus notice] >31<cc
2019-10-26 09:50:28.591 [bus notice] >31<00
2019-10-26 09:50:28.802 [update notice] received unknown MS cmd: 1026b5040109 / 0a16124100850c000f3200
2019-10-26 09:50:28.806 [bus notice] >31<1026b5040109d0000a16124100850c000f32001300
2019-10-26 09:50:28.972 [bus notice] >31<cc
2019-10-26 09:50:29.135 [bus notice] >31<cc
2019-10-26 09:50:29.256 [update notice] received update-read broadcast outsidetemp QQ=10: 0.000
2019-10-26 09:50:29.260 [bus notice] <10feb51603010000dc
2019-10-26 09:50:29.796 [bus notice] >317c07040022
2019-10-26 09:50:29.850 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:30.337 [bus notice] >3108b509012448
2019-10-26 09:50:30.873 [bus notice] >317d0704007c
2019-10-26 09:50:30.927 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:31.414 [bus notice] >3108b509012448
2019-10-26 09:50:31.950 [bus notice] >317e0704009e
2019-10-26 09:50:31.994 [bus notice] >31<10
2019-10-26 09:50:32.062 [update notice] received update-read broadcast datetime QQ=10: 0.000;09:50:19;26.10.2019
2019-10-26 09:50:32.065 [bus notice] <10fe07000900001950092610051916
2019-10-26 09:50:32.190 [bus notice] >31<cc
2019-10-26 09:50:32.355 [bus notice] >31<cc
2019-10-26 09:50:32.520 [bus notice] >31<cc
2019-10-26 09:50:32.685 [bus notice] >31<cc
2019-10-26 09:50:32.856 [update notice] received unknown MS cmd: 1026b5090118 / 0a00000000000000000000
2019-10-26 09:50:32.860 [bus notice] <1026b50901183f000a000000000000000000009f00
2019-10-26 09:50:32.905 [bus notice] >31<cc
2019-10-26 09:50:33.029 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:33.069 [bus notice] >31<cc
2019-10-26 09:50:33.281 [update notice] received read hc DateTime QQ=10: ok;09:50:21;26.10.2019;8.375
2019-10-26 09:50:33.284 [bus notice] >31<1026b5040100d9000a012150092610061960086700
2019-10-26 09:50:33.449 [bus notice] >31<cc
2019-10-26 09:50:33.663 [bus notice] >31<00ecb5040113db00090000001400000001038300
2019-10-26 09:50:33.828 [bus notice] >31<cc
2019-10-26 09:50:34.001 [update notice] received read mc Params QQ=10: 22;19;0.60;mixer;15;0;25;38;0
2019-10-26 09:50:34.005 [bus notice] <1050b5040109f6000a16133c00810f00192600d700
2019-10-26 09:50:34.541 [bus notice] >318107040058
2019-10-26 09:50:34.595 [bus error] send to 08: ERR: read timeout
2019-10-26 09:50:34.595 [bus error] send message part 0: ERR: read timeout
2019-10-26 09:50:34.596 [main error] error reading message scan.08 id: ERR: read timeout
2019-10-26 09:50:35.082 [bus notice] >3108b509012448
2019-10-26 09:50:35.618 [bus notice] >3182070400ba
2019-10-26 09:50:35.673 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:36.159 [bus notice] >3108b509012448
2019-10-26 09:50:36.203 [bus notice] >31<20
2019-10-26 09:50:36.272 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:50:36.277 [bus notice] <1008b513020508c600000000
2019-10-26 09:50:36.402 [bus notice] >31<cc
2019-10-26 09:50:36.594 [update notice] received read mc Status QQ=10: 32;off;27.38;22
2019-10-26 09:50:36.597 [bus notice] >31<1050b504010df200052000b601164e00
2019-10-26 09:50:36.762 [bus notice] >31<cc
2019-10-26 09:50:36.914 [update notice] received read hc SumFlowSensor QQ=10: 44.00;ok
2019-10-26 09:50:36.917 [bus notice] <1026b509030d04008c0003c00200ba00
2019-10-26 09:50:36.962 [bus notice] >31<cc
2019-10-26 09:50:37.127 [bus notice] >31<cc
2019-10-26 09:50:37.313 [bus notice] >31<0050b505042d0000003200000000
2019-10-26 09:50:37.439 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:37.478 [bus notice] >31<cc
2019-10-26 09:50:37.643 [bus notice] >31<cc
2019-10-26 09:50:37.808 [bus notice] >31<cc
2019-10-26 09:50:38.019 [update notice] received read hc DateTime QQ=10: ok;09:50:25;26.10.2019;8.375
2019-10-26 09:50:38.023 [bus notice] >31<1026b5040100d9000a01255009261006196008be00
2019-10-26 09:50:38.188 [bus notice] >31<cc
2019-10-26 09:50:38.352 [update notice] received update-read broadcast hwcStatus QQ=10: off;43;off
2019-10-26 09:50:38.356 [bus notice] >31<10feb5050427002b00d8
2019-10-26 09:50:38.521 [bus notice] >31<cc
2019-10-26 09:50:38.697 [update notice] received unknown MS cmd: 1008b50903294b00 / 034b0020
2019-10-26 09:50:38.701 [bus notice] <1008b50903294b005f00034b00209200
2019-10-26 09:50:39.238 [bus notice] >3184070400e5
2019-10-26 09:50:39.345 [bus error] send to 08: ERR: wrong symbol received, retry
2019-10-26 09:50:39.856 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:40.392 [bus notice] >3185070400bb
2019-10-26 09:50:40.436 [bus notice] >31<cc
2019-10-26 09:50:40.570 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:50:40.574 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:50:40.619 [bus notice] >31<cc
2019-10-26 09:50:40.783 [bus notice] >31<cc
2019-10-26 09:50:40.981 [update notice] received unknown MS cmd: 1050b505072b0f0100000000 / 00
2019-10-26 09:50:40.985 [bus notice] >31<1050b505072b0f0100000000ed00000000
2019-10-26 09:50:41.150 [bus notice] >31<cc
2019-10-26 09:50:41.337 [update notice] received unknown MS cmd: 1008b5100900000000ffff050000 / 0101
2019-10-26 09:50:41.341 [bus notice] <1008b5100900000000ffff050000ff0001019a00
2019-10-26 09:50:41.387 [bus notice] >31<cc
2019-10-26 09:50:41.511 [bus error] send to 08: ERR: arbitration lost
2019-10-26 09:50:41.511 [bus error] send message part 0: ERR: arbitration lost
2019-10-26 09:50:41.511 [main error] error reading message scan.08 id: ERR: arbitration lost
2019-10-26 09:50:41.550 [bus notice] >31<cc
2019-10-26 09:50:41.762 [update notice] received read hc DateTime QQ=10: ok;09:50:29;26.10.2019;8.375
2019-10-26 09:50:41.765 [bus notice] >31<1026b5040100d9000a012950092610061960084e00
2019-10-26 09:50:41.930 [bus notice] >31<cc
2019-10-26 09:50:42.561 [bus notice] <10ecb5080206013300
2019-10-26 09:50:43.098 [bus notice] >318707040007
2019-10-26 09:50:43.152 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:43.638 [bus notice] >3108b509012448
2019-10-26 09:50:44.175 [bus notice] >31880704005b
2019-10-26 09:50:44.229 [bus error] send to 08: ERR: read timeout, retry
2019-10-26 09:50:44.716 [bus notice] >3108b509012448
2019-10-26 09:50:45.252 [bus notice] >318907040005
2019-10-26 09:50:45.296 [bus notice] >31<20
2019-10-26 09:50:45.367 [update notice] received unknown MS cmd: 10ecb50903298200 / 03820073
2019-10-26 09:50:45.372 [bus notice] <10ecb509032982003300038200739200
2019-10-26 09:50:45.497 [bus notice] >31<cc
2019-10-26 09:50:45.662 [bus notice] >31<cc
2019-10-26 09:50:45.827 [bus notice] >31<00
2019-10-26 09:50:45.938 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:50:45.942 [bus notice] <1008b513020508c600000000
2019-10-26 09:50:46.027 [bus notice] >31<cc
2019-10-26 09:50:46.191 [bus notice] >31<cc
2019-10-26 09:50:46.342 [update notice] received unknown MS cmd: 1025b504010d / 050000740337
2019-10-26 09:50:46.346 [bus notice] <1025b504010dde000500007403375200
2019-10-26 09:50:46.350 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:46.391 [bus notice] >31<cc
2019-10-26 09:50:46.556 [bus notice] >31<cc
2019-10-26 09:50:46.748 [update notice] received read hc SumFlowSensor QQ=10: 44.31;ok
2019-10-26 09:50:46.751 [bus notice] >31<1026b509030d04008c0003c50200f400
2019-10-26 09:50:46.916 [bus notice] >31<cc
2019-10-26 09:50:47.089 [update notice] received read hc DateTime QQ=10: ok;09:50:34;26.10.2019;8.375
2019-10-26 09:50:47.092 [bus notice] <1026b5040100d9000a013450092610061960087100
2019-10-26 09:50:47.136 [bus notice] >31<cc
2019-10-26 09:50:47.301 [bus notice] >31<cc
2019-10-26 09:50:47.466 [bus notice] >31<cc
2019-10-26 09:50:47.631 [bus notice] >31<cc
2019-10-26 09:50:47.755 [bus error] send to 08: ERR: arbitration lost
2019-10-26 09:50:47.756 [bus error] send message part 0: ERR: arbitration lost
2019-10-26 09:50:47.756 [main error] error reading message scan.08 id: ERR: arbitration lost
2019-10-26 09:50:47.796 [bus notice] >31<cc
2019-10-26 09:50:47.961 [update notice] received update-read broadcast hwcStatus QQ=10: off;44;off
2019-10-26 09:50:47.964 [bus notice] >31<10feb5050427002c002f
2019-10-26 09:50:48.130 [bus notice] >31<cc
2019-10-26 09:50:48.263 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:50:48.267 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:50:48.312 [bus notice] >31<cc
2019-10-26 09:50:48.477 [bus notice] >31<cc
2019-10-26 09:50:48.668 [update notice] received unknown MS cmd: 10ecb50903298100 / 03810001
2019-10-26 09:50:48.672 [bus notice] >31<10ecb50903298100050003810001da00
2019-10-26 09:50:48.837 [bus notice] >31<cc
2019-10-26 09:50:49.005 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000100
2019-10-26 09:50:49.009 [bus notice] <1026b5040101d800091604000003850001007e00
2019-10-26 09:50:49.546 [bus notice] >318c070400b8
2019-10-26 09:50:49.643 [bus error] send to 08: ERR: wrong symbol received, retry
2019-10-26 09:50:50.154 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:50.691 [bus notice] >318d070400e6
2019-10-26 09:50:50.790 [bus error] send to 08: ERR: wrong symbol received, retry
2019-10-26 09:50:51.301 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:51.838 [bus notice] >318e07040004
2019-10-26 09:50:51.883 [bus notice] >31<00
2019-10-26 09:50:51.959 [update notice] received unknown MS cmd: 1025b505072b0f0100000000 / 00
2019-10-26 09:50:51.963 [bus notice] <1025b505072b0f01000000004c00000000
2019-10-26 09:50:52.087 [bus notice] >31<cc
2019-10-26 09:50:52.300 [update notice] received read hc DateTime QQ=10: ok;09:50:40;26.10.2019;8.375
2019-10-26 09:50:52.303 [bus notice] >31<1026b5040100d9000a014050092610061960088d00
2019-10-26 09:50:52.468 [bus notice] >31<cc
2019-10-26 09:50:52.652 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 09:50:52.657 [bus notice] <1008b5100900004000ffff040001100001019a00
2019-10-26 09:50:52.756 [bus error] send to 08: ERR: wrong symbol received, retry
2019-10-26 09:50:53.267 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:53.804 [bus notice] >318f0704005a
2019-10-26 09:50:53.903 [bus error] send to 08: ERR: wrong symbol received
2019-10-26 09:50:53.903 [bus error] send message part 0: ERR: wrong symbol received
2019-10-26 09:50:53.904 [main error] error reading message scan.08 id: ERR: wrong symbol received
2019-10-26 09:50:54.414 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:54.951 [bus notice] >3190070400bc
2019-10-26 09:50:54.996 [bus notice] >31<00
2019-10-26 09:50:55.548 [bus notice] <10ecb5080206013300
2019-10-26 09:50:55.673 [bus notice] >31<cc
2019-10-26 09:50:55.837 [bus notice] >31<cc
2019-10-26 09:50:55.983 [update notice] received unknown MS cmd: 1025b504010b / 0400050000
2019-10-26 09:50:55.988 [bus notice] <1025b504010bd8000400050000df00
2019-10-26 09:50:56.032 [bus notice] >31<cc
2019-10-26 09:50:56.196 [bus notice] >31<cc
2019-10-26 09:50:56.361 [bus notice] >31<00
2019-10-26 09:50:56.430 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:50:56.434 [bus notice] <1008b513020508c600000000
2019-10-26 09:50:56.519 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:56.559 [bus notice] >31<cc
2019-10-26 09:50:56.724 [bus notice] >31<cc
2019-10-26 09:50:56.889 [bus notice] >31<cc
2019-10-26 09:50:57.097 [update notice] received unknown MS cmd: 1023b5040101 / 09140300000306000000
2019-10-26 09:50:57.101 [bus notice] >31<1023b5040101c60009140300000306000000a300
2019-10-26 09:50:57.266 [bus notice] >31<cc
2019-10-26 09:50:57.430 [bus notice] >31<10
2019-10-26 09:50:57.541 [update notice] received unknown MS cmd: 1023b504010d / 050000008000
2019-10-26 09:50:57.545 [bus notice] <1023b504010dca000500000080004c00
2019-10-26 09:50:57.630 [bus notice] >31<cc
2019-10-26 09:50:57.795 [bus notice] >31<cc
2019-10-26 09:50:57.920 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:50:57.960 [bus notice] >31<cc
2019-10-26 09:50:58.125 [bus notice] >31<cc
2019-10-26 09:50:58.317 [update notice] received read hc SumFlowSensor QQ=10: 44.44;ok
2019-10-26 09:50:58.321 [bus notice] >31<1026b509030d04008c0003c70200d800
2019-10-26 09:50:58.485 [bus notice] >31<cc
2019-10-26 09:50:58.657 [update notice] received read hc DateTime QQ=10: ok;09:50:46;26.10.2019;8.375
2019-10-26 09:50:58.661 [bus notice] <1026b5040100d9000a01465009261006196008f500
2019-10-26 09:50:58.760 [bus error] send to 08: ERR: wrong symbol received, retry
2019-10-26 09:50:59.271 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:50:59.807 [bus notice] >31930704005e
2019-10-26 09:50:59.910 [bus error] send to 08: ERR: wrong symbol received
2019-10-26 09:50:59.911 [bus error] send message part 0: ERR: wrong symbol received
2019-10-26 09:50:59.912 [main error] error reading message scan.08 id: ERR: wrong symbol received
2019-10-26 09:51:00.422 [bus notice] >3108b509012448<0009003231303933303030cf>00<80
2019-10-26 09:51:00.958 [bus notice] >31940704005f
2019-10-26 09:51:01.002 [bus notice] >31<20
2019-10-26 09:51:01.092 [update notice] received unknown MS cmd: 10ecb5040113 / 09000000140000000103
2019-10-26 09:51:01.096 [bus notice] <10ecb5040113db00090000001400000001038300
2019-10-26 09:51:01.222 [bus notice] >31<cc
2019-10-26 09:51:01.387 [update notice] received update-read broadcast hwcStatus QQ=10: off;44;off
2019-10-26 09:51:01.391 [bus notice] >31<10feb5050427002c002f
2019-10-26 09:51:01.556 [bus notice] >31<cc
2019-10-26 09:51:01.690 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:51:01.694 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:51:01.739 [bus notice] >31<cc
2019-10-26 09:51:01.904 [bus notice] >31<cc
2019-10-26 09:51:02.028 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:02.102 [update notice] received unknown MS cmd: 1025b5040104 / 0721303078909001
2019-10-26 09:51:02.107 [bus notice] >31<1025b5040104d70007213030789090016000
2019-10-26 09:51:02.272 [bus notice] >31<cc
2019-10-26 09:51:02.437 [bus notice] >31<cc
2019-10-26 09:51:02.633 [update notice] received unknown MS cmd: 1023b505072b0f0100000000 / 00
2019-10-26 09:51:02.637 [bus notice] >31<1023b505072b0f0100000000b000000000
2019-10-26 09:51:02.803 [bus notice] >31<cc
2019-10-26 09:51:02.987 [update notice] received unknown MS cmd: 1008b5100900003e00ffff040001 / 0101
2019-10-26 09:51:02.992 [bus notice] <1008b5100900003e00ffff040001160001019a00
2019-10-26 09:51:03.036 [bus notice] >31<cc
2019-10-26 09:51:03.201 [bus notice] >31<cc
2019-10-26 09:51:03.365 [bus notice] >31<10
2019-10-26 09:51:03.917 [bus notice] <10ecb5080206013300
2019-10-26 09:51:04.001 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:04.041 [bus notice] >31<cc
2019-10-26 09:51:04.206 [bus notice] >31<cc
2019-10-26 09:51:04.378 [update notice] received read hc DateTime QQ=10: ok;09:50:52;26.10.2019;8.375
2019-10-26 09:51:04.381 [bus notice] <1026b5040100d9000a015250092610061960087e00
2019-10-26 09:51:04.426 [bus notice] >31<cc
2019-10-26 09:51:04.591 [bus notice] >31<cc
2019-10-26 09:51:04.778 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:51:04.783 [bus notice] >31<1008b513020508c600000000
2019-10-26 09:51:04.948 [bus notice] >31<cc
2019-10-26 09:51:05.113 [bus notice] >31<cc
2019-10-26 09:51:05.278 [bus notice] >31<cc
2019-10-26 09:51:05.444 [update notice] received unknown MS cmd: 10ecb5040101 / 09000300000307000100
2019-10-26 09:51:05.449 [bus notice] <10ecb5040101c90009000300000307000100ed00
2019-10-26 09:51:05.453 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:05.494 [bus notice] >31<cc
2019-10-26 09:51:05.659 [bus notice] >31<cc
2019-10-26 09:51:05.849 [update notice] received unknown MS cmd: 10ecb504010d / 050000008000
2019-10-26 09:51:05.853 [bus notice] >31<10ecb504010dc5000500000080004c00
2019-10-26 09:51:06.019 [bus notice] >31<cc
2019-10-26 09:51:06.215 [bus notice] >31<0026b509030d04008c0003bf02002400
2019-10-26 09:51:06.379 [bus notice] >31<cc
2019-10-26 09:51:06.514 [update notice] received unknown MS cmd: 1026b505021c02 / 00
2019-10-26 09:51:06.518 [bus notice] <1026b505021c02ff00000000
2019-10-26 09:51:06.563 [bus notice] >31<cc
2019-10-26 09:51:06.728 [bus notice] >31<cc
2019-10-26 09:51:06.852 [bus error] send to 08: ERR: arbitration lost
2019-10-26 09:51:06.852 [bus error] send message part 0: ERR: arbitration lost
2019-10-26 09:51:06.852 [main error] error reading message scan.08 id: ERR: arbitration lost
2019-10-26 09:51:06.883 [update notice] received unknown BC cmd: 10feb505022a11
2019-10-26 09:51:06.888 [bus notice] >31<10feb505022a110b
2019-10-26 09:51:07.053 [bus notice] >31<cc
2019-10-26 09:51:07.218 [bus notice] >31<cc
2019-10-26 09:51:07.392 [update notice] received unknown MS cmd: 1026b505022800 / 00
2019-10-26 09:51:07.396 [bus notice] >31<1026b5050228006a00000000
2019-10-26 09:51:07.561 [bus notice] >31<cc
2019-10-26 09:51:07.726 [bus notice] >31<cc
2019-10-26 09:51:07.909 [update notice] received update-read broadcast vdatetime QQ=10: 09:51:00;26.10.2019
2019-10-26 09:51:07.912 [bus notice] >31<10feb516080000510926100619e0
2019-10-26 09:51:08.077 [bus notice] >31<cc
2019-10-26 09:51:08.202 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:08.242 [bus notice] >31<cc
2019-10-26 09:51:08.398 [update notice] received unknown BC cmd: 10feb50502150f
2019-10-26 09:51:08.402 [bus notice] >31<10feb50502150fad
2019-10-26 09:51:08.568 [bus notice] >31<cc
2019-10-26 09:51:08.733 [bus notice] >31<cc
2019-10-26 09:51:08.848 [update notice] received unknown BC cmd: 10feb505021601
2019-10-26 09:51:08.852 [bus notice] <10feb50502160195
2019-10-26 09:51:08.897 [bus notice] >31<cc
2019-10-26 09:51:09.061 [bus notice] >31<cc
2019-10-26 09:51:09.226 [bus notice] >31<cc
2019-10-26 09:51:09.391 [bus notice] >31<cc
2019-10-26 09:51:09.515 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:09.555 [bus notice] >31<10
2019-10-26 09:51:09.591 [update notice] received unknown BC cmd: 10feb505021700
2019-10-26 09:51:09.595 [bus notice] <10feb5050217000f
2019-10-26 09:51:09.721 [bus notice] >31<cc
2019-10-26 09:51:09.885 [bus notice] >31<10
2019-10-26 09:51:09.920 [update notice] received unknown BC cmd: 10feb505022c00
2019-10-26 09:51:09.925 [bus notice] <10feb505022c0076
2019-10-26 09:51:10.051 [bus notice] >31<cc
2019-10-26 09:51:10.215 [bus notice] >31<cc
2019-10-26 09:51:10.380 [bus notice] >31<cc
2019-10-26 09:51:10.545 [bus notice] >31<cc
2019-10-26 09:51:10.701 [update notice] received unknown BC cmd: 10feb505021400
2019-10-26 09:51:10.705 [bus notice] >31<10feb50502140039
2019-10-26 09:51:10.830 [bus error] send to 08: ERR: arbitration lost, retry
2019-10-26 09:51:10.871 [bus notice] >31<cc
2019-10-26 09:51:10.996 [update notice] received update-read broadcast hwcStatus QQ=10: off;44;off
2019-10-26 09:51:10.999 [bus notice] <10feb5050427002c002f
2019-10-26 09:51:11.044 [bus notice] >31<cc
2019-10-26 09:51:11.209 [bus notice] >31<cc
2019-10-26 09:51:11.373 [bus notice] >31<10
2019-10-26 09:51:11.426 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:51:11.430 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:51:11.556 [bus notice] >31<cc
2019-10-26 09:51:11.721 [bus notice] >31<00
2019-10-26 09:51:11.798 [update notice] received unknown MS cmd: 10ecb505072b0f0100000000 / 00
2019-10-26 09:51:11.802 [bus notice] <10ecb505072b0f0100000000f100000000
...
2019-10-26 09:51:12.217 [bus error] send to 08: ERR: arbitration lost
2019-10-26 09:51:12.217 [bus error] send message part 0: ERR: arbitration lost
Hier das log "erst Steuerung dann ebusd":
sudo ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyS0 --mqtthost=ubuntuserv1 --mqttport=1883
2019-10-26 09:59:34.486 [main notice] ebusd 3.3.v3.3-42-g67a4254 started with full scan
2019-10-26 09:59:34.701 [bus notice] bus started with own address 31/36
2019-10-26 09:59:34.723 [bus notice] signal acquired
2019-10-26 09:59:34.731 [mqtt notice] connection established
2019-10-26 09:59:36.165 [bus notice] new master 10, master count 2
2019-10-26 09:59:36.165 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 09:59:36.170 [bus notice] <10feb5050427001c0079
2019-10-26 09:59:36.663 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:59:36.667 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:59:38.182 [update notice] received unknown MS cmd: 1026b505072b0f0100000000 / 00
2019-10-26 09:59:38.186 [bus notice] <1026b505072b0f01000000003200000000
2019-10-26 09:59:40.394 [update notice] received unknown MS cmd: 10ecb5040112 / 0aa60000ff1f0080000000
2019-10-26 09:59:40.398 [bus notice] <10ecb5040112da000aa60000ff1f00800000005500
2019-10-26 09:59:40.662 [bus notice] new master 03, master count 3
2019-10-26 09:59:40.662 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 09:59:40.666 [bus notice] <1008b5100900004000ffff040001100001019a00
2019-10-26 09:59:41.697 [bus notice] <10ecb5080206013300
2019-10-26 09:59:42.171 [update notice] received unknown MS cmd: 10ecb5040111 / 06410703410503
2019-10-26 09:59:42.175 [bus notice] <10ecb5040111d900064107034105033e00
2019-10-26 09:59:42.426 [update notice] received unknown MS cmd: 10ecb504010f / 0a7403250221ff21ff0000
2019-10-26 09:59:42.430 [bus notice] <10ecb504010fc7000a7403250221ff21ff00007100
2019-10-26 09:59:42.658 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:59:42.662 [bus notice] <1008b513020508c600000000
2019-10-26 09:59:43.230 [update notice] received unknown MS cmd: 1050b5040101 / 09160300000381000100
2019-10-26 09:59:43.234 [bus notice] <1050b5040101fe00091603000003810001001200
2019-10-26 09:59:43.466 [update notice] received unknown MS cmd: 1050b504010d / 052000d40116
2019-10-26 09:59:43.470 [bus notice] <1050b504010df200052000d40116d500
2019-10-26 09:59:43.701 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c80100
2019-10-26 09:59:43.705 [bus notice] <1026b509030d04008c0003c801003c00
2019-10-26 09:59:44.216 [update notice] received unknown MS cmd: 10ecb50903298300 / 03830000
2019-10-26 09:59:44.220 [bus notice] <10ecb50903298300a80003830000f700
2019-10-26 09:59:44.444 [update notice] received unknown MS cmd: 1050b505042d000000 / 00
2019-10-26 09:59:44.448 [bus notice] <1050b505042d0000003200000000
2019-10-26 09:59:44.726 [main notice] starting initial full scan
2019-10-26 09:59:44.773 [bus notice] >31<cc
2019-10-26 09:59:44.898 [bus notice] >31<cc
2019-10-26 09:59:45.023 [bus notice] >31<cc
2019-10-26 09:59:45.148 [bus notice] >31<cc
2019-10-26 09:59:45.273 [bus notice] >31<cc
2019-10-26 09:59:45.398 [bus notice] >31<cc
2019-10-26 09:59:45.523 [bus notice] >31<cc
2019-10-26 09:59:45.648 [bus notice] >31<cc
2019-10-26 09:59:45.773 [bus notice] >31<cc
2019-10-26 09:59:45.898 [bus notice] >31<cc
2019-10-26 09:59:46.023 [bus notice] >31<cc
2019-10-26 09:59:46.148 [bus notice] >31<cc
2019-10-26 09:59:46.272 [bus notice] >31<10
2019-10-26 09:59:46.316 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 09:59:46.320 [bus notice] <10feb5050427001c0079
2019-10-26 09:59:46.405 [bus notice] >31<cc
2019-10-26 09:59:46.530 [bus notice] >31<cc
2019-10-26 09:59:46.655 [bus notice] >31<cc
2019-10-26 09:59:46.788 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:59:46.793 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 09:59:46.918 [bus notice] >31<cc
2019-10-26 09:59:47.043 [bus notice] >31<cc
2019-10-26 09:59:47.168 [bus notice] >31<cc
2019-10-26 09:59:47.293 [bus notice] >31<cc
2019-10-26 09:59:47.417 [bus notice] >31<cc
2019-10-26 09:59:47.542 [bus notice] >31<cc
2019-10-26 09:59:47.667 [bus notice] >31<cc
2019-10-26 09:59:47.792 [bus notice] >31<cc
2019-10-26 09:59:47.917 [bus notice] >31<cc
2019-10-26 09:59:48.042 [bus notice] >31<cc
2019-10-26 09:59:48.167 [bus notice] >31<cc
2019-10-26 09:59:48.292 [bus notice] >31<cc
2019-10-26 09:59:48.417 [bus notice] >31<cc
2019-10-26 09:59:48.542 [bus notice] >31<cc
2019-10-26 09:59:48.710 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000100
2019-10-26 09:59:48.714 [bus notice] >31<1026b5040101d800091604000003850001007e00
2019-10-26 09:59:48.840 [bus notice] >31<cc
2019-10-26 09:59:48.965 [bus notice] >31<cc
2019-10-26 09:59:49.122 [update notice] received unknown MS cmd: 1050b505072b0f0100000000 / 00
2019-10-26 09:59:49.126 [bus notice] >31<1050b505072b0f0100000000ed00000000
2019-10-26 09:59:49.251 [bus notice] >31<cc
2019-10-26 09:59:49.375 [bus notice] >31<cc
2019-10-26 09:59:49.500 [bus notice] >31<cc
2019-10-26 09:59:49.625 [bus notice] >31<cc
2019-10-26 09:59:49.750 [bus notice] >31<cc
2019-10-26 09:59:49.875 [bus notice] >31<cc
2019-10-26 09:59:50.000 [bus notice] >31<cc
2019-10-26 09:59:50.125 [bus notice] >31<cc
2019-10-26 09:59:50.250 [bus notice] >31<cc
2019-10-26 09:59:50.375 [bus notice] >31<cc
2019-10-26 09:59:50.557 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 09:59:50.561 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 09:59:51.178 [bus notice] >31120704008a
2019-10-26 09:59:51.714 [bus notice] >3114070400d5
2019-10-26 09:59:52.316 [bus notice] >31150704008b<000ab555492020200324620191>00<80
2019-10-26 09:59:52.867 [bus notice] >31<10ecb5080206013300
2019-10-26 09:59:52.992 [bus notice] >31<cc
2019-10-26 09:59:53.117 [bus notice] >31<cc
2019-10-26 09:59:53.242 [bus notice] >31<cc
2019-10-26 09:59:53.367 [bus notice] >31<cc
2019-10-26 09:59:53.492 [bus notice] >31<cc
2019-10-26 09:59:53.617 [bus notice] >31<10
2019-10-26 09:59:53.708 [update notice] received unknown MS cmd: 1026b5040100 / 0a0353590926100619a008
2019-10-26 09:59:53.713 [bus notice] <1026b5040100d9000a0353590926100619a008de00
2019-10-26 09:59:53.797 [bus notice] >31<cc
2019-10-26 09:59:53.921 [bus notice] >31<cc
2019-10-26 09:59:54.046 [bus notice] >31<cc
2019-10-26 09:59:54.194 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 09:59:54.198 [bus notice] >31<1008b513020508c600000000
2019-10-26 09:59:54.323 [bus notice] >31<cc
2019-10-26 09:59:54.448 [bus notice] >31<cc
2019-10-26 09:59:54.573 [bus notice] >31<cc
2019-10-26 09:59:54.698 [bus notice] >31<cc
2019-10-26 09:59:54.823 [bus notice] >31<cc
2019-10-26 09:59:54.948 [bus notice] >31<cc
2019-10-26 09:59:55.073 [bus notice] >31<cc
2019-10-26 09:59:55.197 [bus notice] >31<cc
2019-10-26 09:59:55.365 [update notice] received unknown MS cmd: 1025b5040101 / 09370300000303000100
2019-10-26 09:59:55.370 [bus notice] >31<1025b5040101d200093703000003030001001d00
2019-10-26 09:59:55.494 [bus notice] >31<cc
2019-10-26 09:59:55.618 [bus notice] >31<cc
2019-10-26 09:59:55.702 [main error] scan config 08: ERR: arbitration lost
2019-10-26 09:59:55.768 [update notice] received unknown MS cmd: 1025b504010d / 050000740337
2019-10-26 09:59:55.772 [bus notice] >31<1025b504010dde000500007403375200
2019-10-26 09:59:55.896 [bus notice] >31<cc
2019-10-26 09:59:56.021 [bus notice] >31<cc
2019-10-26 09:59:56.146 [bus notice] >31<cc
2019-10-26 09:59:56.271 [bus notice] >31<cc
2019-10-26 09:59:56.887 [bus notice] >311c07040088
2019-10-26 09:59:56.933 [bus notice] >31<00
2019-10-26 09:59:57.003 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c80100
2019-10-26 09:59:57.008 [bus notice] <1026b509030d04008c0003c801003c00
2019-10-26 09:59:57.093 [bus notice] >31<cc
2019-10-26 09:59:57.218 [bus notice] >31<cc
2019-10-26 09:59:57.343 [bus notice] >31<cc
2019-10-26 09:59:57.960 [bus notice] >311e07040034
2019-10-26 09:59:58.004 [bus notice] >31<10
2019-10-26 09:59:58.047 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 09:59:58.052 [bus notice] <10feb5050427001c0079
2019-10-26 09:59:58.137 [bus notice] >31<cc
2019-10-26 09:59:58.262 [bus notice] >31<cc
2019-10-26 09:59:58.387 [bus notice] >31<cc
2019-10-26 09:59:58.511 [bus notice] >31<10
2019-10-26 09:59:58.564 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 09:59:58.568 [bus notice] <1025b5040117c40001019a00
2019-10-26 09:59:58.654 [bus notice] >31<cc
2019-10-26 09:59:58.779 [bus notice] >31<cc
2019-10-26 09:59:58.863 [main error] scan config 15: ERR: arbitration lost
2019-10-26 09:59:58.903 [bus notice] >31<cc
2019-10-26 09:59:59.059 [update notice] received unknown MS cmd: 1025b505072b0f0100000000 / 00
2019-10-26 09:59:59.063 [bus notice] >31<1025b505072b0f01000000004c00000000
2019-10-26 09:59:59.187 [bus notice] >31<cc
2019-10-26 09:59:59.312 [bus notice] >31<cc
2019-10-26 09:59:59.437 [bus notice] >31<cc
2019-10-26 09:59:59.562 [bus notice] >31<cc
2019-10-26 09:59:59.687 [bus notice] >31<cc
2019-10-26 09:59:59.812 [bus notice] >31<cc
2019-10-26 09:59:59.937 [bus notice] >31<cc
2019-10-26 10:00:00.109 [update notice] received unknown MS cmd: 10ecb5040112 / 0aa60000ff1f0080000000
2019-10-26 10:00:00.113 [bus notice] >31<10ecb5040112da000aa60000ff1f00800000005500
2019-10-26 10:00:00.238 [bus notice] >31<cc
2019-10-26 10:00:00.363 [bus notice] >31<cc
2019-10-26 10:00:00.534 [update notice] received unknown MS cmd: 10ecb504010f / 0a7403250221ff21ff0000
2019-10-26 10:00:00.539 [bus notice] >31<10ecb504010fc7000a7403250221ff21ff00007100
2019-10-26 10:00:00.663 [bus notice] >31<cc
2019-10-26 10:00:00.787 [bus notice] >31<cc
2019-10-26 10:00:00.912 [bus notice] >31<00
2019-10-26 10:00:01.015 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:01.019 [bus notice] <1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:01.104 [bus notice] >31<cc
2019-10-26 10:00:01.229 [bus notice] >31<cc
2019-10-26 10:00:01.354 [bus notice] >31<cc
2019-10-26 10:00:01.479 [bus notice] >31<cc
2019-10-26 10:00:01.603 [bus notice] >31<cc
2019-10-26 10:00:02.235 [bus notice] >31<10ecb5080206013300
2019-10-26 10:00:02.319 [main error] scan config 25: ERR: arbitration lost
2019-10-26 10:00:02.360 [bus notice] >31<cc
2019-10-26 10:00:02.485 [bus notice] >31<cc
2019-10-26 10:00:02.610 [bus notice] >31<cc
2019-10-26 10:00:02.734 [bus notice] >31<10
2019-10-26 10:00:02.808 [update notice] received unknown MS cmd: 10ecb5040111 / 06410703410503
2019-10-26 10:00:02.813 [bus notice] <10ecb5040111d900064107034105033e00
2019-10-26 10:00:02.898 [bus notice] >31<cc
2019-10-26 10:00:03.023 [bus notice] >31<cc
2019-10-26 10:00:03.148 [bus notice] >31<cc
2019-10-26 10:00:03.273 [bus notice] >31<cc
2019-10-26 10:00:03.398 [bus notice] >31<cc
2019-10-26 10:00:03.523 [bus notice] >31<cc
2019-10-26 10:00:03.670 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:03.674 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:00:03.800 [bus notice] >31<cc
2019-10-26 10:00:03.923 [bus notice] >31<cc
2019-10-26 10:00:04.048 [bus notice] >31<cc
2019-10-26 10:00:04.172 [bus notice] >31<cc
2019-10-26 10:00:04.297 [bus notice] >31<cc
2019-10-26 10:00:04.422 [bus notice] >31<cc
2019-10-26 10:00:04.547 [bus notice] >31<cc
2019-10-26 10:00:04.715 [update notice] received unknown MS cmd: 1023b5040101 / 09140300000306000000
2019-10-26 10:00:04.720 [bus notice] >31<1023b5040101c60009140300000306000000a300
2019-10-26 10:00:04.845 [bus notice] >31<cc
2019-10-26 10:00:04.970 [bus notice] >31<cc
2019-10-26 10:00:05.121 [update notice] received unknown MS cmd: 1023b504010d / 050000008000
2019-10-26 10:00:05.125 [bus notice] >31<1023b504010dca000500000080004c00
2019-10-26 10:00:05.251 [bus notice] >31<cc
2019-10-26 10:00:05.335 [main error] scan config 26: ERR: arbitration lost
2019-10-26 10:00:05.376 [bus notice] >31<cc
2019-10-26 10:00:05.500 [bus notice] >31<cc
2019-10-26 10:00:05.624 [bus notice] >31<cc
2019-10-26 10:00:05.749 [bus notice] >31<cc
2019-10-26 10:00:05.874 [bus notice] >31<cc
2019-10-26 10:00:05.999 [bus notice] >31<cc
2019-10-26 10:00:06.150 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c80100
2019-10-26 10:00:06.155 [bus notice] >31<1026b509030d04008c0003c801003c00
2019-10-26 10:00:06.280 [bus notice] >31<cc
2019-10-26 10:00:06.404 [bus notice] >31<cc
2019-10-26 10:00:06.554 [update notice] received unknown MS cmd: 10ecb50903298300 / 03830000
2019-10-26 10:00:06.558 [bus notice] >31<10ecb50903298300a80003830000f700
2019-10-26 10:00:06.683 [bus notice] >31<cc
2019-10-26 10:00:06.808 [bus notice] >31<cc
2019-10-26 10:00:06.933 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:00:06.937 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:00:07.061 [bus notice] >31<cc
2019-10-26 10:00:07.186 [bus notice] >31<cc
2019-10-26 10:00:07.324 [bus notice] >31<0025b5040117c40001019a00
2019-10-26 10:00:07.449 [bus notice] >31<cc
2019-10-26 10:00:07.574 [bus notice] >31<cc
2019-10-26 10:00:07.699 [bus notice] >31<cc
2019-10-26 10:00:07.824 [bus notice] >31<cc
2019-10-26 10:00:07.948 [bus notice] >31<cc
2019-10-26 10:00:08.073 [bus notice] >31<cc
2019-10-26 10:00:08.198 [bus notice] >31<cc
2019-10-26 10:00:08.282 [main error] scan config 50: ERR: arbitration lost
2019-10-26 10:00:08.323 [bus notice] >31<cc
2019-10-26 10:00:08.448 [bus notice] >31<cc
2019-10-26 10:00:08.572 [bus notice] >31<cc
2019-10-26 10:00:08.697 [bus notice] >31<cc
2019-10-26 10:00:08.822 [bus notice] >31<cc
2019-10-26 10:00:08.947 [bus notice] >31<cc
2019-10-26 10:00:09.071 [bus notice] >31<cc
2019-10-26 10:00:09.196 [bus notice] >31<00
2019-10-26 10:00:09.284 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000100
2019-10-26 10:00:09.288 [bus notice] <1026b5040101d800091604000003850001007e00
2019-10-26 10:00:09.373 [bus notice] >31<cc
2019-10-26 10:00:09.498 [bus notice] >31<cc
2019-10-26 10:00:09.623 [bus notice] >31<cc
2019-10-26 10:00:09.779 [update notice] received unknown MS cmd: 1023b505072b0f0100000000 / 00
2019-10-26 10:00:09.783 [bus notice] >31<1023b505072b0f0100000000b000000000
2019-10-26 10:00:09.909 [bus notice] >31<cc
2019-10-26 10:00:10.034 [bus notice] >31<cc
2019-10-26 10:00:10.159 [bus notice] >31<cc
2019-10-26 10:00:10.284 [bus notice] >31<cc
2019-10-26 10:00:10.409 [bus notice] >31<cc
2019-10-26 10:00:10.534 [bus notice] >31<cc
2019-10-26 10:00:10.659 [bus notice] >31<cc
2019-10-26 10:00:10.784 [bus notice] >31<cc
2019-10-26 10:00:10.909 [bus notice] >31<cc
2019-10-26 10:00:11.034 [bus notice] >31<cc
2019-10-26 10:00:11.226 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:11.230 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:11.315 [main error] scan config ec: ERR: arbitration lost
2019-10-26 10:00:11.356 [bus notice] >31<cc
2019-10-26 10:00:11.481 [bus notice] >31<cc
2019-10-26 10:00:11.606 [bus notice] >31<cc
2019-10-26 10:00:11.730 [bus notice] >31<cc
2019-10-26 10:00:11.855 [bus notice] >31<cc
2019-10-26 10:00:11.980 [bus notice] >31<cc
2019-10-26 10:00:12.105 [bus notice] >31<cc
2019-10-26 10:00:12.230 [bus notice] >31<cc
2019-10-26 10:00:12.372 [update notice] received unknown BC cmd: 10feb516080003001026100619
2019-10-26 10:00:12.376 [bus notice] >31<10feb516080003001026100619f7
2019-10-26 10:00:12.502 [bus notice] >31<cc
2019-10-26 10:00:12.627 [bus notice] >31<cc
2019-10-26 10:00:12.751 [bus notice] >31<cc
2019-10-26 10:00:12.876 [bus notice] >31<cc
2019-10-26 10:00:13.000 [bus notice] >31<cc
2019-10-26 10:00:13.125 [bus notice] >31<cc
2019-10-26 10:00:13.757 [bus notice] >31<10ecb5080206013300
2019-10-26 10:00:13.881 [bus notice] >31<cc
2019-10-26 10:00:14.006 [bus notice] >31<cc
2019-10-26 10:00:14.131 [bus notice] >31<cc
2019-10-26 10:00:14.251 [update notice] received unknown BC cmd: 10feb5160301a00a
2019-10-26 10:00:14.255 [bus notice] >31<10feb5160301a00ab9
2019-10-26 10:00:14.381 [bus notice] >31<cc
2019-10-26 10:00:14.506 [bus notice] >31<cc
2019-10-26 10:00:14.631 [bus notice] >31<cc
2019-10-26 10:00:14.755 [bus notice] >31<cc
2019-10-26 10:00:14.879 [bus notice] >31<cc
2019-10-26 10:00:15.004 [bus notice] >31<cc
2019-10-26 10:00:15.151 [update notice] received update-read broadcast datetime QQ=10: 10.625;10:00:03;26.10.2019
2019-10-26 10:00:15.155 [bus notice] >31<10fe070009a00a030010261005194a
2019-10-26 10:00:15.281 [bus notice] >31<cc
2019-10-26 10:00:15.406 [bus notice] >31<cc
2019-10-26 10:00:15.531 [bus notice] >31<cc
2019-10-26 10:00:15.656 [bus notice] >31<cc
2019-10-26 10:00:15.780 [bus notice] >31<cc
2019-10-26 10:00:15.905 [bus notice] >31<cc
2019-10-26 10:00:16.030 [bus notice] >31<cc
2019-10-26 10:00:16.155 [bus notice] >31<cc
2019-10-26 10:00:16.279 [bus notice] >31<10
2019-10-26 10:00:16.370 [update notice] received unknown MS cmd: 1026b5090118 / 0a00000000000000000000
2019-10-26 10:00:16.374 [bus notice] <1026b50901183f000a000000000000000000009f00
2019-10-26 10:00:16.951 [bus notice] >314107040097
2019-10-26 10:00:17.488 [bus notice] >314207040075
2019-10-26 10:00:18.024 [bus notice] >31430704002b
2019-10-26 10:00:18.068 [bus notice] >31<20
2019-10-26 10:00:18.137 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:18.141 [bus notice] <1008b513020508c600000000
2019-10-26 10:00:18.227 [bus notice] >31<cc
2019-10-26 10:00:18.352 [bus notice] >31<cc
2019-10-26 10:00:18.477 [bus notice] >31<cc
2019-10-26 10:00:18.602 [bus notice] >31<cc
2019-10-26 10:00:18.727 [bus notice] >31<cc
2019-10-26 10:00:18.852 [bus notice] >31<cc
2019-10-26 10:00:19.018 [update notice] received unknown MS cmd: 10ecb5040101 / 09000300000307000100
2019-10-26 10:00:19.023 [bus notice] >31<10ecb5040101c90009000300000307000100ed00
2019-10-26 10:00:19.148 [bus notice] >31<cc
2019-10-26 10:00:19.273 [bus notice] >31<cc
2019-10-26 10:00:19.424 [update notice] received unknown MS cmd: 10ecb504010d / 050000008000
2019-10-26 10:00:19.429 [bus notice] >31<10ecb504010dc5000500000080004c00
2019-10-26 10:00:19.554 [bus notice] >31<cc
2019-10-26 10:00:19.679 [bus notice] >31<cc
2019-10-26 10:00:19.804 [bus notice] >31<cc
2019-10-26 10:00:19.928 [bus notice] >31<cc
2019-10-26 10:00:20.053 [bus notice] >31<cc
2019-10-26 10:00:20.178 [bus notice] >31<cc
2019-10-26 10:00:20.302 [bus notice] >31<cc
2019-10-26 10:00:20.425 [bus notice] >31<cc
2019-10-26 10:00:20.577 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c70100
2019-10-26 10:00:20.581 [bus notice] >31<1026b509030d04008c0003c70100ee00
2019-10-26 10:00:20.707 [bus notice] >31<cc
2019-10-26 10:00:20.832 [bus notice] >31<cc
2019-10-26 10:00:20.956 [bus notice] >31<10
2019-10-26 10:00:21.000 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:00:21.004 [bus notice] <10feb5050427001c0079
2019-10-26 10:00:21.090 [bus notice] >31<cc
2019-10-26 10:00:21.215 [bus notice] >31<cc
2019-10-26 10:00:21.340 [bus notice] >31<cc
2019-10-26 10:00:21.465 [bus notice] >31<cc
2019-10-26 10:00:21.590 [bus notice] >31<cc
2019-10-26 10:00:21.715 [bus notice] >31<cc
2019-10-26 10:00:21.840 [bus notice] >31<cc
2019-10-26 10:00:21.965 [bus notice] >31<cc
2019-10-26 10:00:22.088 [bus notice] >31<cc
2019-10-26 10:00:22.221 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:00:22.226 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:00:22.352 [bus notice] >31<cc
2019-10-26 10:00:22.476 [bus notice] >31<cc
2019-10-26 10:00:22.601 [bus notice] >31<cc
2019-10-26 10:00:22.757 [update notice] received unknown MS cmd: 10ecb505072b0f0100000000 / 00
2019-10-26 10:00:22.762 [bus notice] >31<10ecb505072b0f0100000000f100000000
2019-10-26 10:00:22.887 [bus notice] >31<cc
2019-10-26 10:00:23.012 [bus notice] >31<cc
2019-10-26 10:00:23.188 [bus notice] >31<00ecb5040112da000aae0000ff1f0080000000b300
2019-10-26 10:00:23.805 [bus notice] >314e070400cb
2019-10-26 10:00:23.855 [main error] scan config 08: ERR: read timeout
2019-10-26 10:00:24.341 [bus notice] >3108070400d1
2019-10-26 10:00:24.385 [bus notice] >31<20
2019-10-26 10:00:24.476 [update notice] received unknown MS cmd: 10ecb504010f / 0a7403250221ff21ff0000
2019-10-26 10:00:24.481 [bus notice] <10ecb504010fc7000a7403250221ff21ff00007100
2019-10-26 10:00:24.566 [bus notice] >31<cc
2019-10-26 10:00:24.691 [bus notice] >31<cc
2019-10-26 10:00:24.816 [bus notice] >31<cc
2019-10-26 10:00:24.941 [bus notice] >31<00
2019-10-26 10:00:25.044 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:25.049 [bus notice] <1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:25.134 [bus notice] >31<cc
2019-10-26 10:00:25.259 [bus notice] >31<cc
2019-10-26 10:00:25.384 [bus notice] >31<cc
2019-10-26 10:00:25.509 [bus notice] >31<cc
2019-10-26 10:00:25.634 [bus notice] >31<cc
2019-10-26 10:00:25.757 [bus notice] >31<10
2019-10-26 10:00:26.309 [bus notice] <10ecb5080206013300
2019-10-26 10:00:26.394 [bus notice] >31<cc
2019-10-26 10:00:26.519 [bus notice] >31<cc
2019-10-26 10:00:26.644 [bus notice] >31<cc
2019-10-26 10:00:26.769 [bus notice] >31<cc
2019-10-26 10:00:26.893 [bus notice] >31<10
2019-10-26 10:00:26.959 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:26.963 [bus notice] <1008b513020508c600000000
2019-10-26 10:00:27.049 [bus notice] >31<cc
2019-10-26 10:00:27.174 [bus notice] >31<cc
2019-10-26 10:00:27.258 [main error] scan config 15: ERR: arbitration lost
2019-10-26 10:00:27.299 [bus notice] >31<cc
2019-10-26 10:00:27.423 [bus notice] >31<cc
2019-10-26 10:00:27.574 [update notice] received unknown MS cmd: 1026b504010d / 052000c70116
2019-10-26 10:00:27.579 [bus notice] >31<1026b504010dd400052000c701161400
2019-10-26 10:00:27.704 [bus notice] >31<cc
2019-10-26 10:00:27.829 [bus notice] >31<cc
2019-10-26 10:00:27.954 [bus notice] >31<cc
2019-10-26 10:00:28.079 [bus notice] >31<cc
2019-10-26 10:00:28.204 [bus notice] >31<cc
2019-10-26 10:00:28.329 [bus notice] >31<cc
2019-10-26 10:00:28.454 [bus notice] >31<cc
2019-10-26 10:00:28.579 [bus notice] >31<cc
2019-10-26 10:00:28.730 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c70100
2019-10-26 10:00:28.734 [bus notice] >31<1026b509030d04008c0003c70100ee00
2019-10-26 10:00:28.859 [bus notice] >31<cc
2019-10-26 10:00:28.984 [bus notice] >31<cc
2019-10-26 10:00:29.109 [bus notice] >31<cc
2019-10-26 10:00:29.234 [bus notice] >31<cc
2019-10-26 10:00:29.359 [bus notice] >31<cc
2019-10-26 10:00:29.484 [bus notice] >31<cc
2019-10-26 10:00:29.609 [bus notice] >31<cc
2019-10-26 10:00:29.734 [bus notice] >31<cc
2019-10-26 10:00:29.859 [bus notice] >31<cc
2019-10-26 10:00:30.001 [update notice] received unknown MS cmd: 1026b505042d000000 / 00
2019-10-26 10:00:30.005 [bus notice] >31<1026b505042d0000008200000000
2019-10-26 10:00:30.130 [bus notice] >31<cc
2019-10-26 10:00:30.214 [main error] scan config 23: ERR: arbitration lost
2019-10-26 10:00:30.255 [bus notice] >31<cc
2019-10-26 10:00:30.380 [bus notice] >31<cc
2019-10-26 10:00:30.505 [bus notice] >31<cc
2019-10-26 10:00:30.630 [bus notice] >31<cc
2019-10-26 10:00:30.755 [bus notice] >31<cc
2019-10-26 10:00:30.906 [update notice] received unknown MS cmd: 10ecb50903298300 / 03830000
2019-10-26 10:00:30.910 [bus notice] >31<10ecb50903298300a80003830000f700
2019-10-26 10:00:31.036 [bus notice] >31<cc
2019-10-26 10:00:31.161 [bus notice] >31<cc
2019-10-26 10:00:31.285 [bus notice] >31<10
2019-10-26 10:00:31.360 [update notice] received unknown MS cmd: 10ecb5040111 / 06410703410503
2019-10-26 10:00:31.364 [bus notice] <10ecb5040111d900064107034105033e00
2019-10-26 10:00:31.450 [bus notice] >31<cc
2019-10-26 10:00:31.575 [bus notice] >31<cc
2019-10-26 10:00:31.700 [bus notice] >31<cc
2019-10-26 10:00:31.825 [bus notice] >31<cc
2019-10-26 10:00:31.950 [bus notice] >31<cc
2019-10-26 10:00:32.074 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:00:32.079 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:00:32.204 [bus notice] >31<cc
2019-10-26 10:00:32.328 [bus notice] >31<cc
2019-10-26 10:00:32.462 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:00:32.466 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:00:32.592 [bus notice] >31<cc
2019-10-26 10:00:32.717 [bus notice] >31<cc
2019-10-26 10:00:32.888 [update notice] received unknown MS cmd: 1026b5040100 / 0a0120001026100619a008
2019-10-26 10:00:32.892 [bus notice] >31<1026b5040100d9000a0120001026100619a0084a00
2019-10-26 10:00:33.017 [bus notice] >31<cc
2019-10-26 10:00:33.142 [bus notice] >31<cc
2019-10-26 10:00:33.226 [main error] scan config 25: ERR: arbitration lost
2019-10-26 10:00:33.310 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000100
2019-10-26 10:00:33.314 [bus notice] >31<1026b5040101d800091604000003850001007e00
2019-10-26 10:00:33.931 [bus notice] >315c070400cd
2019-10-26 10:00:34.468 [bus notice] >315d07040093
2019-10-26 10:00:34.512 [bus notice] >31<20
2019-10-26 10:00:34.589 [update notice] received unknown MS cmd: 1026b505072b0f0100000000 / 00
2019-10-26 10:00:34.593 [bus notice] <1026b505072b0f01000000003200000000
2019-10-26 10:00:34.679 [bus notice] >31<cc
2019-10-26 10:00:34.804 [bus notice] >31<cc
2019-10-26 10:00:34.928 [bus notice] >31<cc
2019-10-26 10:00:35.109 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:35.113 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:35.239 [bus notice] >31<cc
2019-10-26 10:00:35.364 [bus notice] >31<cc
2019-10-26 10:00:35.489 [bus notice] >31<cc
2019-10-26 10:00:36.120 [bus notice] >31<10ecb5080206013300
2019-10-26 10:00:36.245 [bus notice] >31<cc
2019-10-26 10:00:36.370 [bus notice] >31<cc
2019-10-26 10:00:36.495 [bus notice] >31<cc
2019-10-26 10:00:36.620 [bus notice] >31<cc
2019-10-26 10:00:36.705 [main error] scan config 26: ERR: arbitration lost
2019-10-26 10:00:36.745 [bus notice] >31<cc
2019-10-26 10:00:36.870 [bus notice] >31<cc
2019-10-26 10:00:36.995 [bus notice] >31<cc
2019-10-26 10:00:37.119 [bus notice] >31<cc
2019-10-26 10:00:37.244 [bus notice] >31<cc
2019-10-26 10:00:37.392 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:37.396 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:00:37.522 [bus notice] >31<cc
2019-10-26 10:00:37.647 [bus notice] >31<cc
2019-10-26 10:00:37.772 [bus notice] >31<cc
2019-10-26 10:00:37.897 [bus notice] >31<cc
2019-10-26 10:00:38.022 [bus notice] >31<cc
2019-10-26 10:00:38.147 [bus notice] >31<cc
2019-10-26 10:00:38.272 [bus notice] >31<cc
2019-10-26 10:00:38.397 [bus notice] >31<cc
2019-10-26 10:00:38.522 [bus notice] >31<cc
2019-10-26 10:00:38.690 [update notice] received unknown MS cmd: 1050b5040101 / 09160300000381000100
2019-10-26 10:00:38.694 [bus notice] >31<1050b5040101fe00091603000003810001001200
2019-10-26 10:00:38.820 [bus notice] >31<cc
2019-10-26 10:00:38.945 [bus notice] >31<cc
2019-10-26 10:00:39.096 [update notice] received unknown MS cmd: 1050b504010d / 052000cd0116
2019-10-26 10:00:39.100 [bus notice] >31<1050b504010df200052000cd01168800
2019-10-26 10:00:39.226 [bus notice] >31<cc
2019-10-26 10:00:39.351 [bus notice] >31<cc
2019-10-26 10:00:39.475 [bus notice] >31<cc
2019-10-26 10:00:39.600 [bus notice] >31<cc
2019-10-26 10:00:39.684 [main error] scan config 50: ERR: arbitration lost
2019-10-26 10:00:39.725 [bus notice] >31<cc
2019-10-26 10:00:39.850 [bus notice] >31<cc
2019-10-26 10:00:39.975 [bus notice] >31<cc
2019-10-26 10:00:40.126 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c70100
2019-10-26 10:00:40.130 [bus notice] >31<1026b509030d04008c0003c70100ee00
2019-10-26 10:00:40.256 [bus notice] >31<cc
2019-10-26 10:00:40.381 [bus notice] >31<cc
2019-10-26 10:00:40.525 [update notice] received unknown MS cmd: 1050b505042d000000 / 00
2019-10-26 10:00:40.529 [bus notice] >31<1050b505042d0000003200000000
2019-10-26 10:00:40.655 [bus notice] >31<cc
2019-10-26 10:00:40.780 [bus notice] >31<cc
2019-10-26 10:00:40.905 [bus notice] >31<cc
2019-10-26 10:00:41.029 [bus notice] >31<cc
2019-10-26 10:00:41.154 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:00:41.158 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:00:41.283 [bus notice] >31<cc
2019-10-26 10:00:41.408 [bus notice] >31<cc
2019-10-26 10:00:41.533 [bus notice] >31<cc
2019-10-26 10:00:41.667 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:00:41.671 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:00:41.795 [bus notice] >31<cc
2019-10-26 10:00:41.920 [bus notice] >31<cc
2019-10-26 10:00:42.045 [bus notice] >31<cc
2019-10-26 10:00:42.170 [bus notice] >31<cc
2019-10-26 10:00:42.295 [bus notice] >31<cc
2019-10-26 10:00:42.420 [bus notice] >31<cc
2019-10-26 10:00:42.544 [bus notice] >31<cc
2019-10-26 10:00:42.629 [main error] scan config ec: ERR: arbitration lost
2019-10-26 10:00:42.669 [bus notice] >31<cc
2019-10-26 10:00:42.794 [bus notice] >31<cc
2019-10-26 10:00:42.919 [bus notice] >31<cc
2019-10-26 10:00:43.075 [update notice] received unknown MS cmd: 1050b505072b0f0100000000 / 00
2019-10-26 10:00:43.079 [bus notice] >31<1050b505072b0f0100000000ed00000000
2019-10-26 10:00:43.204 [bus notice] >31<cc
2019-10-26 10:00:43.329 [bus notice] >31<cc
2019-10-26 10:00:43.454 [bus notice] >31<cc
2019-10-26 10:00:43.579 [bus notice] >31<cc
2019-10-26 10:00:43.704 [bus notice] >31<cc
2019-10-26 10:00:43.829 [bus notice] >31<cc
2019-10-26 10:00:43.954 [bus notice] >31<cc
2019-10-26 10:00:44.078 [bus notice] >31<cc
2019-10-26 10:00:44.203 [bus notice] >31<cc
2019-10-26 10:00:44.328 [bus notice] >31<cc
2019-10-26 10:00:44.509 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:44.514 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:44.638 [bus notice] >31<cc
2019-10-26 10:00:44.763 [bus notice] >31<cc
2019-10-26 10:00:44.888 [bus notice] >31<cc
2019-10-26 10:00:45.013 [bus notice] >31<cc
2019-10-26 10:00:45.644 [bus notice] >31<10ecb5080206013300
2019-10-26 10:00:45.768 [bus notice] >31<cc
2019-10-26 10:00:45.893 [bus notice] >31<cc
2019-10-26 10:00:46.017 [bus notice] >31<cc
2019-10-26 10:00:46.189 [update notice] received unknown MS cmd: 10ecb5040112 / 0aa60000ff1f0080000000
2019-10-26 10:00:46.193 [bus notice] >31<10ecb5040112da000aa60000ff1f00800000005500
2019-10-26 10:00:46.318 [bus notice] >31<cc
2019-10-26 10:00:46.443 [bus notice] >31<cc
2019-10-26 10:00:46.592 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:46.596 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:00:46.721 [bus notice] >31<cc
2019-10-26 10:00:46.846 [bus notice] >31<cc
2019-10-26 10:00:46.971 [bus notice] >31<cc
2019-10-26 10:00:47.144 [bus notice] >31<0025b5040101d200093703000003030001001d00
2019-10-26 10:00:47.268 [bus notice] >31<cc
2019-10-26 10:00:47.393 [bus notice] >31<cc
2019-10-26 10:00:47.518 [bus notice] >31<00
2019-10-26 10:00:47.589 [update notice] received unknown MS cmd: 1025b504010d / 050000740337
2019-10-26 10:00:47.593 [bus notice] <1025b504010dde000500007403375200
2019-10-26 10:00:47.678 [bus notice] >31<cc
2019-10-26 10:00:47.803 [bus notice] >31<cc
2019-10-26 10:00:47.928 [bus notice] >31<cc
2019-10-26 10:00:48.053 [bus notice] >31<cc
2019-10-26 10:00:48.178 [bus notice] >31<cc
2019-10-26 10:00:48.303 [bus notice] >31<cc
2019-10-26 10:00:48.428 [bus notice] >31<cc
2019-10-26 10:00:48.553 [bus notice] >31<cc
2019-10-26 10:00:48.703 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c70100
2019-10-26 10:00:48.708 [bus notice] >31<1026b509030d04008c0003c70100ee00
2019-10-26 10:00:48.833 [bus notice] >31<cc
2019-10-26 10:00:48.958 [bus notice] >31<cc
2019-10-26 10:00:49.129 [update notice] received unknown MS cmd: 10ecb504010f / 0a7403250221ff21ff0000
2019-10-26 10:00:49.134 [bus notice] >31<10ecb504010fc7000a7403250221ff21ff00007100
2019-10-26 10:00:49.259 [bus notice] >31<cc
2019-10-26 10:00:49.384 [bus notice] >31<cc
2019-10-26 10:00:49.509 [bus notice] >31<cc
2019-10-26 10:00:49.634 [bus notice] >31<cc
2019-10-26 10:00:49.759 [bus notice] >31<cc
2019-10-26 10:00:49.884 [bus notice] >31<cc
2019-10-26 10:00:50.009 [bus notice] >31<cc
2019-10-26 10:00:50.134 [bus notice] >31<cc
2019-10-26 10:00:50.259 [bus notice] >31<cc
2019-10-26 10:00:50.383 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:00:50.388 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:00:50.513 [bus notice] >31<cc
2019-10-26 10:00:50.638 [bus notice] >31<cc
2019-10-26 10:00:50.771 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:00:50.776 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:00:50.901 [bus notice] >31<cc
2019-10-26 10:00:51.026 [bus notice] >31<cc
2019-10-26 10:00:51.150 [bus notice] >31<10
2019-10-26 10:00:51.227 [update notice] received unknown MS cmd: 1025b505072b0f0100000000 / 00
2019-10-26 10:00:51.231 [bus notice] <1025b505072b0f01000000004c00000000
2019-10-26 10:00:51.317 [bus notice] >31<cc
2019-10-26 10:00:51.442 [bus notice] >31<cc
2019-10-26 10:00:51.567 [bus notice] >31<cc
2019-10-26 10:00:51.717 [update notice] received unknown MS cmd: 10ecb50903298300 / 03830000
2019-10-26 10:00:51.722 [bus notice] >31<10ecb50903298300a80003830000f700
2019-10-26 10:00:51.847 [bus notice] >31<cc
2019-10-26 10:00:52.464 [bus notice] >317e0704009e
2019-10-26 10:00:52.508 [bus notice] >31<20
2019-10-26 10:00:52.582 [update notice] received unknown MS cmd: 10ecb5040111 / 06410703410503
2019-10-26 10:00:52.587 [bus notice] <10ecb5040111d900064107034105033e00
2019-10-26 10:00:52.672 [bus notice] >31<cc
2019-10-26 10:00:52.797 [bus notice] >31<cc
2019-10-26 10:00:52.922 [bus notice] >31<cc
2019-10-26 10:00:53.047 [bus notice] >31<cc
2019-10-26 10:00:53.172 [bus notice] >31<cc
2019-10-26 10:00:53.297 [bus notice] >31<cc
2019-10-26 10:00:53.421 [bus notice] >31<cc
2019-10-26 10:00:53.546 [bus notice] >31<cc
2019-10-26 10:00:53.736 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:00:53.740 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:00:53.865 [bus notice] >31<cc
2019-10-26 10:00:53.990 [bus notice] >31<cc
2019-10-26 10:00:54.115 [bus notice] >31<cc
2019-10-26 10:00:54.240 [bus notice] >31<cc
2019-10-26 10:00:54.365 [bus notice] >31<cc
2019-10-26 10:00:54.490 [bus notice] >31<cc
2019-10-26 10:00:54.615 [bus notice] >31<cc
2019-10-26 10:00:55.246 [bus notice] >31<10ecb5080206013300
2019-10-26 10:00:55.371 [bus notice] >31<cc
2019-10-26 10:00:55.496 [bus notice] >31<cc
2019-10-26 10:00:55.621 [bus notice] >31<cc
2019-10-26 10:00:55.771 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:00:55.776 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:00:55.901 [bus notice] >31<cc
2019-10-26 10:00:56.518 [bus notice] >3185070400bb
2019-10-26 10:00:56.522 [main error] scan config 15: ERR: arbitration lost
2019-10-26 10:00:56.562 [bus notice] >31<20
2019-10-26 10:00:56.650 [update notice] received unknown MS cmd: 1023b5040101 / 09140300000306000000
2019-10-26 10:00:56.654 [bus notice] <1023b5040101c60009140300000306000000a300
2019-10-26 10:00:56.740 [bus notice] >31<cc
2019-10-26 10:00:56.865 [bus notice] >31<cc
2019-10-26 10:00:56.990 [bus notice] >31<cc
2019-10-26 10:00:57.140 [update notice] received unknown MS cmd: 1023b504010d / 050000008000
2019-10-26 10:00:57.144 [bus notice] >31<1023b504010dca000500000080004c00
2019-10-26 10:00:57.268 [bus notice] >31<cc
2019-10-26 10:00:57.393 [bus notice] >31<cc
2019-10-26 10:00:57.518 [bus notice] >31<cc
2019-10-26 10:00:57.674 [bus notice] >31<0026b509030d04008c0003c70100ee00
2019-10-26 10:00:57.799 [bus notice] >31<cc
2019-10-26 10:00:57.924 [bus notice] >31<cc
2019-10-26 10:00:58.049 [bus notice] >31<cc
2019-10-26 10:00:58.173 [bus notice] >31<cc
2019-10-26 10:00:58.298 [bus notice] >31<cc
2019-10-26 10:00:58.423 [bus notice] >31<cc
2019-10-26 10:00:58.548 [bus notice] >31<cc
2019-10-26 10:00:58.673 [bus notice] >31<cc
2019-10-26 10:00:58.798 [bus notice] >31<cc
2019-10-26 10:00:58.927 [bus notice] >31<00feb5050427001c0079
2019-10-26 10:00:59.052 [bus notice] >31<cc
2019-10-26 10:00:59.177 [bus notice] >31<cc
2019-10-26 10:00:59.315 [bus notice] >31<0025b5040117c40001019a00
2019-10-26 10:00:59.440 [bus notice] >31<cc
2019-10-26 10:00:59.525 [main error] scan config 23: ERR: arbitration lost
2019-10-26 10:00:59.565 [bus notice] >31<cc
2019-10-26 10:00:59.690 [bus notice] >31<10
2019-10-26 10:00:59.781 [update notice] received unknown MS cmd: 1026b5040100 / 0a0147001026100619a008
2019-10-26 10:00:59.786 [bus notice] <1026b5040100d9000a0147001026100619a008d800
2019-10-26 10:00:59.871 [bus notice] >31<cc
2019-10-26 10:00:59.996 [bus notice] >31<cc
2019-10-26 10:01:00.121 [bus notice] >31<cc
2019-10-26 10:01:00.290 [update notice] received unknown MS cmd: 1026b5040101 / 09160400000385000100
2019-10-26 10:01:00.294 [bus notice] >31<1026b5040101d800091604000003850001007e00
2019-10-26 10:01:00.419 [bus notice] >31<cc
2019-10-26 10:01:00.544 [bus notice] >31<cc
2019-10-26 10:01:00.700 [update notice] received unknown MS cmd: 1023b505072b0f0100000000 / 00
2019-10-26 10:01:00.704 [bus notice] >31<1023b505072b0f0100000000b000000000
2019-10-26 10:01:00.830 [bus notice] >31<cc
2019-10-26 10:01:00.954 [bus notice] >31<cc
2019-10-26 10:01:01.079 [bus notice] >31<cc
2019-10-26 10:01:01.204 [bus notice] >31<cc
2019-10-26 10:01:01.328 [bus notice] >31<cc
2019-10-26 10:01:01.453 [bus notice] >31<cc
2019-10-26 10:01:01.578 [bus notice] >31<cc
2019-10-26 10:01:01.703 [bus notice] >31<cc
2019-10-26 10:01:01.828 [bus notice] >31<cc
2019-10-26 10:01:02.010 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:01:02.015 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:01:02.140 [bus notice] >31<cc
2019-10-26 10:01:02.265 [bus notice] >31<cc
2019-10-26 10:01:02.390 [bus notice] >31<cc
2019-10-26 10:01:02.475 [main error] scan config 25: ERR: arbitration lost
2019-10-26 10:01:02.515 [bus notice] >31<cc
2019-10-26 10:01:02.640 [bus notice] >31<cc
2019-10-26 10:01:03.272 [bus notice] >31<10ecb5080206013300
2019-10-26 10:01:03.397 [bus notice] >31<cc
2019-10-26 10:01:03.522 [bus notice] >31<cc
2019-10-26 10:01:03.647 [bus notice] >31<cc
2019-10-26 10:01:03.796 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:01:03.800 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:01:03.925 [bus notice] >31<cc
2019-10-26 10:01:04.050 [bus notice] >31<cc
2019-10-26 10:01:04.175 [bus notice] >31<cc
2019-10-26 10:01:04.342 [update notice] received unknown MS cmd: 10ecb5040101 / 09000300000307000100
2019-10-26 10:01:04.347 [bus notice] >31<10ecb5040101c90009000300000307000100ed00
2019-10-26 10:01:04.472 [bus notice] >31<cc
2019-10-26 10:01:04.597 [bus notice] >31<cc
2019-10-26 10:01:04.748 [update notice] received unknown MS cmd: 10ecb504010d / 050000008000
2019-10-26 10:01:04.752 [bus notice] >31<10ecb504010dc5000500000080004c00
2019-10-26 10:01:04.878 [bus notice] >31<cc
2019-10-26 10:01:05.003 [bus notice] >31<cc
2019-10-26 10:01:05.126 [bus notice] >31<cc
2019-10-26 10:01:05.251 [bus notice] >31<cc
2019-10-26 10:01:05.376 [bus notice] >31<cc
2019-10-26 10:01:05.461 [main error] scan config 26: ERR: arbitration lost
2019-10-26 10:01:05.501 [bus notice] >31<cc
2019-10-26 10:01:05.626 [bus notice] >31<cc
2019-10-26 10:01:05.781 [bus notice] >31<0026b509030d04008c0003c70100ee00
2019-10-26 10:01:05.907 [bus notice] >31<cc
2019-10-26 10:01:06.032 [bus notice] >31<cc
2019-10-26 10:01:06.202 [update notice] received unknown MS cmd: 10ecb5040112 / 0aae0000ff1f0080000000
2019-10-26 10:01:06.207 [bus notice] >31<10ecb5040112da000aae0000ff1f0080000000b300
2019-10-26 10:01:06.333 [bus notice] >31<cc
2019-10-26 10:01:06.458 [bus notice] >31<cc
2019-10-26 10:01:06.582 [bus notice] >31<cc
2019-10-26 10:01:06.707 [bus notice] >31<cc
2019-10-26 10:01:06.830 [bus notice] >31<cc
2019-10-26 10:01:06.955 [bus notice] >31<cc
2019-10-26 10:01:07.080 [bus notice] >31<cc
2019-10-26 10:01:07.205 [bus notice] >31<cc
2019-10-26 10:01:07.329 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:01:07.333 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:01:07.459 [bus notice] >31<cc
2019-10-26 10:01:07.583 [bus notice] >31<cc
2019-10-26 10:01:07.708 [bus notice] >31<cc
2019-10-26 10:01:07.841 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:01:07.845 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:01:07.971 [bus notice] >31<cc
2019-10-26 10:01:08.096 [bus notice] >31<cc
2019-10-26 10:01:08.267 [update notice] received unknown MS cmd: 10ecb504010f / 0a7403250221ff21ff0000
2019-10-26 10:01:08.272 [bus notice] >31<10ecb504010fc7000a7403250221ff21ff00007100
2019-10-26 10:01:08.397 [bus notice] >31<cc
2019-10-26 10:01:08.482 [main error] scan config 50: ERR: arbitration lost
2019-10-26 10:01:08.522 [bus notice] >31<cc
2019-10-26 10:01:08.679 [update notice] received unknown MS cmd: 10ecb505072b0f0100000000 / 00
2019-10-26 10:01:08.683 [bus notice] >31<10ecb505072b0f0100000000f100000000
2019-10-26 10:01:08.809 [bus notice] >31<cc
2019-10-26 10:01:08.933 [bus notice] >31<cc
2019-10-26 10:01:09.058 [bus notice] >31<cc
2019-10-26 10:01:09.183 [bus notice] >31<cc
2019-10-26 10:01:09.308 [bus notice] >31<cc
2019-10-26 10:01:09.432 [bus notice] >31<cc
2019-10-26 10:01:09.557 [bus notice] >31<cc
2019-10-26 10:01:09.682 [bus notice] >31<cc
2019-10-26 10:01:09.833 [update notice] received unknown MS cmd: 10ecb50903298300 / 03830000
2019-10-26 10:01:09.838 [bus notice] >31<10ecb50903298300a80003830000f700
2019-10-26 10:01:09.963 [bus notice] >31<cc
2019-10-26 10:01:10.088 [bus notice] >31<cc
2019-10-26 10:01:10.213 [bus notice] >31<cc
2019-10-26 10:01:10.338 [bus notice] >31<cc
2019-10-26 10:01:10.463 [bus notice] >31<cc
2019-10-26 10:01:10.587 [bus notice] >31<cc
2019-10-26 10:01:10.712 [bus notice] >31<cc
2019-10-26 10:01:10.837 [bus notice] >31<cc
2019-10-26 10:01:10.962 [bus notice] >31<cc
2019-10-26 10:01:11.147 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:01:11.151 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:01:11.277 [bus notice] >31<cc
2019-10-26 10:01:11.402 [bus notice] >31<cc
2019-10-26 10:01:11.486 [main error] scan config ec: ERR: arbitration lost
2019-10-26 10:01:11.526 [bus notice] >31<cc
2019-10-26 10:01:11.651 [bus notice] >31<cc
2019-10-26 10:01:11.776 [bus notice] >31<cc
2019-10-26 10:01:11.901 [bus notice] >31<cc
2019-10-26 10:01:12.532 [bus notice] >31<10ecb5080206013300
2019-10-26 10:01:12.657 [bus notice] >31<cc
2019-10-26 10:01:12.782 [bus notice] >31<cc
2019-10-26 10:01:12.907 [bus notice] >31<cc
2019-10-26 10:01:13.032 [bus notice] >31<cc
2019-10-26 10:01:13.157 [bus notice] >31<cc
2019-10-26 10:01:13.282 [bus notice] >31<cc
2019-10-26 10:01:13.407 [bus notice] >31<cc
2019-10-26 10:01:13.532 [bus notice] >31<cc
2019-10-26 10:01:13.655 [bus notice] >31<cc
2019-10-26 10:01:13.780 [bus notice] >31<cc
2019-10-26 10:01:13.922 [update notice] received unknown BC cmd: 10feb516080004011026100619
2019-10-26 10:01:13.927 [bus notice] >31<10feb5160800040110261006194c
2019-10-26 10:01:14.052 [bus notice] >31<cc
2019-10-26 10:01:14.177 [bus notice] >31<cc
2019-10-26 10:01:14.302 [bus notice] >31<cc
2019-10-26 10:01:14.427 [bus notice] >31<cc
2019-10-26 10:01:14.551 [bus notice] >31<cc
2019-10-26 10:01:14.676 [bus notice] >31<cc
2019-10-26 10:01:14.796 [update notice] received unknown BC cmd: 10feb5160301a00a
2019-10-26 10:01:14.801 [bus notice] >31<10feb5160301a00ab9
2019-10-26 10:01:14.925 [bus notice] >31<cc
2019-10-26 10:01:15.050 [bus notice] >31<cc
2019-10-26 10:01:15.175 [bus notice] >31<cc
2019-10-26 10:01:15.322 [update notice] received update-read broadcast datetime QQ=10: 10.625;10:01:04;26.10.2019
2019-10-26 10:01:15.326 [bus notice] >31<10fe070009a00a04011026100519f1
2019-10-26 10:01:15.452 [bus notice] >31<cc
2019-10-26 10:01:15.576 [bus notice] >31<cc
2019-10-26 10:01:15.701 [bus notice] >31<cc
2019-10-26 10:01:15.826 [bus notice] >31<cc
2019-10-26 10:01:15.997 [update notice] received unknown MS cmd: 1026b5090118 / 0a00000000000000000000
2019-10-26 10:01:16.002 [bus notice] >31<1026b50901183f000a000000000000000000009f00
2019-10-26 10:01:16.127 [bus notice] >31<cc
2019-10-26 10:01:16.252 [bus notice] >31<cc
2019-10-26 10:01:16.376 [bus notice] >31<10
2019-10-26 10:01:16.442 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:01:16.447 [bus notice] <1008b513020508c600000000
2019-10-26 10:01:16.532 [bus notice] >31<cc
2019-10-26 10:01:16.657 [bus notice] >31<cc
2019-10-26 10:01:16.782 [bus notice] >31<cc
2019-10-26 10:01:16.907 [bus notice] >31<cc
2019-10-26 10:01:17.032 [bus notice] >31<cc
2019-10-26 10:01:17.157 [bus notice] >31<cc
2019-10-26 10:01:17.281 [bus notice] >31<cc
2019-10-26 10:01:17.406 [bus notice] >31<cc
2019-10-26 10:01:17.557 [update notice] received unknown MS cmd: 1026b504010d / 052000c50116
2019-10-26 10:01:17.562 [bus notice] >31<1026b504010dd400052000c501163800
2019-10-26 10:01:17.687 [bus notice] >31<cc
2019-10-26 10:01:17.812 [bus notice] >31<cc
2019-10-26 10:01:17.937 [bus notice] >31<cc
2019-10-26 10:01:18.062 [bus notice] >31<cc
2019-10-26 10:01:18.187 [bus notice] >31<cc
2019-10-26 10:01:18.312 [bus notice] >31<cc
2019-10-26 10:01:18.437 [bus notice] >31<cc
2019-10-26 10:01:18.561 [bus notice] >31<cc
2019-10-26 10:01:18.686 [bus notice] >31<cc
2019-10-26 10:01:18.811 [bus notice] >31<10
2019-10-26 10:01:18.883 [update notice] received unknown MS cmd: 1026b509030d0400 / 03c50100
2019-10-26 10:01:18.887 [bus notice] <1026b509030d04008c0003c50100c200
2019-10-26 10:01:18.973 [bus notice] >31<cc
2019-10-26 10:01:19.098 [bus notice] >31<cc
2019-10-26 10:01:19.223 [bus notice] >31<cc
2019-10-26 10:01:19.377 [update notice] received unknown MS cmd: 10ecb5040111 / 06410703410503
2019-10-26 10:01:19.382 [bus notice] >31<10ecb5040111d900064107034105033e00
2019-10-26 10:01:19.507 [bus notice] >31<cc
2019-10-26 10:01:19.632 [bus notice] >31<cc
2019-10-26 10:01:19.756 [bus notice] >31<cc
2019-10-26 10:01:19.881 [bus notice] >31<cc
2019-10-26 10:01:20.024 [update notice] received unknown MS cmd: 1026b505042d000000 / 00
2019-10-26 10:01:20.028 [bus notice] >31<1026b505042d0000008200000000
2019-10-26 10:01:20.154 [bus notice] >31<cc
2019-10-26 10:01:20.279 [bus notice] >31<cc
2019-10-26 10:01:20.404 [bus notice] >31<cc
2019-10-26 10:01:20.529 [bus notice] >31<cc
2019-10-26 10:01:20.654 [bus notice] >31<cc
2019-10-26 10:01:20.778 [bus notice] >31<cc
2019-10-26 10:01:20.903 [update notice] received unknown BC cmd: 10feb5050427001c00
2019-10-26 10:01:20.908 [bus notice] >31<10feb5050427001c0079
2019-10-26 10:01:21.032 [bus notice] >31<cc
2019-10-26 10:01:21.157 [bus notice] >31<cc
2019-10-26 10:01:21.282 [bus notice] >31<cc
2019-10-26 10:01:21.415 [update notice] received unknown MS cmd: 1025b5040117 / 0101
2019-10-26 10:01:21.420 [bus notice] >31<1025b5040117c40001019a00
2019-10-26 10:01:21.545 [bus notice] >31<cc
2019-10-26 10:01:21.670 [bus notice] >31<cc
2019-10-26 10:01:21.826 [update notice] received unknown MS cmd: 1026b505072b0f0100000000 / 00
2019-10-26 10:01:21.831 [bus notice] >31<1026b505072b0f01000000003200000000
2019-10-26 10:01:21.956 [bus notice] >31<cc
2019-10-26 10:01:22.081 [bus notice] >31<cc
2019-10-26 10:01:22.206 [bus notice] >31<cc
2019-10-26 10:01:22.331 [bus notice] >31<cc
2019-10-26 10:01:22.456 [bus notice] >31<cc
2019-10-26 10:01:22.581 [bus notice] >31<cc
2019-10-26 10:01:22.706 [bus notice] >31<cc
2019-10-26 10:01:22.831 [bus notice] >31<cc
2019-10-26 10:01:22.955 [bus notice] >31<cc
2019-10-26 10:01:23.137 [update notice] received unknown MS cmd: 1008b5100900004000ffff040001 / 0101
2019-10-26 10:01:23.141 [bus notice] >31<1008b5100900004000ffff040001100001019a00
2019-10-26 10:01:23.267 [bus notice] >31<cc
2019-10-26 10:01:23.392 [bus notice] >31<cc
2019-10-26 10:01:23.517 [bus notice] >31<cc
2019-10-26 10:01:23.642 [bus notice] >31<cc
2019-10-26 10:01:23.766 [bus notice] >31<cc
2019-10-26 10:01:24.398 [bus notice] >31<10ecb5080206013300
2019-10-26 10:01:24.523 [bus notice] >31<cc
2019-10-26 10:01:24.648 [bus notice] >31<cc
2019-10-26 10:01:24.773 [bus notice] >31<cc
2019-10-26 10:01:24.921 [update notice] received unknown MS cmd: 1008b513020508 / 00
2019-10-26 10:01:24.925 [bus notice] >31<1008b513020508c600000000
2019-10-26 10:01:25.010 [main error] scan config 15: ERR: arbitration lost
2019-10-26 10:01:25.051 [bus notice] >31<cc
2019-10-26 10:01:25.176 [bus notice] >31<cc
2019-10-26 10:01:25.300 [bus notice] >31<cc
2019-10-26 10:01:25.424 [bus notice] >31<10
Wäre interessant, was Deine Raspis auf
sudo lsmod und
sudo modinfo ttyebus
sagen.
Greetz
Det :)
Hi Det,
erneut vielen Dank!
Mit dem ttyebus kernel module scheint jetzt alles soweit zu laufen
Vielen Dank an alle für die Hilfe!
Grüße
Zitat von: dnlGrande am 26 Oktober 2019, 09:02:34
sudo ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyAMA0 --mqtthost=ubuntuserv1 --httpport=8080 --mqttport=1883
du musst schon das ttyebus Modul benutzen, sonst klappt das nicht.
Zitat von: john30 am 25 Oktober 2019, 12:58:27
du kannst helfen, die messages zu finden, indem du folgendes tust:
- "ebusctl grab result" aufrufen und das Ergebnis als Datei abspeichern
- An der VRC 700 den Legionennschutz umkonfigurieren und die verwendeten Werte notieren.
- "ebusctl grab result" erneut aufrufen und das Ergebnis als zweite Datei abspeichern
- die beiden Files (oder nur die Differenzen) und die verwendeten Werte posten, dann kann man darauf wahrscheinlich eine CSV Definition bauen
Ich hab das jetzt mal gemacht, aber offensichtlich keine Informationen erhalten, die den Legionellenschutz betreffen. Die Unterschiede in den beiden Dateien sind:
6c6
< 1008b5100900004dffffff040000 / 0101 = 2390686: bai SetMode
---
> 1008b5100900004dffffff040000 / 0101 = 2390687: bai SetMode
18c18
< 1008b5110101 / 094647b00dff460000ff = 2386000: bai Status01
---
> 1008b5110101 / 094646b00dff450000ff = 2386001: bai Status01
also die übliche Kommunikation zwischen der Regelung und der Heizung im 10-Sekunden Abstand.
Das überrascht mich aber auch nicht wirklich, da ich ja direkt an der Regelung einen Wert geändert habe und wieso sollte die das dann über den ebus kommunizieren? Die Regelung speichert doch nur den neuen Wert und verhält sich entsprechend.
VG
Günni
Zitat von: guenni am 27 Oktober 2019, 16:27:58
Ich hab das jetzt mal gemacht, aber offensichtlich keine Informationen erhalten, die den Legionellenschutz betreffen. Die Unterschiede in den beiden Dateien sind:
6c6
< 1008b5100900004dffffff040000 / 0101 = 2390686: bai SetMode
---
> 1008b5100900004dffffff040000 / 0101 = 2390687: bai SetMode
18c18
< 1008b5110101 / 094647b00dff460000ff = 2386000: bai Status01
---
> 1008b5110101 / 094646b00dff450000ff = 2386001: bai Status01
also die übliche Kommunikation zwischen der Regelung und der Heizung im 10-Sekunden Abstand.
Das überrascht mich aber auch nicht wirklich, da ich ja direkt an der Regelung einen Wert geändert habe und wieso sollte die das dann über den ebus kommunizieren? Die Regelung speichert doch nur den neuen Wert und verhält sich entsprechend.
ah stimmt, das hatte ich übersehen.
dann das selbe Procedere aber mit readallvaillantregisters.sh (https://github.com/john30/ebusd/blob/master/contrib/scripts/readallvaillantregisters.sh) statt ebusctl grab result
readallvaillantregisters.sh fragt doch aber auch die Heizung ab, nicht die Regelung. Und ich müsste doch die Regelung steuern/ändern damit ich einen Effekt erziele. Denn wenn ich mithilfe der Erkenntnisse, die mir readallvaillantregisters.sh liefert, die Heizung beeinflussen würde, würde doch trotzdem die Regelung beim nächtsen Fälligkeitstermin für das Legionellenschutzprogramm der Heizung wieder "sagen": "Speicher auf 70° aufheizen". Oder irre ich mich hier?
VG Günni
Zitat von: guenni am 28 Oktober 2019, 10:57:55
readallvaillantregisters.sh fragt doch aber auch die Heizung ab, nicht die Regelung. Und ich müsste doch die Regelung steuern/ändern damit ich einen Effekt erziele. Denn wenn ich mithilfe der Erkenntnisse, die mir readallvaillantregisters.sh liefert, die Heizung beeinflussen würde, würde doch trotzdem die Regelung beim nächtsen Fälligkeitstermin für das Legionellenschutzprogramm der Heizung wieder "sagen": "Speicher auf 70° aufheizen". Oder irre ich mich hier?
richtig, dann musst du halt das Skript mit Parameter "-a 15" aufrufen, um bspw. Slave 0x15 abzufragean
Ich habe jetzt herausgefunden, welche MessageID ich für das Legionellenschutzprogramm benutzen muss:
aus vs. Donnerstag
< 020000002b00 = 0603002b000000
---
> 020000002b00 = 0603002b000400
16:30 vs. 17:40
< 020000002a00 = 0703002a00101e00
---
> 020000002a00 = 0703002a00112800
Ich hab mich aber noch nicht in ausreichendem Maße mit der Konfiguration von Messages befasst, so daß es mir noch nicht gelungen ist, per "ebusctl define" eine Messagedefinition zu erzeugen, die die Werte schreibt (lesen habe ich geschafft). Per "ebusctl hex" funktioniert das Schreiben.
Vielleicht kannst Du, John, mir da weiterhelfen.
VG
Günni
Zitat von: guenni am 29 Oktober 2019, 21:03:54
Ich habe jetzt herausgefunden, welche MessageID ich für das Legionellenschutzprogramm benutzen muss:
aus vs. Donnerstag
< 020000002b00 = 0603002b000000
---
> 020000002b00 = 0603002b000400
16:30 vs. 17:40
< 020000002a00 = 0703002a00101e00
---
> 020000002a00 = 0703002a00112800
Ich hab mich aber noch nicht in ausreichendem Maße mit der Konfiguration von Messages befasst, so daß es mir noch nicht gelungen ist, per "ebusctl define" eine Messagedefinition zu erzeugen, die die Werte schreibt (lesen habe ich geschafft). Per "ebusctl hex" funktioniert das Schreiben.
Vielleicht kannst Du, John, mir da weiterhelfen.
dann poste doch mal die read Definition. Üblicherweise ist die andere Richtung dann ganz banal.
Hi zusammen,
ich hab die letzten Tage etwas mit den read und wirte commands für meine Vaillant Steuerung "gespielt" - dabei sind mir ein paar Sachen aufgefallen.
1. Für den Kreis "hc" der Vaillant auroTERM - SOLSY id 26 - scheinen ein paar Set-Befehle zu fehlen. Zumindest, wenn ich das mit dem Kreis "mc" vergleiche. So kann der Betriebsmodus und die Heizkurve erst verstellt werden, wenn die entsprechenden Befehle definiert wurden:
# Vorlage mc
# w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
# w,mc,SetHeatingCurve,Heizkurve setzen,,50,b505,0b,curve,m,UIN,100,,Heizkurve
#
# definition für hc
define "w,hc,SetMode,Betriebsart setzen,,26,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Heizkreis Modus"
define "w,hc,SetHeatingCurve,Heizkurve setzen,,26,b505,0b,curve,m,UIN,100,,Heizkurve"
Kann man diese Befehle in die allgemeine "Befehlsliste" aufnehmen, damit man sie nicht nach jedem reboot des Pi neu definieren muss?
2. Beim Auslesen der Heizkurven HeatingCurve liefert der ebusd nach dem Schreiben mit "SetHeatingCurve" allerdings weiterhin die alten Werte - die Steuerung hat die neuen Werte über "SetHeatingCurve" direkt übernommen (direkt an der Steuerung geprüft; sowohl für mc als auch hc).
Erst wenn man den Befehlt "HeatingCurve" auch beschreibt, dann wird der Wert wohl aktualisiert und anschließend mit einem read auch ausgegeben. DAbei spielt es scheinbar keine Rolle, welchen Befehl man für "write -c hc HeatingCurve x" eingibt, da dieser nicht geschrieben wird aber für das aktualisieren notwendig ist.
localhost: write -c hc SetHeatingCurve 0.65
done
localhost: read -c hc HeatingCurve
0.70
localhost: write -c hc HeatingCurve 0.7
done
localhost: read -c hc HeatingCurve
0.65
Update: Das Problem scheint aktuell nur temporär zu sein - ich vermute, dass ebusd nicht immer direkt eine für ihn bekannte Message direkt wieder auf dem Bus sendet, solange er keinen Grund dafür erkannt hat. Das kann mit einem "write" oder auch anderen Messages aufgelöst werden.
3. read-Befehle für bestimmte Kommandos liefern den falschen Wert zurück bzw. werden nicht immer ausgeführt. In dem Beispiel werden die beiden Heizkurven für hc und mc auf unterschiedliche Werte eingestellt (Einstellung an der Steuerung direkt geprüft und OK).
localhost: write -c hc SetHeatingCurve 0.75
done
2019-10-31 22:46:45.355 [update notice] sent write hc SetHeatingCurve QQ=31: 0.75
2019-10-31 22:46:45.360 [main notice] write hc SetHeatingCurve: decode done
localhost: write -c mc SetHeatingCurve 0.70
done
2019-10-31 22:47:40.483 [update notice] sent write mc SetHeatingCurve QQ=31: 0.70
2019-10-31 22:47:40.487 [main notice] write mc SetHeatingCurve: decode done
2019-10-31 22:47:40.494 [bus notice] >3150b505030b46003c<000000>00
localhost: read -c mc HeatingCurve
0.65
# kein ebus send message zu finden - zudem war zuvor 0.60 für mc eingestellt (0.65 war hc)
localhost: read -c hc HeatingCurve
0.65
# jetzt auch keine ebus send message für den hc read zu finden - die 0.65 waren die alte Einstellung
localhost: read -c hc HeatingCurve
0.75
2019-10-31 22:50:28.824 [update notice] sent read hc HeatingCurve QQ=31: 0.75
2019-10-31 22:50:28.831 [bus notice] >3126b509030d3500d1<00064b0046007800c1>00
# Wiederholung nach kurzer Zeit brachte die send message hervor und der hc Wert wurde korrekt ausgegeben
localhost: read -c mc HeatingCurve
0.75
2019-10-31 22:51:33.521 [update notice] sent read mc HeatingCurve QQ=31: 0.75
2019-10-31 22:51:33.528 [bus notice] >3150b509030d3500c8<00064b0046007800c1>00
# anschl. Nochmals für mc ausgelesen - hier wird der Wert des hc zurück gemeldet.
localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0
Hier wird von der Steuerung also der Wert für die mc HeatingCurve nicht korrekt zurück gegeben - auf dem Bus ist bereits der falsche Wert zu sehen '4b' = 75 (5. & 6. Stelle in der Antwort); also scheint das Problem nicht am ebusd zu liegen.
In den "Params" von mc wird der Wert korrekt ausgegeben. Könnte es daher ggf. an einer falschen Adresse bei dem "read -c mc HeatingCurve" liegen? Oder ist das wirklich "nur" ein Bug in der Vaillant Steuerung?
Bei anderen Werten habe ich aktuell den gleichen Verdacht - z.B. TempDesiredLow.
Hier wird bei mc auch der Wert von hc zurück gegeben, obwohl er in der Message "Params" richtig hinterlegt zu sein scheint.
localhost: read -c hc TempDesiredLow
18.0
localhost: read -c mc TempDesiredLow
18.0
localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0
Kennt das Problem jemand und hat ggf. auch eine Lösung? Über die Suche habe ich leider nichts konkretes gefunden...
Gestartet wurde ebusd für diese Versuche über diesen Weg (systemd deamon wurde vorher gestoppt):
ebusd --lograwdata --configpath=http://ebusd.eu/config/ --scanconfig=full -f -d /dev/ttyebus --mqtthost=localhost --httpport=8088 --mqttport=1883 --mqttretain --mqttignoreinvalid --enablehex --enabledefine
Vielen Dank und Grüße
Bei einem einfachen read liefert der ebusd die Werte aus seinem Cach. Wenn du die Werte direkt vom eBus haben möchtest, musst du die Option -f beim read verwenden.
Gruß
Maik
Zitat von: john30 am 30 Oktober 2019, 08:53:22
dann poste doch mal die read Definition. Üblicherweise ist die andere Richtung dann ganz banal.
Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:
ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"
John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?
VG
Günni
Zitat von: guenni am 01 November 2019, 17:36:10
Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:
ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"
John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?
poste doch mal dein "scan result", anhand dessen wird die .inc gepickt
Zitat von: john30 am 02 November 2019, 08:39:05
poste doch mal dein "scan result", anhand dessen wird die .inc gepickt
pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;BAI00;0104;7803;21;18;34;0010021924;0001;009260;N7
15;Vaillant;70000;0510;6403;21;18;32;0020242192;0082;050499;N6
ec;Vaillant;70000;0510;6403;21;18;32;0020242192;0082;050499;N6
Zitat von: dnlGrande am 31 Oktober 2019, 23:17:31
1. Für den Kreis "hc" der Vaillant auroTERM - SOLSY id 26 - scheinen ein paar Set-Befehle zu fehlen. Zumindest, wenn ich das mit dem Kreis "mc" vergleiche. So kann der Betriebsmodus und die Heizkurve erst verstellt werden, wenn die entsprechenden Befehle definiert wurden:
# Vorlage mc
# w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
# w,mc,SetHeatingCurve,Heizkurve setzen,,50,b505,0b,curve,m,UIN,100,,Heizkurve
#
# definition für hc
define "w,hc,SetMode,Betriebsart setzen,,26,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Heizkreis Modus"
define "w,hc,SetHeatingCurve,Heizkurve setzen,,26,b505,0b,curve,m,UIN,100,,Heizkurve"
Kann man diese Befehle in die allgemeine "Befehlsliste" aufnehmen, damit man sie nicht nach jedem reboot des Pi neu definieren muss?
konntest du die Funktionsfähigkeit der Defs vollständig nachvollziehen?
Zitat von: dnlGrande am 31 Oktober 2019, 23:17:31
2. Beim Auslesen der Heizkurven HeatingCurve liefert der ebusd nach dem Schreiben mit "SetHeatingCurve" allerdings weiterhin die alten Werte - die Steuerung hat die neuen Werte über "SetHeatingCurve" direkt übernommen (direkt an der Steuerung geprüft; sowohl für mc als auch hc).
Erst wenn man den Befehlt "HeatingCurve" auch beschreibt, dann wird der Wert wohl aktualisiert und anschließend mit einem read auch ausgegeben. DAbei spielt es scheinbar keine Rolle, welchen Befehl man für "write -c hc HeatingCurve x" eingibt, da dieser nicht geschrieben wird aber für das aktualisieren notwendig ist.
localhost: write -c hc SetHeatingCurve 0.65
done
localhost: read -c hc HeatingCurve
0.70
localhost: write -c hc HeatingCurve 0.7
done
localhost: read -c hc HeatingCurve
0.65
Update: Das Problem scheint aktuell nur temporär zu sein - ich vermute, dass ebusd nicht immer direkt eine für ihn bekannte Message direkt wieder auf dem Bus sendet, solange er keinen Grund dafür erkannt hat. Das kann mit einem "write" oder auch anderen Messages aufgelöst werden.
solange die read und write Definition nicht exakt den gleichen Namen tragen, weiß ebusd nichts von dem Zusammenhang und beantwortet ein read an HeatingCurve aus dem Cache. da müsstest Du also die Verwendung des Cache beim Lesen unterbinden (read -f). Besser ist es, der Write Definition den gleichen Namen zu geben, dann invalidiert ebusd den read cache bei jedem Schreiben an die Write automatisch.
Zitat von: dnlGrande am 31 Oktober 2019, 23:17:31
3. read-Befehle für bestimmte Kommandos liefern den falschen Wert zurück bzw. werden nicht immer ausgeführt. In dem Beispiel werden die beiden Heizkurven für hc und mc auf unterschiedliche Werte eingestellt (Einstellung an der Steuerung direkt geprüft und OK).
localhost: write -c hc SetHeatingCurve 0.75
done
2019-10-31 22:46:45.355 [update notice] sent write hc SetHeatingCurve QQ=31: 0.75
2019-10-31 22:46:45.360 [main notice] write hc SetHeatingCurve: decode done
localhost: write -c mc SetHeatingCurve 0.70
done
2019-10-31 22:47:40.483 [update notice] sent write mc SetHeatingCurve QQ=31: 0.70
2019-10-31 22:47:40.487 [main notice] write mc SetHeatingCurve: decode done
2019-10-31 22:47:40.494 [bus notice] >3150b505030b46003c<000000>00
localhost: read -c mc HeatingCurve
0.65
# kein ebus send message zu finden - zudem war zuvor 0.60 für mc eingestellt (0.65 war hc)
localhost: read -c hc HeatingCurve
0.65
# jetzt auch keine ebus send message für den hc read zu finden - die 0.65 waren die alte Einstellung
localhost: read -c hc HeatingCurve
0.75
2019-10-31 22:50:28.824 [update notice] sent read hc HeatingCurve QQ=31: 0.75
2019-10-31 22:50:28.831 [bus notice] >3126b509030d3500d1<00064b0046007800c1>00
# Wiederholung nach kurzer Zeit brachte die send message hervor und der hc Wert wurde korrekt ausgegeben
localhost: read -c mc HeatingCurve
0.75
2019-10-31 22:51:33.521 [update notice] sent read mc HeatingCurve QQ=31: 0.75
2019-10-31 22:51:33.528 [bus notice] >3150b509030d3500c8<00064b0046007800c1>00
# anschl. Nochmals für mc ausgelesen - hier wird der Wert des hc zurück gemeldet.
localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0
das ist dann ne cache Antwort, siehe oben.
Zitat von: dnlGrande am 31 Oktober 2019, 23:17:31
Hier wird von der Steuerung also der Wert für die mc HeatingCurve nicht korrekt zurück gegeben - auf dem Bus ist bereits der falsche Wert zu sehen '4b' = 75 (5. & 6. Stelle in der Antwort); also scheint das Problem nicht am ebusd zu liegen.
In den "Params" von mc wird der Wert korrekt ausgegeben. Könnte es daher ggf. an einer falschen Adresse bei dem "read -c mc HeatingCurve" liegen? Oder ist das wirklich "nur" ein Bug in der Vaillant Steuerung?
ich tippe hier auf eine Steuerungs-interne Spezialität
Zitat von: dnlGrande am 31 Oktober 2019, 23:17:31
Bei anderen Werten habe ich aktuell den gleichen Verdacht - z.B. TempDesiredLow.
Hier wird bei mc auch der Wert von hc zurück gegeben, obwohl er in der Message "Params" richtig hinterlegt zu sein scheint.
localhost: read -c hc TempDesiredLow
18.0
localhost: read -c mc TempDesiredLow
18.0
localhost: read -c mc Params
22;19;0.70;mixer;13;0;25;38;0
Kennt das Problem jemand und hat ggf. auch eine Lösung? Über die Suche habe ich leider nichts konkretes gefunden...
bei solchen Tests unbedingt immer "read -f ..." benutzen, da sonst der ebusd Cache antwortet.
Zitat von: guenni am 01 November 2019, 17:36:10
Ich habe nach einem etwas gründlicherem Studium der Dokumentation (ich weiß, hätte ich schon eher machen sollen:)) auch die Mesagedefinitionen für das Schreiben der Legionellenschutzprogramm-Werte hinbekommen. Hier sind die Definitionen zum Lesen und Schreiben:
ebusctl define -r "r,700,LegioTag,Legionellen Tag,,15,b524,020000002b00,,s,IGN:4,,,,,s,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,,"
ebusctl define -r "w,700,LegioTag,Legionellen Tag,,15,b524,020100002b00,,,UIN,0=aus;1=Mo;2=Di;3=Mi;4=Do;5=Fr;6=Sa;7=So;8=Mo-So,"
ebusctl define -r "r,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020000002a00,,s,IGN:4,,,,,s,HTM,"
ebusctl define -r "w,700,LegioZeit,Legionellen Uhrzeit,,15,b524,020100002a00,,,HTM,,,,,,BCD,=0,"
John, könntest Du dies in Konfig 15.700 mit aufnehmen?.
Und ich habe noch einen "Änderungswunsch" für eine Konfig-Datei. Der ebusd zieht für meine Heizung die Konfigurationsdatei bai.308523.inc. Die Message-ID für die Heizungsteillast (Register d.00) ist bei mir aber nicht "0704", sondern "6C00". Könntest du das auch ändern, oder zieht der ebusd evtl. die falsche Konfigurationsdatei?
so ganz nehme ich die Definition noch nicht ab. insbes. die 0=aus sowie die Länge 4 im UIN weichen von allen anderen bisherigen Defintionen ab. Könntest Du bitte mal die read Message als Hex posten? die solltest du mittels "find -d -h LegioTag" bekommen. Und bitte finde raus, ob 1=Mo wirklich am Montag zum Start der Funktion führt.
Hi John,
erstmal danke für deine Arbeit und deine Hilfe - und sorry, dass ich erst jetzt wieder zum Antworten komme... das mit den cache antworten habe ich dann auch verstanden.
Zitat von: john30 am 05 November 2019, 08:58:27
# Vorlage mc
# w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
# w,mc,SetHeatingCurve,Heizkurve setzen,,50,b505,0b,curve,m,UIN,100,,Heizkurve
#
# definition für hc
define "w,hc,SetMode,Betriebsart setzen,,26,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Heizkreis Modus"
define "w,hc,SetHeatingCurve,Heizkurve setzen,,26,b505,0b,curve,m,UIN,100,,Heizkurve"
konntest du die Funktionsfähigkeit der Defs vollständig nachvollziehen?
Wenn du damit meinst, ob ich alle möglichen Werte mit den Befehlen geprüft habe -> leider nein. Die einzelnen Modis per SetMode habe ich geprüft, aber z.B. noch keine fehlerhaften Eingaben. Bei SetHeatingCurve habe ich auch nicht alle möglichen Daten getestet - nur ein paar relevante Werte zwischen 0,5 und 0,75 mit 0,05 Skalierung.
Aber es handelt sich um bestehende Definitionen, bei denen ich lediglich den circuit und die entsprechende Adresse ausgetauscht - alles andere blieb gleich.
Da ich nur bestehende Definitionen von mc auf hc übernommen habe wollte ich erstmal keine bestehenden Definitionen überschreiben.
Zudem gibt "mc Mode" auch mehr als den aktuellen Modus zurück; daher wollte ich in diese Definition nicht auch noch schreiben (kenn mich ja so schon kaum aus, dann war mir das zu heiß).
# vergleich der beiden Befehle aus der auto-config für mc Mode und SetMode
# definition von r,mc,Mode
r,mc,Mode,Betriebsart/Temperatur,,50,b504,01,temp0,s,UCH,,°C,Temperatur,mcmode,s,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus,days,s,UCH,,,Tage,temp0,s,UCH,,°C,Temperatur,mcmode,s,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus,mctype7,s,BI0:7,0=inactive;1=mixer;2=fixed;3=hwc;4=returnincr;5=pool,,Mischer Typ,,s,IGN:1,,,,daynight,s,UCH,0=night;1=day;7=floorpaving,,Tag-/Nachtmodus
#definition von w,mc,SetMode
w,mc,SetMode,Betriebsart setzen,,50,b505,02,mcmode,m,UCH,0=disabled;1=on;2=off;3=auto;4=eco;5=low,,Mischer Modus
Zu mehr bin ich in den letzten Tagen leider nicht gekommen...
Ich würde in nächster Zeit mal versuchen die Definition in eine lokale Config zu schreiben und von dort zu laden, damit sie nach einem reboot auch wieder vorhanden sind... oder hättest du noch einen anderen/ weiteren guten Tip?
Danke und Grüße
Zitat von: john30 am 10 November 2019, 17:38:34
so ganz nehme ich die Definition noch nicht ab. insbes. die 0=aus sowie die Länge 4 im UIN weichen von allen anderen bisherigen Defintionen ab. Könntest Du bitte mal die read Message als Hex posten? die solltest du mittels "find -d -h LegioTag" bekommen. Und bitte finde raus, ob 1=Mo wirklich am Montag zum Start der Funktion führt.
pi@raspberrypi:~ $ ebusctl find -d -h legiotag
700 LegioTag = 3115b52406020000002b00 / 0603002b000000
Aktuell ist der Legionellenschutz ausgeschaltet. Und die Interpretation der Werte (0 bis 8 ) habe ich direkt an der Regelung überprüft (d.h. per "ebusctl w" geändert und dann an der Reglung kontrolliert, und umgekehrt).
Änderung auf Montag:
pi@raspberrypi:~ $ ebusctl w -c 700 legiotag 1
done
pi@raspberrypi:~ $ ebusctl r legiotag
Mo
pi@raspberrypi:~ $ ebusctl find -d -h legiotag
700 LegioTag = 3115b52406020000002b00 / 0603002b000100
VG
Günni
Nachtrag: die Heizung hat heute zu der definierten Zeit begonnen, das Wasser zu erhitzen; d.h. das Legionellenschutzprogramm wurde gestartet.
VG
Günni
Hi,
ich habe auch einen neuen Adapter in Betrieb genommen.
Am Raspi 4 habe ich den ttyebus Driver nicht zum laufen gebracht. Ich schätze die I/O... Adressen liegen dort wo anders.
Am 3B funktioniert es.
Für meine Ochsner OTE3 Wärmepumpe kann ich auch schon die wichtigsten Werte dekodiert.
Leider habe ich am MQTT Bus hin und wieder Probleme das ein 2tes Werte-paar im gleichen Wert auftaucht.
Als Beispiel: der erste Teil bis Temperatur ist ein anderer Wert.
ebusd/WP-SOLL-IST/02-080-Schaltzyklen
{
"group": {"value": 130},
"value": {"value": 0},
"type": {"value": "0d"},
"unit": {"value": "02"},
"max": {"value": 1000},
"min": {"value": 0},
"temperature": {"value": 37.7}}{
"group": {"value": 80},
"value": {"value": 1},
"type": {"value": "1d"},
"unit": {"value": "00"},
"max": {"value": 1},
"cycles": {"value": 7807}}
Mit ebusctl find -d schaut alles gut aus.
WP-SOLL-IST 02-080-Schaltzyklen = 80;1;1d;00;1;7807
WP-SOLL-IST 21-002-Volumstrom = 130;10;0d;34;1000;0;16.4
HZ-SOLL-IST 01-002-Sollwert-heizkreis_Vorlauf = 130;0;0d;02;1000;0;37.7
Keine Ahnung wieso. Hat das jemand schon mal gehabt? Kann das am Config File liegen?
Vielen Dank, Markus
ja, das kenne ich, kommt auch bei den Statusmeldungen vor!
Du solltest MQTT2 verwenden und dann beim MQTT2_Server (oder Client wenn du den verwendest) autocreate auf "complex" stellen!
Ich habe da hier (https://wiki.fhem.de/wiki/EBUS-MQTT2)einmal zusammen geschrieben.
Hier unten im Bild siehst du die beiden Statusmeldungen mit jeweils gleichen Datenpunkten. Bei Complex, wird dann allerdings auch der erste Part dazu gehängt und kann somit unterschieden werden.
Ach ja, mit jsonmap kannst du dann auch sprechende Namen vergeben so wie im Bild.
Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
Status02_0_value:_HWCMode
Status02_1_value:_Maximaltemperatur
Status02_2_value:_ReglerMaxTEMP
Status02_3_value:_ReglerCurrentTemp
LG
Das Problem dürfte schon vor FHEM liegen. Bei der Verbindung von EBUSD zu MQTT.
Habe den Beginn des Problems gefunden.
Es werden die Werte von "02-020-Aussentemp-mittel" im nächsten Datensatz "01-007-Soll-Temp-TWV-Vorlauf" wiederholt, obwohl sie überhaupt nichts miteinander zu tun haben.
Und bei "01-007-Soll-Temp-TWV-Vorlauf" sollte nur der zweite Teil stehen sollte.
Mit ebusctl find stimmt alles, in einem MQTT Logging Prog. sieht man das die Daten zusammengehängt sind...
ebusd/HZ-SOLL-IST/02-020-Aussentemp-mittel
{
"group": {"value": 20},
"value": {"value": 1},
"type": {"value": "0d"},
"unit": {"value": "02"},
"max": {"value": 500},
"min": {"value": -500},
"temperature": {"value": 6.8}}
ebusd/WP-SOLL-IST/01-007-Soll-Temp-TWV-Vorlauf
{
"group": {"value": 20},
"value": {"value": 1},
"type": {"value": "0d"},
"unit": {"value": "02"},
"max": {"value": 500},
"min": {"value": -500},
"temperature": {"value": 6.8}}{
"group": {"value": 135},
"value": {"value": 0},
"type": {"value": "0d"},
"unit": {"value": "02"},
"max": {"value": 1000},
"min": {"value": 0},
"temperature": {"value": 0.0}}
...etwas off topic, was ist das denn für ein Logging Prog. ? ich stehe nämlich so ein kleinwenig mit Mqtt auf Kriegsfuss und das könnte etwas helfen...
Grüsse Christian
@max78
Die Art und Type der Messpunkte ist mir nicht bekannt, spielt aber keine Rolle. Wie gesagt, mit "complex" erhältst du dann 2 verschiedene Readings angelegt und daher sollte es kein Problem darstellen das weiter zu verarbeiten.
Es sieht irgendwie so aus, als würde beim "WP-SOLL-IST/01-007-Soll-Temp-TWV-Vorlauf" hier ein Teil aus dem Cache nochmals gelistet. Teste doch mal und frage vorher was anderes ab. Mit was logst du eigentlich, ist das ein Mosquitto Log?
LG
Zitat von: cs-online am 12 November 2019, 18:22:05
...etwas off topic, was ist das denn für ein Logging Prog. ? ich stehe nämlich so ein kleinwenig mit Mqtt auf Kriegsfuss und das könnte etwas helfen...
Grüsse Christian
also wenn du MQTT2 einsetzt logst du ganz normal in Fhem mit verbose 5. Wenn du Mosquitto einsetzt dann logst du ganz normal mit Mosquitto in der Konsole.
Das sieht dann in etwa so aus wenn was reinkommt (MQTT2)
2019.11.12 19:23:32 5: in: PUBLISH: 0(241)(1)(0)(18)ebusd/bai/Status02{(10) "0": {"name": "hwcmode", "value": "auto"},(10) "1": {"name": "temp0", "value": 60},(10) "2": {"name": "temp1", "value": 70.0},(10) "3": {"name": "temp0", "value": 70},(10) "4": {"name": "temp1", "value": 48.0}}
2019.11.12 19:23:32 4: ebusMQTT_10.0.0.6_39188 ebusd_3.3_565 PUBLISH ebusd/bai/Status02:{
"0": {"name": "hwcmode", "value": "auto"},
"1": {"name": "temp0", "value": 60},
"2": {"name": "temp1", "value": 70.0},
"3": {"name": "temp0", "value": 70},
"4": {"name": "temp1", "value": 48.0}}
2019.11.12 19:23:32 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.3_565\000ebusd/bai/Status02\000{\n "0": {"name": "hwcmode", "value": "auto"},\n "1": {"name": "temp0", "value": 60},\n "2": {"name": "temp1", "value": 70.0},\n "3": {"name": "temp0", "value": 70},\n "4": {"name": "temp1", "value": 48.0}}Warum stehst du mit MQTT auf Kriegsfuß, bei MQTT2 geht doch alles von selbst und es stehen außerdem noch Templates zur Verfügung, die formatieren die Readings vollautomatisch.
LG
Habe mal eine Frage zu den CSV-Definitionen; wahrscheinlich am ehesten an john30 :-)
Ich verstehe die Erklärung zu Update-Nachrichten nicht ganz:
Zitatany other character: update
All of the remaining characters can be used to define a passive message that ebusd will listen to in order to recognize updates of field values. If the type is suffixed with a "w", the message is treated as write message as mentioned above. Otherwise it is treated as read message.
Was ich in den Beispielen bzw. Konfigs anderer Geräte sehe, sind Update-Nachrichten komplett andere als Read- oder Write-Nachrichten.
Was ich gern erreichen würde: meine multiMATIC VRC700 erzeugt schon viel Last auf dem Bus, um mit allen möglichen Teilnehmern zu kommunizieren.
Dabei gibt es sowohl Reads, als auch Writes. Damit ich im Log nicht ständig "unknown MS cmd" lese, habe ich einige davon entschlüsselt und z.Bsp. zu meinem Mischermodul VR71 folgende CSV erstellt:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,VR_71,VR 71,104 104,,,,,,,,,,
*r,,,,,,"B523",,,,,,,,,,
*w,,,,,,"B523",,,,,,,,,,
w,,SetActorState,,,,,05,R1,,UCH,0=off;20=on,,,R2,,UCH,0=off;20=on,,,R3,,UCH,0=off;20=on,,,R4,,UCH,0=off;20=on,,,R5,,UCH,0=off;20=on,,,R6,,UCH,0=off;20=on,,,R7,,UCH,0=off;20=on,,,R8,,UCH,0=off;20=on,,,R9,,UCH,0=off;20=on,,,R10,,UCH,0=off;20=on,,,R11,,UCH,0=off;20=on,,,R12,,UCH,0=off;20=on,,,Rx,,HEX:2,,,
w,,Mc1FlowTempDesired,,,,,0200,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,
w,,Mc2FlowTempDesired,,,,,0201,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,
w,,Mc3FlowTempDesired,,,,,0202,FTStatus,m,UCH,0=off;1=on,,,FTDesired,m,temp1,,,,MixerStatus,s,UCH,0=off;1=on,,,MixerMovement,s,percents,,,
r,,SensorData1,,,,,06,S1,,temp,,,,S2,,temp,,,,S3,,temp,,,,S4,,temp,,,,S5,,temp,,,,S6,,temp,,,,S7,,temp,,,,ignore,,HEX:2,,,
r,,SensorData2,,,,,07,S8,,temp,,,,S9,,temp,,,,S10,,temp,,,,S11,,temp,,,,S12,,temp,,,,Sx,,temp,,,,ignore,,HEX:3,,,
!include,errors.inc,,,,,,,,,,,,
Mit dieser steht nun schön im Log:
2019-11-27 11:11:34.487 [update notice] received write vr_71 SetActorState QQ=10: -;-;off;off;off;off;-;-;-;-;off;off;00 00
2019-11-27 11:11:34.860 [update notice] received write vr_71 Mc1FlowTempDesired QQ=10: on;38.5;on;35
2019-11-27 11:11:35.124 [update notice] received write vr_71 Mc2FlowTempDesired QQ=10: on;29.5;on;0
2019-11-27 11:11:43.315 [update notice] received read vr_71 SensorData1 QQ=10: 37.50;33.88;29.12;-;40.56;30.69;52.31;40 00
2019-11-27 11:11:43.728 [update notice] received read vr_71 SensorData2 QQ=10: 49.50;-;-;-;0.00;8.00;80 fc 05
Aber im Cache landen leider nur die Reads:
# ebusctl find -c vr_71
vr_71 currenterror = -;-;-;-;-
vr_71 errorhistory = no data stored
vr_71 SensorData1 = 37.19;33.25;29.06;-;40.19;30.75;52.31;40 00
vr_71 SensorData2 = 49.50;-;-;-;0.00;8.00;80 fc 05
Nun zur Frage: kann ich Ebusd irgendwie beibringen, auch mitgelesene Writes von anderen Busteilnehmern im Cache abzulegen, dass ich diese anschließend (aus dem Cache) auslesen kann?
Konkret geht es in diesem Beispiel u.a. um die geforderte Vorlauftemperatur - die kann ich zwar auch von der VRC700 (aktiv!) auslesen, erzeuge damit aber eine Nachricht auf dem Bus, obwohl die Info ohnehin alle paar Sekunden mitgelesen wird.
Zitat von: Sven77 am 27 November 2019, 11:21:08
Aber im Cache landen leider nur die Reads:
# ebusctl find -c vr_71
vr_71 currenterror = -;-;-;-;-
vr_71 errorhistory = no data stored
vr_71 SensorData1 = 37.19;33.25;29.06;-;40.19;30.75;52.31;40 00
vr_71 SensorData2 = 49.50;-;-;-;0.00;8.00;80 fc 05
naja, du hast halt auch nur nach den reads gefragt. "find -a" ist dein Freund :)
Ah, vielen Dank!
Den Schalter hatte ich wohl glatt übersehen - somit kann ich wenigstens über einige Umwege die passiven Reads auslesen, z.Bsp. mittels
# ebusctl find -a -e -c vr_71 SensorData1
vr_71 SensorData1 = 47.12;49.06;37.38;-;51.50;35.38;54.19;40 00
Die gesuchten Temperaturen kann ich dann mit cut herauspicken - es wäre zwar einfacher, wenn man diese auch noch auswählen und das einleitende "vr_71 SensorData1" weglassen könnte - aber das bringt mich schon einen großen Schritt weiter!
Zitat von: Sven77 am 02 Dezember 2019, 13:39:09
Ah, vielen Dank!
Den Schalter hatte ich wohl glatt übersehen - somit kann ich wenigstens über einige Umwege die passiven Reads auslesen, z.Bsp. mittels
# ebusctl find -a -e -c vr_71 SensorData1
vr_71 SensorData1 = 47.12;49.06;37.38;-;51.50;35.38;54.19;40 00
Die gesuchten Temperaturen kann ich dann mit cut herauspicken - es wäre zwar einfacher, wenn man diese auch noch auswählen und das einleitende "vr_71 SensorData1" weglassen könnte - aber das bringt mich schon einen großen Schritt weiter!
wenn du die niemals aktiv via ebusd schreiben willst, wäre "uw" dein Freund beim Typ in der Definition, dann könntest du die mit read auch regulär lesen
Hallo! Hat jemand einen Tipp für mich? Wie kann ich die Therme über den ebusd ein/ausschalten (sprich heizen/nicht heizen)?
Therme: Vaillant ecoTEC exclusiv VC 206/4. KEIN ebus Regler vorhanden. Am ebus hängen nur die Therme und der ebus Adapter.
Derzeitige Ansteuerung ist über ein Relais am Raumthermostat.
Werte auslesen und setzen über den ebus Adapter funktioniert einwandfrei. Z.b. über FlowsetHcMax kann ich die max. Vorlauftemperatur einstellen (aber leider nicht soweit runter drehen, daß die Heizung aus bleibt).
Mein erster Ansatz war, über HeatingSwitch zwischen Sommer- und Winterbetrieb umzuschalten. Funktioniert aber nicht, da die Variable readonly ist (auch wenn ich im csv auf write stelle, nimmt die Therme Änderungen nicht an).
Wie geht man hier richtig vor? Was würde ein ebus Regler schicken um die Therme zu schalten?
info
version: ebusd 3.3.v3.3
update check: version 3.4 available, vaillant/08.bai.csv: different version available, vaillant/bai.0010006101.inc: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 118
min arbitration micros: 24
max arbitration micros: 323
min symbol latency: 0
max symbol latency: 48
reconnects: 0
masters: 2
messages: 231
conditional: 0
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0706;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2, ebusd (answering)
address 15: slave #2, ebusd (answering)
f -w
bai AccessoriesOne = no data stored
bai AccessoriesTwo = no data stored
bai AntiCondensValue = no data stored
bai BlockTimeHcMax = no data stored
bai clearerrorhistory = no data stored
bai DSNOffset = no data stored
bai ExhaustCurve = no data stored
bai FlowsetHcMax = no data stored
bai FlowsetHwcMax = no data stored
bai GVStepOffsetMax = no data stored
bai GVStepOffsetMin = no data stored
bai HcPumpMode = no data stored
bai HoursTillService = no data stored
bai HwcPostrunTime = no data stored
bai HwcTempMax = no data stored
bai PartloadHcKW = no data stored
bai PartloadHwcKW = no data stored
bai ReduceModulationBlocktime = no data stored
bai ReturnRegulation = no data stored
bai SecondPumpMode = no data stored
bai SetFactoryValues = no data stored
bai SpecialAdj = no data stored
bai StorageLoadTimeMax = no data stored
bai ValveMode = no data stored
bai WPPostrunTime = no data stored
bai WPPWMPowerDia = no data stored
broadcast id = no data stored
broadcast queryexistence = no data stored
memory eeprom = no data stored
memory ram = no data stored
Ohjee - da ist ja lt. CSV fast alles read-only!
Also ich habe bei meiner icoVIT156 folgende Nachricht in der CSV hinzugefügt, weil über diese die multiMATIC ihre gewünschte Vorlauftemperatur sendet:
w,,ExtFlowTempDesired,,,,B510,00,HwcSwitch,,HEX:1,,,,HcFlowTempDesired,,temp1,,,,HwcTappingDesired,,temp1,,,,HwcFlowTempDesired,,temp1,,,,Unknown1,,HEX:1,,,,Unknown2,,HEX:1,,,,Unknown3,,HEX:1,,,,Unknown4,,HEX:1,,,
Da zumindest einige Nachrichten, u.a. ExtFlowTempDesiredMin, mit deiner CSV übereinstimmen wäre es ein Versuch wert.
Wenn du darüber meldest, dass keine Wärme benötigt wird, sollte die Therme das eigentlich auch so anzeigen und akzeptieren.
Leider sind ein paar "Unknowns" dabei, hier habe ich noch nicht durchschaut, was die machen - aber folgende Zustände kenne ich:
Kein Wärmebedarf (also für deine Frage, wie man sie ausschalten kann):
[update notice] received write bai ExtFlowTempDesired QQ=10: 00;0.0;-;-;ff;01;00;00
Also HwcSwitch=0, HcFlowTempDesired=0, HwcTappingDesired=ff, HwcFlowTempDesired=ff, Unknown1=ff, Unknown2=01 und die letzten beiden 0.
Normale Anforderung für Heizkreis:
[update notice] received write bai ExtFlowTempDesired QQ=10: 00;50.0;44.0;-;ff;00;00;00
Also HwcSwitch=0, HcFlowTempDesired=50 (nach Bedarf ändern), HwcTappingDesired=44 (Sollwert Warmwasser), HwcFlowTempDesired=ff, Unknown1=ff und die letzten 3 alle 0.
Für (reine) Warmwasser Anforderung habe ich folgende beobachtet, müsstest du mal probieren wie sich diese auswirken:
received write bai ExtFlowTempDesired QQ=10: 01;-;44.0;-;ff;01;00;01
received write bai ExtFlowTempDesired QQ=10: 01;-;44.0;-;ff;01;c8;00
received write bai ExtFlowTempDesired QQ=10: 03;-;44.0;58.0;ff;01;00;01
received write bai ExtFlowTempDesired QQ=10: 03;-;44.0;58.0;ff;01;c8;00
Also wie ich das sehe: Unknown1 (bei mir) immer ff, Unknown2 scheint bei mir dieses VUV-Ventil umzuschalten (d.35).
Und HwcSwitch scheint auf 1 zu stehen, wenn nur Warmwasser gewünscht, aber aktuell kein Heizbedarf des Brenners erforderlich ist und auf 3, wenn er heizen soll.
Danke Sven! Das funktioniert!
Habe das ins bai.0010006101.inc eingetragen und mit den ExtFlowTempDesired Nachrichten läßt sich das nun wunderbar steuern.
Hatte anfangs bedenken, ob die alte Steuermethode (mittels Relais) weiterhin funktioniert wenn man einmal so ein Kommando absetzt. Ist aber kein Problem, die Therme stellt automatisch zurück, wenn eine Zeit lang kein weiteres Kommando kommt:
read -f EBusHeatControl
yes
nach etwa 15 Minuten:
read -f EBusHeatControl
no
Danke!
Zitat von: paul79 am 03 Februar 2018, 20:18:20
Hallo,
ich habe für meine Heizung mit VRC 700 die Brennstoffverbrauchsdaten vermisst und habe meine 15.700.csv von ebusd etwas erweitert, jetzt werden die auch angezeigt.
Zeile 27-33 durch diese Zeilen ersetzen.
r;w,,PrFuelSumHcThisMonth,ThisMonthsFConsumptionHc,,,,4E00,,,energy4,,,Aktueller Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcThisMonth,ThisMonthsEConsumptionHc,,,,4F00,,,energy4,,,Aktueller Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcThisMonth,ThisMonthsEConsumptionHwc,,,,5000,,,energy4,,,Aktueller Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcThisMonth,ThisMonthsFConsumptionHwc,,,,5100,,,energy4,,,Aktueller Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHcLastMonth,LastMonthsFConsumptionHc,,,,5200,,,energy4,,,Letzter Monat Brennstoffverbrauch Heizung
r;w,,PrEnergySumHcLastMonth,LastMonthsEConsumptionHc,,,,5300,,,energy4,,,Letzter Monat Stromverbrauch Heizung
r;w,,PrEnergySumHwcLastMonth,LastMonthsEConsumptionHwc,,,,5400,,,energy4,,,Letzter Monat Stromverbrauch Warmwasser
r;w,,PrFuelSumHwcLastMonth,LastMonthsFConsumptionHwc,,,,5500,,,energy4,,,Letzter Monat Brennstoffverbrauch Warmwasser
r;w,,PrFuelSumHc,TotalFConsumptionHc,,,,5600,,,energy4,,,Brennstoffverbrauch Heizung gesamt
r;w,,PrEnergySumHc,TotalEConsumptionHc,,,,5700,,,energy4,,,Stromverbrauch Heizung gesamt
r;w,,PrEnergySumHwc,TotalEConsumptionHwc,,,,5800,,,energy4,,,Stromverbrauch Warmwasser gesamt
r;w,,PrFuelSumHwc,TotalFConsumptionHwc,,,,5900,,,energy4,,,Brennstoffverbrauch Warmwasser gesamt
r;w,,PrEnergySum,TotalEConsumption,,,,5C00,,,energy4,,,Dieses Jahr Stromverbrauch gesamt
r;w,,PrFuelSum,TotalFConsumption,,,,5D00,,,energy4,,,Dieses Jahr Brennstoffverbrauch gesamt
Gruß Paul
Ich wurde gerade per PN gefragt, ob es schon die Brennstoffverbräuche gibt.
@John30: könntest du diese im GitHub mit aufnehmen?
Hi John,
ich musste nun wegen Wechsel auf RPI4 Buster neu installieren. Nun habe ich das dort so eingerichtet, wie vorher im Jessie, ich habe unter /ect/Default/ebusd
EBUSD_OPTS="--configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log"
EBUSD_OPTS1="--configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log"
dann die entsprechenden CSVs in die Ordner wie in der Konfig, dann zwei Dienste angelegt
1) ebusd.service : /lib/systemd/system/ebusd.service
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
[Install]
WantedBy=multi-user.target
2) ebusd2.service : /lib/systemd/system/ebusd2.service
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS1
[Install]
WantedBy=multi-user.target
Beide enabled. Beim Booten läd er einen von beiden (mal den einen, mal den anderen), der andere schlägt fehl. Es kommt ein Hinweis auf die pid-Datei. Ich habe schon versucht, im 2.Service ebus2.pid anzugeben, das klappt aber auch nicht. Wenn ich den Service beende, der nicht funktioniert und dann wieder starte, laufen beide und liefern auch beide Daten.
Nun bin ich leider nicht so fit in Sachen Service und co... Was mache ich denn falsch ?
Grüße
Christian
Hi Christan,
der PIDFile-Parameter muss natürlich unterschiedlich sein. Sonst gibt es Probleme beim beenden der Prozesse.
Nach den Änderungen den service-Dateien für systemd hast du da
systemctl daemon-reload
aufgerufen? Damit werden die Änderungen an den Konfigdateien erst geladen. Danach dann versuchen die ebusd zu stoppen und neu zu starten.
Der Befehl systemctl status ebusd liefert dann den Status der Dienste ggf. die Fehlermeldung dazu.
Gruß
Maik
Hallo Maik,
ja, das hatte ich gemacht. Hab nun nochmal im ebusd2 das ebusd.pid in ebusd2.pid geändert, dann systemctl daemon-reload, dann sudo reboot, dann:
pi@raspberrypi:~ $ systemctl status ebusd
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: activating (start) since Sun 2019-12-29 22:01:07 CET; 1min 15s ago
Process: 454 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
Memory: 1.2M
CGroup: /system.slice/ebusd.service
Dez 29 22:01:07 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:01:08 raspberrypi systemd[1]: ebusd.service: Failed to parse PID from file /run/ebusd.pid: Invalid argument
pi@raspberrypi:~ $ systemctl status ebusd2
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
Active: activating (start) since Sun 2019-12-29 22:01:07 CET; 1min 42s ago
Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 4915)
Memory: 1.9M
CGroup: /system.slice/ebusd2.service
└─486 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI0
Dez 29 22:01:07 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:01:08 raspberrypi systemd[1]: ebusd2.service: Can't open PID file /run/ebusd2.pid (yet?) after start: No such file or directory
Dann wieder zurück beim ebusd2.service auf ebusd.pid, dann systemctl daemon-reload, dann sudo reboot, dann:
pi@raspberrypi:~ $ systemctl status ebusd.service
● ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-12-29 22:11:21 CET; 1min 50s ago
Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=0/SUCCESS)
Main PID: 489 (ebusd)
Tasks: 6 (limit: 4915)
Memory: 2.5M
CGroup: /system.slice/ebusd.service
└─489 /usr/bin/ebusd --configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-p
Dez 29 22:11:19 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:11:21 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: timeout) since Sun 2019-12-29 22:13:02 CET; 21s ago
Process: 458 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
pi@raspberrypi:~ $ ebusctl
localhost: q
pi@raspberrypi:~ $ ebusctl -p 8889
localhost: q
mit anderen Worten: da lief es, nach erneutem reboot :
pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
Active: activating (start) since Sun 2019-12-29 22:21:35 CET; 25s ago
Process: 457 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
Tasks: 6 (limit: 4915)
Memory: 2.3M
CGroup: /system.slice/ebusd2.service
└─480 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if
Dez 29 22:21:35 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:21:36 raspberrypi systemd[1]: ebusd2.service: Failed to parse PID from file /run/ebusd.pid: Invalid argument
dann etwas gewartet :
pi@raspberrypi:~ $ systemctl stop ebusd2.service
pi@raspberrypi:~ $ systemctl start ebusd2.service
pi@raspberrypi:~ $ systemctl status ebusd2.service
● ebusd2.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/lib/systemd/system/ebusd2.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-12-29 22:25:05 CET; 5s ago
Process: 1180 ExecStart=/usr/bin/ebusd $EBUSD_OPTS1 (code=exited, status=0/SUCCESS)
Main PID: 1181 (ebusd)
Tasks: 4 (limit: 4915)
Memory: 588.0K
CGroup: /system.slice/ebusd2.service
└─1181 /usr/bin/ebusd --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-i
Dez 29 22:25:05 raspberrypi systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Dez 29 22:25:05 raspberrypi systemd[1]: Started ebusd, the daemon for communication with eBUS heating systems..
Mit anderen Worten: mal geht es und alles wird geladen, mal klappt nur die erste Instanz, mal nur die zweite, wenn man die fehlgeschlagene Instanz beendet und neu startet, gehen wieder beide... Klingt irgendwie nach einem Timing-Problem oder ?
Brauche ich denn eigentlich zwei Services, nur um zwei Instanzen (also zwei verschiedene EBUS-Adapter) gleichzeitig laufen lassen zu können ?
Moin Christian,
Per Default nutzt der ebusd-Daemon:
--pidfile=FILE
PID file name (only for daemon) [/var/run/ebusd.pid]
Du musst deine Default-Konfiguration für den ebusd-Daemon um den Parameter pidfile erweitern und dort auch noch angeben wo der Dämon seine PID Datei schreiben soll. Am besten auf die gleichen Werte wie in der Systemd-Konfiguration. :-)
Dann findet systemd auch die PID Datei vom zweiten Prozess und jeder Prozess kann gestoppt werden.
Schöne Grüße
Maik
Gesendet von meinem Aquaris_A4.5 mit Tapatalk
Super, das war's (hoffe ich) :) Danke dir, wieder etwas schlauer geworden ;D
Grüße Christian
Zitat von: istler am 30 Dezember 2019, 07:51:38
Per Default nutzt der ebusd-Daemon:
--pidfile=FILE
PID file name (only for daemon) [/var/run/ebusd.pid]
Du musst deine Default-Konfiguration für den ebusd-Daemon um den Parameter pidfile erweitern und dort auch noch angeben wo der Dämon seine PID Datei schreiben soll. Am besten auf die gleichen Werte wie in der Systemd-Konfiguration. :-)
Dann findet systemd auch die PID Datei vom zweiten Prozess und jeder Prozess kann gestoppt werden.
genau, Danke fürs Beantworten!
Zitat von: Sven77 am 20 Dezember 2019, 08:00:38
Ich wurde gerade per PN gefragt, ob es schon die Brennstoffverbräuche gibt.
@John30: könntest du diese im GitHub mit aufnehmen?
bitte via PR
Hallo,
ich habe den ebusd am RPI02 meiner Zeotherm über MQTT2 wieder an den RPI03 angeschlossen und lese einige Werte aus. Ein ebusctl scan hat verschiedene Module gefunden, zu denen auch die CSV's geladenw erden. Leider wird mir immer wieder ein neues MQTT2-Device mit den selben Inhalten und einer fortlaufenden Nummer angelegt. Es handelt sich um folgendes Device:
Internals:
CID ebusd_3.4_6139
DEF ebusd_3.4_6139
DEVICETOPIC MQTT2_ebusd_3.4_6139
FUUID 5e052225-f33f-6b6f-6ee1-6b98a5c7450a8a3e
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 1416
MQTT2_FHEM_Server_TIME 2019-12-28 21:02:45
MSGCNT 1416
NAME MQTT2_ebusd_3.4_6139
NR 1805
STATE Betriebszustand: Warmwasser <br>Vorlauftemperatur: 63.9 <br>Aussentemperatur: -2.4
TYPE MQTT2_DEVICE
READINGS:
2019-12-28 21:02:45 Betriebszustand Warmwasser
2019-12-28 21:02:45 FlowTemp_sensor_value ok
2019-12-28 21:02:45 FlowTemp_temp_value 63.94
2019-12-28 21:02:45 OutsideTemp_sensor_value ok
2019-12-28 21:02:45 OutsideTemp_temp_value -2.38
2019-12-28 21:02:45 StateEM_0_name
2019-12-28 21:02:45 StateEM_0_value water
2019-12-27 20:59:05 subscriptions ebusd/#
Attributes:
IODev MQTT2_FHEM_Server
devStateStyle style="text-align:right"
readingList ebusd_3.4_6139:ebusd/uiz/OutsideTemp:.* { json2nameValue($EVENT, 'OutsideTemp_', $JSONMAP) }
ebusd_3.4_6139:ebusd/uiz/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd_3.4_6139:ebusd/uiz/StateEM:.* { json2nameValue($EVENT, 'StateEM_', $JSONMAP) }
room 9.6.1_MQTT
stateFormat {sprintf("Betriebszustand: %s <br>Vorlauftemperatur: %.1f <br>Aussentemperatur: %.1f",
ReadingsVal($name,"Betriebszustand",0),
ReadingsVal($name,"FlowTemp_temp_value",0),
ReadingsVal($name,"OutsideTemp_temp_value",0))}
userReadings Betriebszustand {ReadingsVal($name, "StateEM_0_value", "") eq "heat" ? "Heizen" :
ReadingsVal($name, "StateEM_0_value", "") eq "water" ? "Warmwasser" :
ReadingsVal($name, "StateEM_0_value", "") eq "wateroverrun" ? "Nicht klar was das ist" :
"unbekannt"}
Danach:
Internals:
CFGFN
CID ebusd_3.4_6390
DEF ebusd_3.4_6390
DEVICETOPIC MQTT2_ebusd_3.4_6390
FUUID 5e07b60b-f33f-6b6f-41a0-0e4f5371305ef315
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 16
MQTT2_FHEM_Server_TIME 2019-12-28 21:17:41
MSGCNT 16
NAME MQTT2_ebusd_3.4_6390
NR 13438
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-12-28 21:17:41 FlowTemp_sensor_value ok
2019-12-28 21:17:41 FlowTemp_temp_value 40.12
2019-12-28 21:09:16 FrostOverRideTime_hours_value 1
2019-12-28 21:17:41 OutsideTemp_sensor_value ok
2019-12-28 21:17:41 OutsideTemp_temp_value -2.38
2019-12-28 21:17:41 StateEM_0_name
2019-12-28 21:17:41 StateEM_0_value heat
2019-12-28 21:07:39 subscriptions ebusd/#
Attributes:
IODev MQTT2_FHEM_Server
readingList ebusd_3.4_6390:ebusd/uiz/OutsideTemp:.* { json2nameValue($EVENT, 'OutsideTemp_', $JSONMAP) }
ebusd_3.4_6390:ebusd/uiz/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd_3.4_6390:ebusd/uiz/StateEM:.* { json2nameValue($EVENT, 'StateEM_', $JSONMAP) }
ebusd_3.4_6390:ebusd/uiz/FrostOverRideTime:.* { json2nameValue($EVENT, 'FrostOverRideTime_', $JSONMAP) }
room 9.6.1_MQTT
und gerade aktuell:
Internals:
CFGFN
CID ebusd_3.4_22589
DEF ebusd_3.4_22589
DEVICETOPIC MQTT2_ebusd_3.4_22589
FUUID 5e09d49f-f33f-6b6f-3984-1413cdae6047a9b9
IODev MQTT2_FHEM_Server
LASTInputDev MQTT2_FHEM_Server
MQTT2_FHEM_Server_MSGCNT 9
MQTT2_FHEM_Server_TIME 2019-12-30 11:47:44
MSGCNT 9
NAME MQTT2_ebusd_3.4_22589
NR 32159
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2019-12-30 11:47:44 FlowTemp_sensor_value ok
2019-12-30 11:47:44 FlowTemp_temp_value 57.06
2019-12-30 11:47:44 OutsideTemp_sensor_value ok
2019-12-30 11:47:44 OutsideTemp_temp_value -1.88
2019-12-30 11:47:44 StateEM_0_name
2019-12-30 11:47:44 StateEM_0_value off
2019-12-30 11:42:39 subscriptions ebusd/#
Attributes:
IODev MQTT2_FHEM_Server
readingList ebusd_3.4_22589:ebusd/uiz/OutsideTemp:.* { json2nameValue($EVENT, 'OutsideTemp_', $JSONMAP) }
ebusd_3.4_22589:ebusd/uiz/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd_3.4_22589:ebusd/uiz/StateEM:.* { json2nameValue($EVENT, 'StateEM_', $JSONMAP) }
room 9.6.1_MQTT
Wie kann ich das abstellen?
Grüße Jürgen
hallo ihr profis!
vielen dank für das alles hier.
mittlerweile habe selbst ich dank der vielen hilfestellungen hier mein system recht gut am laufen
obwohl ich noch immer herzlich wenig ahnung davon habe.
der aktuelle koppler 2.2 funktioniert perfekt und sehr stabil.
dank der vielen hex werte im forum konnte ich sogar fast alles rund um die dämliche recovair (360) umsetzen.
das letzte was mir an daten fehlt sind die temperatur werte und die luftfeuchte. :D
pi@raspberrypi:~ $ ebusctl hex 08b509030dF40C
02b237
das könnte oder sollte einer dieser werte sein.
und aus dem hex 37b2/256 wird dann ein wert von ca. 55,7.
habe in einem der beiträge gelesen dass er je nach gerät bei vaillant zu einem beliebigen multiplikator.
gibt es dazu irgenwechle infos oder wie geht man da besten vor? :-\
durch 3-4 wäre wohl recht nahe am ergebnis ... ;)
Zitat von: rob uboot am 20 Januar 2020, 02:23:50
und aus dem hex 37b2/256 wird dann ein wert von ca. 55,7.
habe in einem der beiträge gelesen dass er je nach gerät bei vaillant zu einem beliebigen multiplikator.
gibt es dazu irgenwechle infos oder wie geht man da besten vor? :-\
durch 3-4 wäre wohl recht nahe am ergebnis ... ;)
genau beobachten und eine Liste von HEX = abgelesener Wert am Display erstellen. Dann kann man schauen, wie der Faktor ist.
okay danke.
werde ich mal machen und notieren.
wollte nur mal wissen ob sowas überhaupt einen sinn ergeben kann ... :)
alle anderen daten sind ja entweder 1:1 zu übernehmen oder durch 256 zu dividieren.
auf so eine seltsame idee muss man als hersteller mal kommen ... >:(
es war nur der falsche befehl.
es ist kein multipliaktor dabei.
der normale hex wert durch die 256 und dann durch 16. (warum auch immer ... ;))
anhand der daten konnte man alles adaptieren.
https://github.com/john30/ebusd-configuration/pull/102/files#diff-1f915e6d082d47cdd677194426ef4985 (https://github.com/john30/ebusd-configuration/pull/102/files#diff-1f915e6d082d47cdd677194426ef4985)
habe jetzt alle werte für die recovair 360/4
pi@raspberrypi:~ $ ebusctl hex 08b509030d050e
023e01
wenn man mir bitte jemand das so erklärt dass ich es verstehe kann ich ein csv file daraus machen.
john hat mir schon erklärt dass die files jetzt alle online sind und man das dann extra angeben muss wenn man das lokal haben möchte. aber wie erkennt er das file das er zieht?
habe das teil jetzt mal zum austesten ohne koppler in verwendung gehabt.
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 24
max symbol rate: 122
min arbitration micros: 3
max arbitration micros: 72
min symbol latency: 4
max symbol latency: 5
reconnects: 1
masters: 3
messages: 419
conditional: 0
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0223;HW=0203"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
sollte aber nichts ändern wenn ich das richtig verstanden habe da die 2. ebus instanz weiter auf die 08 zugreifen kann. ist es ein problem wenn man das original zusätzlich als backup am laufen hat oder überschreibt mit der 700 von zeit zu zeit was?
Zitat von: rob uboot am 21 Januar 2020, 23:44:53
wenn man mir bitte jemand das so erklärt dass ich es verstehe kann ich ein csv file daraus machen.
nimm doch schon mal das File vom Pull Request als Basis, bringt ja nichts, alles neu zu erfinden.
Zitat von: rob uboot am 21 Januar 2020, 23:44:53
john hat mir schon erklärt dass die files jetzt alle online sind und man das dann extra angeben muss wenn man das lokal haben möchte. aber wie erkennt er das file das er zieht?
habe das teil jetzt mal zum austesten ohne koppler in verwendung gehabt.
bevor das online gehen kann, musst du es eh lokal testen, d.h. ebusd-configuration lokal clonen, zusätzlich das recov noch dazu legen, und dann ebusd auf den 2.1.x/de Ordner konfigurieren (-c PFAD).
Damit testest Du dann und kannst in die recov deine zusätzliche Definition eintragen.
okay verstehe.
sobald er ein file mit dem namen revov finden lädt es mir es auch rein.
jetzt muss ich nur mehr herausfinden wie ich das ganze lokal clone.
dazu reichen meine linux unkenntnisse wohl nicht aus ... :)
hat john im Github beschrieben:
ebusd installieren (https://github.com/john30/ebusd/wiki/1.-Build-and-install)
Konfiguration lokal installieren (https://github.com/john30/ebusd-configuration)
LG
ist es mit der aktuellen version noch möglich 2 ebus instanzen gleichzeitig laufen zu lassen?
das ging doch mal früher oder ... :o
oder muss man in dem fall immer immer die ganze software 2 mal installieren und am laufen haben?
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
SYSV funktioniert bei mir nicht weil er immer nur eine opts nimmt.
mein csv file export mir immer lauter ';' anstatt der ','
gibt es eine elegante variante das anders zu exporterien?
Also, ich habe hier Buster neu aufgelegt, das arbeitet mit systemd und meine config sieht so aus:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
# In order to run multiple ebusd instances, simply define several EBUSD_OPTS
# with a unique suffix for each.
# Recommended is using a number as suffix for all EBUSD_OPTS settings.
# That number can then be used as additional "instance" parameter to the init.d
# script in order to start/stop an individual ebusd instance instead of all
# instances.
# Example (uncomment the EBUSD_OPTS above):
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
#EBUSD_OPTS1="--scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log --mqttport=1883 --mqttjson --mqtthost=192.168.2.22 --mqtttopic=ebusd/%circuit/%name"
#EBUSD_OPTS2="--scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log --mqttport=1883 --mqttjson --mqtthost=192.168.2.22 --mqtttopic=ebusd/%circuit/%name"
EBUSD_OPTS="--pidfile=/var/run/ebusd.pid --configpath=/etc/ebusd --scanconfig --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBP-if00-port0 -p 8888 -l /var/log/ebusd1.log"
EBUSD_OPTS1="--pidfile=/var/run/ebusd2.pid --configpath=/etc/ebusd2 --scanconfig=15 --accesslevel=* --latency=0 -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IEBO-if00-port0 -p 8889 -l /var/log/ebusd2.log"
dann habe ich den EBUSD-Service kopiert
sudo cp /lib/systemd/system/ebusd.service /lib/systemd/system/ebusd2.service
dann den neuen Service editiert und dort dann auf EBUSD_OPTS1 verwiesen
sudo nano /lib/systemd/system/ebusd2.service
dann die Dienste aktualisieren:
systemctl daemon-reload
einmal rebootet,
dann testen mit:
1. Instanz:
ebusctl
2. Instanz (so wie ich den konfiguriert habe
ebusctl -p 8889
ohne Gewähr (soweit ich das noch nachstellen konnte)
Grüße
Christian
danke dir! :)
genauso sollte es aussehen. ;D
pi@raspberrypi:/ $ ebusctl -p 8888 info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available, vaillant/15.700.csv: different version available, vaillant/hcmode.inc: different version available
access: *
signal: acquired
symbol rate: 24
max symbol rate: 129
min arbitration micros: 8
max arbitration micros: 31
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 5
messages: 470
conditional: 0
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=HMU01;SW=0300;HW=8802", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0419;HW=4603", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZIO;SW=0107;HW=0103"
address e8: slave, scanned "MF=Vaillant;ID=FMU00;SW=0202;HW=6502"
pi@raspberrypi:/ $ ebusctl -p 8889 info
version: ebusd 3.4.v3.3-51-g57eae05
access: *
signal: acquired
symbol rate: 14
max symbol rate: 58
min arbitration micros: 794
max arbitration micros: 879
min symbol latency: 5
max symbol latency: 15
reconnects: 0
masters: 4
messages: 52
conditional: 0
poll: 0
update: 8
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=recoV;SW=0223;HW=0203", loaded "vaillant/08.recov.csv"
address 10: master #2
address 31: master #8, ebusd
address 33: master #13
address 36: slave #8, ebusd
address 38: slave #13, scanned "MF=Vaillant;ID=V32;SW=0117;HW=9802"
Hallo zusammen,
kann ich eine auromatic und eine VWL 61/3 an den gleichen eBus hängen, oder brauche ich 2 Koppler?
Falls ja, einfach von der auromatic auf die VWL und von dort aus weiter zum Koppler?
Danke!
das kommt darauf an welche adresse die geräte verwenden.
denke aber mal das einer reichen sollte wenn du sonst auch keinen koppler in verwendung hast.
wenn die 2 geräte jetzt auch zusammenhängen ist das sicher kein problem.
den bus kann man abzweigen wo immer man möchte.
anbei die 08.recov.csv
# type (r[1-9];w;u)",circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recov,recoVair 260/4 360/4,,,,,,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
*r,,,,,,B513,,,,IGN:2,,,
*w,,,,,,B509,,,,,,,
r,recov,IntensTag,Lueftungsintensitaet Tag auslesen,,,,048a03,HEX:15,,UIN,,,Werte 1-6
r,recov,IntensNacht,Lueftungsintensitaet Nacht auslesen,,,,048b03,HEX:15,,UIN,,,Werte 1-6
r,recov,WaermeRueck,Waermerueckgewinnung auslesen,,,,048c03,HEX:15,,UIN,0=auto;1=on;2=off,,Werte auto/on/off
w,recov,IntensTag,Lueftungsintensitaet Tag setzen,,,,0e8a03,,,UCH,,,Werte 1-6
w,recov,IntensNacht,Lueftungsintensitaet Nacht setzen,,,,0e8b03,,,UCH,,,Werte 1-6
w,recov,HeatRecovery,Waermerueckgewinnung,,,,0e8c03,,,UCH,,,Werte 0=auto;1=on;2=off
w,recov,SetTag,Lueftung Tag setzen,,,B522,000200FFFF,,,,,,
w,recov,SetNacht,Lueftung Nacht setzen,,,B522,000100FFFF,,,,,,
w,recov,SetIntensiv,Stosslueften aktivieren,,,B522,000300FFFF,,,,,,
w,recov,SetIntensivAb,Stosslueften deaktivieren,,,B522,000000FFFF,,,,,,Setzt den Wert zurück (Tag/Nacht oder auto?)
w,recov,SetWunschTemp,Wunschtemperatur,,,,0e140e,,,temp,,,Wert ändert sich erst nach restart von EBUSD?
# ##### Read #####,,,,,,,,,,,,,
*r,,,,,,B509,,,,IGN:2,,,
r,recov,BypassPosition,Position der Bypass-Klappe,,,,290b0e,,,UIN,10,%,
r,recov,Frostschutz,Frostschutz,,,,29f10c,,,onoff,,,
r,recov,WunschTemp,Wunschtemperatur,,,,29140e,,,temp,,°C,
r,recov,Filterwechsel,Filterwechsel in Tagen,,,,29360e,,,UIN,,Tage,
r,recov,Volumstrom,Drehzahl Volumstrom,,,,29FC0D,,,UIN,,m3/h,
r,recov,Zuluft,Drehzahl,,,,29010E,,,UIN,,rpm,
r,recov,Abluft,Drehzahl,,,,29020E,,,UIN,,rpm,
r,recov,TempZuluft,Temperatur Zuluft,,,,29b30d,,,temp,,°C,
r,recov,TempAbluft,Temperatur Abluft,,,,29b40d,,,temp,,°C,
r,recov,TempAussenluft,Temperatur Aussenluft,,,,290c0e,,,temp,,°C,
r,recov,TempFortluft,Temperatur Fortluft,,,,290d0e,,,temp,,°C,
r,recov,FeutigkeitAbluft,Feuchtigkeit Abluft,,,,298503,,,percent,,%,
r,recov,ErtragHeute,Ertrag Heute,,,,29560E,,,UIN,,kw/h,
r,recov,ErtragVortag,Ertrag Vortag,,,,29570E,,,UIN,,kw/h,
r,recov,ErtragMonat,Ertrag Monat,,,,29580E,,,UIN,,kw/h,
r,recov,ErtragJahr,Ertrag Jahr,,,,29590E,,,UIN,,kw/h,
r,recov,ErtragGesamt,Ertrag Gesamt,,,,295A0E,,,UIN,,kw/h,
sollte soweit alles klappen.
bin mir noch nicht sicher wie ich das laufen lasse werden.
wird aber wohl mehr sinn machen den 2. ebusd nicht zusätzlich am vailllant regler anzuschließen.
stufe nacht und tag übernimmt er mir andere befehle wie intensivlüften überschreibt der regler wieder.
das müsste man dann wenn man den regler auch verwenden will über einen mode regeln. (zb.: hwcSFMode)
Zitat von: rob uboot am 16 Februar 2020, 19:57:05
das kommt darauf an welche adresse die geräte verwenden.
denke aber mal das einer reichen sollte wenn du sonst auch keinen koppler in verwendung hast.
wenn die 2 geräte jetzt auch zusammenhängen ist das sicher kein problem.
den bus kann man abzweigen wo immer man möchte.
Naja doch, 1 Koppler habe ich aktuell. Die beiden Geräte kennen sich aktuell nicht.
Ich habe bisher nichts gefunden, wie ich die unterschiedlichen Geräteadressen einstellen kann?
Zitat von: Peter1984 am 16 Februar 2020, 20:27:39
Naja doch, 1 Koppler habe ich aktuell. Die beiden Geräte kennen sich aktuell nicht.
Ich habe bisher nichts gefunden, wie ich die unterschiedlichen Geräteadressen einstellen kann?
einfacher und auch günstiger wird es sein, 2 ebus interfaces zu nutzen, denn sonst bräuchtest du einen VR32 und wärst damit aber eingeschränkt in den Möglichkeiten (und ich weiß auch gar nicht, ob das überhaupt was bringen würde).
Den Bus einfach direkt zu verbinden wird m.E. aber generell nicht klappen, da die Adressen üblicherweise nicht einstellbar sind.
Ok, danke! Dann werde ich mal versuchen, irgendwie günstig an einen 2. Koppler zu kommen.
wie habt ihr den befehl setmode bzw. setmodeoverride in der praxis gelöst?
ganz ohne regler kann man das sicher auch realisieren aber das wird man wohl eher vermeiden wollen.
wenn man jetzt zb jede sekunde den setmode neu setzt und damit den regler permanent überschreibt sollte man
das system damit eigentlich regeln können. ist aber wohl nicht so elegant gelöst ... :)
@rob uboot
Ich quäle mich auch mit dem Problem rum und habe eine teilweise einen Ansatz gefunden.
Was habe ich getan...
In meiner Konfiguration vom EBus greife ich auf die lokalen Konfig Dateien zu.
Da ich für meine EcoTec Plus kein Wandthermostat habe, muss ich den Wert FlowTempDesired setzen.
Um das zu realisieren, habe ich in meiner Konfigurations Datei(bai.308523.inc), folgenden Eintag hinzugefügt.
Das Vorgehen dazu stammt nicht von mir, sondern habe ich auf der GitHub Plattform gelesen.
wi,BAI,SetModeOverride,Betriebsart,,08,B510,00,hcmode,,UCH,,,,flowtempdesired,,D1C,,,,hwctempdesired,,D1C,,,,hwcflowtempdesired,,UCH,,,,,,IGN:1,,,,disablehc,,BI0,,,,disablehwctapping,,BI1,,,,disablehwcload,,BI2,,,,,,IGN:1,,,,remoteControlHcPump,,BI0,,,,releaseBackup,,BI1,,,,releaseCooling,,BI2
Über die Konsole ist man dann in der Lage, mit folgendem Befehl, die gewünschte Vorlauftemperatur zu schreiben.
ebusctl -s localhost w -c bai SetModeOverride '0;34;-;-;0;0;0;0;0;0'
Was in meinem Fall funktioniert ist, dass die neue gewünschte Temperatur an die Heizung übermittelt wird.
Was in meinem Fall nicht fünktioniert ist, dass die Heizung überhaupt wieder den Brenner startet.
Wenn ich den Befehl richtige verstehe, ist der erste Wert der Betriebsmodus(im Beispiel 0), der zweite die gewünschte Vorlauftemp. und der dritte, die Temp. des Warmwasserspeichers.
Die anderen Befehle sagen mir gar nichts.
Im Moment Versuche ich gerade die Heizung dadurch ans Laufen zu bekommen, indem ich die Werte von dem Betriebsmodus ändere.
Leider ist mir das, bis jetzt nicht gelungen. Nach dem setzten des Befehls, warte ich immer dass der heizungsinterne Controller, meine gesetzte Voralauftemp. überschreibt und das der Brenner startet.
Vielleicht kann mir ja jemand einen Tip geben, was anstatt der Null dort einzutragen ist.
ja so richtige tipps bekommt man hier warum auch immer nimmer. :))
dieser setmodeoverride klappt super wenn man das ganze ohne regler verwendet.
mit regler ergibt das jedoch leider keinen sinn weil er das immer wieder überschreibt und damit das system nie ins laufen kommt,
ganz egal wie oft du den befehl setzt. (intervall)
genauso ist es.
der erste wert ist der modus.
hcmode.inc bzw. _templates.csv haben in meinen fall nicht zu 100% die richtigen werte.
ich gehe mal davon aus dass das alles nicht zu 100% klappen kann da jeder eine andere anlage hat und das system daher zu adapterien ist/wäre.
hc modus 3 ist zb warmwasser und nicht 2.
pumpstatus gibt es zb. folgende werte 0,1,4,8,9,128
muss sich wohl jeder überlegen was er machen möchte und wie er das umsetzen möchte.
für das heizen ist bei mir der erste wert nach dem modus die vorlauf temperatur
und bei dem warmwasser der 3 wert mal 2 (warum auch immer?!? - also angenommen du hast 70 grad eingstellt steht dann bei mir 140)
und das stimmt dann auch nicht zwingend weil mein teil nur 65 grad schafft auch wenn man bis zu 80 grad einstellen kann.
der 2. wert nach dem modus verändert sich in meinen fall nie. (viele dinge rechnet sich die anlage auf basis der angaben selber aus)
die hinteren werte müssen auch stimmen. sonst klappt das nicht. das wäre dann zb. heizen ohne umwälzpumpe an. :)
kann dir meine werte alle noch senden falls du es genau brauchst.
generell reicht es aber wenn du alles austestest was du haben willst und dir dann im log file ansiehst was die anlage für setmode befehl gesetzt hat.
es ist generell ein wenig eine themenverfehlung weil man alle diese befehle nicht über den regler setzen sollte sondern gleich direkt an die eigentliche heizung senden sollte.
diese wiederrum setzt aber einen regler vorraus. :)
mit ein paar temperaturfühlern einem druckwächter und ein paar relais kann die anlage komplett ohne dem zeug betreiben.
fragt sich nur wozu man das brauchen sollte. :)))
ich möchte meine anlage als hybrid anlage nutzen und daher wäre es nett wenn man ins system eingreifen könnte
was ich mittlerweile auch komplett ohne regler könnte, den regler selber würde ich jedoch gerne als backup lösung weiter verwenden.
ich kann aktuell die heizung und die kühlung direkt an den hmu mit der vorlauf temperatur senden ohne dass der setmode überhaupt benutzt wird.
es gibt also noch eine instanz über dem dem setmode und sicher noch zumindest 2 darunter...
das einzige was er mir noch nicht macht ist die speicherladung ohne den befehl über den regler zu senden, aber das kann das system vielleicht auch garnicht.
zumindest sieht es die software im hmu nicht vor.
in deinem fall stimmt die setmode kombi sicher nicht.
wenn da ein wert falsch ist klappt es nicht.
sollte die anlage nicht mehr zu 100% machen was sie sollte hilt ein vom strom nehmen.
@rob uboot
Wir diskutieren das ganze Thema im Moment auch auf der GitHub Seite von John30.
Ich hätte dir ja gerne genauere Infos gegeben aber das ist das, was ich im Moment selber durch lesen herausgefunden habe.
In meinem Fall handelt es sich um eine Vaillant ecoTec plus 206/5-5, die ich ohne externen VC Kontroller betreibe.
Deswegen bin ich auch nicht in der Lage, den Datenverkehr zu belauschen.
Wenn du von Regler sprichst, welchen meinst du genau?
Es wäre nett wenn du mir deine Werte bezogen auf den SetModeOverride zukommen lassen könntest.
Was du schreibst, bezüglich Heizen ohne einschalten der Pumpe ist mir auch schon durch den Kopf gegangen, nur leider weiß ich nicht wirklich an welcher Stelle in dem Aufruf, welcher Wert eingetragen werden soll.
Hallo Jungs,
ich stelle mich beim erstellen einer CSV-Datei für meine recovair275 echt zu dämlich an.
Leider bekomme ich es nicht auf die Latte wie ich die empfangenen Daten in die CSV umsetzen muss.
Hier mal ein paar Infos falls mir da jemand weiter helfen möchte:
ich habe insgesamt 3 ebuse.
1.) Heizung -> läuft auf Port 8888 - CSV-Dateien gefunden - alles ok
2.) Solaranlage -> läuft auf Port 7777 - CSV-Dateien gefunden - alles ok
3.) Lüftungsanlage -> läuft auf Port 6666 - CSV-Dateien gibt es dafür nicht :-(
ich habe jetzt einfach eine leere Datei mit dem Namen 15.vai00.csv erstellt welche dann auch geladen wird.
Hier mal die Info-Ausgabe vom ebusd:
ebusctl -p 6666 info
version: ebusd 3.3.v3.3-10-gfa434e5
update check: version 3.4 available
signal: acquired
symbol rate: 69
max symbol rate: 120
min arbitration micros: 783
max arbitration micros: 980
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 2
messages: 71
conditional: 0
poll: 0
update: 8
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=VAI00;SW=0124;HW=8901", loaded "vaillant/15.vai00.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address c0: slave, scanned "MF=Vaillant;ID=WTW04;SW=0123;HW=9001", loaded "vaillant/c0.wtw.csv"
ein grab resault sieht so aus:
ebusctl -p 6666 grab result
10c0b503020001 / 0affffffffffffffffffff = 102
10c0b503020002 / 0a0b03ffffffffffffffff = 102
10c0b50903290200 / 050200580100 = 207
10c0b50903290900 / 03090000 = 106
10c0b50903290e00 / 030e0000 = 109
10c0b50903290f00 / 030f0000 = 105
10c0b50903294d00 / 044d00d51f = 111
10c0b509040e0a0001 / 00 = 201
10c0b509060e00008f0100 / 00 = 27
10c0b509050e15009001 / 00 = 204
10c0b509060e0000910100 / 00 = 143
ich habe jetzt schon heraus gefunden dass:
Waermerueckgewinnung an 10c0b509040e0a0002 / 00
Waermerueckgewinnung aus 10c0b509040e0a0001 / 00
Lueftung Tag 10c0b509050e15009001 / 00
Lueftung Nacht 10c0b509050e15000a01 / 00
Lueftung HI 10c0b509050e1500dd02 / 00
Lueftung aus 10c0b509050e1500a600 / 00
Wenn ich es richtig verstanden habe ist:
10 = der Sender - master #2
c0 = der Empfänger - slave Vaillant;ID=WTW04 .....
b5 = Standard weil Vaillant
09 = weiß ich nicht so richtig manchmal auch 03 - habe irgendwo was von der Klasse des Kommandos gelesen
04 bzw 05 = die Länge der Nachricht
e0a0002 z.B. = Waermerueckgewinnung an
/ 00 = denke das ist die Bestätigung Empfangen und verstanden -> OK
Ist das richtig so und wo muss ich in der CSV was eintragen damit wie bei der Heizung und Solaranlage die Nachrichten richtig decodiert werden?
Ich habe jetzt schon viel gelesen aber so richtig verstanden habe ich es noch nicht.
Es würde mich freuen wenn es mir jemand so erklären könnte dass sogar ich es verstehe ::)
Hier habe ich mal ein paar Zeilen von @rob uboot geklaut.
Was müsste ich da jetzt reinschreiben für meine Anlage?
# type (r[1-9];w;u)",circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recov,recoVair 260/4 360/4,,,,,,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
*r,,,,,,B513,,,,IGN:2,,,
*w,,,,,,B509,,,,,,,
r,recov,IntensTag,Lueftungsintensitaet Tag auslesen,,,,048a03,HEX:15,,UIN,,,Werte 1-6
Was mir aber auch noch zu denken gibt ist der Beitrag von @rob uboot in dem er schreibt, dass die Einstellungen immer vom Steuermodul überschrieben werden.
Wenn ich das Steuermodul abklemme und es nicht dauern befehle sendet dreht die Lüftung nach einer weile hoch obwohl keine Steuerbefehle kommen :o
Würde mich freuen wenn mir da jemand etwas Licht ins Dunkel bringen könnte. Ich glaube ( hoffe ) so viel fehlt nicht mehr bis ich es begreife ;D
LG
Thomas
Es empfiehlt sich, nicht direkt mit einer CSV-Datei zu arbeiten. Sondern mit einem Spreadsheet (z.B. Libre Office) und dieses dann nach CSV zu exportieren. Zum Thema Beschreibung des Protokolls: Siehe im Ordner contrib/EBUS. Dort habe ich vor 5 Jahren mal ein Paper über das Protokoll abgelegt, wird immer noch mit verteilt.
LG
pah
Guten Morgen Herr Prof. Dr. Henning,
vielen Dank für die schnelle Antwort.
Die CSV-Datei habe ich mit Calc geöffnet und bearbeitet der Übersichtlichkeit halber.
Die Anleitung wie die Nachrichten zu dekodieren sind habe ich z.B. bei Github im Wiki von Ebus hier: https://github.com/john30/ebusd/wiki/4.1.-Message-definition (https://github.com/john30/ebusd/wiki/4.1.-Message-definition)
und aus verschiedenen Beiträgen im Forum, aber irgendwie bekomme ich es immer noch nicht hin. Vielleicht liegt es auch an meinem schlechten englisch :-[
Das Paper dass Sie meinen habe ich leider nicht gefunden. Wie heißt die Datei?
Trotzdem noch mal danke für die Antwort.
LG
Thomas
...findest du unter
/opt/fhem/contrib/EBUS
auf deinem FHEM-Server
Grüße
Christian
ah, super - danke.
Ich habe die ganze Zeit im Ebus-Verzeichniss / Configurations-Verzeichniss gesucht.
Die Anleitung werde ich mal durcharbeiten, vielleicht klappt es dann :)
LG
Thomas
Moin,
kurze Frage.
Gibt der eBus die aktuelle elektrische Leistungsaufnahme der Vaillant WP aus? Gibt es irgendwo eine Liste mit Werten die ausgegeben wird?
VG!
es gibt einen Wert der nennt sich "Partialpower".
Aber dieser Wert ändert sich bei mir nicht und gibt daher mehr oder weniger die maximal eingestellte Leistung des Gerätes aus.
Das Register ist aber in der Diagnose Ebene 1, Installateur Mode (wi) beschreibbar.
r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"0704",,,power,,,Heizungsteillast
aber reine elektrische Leistung habe ich noch nichts gesehen!
lg
Reinhart
Die einzig nennenswerte elektrische Leistung kommt durch die Pumpe zu Stande. Deren Leistung kann man (einmal) messen und das Pumpen-Signal über den Ebus abgreifen.
Eine Messung der elektrischen Gesamtleistung ist in keiner der mir bekannten Thermen vorgesehen - dafür sollte man ein externes Gerät wie etwa einen Shelly-Plug verwenden.
LG
pah
Dann werde ich mir wohl einen Shelly EM für die Messung besorgen. Aktuell interessiert mich die elektrische Leistung, die sonstigen Werte stelle ich mittels des Controlers ein.
Danke und Gruß
Zitat von: Reinhart am 31 Mai 2020, 09:40:08
r;wi,,PartloadHcKW,d.00 Heizungsteillast,,,,"0704",,,power,,,Heizungsteillast
Hi Reinhart,
ich mag mich täuschen, ist das nicht die Leistungsbegrenzung im Teillastbereich ? Also auf z.b. 5KW eingestellt heizt eine "normale" Brennwerttherme dann mit einer Begrenzung von 5KW, damit z.B. in der Übergangszeit die Therme bei 20KW nicht ständig an und aus geht...
Ja genau so macht dann der verstellbare Wert auch Sinn.
Die reine Pumpenleistung kann ja auch über ein Register abgefragt werden, ob das allerdings so exakt stimmt müsste wirklich nachgemessen werden. da aber auch der Ventilator die Drehzahl stufenlos einstellt, wird aber alles eine Schätzung bleiben. Daher wird das einfach besser und genauer sein sich so ein Shelly EM zu besorgen.
LG
Hallo zusammen.
Bin auf dieses Forum gestoßen im Zuge meiner Suche nach meinem Problem bei der Einbindung der Vaillant Komponenten in meine Hausautomatisation mittels EBUSD und Ebuskoppler.
Ich habe ein Plugin auf meinem Rasberry am Laufen, welches eine grafische Oberfläche hat und im Hintergrund das EBUSD ausführt.
Jetzt komme ich aber nicht weiter. Ich bekomme von dem Plugin folgende Auswertung in einer PHP Datei bereitgestellt.
{"bai":{"AccessoriesOne":"no data stored","AccessoriesTwo":"no data stored","ACRoomthermostat":"no data stored","averageIgnitiontime":"no data stored","BlockTimeHcMax":"no data stored","BoilerType":"no data stored","ChangesDSN":"no data stored","CirPump":"no data stored","CounterStartattempts1":"no data stored","CounterStartattempts2":"no data stored","CounterStartAttempts3":"no data stored","CounterStartAttempts4":"no data stored","currenterror":"no data stored","DateTime":"no data stored","dcfState":"no data stored","DCFTimeDate":"no data stored","DCRoomthermostat":"no data stored","DeactivationsIFC":"no data stored","DeactivationsTemplimiter":"no data stored","DeltaFlowReturnMax":"no data stored","DisplayMode":"no data stored","DSN":"no data stored","DSNOffset":"no data stored","DSNStart":"no data stored","EBusHeatcontrol":"no data stored","EbusSourceOn":"no data stored","EbusVoltage":"no data stored","errorhistory":"no data stored","expertlevel_ReturnTemp":"no data stored","ExternalFaultmessage":"no data stored","externalFlowTempDesired":"no data stored","externalHwcSwitch":"no data stored","ExternGasvalve":"no data stored","ExtFlowTempDesiredMin":"no data stored","ExtStorageModulCon":"no data stored","extWP":"no data stored","FanHours":"no data stored","FanMaxSpeedOperation":"no data stored","FanMinSpeedOperation":"no data stored","FanPWMSum":"no data stored","FanPWMTest":"no data stored","FanSpeed":"no data stored","FanSpeedOffsetMax":"no data stored","FanSpeedOffsetMin":"no data stored","FanStarts":"no data stored","Flame":"no data stored","FlameSensingASIC":"no data stored","FloorHeatingContact":"no data stored","FlowsetHcMax":"no data stored","FlowsetHwcMax":"no data stored","FlowSetPotmeter":"no data stored","FlowTemp":"no data stored","FlowTempDesired":"no data stored","FlowTempMax":"no data stored","Fluegasvalve":"no data stored","FluegasvalveOpen":"no data stored","Gasvalve3UC":"no data stored","Gasvalve":"no data stored","GasvalveASICFeedback":"no data stored","GasvalveUC":"no data stored","GasvalveUCFeedback":"no data stored","HcHours":"no data stored","HcPumpMode":"no data stored","HcPumpStarts":"no data stored","HcStarts":"no data stored","HcUnderHundredStarts":"no data stored","HeatingSwitch":"no data stored","HoursTillService":"no data stored","HwcDemand":"no data stored","HwcHours":"no data stored","HwcImpellorSwitch":"no data stored","HwcPostrunTime":"no data stored","HwcSetPotmeter":"no data stored","HwcStarts":"no data stored","HwcSwitch":"no data stored","HwcTemp":"no data stored","HwcTempDesired":"no data stored","HwcTempMax":"no data stored","HwcTypes":"no data stored","HwcUnderHundredStarts":"no data stored","HwcWaterflow":"no data stored","HwcWaterflowMax":"no data stored","Ignitor":"no data stored","InitialisationEEPROM":"no data stored","IonisationVoltageLevel":"no data stored","maintenancedata_HwcTempMax":"no data stored","maxIgnitiontime":"no data stored","minIgnitiontime":"no data stored","ModulationTempDesired":"no data stored","OutdoorstempSensor":"no data stored","OverflowCounter":"no data stored","ParamToken":"no data stored","PartloadHcKW":"no data stored","PartloadHwcKW":"no data stored","PartnumberBox":"no data stored","PositionValveSet":"no data stored","PowerValue":"no data stored","PrAPSCounter":"no data stored","PrAPSSum":"no data stored","PrEnergyCountHc1":"no data stored","PrEnergyCountHc2":"no data stored","PrEnergyCountHc3":"no data stored","PrEnergyCountHwc1":"no data stored","PrEnergyCountHwc2":"no data stored","PrEnergyCountHwc3":"no data stored","PrEnergySumHc1":"no data stored","PrEnergySumHc2":"no data stored","PrEnergySumHc3":"no data stored","PrEnergySumHwc1":"no data stored","PrEnergySumHwc2":"no data stored","PrEnergySumHwc3":"no data stored","ProductionByte":"no data stored","PrVortexFlowSensorValue":"no data stored","PumpHours":"no data stored","PumpHwcFlowNumber":"no data stored","PumpHwcFlowSum":"no data stored","RemainingBoilerblocktime":"no data stored","ReturnRegulation":"no data stored","ReturnTemp":"no data stored","ReturnTempMax":"no data stored","SecondPumpMode":"no data stored","SerialNumber":"no data stored","SetFactoryValues":"no data stored","SHEMaxDeltaHwcFlow":"no data stored","SHEMaxFlowTemp":"no data stored","SolPostHeat":"no data stored","Statenumber":"no data stored","Status01":"57.0;56.0;-;-;-;off","Status02":"no data stored","Status16":"no data stored","Status":"no data stored","Storageloadpump":"no data stored","StorageLoadPumpHours":"no data stored","StorageloadPumpStarts":"no data stored","StorageLoadTimeMax":"no data stored","StoragereleaseClock":"no data stored","StorageTemp":"no data stored","StorageTempDesired":"no data stored","StorageTempMax":"no data stored","TargetFanSpeed":"no data stored","TargetFanSpeedOutput":"no data stored","TempDiffBlock":"no data stored","TempDiffFailure":"no data stored","TempGradientFailure":"no data stored","Templimiter":"no data stored","TemplimiterWithNTC":"no data stored","TempMaxDiffExtTFT":"no data stored","Testbyte":"no data stored","TimerInputHc":"no data stored","ValveMode":"no data stored","ValveStarts":"no data stored","VolatileLockout":"no data stored","VolatileLockoutIFCGV":"no data stored","VortexFlowSensor":"no data stored","WarmstartDemand":"no data stored","WarmstartOffset":"no data stored","WaterHcFlowMax":"no data stored","WaterPressure":"no data stored","WaterpressureBranchControlOff":"no data stored","WaterpressureMeasureCounter":"no data stored","WaterpressureVariantSum":"no data stored","WP":"no data stored","WPPostrunTime":"no data stored","WPSecondStage":"no data stored"},"broadcast":{"id":"no data stored"},"general":{"valuerange":"no data stored"},"memory":{"eeprom":"no data stored","ram":"no data stored"},"scan":{"id":"no data stored"},"scan.06":{"":"Vaillant;PMS02;0209;8402"} ,"scan.08":{"":"Vaillant;BAI00;0703;7401","id": "no data stored"},"scan.0a":{"":"Vaillant;PMW01;0205;8302"} ,"scan.12":{"":"Vaillant;PMW01;0205;8302"},"scan.1 5":{"":"no data stored"},"scan.23":{"":"no data stored"},"scan.25":{"":"no data stored"},"scan.26":{"":"Vaillant;SOLSY;0500;6301"} ,"scan.50":{"":"Vaillant;SOLSY;0500;6301"},"scan.e c":{"":"Vaillant;SOLSY;0500;6301"},"scan.ed":{"":" Vaillant;PMS02;0209;8402"},"scan.fc":{"":"Vaillant ;PMW01;0205;8302"}}
Es wird meiner Meinung nach nur ein "Status01" ausgelesen mit 2 Werten mit denen ich nichts anfangen kann.
Hat da jemand eine Idee, was nicht stimmen kann.
mfg Schorsch
Hallo,
das könnten mehrere Dinge sein. Du könntest dich auf dem Raspi einloggen (im Terminal, per ssh, putty,....) und ein "ebusctl info" absetzen. Dort müsste ziemlich weit unten bei den Devices stehen, ob und welche CSVs geladen wurden. Ein "ebusctl find -d" würde dir alle Werte anzeigen, bei denen auch etwas gefunden wurde. Wenn du die beiden Dinge dann hier postest, kann man ggf. schon mehr sehen.
Grüße
Christian
Hallo.
Anbei die Auswertung:
root@loxberry:~# ebusctl info
version: ebusd 3.4.v3.4-16-g9e152da
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 37
max symbol rate: 158
reconnects: 0
masters: 5
messages: 221
conditional: 3
poll: 0
update: 9
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "v aillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave #2
address 23: slave
address 25: slave
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
root@loxberry:~# ebusctl find -d
bai SetMode = auto;0.0;-;-;1;0;0;0;0;0
bai Status01 = 37.0;41.0;-;-;-;off
broadcast datetime = 20.000;09:39:01;04.06.2020
broadcast outsidetemp = 20.000
broadcast vdatetime = 09:39:01;04.06.2020
scan.06 = Vaillant;PMS02;0209;8402
scan.08 = Vaillant;BAI00;0703;7401
scan.0a = Vaillant;PMW01;0205;8302
scan.12 = Vaillant;PMW01;0205;8302
scan.26 = Vaillant;SOLSY;0500;6301
scan.50 = Vaillant;SOLSY;0500;6301
scan.ec = Vaillant;SOLSY;0500;6301
scan.ed = Vaillant;PMS02;0209;8402
scan.fc = Vaillant;PMW01;0205;8302
mfg schorsch
...das ist in der Tat etwas mager, es scheint, als ob nur die eine CSV für die BAI (das müsste die Therme selber sein, wenn ich mich nicht täusche) geladen wird. Aber es werden noch keine Daten abgefragt. Die gute Nachricht ist damit, dass EBUSD läuft und auch der Broadcast von der Therme wie Datum und Aussentemperatur kommen. Nun müssen noch Werte aufgenommen werden, es werden hier noch keine gepollt (also aktiv an Werten gezogen, denn von sich aus gibt die Therme erstmal gar nichts freiwillig raus). Du kannst das entweder über Abfragen der Marke "ebusctl r -f <und dann was aus der CSV, 3. Spalte>" (z.B. "ebusctl r -f PartloadHcKW") machen, das hat den Nachteil, dass du alle Werte aktiv und einzeln ziehen musst, oder in der CSV, wenn du sie denn lokal hast und auch von dort beim Start von EBUSD ranziehst, bei den Werten, die du gerne gelesen haben möchtest, statt "r" am Anfang ein "r1" draus machst. Dann sollte (wenn ich das noch richtig in Erinnerung habe) EBUSD diese Werte automatisch abfragen, die Ergebnisse siehst du dann unter "ebusctl find -d" und dann müsstest du auch in deinem Skript entsprechende Werte sehen...
Wenn ich ganz groben Blödsinn schreibe, darf mich auch gern jemand korrigieren ;-)
Grüße
Christian
Hallo @thomhug und @john30
Ich habe auch eine "IT 5711" von TEM (Kessel von Ryll, Brenner von Elco) und versuche gerade, die wichtigsten Kenndaten (vor allem Status und Temperaturen) auszulesen (read only reicht mir im Moment).
Hast du @thomashug das mal hingekriegt? Ich habe schon x Kombinationen von CSV-Files probiert, aber hatte irgendwie noch keinen Erfolg. Es kann aber auch sein, dass ich etwas noch nicht richtig verstanden habe...
Liebe Grüsse
Christian
Hallo,
wie ich schon letztens geschrieben habe bin ich, wenn es die Zeit zulässt, dabei meine Recovair 275 verstehen zu wollen ;D
ein paar Dinge habe ich schon heraus gefunden und möchte sie hier mal einstellen und vielleicht hat ja jemand eine gute Idee zu meinem aktuellen Problem.
Ich habe herausgefunden wie die Lüftungsstufe übertragen wird, bekomme aber nicht heraus wie es codiert ist >:(
10c0b509050e1500a600 Lüftung = 50
10c0b509050e1500b700 Lüftung = 55
10c0b509050e1500c800 Lüftung = 60
10c0b509050e1500d800 Lüftung = 65
10c0b509050e1500e900 Lüftung = 70
10c0b509050e1500fa00 Lüftung = 75
10c0b509050e15000a01 Lüftung = 80
10c0b509050e15001b01 Lüftung = 85
10c0b509050e15002c01 Lüftung = 90
10c0b509050e15003c01 Lüftung = 95
10c0b509050e15004d01 Lüftung = 100
10c0b509050e15005e01 Lüftung = 105
10c0b509050e15006e01 Lüftung = 110
10c0b509050e15007f01 Lüftung = 115
10c0b509050e15009001 Lüftung = 120
10c0b509050e1500a001 Lüftung = 125
10c0b509050e1500b101 Lüftung = 130
10c0b509050e1500c201 Lüftung = 135
10c0b509050e1500d201 Lüftung = 140
10c0b509050e1500e301 Lüftung = 145
10c0b509050e1500f401 Lüftung = 150
10c0b509050e15000402 Lüftung = 155
10c0b509050e15001502 Lüftung = 160
10c0b509050e15002602 Lüftung = 165
10c0b509050e15003602 Lüftung = 170
10c0b509050e15004702 Lüftung = 175
10c0b509050e15005802 Lüftung = 180
10c0b509050e15006802 Lüftung = 185
10c0b509050e15007902 Lüftung = 190
10c0b509050e15008a02 Lüftung = 195
10c0b509050e15009a02 Lüftung = 200
10c0b509050e1500ab02 Lüftung = 205
10c0b509050e1500bc02 Lüftung = 210
10c0b509050e1500cc02 Lüftung = 215
10c0b509050e1500dd02 Lüftung = 220
10c0b509050e1500ee02 Lüftung = 225
10c0b509050e1500fe02 Lüftung = 230
10c0b509050e15000f03 Lüftung = 235
10c0b509050e15002003 Lüftung = 240
10c0b509050e15003003 Lüftung = 245
10c0b509050e15004103 Lüftung = 250
10c0b509050e15005203 Lüftung = 255
10c0b509050e15006203 Lüftung = 260
10c0b509050e15007303 Lüftung = 265
10c0b509050e15008403 Lüftung = 270
10c0b509050e15009403 Lüftung = 275
10c0b509050e1500a503 Lüftung = 280
10c0b509050e1500b603 Lüftung = 285
10c0b509050e1500c603 Lüftung = 290
10c0b509050e1500d703 Lüftung = 295
10c0b509050e1500e803 Lüftung = 300
e1500 scheinet ja für die Lüftungsstufe zu stehen und die 4 Werte danach ergebn die Stufe - aber wie?
Wenn ich die ersten 2 Werte nehme ist immer ein Sprung von 16 oder 17 auf den nächst höheren bis bei den letzten 2 Werten um 1 aufsummiert wird.
Jemand eine Idee?
Hier noch ein paar Werte die ich heraus gefunden habe:
# type (r[1-9] w u ),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recov,RecoVair 275,,,,,,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
*r,,,,,,B509,,,,,,,
*w,,,,,,B509,,,,,,,
w,wtw04,Waermerueckgewinnung,Waermerueckgewinnung,,,,0e0a00,,,UCH,1=an;2=aus,,
#w,wtw04,Waermerueckgewinnung aus,Waermerueckgewinnung ausschalten,,,,0e0a0002,,,,,,
#w,wtw04,Waermerueckgewinnung an,Waermerueckgewinnung anschalten,,,,0e0a0001,,,,,,
w,wtw04,Lueftungsmodus Tag,Lueftungsstufe Tag,,,,0e1500a001,,,,,,
w,wtw04,Lueftungsmodus Nacht,Lueftungsstufe Nacht,,,,0e15000a01,,,,,,
w,wtw04,Lueftungsmodus HI,Lueftungsstufe HI,,,,0e1500dd02,,,,,,
w,wtw04,Lueftungsmodus Aus,Lueftungsstufe Aus,,,,0e1500a600,,,,,,
w,wtw04,Roomtemp,Temperatur Zimmer,,,,0e0000,,,temp,,,
#######Weitere #####,,,,,,,,,,,,,
*r,,,,,,B509,,,,IGN:2,,,
*w,,,,,,B509,,,,,,,
r,wtw04,TempOutsideAir SAO,Temperatur Aussenluft,,,,290200,,,temp,,,
r,wtw04,TempOutgoingAir EAO,Temperatur Fortluft,,,,290400,,,temp,,,
r,wtw04,TempWasteAir EAI,Temperatur Abluft,,,,290300,,,temp,,,
r,wtw04,TempInletAir SAI,Temperatur Zuluft,,,,290100,,,temp,,,
Die Werte für Tag, Nacht, HI sind halt jetzt "fest verdrahtet"
Die .csv's sind von mir zum Testen erstellt ;)
ebusctl info
version: ebusd 3.4.v3.4-18-g5e97d08
signal: acquired
symbol rate: 79
max symbol rate: 91
min arbitration micros: 1562
max arbitration micros: 3064
min symbol latency: 5
max symbol latency: 6
reconnects: 0
masters: 2
messages: 29
conditional: 0
poll: 0
update: 4
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=VAI00;SW=0124;HW=8901", loaded "vaillant/15.vai00.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address c0: slave, scanned "MF=Vaillant;ID=WTW04;SW=0123;HW=9001", loaded "vaillant/c0.wtw04.csv"
Gruß
Thomas
Liebe Leute,
ich brauche jetzt auch einmal Eure Expertise. Angefixt durch ein posting eines anderen users in de.rec.heimwerken habe ich mich an ein vor Jahren eingemottetes Projekt gemacht, meine Heizungsanlage mit fhem zu verbinden. Den Buskoppler hatte ich schon cor ein paar Jahren erstanden (Fertiggerät, Ebus-LAN), jetzt endlich angeschlossen und in Betrieb genommen. Heizungsseitig werkelt eine Vaillant Calormatic 630 und ein Vaillant icoVIT Öl-Brennwertkessel, beides 2012 eingebaut.
Was schon funktioniert:
ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 24
max symbol rate: 179
min arbitration micros: 13
max arbitration micros: 4447
min symbol latency: 0
max symbol latency: 14
reconnects: 0
masters: 3
messages: 406
conditional: 3
poll: 1
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/bai.308523.inc" ([HW=7401]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0501;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
address 25: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
address 26: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
address 51: slave, scanned "MF=Vaillant;ID=VR630;SW=0500;HW=6301"
ebusctl find -d
bai SetMode = auto;15.0;-;-;0;0;0;0;0;0
bai Status01 = 52.0;29.0;-;0.0;-;off
broadcast datetime = 16.812;08:02:04;22.06.2020
broadcast outsidetemp = 16.812
broadcast vdatetime = 08:02:04;22.06.2020
scan.08 = Vaillant;BAI00;0703;7401
scan.15 = Vaillant;UI ;0501;6201
scan.15 id = 21;11;36;0020080467;0907;005943;N3
scan.23 = Vaillant;VR630;0500;6301
scan.25 = Vaillant;VR630;0500;6301
scan.26 = Vaillant;VR630;0500;6301
scan.50 = Vaillant;VR630;0500;6301
scan.51 = Vaillant;VR630;0500;6301
ui YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0
Der Buskoppler ist abgeglichen, ebusctl raw bytes liefert ganz viele <aa wie es wohl auch sein soll.
Was leider nicht funktioniert ist das laden der passenden csv-Dateien von (wenn ichs richtig verstanden habe) ebusd.eu. Die 15.ui.csv passt und wird relativ schnell nach start des ebusd-services geladen. Die bai.308523.inc passt nicht, gehört zu einem ecoTec und wird wohl als fallback-Datei irgendwann geladen, wenn nichts besser passendes gefunden wird (?).
Es gibt allerdings mindestens drei csv's für icoVIT-Geräte für die ebusd-Version 2.2, deren Konfigurationsfiles ich mir heruntergeladen habe, ich gehe davon aus, dass diese auch für Version 3.4 zur Verfügung stehen müssten(?)..
Für die Adressen 23, 25, 26, 50 und 51 gibt es ebenfalls zur calormatic 630 passende csv-Dateien, das weiß ich aus besagtem usenet-posting, da ist der gleiche Regler verbaut und die entsprechenden Dateien für die fünf Heizkreise werden geladen und können abgefragt werden.
Wenn ich die log-Datei richtig interpretiere (zip im Anhang) lädt ebusd die Dateien nicht, weil er von den Devices keine Antwort bekommt. Beispielsweise letzter Eintrag diesbezüglich:
2020-06-22 08:44:03.417 [main error] scan config 50: ERR: ACK error
Frage also: Liege ich mit meiner Annahme richtig, dass das Problem hier seine Ursache hat? Was tue ich dagegen?
Probiert habe ich schon, den Ebuskoppler auf der anderen Seite der festen Ebus-Verdrahtung anzuklemmen (also statt auf die Klemmen im Regler auf die des Kessels zu legen), keine Änderung. Ein anderes Buskabel zwischen Koppler und Vaillant Gerätschaften hat ebenfalls nichts gebracht.
Ich wollte dann von TCP- auf UDP-Betrieb umschalten weil der Hersteller des Buskopplers diese Betriebsart wegen der geringeren Latenzzeiten empfiehlt, aber nach Umschalten des Buskopplers auf UDP-Betrieb (geht per Windows-Konfigurationsprogramm) erhalte ich bei Aufruf von
ebusd -f -c /tmp --logareas bus --loglevel debug --device=udp:192.168.1.47:5010
nur ein "no signal", egal welchen Port ich probiere.
Und jetzt seid Ihr gefragt: Was kann ich noch probieren, vorzugsweise die ACK ERRORs wegzubekommen, oder hilfsweise das Laden der passenden csv's zu erzwingen? Die Methode für Version 2.2, kopieren der Dateien nach /etc/ebusd und setzen der configpath-option endete bei mir in Fehlermeldungen ohne Ende, wahrscheinlich weil die 2.2er csv's nicht zur Version 3.4 passen?
Bonusfrage: Die Abfrage YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0 alle paar 10tel Sekunden ist bei meiner Anlage sinnlos, es ist keine Solaranlage, Brennstoffzelle oder BHKW angeschlossen, welches einen "Ertrag" melden könnte. Schon gar nicht ändert sich der nicht vorhandene Ertrag 10tel-sekundenweise. Bekomme ich das irgendwie weg, oder liegt das auch an ACK ERROR?
Danke Euch fürs Lesen dieses doch länglich geratenen Beitrags und für Eure Ideen!
du kannst ja einmal versuchen in der config den Parameter "--latency=20000" zu testen. Die Fehlermeldung bei Adresse 50 sollte nicht sein!
Nach setzen des Parameters bitte den Dämon neu starten!
LG
habe gerade im Log gesehen, du hast den ACK Error ja grundsätzlich bei allen VR630 Adressen!
LG
Erstmal danke für Deine Antwort, Reinhart!
Ja, der ACK Error kommt bei allen VR630-Adressen regelmäßig, und das sind dann auch die, zu denen keine csv geladen wird.
Dass das nicht gut ist und nicht so sein sollte ist auch klar, aber man findet im Netz leider nur sehr spärliche Informationen über Ursache und Wirkung dieser Fehlermeldung. Der einzige Leidensgenosse, dem aber auch nicht abschliessend geholfen wurde, hat dann zusätzlich noch einen Timeout-Reading-Fehler hinterher, der kommt bei mir nicht.
Deswegen meine Hoffnung, dass hier jemand noch einen Tipp hat.
Deine Idee mit latency=20000 habe ich über Nacht laufen lassen, ohne dass sich etwas verbessert (oder verschlechtert) hätte.
Ich hatte versäumt, die ebusd-Einstellungen, mit denen die Logdatei erstellt wurde, mitzuliefern. Das sei hiermit nachgeholt:
Ausschnitt aus /etc/default/ebusd:
EBUSD_OPTS="--device=192.168.1.47:5007 --latency=10000 --scanconfig=full --enablehex"
Alle anderen Zeilen sind mit # auskommentiert. Wie gesagt, Änderung auf latency =20000 hat nix gebracht, ich teste jetzt nochmal mit 40000, aber habe wenig Hoffnung.
Was irgendwie auch merkwürdig ist: das ui-Device, das ja problemlos ohne Fehlermeldung gefunden und geladen wird, befindet sich ja physisch wohl im gleichen Gehäuse wie die VR630-devices, die mit Ack-Error Probleme machen.
Ich habe auch Zugriff auf die Vaillant-Software (VRDialog) und den zugehörigen Original-Vaillant-Buskoppler. Die VRDialog-Software hat keine Probleme die devices zu finden, Werte auszulesen und Parameter zu setzen. Heizungshardwareseitig sollte also alles ok sein.
Hoi,
hab mal ein kleines Problem.
Ich lese grade alle Register meiner RecoVair 260/4 aus, um sie zuzuordnen.
Dabei habe ich ein seltsames Problem.
ich habe in der bai00.cfg folgendes definiert
# Test 10
get Test10 cmd {"r -f temp10 \n"}
get Test10 expect "\d+\.\d+\;\w+\n\n"
get Test10 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 11
get Test11 cmd {"r -f temp11 \n"}
get Test11 expect "\d+\.\d+\;\w+\n\n"
get Test11 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 12
get Test12 cmd {"r -f temp12 \n"}
get Test12 expect "\d+\.\d+\;\w+\n\n"
get Test12 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 13
get Test13 cmd {"r -f temp13 \n"}
get Test13 expect "\d+\.\d+\;\w+\n\n"
get Test13 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 14
get Test14 cmd {"r -f temp14 \n"}
get Test14 expect "\d+\.\d+\;\w+\n\n"
get Test14 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 15
get Test15 cmd {"r -f temp15 \n"}
get Test15 expect "\d+\.\d+\;\w+\n\n"
get Test15 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 16
get Test16 cmd {"r -f temp16 \n"}
get Test16 expect "\d+\.\d+\;\w+\n\n"
get Test16 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 17
get Test17 cmd {"r -f temp17 \n"}
get Test17 expect "\d+\.\d+\;\w+\n\n"
get Test17 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 18
get Test18 cmd {"r -f temp18 \n"}
get Test18 expect "\d+\.\d+\;\w+\n\n"
get Test18 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 19
get Test19 cmd {"r -f temp19 \n"}
get Test19 expect "\d+\.\d+\;\w+\n\n"
get Test19 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 20
get Test20 cmd {"r -f temp20 \n"}
get Test20 expect "\d+\.\d+\;\w+\n\n"
get Test20 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 21
get Test21 cmd {"r -f test21 \n"}
get Test21 expect "\d+\.\d+\;\w+\n\n"
get Test21 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 22
get Test22 cmd {"r -f temp22 \n"}
get Test22 expect "\d+\.\d+\;\w+\n\n"
get Test22 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 23
get Test23 cmd {"r -f temp23 \n"}
get Test23 expect "\d+\.\d+\;\w+\n\n"
get Test23 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 24
get Test24 cmd {"r -f temp24 \n"}
get Test24 expect "\d+\.\d+\;\w+\n\n"
get Test24 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 25
get Test25 cmd {"r -f temp25 \n"}
get Test25 expect "\d+\.\d+\;\w+\n\n"
get Test25 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 26
get Test26 cmd {"r -f temp26 \n"}
get Test26 expect "\d+\.\d+\;\w+\n\n"
get Test26 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 27
get Test27 cmd {"r -f temp27 \n"}
get Test27 expect "\d+\.\d+\;\w+\n\n"
get Test27 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 28
get Test28 cmd {"r -f temp28 \n"}
get Test28 expect "\d+\.\d+\;\w+\n\n"
get Test28 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 29
get Test29 cmd {"r -f temp29 \n"}
get Test29 expect "\d+\.\d+\;\w+\n\n"
get Test29 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 30
get Test30 cmd {"r -f temp30 \n"}
get Test30 expect "\d+\.\d+\;\w+\n\n"
get Test30 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
# Test 31
get Test31 cmd {"r -f temp31 \n"}
get Test31 expect "\d+\.\d+\;\w+\n\n"
get Test31 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
#
Test 10 - 20 geht
pi@raspberrypi:~ $ ebusctl -p 8889 r -f temp10
88
Test 21 - 31 geht nicht
pi@raspberrypi:~ $ ebusctl -p 8889 r -f temp31
ERR: element not found
der hex cdoe für zB. Test31 geht
pi@raspberrypi:~ $ ebusctl -p 8889 hex 08b509030d4e0d
022b04
das ist meine 08.recov.scv
pi@raspberrypi:~ $ cat /etc/ebusd/vaillant/08.recov.csv
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recoV,RecoVair,RecoVair,,,,,,,,,,
*r,,,,,,B509,0D,,,,,,
*w,,,,,,B509,0E,,,,,,
*wi,#install,,,,,B509,0E,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
r;w,,FanLevelDay,Lüfterstufe Tag,,,,8a03,,,UCH,1=1;2=2;3=3;4=4;5=5;6=6,,
r;w,,FanLevelNight,Lüfterstufe Nacht,,,,8b03,,,UCH,1=1;2=2;3=3;4=4;5=5;6=6,,
r;w,,Heatrecovery,Wärmerückgewinnung,,,,8c03,,,UCH,0=auto;1=on;2=off,,Aktuelle Uhrzeit
r;w,,FilterChange,Tage bisFilterwechsel,,,,350e,,,UIN,,Tage,
r;w,,maintenance,Tage bis Wartung,,,,360e,,,UIN,,Tage,
r,,DayKwh,Ertrag Heute kwh /10,,,,560e,,,ULG,10,Kwh,
r,,YesterdayKwh,Ertrag Vortag kwh /10,,,,570e,,,ULG,10,Kwh,
r,,MonthKwh,Ertrag Monat kwh /10,,,,580e,,,ULG,10,Kwh,
r,,YearKwh,Ertrag Jahr kwh,,,,590e,,,ULG,,Kwh,
r,,TotalKwh,Ertrag Gesamt kwh,,,,5a0e,,,ULG,,Kwh,
r;w,,InstallationHight,Installationshöhe in m,,,,1a0e,,,UIN,,m,
r;w,,Disbalance,Dissbalance Abluft %,,,,1b0e,,,SCH,,%,
r;w,,VolumeFlow,Nennvolumenstrom NL,,,,1c0e,,,UIN,,m³/h,
r;w,,RedVolumeFlow,Red.lüftung % zu NL,,,,1d0e,,,UCH,,%,
r;w,,IntensVolumeFlow,Intensivlüftung % zu NL,,,,1e0e,,,UCH,,%,
r;w,,WTTyp,WTTyp,,,,250e,,,UCH,0=Standart;1=Etalphie,,
r;w,,FreezProtect,FrostschutzTyp,,,,260e,,,UCH,0=kein;1=elektrisch;2=hydraulisch,,
r;w,,GroundCollector,Erdkollektor,,,,280e,,,UCH,0=nein;1=ja,,
r;w,,BypassDiffTemp,BypassDiffTemp,,,,2a0e,,,temp,,°C,
r;w,,PressureSwitch,Druckwächter,,,,2b0e,,,UCH,0=nein;1=ja,,
r;w,,StepSwitch,Stufenschalter,,,,2c0e,,,UCH,0=nein;1=ja,,
r;w,,AirQualitySens,Luftqualitätssensor,,,,2d0e,,,UCH,0=keiner;1=1Sensor;2=2Sensoren,,
r;w,,MinCO2,min CO2 Wert,,,,2e0e,,,UIN,,ppm,
r;w,,MaxCO2,max CO2 Wert,,,,2f0e,,,UIN,,ppm,
r;w,,MinHum,min Luftfeuchte %,,,,300e,,,UCH,,,
r;w,,MaxHum,max Luftfeuchte %,,,,310e,,,UCH,,,
r,,VolumeFlowAct,aktueller Volumenstrom,,,,040e,,,UIN,,,
r;w,,ByPass,ByPass Klappe,,,,0a0e,,,UCH,0=on;01=mid;02=off,,
r;w,,FanStage,Luefterstufe,,,,150e,,,UCH,0=low;1=auto;2=mid;3=high,,
r;w,,Desiredtemp,Wunschtemp,,,,140e,,,temp,,°C,
r,,OutsideAirTemp,AussenTemp,,,,0c0e,,,temp,,°C,
r,,ExhaustAirTemp,FortLuft,,,,0d0e,,,temp,,°C,
r,,OutletAirTemp,AbLuft,,,,b40d,,,temp,,°C,
r,,InletAirTemp,ZuLuft,,,,b30d,,,temp,,°C,
r,,HeatElement,Frostschutzelement,,,,f10c,,,UCH,0=off;1=on,,
r,,BypassPos,Bypass Position,,,,0b0e,,,UIN,10,%,
r,,RPM1,Drehzahl,,,,b00d,,,UIN,,rpm,
r,,RPM2,Drehzahl,,,,b10d,,,UIN,,rpm,
r,,temp4,Zu Fort Luft AVG,,,,b50d,,,temp,,°C,
r,,humidity,Feuchtigkeit?,,,,b70d,,,temp,,°C,
r,,temp6,Zu Fort Luft AVG,,,,b20d,,,temp,,°C,
r,,temp7,,,,,8503,,,UIN,,,
r,,temp8,,,,,010e,,,UIN,,,
r,,temp9,,,,,020e,,,UIN,,,
r,,temp10,,,,,030e,,,UIN,,,
r,,temp11,,,,,050e,,,UIN,,,
r,,temp12,,,,,060e,,,UIN,,,
r,,temp13,,,,,070e,,,UIN,,,
r,,temp14,,,,,080e,,,UIN,,,
r,,temp15,,,,,0e0e,,,UIN,,,
r,,temp16,,,,,0f0e,,,UIN,,,
r,,temp17,,,,,170D,,,UIN,,,
r,,temp18,,,,,180d,,,UIN,,,
r,,temp19,,,,,190D,,,UIN,,,
r,,temp20,,,,,1a0d,,,UIN,,,
r,,temp21,,,,,1b0e,,,UCH,,,
r,,temp22,,,,,270d,,,temp,,,
r,,temp23,,,,,370e,,,UIN,,,
r,,temp24,,,,,420e,,,UIN,,,
r,,temp25,,,,,430e,,,UIN,,,
r,,temp26,,,,,490e,,,UIN,,,
r,,temp27,,,,,4a0d,,,temp,,,
r,,temp28,,,,,4a0e,,,UIN,,,
r,,temp29,,,,,4b0e,,,UIN,,,
r,,temp30,,,,,4d0d,,,temp,,,
r,,temp31,,,,,4e0d,,,temp,,,
kann mir das einer erklären?
MfG Maik
Moin,
wenn du ebusd im Vordergrund in einem Fenster laufen lässt und den Befehl temp31 in einem anderen absetzt müsstest du doch sehen ob der richtige hexwert vom ebusdämon zusammen gebaut wird. Passt das?
Gruß
Thomas
Zitat von: hasenhirn am 27 Juni 2020, 09:35:46
Moin,
wenn du ebusd im Vordergrund in einem Fenster laufen lässt und den Befehl temp31 in einem anderen absetzt müsstest du doch sehen ob der richtige hexwert vom ebusdämon zusammen gebaut wird. Passt das?
Gruß
Thomas
Danke,
hast mir geholfen!
Es waren
[main error] error reading scan config file vaillant/08.recov.csv for ID "recov", SW0217, HW0203: ERR: duplicate entry, vaillant/08.recov.csv:48: ERR: duplicate entry, duplicate ID
die Test21 war schon vorhanden, und somit stoppte der Dämon dort ;D
MfG Maik
Aber wo wir grade dabei sind ;)
LOG
[main error] error reading common config file vaillant/scan.csv: ERR: duplicate entry, vaillant/scan.csv:3: ERR: duplicate entry, duplicate ID
scan.csv
# type (r;w;u;1-9),class,name,comment,QQ,ZZ,PBSB,ID,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment,field,part (m;s),type / templates,divider / values,unit,comment
*r,scan,,,,,B509,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
r,scan,id,Scan ID,,,,24;25;26;27,,,IGN,,,,prefix,,STR:2,,,,year,,STR:2,,,,week,,STR:2,,,,product,,STR:10,,,,supplier,,STR:4,,,,counter,,STR:6,,,,suffix,,STR:2,,,
wo ist hier ein dublicate entry?
MfG Maik
Keine Ahnung - aber könnte das nicht ein cut&paste error sein mit "r -f test21 \n". Besser wäre doch temp21, oder?
# Test 21
get Test21 cmd {"r -f test21 \n"}
get Test21 expect "\d+\.\d+\;\w+\n\n"
get Test21 postproc { s/(\d+\.\d+)\n\n/$1/;;$_}
Moin,
ich hatte alle Lüftungsstufen in der CSV-Datei ( wie im Post vorher gezeigt ) untereinander geschrieben und für jeden Wert eine Zeile.
Wenn ich es richtig verstanden habe müsste das aber auch über den Datentyp UCH gehen.
Bei der Wärmerückgewinnung ( Bypassklappe ) funktioniert es einwandfrei da habe ich:
# type (r[1-9] w u ) circuit name [comment] [QQ] ZZ PBSB [ID] field1 part (m/s) datatypes/templates divider/values
w Waermerueckgewinnung Waermerueckgewinnung 0a00 UCH 1=an;2=aus
Bei der Lüfterstufe sind es aber 2 Werte welche die Lüfterstufe angeben z.B. 125m³/h =a001
# type (r[1-9] w u ) circuit name [comment] [QQ] ZZ PBSB [ID] field1 part (m/s) datatypes/templates divider/values
w Lüftung Lüftung 1500 UCH 0xa001=125m³/h
ZitatERR: argument value out of valid range, create field in field 0
Ich habe es auch schon dezimal mit 40961=125m³/h oder 0xa0,0x01=125m³/h oder 0xa0 0x01=125m³/h probiert, hat alles nicht funktioniert :-/
Kennt da jemand die Lösung oder geht es eventuell überhaupt nicht?
Gruß
Thomas
Hallo Jungs,
für alle die es interessiert und die etwas damit anfangen können, hier der aktuelle Status meiner csv-Dateien für die Vailant recovair 275.
Ein paar Sachen für Einstellungen werde ich wohl noch nachpflegen, aber das Einstellen zwichen Tag, Nacht, Auto und HI funktioniert schon mal.
Für Verbesserungen und Anregungen bin ich jederzeit offen. Das Problem mit dem Luftdurchsatzt in m³/h habe ich auch noch nicht hin bekommen.
@john30: falls die Dateien irgendwelchen Standards gerecht werden, kannst Du sie ja bei Github mit dazu werfen. ;)
c0.wtw04.csv:
# type (r[1-9] w u ),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recov,RecoVair 275,,,,,,,,,,,
############ Luftvolumen################,,,,,,,,,,,,,
*r,,,,,,B509,0D,,,,,,
*w,,,,,,B509,0E,,,,,,
w,,Lüftung = 50m³/h,Lüftung = 50m³/h,,,,1500a600,,,,,,
w,,Lüftung = 55m³/h,Lüftung = 55m³/h,,,,1500b700,,,,,,
w,,Lüftung = 60m³/h,Lüftung = 60m³/h,,,,1500c800,,,,,,
w,,Lüftung = 65m³/h,Lüftung = 65m³/h,,,,1500d800,,,,,,
w,,Lüftung = 70m³/h,Lüftung = 70m³/h,,,,1500e900,,,,,,
w,,Lüftung = 75m³/h,Lüftung = 75m³/h,,,,1500fa00,,,,,,
w,,Lüftung = 80m³/h,Lüftung = 80m³/h,,,,15000a01,,,,,,
w,,Lüftung = 85m³/h,Lüftung = 85m³/h,,,,15001b01,,,,,,
w,,Lüftung = 90m³/h,Lüftung = 90m³/h,,,,15002c01,,,,,,
w,,Lüftung = 95m³/h,Lüftung = 95m³/h,,,,15003c01,,,,,,
w,,Lüftung = 100m³/h,Lüftung = 100m³/h,,,,15004d01,,,,,,
w,,Lüftung = 105m³/h,Lüftung = 105m³/h,,,,15005e01,,,,,,
w,,Lüftung = 110m³/h,Lüftung = 110m³/h,,,,15006e01,,,,,,
w,,Lüftung = 115m³/h,Lüftung = 115m³/h,,,,15007f01,,,,,,
w,,Lüftung = 120m³/h,Lüftung = 120m³/h,,,,15009001,,,,,,
w,,Lüftung = 125m³/h,Lüftung = 125m³/h,,,,1500a001,,,,,,
w,,Lüftung = 130m³/h,Lüftung = 130m³/h,,,,1500b101,,,,,,
w,,Lüftung = 135m³/h,Lüftung = 135m³/h,,,,1500c201,,,,,,
w,,Lüftung = 140m³/h,Lüftung = 140m³/h,,,,1500d201,,,,,,
w,,Lüftung = 145m³/h,Lüftung = 145m³/h,,,,1500e301,,,,,,
w,,Lüftung = 150m³/h,Lüftung = 150m³/h,,,,1500f401,,,,,,
w,,Lüftung = 155m³/h,Lüftung = 155m³/h,,,,15000402,,,,,,
w,,Lüftung = 160m³/h,Lüftung = 160m³/h,,,,15001502,,,,,,
w,,Lüftung = 165m³/h,Lüftung = 165m³/h,,,,15002602,,,,,,
w,,Lüftung = 170m³/h,Lüftung = 170m³/h,,,,15003602,,,,,,
w,,Lüftung = 175m³/h,Lüftung = 175m³/h,,,,15004702,,,,,,
w,,Lüftung = 180m³/h,Lüftung = 180m³/h,,,,15005802,,,,,,
w,,Lüftung = 185m³/h,Lüftung = 185m³/h,,,,15006802,,,,,,
w,,Lüftung = 190m³/h,Lüftung = 190m³/h,,,,15007902,,,,,,
w,,Lüftung = 195m³/h,Lüftung = 195m³/h,,,,15008a02,,,,,,
w,,Lüftung = 200m³/h,Lüftung = 200m³/h,,,,15009a02,,,,,,
w,,Lüftung = 205m³/h,Lüftung = 205m³/h,,,,1500ab02,,,,,,
w,,Lüftung = 210m³/h,Lüftung = 210m³/h,,,,1500bc02,,,,,,
w,,Lüftung = 215m³/h,Lüftung = 215m³/h,,,,1500cc02,,,,,,
w,,Lüftung = 220m³/h,Lüftung = 220m³/h,,,,1500dd02,,,,,,
w,,Lüftung = 225m³/h,Lüftung = 225m³/h,,,,1500ee02,,,,,,
w,,Lüftung = 230m³/h,Lüftung = 230m³/h,,,,1500fe02,,,,,,
w,,Lüftung = 235m³/h,Lüftung = 235m³/h,,,,15000f03,,,,,,
w,,Lüftung = 240m³/h,Lüftung = 240m³/h,,,,15002003,,,,,,
w,,Lüftung = 245m³/h,Lüftung = 245m³/h,,,,15003003,,,,,,
w,,Lüftung = 250m³/h,Lüftung = 250m³/h,,,,15004103,,,,,,
w,,Lüftung = 255m³/h,Lüftung = 255m³/h,,,,15005203,,,,,,
w,,Lüftung = 260m³/h,Lüftung = 260m³/h,,,,15006203,,,,,,
w,,Lüftung = 265m³/h,Lüftung = 265m³/h,,,,15007303,,,,,,
w,,Lüftung = 270m³/h,Lüftung = 270m³/h,,,,15008403,,,,,,
w,,Lüftung = 275m³/h,Lüftung = 275m³/h,,,,15009403,,,,,,
w,,Lüftung = 280m³/h,Lüftung = 280m³/h,,,,1500a503,,,,,,
w,,Lüftung = 285m³/h,Lüftung = 285m³/h,,,,1500b603,,,,,,
w,,Lüftung = 290m³/h,Lüftung = 290m³/h,,,,1500c603,,,,,,
w,,Lüftung = 295m³/h,Lüftung = 295m³/h,,,,1500d703,,,,,,
w,,Lüftung = 300m³/h,Lüftung = 300m³/h,,,,1500e803,,,,,,
#######Weitere #####,,,,,,,,,,,,,
r;w,,Soll-Volumenstromkorrektur,Soll-Volumenstromkorrektur,,,,2000,,,D1B,,,
r;w,,Waermerueckgewinnung,Waermerueckgewinnung,,,,0a00,,,UCH,1=an;2=aus,,
*r,,,,,,B509,29,,,IGN:2,,,
r;w,,TempInletAir_SAI,Temperatur Zuluft,,,,0100,,,temp,,,
r;w,,TempOutsideAir_SAO,Temperatur Aussenluft,,,,0200,,,temp,,,
r;w,,TempWasteAir_EAI,Temperatur Abluft,,,,0300,,,temp,,,
r;w,,TempOutgoingAir_EAO,Temperatur Fortluft,,,,0400,,,temp,,,
r;w,,Roomtemp,Zimmertemperatur,,,,0000,,,temp,,,
r;w,,Unterdruckschutz,Unterdruckschutz,,,,4700,,,UCH,1=an;0=aus,,
r;w,,Ertrag_Gesamt_kWh,Ertrag_Gesamt_kWh,,,,4d00,,,UIN,,,
15.vai00.csv:
# type (r[1-9];w;u),circuit,name,[comment],[QQ],ZZ,PBSB,[ID],field1,part (m/s),datatypes/templates,divider/values,unit,comment
#,recov,RecoVair 275,,,,,,,,,,,
# ##### Generell #####,,,,,,,,,,,,,
*r,,,,,,B509,0D,,,,,,
*w,,,,,,B509,0F,,,,,,
r;w,,Lüftungsstufe,Lüftungsstufe,,,,2400,,,UCH,1=Tag;2=Aus;3=Auto;5=Nacht,,
r;w,,Lüftung_HI,Lüftung_HI,,,,5800,,,BCD:2,,,
r,,Uhrzeit,Uhrzeit,,,,2C00,,,VTI,,,
Gruß
Thomas
Hi Sirs,
Renovating a house, the installed boiler is a Vaillant EcoTec Plus VUW FR 306/5-5 C R3 with product number 0010015183.
After reading several posts, i'm little bit dissapointed because it seems that the majority of FHEM/Ebus coupler community have an external temperature regulator and i thought that the purpose of the Ebus coupler with ebusD daemon is to avoid this external regulator by directly reading and writing the parameters value from/to the boiler.
Do i miss something ???
Beside, i notice that we can read the value of the outdoor temperature sensor. Can we imagine to set the value from the Ebus (i.e. bypass the real outdoor temp sensor) ?
Thanks in advance for your clarification.
--
Lionel
Ich benötige eure Hilfe. Mein RPI Adapter auf dem Raspberry Pi 4 funktioniert nicht mehr. Mir ist nicht klar warum, zumal er über Monate hinweg funktionierte.
LEDs
grün blinkt
gelb leuchtet dauerhaft
ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
access: *
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
/boot/config.txt
#enable_uart=0
dtoverlay=pi3-miniuart-bt
/etc/default/ebusd
EBUSD_OPTS="-d /dev/ttyebus -p 8888 --configpath=http://ebusd.eu/config/ -l /var/log/ebusd.log --scanconfig --accesslevel=* --httpport=8080 --mqttport=1883 --mqttjson --mqtthost=192.168.102.3 --mqtttopic=ebusd/%name"
sudo ebusd -f --scanconfig -d /dev/ttyebus -p 8888
2020-09-15 19:00:43.219 [main notice] ebusd 3.4.v3.3-51-g57eae05 started with auto scan
2020-09-15 19:00:43.378 [bus error] unable to open /dev/ttyebus: ERR: element not found
2020-09-15 19:00:43.378 [bus notice] bus started with own address 31/36
2020-09-15 19:00:43.378 [bus notice] device invalid
2020-09-15 19:00:48.379 [bus error] unable to open /dev/ttyebus: ERR: element not found
2020-09-15 19:00:48.379 [bus notice] device invalid
^C2020-09-15 19:00:49.324 [main notice] SIGINT received
2020-09-15 19:00:53.379 [bus error] unable to open /dev/ttyebus: ERR: element not found
2020-09-15 19:00:53.379 [bus notice] device invalid
2020-09-15 19:00:53.480 [main notice] ebusd stopped
/dev/
ttyebus vorhanden
Was kann die Ursache sein?
Zitat von: hasenhirn am 21 Juli 2020, 18:41:48
Ein paar Sachen für Einstellungen werde ich wohl noch nachpflegen, aber das Einstellen zwichen Tag, Nacht, Auto und HI funktioniert schon mal.
Für Verbesserungen und Anregungen bin ich jederzeit offen. Das Problem mit dem Luftdurchsatzt in m³/h habe ich auch noch nicht hin bekommen.
@john30: falls die Dateien irgendwelchen Standards gerecht werden, kannst Du sie ja bei Github mit dazu werfen. ;)
mach doch einen pull request auf dem github. Aber ich sehe schon, dass dein CSV noch überarbeitet werden muss
Zitat von: Sandmanyz am 15 September 2020, 19:09:39
/dev/
ttyebus vorhanden
Was kann die Ursache sein?
das kann ein eifnaches Rechteproblem sein. Was zeigt denn "ls -la /dev/ttyebus"? Versuche mal "chmod a+rw /dev/ttyebus" als root und dann ebusd neu starten.
Moin Gemeinde,
gestern habe ich einen RPI 3b mit dem ebus-Adapter 2.2 RPI an meine Heizung "Elco Thision-Mini 15.3" gehängt. Inspiriert wurde ich durch diesen Beitraig hier im Forum:
https://forum.fhem.de/index.php/topic,29762.msg830772.html#msg830772
Dort wird auf eine alte Dokumentation verwiesen, in der der Bus-Anschluss auf der Platine noch mit "ebus" gekennzeichnet ist.
Bei dieser Gelegenheit ein herzliches Dankeschön an alle die, die sich die Mühe gemacht haben und die Hard- und Software für den ebus-Anschluss entwickelt haben!
Die aktuelle config:
EBUSD_OPTS="--scanconfig --device=/dev/ttyebus -c /etc/ebusd -l /var/log/ebusd.log"
Die vorhandenen config files liegen hier:
lrwxrwxrwx 1 root root 43 Sep 10 19:21 /etc/ebusd -> /home/pi/ebusd-configuration/ebusd-2.1.x/de
Und das ebusd.log zeigt nach dem Start:
2020-09-28 18:14:58.222 [main notice] ebusd 3.4.v3.3-51-g57eae05 started with auto scan
2020-09-28 18:14:58.231 [bus notice] bus started with own address 31/36
2020-09-28 18:14:58.239 [bus notice] signal acquired
2020-09-28 18:14:58.657 [bus notice] new master 10, master count 2
2020-09-28 18:14:58.699 [bus notice] new master 37, master count 3
2020-09-28 18:14:58.699 [update notice] received unknown MS cmd: 103c200008d1400e117547c404 / 060f04000a0000
2020-09-28 18:14:59.116 [update notice] received unknown BC cmd: 10fe2070070e121c09011411
2020-09-28 18:14:59.246 [bus notice] new master 7f, master count 4
2020-09-28 18:14:59.246 [update notice] received unknown MS cmd: 1084200008d140cc4bc89ccc9a / 050f01080000
2020-09-28 18:14:59.350 [update notice] received unknown MS cmd: 103c200008c54602454013d69c / 060f0000000000
2020-09-28 18:15:00.205 [update notice] received unknown BC cmd: 7ffe202003099000
2020-09-28 18:15:00.331 [update notice] received unknown BC cmd: 7ffe207309000000000000000001
2020-09-28 18:15:00.530 [update notice] received unknown BC cmd: 10fe2038050164050708
2020-09-28 18:15:01.256 [update notice] received unknown BC cmd: 37fe201010c04b0100091901000a1901000b190000
2020-09-28 18:15:01.364 [update notice] received unknown BC cmd: 37fe20100c0c1900000d1900000e190000
2020-09-28 18:15:01.489 [update notice] received unknown BC cmd: 37fe20101001910000029100000391000004910000
2020-09-28 18:15:01.581 [update notice] received unknown BC cmd: 37fe2010080591000006910000
2020-09-28 18:15:02.004 [bus notice] max. symbols per second: 102
2020-09-28 18:15:03.447 [update notice] received unknown BC cmd: 37fe2001026126
2020-09-28 18:15:03.510 [update notice] received unknown BC cmd: 37fe200e086126260290018a02
...
Demnach ist der wohl von Elco aus Marketinggründen "bridgenet bus" technisch offensichtlich ein ebus :).
ebusctl info liefert:
localhost: info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 41
max symbol rate: 190
min arbitration micros: 8
max arbitration micros: 14
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 4
messages: 14
conditional: 0
poll: 0
update: 4
address 10: master #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 37: master #18
address 3c: slave #18
address 7f: master #24
address 84: slave #24
Elco wurde von langer Zeit von Ariston aufgekauft, deshalb steht auf der Platine der Therme auch Ariston drauf.
Wenn ich aber die x20 als primäres Befehlsbyte richtig interpretiere, wurden alle 3 Master von der "RAWE Elektronic GmbH" gefertigt. Die Master 0x10 und 0x37 dürften die Regler sein, der Master 0x7F die Therme bzw. der Feuerungsautomat.
Angeschlosssen an die Therme sind ein Regler "Remocon Plus" und intern verbaut die "Gateway Wifi" Platine. Ich vermute, dass das die beiden "Regler" sind. Die ersten Thision Mini hatten die Remocon Plus noch eingebaut, die 15.3 werden standardmäßig ohne geliefert, dafür aber mit dem "Gateway Wifi". Damit man quasi gezwungen wird, die Therme zu registrieren und die App von Elco zu nutzen. Ohne App und Remocom Plus könnte man nicht mal individuelle Zeitpläne erstellen ... >:(
Da es für die Thision Mini noch keine config gibt, habe ich sowohl "scan" als auch "scan full" ausgeführt. Als "scan result" erhielt ich leider nichts.
Im ebusd.log steht da z. B.
2020-09-28 18:15:10.626 [update error] unable to parse scan-read scan.3c from 313c070400 / 00: ERR: invalid positionDie ebusd,log-Datei von meinen Versuchen habe ich angehängt.
Nun hoffe ich, dass mir ein Kundiger Anworten oder Hinweise zu folgenden Fragen geben kann:
- Kann es durchaus mal kein scan result geben?
- Liegt ein anderer Fehler vor, der im Log zu erkennen ist?
- Kann ich überhaupt eine config erzeugen, wenn der scan nicht funktioniert? Ich bekäme dann ja nie einen Identifikations-String und weder HW- noch SW-Version.
Heute habe ich auch noch diese Eintrag https://forum.fhem.de/index.php/topic,29762.msg1084829.html#msg1084829 gefunden, in dem ein Verweis auf https://github.com/komw/ariston-bus-bridgenet-ebusd steht. Da werde ich jetzt gleich mal weiterlesen ...
Werden weitere Informationen benötigt, bitte melden :).
Viele Grüße
Thomas
Moin,
da steht eine Fehlermeldung:
Sep 29 08:10:33 fhem ebusd[1140]: /usr/bin/ebusd: unrecognized option '--mqttport=1883'
Sep 29 08:10:33 fhem ebusd[1140]: Try `ebusd --help' or `ebusd --usage' for more information.
Sep 29 08:10:33 fhem systemd[1]: ebusd.service: Control process exited, code=exited, status=64/USAGE
Darum startet der daemon nicht. Hast Du einen ebusd mit mqtt support installiert?
Wenn Du hierhin schaust https://github.com/john30/ebusd/releases/tag/v3.4, ist erkennbar, dass die gleiche Version mit und ohne mqtt-Support verfügbar ist. Ich vermute, dass das auch bei 3.2 so war. Falls ja, wäre das eine Erklärung, da die erste mqtt Option in der Liste für den Fehler sorgt.
Guten Morgen,
viel geblättert nichts gefunden. Gibt es jetzt bei Vaillant Kombithermen den Gesamtgasverbrauch zu berechnen?
...an der Therme selber ? Ich habe bei mir den Gaszähler mit einem Reedkontakt abgegriffen und bekomme so den Gasverbrauch.
Ja an der Therme. Der Raumregler zeigt mir die Verbräuche von Gas und Strom an.
Strom konnte ich schon abgreifen. Bei Gas habe ich den Wert nicht gefunden.
Ähm John, kannst du helfen ?
@ Cihan
verwende PrEnergySumHc1, PrEnergySumHwc1 usw mit empirischem Parameter s. hier #2089 funktioniert fast prozentgenau, gesamt bzw WW Verbrauch
Zitat von: thomas.z am 28 September 2020, 19:49:12
...
Da es für die Thision Mini noch keine config gibt, habe ich sowohl "scan" als auch "scan full" ausgeführt. Als "scan result" erhielt ich leider nichts.
...
2020-09-28 18:15:10.626 [update error] unable to parse scan-read scan.3c from 313c070400 / 00: ERR: invalid position
...
- Kann es durchaus mal kein scan result geben?
- Liegt ein anderer Fehler vor, der im Log zu erkennen ist?
- Kann ich überhaupt eine config erzeugen, wenn der scan nicht funktioniert? Ich bekäme dann ja nie einen Identifikations-String und weder HW- noch SW-Version.
Die Antwort "... / 00" ist die Länge der Antwort, also 0. Ergo antwortet das Gerät nicht standard-konform auf die ID Anfrage.
Also Antworten auf Deine Fragen:
- ja
- nein
- ja
Noch Fragen? ;-)
Hallo john30,
danke für Deine Antwort(en) und natürlich ebusd ;).
Nach meinem Beitrag habe ich inzwischen allerlei Zeit investiert und konnte durch Suchen, Lesen, Probieren und etwas Glück ein gutes Stück weiter kommen. Über google habe ich auf "gitter.im" einen chat von Dir mit einem anscheinend polnischen ebus-Forscher (Szymon Gładysz) aus dem letzten Jahr gefunden. Er war so nett, eine config-Datei für seine Ariston Heizung auf GitHub zu veröffentlichen.
Diese habe ich, nachdem ich begriffen hatte, wie man ohne scan config eine Konfiguration erzeugen kann, einfach mal ausprobiert. Und hatte Glück, weil von den enthaltenen Definitionen eine ganze Reihe auf Anhieb funktionierten. :D
Seitdem versuche ich, meine Heizung zu verstehen und so zu steuern, dass sie möglichst wenig taktet und aus ist, wenn sie nicht benötigt wird. Das gelingt schon recht gut. Wenn das dann läuft, werde ich noch ein wenig forschen, um weitere message typen zu identifizieren. Und ich werde die Config natürlich auch bereitstellen, auch wenn sie am Ende wohl eher rudimentär sein wird (verglichen mit dem geballten, verfügbaren Vaillant-Know-How). Bei der Gelegenheit - wäre es möglich und nicht auch am sinnvollsten, dass über Dein git-Repo zu machen?
Viele Grüße
Thomas
Zitat von: thomas.z am 12 Oktober 2020, 21:56:08
Bei der Gelegenheit - wäre es möglich und nicht auch am sinnvollsten, dass über Dein git-Repo zu machen?
ja natürlich via pull request auf ebusd-configuration (https://github.com/john30/ebusd-configuration). Allerdings fehlt mir die Zeit, das alles zu prüfen und im Zweifelsfall ordentlich zu machen. Vielleicht schaffe ich es doch irgendwann, meinen Konfigurationseditor fertig zu machen, mit dem das alles unvergleichlich viel einfacher wäre...
es gibt einen neuen Thread zum eBUS Adapter 3.0! (https://forum.fhem.de/index.php?topic=114988.new#new)
LG
Reinhart
Zitat von: john30 am 12 Oktober 2020, 22:21:24
ja natürlich via pull request auf ebusd-configuration (https://github.com/john30/ebusd-configuration). Allerdings fehlt mir die Zeit, das alles zu prüfen und im Zweifelsfall ordentlich zu machen. Vielleicht schaffe ich es doch irgendwann, meinen Konfigurationseditor fertig zu machen, mit dem das alles unvergleichlich viel einfacher wäre...
Wo Ihr die Zeit hernehmt, ist mir eh ein Rätsel ;). (Siehe auch Adapter 3.0 -Cool!).
Danke für die Antwort! Wenn ich dann noch etwas weitergekommen sein werde, werde ich die Config so gut wie möglich machen (Vorlagen gibt es ja genug) und dann mal einen Pull request versuchen.
Gruß
Thomas
Hi,
nach langer Zeit brauche ich mal wieder eure Hilfe :-\
seit heutigem neustart (PI) will der EBUS nicht mehr richtig.
Er lädt die 15.470.csv nicht mehr
pi@raspberrypi:~ $ ebusctl -p 8890 info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available, broadcast.csv: different version available, vaillant/08.bai.csv: different version available, vaillant/errors.inc: different version available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 41
max symbol rate: 118
min arbitration micros: 1384
max arbitration micros: 4895
min symbol latency: 4
max symbol latency: 19
reconnects: 0
masters: 3
messages: 255
conditional: 3
poll: 0
update: 11
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.308523.inc" ([PROD='0010004276']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0420;HW=1403"
address ff: master #25, ebusd
Datein sind vorhanden
pi@raspberrypi:~ $ ls -l /etc/ebusd/vaillant/
insgesamt 124
-rw-r--r-- 1 pi pi 3887 Okt 16 17:27 08.bai.csv
-rw-r--r-- 1 pi pi 3240 Jun 27 09:58 08.recov.csv
-rw-r--r-- 1 pi pi 2031 Jun 22 16:13 08.recov.csv.bak
-rw-r--r-- 1 pi pi 3295 Jun 27 09:34 08.recov.csv.org
-rw-r--r-- 1 pi pi 17160 Okt 16 17:28 15.470.csv
-rw-r--r-- 1 pi pi 1990 Jun 22 16:13 38.v32.csv
-rw-r--r-- 1 pi pi 17001 Okt 16 17:28 bai.308523.inc
-rw-r--r-- 1 pi pi 620 Jun 22 16:13 broadcast.csv
-rw-r--r-- 1 pi pi 245 Jun 22 16:13 currentservice.inc
-rw-r--r-- 1 pi pi 527 Jun 22 16:13 errors.inc
-rw-r--r-- 1 pi pi 738 Jun 22 16:13 hcmode.inc
-rw-r--r-- 1 pi pi 301 Jun 22 16:13 hwcmode.inc
-rw-r--r-- 1 pi pi 409 Jun 22 16:13 mcmode.inc
-rw-r--r-- 1 pi pi 316 Jun 22 16:13 quick.inc
-rw-r--r-- 1 pi pi 238 Jun 22 16:13 roomtempoffset.inc
-rw-r--r-- 1 pi pi 792 Jun 22 16:13 scan.csv
-rw-r--r-- 1 pi pi 2379 Jun 22 16:13 _templates.csv
-rw-r--r-- 1 pi pi 709 Jun 22 16:13 tempsetpoints.inc
-rw-r--r-- 1 pi pi 647 Jun 22 16:13 timercc.inc
-rw-r--r-- 1 pi pi 677 Jun 22 16:13 timercool.inc
-rw-r--r-- 1 pi pi 633 Jun 22 16:13 timerhc.inc
-rw-r--r-- 1 pi pi 647 Jun 22 16:13 timerhwc.inc
-rw-r--r-- 1 pi pi 979 Jun 22 16:13 timer.inc
woran liegts??
MfG Maik
Zitat von: TiPpFeHlEr am 16 Oktober 2020, 19:30:24
seit heutigem neustart (PI) will der EBUS nicht mehr richtig.
Er lädt die 15.470.csv nicht mehr
woran liegts??
schau halt mal in das ebusd log, da wird schon drin stehen warum ;)
Hallo zusammen, hallo John,
ich möchte gerne die Einmal Speicher Ladung (SingleStorageCharge) der Vaillant Geotherm VWL 81/3 nutzen.
Dazu fand ich im GitHub folgendes:
ebusctl w -c hwc load on
Der Befehl wird mit Done quittiert, nur springt die VWL81/3 nicht an.
Ich habe das mehrmals getest auch bei niedrigen Warmwasser Temperaturen, leider ohne Erfolg.
Hat das jemand am laufen?
Zitat von: Wolpertinger am 27 Oktober 2020, 19:44:07
ich möchte gerne die Einmal Speicher Ladung (SingleStorageCharge) der Vaillant Geotherm VWL 81/3 nutzen.
Dazu fand ich im GitHub folgendes:
ebusctl w -c hwc load on
Der Befehl wird mit Done quittiert, nur springt die VWL81/3 nicht an.
Ich habe das mehrmals getest auch bei niedrigen Warmwasser Temperaturen, leider ohne Erfolg.
probier das mal auf dem Mixer mit
ebusctl w -c mc load on. ich meine, dass das etwas merkwürdig "verdrahtet" ist (habe selbst eine VWS).
Hallo Zusammen,
ich möchte meine Warmwasseraufbereitung über die Anwesenheit steuern. Ich würde das über die Heizspeicher soll Temp machen, aber ich bin mir nicht sicher, ob das zu viele Schreibzugriffe auf den Flashspeicher sind. Oder gibt es noch eine weitere Möglichkeit dies zu realisieren? Meine Heizungsanlage ist eine Vaillant VSC126/3 mit einer Calormatic 470.
VG Andreas
Zitat von: a_quadrat am 30 Oktober 2020, 12:38:47
Hallo Zusammen,
ich möchte meine Warmwasseraufbereitung über die Anwesenheit steuern. Ich würde das über die Heizspeicher soll Temp machen, aber ich bin mir nicht sicher, ob das zu viele Schreibzugriffe auf den Flashspeicher sind. Oder gibt es noch eine weitere Möglichkeit dies zu realisieren? Meine Heizungsanlage ist eine Vaillant VSC126/3 mit einer Calormatic 470.
VG Andreas
Ich hab die Ecotec Exclusiv und die 470er Steuerung, seit Jahren Speicherladung über EBUSd, keine Probleme. Aber wir haben hier festgestellt, dass es unterschiedliche SW-Versionen gibt und nicht alle das unterstützen.
Du musst mal in die 470er CSV und schauen, ob bei HwcOPMode r;w oder nur r vorsteht, das muss r;w sein. Wenn du Ändern musst, dann einmal EbusD neustarten oder reload senden, dann mal probieren, ob mit
ebusctl w -c 470 HwcOPMode 6die Speicherladung gestartet wird, kann ein paar Sekunden dauern, bis das im Display der 470er erscheint... Dann schauen wir weiter ;-)
Grüße Christian
Hallo Christian,
danke für deine Antwort. In der CSV stand nur lesen für diesen Befehl, aber das zufügen von w für schreiben hat auch nichts genutzt. Gibt es noch einen workaround für dieses Problem?
VG Andreas
Hast du EBUSD denn so konfiguriert, dass es die lokalen CSVs läd ? Und hast du EBUSD nach dem Ändern auf r;w und speichern auch neu gestartet ? Dann hast du wahrscheinlich eine 470 mit einer SW, die das nicht unterstützt. Ich weiß nicht, ob John da inzwischen einen Workaround für gefunden hat :-(
Neu gestartet hatte ich ebusd, aber wo kann ich konfigurieren welche CSV geladen werden sollen? Ich dachte die csv's aus dem ebusd Ordner werden automatisch mit geladen.
VG Andreas
Wenn ich das richtig in Erinnerung habe, dann ist default bei aktuellen Versionen, dass die Config aus dem Web von EBUSD.ORG gezogen wird. Ich finde es auf die Schnelle nicht, aber du musst den EBUSD mit --configpath=Da wo deine CSVs auf dem Raspi liegen starten, damit dei lokalen Files geladen werden...
Grüße Christian
nochmal nachgesehen, bei mir liegt die Config für EBUSD hier:
/etc/default/ebusd
also nach /etc/default gehen und dann mit Texteditor die Datei ebusd öffnen. Dort drin dann die OPTs anpassen:
bei mir:
EBUSD_OPTS="--pidfile=/var/run/ebusd.pid --configpath=/etc/ebusd und danach kommt bei mir noch einiges für die Schnittstelle u.s.w.
d.h. meine CSVs für die Instanz liegen bei mir unter /etc/ebusd
Dann werden die lokalen geladen :-)
Grüße
Christian
Danke, der Hinweis mit dem configpath hat zum Erfolg geführt. Speicherladung (6) funktioniert.
Kannst du auch andere Modi setzen, z.B. 7 für holiday? Ich kann die 7 zwar setzen, aber nach der nächsten Abfrage steht der Modus wieder auf 2 (Auto).
VG Andreas
Zitat von: john30 am 28 Oktober 2020, 07:50:40
probier das mal auf dem Mixer mit ebusctl w -c mc load on. ich meine, dass das etwas merkwürdig "verdrahtet" ist (habe selbst eine VWS).
Neee funktioniert komischwerweise auch nicht, hab gewartet bis die Temperatur schon etwas runter war.
Beide werden aber mit Done quittiert.
versuch die Abfrage in der bai00.cfg um eine Stufe zu erweitern und gib den Sensor mit "press.0" mit an, dann bekommst du nur den Messwert ohne ok zurück!
# Anlagendruck
get Druck cmd {"r -f Waterpressure press.0\n"}
get Druck expect ".*\n*"
get Druck postproc { sprintf("%5.1f",$_) }
LG
Reinhart
Hallo ihr Spezialisten,
seit einer ganzen Weile versuche ich die Integration in FHEM mittels MQTT2. Es klappt alles super und auch die Templates sehen gut aus. Nur aus irgendeinem Grund werden die Statusmeldungen(Status01 und Status02) nicht in einzelne Readings aufgeteilt. Vermutlich keine große Sache aber ich komm einfach nicht drauf wo das Problem liegt.
defmod MQTT2_ebusd_bai MQTT2_DEVICE ebusd_bai
attr MQTT2_ebusd_bai IODev ebusMQTT
attr MQTT2_ebusd_bai jsonMap Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
attr MQTT2_ebusd_bai readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }\
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }\
ebusd/bai/DateTime:.* DateTime\
ebusd/bai/SetMode:.* SetMode
attr MQTT2_ebusd_bai room MQTT2_DEVICE
setstate MQTT2_ebusd_bai 2020-11-11 21:32:18 DateTime valid;;21:32:13;;11.11.2020;;7.312
setstate MQTT2_ebusd_bai 2020-11-11 21:32:18 SetMode auto;;38.0;;50.0;;-;;0;;0;;1;;0;;0;;0
setstate MQTT2_ebusd_bai 2020-11-11 21:18:42 Status01 44.0;;-;;7.562;;0.0;;47.0;;off
setstate MQTT2_ebusd_bai 2020-11-11 21:32:13 Status01_ 42.0
setstate MQTT2_ebusd_bai 2020-11-11 21:18:33 Status02 auto;;60;;50.0;;80;;65.0
setstate MQTT2_ebusd_bai 2020-11-11 21:19:08 associatedWith MQTT2_ebusd
Zitat von: blackmondeo am 11 November 2020, 21:33:48
Hallo ihr Spezialisten,
seit einer ganzen Weile versuche ich die Integration in FHEM mittels MQTT2. Es klappt alles super und auch die Templates sehen gut aus. Nur aus irgendeinem Grund werden die Statusmeldungen(Status01 und Status02) nicht in einzelne Readings aufgeteilt. Vermutlich keine große Sache aber ich komm einfach nicht drauf wo das Problem liegt.
mach doch bitte mal ein
list MQTT2_ebusd_baiund poste es hier.
LG
Hallo zusammen,
eigentlich wollte ich erst einen eigenen Thread aufmachen. Doch hier scheint das geballte Wissen bereits versammelt zu sein ;)
Ich habe eine Vaillant atmoTEC classic VCW 194/3-C-HL Gas-Kombitherme in Betrieb. Vor langer Zeit hatte ich mal experimentell ein paar Daten über die X6 Schnittstelle abgegriffen, lies das Projekt aber einschlafen. Schnittstelle funktionierte soweit, konnte das auch mit vrDialog verifizieren. Nun möchte ich das Projekt "VCW" erneut angehen; diesmal über eBus. Und da hat sich ja in den Jahren hier sehr viel getan.
Mein Gerät unterstützt leider eBus nicht out-of-thebox. Also habe ich kurz recherchiert und mir das Vaillant VR 39 Zusatzmodul besorgt. Klemme 7-8-9 ist bei mir vorhanden, X6 ebenfalls.
Nun wollte ich heute das Zusatzmodul einbauen und musste feststellen, das meine Anlage etwas von der Einbauanleitung abweicht. Schaut man sich die zwei Seiten der Einbauanleitung an, so sollte das Zusatzmodul links neben der Hauptplatine gesteckt werden. Hier ist jedoch bei mir kein entsprechender Platz vorgesehen.
Dies beunruhigt mich erst einmal nicht. Es würde sich schon ein Plätzchen für die Platine finden, doch anders als auf der Zeichnung dargestellt, hat mein Zusatzmodul unten noch 4 Steckkontakte. Desweiteren ist in einer Installationsanleitung, die ich im Web gefunden habe, oben am Rand der Platine noch ein kontaktfreier Steckplatz, den ich gemäß Zeichnung nicht einordnen kann. Ich vermute mal, dass das ein Abstandshalter ist. Gemäß der Installationsanleitung besteht ja nur eine Verbindung über RJ-12 / 6P6C zwischen dem Modul und der Hauptplatine.
Ist das Zusatzmodul VR 39 für meine Anlage geeignet? Hat da jemand schon Erfahrungen?
Viele Grüße
Martin
@Martin
Ich kenne die VR 39 leider nicht, habe mir aber die Bedienungsanleitungen angeschaut. Es hat auch schon einer hier im Forum (https://forum.fhem.de/index.php?topic=47439.0) darüber diskutiert und das erfolgreich in Betrieb genommen. Anfangs hatte der Probleme mit dem eBus Adapter.
Du hast völlig recht, die Datenverbindung zum Heizgerät läuft ja über den RJ12 Stecker und die VR 39 ist ja ein Protokollkonverter um eBus fähige Geräte anschließen zu können, sehe daher keinen Grund warum das nicht gehen sollte.
Was dann der eBus Dämon für ein Gerät erkennt weiß ich nicht, nehme aber an nicht VR39 sondern eben deinen Heizgerätetyp. Vermutlich schleift die VR 39 das 1:1 durch, sonst hätte ja auch der Modemanschluß für Wartung ein Problem wenn das nicht transparent wäre.
Der obere leere Platinenstecker ist für mich eine reine mechanische Stütze der Platine, sehe ich auch auf der Zeichnung so.
Der untere rechte Platinenstecker könnte eventuell der Anschluß für einen Außenfühler mit DCF sein.
Was die immer von 7-8-9 schreiben bin ich mir auch nicht im klaren, normalerweise ist das der Anschluß für einen Raumthermostat (mit Kontakt) .
Das einzig Dumme ist jetzt, das wir im Augenblick keine Adapter haben, die kommen aber hoffentlich in einigen Wochen. Vorher kannst daher auch nichts weiter testen. Ich würde mich mit dem Anwender pc1246 in Verbindung setzen, der hat das ja schon erfolgreich umgesetzt. Vielleicht liest er hier eh schon mit.
LG
Reinhart
Zitat von: Reinhart am 14 November 2020, 10:10:25
mach doch bitte mal ein
list MQTT2_ebusd_bai
und poste es hier.
LG
Hallo Reinhart,
ja gern. Folgendes wird ausgegeben.
Internals:
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
FUUID 5fac46f6-f33f-7689-d31f-3d8fa7bf3d7d5254
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 16961
NAME MQTT2_ebusd_bai
NR 30
STATE ???
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 16961
ebusMQTT_TIME 2020-11-14 22:03:31
Helper:
DBLOG:
DateTime:
logdb:
TIME 1605387785.56163
VALUE ok;22:03:07;-.-.-;9.688
SetMode:
logdb:
TIME 1605387805.91309
VALUE auto;36.0;50.0;-;0;0;1;0;0;0
Status01_:
logdb:
TIME 1605387811.02142
VALUE 42.0
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
Status02_0_value _HWCMode
Status02_1_value _Maximaltemperatur
Status02_2_value _ReglerMaxTEMP
Status02_3_value _ReglerCurrentTemp
READINGS:
2020-11-14 22:03:05 DateTime ok;22:03:07;-.-.-;9.688
2020-11-14 22:03:25 SetMode auto;36.0;50.0;-;0;0;1;0;0;0
2020-11-11 21:18:42 Status01 44.0;-;7.562;0.0;47.0;off
2020-11-14 22:03:31 Status01_ 42.0
2020-11-11 21:18:33 Status02 auto;60;50.0;80;65.0
2020-11-11 21:19:08 associatedWith MQTT2_ebusd
Attributes:
IODev ebusMQTT
jsonMap Status01_0_value:_Vorlauf Status01_1_value:_Ruecklauf Status01_2_value:_Aussentemp Status01_3_value:_Warmwasser Status01_4_value:_WWSpeicher Status01_5_value:_Pumpenstatus Status02_0_value:_HWCMode Status02_1_value:_Maximaltemperatur Status02_2_value:_ReglerMaxTEMP Status02_3_value:_ReglerCurrentTemp
readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/DateTime:.* DateTime
ebusd/bai/SetMode:.* SetMode
room MQTT2_DEVICE
Im globalen FHEM-Logfile wird immer wieder folgendes notiert:
2020.11.14 22:11:35 1: Error parsing >auto;60;50.0;80;65.0< for Status02_
Komisch ist das nur Status02 geloggt wird und Status01 nicht auftaucht.
Hat jemand einen Ansatz wo ich nach dem Problem suchen kann? Ich hab gerade keine Idee mehr.
Vielen Dank. Torsten
Hallo Reinhard,
danke für Deine Überlegungen. Ich sehe es genau so wie Du:
Daten über RJ12 und auch ich gehe davon aus, dass das Gerät (also die VCW) dann über den VR 39 "durchgereicht" wird. Es sind eigentlich zwei Fragen, die ich mir stelle:
a) Was hat der untere Platinenstecker für eine Funktion?
b) Woher bezieht das Zusatzmodul seine Betriebsspannung? Über die RJ12 Schnittstelle oder vielleicht über a)?
Meine Vermutung zum oberen, leeren Stecker hatte ich ja schon geschrieben. Das sehen wir beide gleich. Laut Anleitung für den VR 32/3 wird hier ein Befestigungsclip angebracht. Also gilt das (dem gleichen Aufbau der Platine zu entnehmen) wohl auch für den VR 39 ;)
Zitat von: Reinhart am 14 November 2020, 20:04:26
Was die immer von 7-8-9 schreiben bin ich mir auch nicht im klaren, normalerweise ist das der Anschluß für einen Raumthermostat (mit Kontakt) .
Jepp... Ich habe da eine Vermutung: Es gibt Geräte mit "3-4-5 Klemme", die dann wohl keine "7-8-9 Klemme" haben (und vice versa?). Daher auch die zwei unterschiedlichen Module VR 36 ("3-4-5") und VR 39 ("7-8-9"). Der Aufbau der Platinen ist auch vollkommen verschieden und beim VR 36 ist dann auch gleich die "Klemme 7-8-9" dabei, die ja scheinbar bei den Geräten mit "3-4-5 Klemme" fehlt. Die Angabe der "Klemme" dient also wohl nur zur Unterscheidung der kompatiblen Geräte. Ist aber nur eine Vermutung!
Folgende (mir bekannte relevante) Module gibt es im Zusammenhang mit eBus:
Vaillant VR 32/3 modulierender Buskoppler eBUS- verwendbar für auroMATIC 620, multiMATIC 700, sensoCOMFORT 720
- Der Buskoppler verbindet bis zu 16 Heizgeräte mit eBUS-Schnittstelle über den eBUS. Durch den Adressschalter kann jedem Gerät eine eigene Adresse zugewiesen werden. Eine andere oder darüber hinausgehende Benutzung gilt als nicht bestimmungsgemäß.
Anmerkung:
Aus meiner Sicht kommt dieses Modul nicht in Frage, da es weitere Geräte wie z.B. einen Regler, etc. mit jeweils eigener Adresse über eBus anbinden kann. Dazu gibt es dann auch noch einen Buskoppler (VR 30/3), der bei einer Kaskade von mehr als einem VR 32 angeschlossen werden muss. Ohne Gewähr... habe es nur "überflogen"... ;)
Beim VR 32 wird jedoch explizit von der X30 Buchse geschrieben. Meine Anlage hat "nur" eine X6 Schnittstelle.. Siehe auch Anmerkung weiter unten.
Vaillant VR 36 Zusatzmodul (eBUS-Adapter) an vorhandenen Regler- für den Anschluss eines nicht eBUS-fähigen Reglers (Schnittst. 3-4-5) an ein eBUS Gerät
- zum Einbau in die Elektronikbox
Anmerkung:
Aus meiner Sicht kommt auch dieses Modul nicht in Frage, da es für die Geräte mit "Klemme 3-4-5" gedacht ist. Siehe oben.
Vaillant VR 39 Zusatzmodul (eBUS-Adapter) an Wärmeerzeuger mit Schnittstelle 7-8-9, bidirektional an eBUS Regler- für den Anschluss eines nicht eBUS-fähigen Wärmeerzeugers (Schnittst. 7-8-9) an einen eBUS Regler,
- zum Einbau in die Elektronikbox
Anmerkung:
Trotz der äusserst knappen Beschreibungen, kommt für mich also nur der VR 39 in Frage. So meine Schlussfolgerung. ;)
Dennoch sehe ich hier noch einen "Stolperstein", den ich oben bereits erwähnt hatte:
Beim VR 32/3 ist die Rede von X30; ich habe "nur" X6, also die "Modemschnittstelle" für die es m.M.n. sogar mal ein "Telefonmodul" gab. Leider habe ich bisher noch keine zur VR 32/3 vergleichbare "Installationsanleitung für den Fachhandwerker" gefunden. Dort stünde vielleicht genauer drin, das es an die X6 Schnittstelle angeschlossen wird. Nach meinen Recherchen läge am X30 ja bereits der eBus an. Ausserdem ist X30 ein 4P4C. Der X6 ist 6P6C, was sich auch mit dem VR 39 Anschluss deckt.
Zitat von: Reinhart am 14 November 2020, 20:04:26
Das einzig Dumme ist jetzt, das wir im Augenblick keine Adapter haben, die kommen aber hoffentlich in einigen Wochen. Vorher kannst daher auch nichts weiter testen. Ich würde mich mit dem Anwender pc1246 in Verbindung setzen, der hat das ja schon erfolgreich umgesetzt. Vielleicht liest er hier eh schon mit.
Ja, Erfahrungswerte wären hier hilfreich. Vielleicht hat ja auch jemand noch einen eBus 1.x oder 2.x Adapter (fertig bestückt, ggf. zum Testen) über. Ansonsten gebe ich Dir recht: Warten ist angesagt, leider ;)
Danke und viele Grüße
Martin
hm, habe selber keine Ahnung, bei mir zählt der brav hoch!
Vielleicht hilft ein Reset auf Werkseinstellungen, aber ich vermute dann ist alles von dir programmierte auch weg!
r;wi,,SetFactoryValues,d.96 Werkseinstellungen,,,,"6804",,,yesno,,,Werkseinstellungen
Vorsicht, ist ein "wi" (Installer) Kommando, also "--accesslevel=*" in der Config angeben sonst kannst nicht ins Register schreiben.
LG
Reinhart
Zitat von: blackmondeo am 14 November 2020, 22:41:19
Hat jemand einen Ansatz wo ich nach dem Problem suchen kann? Ich hab gerade keine Idee mehr.
Vielen Dank. Torsten
Also deine jsonMaps auf die Readings funktionieren nicht so wie du sie brauchst. Als Beispiel hänge ich dir unten meine an damit du vergleichen kannst.
Ich vermute, deine bridgeRegexp am Device "MQTT2_ebusd" passt nicht ganz oder du hast "autocreate" nicht auf "1" gesetzt. Vergleiche deine Readings mit meinen! Versuche einmal in diese Richtung den Fehler einzugrenzen, wenn die Regexp im übergeordneten Device passen, dann sollten die Readings auch im "bai" richtig gefüllt werden.
(ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"bridgeRegexp im Device " MQTT2_ebusd", sichere aber vorher deine!
Internals:
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 61333
NAME MQTT2_ebusd_bai
NR 1868
STATE ???
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 61333
ebusMQTT_TIME 2020-11-15 11:01:27
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
Status02_0_value _HWCMode
Status02_1_value _Maximaltemperatur
Status02_2_value _ReglerMaxTEMP
Status02_3_value _ReglerCurrentTemp
READINGS:
2020-11-15 10:39:15 CounterStartattempts1_temp0_value 30
2020-11-15 11:01:12 DateTime_bdate_value -.-.-
2020-11-15 11:01:12 DateTime_btime_value 03:12:33
2020-11-15 11:01:12 DateTime_dcfstate_value nosignal
2020-11-15 11:01:12 DateTime_temp2_value 4.000
2020-11-15 10:39:15 DeactivationsIFC_0_name
2020-11-15 10:39:15 DeactivationsIFC_0_value 19
2020-11-15 10:39:15 FanHours_hoursum2_value 9479
2020-11-15 10:59:23 FanSpeed_0_name
2020-11-15 10:59:23 FanSpeed_0_value 1780
2020-11-15 10:59:17 FlowTempDesired_temp_value 43.50
2020-11-15 10:59:23 FlowTemp_sensor_value ok
2020-11-15 10:59:23 FlowTemp_temp_value 46.25
2020-11-15 10:59:23 HcHours_hoursum2_value 8164
2020-11-15 10:39:15 HcStarts_0_name
2020-11-15 10:39:15 HcStarts_0_value 60700
2020-11-15 10:39:15 HwcHours_hoursum2_value 982
2020-11-15 10:39:19 HwcSetPotmeter_temp_value 49.00
2020-11-15 10:59:23 HwcStarts_0_name
2020-11-15 10:59:23 HwcStarts_0_value 131900
2020-11-15 10:59:12 OutdoorstempSensor_sensor_value ok
2020-11-15 10:59:12 OutdoorstempSensor_temp_value 4.25
2020-11-15 10:39:19 PartloadHcKW_power_value 18
2020-11-15 10:48:28 PrEnergyCountHwc1 {
"0": {"name": "", "value": 3602137}}
2020-11-15 10:48:18 PrEnergySumHc1 {
"0": {"name": "", "value": 4294967154}}
2020-11-15 10:59:23 ReturnTemp_sensor_value ok
2020-11-15 10:59:23 ReturnTemp_temp_value 39.50
2020-11-15 10:59:23 ReturnTemp_tempmirror_value 64903
2020-11-15 11:01:21 SetMode_disablehc_value 0
2020-11-15 11:01:21 SetMode_disablehwcload_value 1
2020-11-15 11:01:21 SetMode_disablehwctapping_value 0
2020-11-15 11:01:21 SetMode_flowtempdesired_value 43.5
2020-11-15 11:01:21 SetMode_hcmode_value auto
2020-11-15 11:01:21 SetMode_releaseBackup_value 0
2020-11-15 11:01:21 SetMode_releaseCooling_value 0
2020-11-15 11:01:21 SetMode_remoteControlHcPump_value 0
2020-11-15 11:01:27 Status01_0_name temp1
2020-11-15 11:01:27 Status01_1_name temp1
2020-11-15 11:01:27 Status01_2_name temp2
2020-11-15 11:01:27 Status01_3_name temp1
2020-11-15 11:01:27 Status01_4_name temp1
2020-11-15 11:01:27 Status01_5_name pumpstate
2020-11-15 11:01:12 Status02_0_name hwcmode
2020-11-15 11:01:12 Status02_1_name temp0
2020-11-15 11:01:12 Status02_2_name temp1
2020-11-15 11:01:12 Status02_3_name temp0
2020-11-15 11:01:12 Status02_4_name temp1
2020-11-15 11:01:12 Status02_4_value 49.0
2020-11-15 10:59:23 WPPWMPower_percent0_value 53
2020-11-15 10:59:23 WaterPressure_press_value 1.488
2020-11-15 10:59:23 WaterPressure_sensor_value ok
2020-11-15 11:01:27 _Aussentemp 4.000
2020-11-15 11:01:12 _HWCMode auto
2020-11-15 11:01:12 _Maximaltemperatur 60
2020-11-15 11:01:27 _Pumpenstatus on
2020-11-15 11:01:12 _ReglerCurrentTemp 70
2020-11-15 11:01:12 _ReglerMaxTEMP 70.0
2020-11-15 11:01:27 _Ruecklauf 37.0
2020-11-15 11:01:27 _Vorlauf 44.0
2020-11-15 11:01:27 _WWSpeicher 41.0
2020-11-15 11:01:27 _Warmwasser 43.0
2020-11-15 11:01:22 outsidetemp_temp2_value 2.000
2020-11-15 11:01:02 vdatetime_date_value 12.02.2008
2020-11-15 11:01:02 vdatetime_time_value 11:42:02
Attributes:
DbLogExclude .*
IODev ebusMQTT
devStateStyle style="text-align:right"
icon sani_boiler_temp
jsonMap Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
Status02_0_value:_HWCMode
Status02_1_value:_Maximaltemperatur
Status02_2_value:_ReglerMaxTEMP
Status02_3_value:_ReglerCurrentTemp
model E_05_eBus_bai_Fan_Pump
readingList ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* { json2nameValue($EVENT, 'Status02_', $JSONMAP) }
ebusd/bai/DateTime:.* { json2nameValue($EVENT, 'DateTime_', $JSONMAP) }
ebusd/bai/WaterPressure/get:.* get
ebusd/bai/FlowTemp/get:.* get
ebusd/bai/ReturnTemp/get:.* get
ebusd/bai/FanSpeed/get:.* get
ebusd/bai/WPPWMPower/get:.* get
ebusd/bai/OutdoorstempSensor/get:.* get
ebusd/bai/WaterPressure:.* { json2nameValue($EVENT, 'WaterPressure_', $JSONMAP) }
ebusd/bai/FlowTemp:.* { json2nameValue($EVENT, 'FlowTemp_', $JSONMAP) }
ebusd/bai/ReturnTemp:.* { json2nameValue($EVENT, 'ReturnTemp_', $JSONMAP) }
ebusd/bai/FanSpeed:.* { json2nameValue($EVENT, 'FanSpeed_', $JSONMAP) }
ebusd/bai/WPPWMPower:.* { json2nameValue($EVENT, 'WPPWMPower_', $JSONMAP) }
ebusd/bai/OutdoorstempSensor:.* { json2nameValue($EVENT, 'OutdoorstempSensor_', $JSONMAP) }
ebusd/broadcast/vdatetime:.* { json2nameValue($EVENT, 'vdatetime_', $JSONMAP) }
ebusd/bai/SetMode:.* { json2nameValue($EVENT, 'SetMode_', $JSONMAP) }
ebusd/broadcast/outsidetemp:.* { json2nameValue($EVENT, 'outsidetemp_', $JSONMAP) }
ebusd/bai/HcHours:.* { json2nameValue($EVENT, 'HcHours_', $JSONMAP) }
ebusd/bai/FanHours:.* { json2nameValue($EVENT, 'FanHours_', $JSONMAP) }
ebusd/bai/FlowTempDesired:.* { json2nameValue($EVENT, 'FlowTempDesired_', $JSONMAP) }
ebusd/bai/HwcStarts:.* { json2nameValue($EVENT, 'HwcStarts_', $JSONMAP) }
ebusd/bai/HcStarts:.* { json2nameValue($EVENT, 'HcStarts_', $JSONMAP) }
ebusd/bai/ccTimer\.Monday/get:.* get
ebusd/bai/DeactivationsIFC:.* { json2nameValue($EVENT, 'DeactivationsIFC_', $JSONMAP) }
ebusd/bai/HwcHours:.* { json2nameValue($EVENT, 'HwcHours_', $JSONMAP) }
ebusd/bai/CounterStartattempts1:.* { json2nameValue($EVENT, 'CounterStartattempts1_', $JSONMAP) }
ebusd/bai/PartloadHcKW:.* { json2nameValue($EVENT, 'PartloadHcKW_', $JSONMAP) }
ebusd/bai/HwcSetPotmeter:.* { json2nameValue($EVENT, 'HwcSetPotmeter_', $JSONMAP) }
ebusd/bai/list:.* list
ebusd/bai/AATemp:.* AATemp
ebusd/bai/AccessoriesOne:.* AccessoriesOne
ebusd/bai/AccessoriesTwo:.* AccessoriesTwo
ebusd/bai/ACRoomthermostat:.* ACRoomthermostat
ebusd/bai/AircontrolOk:.* AircontrolOk
ebusd/bai/AITemp:.* AITemp
ebusd/bai/AntiCondensValue:.* AntiCondensValue
ebusd/bai/averageIgnitiontime:.* averageIgnitiontime
ebusd/bai/BlockTimeHcMax:.* BlockTimeHcMax
ebusd/bai/BoilerType2:.* BoilerType2
ebusd/bai/BoilerType:.* BoilerType
ebusd/bai/ChangesDSN:.* ChangesDSN
ebusd/bai/CirPump:.* CirPump
ebusd/bai/clearerrorhistory:.* clearerrorhistory
ebusd/bai/CounterStartattempts2:.* CounterStartattempts2
ebusd/bai/CounterStartAttempts3:.* CounterStartAttempts3
ebusd/bai/currenterror:.* currenterror
ebusd/bai/dcfState:.* dcfState
ebusd/bai/DCFTimeDate:.* DCFTimeDate
ebusd/bai/DCRoomthermostat:.* DCRoomthermostat
ebusd/bai/DeactivationsTemplimiter:.* DeactivationsTemplimiter
ebusd/bai/DeltaFlowReturnMax:.* DeltaFlowReturnMax
ebusd/bai/DisplayMode:.* DisplayMode
ebusd/bai/DSN:.* DSN
ebusd/bai/DSNOffset:.* DSNOffset
ebusd/bai/DSNStart:.* DSNStart
ebusd/bai/EBusHeatcontrol:.* EBusHeatcontrol
ebusd/bai/EbusSourceOn:.* EbusSourceOn
ebusd/bai/EbusVoltage:.* EbusVoltage
ebusd/bai/errorhistory:.* errorhistory
ebusd/bai/ExhaustCurve:.* ExhaustCurve
ebusd/bai/exhaustWayBlockCounter:.* exhaustWayBlockCounter
ebusd/bai/expertlevel_ReturnTemp:.* expertlevel_ReturnTemp
ebusd/bai/ExternalFaultmessage:.* ExternalFaultmessage
ebusd/bai/externalFlowTempDesired:.* externalFlowTempDesired
ebusd/bai/externalHwcSwitch:.* externalHwcSwitch
ebusd/bai/ExternGasvalve:.* ExternGasvalve
ebusd/bai/ExtFlowTempDesiredMin:.* ExtFlowTempDesiredMin
ebusd/bai/extWP:.* extWP
ebusd/bai/FanMaxSpeedOperation:.* FanMaxSpeedOperation
ebusd/bai/FanMinSpeedOperation:.* FanMinSpeedOperation
ebusd/bai/FanPWMSum:.* FanPWMSum
ebusd/bai/FanPWMTest:.* FanPWMTest
ebusd/bai/FanStarts:.* FanStarts
ebusd/bai/Flame:.* Flame
ebusd/bai/FlameSensingASIC:.* FlameSensingASIC
ebusd/bai/FloorHeatingContact:.* FloorHeatingContact
ebusd/bai/FlowsetHcMax:.* FlowsetHcMax
ebusd/bai/FlowsetHwcMax:.* FlowsetHwcMax
ebusd/bai/FlowSetPotmeter:.* FlowSetPotmeter
ebusd/bai/Fluegasvalve:.* Fluegasvalve
ebusd/bai/Gasvalve3UC:.* Gasvalve3UC
ebusd/bai/Gasvalve:.* Gasvalve
ebusd/bai/GasvalveASICFeedback:.* GasvalveASICFeedback
ebusd/bai/GasvalveUC:.* GasvalveUC
ebusd/bai/GasvalveUCFeedback:.* GasvalveUCFeedback
ebusd/bai/GVStepOffsetMax:.* GVStepOffsetMax
ebusd/bai/GVStepOffsetMin:.* GVStepOffsetMin
ebusd/bai/HcPumpMode:.* HcPumpMode
ebusd/bai/HcPumpStarts:.* HcPumpStarts
ebusd/bai/HcUnderHundredStarts:.* HcUnderHundredStarts
ebusd/bai/HeatingSwitch:.* HeatingSwitch
ebusd/bai/HoursTillService:.* HoursTillService
ebusd/bai/HwcDemand:.* HwcDemand
ebusd/bai/HwcImpellorSwitch:.* HwcImpellorSwitch
ebusd/bai/HwcPostrunTime:.* HwcPostrunTime
ebusd/bai/HwcSwitch:.* HwcSwitch
ebusd/bai/HwcTemp:.* HwcTemp
ebusd/bai/HwcTempDesired:.* HwcTempDesired
ebusd/bai/HwcTempMax:.* HwcTempMax
ebusd/bai/HwcTypes:.* HwcTypes
ebusd/bai/HwcUnderHundredStarts:.* HwcUnderHundredStarts
ebusd/bai/HwcWaterflow:.* HwcWaterflow
ebusd/bai/HwcWaterflowMax:.* HwcWaterflowMax
ebusd/bai/Ignitor:.* Ignitor
ebusd/bai/IonisationVoltageLevel:.* IonisationVoltageLevel
ebusd/bai/maintenancedata_HwcTempMax:.* maintenancedata_HwcTempMax
ebusd/bai/maxIgnitiontime:.* maxIgnitiontime
ebusd/bai/minIgnitiontime:.* minIgnitiontime
ebusd/bai/ModulationTempDesired:.* ModulationTempDesired
ebusd/bai/OverflowCounter:.* OverflowCounter
ebusd/bai/ParamToken:.* ParamToken
ebusd/bai/PartloadHwcKW:.* PartloadHwcKW
ebusd/bai/PartnumberBox:.* PartnumberBox
ebusd/bai/PositionValveSet:.* PositionValveSet
ebusd/bai/PowerValue:.* PowerValue
ebusd/bai/PrAPSCounter:.* PrAPSCounter
ebusd/bai/PrAPSSum:.* PrAPSSum
ebusd/bai/PredCombustionDecrementTime:.* PredCombustionDecrementTime
ebusd/bai/PredCombustionPredCounter:.* PredCombustionPredCounter
ebusd/bai/PredCombustionSwitchingPoint:.* PredCombustionSwitchingPoint
ebusd/bai/PredFanPWMDevThreshold:.* PredFanPWMDevThreshold
ebusd/bai/PredFanPWMPredCounter:.* PredFanPWMPredCounter
ebusd/bai/PredFanPWMRefPWMcounter:.* PredFanPWMRefPWMcounter
ebusd/bai/PredFanPWMRefPWMsum:.* PredFanPWMRefPWMsum
ebusd/bai/PredFanPWMSwitchingPoint:.* PredFanPWMSwitchingPoint
ebusd/bai/PredIgnitionPredCounter:.* PredIgnitionPredCounter
ebusd/bai/PredIgnitionSwitchingPoint:.* PredIgnitionSwitchingPoint
ebusd/bai/PredSourcePressureDevThreshold:.* PredSourcePressureDevThreshold
ebusd/bai/PredSourcePressurePredCounter:.* PredSourcePressurePredCounter
ebusd/bai/PredSourcePressureSwitchingPoint:.* PredSourcePressureSwitchingPoint
ebusd/bai/PredWaterflowDevThreshold:.* PredWaterflowDevThreshold
ebusd/bai/PredWaterflowSwitchingPoint:.* PredWaterflowSwitchingPoint
ebusd/bai/PredWaterpressureMaxPressure:.* PredWaterpressureMaxPressure
ebusd/bai/PredWaterpressureMinPressure:.* PredWaterpressureMinPressure
ebusd/bai/PredWaterpressureSwitchingPoint:.* PredWaterpressureSwitchingPoint
ebusd/bai/PrEnergyCountHc1:.* PrEnergyCountHc1
ebusd/bai/PrEnergyCountHc2:.* PrEnergyCountHc2
ebusd/bai/PrEnergyCountHc3:.* PrEnergyCountHc3
ebusd/bai/PrEnergyCountHwc1:.* PrEnergyCountHwc1
ebusd/bai/PrEnergyCountHwc2:.* PrEnergyCountHwc2
ebusd/bai/PrEnergyCountHwc3:.* PrEnergyCountHwc3
ebusd/bai/PrEnergySumHc1:.* PrEnergySumHc1
ebusd/bai/PrEnergySumHc2:.* PrEnergySumHc2
ebusd/bai/PrEnergySumHc3:.* PrEnergySumHc3
ebusd/bai/PrEnergySumHwc1:.* PrEnergySumHwc1
ebusd/bai/PrEnergySumHwc2:.* PrEnergySumHwc2
ebusd/bai/PrEnergySumHwc3:.* PrEnergySumHwc3
ebusd/bai/PumpHours:.* PumpHours
ebusd/bai/PumpHwcFlowNumber:.* PumpHwcFlowNumber
ebusd/bai/PumpHwcFlowSum:.* PumpHwcFlowSum
ebusd/bai/ReduceModulationBlocktime:.* ReduceModulationBlocktime
ebusd/bai/RemainingBoilerblocktime:.* RemainingBoilerblocktime
ebusd/bai/ReturnRegulation:.* ReturnRegulation
ebusd/bai/ReturnTempMax:.* ReturnTempMax
ebusd/bai/SecondPumpMode:.* SecondPumpMode
ebusd/bai/SerialNumber:.* SerialNumber
ebusd/bai/SetFactoryValues:.* SetFactoryValues
ebusd/bai/SHEMaxDeltaHwcFlow:.* SHEMaxDeltaHwcFlow
ebusd/bai/SHEMaxFlowTemp:.* SHEMaxFlowTemp
ebusd/bai/SolPostHeat:.* SolPostHeat
ebusd/bai/SpecialAdj:.* SpecialAdj
ebusd/bai/Statenumber:.* Statenumber
ebusd/bai/Status16:.* Status16
ebusd/bai/Status:.* Status
ebusd/bai/Storageloadpump:.* Storageloadpump
ebusd/bai/StorageLoadPumpHours:.* StorageLoadPumpHours
ebusd/bai/StorageloadPumpStarts:.* StorageloadPumpStarts
ebusd/bai/StorageLoadTimeMax:.* StorageLoadTimeMax
ebusd/bai/StoragereleaseClock:.* StoragereleaseClock
ebusd/bai/StorageTemp:.* StorageTemp
ebusd/bai/StorageTempDesired:.* StorageTempDesired
ebusd/bai/StorageTempMax:.* StorageTempMax
ebusd/bai/TargetFanSpeed:.* TargetFanSpeed
ebusd/bai/TargetFanSpeedOutput:.* TargetFanSpeedOutput
ebusd/bai/TempDiffBlock:.* TempDiffBlock
ebusd/bai/TempDiffFailure:.* TempDiffFailure
ebusd/bai/TempGradientFailure:.* TempGradientFailure
ebusd/bai/Templimiter:.* Templimiter
ebusd/bai/TemplimiterWithNTC:.* TemplimiterWithNTC
ebusd/bai/TempMaxDiffExtTFT:.* TempMaxDiffExtTFT
ebusd/bai/TimerInputHc:.* TimerInputHc
ebusd/bai/ValveMode:.* ValveMode
ebusd/bai/ValveStarts:.* ValveStarts
ebusd/bai/VolatileLockout:.* VolatileLockout
ebusd/bai/WarmstartDemand:.* WarmstartDemand
ebusd/bai/WarmstartOffset:.* WarmstartOffset
ebusd/bai/WaterHcFlowMax:.* WaterHcFlowMax
ebusd/bai/WaterpressureBranchControlOff:.* WaterpressureBranchControlOff
ebusd/bai/WaterpressureMeasureCounter:.* WaterpressureMeasureCounter
ebusd/bai/WaterpressureVariantSum:.* WaterpressureVariantSum
ebusd/bai/WP:.* WP
ebusd/bai/WPPostrunTime:.* WPPostrunTime
ebusd/bai/WPPWMPowerDia:.* WPPWMPowerDia
ebusd/bai/WPSecondStage:.* WPSecondStage
room MQTT2_DEVICE
LG
Reinhart
das wird so nicht funktionieren, da das Register vermutlich "read only" ist.
Aber probieren kannst du es ja und erweitere mit "w" und teste mit ebusctl.
ebusctl w -c bai PrEnergyCountHc1 0
müsste dann so ähnlich sein.
eBusd neu starten damit die Änderung gelesen wird!
LG
@ fhempi
Ermittle damit recht ordentlich den aktuellen Zählerstand:
get T.Zaehler cmd {"read -f -c bai PrEnergySumHc1\n\000read -f -c bai PrEnergySumHwc1\n"}
get T.Zaehler expect ".*\n\n"
get T.Zaehler postproc { calc_Verbrauch($_); }
sub calc_Verbrauch($)
{
my ($str)=@_;
$str=~ s/\n/ /g;
my @val=split(' ',$str);
my $Verbr = ($val[0]+$val[1])/1000000*1.246; # 20.12.19
my $Zaehler = $Verbr + 55.15; # 539.720
$str = sprintf('%.2f',$Zaehler);
return $str;
}
aktuell Gaszähler abgelesen: 649,0 - berechneter Zähler: 648,7
Bitte den Faktor nach einiger Zeit überprüfen und Deinen aktuellen Anfang-Zählertand eingeben.
Zitat von: cs-online am 30 Oktober 2020, 19:28:34
Ich hab die Ecotec Exclusiv und die 470er Steuerung, seit Jahren Speicherladung über EBUSd, keine Probleme. Aber wir haben hier festgestellt, dass es unterschiedliche SW-Versionen gibt und nicht alle das unterstützen.
Du musst mal in die 470er CSV und schauen, ob bei HwcOPMode r;w oder nur r vorsteht, das muss r;w sein. Wenn du Ändern musst, dann einmal EbusD neustarten oder reload senden, dann mal probieren, ob mit
ebusctl w -c 470 HwcOPMode 6
die Speicherladung gestartet wird, kann ein paar Sekunden dauern, bis das im Display der 470er erscheint... Dann schauen wir weiter ;-)
Grüße Christian
Moin zusammen
Koennt Ihr in HwcOPMode sehen, wenn Ihr manuell eine Speicherladung anstosst? Bei mir aendert sich das nie, und das waere eigentlich mein groesster Traum dies von fhem anstossen zu koennen!
Danke und Gruss Christoph
@fhempi
wie hast du ihn jetzt auf 0 gesetzt, mit Reset oder das Register mit 0 beschrieben, interessiert sicher auch andere wie das geht
LG
Zitat von: pc1246 am 16 November 2020, 10:17:48
Moin zusammen
Koennt Ihr in HwcOPMode sehen, wenn Ihr manuell eine Speicherladung anstosst? Bei mir aendert sich das nie, und das waere eigentlich mein groesster Traum dies von fhem anstossen zu koennen!
Danke und Gruss Christoph
Wie meinst du das ? Wenn ich das mit FHEM setze, dann steht auch in meiner 470er Regelung z.B. "1x Speicherladung" und auch wenn ich an der Steuerung Speicherladung aktiviere, bekomme ich mit
ebusctl r -f hwcopmodedann eine 6 zurück, nach Abbruch dann wieder die 2. So kann ich z.B. auch ermitteln, wann Warmwasser fertig ist und über Alexa "Warmwasser ist fertig" ausgeben lassen...
Moin
Bei mir steht da immer eine "2", deshalb meine Frage ob Du das am Regler anforderst und in fhem siehst.
So ganz nebenbei, hast Du keinen Schichtspeicher? Wenn ich Speicherladung anfordere, steht das warme Wasser zur Verfuegung, wenn ich die Treppe hoch bin mich ausgezogen habe und in die Dusche gehe!
Gruss Christoph
Zitat von: Reinhart am 15 November 2020, 11:21:47
Also deine jsonMaps auf die Readings funktionieren nicht so wie du sie brauchst. Als Beispiel hänge ich dir unten meine an damit du vergleichen kannst.
Ich vermute, deine bridgeRegexp am Device "MQTT2_ebusd" passt nicht ganz oder du hast "autocreate" nicht auf "1" gesetzt. Vergleiche deine Readings mit meinen! Versuche einmal in diese Richtung den Fehler einzugrenzen, wenn die Regexp im übergeordneten Device passen, dann sollten die Readings auch im "bai" richtig gefüllt werden.
Hallo Reinhard,
danke erstmal für die Informationen wie es aussehen sollte. Ich habe jetzt alles mögliche probiert und verglichen und mit deinen Einstellungen ersetzt. Hat leider nichts gebracht.
Ich habe alle Devices's gelöscht und nochmal neu erstellt bzw. erstellen lassen. Ich habe mit Templates gearbeitet und auch mal ohne.
Ebenso habe ich auf einem meines Windows System zum testen ein komplett frisches FHEM eingerichtet welches auf den MQTT von RPI zugreift, auch dort das gleiche Problem das jsonmap nicht trennen will.
Ich hab keine Ahnung warum das bei mir nicht funktioniert.
Hier mal die List vom FHEM MQTT Server (Autocreate steht auf Complex)
Internals:
CONNECTS 4
DEF 1883 global
FD 18
FUUID 5fb19b72-f33f-7689-742b-70dbe0138f524fd8
NAME ebusMQTT
NR 87
PORT 1883
STATE Initialized
TYPE MQTT2_SERVER
READINGS:
2020-11-15 22:28:58 RETAIN {"ebusd/global/running":"true","ebusd/global/signal":"true","ebusd/global/version":"ebusd 3.4.v3.3-51-g57eae05"}
2020-11-16 12:39:28 nrclients 2
2020-11-15 22:28:50 state Initialized
clients:
ebusMQTT_127.0.0.1_60382 1
ebusMQTT_192.168.1.27_56468 1
retain:
ebusd/global/running:
ts 1605475738.08554
val true
ebusd/global/signal:
ts 1605475738.0423
val true
ebusd/global/version:
ts 1605475738.08403
val ebusd 3.4.v3.3-51-g57eae05
Attributes:
autocreate complex
room MQTT2_SERVERHier die List vom ebusd mit dem Template als Splitter und autocreate = 1
Internals:
CID ebusd
DEF ebusd
DEVICETOPIC MQTT2_ebusd
FUUID 5fb19b8f-f33f-7689-3e2b-54e83d3cdeb4826f
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 7367
NAME MQTT2_ebusd
NR 88
STATE Status:
1:running
Signal:
2:signal
<br>Uptime: 0 003 22:14
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 7367
ebusMQTT_TIME 2020-11-16 21:24:29
OLDREADINGS:
READINGS:
2020-11-16 09:08:00 associatedWith MQTT2_ebusd
2020-11-16 21:24:27 formatedUptime 0 003 22:14
2020-11-16 21:23:49 outsidetemp 8.625
2020-11-16 21:24:27 uptime 339279
2020-11-16 21:24:29 vdatetime 21:24:24;16.11.2020
Attributes:
IODev ebusMQTT
autocreate 1
bridgeRegexp (ebus.)[^/]*/(bai|[\d]+|cc|e7f|ehp|f[\d][\d]|hc|he.|hmu|hwc|mc|mc.[\d]|omu|omu.[\d]|pms|rcc|rcc.[\d]|sc|sdr_p|ui|uih|v[\d][\d]|v81|v81.[\d]|vd[\d]|vl[\d]|vr_[\d][\d]|zeo)/.*:.* "$1_$2"
(ebus.)[^/]*/(global|broadcast|general|scan|)/.*:.* "$1"
comment NOTE: additional templates and code have been downloaded from svn (contrib).
devStateIcon 1.true:it_net 1.false:it_net@red 2.true:lan_rs485 2.false:lan_rs485@red
icon sani_boiler_temp
model eBus_daemon_splitter
readingList ebusd/global/uptime:.* uptime
ebusd/broadcast/outsidetemp:.* outsidetemp
ebusd/broadcast/vdatetime:.* vdatetime
room MQTT2_DEVICE
setList getKnown:noArg ebusd/list onlyknown
getAll:noArg ebusd/list
stateFormat Status:
1:running
Signal:
2:signal
<br>Uptime: formatedUptime
userReadings formatedUptime:uptime.* {my $m = ReadingsVal($name,"uptime",0)/60;; return sprintf "0 000 00:%02d", $m if $m < 60;; my $h = $m / 60;; $m %= 60;; return sprintf "0 000 %02d:%02d", $h, $m if $h < 24;; my $d = $h / 24;; $h %= 24;; return sprintf "0 %03d %02d:%02d", $d, $h, $m if $d <365;; my $y = $d / 365;; $d %= 365;; return sprintf "%d %03d %02d:%02d", $y, $d, $h, $m}Und hier die List vom BAI Device. Ich habe mich jetzt auf Status01 beschränkt, aber auch dieser wird nicht in seine Bestandteile aufgetrennt.
Internals:
CFGFN
CID ebusd_bai
DEF ebusd_bai
DEVICETOPIC MQTT2_ebusd_bai
FUUID 5fb2dd7d-f33f-7689-4ef6-53ef9c199782f28e
IODev ebusMQTT
LASTInputDev ebusMQTT
MSGCNT 147
NAME MQTT2_ebusd_bai
NR 376
STATE ???
TYPE MQTT2_DEVICE
ebusMQTT_MSGCNT 147
ebusMQTT_TIME 2020-11-16 21:25:09
JSONMAP:
Status01_0_value _Vorlauf
Status01_1_value _Ruecklauf
Status01_2_value _Aussentemp
Status01_3_value _Warmwasser
Status01_4_value _WWSpeicher
Status01_5_value _Pumpenstatus
READINGS:
2020-11-16 21:25:09 DateTime valid;21:25:05;16.11.2020;8.625
2020-11-16 21:25:09 SetMode auto;36.5;50.0;-;0;0;1;0;0;0
2020-11-16 21:16:24 Status01 35.0;-;8.625;0.0;45.0;on
2020-11-16 21:25:04 Status01_ 32.0
2020-11-16 21:24:59 Status02 auto;60;50.0;80;65.0
2020-11-16 21:19:39 associatedWith MQTT2_ebusd
Attributes:
IODev ebusMQTT
jsonMap Status01_0_value:_Vorlauf
Status01_1_value:_Ruecklauf
Status01_2_value:_Aussentemp
Status01_3_value:_Warmwasser
Status01_4_value:_WWSpeicher
Status01_5_value:_Pumpenstatus
readingList ebusd/bai/SetMode:.* SetMode
ebusd/bai/DateTime:.* DateTime
ebusd/bai/Status01:.* { json2nameValue($EVENT, 'Status01_', $JSONMAP) }
ebusd/bai/Status02:.* Status02
room MQTT2_DEVICE
ich kann jetzt so beim durchsehen auch nix besonderes feststellen was falsch sein sollte. Bei den Clients vom Server ist mir aufgefallen, dass du den eBus Dämon auf diesem Raspi laufen hast, ist das richtig? Das müsste der Localhost mit 127.0.0.1_60382 sein.
Setzte bitte einmal am MQTT2_Server das Attribut rawEvents auf .* und verbose auf 5, dann wird alles auch ins Log geschrieben.
Ich hänge dir jetzt hier unten so ein Log an wo der Status01 empfangen wird. Siehst du da jetzt gravierende Unterschiede zu deinen Werten und vor allem zieht die regExp? Wichtig ist hier die Trennung der 6 Namen mit 0 beginnend.
2020.11.17 09:40:43 5: in: PUBLISH: 0(162)(2)(0)(18)ebusd/bai/Status01{(10) "0": {"name": "temp1", "value": 48.0},(10) "1": {"name": "temp1", "value": 41.0},(10) "2": {"name": "temp2", "value": 7.562},(10) "3": {"name": "temp1", "value": 38.0},(10) "4": {"name": "temp1", "value": 41.0},(10) "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 4: ebusMQTT_10.0.0.6_50000 ebusd_3.3_15662 PUBLISH ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 48.0},
"1": {"name": "temp1", "value": 41.0},
"2": {"name": "temp2", "value": 7.562},
"3": {"name": "temp1", "value": 38.0},
"4": {"name": "temp1", "value": 41.0},
"5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5: ebusMQTT_10.0.0.6_50000 ebusd_3.3_15662 => ebusd/bai/Status01:{
"0": {"name": "temp1", "value": 48.0},
"1": {"name": "temp1", "value": 41.0},
"2": {"name": "temp2", "value": 7.562},
"3": {"name": "temp1", "value": 38.0},
"4": {"name": "temp1", "value": 41.0},
"5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5: out: PUBLISH: 0(162)(2)(0)(18)ebusd/bai/Status01{(10) "0": {"name": "temp1", "value": 48.0},(10) "1": {"name": "temp1", "value": 41.0},(10) "2": {"name": "temp2", "value": 7.562},(10) "3": {"name": "temp1", "value": 38.0},(10) "4": {"name": "temp1", "value": 41.0},(10) "5": {"name": "pumpstate", "value": "on"}}
2020.11.17 09:40:43 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.3_15662\000ebusd/bai/Status01\000{\n "0": {"name": "temp1", "value": 48.0},\n "1": {"name": "temp1", "value": 41.0},\n "2": {"name": "temp2", "value": 7.562},\n "3": {"name": "temp1", "value": 38.0},\n "4": {"name": "temp1", "value": 41.0},\n "5": {"name": "pumpstate", "value": "on"}}
Ach ja, in der Config vom Dämon sollte unbedingt diese Einträge vor allem bei der Topic vorhanden sein, IP mit deiner ersetzen.
--mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name
LG
Zitat von: Reinhart am 17 November 2020, 09:53:25
Setzte bitte einmal am MQTT2_Server das Attribut rawEvents auf .* und verbose auf 5, dann wird alles auch ins Log geschrieben.
Ich hänge dir jetzt hier unten so ein Log an wo der Status01 empfangen wird. Siehst du da jetzt gravierende Unterschiede zu deinen Werten und vor allem zieht die regExp? Wichtig ist hier die Trennung der 6 Namen mit 0 beginnend.
Hallo Reinhart,
ja der ebusd läuft auf dem gleichen Raspi. Beim abgleich habe ich jetzt festgestellt das in meiner ebusd config der Eintrag "--mqttjson" fehlte. Warum auch immer, denn die anderen MQTT Einträge hatte ich so drin stehen. Auf jeden Fall habe ich das jetzt ergänzt und nun funktiert das auch so wie es soll.
Zum Vergleich (eventuell hat ja jemand den gleichen Fehler gemacht) hier die LOG Einträge wie sie
nicht aussehen sollten.
2020.11.17 13:41:51 5: in: PUBLISH: 0-(0)(18)ebusd/bai/Status0141.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 4: ebusMQTT_127.0.0.1_60382 ebusd_3.4_562 PUBLISH ebusd/bai/Status01:41.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5: ebusMQTT_127.0.0.1_60382 ebusd_3.4_562 => ebusd/bai/Status01:41.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5: out: PUBLISH: 0-(0)(18)ebusd/bai/Status0141.0;-;9.938;0.0;51.0;off
2020.11.17 13:41:51 5: ebusMQTT: dispatch autocreate=complex\000ebusd_3.4_562\000ebusd/bai/Status01\00041.0;-;9.938;0.0;51.0;off
Also vielen Dank für Eure(Deine) Hilfe und Geduld bei der Fehlersuche.
Sollte ich mir Gedanken machen das beim Rücklauf kein Wert angezeigt wird?
Viele Grüße Torsten
Zitat von: blackmondeo am 17 November 2020, 14:16:18
Hallo Reinhart,
ja der ebusd läuft auf dem gleichen Raspi. Beim abgleich habe ich jetzt festgestellt das in meiner ebusd config der Eintrag "--mqttjson" fehlte. Warum auch immer, denn die anderen MQTT Einträge hatte ich so drin stehen. Auf jeden Fall habe ich das jetzt ergänzt und nun funktiert das auch so wie es soll.
Sollte ich mir Gedanken machen das beim Rücklauf kein Wert angezeigt wird?
Viele Grüße Torsten
frag doch mal den Rücklauf mit ebusctl direkt ab ob er da vorhanden ist. Wenn der Rücklaufsensor defekt wäre, dann müsste die Therme auf Störung gehen, sonst wäre ja keine Steuerung nach der Heizkurve möglich und immer auf Vollgas laufen. Je größer die Differenz zwischen Vor und Rücklauf, desto mehr Leistung des Brenners wird ja eingestellt und umgekehrt.
Hätte ich eigentlich früher drauf kommen könnnen, das in deiner config was nicht stimmt, aber Hauptsache du hast es jetzt gefunden.
LG
Reinhart
Zitat von: Reinhart am 17 November 2020, 20:48:18
frag doch mal den Rücklauf mit ebusctl direkt ab ob er da vorhanden ist. Wenn der Rücklaufsensor defekt wäre, dann müsste die Therme auf Störung gehen, sonst wäre ja keine Steuerung nach der Heizkurve möglich und immer auf Vollgas laufen. Je größer die Differenz zwischen Vor und Rücklauf, desto mehr Leistung des Brenners wird ja eingestellt und umgekehrt.
Hallo Reinhard,
ich habe den test gemacht und es kommt dieses Ergebnis, die -13.50 bleiben auch konstant.
ebusctl r -f ReturnTemp
-13.50;215;cutoff
ebusctl r -f ReturnTempMax
0.00
ebusctl r -f expertlevelMain_ReturnTemp
-1.81;cutoff
Die Therme zeigt keine Störung an, und läuft m.E. auch normal. Es handelt sich um eine Öl-Brennwerttherme und ist mittlerweile fast 7 Jahre alt.
Aus eurer Erfahrung heraus, wäre es denkbar das die falsche CSV verwendet wird?
ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 171
min arbitration micros: 9
max arbitration micros: 698
min symbol latency: 0
max symbol latency: 30
reconnects: 0
masters: 3
messages: 483
conditional: 0
poll: 1
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0902;HW=7401", loaded "vaillant/bai.0010010674.inc" ([PROD='0010010676']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0348;HW=9502", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Viele Grüße Torsten
ich kenne das Gerät nicht und kann dir daher auch nicht sagen ob die 08.bai da korrekt ist.
LG
@blackmondeo: du fragst den falschen Wert ab ;)
...würde ich auch meinen, meine CSVs sind nicht mehr ganz aktuell, aber bei mir wird die Rücklauftemperatur mit
ebusctl r -f SDTRT
abgefragt...
Zitat von: cs-online am 20 November 2020, 19:33:40
...würde ich auch meinen, meine CSVs sind nicht mehr ganz aktuell, aber bei mir wird die Rücklauftemperatur mit
ebusctl r -f SDTRT
abgefragt...
Hallo,
das die Abfrage nicht korrekt ist das glaub ich ja, aber ich weiß halt nicht genau warum. Ich habe mir die csv heruntergeladen um zu schauen was dort zum Stichwort Rücklauf zu finden ist, nur leider komme ich so nicht an einen Wert.
SDTRT ist bei meiner Konfiguration nicht bekannt. Soweit ich das verstanden habe sucht der ebusd die passende bai und csv Datei. das scheint ja auch zu funktionieren. Kann man das manuell überprüfen ob die richtige Konfigurationsdatei gefunden wurde?
ebusctl r -f Returntemp
-13.50;215;cutoff
ebusctl r -f SDTRT
ERR: element not found
macht es Sinn in dem Fall in alten CSV Dateien zu stöbern um SDTRT zu finden?
...also bei meinen CSVs ist in der bai.0010010674.inc (Wie gesagt, meine sind schon etwas älter, kann sein, dass John das mal vereinheitlicht hat und deshalb nun nicht mehr SDTRT dort steht)
r,,SDTRT,d.41 Rücklauftemperatur,,,,"9800",,,tempmirrorsensor,,,Rücklauftemperatur
Also ist in meiner Therme unter D.41 die Rücklauftemperratur gespeichert. Nun könntest du in deiner Bedienungsanleitung mal schauen, ob das auch D.41 ist. Oder an der Therme selber mal schauen, was Rücklauftemperatur für ein D.xx ist. Dann vielleicht in deiner CSV schauen, was unter D.41 bzw. eben dem, was es bei deiner Therme ist, davor steht und damit solltest du dann passend die Rücklauftemperatur auslesen können, du kannst dann ja mal vergleichen, was deine Therme im Display ausgibt und was EBUSD ermittelt
Zitat von: cs-online am 21 November 2020, 07:44:17
Also ist in meiner Therme unter D.41 die Rücklauftemperratur gespeichert. Nun könntest du in deiner Bedienungsanleitung mal schauen, ob das auch D.41 ist. Oder an der Therme selber mal schauen, was Rücklauftemperatur für ein D.xx ist. Dann vielleicht in deiner CSV schauen, was unter D.41 bzw. eben dem, was es bei deiner Therme ist, davor steht und damit solltest du dann passend die Rücklauftemperatur auslesen können, du kannst dann ja mal vergleichen, was deine Therme im Display ausgibt und was EBUSD ermittelt
Hallo,
in der aktuellen Configurationsdatei steht d.41 als "ReturnTemp" drin. Soweit alles klar. Am Display meiner Therme bekomme ich die einzelnen Werte irgendwie nicht angezeigt. Aber beim stöbern in der Anleitung meiner Therme habe ich gesehen das der Rücklauftemperatursensor (als d.41) als optionales Zubehör erhältlich ist. Also habe ich aktuell gar keinen Sensor eingebaut. Damit hätte sich das auch geklärt.
Danke für die Hinweise.
hmm, eine Therme ohne Rücklauffühler ? Wie soll die denn regeln ohne Rücklauftemperatur ? Es kann sein, dass die Rücklauftemperatur nur in der 2. Diagnoseebene sichtbar ist, um dahin zu kommen muss ich z.B. bei meiner Therme auf D.97 (Aktivierung der 2. Diagnoseebene) gehen, Passwort für die Ebene ist 17, speichern, dann komm ich in die Werte, die in der "normalen" Ebene nicht angezeigt werden. Dann auf D.41 gehen, dann sollte dort auch ein Wert drin sein...
Grüße
Christian
Hallo zusammen,
ich hoffe es ist in Ordnung diesen Thread für mein Problem zu nutzen.
Ich habe eine Weishaupt WTC-15 Therme und nun nach drei Jahren die Ebus-Platine V2.0 mit einem Wemos in Betrieb genommen.
Nun zu meinem Problem, es werden nicht alle csv Dateien geladen:
ebusctl info
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 48
reconnects: 0
masters: 5
messages: 61
conditional: 0
poll: 0
update: 4
address 03: master #11
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=1200;HW=0302", loaded "kromschroeder/08..sc.csv"
address 30: master #3
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302"
Hier sollte an der address f6 noch eine csv geladen werden, macht er aber nicht... was mache ich falsch??
Zwei configs ausprobiert (lokal & http)
EBUSD_OPTS="--device=192.168.2.151:9999 --configlang=de --accesslevel=* --scanconfig --htmlpath=/var/ebusd/html --httpport=8889"
EBUSD_OPTS="--device=192.168.2.151:9999 --configlang=de --accesslevel=* --configpath=/etc/ebusd/ --scanconfig --htmlpath=/var/ebusd/html --httpport=8889"
Vielleicht kann mir ja jemand weiterhelfen ;)
VG
Dominique
Zitat von: znyde am 22 November 2020, 07:02:19
Ich habe eine Weishaupt WTC-15 Therme und nun nach drei Jahren die Ebus-Platine V2.0 mit einem Wemos in Betrieb genommen.
Nun zu meinem Problem, es werden nicht alle csv Dateien geladen:
ebusctl info
version: ebusd 3.4.v3.4-20-gedfe09a
update check: revision v3.4 available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 48
reconnects: 0
masters: 5
messages: 61
conditional: 0
poll: 0
update: 4
address 03: master #11
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=1200;HW=0302", loaded "kromschroeder/08..sc.csv"
address 30: master #3
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302"
Hier sollte an der address f6 noch eine csv geladen werden, macht er aber nicht... was mache ich falsch??
Zwei configs ausprobiert (lokal & http)
EBUSD_OPTS="--device=192.168.2.151:9999 --configlang=de --accesslevel=* --scanconfig --htmlpath=/var/ebusd/html --httpport=8889"
EBUSD_OPTS="--device=192.168.2.151:9999 --configlang=de --accesslevel=* --configpath=/etc/ebusd/ --scanconfig --htmlpath=/var/ebusd/html --httpport=8889"
auf dem webservice sind derzeit überhaupt keine Weishaupt/Kromschröder CSV hinterlegt, da diese nicht im github (https://github.com/john30/ebusd-configuration/tree/master/ebusd-2.1.x/de) gepflegt sind. D.h. wenn dann geht eh nur die lokale Variante und dort müsste dann entsprechend eine f6.csv liegen, damit diese geladen werden kann. Aber die Weishaupt Devices antworten nicht besonders sinnvoll auf die ID Abfrage, weswegen ich hier eh empfehlen würde, genau die CSVs lokal abzulegen, die für die Anlage benötigt werden und dann "--scanconfig" rauszunehmen.
Danke für deine Antwort John.
Das die csv´s nicht auf dem webservice sind hab ich mir schon fast gedacht.
Lokale config genutzt und nochmal ein restart durchgeführt und jetzt scheint es zu laufen..
Warum auch immer :D
wenigstens sehe ich den status einiger Daten,
Heizung ein und ausschalten wäre noch gut... muss ich mal schauen, weishaupt scheint ja nicht so vertreten zu sein
@csonline: habe alle bai's mal durchgesehen, ReturnTemp betrifft den externen Sensor, daher auch die Ausgabe "cut-off" ... vermutlich hat er sich eine bai.cfg "zusammengeklickt" wenn bei ihm d.41 dabei steht ...
@fhempi
r,,PrEnergySumHc1,PrEnergySumCH1_DK,,,,"F500",,,ULG,,,Wartungsdaten,,,,,,,,,,,,
stamt vom 20.05.2015, also sehr alt
Hallo,
kann mir jemand helfen? Ich kriege es ums verrecken nicht hin, dass ebusd die richtigen csv Dateien lädt. Weder übers web noch lokal (unter /etc/ebusd/). Wie bekomme ich raus, was da falsch läuft?
pi@Raspbi-ebus:/etc/ebusd/vaillant $ ebusctl i
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 44
max symbol rate: 75
reconnects: 0
masters: 3
messages: 13
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401"
address 10: master #2
address 15: slave #2
address 31: master #8, ebusd
address 36: slave #8, ebusd
@fhempi
Versuche auch Zähler über
read -f -c bai PrEnergyCountHc1\n\000read -f -c bai PrEnergyCountHwc1
herauszubekommen. Dann könnte man den Verbrauch Heizung/WW aufteilen.
Meine Summe weicht nur wenig ab, aber die Aufteilung könnte noch nicht korrekt sein. Dazu bräuchte ich über eine längere Zeit nur eine Verbrauchsart.
Hallo zusammen,
ich lese seit ein paar Tagen hier im Forum mit und bin begeistert was ihr alles so auf die Beine stellt.
Das hat den Entschluss reifen lassen meine Wärmepumpe ebenfalls an den Bus zu bekommen.
Kurz ein paar Sätze zu meiner Ausrüstung:
1) ich habe das Haus beim Neubau 2009 mit KNX ausgerüstet
2) Raspi 3 mit IOBroker vorhanden
3) Wärmepumpe:
- Bartl Grundwasserwärmepumpe mit TEM SE 6001 WPC (hängt leider noch nicht am Bus)
- ich habe mir damals das TEM ServiceTool ausgeliehen und mit diesem Adapter den eBus via serielle Schnittstelle an den Laptop angeschlossen um diverse Aufzeichnungen zu machen; aus Zeitmangel habe ich das dann nach ein paar Monaten und Optimierungsschleifen der WP nicht weiter verfolgt - jedoch liegt eine umfangreiche Dokumentation vor. Wenn das jemanden hilft bitte melden.
- meine WP soll via eBus-Adapter (USB oder besser Netzwerk) an den Raspi angeschlossen werden
Eigentlich wollte ich mir den Esera eBus Adapter zulegen, aber wahrscheinlich ist es besser auf den eBus Adapter 3 zu warten.
Diesen kann ich dann per Netzwerk an den Raspberry anschließen und mit dem entsprechenden eBus - Adapter im IOBroker meine Wärmepumpe auslesen - korrekt?
Was brauche ich ansonsten noch für die Daten?
Vielen Dank,
Gruß Ralf
Welche Daten brauche ich noch bzw. wie kann ich euch
Hallo zusammen,
ich habe mir die Raspi Platine in der Version 2.2 fertig gelötet und an meine Vailant Therme angeschlossen. A funktioniert auch alles soweit, ich kann Werte auslesen und auch bestimmte Werte schreiben. Allerdings wollte ich den Wert für die Raumtemperatur schreiben um die adaptive Heizkurve zu nutzen. Jetzt musste ich leider feststellen das man den Wert nur lesen kann.
Ich habe eine Vailant ecoTec exclusiv mit dem VRC700 in der Therme montiert. Ich möchte mir nicht einen Vailant Regler ins Wohnzimmer hängen, da ich in allen Räumen die Temperatur mit den MDT Glastastern 2 dezent meße.
Kann ich irgendwie eine VR91 simulieren und der VRC700 so die Raumtemperatur mitteilen?
Danke für eure Unterstützung
Hi @Ronny87
dein Vorhaben hätte ich jetzt so nicht aus deinem Post gelesen.
Ich muss auch dazu sagen, das ich nicht FHEM sondern Openhab nutze. Mit dem aktuellen Binding kann man schon die Nachrichten beliebiger Geräte senden aber ich denke hier fehlt noch die Möglichkeit, dass sich die jeweilige Instanz auch als ein solches Gerät identifizieren lässt von der Heizungsregelung.
Schöne Woche
Ich möchte gerne meine Kommunikation auf mqtt umstellen, da einige Register meiner Vaillant Therme mit Gaebus nicht mehr ausgelesen werden können.
Frage: Muss der ebusd Daemon hierfür auf die letzte Version aktualisiert werden? Ich kann derzeit nicht auf meinen Raspi schauen, meine aber das ich Version 3.3xxx am Laufen habe.
...soweit ich das in Erinnerung habe, muss auf jeden Fall eine Version mit MQTT-Unterstützung genommen werden, das ist scheinbar nicht in allen Versionen verfügbar...
Vielleicht liest John ja hier mit und kann etwas dazu sagen..
Hintergrund: Ich bin die nächsten Tage nicht zu Hause, kann aber über vpn auf dem FHEM Raspi arbeiten, das ist unkritisch.
Arbeiten am Raspi, der direkt an der Vaillant Heizung hängt, möchte ich aber nur machen wenn ich zu Hause bin, falls sich da was aufhängt am Vaillant Regler...
Von daher würde ich den nur ungern anfassen.
John hat ja auch fertig compilierte Versionen hier (https://github.com/john30/ebusd/releases) liegen.
Bitte vorher auf diesem Raspi die Lib "sudo apt install libmosquitto-dev" installieren.
wenn du schon git am Raspi installiert hast und auch ausgescheckt hast, genügt dann ein "git pull" mit anschl. "make install" und dann Dämon neu starten.
MQTT kannst auch parallel zu ECMD benutzen, dann hast du bei der Umstellung nicht soviel Streß. Benutze bitte MQTT2!
ach ja , und die config ändern.
Beispiel
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name --latency=20000 --address=01"
Ip Adressen anpassen.
LG
habe gestern ausgecheckt
Version:
ebusd 3.4.v3.4-20
LG
War auch meine Idee das parallel zu machen...
Bei dem Versuch die Lib zu installieren kommt folgende Meldung
pi@raspberrypi:~ $ sudo apt install libmosquitto-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libmosquitto1
The following NEW packages will be installed:
libmosquitto-dev libmosquitto1
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 87.7 kB of archives.
After this operation, 214 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Err:1 http://raspbian.raspberrypi.org/raspbian stretch/main armhf libmosquitto1 armhf 1.4.10-3+deb9u2
404 Not Found [IP: 93.93.128.193 80]
Err:2 http://raspbian.raspberrypi.org/raspbian stretch/main armhf libmosquitto-d ev armhf 1.4.10-3+deb9u2
404 Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/m/mosquitt o/libmosquitto1_1.4.10-3+deb9u2_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/m/mosquitt o/libmosquitto-dev_1.4.10-3+deb9u2_armhf.deb 404 Not Found [IP: 93.93.128.193 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-mis sing?
Sollte das noch passen?
ist geklärt...
Musste erst mal Stretch aktualisieren....
in meiner ebusd config steht derzeit folgendes:
EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"
Ich habe zwei ebus Adapter an einem Raspi, je an einem USB Port.
Die neuen sehen dann so aus?
EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.167.178.9 --mqtttopic=ebusd/%circuit/%name --address=01"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000 --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.167.178.9 --mqtttopic=ebusd/%circuit/%name --address=01"
Hi,
ich bin gestern auf das Thema hier mit dem ebus-Adapter gestossen und finde es sehr interessant! Ich habe schon länger mit dem Gedanken gespielt, meine Vaillant Gastherme "smart" zu machen und das hier scheint genau das zu sein wonach ich gesucht habe! :)
Im Wiki (des alten 1.x Adapters) steht folgender Disclaimer:
ZitatDie Verwendung des EBUS zur Ansteuerung eines Heizungssystems kann dieses bei unsachgemäßer Anwendung beschädigen. Für unmittelbare oder mittelbare Folgen, die sich aus dem Nachbau des Interfaces oder der Verwendung der hier zur Verfügung gestellten Information ergeben, übernimmt der Autor keine Haftung.
Kann jemand sagen was damit gemeint ist und vielleicht ein Beispiel geben?
Ist es möglich über die ebus-Schnittstelle Nachrichten zu verschicken, die meine Gastherme tatsächlich beschädigen könnten?
Sagen wir, ich habe einen perfekt funktionierenden Adapter und schliesse in korrekt an die ebus-Pins der Gastherme an. Was könnte schlimmstenfalls passieren?
Ich bin noch komplett neu auf dem Gebiet, also verzeiht mir meine Unwissenheit (oder tut es nicht, damit kann ich auch leben... ;) ).
LG,
schneeball
Moin
Und willkommen im Forum. Ich beschreibe mal kurz was passieren koennte.
Deine Hausautomatisierung (fhem, vorzugweise!) schreibt ueber den eBus Adapter wilde Werte auf die Heizung, die im schlimmsten FallDeine Heizung beschaedigen koennten. Hier waere jetzt eine viel zu hohe oder auch zu niedrige Temperatur das wahrscheinlichste Szenario. Inwieweit man aber wirklich die Werte so verstellen kann, das etwas passiert weiss ich nicht. Letztendlich ist man ja nur Teilnehmer auf dem Bus und kann Anhand der passenden CSV die richtigen Werte lesen und schreiben.Eine gewisse Unschaerfe bleibt natuerlich immer, weshalb man hier auch oft Fragen liest, ob man das Schreiben physisch unterbinden kann. Um jetzt nicht bewusst etwas falsch zu machen, sind viele Werte gar nicht von sich aus beschreibbar, und muessen in der CSV erst entsprechend freigegebne werden. (Trotzdem kann natuerlich irgendwelcher Muell auf der Datenleitung etwas anderes bewirken.)
Letztendlich hat sich der Autor des Artikels nur absichern wollen und klargestellt, dass das alles auf eigenen Gefahr geschieht!
Gruss Christoph
Habe eben das Update für den Daemon starten wollen mit
git clone https://github.com/john30/ebusd.git
Dann bekomme ich als Antwort:
pi@raspberrypi:~ $ git clone https://github.com/john30/ebusd.git
fatal: destination path 'ebusd' already exists and is not an empty directory.
Könnt ihr mir sagen was hier zu tun ist?
Ich möchte gerne das letzte release mit mqtt Unterstützung über die alte Version installieren.
Zitat von: pc1246 am 02 Dezember 2020, 07:59:51
Moin
Und willkommen im Forum. Ich beschreibe mal kurz was passieren koennte.
Deine Hausautomatisierung (fhem, vorzugweise!) schreibt ueber den eBus Adapter wilde Werte auf die Heizung, die im schlimmsten FallDeine Heizung beschaedigen koennten. Hier waere jetzt eine viel zu hohe oder auch zu niedrige Temperatur das wahrscheinlichste Szenario. Inwieweit man aber wirklich die Werte so verstellen kann, das etwas passiert weiss ich nicht. Letztendlich ist man ja nur Teilnehmer auf dem Bus und kann Anhand der passenden CSV die richtigen Werte lesen und schreiben.Eine gewisse Unschaerfe bleibt natuerlich immer, weshalb man hier auch oft Fragen liest, ob man das Schreiben physisch unterbinden kann. Um jetzt nicht bewusst etwas falsch zu machen, sind viele Werte gar nicht von sich aus beschreibbar, und muessen in der CSV erst entsprechend freigegebne werden. (Trotzdem kann natuerlich irgendwelcher Muell auf der Datenleitung etwas anderes bewirken.)
Letztendlich hat sich der Autor des Artikels nur absichern wollen und klargestellt, dass das alles auf eigenen Gefahr geschieht!
Gruss Christoph
Hey Christoph,
Danke für die Antwort! War auf jeden Fall schon mal aufschlussreich! :)
Hunderprozentig sicher kann man natürlich nie sein, aber so eine Schnittstelle wie der eBus muss ja schon von irgendwem getestet und abgenommen werden. Von daher hatte ich auch vermutet, dass man wahrscheinlich nicht allzu viel Schaden darüber anrichten kann. Naja, ich werde mich auf jeden Fall noch ein bisschen weiter in das Thema einlesen. Sehr spannend das ganze!
Bin einen Schritt weiter, jedoch habe ich noch das Problem, das ich nicht beide Instanzen meines ebusd gleichzeitig ans Laufen bekomme. Mit einer Instanz läuft es wie es soll.
Meine beiden Instanzen sind:
EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"
Also OPTS1 und OPTS2.
Ich werde nicht ganz schlau aus der Beschreibung in /etc/default/ebusd:
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Bedeutet dies, das ich die vorhandene ebusd.service Datei umbenenne in den angegebenen Namen ebusd-2.service?
Und den Inhalt darin ändere?
type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
Die Zeile mit Environment startend löschen -> OK
Aber wie muss die Zeile danach aussehen?
Zitat von: theotherhalf am 03 Dezember 2020, 11:28:32
Bin einen Schritt weiter, jedoch habe ich noch das Problem, das ich nicht beide Instanzen meines ebusd gleichzeitig ans Laufen bekomme. Mit einer Instanz läuft es wie es soll.
Meine beiden Instanzen sind:
EBUSD_OPTS1="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.4:1.0-port0 -p 8888 -l /var/log/ebusd1.log --latency=20000 --receivetimeout=50000"
EBUSD_OPTS2="--scanconfig -d /dev/serial/by-path/platform-20980000.usb-usb-0:1.5:1.0-port0 -p 8889 -l /var/log/ebusd2.log --latency=20000 --receivetimeout=50000"
Also OPTS1 und OPTS2.
Ich werde nicht ganz schlau aus der Beschreibung in /etc/default/ebusd:
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Bedeutet dies, das ich die vorhandene ebusd.service Datei umbenenne in den angegebenen Namen ebusd-2.service?
Und den Inhalt darin ändere?
type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
Die Zeile mit Environment startend löschen -> OK
Aber wie muss die Zeile danach aussehen?
genau, auf einem systemd basierten System muss man /usr/lib/systemd/system/ebusd.service "clonen" und dann entsprechend darin direkt die richtigen Optionen an die Zeile mit "ExecStart=..." hinhängen (und "$EBUSD_OPTS" rauswerfen) oder darin "$EBUSD_OPTS" durch das entsprechende aus dem /etc/default/ebusd ersetzen (also bspw. "$EBUSD_OPTS2").
Hallo,
ich interessiere mich auch dafür, meine ecoTEC plus in fhem einzubinden. Mich bewegt aber noch folgende Frage: Aktuell steuere ich die Therme über eine calorMATIC 470f, also über Funk (868 MHz), sehe dort die aktuellen Temperaturwerte, kann Kalendereinträge zu Anwesenheits- /Abwesenheitstagen machen usw. Also Zugriff auf alles, was mich in fhem auch interessieren würde. Natürlich könnte ich jetzt auch ein eBUS-Interface an meinen Raspberry anbauen, aber ist das zwingend nötig? Einen CUL für 868 Mhz hätte ich ja schon...
Hat sich schon mal jemand mit der Frage beschäftigt, ob man die bestehende Funkverbindung in fhem mitnutzen kann? Oder ist das eBUS-Interface die einzige Option?
Gruß
beaune
Hallo Forum,
ich habe in den letzten Tagen meinen V1.6 Adapter zum Laufen gebracht (https://forum.fhem.de/index.php/topic,46098.msg1112004.html#msg1112004). Reinhart, Dir nochmals ein Dankeschön für Deine Hilfe. Jetzt geht es bei mir mit den Softwarefragen hier in diesem Thread weiter.
Als Grundlage arbeite ich mit den Weishaupt-Konfigurationsdateien, die das Mitglied J0EK3R zur Verfügung gestellt hat (https://github.com/J0EK3R/ebusd-configuration-weishaupt).
Zum Einen gibt es darunter CSV-Dateien, die zwar gesendete Nachrichten erkennen, diese aber, zumindest in meinem Fall, nicht immer richtig dekodieren. In den meisten Fällen liegt das an den verwendeten Datentypen bzw. Templates.
Zum Anderen gibt es Nachrichten, die noch nicht erkannt werden, weil ich eine andere Anlagenkonfiguration habe.
Für den ersten Fall, also um die Telegramme zu entziffern, suche ich nach einer Möglichkeit, ein
ebusctl grab result decode für ein anzugebendes Telegramm oder Teile davon aufzurufen. Etwa so:
ebusctl "fff65000054573b413a5 / 0b002f00000000000000cf00" decodeoder gar
ebusctl "0b002f00000000000000cf00" decodeGeht das mit ebusctl?
Ich habe
ebusctl define und
ebusctl decode gesehen. Wenn diese Befehle dazu dienen sollen, dann habe ich nicht verstanden, wie. Sorry.
Zur Definition von Templates steht in der Doku (https://github.com/john30/ebusd/wiki/4.4.-Field-templates):
Zitat von: ebusd WIKI 4.4 Field templates[DIVIDER/VALUES]: either a DIVIDER or VALUE=NAME[;VALUE=NAME]*
The divider to apply on the numeric base type or a list of name/value associations separated by semicolon (value either in decimal or starting with "0x" for hex).
DIVIDER wird mit Trenner übersetzt. Deshalb habe ich einen anzugebenden Feldtrenner vermutet. Tatsächlich ist in diesem Feld ein "DIVISOR" anzugeben, der auf den Wert in der zuvor angegebenen Variablen angewendet werden wird.
Bei Abfragen über die Kommandozeile bekomme ich zu einigen Datenelementen diese Fehlermeldungen:
ERR: SYN received,
ERR: wrong symbol received und
ERR: read timeoutAndere gehen einwandfrei durch. (Info: der daemon läuft gleichzeitig im Hintergrund und füllt die Datenbank)
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416799;29;-;25
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic3
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic3
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r datetime
5.000;14:07:-;28.12.2020
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic1
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416799;29;-;25
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic6
0;0;223;145;16;0;0;40448;0;0;0;0
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic5
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: wrong symbol received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: read timeout
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic4
ERR: read timeout
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic6
0;0;224;145;16;0;0;40448;0;0;0;0
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic7
0;31;109;0;11416800;29;-;25
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r statistic2
ERR: SYN received
Das Log dazu:
2020-12-28 14:05:49.666 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:49.866 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:50.066 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:50.265 [bus error] send to 08: ERR: SYN received
2020-12-28 14:05:50.266 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:05:55.354 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:05:55.509 [bus error] send to 08: ERR: CRC error, retry
2020-12-28 14:05:55.713 [bus error] send to 08: ERR: CRC error, retry
2020-12-28 14:05:55.975 [bus error] send to 08: ERR: SYN received
2020-12-28 14:05:55.976 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:06:00.187 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.395 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.634 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:00.832 [bus error] send to 08: ERR: SYN received
2020-12-28 14:06:00.832 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:06:06.124 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;49.50;-;-;35.0;-
2020-12-28 14:06:12.542 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;1;1;0;1;Heating;58;48.0;-;40.0;0.0;4;3.270;49
2020-12-28 14:06:14.929 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 0600043028313a
2020-12-28 14:06:25.285 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.486 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.685 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:06:25.885 [bus error] send to 08: ERR: SYN received
2020-12-28 14:06:25.885 [bus error] send message part 0: ERR: SYN received
2020-12-28 14:07:13.164 [bus error] send to 08: ERR: wrong symbol received, retry
2020-12-28 14:07:13.332 [bus error] send to 08: ERR: read timeout, retry
2020-12-28 14:07:13.496 [bus error] send to 08: ERR: wrong symbol received, retry
2020-12-28 14:07:13.660 [bus error] send to 08: ERR: read timeout
2020-12-28 14:07:13.660 [bus error] send message part 0: ERR: read timeout
2020-12-28 14:17:56.879 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.093 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.292 [bus error] send to 08: ERR: SYN received, retry
2020-12-28 14:17:57.492 [bus error] send to 08: ERR: SYN received
2020-12-28 14:17:57.492 [bus error] send message part 0: ERR: SYN received
Ich hatte solche Abfragen unter den gleichen Bedingungen schon erfolgreich durchgeführt. Am System wurde zwischenzeitlich nichts verändert.
Danke für Tipps.
Gruß,
Jochen
Hallo,
ich habe eine Vaillant mit:
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0311;HW=9602", loaded "vaillant/bai.0010015600.inc" ([HW=9602]), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
alles neu aufgesetzt.
Ich habe mich über die neuen PrFuels* gefreut.
Leider werden die Werte der PrFuelSum, -SumHc und SumHwc nur 24stündlich aktualisiert.
Ist das so?
Kann man die Anlage ermuntern, stündlich upzudaten?
Und sind das reale physikalische Werte oder nur ge-time-te Zähler?
Gruss
Christoph
hallo wieder mal!
eine neue idee wirft leider ein neues kleines problem auf.
meine 08.hmu übertragt über das hcmode.inc file im Status01
(Status01r,,Status01,Vorlauftemperatur/Rücklauftemperatur/Aussentemperatur/WW Temperatur/Speichertemperatur/Pumpenstatus,,,,01,,,temp1;temp1;temp2;temp1;temp1;pumpstate,,,)
die werte Aussentemperatur/WW Temperatur/Speichertemperatur nicht:
pi@raspberrypi:~ $ ebusctl -p 8888 read status01
47.5;40.0;-;-;-;off
das müsste ich wohl adaptieren komme aber mit den werten aus den hex daten nicht klar.
der grab auf der 08 adresse ergibt nur diese paar werte die das system nicht kennt:
pi@raspberrypi:~ $ ebusctl -p 8888 grab result
1008b507010a / 03768207 = 34
1008b5110100 / 09f302ff000000008100 = 1816
3108b507010a / 03708207 = 5
3108b5110100 / 098002ffc80a090081c8 = 10
1008b507020900 / 023802 = 691
1008b50702093f / 02a601 = 18
1008b507020940 / 026801 = 96
1008b507020941 / 026301 = 80
1008b507020942 / 025d01 = 121
1008b507020943 / 025a01 = 673
1008b507020944 / 025d01 = 243
1008b5120204ff / 0101 = 366
1008b513020528 / 0101 = 368
bitte um eure hilfe!
die mit den 02xxxx sind wohl temperatur werte.
aktuell sind es aber minus grade, wo findet man diese?
und wo ist der systemdruck versteckt? ::)
mit dem decode befehl komme ich leider auch nicht weiter.
Zitat von: beaune am 16 Dezember 2020, 11:47:33
Hat sich schon mal jemand mit der Frage beschäftigt, ob man die bestehende Funkverbindung in fhem mitnutzen kann? Oder ist das eBUS-Interface die einzige Option?
dazu müsste jemand das Protokoll hacken (viel Spaß dabei ::)). Nachdem aber immer eine physische eBUS Leitung da ist, ist die Nutzung dieser viel einfacher
Zitat von: metserver1 am 28 Dezember 2020, 14:54:25
Für den ersten Fall, also um die Telegramme zu entziffern, suche ich nach einer Möglichkeit, ein ebusctl grab result decode für ein anzugebendes Telegramm oder Teile davon aufzurufen. Etwa so:
ebusctl "fff65000054573b413a5 / 0b002f00000000000000cf00" decode
das geht laut Hilfetext wie folgt:
ebusctl help decode
usage: decode [-v|-V] [-n|-N] DEFINITION DD[DD]*
Decode field(s) by definition and hex data.
-v increase verbosity (include names/units/comments)
-V be very verbose (include names, units, and comments)
-n use numeric value of value=name pairs
-N use numeric and named value of value=name pairs
DEFINITION field definition (type,divisor/values,unit,comment,...)
DD data byte(s) to decodeAlso brauchst Du die Felddefinition (nicht die Def. der ganzen Message!) und die entsprechenden Datenbytes, z.B.:
decode "d2b" 002f
47.000Möglicherweise suchst Du aber auch nach dem hier:
ebusctl grab result decode
Zitat von: chri123 am 07 Januar 2021, 20:31:59
Leider werden die Werte der PrFuelSum, -SumHc und SumHwc nur 24stündlich aktualisiert.
Ist das so?
Kann man die Anlage ermuntern, stündlich upzudaten?
du kannst das Polling Feature von ebusd verwenden oder einfach via cronjob so oft du magst ein read auslösen, z.B. mit
ebusctl read FuelSumHcThisMonthZitat von: chri123 am 07 Januar 2021, 20:31:59
Und sind das reale physikalische Werte oder nur ge-time-te Zähler?
no idea
Prost Neujahr und danke für Deine Rückmeldung.
Zitat von: john30 am 10 Januar 2021, 10:22:38
Möglicherweise suchst Du aber auch nach dem hier:
ebusctl grab result decode
Nein, das Kommando war ja Ausgangspunkt meiner Frage. Mein Problem damit ist, dass man damit mit Decodierungen ALLER noch ungelösten Nachrichten zugeworfen wird. Das kann sehr unübersichtlich sein.
Dein Vorschlag
Zitat von: john30 am 10 Januar 2021, 10:22:38
decode "d2b" 002f
47.000
hilft nur weiter, wenn man die Lösung - hier "d2b" - schon hat. DEFINITION ist ja genau das Element, was ich nicht habe. Nach meinem Verständnis muss man in Fleißarbeit alle verfügbaren Datentypen/Templates durchprobieren um zu sehen, was passen könnte.
Ich könnte mir folgenden Ablauf als praktisch vorstellen:
ebusctl grab result
um zu sehen, welche ungelösten Nachrichten es noch gibt. Aus der Auflistung sucht man sich eine Nachricht aus und lässt sie dekodieren.
Beispielsweise so:
ebusctl decode "fff65000054573b413a5 / 0b002f00000000000000cf00"
Hierbei greift decode auf alle Standard-Datentypen - und wünschenswert - auf alle definierten Templates zurück und listet die entsprechenden Vorschläge auf. Im Prinzip - ich wiederhole mich - wie ein um Templates erweitertes
ebusctl grab result decode
aber nur
für eine einzige angebbare Nachricht oder einen Teil davon.
Gruß,
Jochen
Zitat von: john30 am 10 Januar 2021, 11:41:14
du kannst das Polling Feature von ebusd verwenden oder einfach via cronjob so oft du magst ein read auslösen, z.B. mit
ebusctl read FuelSumHcThisMonth
Ja, das mach ich sowieso, sogar mit -f (forza!)...
Scheint wohl nicht implementiert zu sein.
Gruss
Christoph
Zum Thema realer Verbrauch: nach 2 Wochen mitschreiben und relativ konstantem Verbrauch (ca 30m³/d) zeigt der PrFuelSum 290 Dingsda/d. Kann aber erst korrelieren, wenn der Verbrauch mal etwas schwankt.
Zitat von: john30 am 10 Januar 2021, 11:41:14
du kannst das Polling Feature von ebusd verwenden oder einfach via cronjob so oft du magst ein read auslösen, z.B. mit
Ich habe das Wiki nochmal durchgelesen, bin aber nicht sicher, wie das Polling genau funktioniert:
Welche Parameter werden gepollt und wo steht das drin?
Kann man zB PrFuelSum einmal am Tag pollen und speichern und zB die relevanten Temperaturen alle 3 Minuten?
Ich habe --pollinterval=180 in den EBUSD_OPTS stehen, die Webpage server:8888/data zeigt aber beim Vergleich des lastup: Feldes eine Differenz von 5 Minuten. Habe ich etwas übersehen?
Ich lasse mehrere Cronjobs laufen, die den ebusd abfragen und speichere die Antworten per MQTT in eine Datenbank. Konfiguration des ebusd läuft über Autoconfig.
Gruss
Christoph
ZitatNach meinem Verständnis muss man in Fleißarbeit alle verfügbaren Datentypen/Templates durchprobieren um zu sehen, was passen könnte.
Ja, ich denke so ist es ... und man muss evtl. auch Datentypen anpassen, wenn gar nichts passt.
Ich habe meine Weishaupt-Config auf basis der Vorarbeit von Jok3r etwas erweitert. Bei Bedarf kann ich sie gerne einmal rüberschmeissen. Vollständig ist die aber auch nicht. Ich habe irgendwann aufgehört, da meine Anforderungen alle damit erfüllt werden konnten.
Hallo,
ich hoffe hier kann mir geholfen werden ;)
Ich habe mich zuletzt in die ganze ebus Thematik hereingefuchst, da ich gerne einige Werte aus Heizung und Lüftung haben möchte.
Ich habe meine Vaillant Heizung (Flexotherm VWF 57/4) via eBus über den eBUS Koppler Ethernet von esera im Netzwerk und nutze auf einem Raspberry 4 ebusd. Das habe ich soweit nun auch alles ans laufen bekommen und er zieht sich die richtigen Config-Files und gibt die Daten via MQTT weiter.
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
update check: revision v3.4 available, vaillant/hcmode.inc: different version available
signal: acquired
symbol rate: 42
max symbol rate: 128
min arbitration micros: 27
max arbitration micros: 377
min symbol latency: 9
max symbol latency: 28
reconnects: 0
masters: 4
messages: 481
conditional: 0
poll: 0
update: 10
address 01: master #6, ebusd
address 03: master #11
address 06: slave #6, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=72000;SW=0118;HW=7703", loaded "vaillant/15.720.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
Nun habe ich neben der Heizung noch eine Lüftung der Fa. Wolf - Wolf CWL 300 excellent.
Sobald ich diese jedoch mit an den eBus anschließe, funktioniert es nicht mehr richtig. Er erkennt zwar, dass die CWL300 angeschlossen wurde, aber findet dann die Vaillant 720 nicht mehr.
pi@raspberrypi:~ $ ebusctl info
version: ebusd 3.4.v3.3-51-g57eae05
signal: acquired
symbol rate: 51
max symbol rate: 80
min arbitration micros: 23
max arbitration micros: 107
min symbol latency: 9
max symbol latency: 237
reconnects: 0
masters: 4
messages: 64
conditional: 0
poll: 0
update: 10
address 01: master #6, ebusd
address 03: master #11
address 06: slave #6, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 37: master #18
address 3c: slave #18, scanned "MF=ENCON;ID= ;SW=-;HW=-"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
pi@raspberrypi:~ $ ebusctl scan result
08;Vaillant;HMU00;0307;0403;21;19;34;0010016420;0001;005288;N6
3c;ENCON; ;-;-;??;??;??
76;Vaillant;VWZ00;0307;0403
An Einstellungen verwende ich nachfolgende:
EBUSD_OPTS="-d 192.168.178.50:5007 --mqtthost=127.0.0.1 --mqttport=1883 --mqttjson --scanconfig=full --configpath=/etc/ebusd --address=01"
Ich hab nun schon überall geschaut ob ich eine Lösung finde, aber habe nichts passendes gefunden. Jemand eine Idee woran das liegen kann oder was ich umstellen muss?
Vielen Dank :)
MFG
...nur dass ich das richtig verstehe, du hast beide Geräte an nur einem EBUS-Adapter angeschlossen ? Also beide Busse parallel gleichzeitig ?
Grüße
Christian
Genau, korrekt.
Ist das beim ebus nicht möglich?
vermutlich nicht... soweit ich weiß (aber ich lass mich gerne eines besseren belehren) geht das nicht und sicherlich nicht, wenn es sich auch noch um zwei verschiedene Hersteller geht....
Zitat von: chri123 am 21 Januar 2021, 23:32:45
Ich habe das Wiki nochmal durchgelesen, bin aber nicht sicher, wie das Polling genau funktioniert:
Welche Parameter werden gepollt und wo steht das drin?
Kann man zB PrFuelSum einmal am Tag pollen und speichern und zB die relevanten Temperaturen alle 3 Minuten?
Ich habe --pollinterval=180 in den EBUSD_OPTS stehen, die Webpage server:8888/data zeigt aber beim Vergleich des lastup: Feldes eine Differenz von 5 Minuten. Habe ich etwas übersehen?
ob ein Parameter gepollt wird, steht in der Definition (https://github.com/john30/ebusd/wiki/4.1.-Message-definition#message-definition). Das ist die Ziffer 1-9 als Priorität hinter dem "r"=read der ersten Spalte.
Das kann auch zur Laufzeit z.B. mit
ebusctl read -p 1 ... geändert werden.
Genauen Einfluss darauf, wann am Ende wirklich der Poll gemacht wird, hat man durch die Prioritäten nicht. Man kann nur festlegen, was einem wichtiger oder weniger wichtig ist.
Wenn Pollinterval auf 1 Minute steht und es gibt 10 Nachrichten derselben Priorität (und sonst keine), wird 1x pro Minute 1 dieser 10 Nachrichten gepollt. Dementsprechend ist der Zyklus nach 10 Minuten durch und es geht von vorne los.
D.h. in diesem Fall hat jede Nachricht ein Alter von 9 bis 10 Minuten, ergo würde die Abfrage mittels
ebusctl r ... nie aus dem Cache beantwortet werden können, nur mit
ebusctl r -m 600 ...
Zitat von: baumhous3 am 23 Januar 2021, 19:09:10
Genau, korrekt.
Ist das beim ebus nicht möglich?
Das ist schon möglich, aber heikel und würde ich bei 2 unterschiedlichen Herstellern auf gar keinen Fall empfehlen. Selbst beim gleichen Hersteller ist das ein zweischneidiges Schwert und geht sowieso nur, wenn auf beiden Bussen alle Geräte unterschiedliche Adressen haben (was oft nicht der Fall ist). Zudem schließt man damit zwei Stromquellen kurz. Das kann wirklich arg in die Hose gehen und ich würde es tunlichst lassen. Ich selbst habe 3 Vaillant Busse und mich nie getraut, die zusammen zu klemmen. Bei zweien ginge es allein schon nicht wegen der Adresskollisiion.
Zitat von: metserver1 am 10 Januar 2021, 15:02:45
ebusctl grab result decode
aber nur für eine einzige angebbare Nachricht oder einen Teil davon.
ab der nächsten Version (bzw. mit eigenem Compilat) geht
ebusctl grab result decode all
Zitat von: john30 am 24 Januar 2021, 09:04:57
Das ist schon möglich, aber heikel und würde ich bei 2 unterschiedlichen Herstellern auf gar keinen Fall empfehlen...
Okay, danke für die Infos. Wieder was dazu gelernt.
Ich hatte den Adapter 3 ohnehin schon reserviert. Dann werden ich wenn ich dort an der Reihe bin diese nehmen für die Lüftung und beides getrennt aufbauen.
Danke :)
Hallo an das Forum!
Ich bin seit einem Monat dabei mich und Teile meines Hause smart zu machen.
Bei der suche nach Unterstützung für den ebus bin ich auf dieses Forum gestoßen, in welchem ein sehr angenehmer Ton vorherrschend ist. Das finde ich Klasse.
Zu meinem Problem:
Ich habe eine Vaillant-Gasheizung VC206 mit Regelung calormatic 470/3.
Über eine ESERA USB ebus-Adapter möchte ich die Heizung über einen RaspberryPi4 auslesen.
Die dev vom ebusd Orange mit MQTT habe ich installiert:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.1.v21.1
update check: version 3.4 available
signal: acquired
symbol rate: 23
max symbol rate: 145
min arbitration micros: 585
max arbitration micros: 9640
min symbol latency: 0
max symbol latency: 23
reconnects: 0
masters: 3
messages: 462
conditional: 3
poll: 1
update: 9
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0604;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=47000;SW=0348;HW=9502", loaded "vaillant/15.470.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Ich bekomme aber nur diese Daten zurück:
pi@raspberrypi:~ $ ebusctl find -d
470 YieldThisYear = 0;0;0;0;0;0;0;0;0;0;0;0
bai DateTime = valid;14:42:13;25.01.2021;0.562
bai SetMode = auto;79.0;-;-;0;0;0;0;0;0
bai Status01 = 47.5;42.5;0.562;-;51.5;on
bai Status02 = auto;60;65.0;70;70.0
broadcast outsidetemp = 0.562
broadcast vdatetime = 14:41:33;25.01.2021
scan.08 = Vaillant;BAI00;0604;5502
scan.08 id = 21;13;50;0010011642;0001;010937;N7
scan.15 = Vaillant;47000;0348;9502
scan.15 id = 21;13;40;0020171208;0082;028014;N8
Meine Neulings-Fragen, bei denen ich etwas auf dem Schlauch stehe und Tipps brauche:
Wie bekomme ich mehr Daten über den ebus, sind das die richtigen csv-Dateien für meine Heizung?
Wie schalte ich MQTT im Hintergrund scharf?
Ich benutze die Standard-Config dieser Installation, muß ich diese ändern?
Wenn ich es richtig verstanden habe, muß ich sobald ich Änderung machen will eine Copy im (noch nicht vorhandenen) Verzeichnis ebusd anlegen und mit make und make compile meine eigene Version auf dem RSP erzeugen.
Daran kann ich dann meine Änderungen machen...
Welche Infos braucht ihr noch?
Danke
Jens
Hallo,
ja das sieht ja schon gut aus und die csv werden geladen. Von sich aus werden nur Broadcast übertragen, den Rest musst du entscheiden was du brauchst und wann du die Daten holen willst. Schau dir dazu die zahlreichen Beiträge über ECMD oder MQTT2 (https://wiki.fhem.de/wiki/EBUS-MQTT2)an. Da du offensichtlich Neueinsteiger auf diesem Gebiet bist, kannst du auch GAEBUS (https://forum.fhem.de/index.php/topic,41064.0.html) nehmen das geht einfacher zu konfigurieren.
LG
Danke Rainhart für den Check und die Info mit dem Broadcast.
Deine weiteren Tipps sind, wenn ich es richtig gelesen habe, für FHEM-Nutzer.
Ich muß mich outen, ich teste zur Zeit IOBroker...
Bei mir läuft schon einiges: Shellys mit Original-SW, D1miniPro und SonOffs mit Tasmota über MQTT.
Nur beim ebus tue ich mich schwer!
Prinzipiell sollte es aber auf ebusd-Ebene im Raspberry gleich sein.
Wo werden denn die weiteren Daten und die Abrufintervalle vereinbart, noch auf dieser Ebene oder im FHEM/IOBroker?
Ich benutze die Standard-Config in /etc/default/ebusd dieser Installation, muß ich diese ändern?
EBUSD_OPTS="--scanconfig"
Für MQTT muß ich ja auch noch die IP und die Zugangsdaten irgendwo hinterlegen?
Danke
Jens
ja die config musst du auf jeden Fall anpassen und eine Version von ebusd nehmen der für MQTT compiliert worden ist, bzw. selber complilieren. Lies bitte dazu das Wiki von John da ist das beschrieben wie du das compilieren musst (https://github.com/john30/ebusd/wiki/1.-Build-and-install).
hier ein Beispiel was man bei MQTT alles für Parameter in der config setzen muss:
EBUSD_OPTS="-d /dev/ttyebus -p 8888 -l /var/log/ebusd.log --scanconfig --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name --latency=20000 --address=01"
Die Abrufintervalle musst du hinterlegen, hier ein Beispiel wie ich so einen Timer setze:
+*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
ebusMQTT ist hier der MQTT Device des Servers (in deinem Fall der MQTT Broker) und die 5 Messwerte werden mit "publish und /get (https://github.com/john30/ebusd/wiki/3.3.-MQTT-client)" abgeholt.
Es ist eigentlich egal ob du mit IOBroker oder Fhem arbeitest, MQTT bleibt MQTT und ist ein definiertes Protokoll.
Aber du wirst schon gesehen haben, es gibt bei diesem Thema einiges wo du dich einlesen musst, das waren jetzt nur ein paar grundlegende Dinge.
LG
Thema Polling
Zitat von: john30 am 24 Januar 2021, 09:01:34
ob ein Parameter gepollt wird, steht in der Definition (https://github.com/john30/ebusd/wiki/4.1.-Message-definition#message-definition). Das ist die Ziffer 1-9 als Priorität hinter dem "r"=read der ersten Spalte.
Das kann auch zur Laufzeit z.B. mit ebusctl read -p 1 ... geändert werden.
Genauen Einfluss darauf, wann am Ende wirklich der Poll gemacht wird, hat man durch die Prioritäten nicht. Man kann nur festlegen, was einem wichtiger oder weniger wichtig ist.
Wenn Pollinterval auf 1 Minute steht und es gibt 10 Nachrichten derselben Priorität (und sonst keine), wird 1x pro Minute 1 dieser 10 Nachrichten gepollt. Dementsprechend ist der Zyklus nach 10 Minuten durch und es geht von vorne los.
D.h. in diesem Fall hat jede Nachricht ein Alter von 9 bis 10 Minuten, ergo würde die Abfrage mittels ebusctl r ... nie aus dem Cache beantwortet werden können, nur mit ebusctl r -m 600 ...
Oha, ich dachte, nach dem Pollintervall werden ALLE Parameter mit Prio-Nummer gelesen.
Das heisst, ich schreibe in die CSV-Dateien, die ebusd (ebusctl info)erkennt, eine Prio-Nummer meiner Wahl und das wird dann gepollt. Was passiert dann nach einem Update der Dateien, die der ebusd ja auch anstösst?
Oder kann ich eine Datei erzeugen, die quasi als Master die Definitionen immer wieder überschreibt?
Wieviel Traffic kann denn so eine Vaillant Steuerung "ertragen"?
Gruss
Christoph
Zitat von: chri123 am 26 Januar 2021, 22:47:16
Das heisst, ich schreibe in die CSV-Dateien, die ebusd (ebusctl info)erkennt, eine Prio-Nummer meiner Wahl und das wird dann gepollt. Was passiert dann nach einem Update der Dateien, die der ebusd ja auch anstösst?
Wenn das in den Files steht, dann bleibts über Neustart hinaus natürlich erhalten. Wenn Du über den Webservice die Configs beziehst, dann geht das verloren. Aber mit dem Config Editor, an dem ich gerade arbeite, lässt sich das dann persistieren.
Zitat von: chri123 am 26 Januar 2021, 22:47:16
Oder kann ich eine Datei erzeugen, die quasi als Master die Definitionen immer wieder überschreibt?
das wäre dann einfach ein lokaler clone vom ebusd-config repo.
Zitat von: chri123 am 26 Januar 2021, 22:47:16
Wieviel Traffic kann denn so eine Vaillant Steuerung "ertragen"?
das kannst du im Prinzip austesten. Solange die Regelung davon nicht beeinträchtigt wird, kannst Du das pollinterval reduzieren. Das Minimum liegt bei einer Sekunde und ebusd pollt natürlich nur, wenn der Bus gerade frei ist.
Hallo, ich habe meinen wlan Adapter auf Version 3 upgedatet, ebenso auf dem Raspi auf V3.1. Jetzt habe ich folgende Probleme und stehe komplett auf dem Schlauch:
- Ebusd startet nicht mehr automatisch obwohl ich die Befehle aus der Anleitung ausgeführt habe (hoffe ich)
- vorher konnte ich mit "ebusd/HwcOPMode/get" und "ebusd/HwcOPMode/set" den Betriebsmodus Warmwasserkreis lesen/setzen. Dies funktioniert jetzt nicht mehr. Das Topic hat sich scheinbar auch auf ebusd/bai/ geändert. Ich habe hier gesehen, dass man den HwcOPMode an die VRC430 Steuerung mit ebusd/430/HwcOPMode schicken kann, aber auch dies ergibt keine Antwort.
Das Scanresult ist:
08;Vaillant;BAI00;0516;7401;;;;;;;
15;Vaillant;43000;0215;2002;21;08;41;0020028515;0907;008196;N2
- update auf Version 3.4 wird angeraten, aber wie?
Vielen Dank für Eure Hilfe!
Grüße,
Thomas
was hast du denn für einen Adapter, V3 oder V2?
ich habe gerade mit meinem Adapter V3 folgendes getestet:
set ebusMQTT publish ebusd/430/HwcOPMode/get
und erhalte "auto", also ok
ebusd_430_HwcOPMode {"0": {"name": "", "value": "auto"}} 2021-02-07 18:30:27
Die Topic selbst habe ich in der Config so eingestellt
--mqtttopic=ebusd/%circuit/%name
Übrigens, der HwcOPMode wird auch im Staus02 (bai) als erster Wert übertragen!
LG
Hallo,
ich habe den V2 Adapter mit Wifi Extension.
in Node-RED schreibe ich:
ebusd/430/HwcOPMode/get
Nutzdaten sind dabei leer, so war es bisher.
und bekomme als Antwort:
ebusd/430/HwcOPMode/get : msg.payload : string[0]""
bzw ist das wohl das Echo meiner Nachricht im debugger. Ich bekomme also keine Antwort.
im logfile steht:
2021-02-07 22:06:50.684 [mqtt error] read message 430 HwcOPMode not found
2021-02-07 22:06:58.378 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:06.538 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:14.698 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:22.858 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:31.018 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:39.178 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
2021-02-07 22:07:47.338 [bus error] unable to open 192.168.11.13:8889: ERR: generic I/O error
Grüße
hast du schon mit ebusctl in der Console getestet ob da was kommt?
pi@eBus:~ $ ebusctl r -f HwcOPMode
auto
LG
es geht jetzt wieder :D
Es lag wohl an dem Parameter
--mqtttopic=ebusd/%circuit/%name
diesen hatte ich nicht mit angegeben.
Bleibt noch das Problem mit dem Autostart von ebusd wenn der Raspi neu startet.
Vielen Dank!
eigentlich sollte der Start mit "sudo make install" in der /etc/systemd eingetragen worden sein. Schau doch einfach ob du dort die Datei "ebusd.service" mit folgendem Inhalt findest.
[Unit]
Description=ebusd, the daemon for communication with eBUS heating systems.
After=network-online.target
ConditionPathExists=/var/log
[Service]
Type=forking
Restart=always
RestartSec=30
PIDFile=/var/run/ebusd.pid
EnvironmentFile=-/etc/default/ebusd
ExecStart=/usr/bin/ebusd $EBUSD_OPTS
[Install]
WantedBy=multi-user.target
ansonsten schau hier (https://www.elektronik-kompendium.de/sites/raspberry-pi/2002211.htm).
LG
Danke! Anscheined hab ich das damals falsch installiert gehabt! Jetzt klappt es.
Vielleicht noch ein Hinweis für nicht Linux Kenner... Wenn man der Anleitung https://github.com/john30/ebusd/wiki/1.-Build-and-install (https://github.com/john30/ebusd/wiki/1.-Build-and-install) von John30 folgt, muss man vor ./autogen.sh noch
sudo apt-get install libmosquitto-dev
ausführen, sonst wird es ohne MQTT Support installiert. Steht ja da, kann man aber überlesen.
LG,
Thomas
Hallo, ich habe eine einfache Vaillant Heizung mit CalorMatic 430 und such mir grad einen Wolf wie ich die Heizungsraumtemperatur im Automaticbetrieb ändern kann.
Im Manuellen Betrieb geht das mit write -c 430 Hc1ManualOPRoomTempDesired 20
Hab schon Port8891/data ausgelesen aber kann keinen entsprechend Parameter finden.
Die dafür in Frage kommenden sind alle read only.
localhost: find -d
430 ActualRoomTempDesiredHc1 = 24.00
430 DisplayedHc1RoomTempDesired = 23.0
430 DisplayedRoomTemp = 21.50
430 Hc1HeatCurve = 1.40
430 Hc1ManualOPRoomTempDesired = 22.0
430 Hc1OPMode = auto
430 OutsideTemp = 2.00;ok
430 RoomTemp = 23.75;ok
bai DateTime = valid;15:44:05;14.02.2021;3.000
bai FanHours = 16927
bai FlowTemp = 69.00;ok
bai HcHours = 14972
bai HwcHours = 1739
bai PumpHours = 28878
bai ReturnTemp = 63.38;64521;ok
bai SetMode = auto;62.0;50.0;-;0;0;1;0;0;0
bai Status01 = 64.0;63.0;3.000;62.0;58.0;off
bai Status02 = auto;60;69.0;80;57.0
bai StatusCirPump = off
bai StorageTemp = 58.00;ok
bai WaterPressure = 1.683;ok
broadcast outsidetemp = 2.000
broadcast vdatetime = 15:43:57;14.02.2021
Danke schon mal für eure Unterstützung
Horst
du brauchst ja nur in der 15.430.csv nachschauen und da gibt es nur diesen einen Wert "manuell" der Raumtemperatur zum einstellen.
r;w,,Hc1ManualOPRoomTempDesired,Raumtemperatur Soll Heizkreis 1 (manuell),,,,"3200",,,temp1,,,room setpoint in operation mode manual of the first heating circuit
LG
OK, danke für die Info
Eigentlich Schade wäre aber aus meiner Sicht ein wichtiger Parameter gewesen den man am 430 durch einfaches Drehen am rechten Rad realisieren kann.
Muss man jetzt halt in den Keller ;-)
LG
Horst
Zitat von: Hasont am 14 Februar 2021, 17:19:41
Hallo, ich habe eine einfache Vaillant Heizung mit CalorMatic 430 und such mir grad einen Wolf wie ich die Heizungsraumtemperatur im Automaticbetrieb ändern kann.
Vielleicht eine blöde Frage, aber was ist denn der manuelle und was der Automatikbetrieb ?
Grüße Christian
ich kann mir das so erklären, das "automatik" die Außentemperatur Steuerung aktiviert und alles über die Heizkurve gesteuert wird. In dieser Betriebsart stellt man auch den Regler auf Vollanschlag rechts. "Manuell" wird dann über den Regler ( Poti ) gesteuert.
Ich würde bei Einsatz einer Calormartic ohnehin den Witterungsgeführten Modus bevorzugen da hier zusätzlich durch Steuerung der Heizkurve der Vorlauf beeinflusst und nachgeregelt werden kann. Ein fest eingestellter Vorlauf kann abgesehen vom ungemütlichen Raumklima erhebliche Kosten verursachen. Aber das muss jeder selbst wissen was er machen will und wie weit er in die Steuerung eingreift.
Die Heizkurve selbst ist ja auch nur ein Standardwert und kann von Gebäude zu Gebäude stark abweichen und bedarf deshalb auch einer intelligenten Feinregelung. Wenn es kalt ist passt sie wunderbar, wenns wärmer wird dann greift meine Regelung hier stark ein und muss die Kurve je nach Wärmebedarf erhöhen. Das liegt aber hauptsächlich daran, weil ich den Fühler auf der Südseite montiert habe was aber unumstritten seine Vorteile hat.
LG
Zitat von: Reinhart am 17 Februar 2021, 20:48:54
Die Heizkurve selbst ist ja auch nur ein Standardwert und kann von Gebäude zu Gebäude stark abweichen und bedarf deshalb auch einer intelligenten Feinregelung. Wenn es kalt ist passt sie wunderbar, wenns wärmer wird dann greift meine Regelung hier stark ein und muss die Kurve je nach Wärmebedarf erhöhen. Das liegt aber hauptsächlich daran, weil ich den Fühler auf der Südseite montiert habe was aber unumstritten seine Vorteile hat.
Mein Fühler ist zwar auf der Nordseite, aber ich muss auch bei höheren Außentemperaturen durch die Erhöhung der Raumsolltemperaturen die Außentemperatur geführte Vorlauftemperatur etwas anheben. Hier liegt es aber daran, dass die Modulation nicht weit genug runter geht und es dann zu einem Verhältnis zwischen Brennzeit und Taktsperre kommt, bei dem auch die 5K plus Toleranz der Vorlauftemperatur bevor der Brenner abschaltet, nicht mehr ausreichen um im Durchschnitt die vom Regler aufgrund der Außentemperatur berechnete Sollvorlauftemperatur zu halten.
Ja, etwas verwirrend, in der 430er CSV finde ich das nicht, ich habe die 470er Steuerung, da gibt es diese Zeile:
r;w,,Hc1DayTemp,HC1_DaySetTemp,,,,"2700",,,temp1,,,day setpoint
im Gegensatz zu QuickVeto ist die schreibbar (warum QuickVeto nicht schreibbar ist, verstehe ich allerdings nicht so ganz)
in der 430er CSV gibt es auch keine Adresse 2700, vielleicht einfach mal (auf eigenes Risiko) probieren, ob man das manuell hizhufügen kann (lokale CSVs vorausgesetzt)
Grüße Christian
Hallo, ich denke der manuelle Wert setzt alle Reglungen wie Heizkurve außer Kraft. Wenn dann aber kein Raumtermostat vorhanden ist frag ich mich was er mit der eingestellten Zahl dann macht da er ja keinerlei Bezug mehr hat. Ev. ist ja hier ein Profi der einem das mal mit verständlichen Worten erklären kann.
An meiner ColorMatic 430 welche im Wohnzimmer verbaut ist wird im Standard die Raumtemperatur angezeigt und wenn ich am rechten Knopf drehe die gewünschte Temperatur im Automatikbetrieb.
Diese kann ich aber ja scheinbar nicht über den ebus schreiben. Da ich, wie viele hier auch, das Problem habe, dass es bei etwas wärmeren Wetter im Wohnzimmer zu kalt wird habe ich seit ca. 3 Wochen die Betriebsart (Hc1RoomTempSwitchOn) auf thermostat eingestellt und das Heizkörperventil im Wohnzimmer voll aufgedreht. Da es der größte Raum ist werden dann alle anderen Räume über die Heizungsventile bestens geregelt. Ob das ein guter Weg ist weiß ich nicht da würde mich eure Meinung interessieren.
Es ist aber sehr angenehm da er mit hoher Heizleistung den Raum morgens aufheizt und dann über Stunden kaum mehr nachheizen muss.
Es sieht auf dem Flow so aus, dass derzeit von 9:00 bis ca. 1/2 10 mit 65 Grad Vorlauf stark geheizt wird und dann schaltet er regelrecht ab für fast zwei Stunden um dann wieder mal aufzuheizen.
Als das über die Heizkurve lief war der Brenner meist dauernd an aber er hat das Wasser natürlich nie so heiß gemacht.
Derzeit sind von 9:00 - 16:00 21 Grad und von 16:00 - 23:00 22,5 Grad eingestellt und das funktioniert zumindest vom Wärmeempfinden ganz gut.
Nun wollte ich Hc1RoomTempSwitchOn auch mal über den ebus steuern bekomme aber "ERR: command not found" zurück.
Ich habe dazu schon einige Befehle wie w -c 430 Hc1RoomTempSwitchOn 2 und w -c 430 Hc1RoomTempSwitchOn thermostat oder wi -c 430#install Hc1RoomTempSwitchOn 2 und wi -c 430#install Hc1RoomTempSwitchOn thermostat ausprobiert aber immer "ERR: command not found" zurück bekommen.
In der Anleitung steht, dass der Wert als wi einzugeben wäre und als Info steht dann beim Circuit #install
r;wi Hc1RoomTempSwitchOn Raumtemperaturschalter Heizkreis 1 3400 UCH 0=off;1=modulating;2=thermostat
Was mache ich da falsch?
Danke schon mal für eure Hilfe.
also einstellen geht mit 0,1 oder 2.
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 0
done
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 1
done
was das aber genau bewirkt kann ich dir nicht sagen, da ich immer "off" zurück bekomme.
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 2
done
pi@eBus:~ $ ebusctl r -f -c 430 Hc1RoomTempSwitchOn
off
falls du den Wert nicht schreiben kannst, dann stell in der config --accesslevel=* ein.
LG
Ich möchte gern zwei ebusd am gleichen BUS (übergangsweise) betreiben: Den einen mit einer älteren, angepassten Config und einen weiteren mit dem aktuellen Software-Stand + Remote-Config. Wie muss ich die ebusd konfigurieren, damit sich diese nicht in die Quere kommen?
Ich vermute, hierfür ist der Parameter --address zu nutzen, der standardmäßig auf 31 gestellt ist (und dann auf 31/36 maste/slave) geht. Ich kann die Adresse aber nicht frei wählen und bekomme immer die Fehlermeldung "ebusd: invalid address". Wenn ich eine bereits vergebene BUS-Adresse nutze, startet zwar ebusd, wirft dann aber (logischer Weise) einen Fehler im Log.
Hier meine Config:
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201", loaded "vaillant/08.ehp.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
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"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 50: slave, scanned "MF=Vaillant;ID=EHP00;SW=0416;HW=7201", loaded "vaillant/50.ehp.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0416;HW=7201"
address ed: slave, scanned "MF=Vaillant;ID=PMS00;SW=0107;HW=4302", loaded "vaillant/ed.pms.sc.csv"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW00;SW=0117;HW=4402"
ich nehme für den zweiten Adapter immer "ff" als Adresse!
LG
Zitat von: Reinhart am 06 März 2021, 20:40:07
ich nehme für den zweiten Adapter immer "ff" als Adresse!
LG
Wenn ich eine Adresse nutze (auch "ff"), die noch nicht vergeben ist, bekomme ich einen Fehler.
Oder stimmt meine Syntax nicht?
~/ebusd $ ./src/ebusd/ebusd -a=ff -p 9000 -f -d enh:/dev/ttyUSB1 --latency=20000
ebusd: invalid address
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyUSB0 --loglevel=debug --address=ff"
so habe ich das beim Testadapter gesetzt!
LG
OK, Parameter ausschreiben lautet die Zauberformel!
Danke.
ja ich mache das immer so weil sich das für mich dann selbsterklärend liest!
LG
... damit konnte ich nun auch den neuen eBus-Adapter v3 in Betrieb nehmen. Funktioniert schon ganz gut.
Allerdings finden sich auch nicht gerade wenige Fehlerausgaben im Log:
device status: eBUS comm error: framing
arbitration start error
Gibt's dagegen auch eine "Zauberformel"? ;)
ja, hat John schon ein paarmal geschrieben, das viele solcher Meldungen beim eBus Protokoll als "normal" zu betrachten sind. Der Debug Modus ist mehr oder weniger nur zur Fehlersuche gedacht und sollte im Normalbetrieb abgeschalten werden. Ich habe den auch nur am Testadapater aufgedreht. Schon beim scan kommen die ersten Meldungen, aber das ist ja der Sinn und Zweck beim scannen um festzustellen wer antwortet.
Kann man vergleichen mit einem Netzwerksniffer was da alles daneben geht, wird halt einfach wiederholt und keinem fällt es auf.
LG
Ist bei mir nicht im Debug-Modus, sondern in der Reporting-Klasse "Error".
2021-03-06 21:48:12.700 [bus error] device status: eBUS comm error: framing
Aber in der Tat habe ich keine Funktionseinschränkungen bslang festgestellt und werde ich somit ignorieren.
Zitat von: Reinhart am 05 März 2021, 19:08:02
also einstellen geht mit 0,1 oder 2.
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 0
done
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 1
done
was das aber genau bewirkt kann ich dir nicht sagen, da ich immer "off" zurück bekomme.
Antwort von Hasont:
Ich hab ja meine Colormatic430 im Wohnzimmer
Der Wert 0 = off sagt, dass die Anlage im Modus Außenthemperaturfühler und Heizkurve läuft
Der Wert 1 = modulating ist mir noch unklar. Ev. kennt sich da ja einer besser aus oder ich finde es noch heraus.
Der Wert 2 = thermostat sagt, dass die Anlage ausschließlich nach Innenraumtemperatur läuft und abschaltet sobald diese erreicht wurde.
pi@eBus:~ $ ebusctl w -c 430 Hc1RoomTempSwitchOn 2
done
pi@eBus:~ $ ebusctl r -f -c 430 Hc1RoomTempSwitchOn
off
falls du den Wert nicht schreiben kannst, dann stell in der config --accesslevel=* ein.
LG
Hallo Reinhard, vielen Dank es war der Eintrag "--accesslevel=*". Das Schreiben ging aber bei den meisten anderen Befehlen eigentlich, komisch!
Es sieht jetzt so bei mir aus, ev findest du ja noch falsche Werte:
EBUSD_OPTS="-d /dev/ttyUSB0 --scanconfig=full --accesslevel=* --htmlpath=/etc/ebusd/html --port=8888 --latency=0 --receivetimeout=100000 -l /var/log/ebusd.log --httpport=8891"
Was genau macht z.B. der Eintrag latency=0. Steht bei mir scheinbar schon seit 2 Jahren so in der config. Hatte bisher aber noch nie Probleme.
Servus,
mich stört es, dass obwohl die Räume in unserem Haus schön warm sind, die Heizkreispumpe (HK2P) fleißig läuft und nicht abschaltet.
Aufgrund der Außentemperatur ( zb 2°C) und der Heizkurve 0.30 geht die Anlage davon aus, dass ich zB. 24°C im Vorlauf der Heizung
brauche. Hier wird aber nicht bereücksichtigt, dass das Haus schon warm genug ist!
Die Idee ist, mit einem Aktor beim Überschreiten einer Temperatur die Heizkreispumpe abzschalten, natürlich mit einem Puffer um ständiges
Takten zu vermeiden.
Was mir dazu aber nun fehlt, die Möglichkeit die HK2P Pumpe für die Fußbodenheizung abzuschalten, Status lesen kann ich allerding finde
ich keine write Möglichkeit für diese Pumpe. Nur als Hinweis, ich meine nicht die Zirkulationspumpe Warmwasser, die hab ich nämlich eh nicht ;-)
Gruß
Chris
Puhh, Heizkurve 0.3 und 24° im Vorlauf. Da fröstelt es mich ja schon beim Lesen. ;D
Warum regelst du nicht einfach die Soll-Temperatur runter, wenn die Raumtemperatur einen bestimmten Wert überschreitet? Dann schaltet die Heizung ja von alleine ab. Beim Unterschreiten kannst du sie ja wieder hochregeln.
Zitat von: Wolpertinger am 08 März 2021, 11:26:02
Servus,
mich stört es, dass obwohl die Räume in unserem Haus schön warm sind, die Heizkreispumpe (HK2P) fleißig läuft und nicht abschaltet.
Aufgrund der Außentemperatur ( zb 2°C) und der Heizkurve 0.30 geht die Anlage davon aus, dass ich zB. 24°C im Vorlauf der Heizung
brauche. Hier wird aber nicht bereücksichtigt, dass das Haus schon warm genug ist!
Die Idee ist, mit einem Aktor beim Überschreiten einer Temperatur die Heizkreispumpe abzschalten, natürlich mit einem Puffer um ständiges
Takten zu vermeiden.
Was mir dazu aber nun fehlt, die Möglichkeit die HK2P Pumpe für die Fußbodenheizung abzuschalten, Status lesen kann ich allerding finde
ich keine write Möglichkeit für diese Pumpe. Nur als Hinweis, ich meine nicht die Zirkulationspumpe Warmwasser, die hab ich nämlich eh nicht ;-)
Gruß
Chris
Moin
Also ich denke, dass das gar nicht moeglich ist, wenn nicht sogar verboten! Die Pumpe laeuft nach meinem Verstaendnis immer so lange, wie der Brenner laeuft, plus Nachlaufzeit.
Andernfalls haettest du innerhalb kurzer Zeit eine Abschaltung wegen Uebertemperatur!
Wie genau die Regelung bei FB-Heizungen ist, weiss ich nicht, da ich keine habe. Grundsaetzlich aber hoert sich das so an, als ob Du keine RT-Aufschaltung hast, die dann sagt, es ist warm genug Therme aus!
Das ist quasi das was Wolle02 geschrieben hat!
Gruss Christoph
Gibt es hier Kollegen die wie ich eine Vaillant Flexotherm 87/4 besitzen? Ich kann aktuell viele Daten auslesen, jedoch fehlt mir die komplette Fachhandwerkebene (Kompressorstarts, SoleTemp etc) sowie der Live Monitor. Vermutlich wurden diese Parameter noch nicht entschlüsselt, oder kann das jemand auslesen? Wenn ja, wie?
Hier noch die Ausgabe:
version: ebusd 21.2.v21.2
update check: OK
access: *
signal: acquired
symbol rate: 24
max symbol rate: 182
min arbitration micros: 584
max arbitration micros: 4311
min symbol latency: 7
max symbol latency: 17
reconnects: 0
masters: 5
messages: 495
conditional: 0
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=HMU00;SW=0307;HW=0403", loaded "vaillant/08.hmu.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0509;HW=6403", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 71: master #9
address 76: slave #9, scanned "MF=Vaillant;ID=VWZ00;SW=0307;HW=0403"
address ff: master #25, ebusd
Moin
@MassiveAttack:
Kannst Du bitte CodeTags benutzen!? Ueber den smilies die Raute (#). Das geht auch nachtraeglich!
Zu Deiner Frage. Welchen e-Bus Adapter nutzt Du denn?
So wie ich sehe, ist Dein daemon ja aktuell! Evtl. hast Du nur nicht die richtige Einstellung beim Aufruf des daemons genommen?
Wenn Du den V3 Adapter nutzt, solltest Du am Besten auch in den entsprechenden thread wechseln!
John und Reinhart sind hier bestimmt noch dabei, aber haben genug mit dem neuen Adapter (V3) um die Ohren!
Gruss Christoph
hi,
sorry, erledigt.
ja ich habe schon den v3, die Einstellungen passen sicher. Es geht mMn nur darum, dass die Signale in den csv's noch nicht dekodiert werden (können). Daher meine Frage, ob das jemand schon geschafft hat.
Diese Frage habe ich auch in den passenden v3 Thread gepostet, aber ich denke das hat nichts mit dem Adapter zu tun, sondern einfach mit der Dekodierung.
Umfeld:
Weishaupt WTC-15A
Ubuntu server 20.04
ebusd 21.2.v21.2
Adapter V1.6, Poti passt, aa's kommen
Problem: ERR: no data stored
Mein ebusd lief klaglos seit Weihnachten - bis gestern.
Nach einem Ubuntu-Update geht jetzt (fast) nichts mehr.
Ein ebusctl -r datetime geht noch. Ein ebusctl -r Set auch.
Darüber hinaus werden aber keine Werte mehr gespeichert
ebusctl r -m 1 Set
hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
ebusctl r -m 1 datetime
7.000;11:56:-;27.03.2021
ebusctl r -m 1 Act
ERR: no data stored
Bei der Aktualisierung wurde wohl auch ebusd aktualisiert und dabei gleich mal die /etc/default/ebusd überschrieben.
Mein Fehler: ich hatte mir die gesetzten Parameter nicht richtig dokumentiert. Bäh!
Aus meinen Aufzeichnungen habe ich das hier rekonstruiert:
/etc/default/ebusd
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -c /etc/ebusd/ -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd.log
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl info
version: ebusd 21.2.v21.2
update check: OK, broadcast.csv: different version available
signal: acquired
symbol rate: 40
max symbol rate: 65
reconnects: 0
masters: 6
messages: 1689
conditional: 0
poll: 0
update: 16
address 03: master #11
address 07: master #16
address 08: slave #11, scanned "MF=Kromschroeder;ID=W ;SW=1200;HW=0302"
address 30: master #3
address 31: master #8, ebusd
address 36: slave #8, ebusd
address f1: master #10
address f6: slave #10, scanned "MF=Kromschroeder;ID=WWST?;SW=1200;HW=0302"
address ff: master #25
jochen@metserver1:/etc/ebusd/kromschroeder$
Obwohl im Logfile alle broadcasts mitsamt den Daten gezeigt werden, kann ich sie nicht - wie bisher - auslesen.
2021-03-27 11:52:45.540 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:52:59.365 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.965;39
2021-03-27 11:53:02.822 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:53:05.464 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:53:18.145 [update notice] received update-read broadcast datetime QQ=30: 7.000;11:55:-;27.03.2021
2021-03-27 11:53:25.380 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:53:29.375 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.965;39
2021-03-27 11:53:45.817 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:53:59.351 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:54:03.089 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:54:05.776 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:54:18.418 [update notice] received update-read broadcast datetime QQ=30: 7.000;11:56:-;27.03.2021
2021-03-27 11:54:25.690 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:54:29.460 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:54:45.612 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:54:59.562 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:55:03.346 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2721
2021-03-27 11:55:05.537 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:55:18.201 [update notice] received update-read broadcast datetime QQ=30: 7.000;11:57:-;27.03.2021
2021-03-27 11:55:25.472 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:55:29.748 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:55:45.417 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:55:59.740 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:56:03.612 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:56:05.350 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:56:18.586 [update notice] received update-read broadcast datetime QQ=30: 7.000;11:58:-;27.03.2021
2021-03-27 11:56:25.767 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:56:29.761 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:56:45.696 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:56:59.673 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:57:03.852 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:57:05.638 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:57:19.409 [update notice] received update-read broadcast datetime QQ=30: 7.000;11:59:-;27.03.2021
2021-03-27 11:57:25.565 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:57:30.057 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:57:45.496 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:58:00.080 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.961;39
2021-03-27 11:58:04.121 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:58:05.414 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:58:18.121 [update notice] received scan-read scan.f6 QQ=30: Kromschroeder;WWST?;1200;0302
2021-03-27 11:58:19.342 [update notice] received scan-read scan.08 QQ=30: Kromschroeder;W ;1200;0302
2021-03-27 11:58:20.538 [update notice] received update-read broadcast datetime QQ=30: 7.000;12:00:-;27.03.2021
2021-03-27 11:58:25.349 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:58:30.063 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 11:58:45.802 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:59:00.211 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 11:59:04.399 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 11:59:05.734 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:59:18.372 [update notice] received update-read broadcast datetime QQ=30: 7.000;12:01:-;27.03.2021
2021-03-27 11:59:25.650 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 11:59:30.050 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 11:59:45.576 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:00:00.250 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 12:00:04.659 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2721
2021-03-27 12:00:05.497 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:00:18.165 [update notice] received update-read broadcast datetime QQ=30: 7.000;12:02:-;27.03.2021
2021-03-27 12:00:25.436 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:00:30.437 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 12:00:45.371 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:01:00.295 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 12:01:04.893 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 12:01:05.788 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:01:18.455 [update notice] received update-read broadcast datetime QQ=30: 7.000;12:03:-;27.03.2021
2021-03-27 12:01:25.724 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:01:30.581 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 12:01:45.660 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:02:00.422 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.957;39
2021-03-27 12:02:05.151 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
2021-03-27 12:02:05.585 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:02:18.263 [update notice] received update-read broadcast datetime QQ=30: 7.000;12:04:-;27.03.2021
2021-03-27 12:02:25.495 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:02:30.615 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;7;8.953;39
2021-03-27 12:02:45.434 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:03:00.793 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;33;40.0;-;45.0;0.0;7;8.953;39
2021-03-27 12:03:05.368 [update notice] received update-read hc1 Set: hotwaterinheating;stopconsumer;39.38;-;-;35.0;-
2021-03-27 12:03:05.798 [update notice] received unknown MS cmd: ff0850000b5d015f0168016a016e0359 / 060007282d2720
Folgende Zeilen in einem bash-skript haben bis gestern meine Datenbank gefüttert:
funktion=`ebusctl r -m 1 Act SettingUV`
modulation=`ebusctl r -m 1 Act Load`
vl_t_ist=`ebusctl r -m 1 Act SupplyTemp`
ww_ist=`ebusctl r -m 1 Act DHWTemp`
Jetzt liefern diese Zeilen nur noch "ERR: no data stored" obwohl im Logfile das hier erscheint:
2021-03-27 12:08:01.500 [update notice] received update-read sc Act QQ=f1: 1;BrennerInBetrieb;1;1;1;1;1;1;1;0;0;Winter;0;0;0;0;1;Heating;32;40.0;-;45.0;0.0;8;8.949;39
Kann mir bitte jemand sagen, wie ich das wieder gerade biegen kann?
Vielen Dank für Tipps,
Gruß,
Jochen
-m 1 gibt dir ja den Wert nur zurück wenn er weniger als 1 Sekunde alt ist.
Versuche doch mal die Zeit zu vergrößern ( zB: 5 oder 10 ) bzw. teste doch mal statt -m mit -f ( force ) den Wert zu holen.
LG
Hallo Reinhart,
danke, dass Du Dich meldest.
Zitat von: Reinhart am 27 März 2021, 18:16:35
-m 1 gibt dir ja den Wert nur zurück wenn er weniger als 1 Sekunde alt ist.
Jawoll! So soll es auch sein, brandaktuelle Werte (eine 10 statt der 1 wäre sicher auch okay).
Zitat von: Reinhart am 27 März 2021, 18:16:35
Versuche doch mal die Zeit zu vergrößern ( zB: 5 oder 10 )
Das hatte ich schon versucht, gebracht hat es nichts.
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -m 1 Act DHWTemp
ERR: no data stored
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -m 10 Act DHWTemp
ERR: no data stored
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -m 100 Act DHWTemp
ERR: no data stored
Zitat von: Reinhart am 27 März 2021, 18:16:35
... bzw. teste doch mal statt -m mit -f ( force ) den Wert zu holen.
Das funktioniert dann aus einem anderen Grund nicht. Den Unterschied verstehe ich aber nicht.
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -f Act DHWTemp
ERR: element not found
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -m 0 Act DHWTemp
ERR: element not found
Gruß,
Jochen
versuche mal
ebusctl r -f -c Act DHWTemp
LG
jochen@metserver1:/etc/ebusd/kromschroeder$ ebusctl r -f -c Act DHWTemp
ERR: element not found
Leider kein Unterschied...
wenn ich mir dein ebusctl i anschaue, dann werden da ja gar keine csv Files geladen. Wenn das so ist, dann frage ich mich woher die Namen im Log kommen.
Kannst du das nochmals checken ob du einen Grund findest warum die csv nicht geladen werden? Dein lokaler Pfad ist ja korrekt in der Konfig eingetragen. Sind dort auch wirklich die "alten" csv Files gespeichert.
LG
Reinhart,
ich mach's kurz: es geht wieder. Schade nur, dass ich nicht weiß, warum.
Ich habe den Prozess nur angehalten und wieder gestartet, um die Logeinträge vom Start nochmal zu bekommen (wie schon so oft, heute) und jetzt geht's.
Zitat von: Reinhart am 27 März 2021, 19:24:12
Dein lokaler Pfad ist ja korrekt in der Konfig eingetragen. Sind dort auch wirklich die "alten" csv Files gespeichert.
Ja, die Dateien wurden zum Glück nicht überschrieben. Ein vernünftiges Backup habe ich jetzt auch gemacht.
Ich danke Dir für Deine Hilfe.
Ob ich morgen mal den V3-Adapter testen soll?
Gruß,
Jochen
Hallo zusammen,
ich habe meinen eBus-Koppler von esera an meine Vaillant arotherm, parallel zur Raumsteuerung geklemmt. Wenn ich den eBus-Koppler stromlos mache steigt meine Heizung aus und meldet einen Kommunikationsfehler... das kann ja so nicht richtig sein? was mache ich falsch?
ich kenne die Beschaltung des Esera nicht, bei unseren Adaptern ist da nicht der Fall.
Das würde ja dann bedeuten, dass bei Stromabschaltung des Adapters die Heizung steht. Der eBus shiftet ja zwischen 12 - 15 Volt, wobei 12V ein Sendesignal darstellt und 15 V den Empfang. Ich kann mir ehrlicherweise nicht vorstellen, das der Esera nach Spannungsausfall die Busspannung nach unten zieht.
Wenn du die Möglichkeit hast die Spannung zu messen, dann miss doch bitte die Spannung am Bus wenn du den Adapter abschaltest.
Daher machst du gar nix falsch würde ich jetzt behaupten.
LG
Zitat von: mikesmiles am 06 April 2021, 18:52:34
Hallo zusammen,
ich habe meinen eBus-Koppler von esera an meine Vaillant arotherm, parallel zur Raumsteuerung geklemmt. Wenn ich den eBus-Koppler stromlos mache steigt meine Heizung aus und meldet einen Kommunikationsfehler... das kann ja so nicht richtig sein? was mache ich falsch?
Nichts, diese Erfahrung habe ich auch mit dem Esera gemacht. Von denen kam wahrscheinlich keiner auf die Idee, dass die Spannungsversorgung mal weg sein könnte. Ich habe daher ein 5V Relais vor den Esera geklemmt, damit der beim Fehlen der USB Spannung nicht die Heizung lahmlegt.
Gruss
Christoph
Danke Christoph - das ist ja spannend. Frage - wie genau hast du das mit dem 5V Relais gelöst? Das benötigt doch auch eine Spannungsversorgung?
Zitat von: mikesmiles am 10 April 2021, 10:14:10
Frage - wie genau hast du das mit dem 5V Relais gelöst? Das benötigt doch auch eine Spannungsversorgung?
Die Spannung habe ich von einem USB Port des Raspberry abgezweigt. 5Volt Relais, weil da eben nur 5Volt rauskommen (150Ohm Spule ~ 30mA). Den EBUS dann über den Schliesser schleifen. Da tut's jedes Miniaturrelais für 2€.
Gruss
Christoph
Hallo Zusammen,
Meine konkrete Frage ist: Wie bekommen ich die Daten aus der Multimatic 700 ausgelesen. Das Gerät wird zwar erkannt (MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv) aber schreibt irgendwie nichts auf den ebus. Wie kann ich gezielt das Gerät auslesen? Habt ihr da Beispiele?
kurz: Meine Konfig: respberry pie3+ (FHEM) und ein seperater raspberry pie 3+ im Keller Technikraum der am ebus an der Gastherme hängt als "ebus Datensammler"
Vaillant Komponenten wären:
Gastherme: VC146-5-5
Regler: Multimatic 700 VRC700
Solarmodul VR70
400 L Warmwasserspeicher
Lüftungsanlage Recovair 260/4
Alle Geräte hängen am ebus.
ebusd konfig:
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d /dev/ttyebus --configpath=http://ebusd.eu/config/ --scanconfig --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.30 --mqtttopic=ebusd/%circuit/%name"
ein ebusctl info auf dem ebus Raspi bringt:
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2-28-gc8a4ad5
update check: revision v21.2 available
access: *
signal: acquired
symbol rate: 23
max symbol rate: 118
min arbitration micros: 2
max arbitration micros: 3
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 3
messages: 640
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
Ich sehe also dass 3 Geräte/Module (Gastherme, Regler und Solarmodul) erkannt werden. Die Lüftungsanlege wird komischerweise nicht erkannt.
Zusätzlich habe ich noch im log Nachrichten die nicht decodiert werden können:
pi@raspberrypi:~ $ ebusctl grab result
1008b5110100 / 08860209001f100000 = 884
1008b5160111 / 00 = 1
1052b5160111 / 090103010e0130010301 = 1
1008b5120204ff / 0101 = 884
1008b513020508 / 00 = 88
1008b5100305ff03 / 0101 = 884
1052b5030c0700ffffffffffffffffffff / 0101 = 59
1052b516081000ffff0304212a / 0b2000ff0304de2a00000000 = 3
1052b516081002ffff0304c12a / 0b2200ff0304c12a00000000 = 28
1052b52309000000000000000100 / 0101 = 1
Aber die unkbekannten Nachrichten sind erstmal weniger wichtig...
Auf dem Raspi mit der laufenden FHEM Instanz sehe ich jedoch nur 2 angelegte Geräte (Gastherme und das Solarmodul VR70). Vom Regler multimatic 700 sehe ich nix (siehe Bild)
Kann man das fehlende Modul irgendwie aus FHEM zum auslesen zwingen?
Ist noch was an der Konfig falsch auf dem Raspi mit der FHEM Instanz?
Hallo in die Runde,
habe seit gestern den Ebus 3 Adapter im Einsatz und habe schon sehr viel über Grafana visualisiert. Echt top!
Wie komme ich an die Temperatur des Kollektors ran?
update: 10
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402", loaded "vaillant/06.pms.csv"
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0104;HW=7803", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 0a: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302", loaded "vaillant/0a.pmw.hwc.csv"
address 10: master #2
address 12: slave, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0613;HW=6903", loaded "vaillant/15.700.csv"
address 26: slave, scanned "MF=Vaillant;ID=VR_71;SW=0104;HW=0503", loaded "vaillant/26.vr_71.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0613;HW=6903", loaded "vaillant/ec.sol.sc.csv"
address ed: slave, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address f7: master #20
address fc: slave #20, scanned "MF=Vaillant;ID=PMW01;SW=0206;HW=8302"
In der vaillant/ec.sol.sc.csv finde ich folgendes:
r,,Col,KOL,,,,"0400",,,tempsensor,,,value and sensorstate of the collector sensor
Diese Abfrage bringt leider keinen Erfolg:
pi@raspberrypi:~ $ ebusctl read -c sc Col
ERR: invalid position in decode
Hallo zusammen,
Ich habe gestern meinen Ebus adapter für den Raspi bekommen.
Er liefert mir auc schon ein paar Daten. Aber ich denke nicht alles.
Könnt ihr mir bitte mal helfen ??
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d enh:/dev/ttyAMA0 -p 8888 --latency=50 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig c /etc/ebusd --configpath=/etc/ebusd --httpport=8889 --htmlpath=/var/ebu$
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
root@ServerEbus:/etc/ebusd# ls -al
insgesamt 32
drwxr-xr-x 3 root root 4096 Okt 7 11:37 .
drwxr-xr-x 4 root root 4096 Okt 6 20:21 ..
-rw-r--r-- 1 root root 5620 Okt 7 08:20 22102.csv
-rw-r--r-- 1 root root 1253 Okt 6 20:21 broadcast.csv
-rw-r--r-- 1 root root 754 Okt 6 20:21 memory.csv
-rw-r--r-- 1 root root 2377 Okt 7 08:20 _templates.csv
drwxr-xr-x 2 root root 4096 Okt 6 20:21 vaillant
root@ServerEbus:/etc/ebusd# ebusd --checkconfig
2021-10-07 11:41:38.090 [main error] invalid configpath without scanconfig
root@ServerEbus:/etc/ebusd#
{
"scan.06": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 1633598767,
"zz": 6,
"fields": {
"MF": {"value": "TEM"},
"ID": {"value": "25440"},
"SW": {"value": "0113"},
"HW": {"value": "0000"}
}
}
}
},
"scan.08": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 1633598769,
"zz": 8,
"fields": {
"MF": {"value": "TEM"},
"ID": {"value": "WE_1 "},
"SW": {"value": "3632"},
"HW": {"value": "3030"}
}
}
}
},
"scan.15": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 1633598771,
"zz": 21,
"fields": {
"MF": {"value": "TEM"},
"ID": {"value": "24849"},
"SW": {"value": "0605"},
"HW": {"value": "0102"}
}
}
}
},
"scan.18": {
"messages": {
"": {
"name": "",
"passive": false,
"write": false,
"lastup": 1633598773,
"zz": 24,
"fields": {
"MF": {"value": "TEM"},
"ID": {"value": "WE_2 "},
"SW": {"value": "3632"},
"HW": {"value": "3030"}
}
}
}
},
"global": {
"version": "21.2.v21.2",
"updatecheck": "OK",
"signal": true,
"symbolrate": 38,
"maxsymbolrate": 108,
"minarbitrationmicros": 5,
"maxarbitrationmicros": 5,
"minsymbollatency": 10,
"maxsymbollatency": 37,
"qq": 49,
"reconnects": 0,
"masters": 5,
"messages": 4,
"lastup": 1633598773
}
}
Ich habe die CSV datein für die Ochsner heizung genommen und in den Ordner kopiert.
Was zeigt denn
ebusctl info
bei dir an?
Das wird angezeigt.
root@ServerEbus:/etc/ebusd# ebusctl info
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 33
max symbol rate: 99
min arbitration micros: 4
max arbitration micros: 327
min symbol latency: 10
max symbol latency: 32
reconnects: 0
masters: 5
messages: 4
conditional: 0
poll: 0
update: 0
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=TEM;ID=25440;SW=0113;HW=0000"
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=TEM;ID=24849;SW=0605;HW=0102"
address 18: slave #12, scanned "MF=TEM;ID=WE_2 ;SW=3632;HW=3030"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Grüße
Pass das mal bitte den configpfad wie folgt an:
--configpath=http://ebusd.eu/config/
hab ich gemacht.
Ich habe das so verstanden, da es eine Ochsner Heizung ist müsste ich CSV dateien aus dem Ebus ordner nehme. Also diese https://github.com/john30/ebusd-configuration/tree/master/ebusd-1.x.x
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d enh:/dev/ttyAMA0 -p 8888 --latency=50 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig=full --configpath=http://ebusd.eu/config/ --httpport=8889 --htmlpath=/va$
Nun zeigt er mir schon mal wieder die Außen Temp. an.
root@ServerEbus:/etc/ebusd# ebusctl info
version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 70
max symbol rate: 110
min arbitration micros: 4
max arbitration micros: 19
min symbol latency: 10
max symbol latency: 32
reconnects: 0
masters: 5
messages: 15
conditional: 0
poll: 0
update: 4
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=TEM;ID=25440;SW=0113;HW=0000"
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=TEM;ID=24849;SW=0605;HW=0102"
address 18: slave #12, scanned "MF=TEM;ID=WE_2 ;SW=3632;HW=3030"
address 31: master #8, ebusd
address 36: slave #8, ebusd
root@ServerEbus:/etc/ebusd# ebusctl grab result
1003050a00 = 1
1013050a00 = 1
100305020101 = 1
101305020101 = 1
10fe080109661f00800000001a00 = 2
10fe0802080000003500000300 = 1
100305010a00003510000000000000 = 3
101305010a00183510000000000100 = 3
011506210400800040 / 0a00800d02f4010cfe9d00 = 6
011506210400840040 / 0a04800d02e8030000e201 = 8
011506210400e00040 / 0a60800d02e80300003a01 = 8
011506210402b50040 / 0a35810000ff0000000000 = 8
011506210402c60040 / 0a46410428ffff0000bbad = 8
011506210402c80040 / 0a4841042a9f050000f102 = 8
031005030c010000003014ff3f00000500 = 6
131005030c011a000030ffff3f43000100 = 6
Hallo in die Runde,
ich habe eine Frage zum Import der Temperatur des Kollektors auf dem Dach. An meiner Solarstation (VAILLANT auroFLOW exclusive) kann ich die Temperatur des Kollektors auf dem Dach auslesen.
Dies möchte ich auch gern über Ebus um die Temperatur in Grafana einzubinden.
Die csv-Datei wird aus meiner Sicht auch korrekt eingelesen.
address ec: slave, scanned "MF=Vaillant;ID=SOL00;SW=0613;HW=6903", loaded "vaillant/ec.sol.sc.csv"
Die Temperatur des Kollektors finde ich in den csv. Datei hier:
r,,Col,KOL,,,,"0400",,,tempsensor,,,value and sensorstate of the collector sensor,,,
Wenn ich die Temperatur abfrage, erhalte ich das:
pi@raspberrypi:~ $ ebusctl r -c sc col
ERR: invalid position in decode
Auch über ./readall.sh
erhalte ich diesen Fehler.
sc Col = ERR: invalid position in decode
Wo könnte der Fehler liegen? Ich vermute das irgendwas an der csv-Datei nicht passt.
ZitatWo könnte der Fehler liegen? Ich vermute das irgendwas an der csv-Datei nicht passt.
Bestimmt.
Ich habe schon ungefähr 200 Seiten vorher geraten, nicht mit den CSV-Dateien zu arbeiten. Sondern diese in ein Programm wie Excel oder LibreOffice Calc zu importieren und von dort aus zu exportieren. Irgendwo im contrib-Ordner gibt es auch noch die Beispieldatei mit den entsprechenden Makros.
LG
pah
Ja aber ich muss ja anscheinend mit der CSV arbeiten wegen der Ochsner Heizung.
Ich bräuchte da mal Hilfe.
root@ServerEbus:/etc/ebusd# ebusctl info
version: ebusd 21.2.v21.2
update check: OK
signal: acquired
symbol rate: 81
max symbol rate: 119
min arbitration micros: 2
max arbitration micros: 20
min symbol latency: 10
max symbol latency: 37
reconnects: 0
masters: 5
messages: 15
conditional: 0
poll: 0
update: 4
address 01: master #6
address 03: master #11
address 06: slave #6, scanned "MF=TEM;ID=25440;SW=0113;HW=0000"
address 08: slave #11, scanned "MF=TEM;ID=WE_1 ;SW=3632;HW=3030"
address 10: master #2
address 13: master #12
address 15: slave #2, scanned "MF=TEM;ID=24849;SW=0605;HW=0102"
address 18: slave #12, scanned "MF=TEM;ID=WE_2 ;SW=3632;HW=3030"
address 31: master #8, ebusd
address 36: slave #8, ebusd
root@ServerEbus:/etc/ebusd# ebusctl grab result all
10fe070009800c32171011100121 = 1527: broadcast datetime
10fefe010a53453630202045204f4b = 255: broadcast error
1003050a00 = 573
1013050a00 = 573
3106070400 / 0a10323534343001130000 = 3: scan.06
3108070400 / 0a1057455f312036323030 = 3: scan.08
3115070400 / 0a10323438343906050102 = 3: scan.15
3118070400 / 0a1057455f322036323030 = 3: scan.18
100305020101 = 573
101305020101 = 573
10fe050d0a0000800000800080ffff = 573
10fe080109002000800000331e00 = 108
10fe0801091920008000c0b31a01 = 121
10fe0801093320008000c0b31a01 = 206
10fe0801094d1f00800008e61900 = 186
10fe080109661d00800008b31900 = 80
10fe080109801f00800008191a00 = 121
10fe0801099a1f00800008661a00 = 316
10fe080109b31f00800008191b00 = 100
10fe080109cd1f008000084d1c00 = 187
10fe080109e61f00800000001d00 = 102
10fe0802080000003500000300 = 1527
10fe10150b0204020101d10100800080 = 53
100305010a0000350b000000000000 = 744
100305010a0000350c000000000000 = 1243
100305010a554e350b646401000001 = 114
100305010aee1a350c00a101000000 = 93
100305010aee1a350b00a101000000 = 96
101305010a001a350b000000000100 = 840
101305010a004e350b000001000101 = 114
101305010a0019350c000000000100 = 1
101305010a001a350c000000000100 = 1335
011506210400800040 / 0a00800d02f4010cfe7d00 = 6911
011506210400840040 / 0a04800d02e8030000fb01 = 6915
011506210400e00040 / 0a60800d02e80300004101 = 6912
011506210402b50040 / 0a35810000ff0000000300 = 6907
011506210402c60040 / 0a46410428ffff0000bfad = 6908
011506210402c80040 / 0a4841042a9f0500006902 = 6904
0115062104068e0040 / 0a0e430000020001000100 = 51
031005030c010000003414ff3f00000500 = 4872
031005030c010040003f19ff3f00000500 = 17
031005030c010240003218ff3f00000500 = 40
031005030c010300003313ff3f81000500 = 81
031005030c010148644019ff3f00000500 = 717
131005030c0103000033ffff3fc3000100 = 81
131005030c011a000034ffff3f43000100 = 5646
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d enh:/dev/ttyAMA0 --latency=50 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig=full -c, --configpath=/etc/ebusd/22102.csv
--httpport=8889 --htmlpath=/va$"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /usr/lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Zitat von: Prof. Dr. Peter Henning am 11 Oktober 2021, 08:37:57
Bestimmt.
Ich habe schon ungefähr 200 Seiten vorher geraten, nicht mit den CSV-Dateien zu arbeiten. Sondern diese in ein Programm wie Excel oder LibreOffice Calc zu importieren und von dort aus zu exportieren. Irgendwo im contrib-Ordner gibt es auch noch die Beispieldatei mit den entsprechenden Makros.
LG
pah
Erstmal Danke für den Hinweis. Kannst du mir da weitere Hilfestellung geben?
In meiner config ziehe ich die Daten direkt aus
EBUSD_OPTS="-d enh:/dev/ttyAMA0 --latency=50 --httpport=8889 -p 8888 --scanconfig=full --enablehex --configpath=http://ebusd.eu/config/ -l /var/log/ebusd.log"
Wenn ich deinen Ansatz richtig verstehe, müsste ich dann aber die csv-Dateien lokal ablegen und darauf verweisen. Korrekt?
Zudem habe ich die Daten aus der Csv nach Excel importiert und dann wieder zur CSV exportiert. Sieht für mich 1:1 genauso aus wie vorher.
Viele Grüße
André
Es gibt im contrib-Ordner EBUS ein älteres Dokument von Vaillant, das ich seinerzeit (2014 - meine Güte, ist das lang her...) ergänzt, aber nie zu Ende geschrieben habe (bei mir läuft ja alles ...). Darin ist die Systematik der Kommandos erklärt, das kann man also benutzen, um seine eigenen (komplett neuen ...) Zeilen in die Konfigurationsdateien einzubauen und somit den Fehler einzugrenzen.
Und das geht wirklich besser mit dem Spreadsheet als mit der CSV-Datei. Zumindest in der ods-Version (Beispiel vr620 ods) sind auch die entsprechenden Feldnamen und Makros hinterlegt.
LG
pah
ich habe nur die Ordner im Contrib Ordner.
https://svn.fhem.de/trac/browser/trunk/fhem/contrib/EBUS
LG
pah
Hallo,
ich hab gerade erstmalig meine Heizung über fhem vom Sommermodus in den Heizbetrieb umgestellt und bin in diesem Zusammenhang noch auf eine Fragestellung gestoßen, wo ich hoffe, einen Hinweis von Euch zu bekommen...
Ich betreibe eine gemischte Heizungsanlage mit Fußbodenheizung und konventionellen Heizkörpern, also zwei Heizkreise. Die Infos zu den Parametern entstammen der Datei 15.f47.csv. Darin sind unter anderem definiert:
- Hc1OPMode: Betriebsart Heizkreis 1 (2=auto;3=on;4=night;5=summer)
- Hc2OPMode: Betriebsart Heizkreis 2 (2=auto;3=on;4=night;5=summer)
- Hc1SFMode: Sonderfunktion Heizkreis 1(0=none;1=party;2=onedaybankholiday;3=onedayholiday;4=holiday;5=bankholiday;6=quickveto;7=onetimeventilation;8=onetimewater)
- Hc2SFMode: Sonderfunktion Heizkreis 2(0=none;1=party;2=onedaybankholiday;3=onedayholiday;4=holiday;5=bankholiday;6=quickveto;7=onetimeventilation;8=onetimewater)
Meine Vorstellung war nun: Zum Einschalten in den Heizbetrieb setze ich Hc1OPMode und HC2OPMode beide auf "auto", und da ich heute zuhause bin setze ich auch Hc1SFMode und HC2SFMode auf "onedaybankholiday". Das geling aber nur für den Heizkreis 1. Beim Heizkreis 2 stelle ich fest:
- Hc2OPMode ist laut csv nur lesbar, der Schreibzugriff darauf wird also konsequenterweise abgelehnt. Ist das dort vielleicht falsch gepflegt?
- Hc2SFMode ist laut csv schreibbar und kann auch geschrieben werden. Der Wert setzt sich aber merkwürdigerweise nach kurzer Zeit von selbst wieder zurück auf none.
Hat vielleicht jemand von Euch so etwas ähnliches auch schon festgestellt? Sollte ich einfach mal versuchen, die csv für Hc2OPMode anzupassen? Aber wie erklärt sich das automatische Rücksetzen von Hc2SFMode?
Setze ich die Betriebsarten nicht mit fhem sondern mit dem Vaillant-Bedienterminal, funktioniert alles, und ich lese auch für beide Heizkreise die erwarteten Werte zurück.
Vielleicht gibt es noch eine Abhängigkeit zum Parameter OpModeEffect, der aktuell auf "2" steht. Nach meinem Verständnis wird dort festgelegt, auf welche Heizkreise sich die Vorgabe durch das Bedienterminal auswirken soll. Laut csv sind aber nur folgende Werte definiert: 0=HC1;1=HC2;3=HC1+HC2. Was "2" bedeutet, kann ich dort nicht sehen.
Ich hoffe auf Vaillant-kundige, die mir eine Tipp geben können, was ich probieren sollte...
Meine Heizungsanlage besteht aus:
- Therme ecoTEC plus VC DE 206/5-5 R2
- Mischermodul VR61
- Bedienterminal und Regler calorMATIC 470f
- Funkaußenfühler VR21 (DCF77)
Danke für Eure Hilfe!
Zitat von: Dre83 am 11 Oktober 2021, 17:57:02
ich habe nur die Ordner im Contrib Ordner.
das ist der contrib Ordner vom ebusd clone. Du bräuchtest wenn dann einen clone von ebusd-configuration (https://github.com/john30/ebusd-configuration/) und würdest dann den configpath auf einen Ordner darin umstellen.
Wenn Du eigene CSVs erzeugen willst, ist der "kleine Umweg" über Libreoffice o.ä. auf jeden Fall hilfreich, denn sonst muss man schon sehr genau schauen, in welche Spalte was rein kommt. Hilfreich könnte dabei aber noch das relativ junge "define" Kommando des ebusd CLI (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#define) sein.
Zitat von: beaune am 12 Oktober 2021, 11:39:52
Hat vielleicht jemand von Euch so etwas ähnliches auch schon festgestellt? Sollte ich einfach mal versuchen, die csv für Hc2OPMode anzupassen? Aber wie erklärt sich das automatische Rücksetzen von Hc2SFMode?
M.W. ist Hc1 meist als Synonym für die Hitzegenerierung verstanden, also bspw. der Gasbrenner oder die der Primärkreis des Wärmetauschers bei einer Wärmepumpe. Hc2 und folgende sind dann die eigentlichen Innenraum-Heizkreise (i.d.R. nur einer). Daher könnte ich mir grundlegende Unterschiede vorstellen.
Das Rücksetzen wird vermutlich durch den Controller verursacht. Das ist auch der Grund, warum direktes Schreiben an Hc1/Hc2 bei Existenz eines Controllers eher sinnlos sind, da dieser das wieder nachjustiert. Hier also besser nach Einstellungen im Controller suchen, die das Verhalten beeinflussen können, bspw. die Heizkurve.
Hi,
Ich habe versuch ebusd auf diesen heizung angeschlossen Protherm Panther Condens 25 und habe ich folgendes error on ebusd
Ich weiß nicht was diese scan config 08: ERR: read timeout bedeutet
Danke fur Hilfe
main error
2021-10-17 23:10:26.745 [main error] scan config 08: ERR: read timeout
ebusctl info
version: ebusd 21.2.v21.2-48-g24a6525
update check: revision v21.2 available
signal: acquired
symbol rate: 23
max symbol rate: 28
min arbitration micros: 3
max arbitration micros: 3
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 03: master #11
address 04: slave #25, ebusd
address ff: master #25, ebusd
Zitat von: sonbaty1 am 18 Oktober 2021, 18:03:41
Ich weiß nicht was diese scan config 08: ERR: read timeout bedeutet
was für einen Adapter hast Du denn?
Hi,
Habe ich Ebus adapter v2.2 und habe ich mir einen Ebus 3 fur sicherheit bestellt.
Danke
Hallo,
Kann mir jemand mit einer Vaillant-Therme sagen, wie man die Solarpumpe per ebus starten kann ?
Programm P0 , SP lässt die Pumpe laufen, um den Volumenstrom einstellen zu können oder zu entlüften.
Im Winter wäre es praktisch, bei Schnee auf den Kollektoren die Solarpumpe laufen zu lassen, damit der Schnee antaut und dann schneller abrutschen kann, da das warme Wasser aus der Therme zu den Kollektoren kommt ...
Hallo, ich besitze eine CWL Brink Renovent Excellent und versuchte bisher vergeblich das Ebus in Betrieb zu nehmen. Ich hoffe mir kann hier jemand weiterhelfen.
-Ich besitze den ebus Adapter 3
-Angeschlossen via USB /dev/ttyUSB2 an einen Raspberry PI
-grüne LED am Adapter blinkt hochfrequent mehr oder weniger zufällig
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 37
max symbol rate: 39
reconnects: 0
masters: 1
messages: 86
conditional: 0
poll: 61
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
-parameter sind von hier: https://github.com/dstrigl/ebusd-config-brink-renovent-excellent-300
im log tut sich das nach reboot:
2021-10-24 15:31:43.715 [main notice] ebusd 21.2.v21.2 started with full scan on device /dev/ttyUSB2
2021-10-24 15:31:43.726 [main info] loading configuration files from /etc/ebusd
2021-10-24 15:31:43.746 [main info] reading templates /
2021-10-24 15:31:43.754 [main info] read templates in /
2021-10-24 15:31:43.754 [main info] reading file broadcast.csv
2021-10-24 15:31:43.758 [main info] successfully read file broadcast.csv
2021-10-24 15:31:43.758 [main info] reading file memory.csv
2021-10-24 15:31:43.759 [main info] successfully read file memory.csv
2021-10-24 15:31:43.759 [main info] reading file 3c.renovent-excellent-300.csv
2021-10-24 15:31:43.765 [main info] successfully read file 3c.renovent-excellent-300.csv
2021-10-24 15:31:43.765 [main info] read config files
2021-10-24 15:31:43.771 [bus notice] bus started with own address 31/36
2021-10-24 15:31:43.772 [main info] registering data handlers
2021-10-24 15:31:43.772 [main info] registered data handlers
2021-10-24 15:31:43.791 [bus notice] signal acquired
2021-10-24 15:32:02.621 [main debug] performing regular tasks
2021-10-24 15:32:02.621 [main notice] starting initial full scan
2021-10-24 15:32:02.621 [bus info] scan 02 cmd: 3102070400
2021-10-24 15:32:12.145 [network info] [00001] client connection opened 127.0.0.1
2021-10-24 15:32:12.145 [network debug] [00001] wait for result
2021-10-24 15:32:12.145 [main debug] performing regular tasks
2021-10-24 15:32:12.145 [main debug] >>> info
2021-10-24 15:32:12.145 [main debug] <<< version: ebusd 21.2.v21.2
signal: acquired
symbol rate: 37
max symbol rate: 39
reconnects: 0
masters ...
2021-10-24 15:32:12.146 [network info] [00001] connection closed
2021-10-24 15:32:13.146 [network debug] dead connection removed - 0
2021-10-24 15:32:22.145 [main debug] performing regular tasks
2021-10-24 15:32:32.146 [main debug] performing regular tasks
2021-10-24 15:32:42.146 [main debug] performing regular tasks
-setze ich einen Befehl ab, zB
ebusctl read Aussenlufttemperatur
hängt die Verarbeitung und im log steht
2021-10-24 15:15:58.007 [network info] [00009] client connection opened 127.0.0.1
2021-10-24 15:15:58.008 [network debug] [00009] wait for result
2021-10-24 15:15:58.008 [main debug] >>> read Aussenlufttemperatur
2021-10-24 15:15:58.008 [bus info] send message: 313c40220108
Zitat von: boellner am 24 Oktober 2021, 15:36:29
-Ich besitze den ebus Adapter 3
-Angeschlossen via USB /dev/ttyUSB2 an einen Raspberry PI
-grüne LED am Adapter blinkt hochfrequent mehr oder weniger zufällig
hast Du den "enh:" Präfix am Device String dran für den enhanced mode? Oder hast Du den Jumper für non-enhanced gesetzt?
danke für den Hinweis, das hatte nicht gestimmt. Jumper am J12 auf non-enhanced hat keine Verbesserung gebracht.
Mit dem Präfix bekomme ich jetzt diese Ausgabe
pi@raspberrypi:~ $ ebusd -f --logareas bus --loglevel debug --device=enh:/dev/ttyUSB3 -c /home/pi/encon
2021-10-24 22:24:44.416 [bus notice] bus started with own address 31/36
2021-10-24 22:24:44.423 [bus debug] ERR: SYN received during no signal, switching to ready
2021-10-24 22:24:44.424 [bus notice] signal acquired
2021-10-24 22:24:44.426 [bus info] poll cmd: 313c40500121
2021-10-24 22:24:44.426 [bus debug] start request 31
2021-10-24 22:24:44.426 [bus debug] arbitration start with 31
2021-10-24 22:24:44.458 [bus notice] device status: reset
2021-10-24 22:24:44.458 [bus error] arbitration start error
2021-10-24 22:24:44.459 [bus debug] ERR: arbitration lost during ready, retry
2021-10-24 22:24:44.461 [bus debug] start request 31
2021-10-24 22:24:44.462 [bus debug] arbitration start with 31
2021-10-24 22:24:44.500 [bus debug] ERR: read timeout during receive command, switching to skip
2021-10-24 22:24:44.525 [bus debug] arbitration won
2021-10-24 22:24:44.525 [bus debug] arbitration delay 715 micros
2021-10-24 22:24:44.525 [bus info] arbitration delay 715 - 715 micros
2021-10-24 22:24:44.525 [bus debug] switching from ready to send command
2021-10-24 22:24:44.539 [bus debug] notify request: ERR: read timeout
2021-10-24 22:24:44.539 [bus error] poll kwl LuftmengeStufe0 failed: ERR: read timeout
2021-10-24 22:24:44.539 [bus debug] ERR: read timeout during send command, switching to skip
2021-10-24 22:24:45.992 [bus notice] new master 37, master count 2
2021-10-24 22:24:46.020 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-24 22:24:47.500 [bus notice] new master 1f, master count 3
2021-10-24 22:24:47.528 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-24 22:24:47.648 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-24 22:24:47.775 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-24 22:24:47.895 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-24 22:24:50.038 [bus info] poll cmd: 313c40500101
2021-10-24 22:24:50.038 [bus debug] start request 31
2021-10-24 22:24:50.038 [bus debug] arbitration start with 31
2021-10-24 22:24:50.086 [bus debug] arbitration won
2021-10-24 22:24:50.086 [bus debug] arbitration delay 1851 micros
2021-10-24 22:24:50.086 [bus info] arbitration delay 715 - 1851 micros
2021-10-24 22:24:50.086 [bus debug] switching from ready to send command
2021-10-24 22:24:50.099 [bus debug] send/receive symbol latency 11 ms
2021-10-24 22:24:50.099 [bus info] send/receive symbol latency 11 - 11 ms
2021-10-24 22:24:50.113 [bus debug] send/receive symbol latency 11 ms
2021-10-24 22:24:50.127 [bus debug] notify request: ERR: read timeout
2021-10-24 22:24:50.127 [bus error] poll kwl LuftmengeStufe1 failed: ERR: read timeout
2021-10-24 22:24:50.127 [bus debug] ERR: read timeout during send command, switching to skip
2021-10-24 22:24:51.086 [bus debug] ERR: read timeout during receive command ACK, switching to skip
Zitat von: boellner am 24 Oktober 2021, 22:28:52
danke für den Hinweis, das hatte nicht gestimmt. Jumper am J12 auf non-enhanced hat keine Verbesserung gebracht.
Mit dem Präfix bekomme ich jetzt diese Ausgabe
kannst du mal mit --lograwdata=bytes starten und mir den output posten?
ich habe jetzt mit latency herumgespielt
ebusd -f --logareas bus --pollinterval=1 --enablehex --loglevel info --device=enh:/dev/ttyUSB3 -c /home/pi/encon --scanconfig --latency=20000
damit bekomme ich daten
pi@raspberrypi:~ $ ebusctl grab result all
1f3c070400 / 0a400816002103ffffffff = 1: scan.3c
1f3c40220107 / 0200d2 = 1: kwl Ablufttemperatur
1f3c40220108 / 02008d = 1: kwl Aussenlufttemperatur
1f3c4022010b / 020032 = 1: kwl TatsaechlicheZuluftmenge
1f3c4022010c / 020031 = 1: kwl TatsaechlicheAbluftmenge
1f3c40220114 / 020384 = 1: kwl IstwertZuluftdruck
1f3c40220115 / 0201ae = 1: kwl IstwertAbluftdruck
1f3c40220120 / 020000 = 1: kwl Feuchte
1f3c40220128 / 020001 = 1: kwl CO2Sensor1Status
jetzt habe ich noch das Problem auf den Ebus zu schreiben. Egal was ich mache
ebusctl hex 3c40A106000300030000
ebusctl write -c kwl Ventilatorbetrieb Normal
ebusctl und ebusd friert ein oder schein für lange zeit inaktiv zu werden so dass ich ihn nur abschiessen kann.
Zitat von: boellner am 27 Oktober 2021, 21:54:14
jetzt habe ich noch das Problem auf den Ebus zu schreiben. Egal was ich mache
ebusctl und ebusd friert ein oder schein für lange zeit inaktiv zu werden so dass ich ihn nur abschiessen kann.
mach mal für den Anfang das pollinterval raus und poste wie angefragt ein logging mit rawbytes
es sieht immer nach diesem Muster aus:
2021-10-28 20:37:22.355 [bus notice] <aa
2021-10-28 20:37:22.402 [bus notice] <aa
2021-10-28 20:37:22.405 [bus notice] <1f
2021-10-28 20:37:22.411 [bus notice] <3c
2021-10-28 20:37:22.415 [bus notice] <40
2021-10-28 20:37:22.419 [bus notice] <22
2021-10-28 20:37:22.423 [bus notice] <01
2021-10-28 20:37:22.427 [bus notice] <29
2021-10-28 20:37:22.433 [bus notice] <d2
2021-10-28 20:37:22.436 [bus notice] <00
2021-10-28 20:37:22.440 [bus notice] <02
2021-10-28 20:37:22.444 [bus notice] <00
2021-10-28 20:37:22.448 [bus notice] <00
2021-10-28 20:37:22.452 [bus notice] <2c
2021-10-28 20:37:22.458 [bus notice] <00
2021-10-28 20:37:22.458 [update notice] received unknown MS cmd: 1f3c40220129 / 020000
2021-10-28 20:37:22.463 [bus notice] <aa
2021-10-28 20:37:22.509 [bus notice] <aa
2021-10-28 20:37:22.513 [bus notice] <1f
2021-10-28 20:37:22.519 [bus notice] <3c
2021-10-28 20:37:22.523 [bus notice] <40
2021-10-28 20:37:22.527 [bus notice] <22
2021-10-28 20:37:22.531 [bus notice] <01
2021-10-28 20:37:22.535 [bus notice] <2a
2021-10-28 20:37:22.540 [bus notice] <d1
2021-10-28 20:37:22.544 [bus notice] <00
2021-10-28 20:37:22.548 [bus notice] <02
2021-10-28 20:37:22.552 [bus notice] <00
2021-10-28 20:37:22.556 [bus notice] <01
2021-10-28 20:37:22.560 [bus notice] <2d
2021-10-28 20:37:22.566 [bus notice] <00
2021-10-28 20:37:22.566 [update notice] received unknown MS cmd: 1f3c4022012a / 020001
2021-10-28 20:37:22.571 [bus notice] <aa
2021-10-28 20:37:22.618 [bus notice] <aa
2021-10-28 20:37:22.621 [bus notice] <1f
2021-10-28 20:37:22.627 [bus notice] <3c
2021-10-28 20:37:22.631 [bus notice] <40
2021-10-28 20:37:22.635 [bus notice] <22
2021-10-28 20:37:22.639 [bus notice] <01
2021-10-28 20:37:22.643 [bus notice] <2b
2021-10-28 20:37:22.649 [bus notice] <d0
2021-10-28 20:37:22.652 [bus notice] <00
2021-10-28 20:37:22.656 [bus notice] <02
^C2021-10-28 20:37:22.657 [main notice] SIGINT received
2021-10-28 20:37:22.660 [bus notice] <00
2021-10-28 20:37:22.664 [bus notice] <00
2021-10-28 20:37:22.668 [bus notice] <2c
2021-10-28 20:37:22.674 [bus notice] <00
2021-10-28 20:37:22.674 [update notice] received unknown MS cmd: 1f3c4022012b / 020000
2021-10-28 20:37:22.679 [bus notice] <aa
2021-10-28 20:37:22.725 [bus notice] <aa
2021-10-28 20:37:22.728 [bus notice] <1f
2021-10-28 20:37:22.734 [bus notice] <3c
2021-10-28 20:37:22.738 [bus notice] <40
2021-10-28 20:37:22.742 [bus notice] <22
2021-10-28 20:37:22.746 [bus notice] <01
2021-10-28 20:37:22.750 [bus notice] <2c
2021-10-28 20:37:22.756 [bus notice] <d7
2021-10-28 20:37:22.759 [bus notice] <00
2021-10-28 20:37:22.763 [bus notice] <02
2021-10-28 20:37:22.767 [bus notice] <00
2021-10-28 20:37:22.771 [bus notice] <01
2021-10-28 20:37:22.775 [bus notice] <2d
2021-10-28 20:37:22.781 [bus notice] <00
2021-10-28 20:37:22.781 [update notice] received unknown MS cmd: 1f3c4022012c / 020001
2021-10-28 20:37:22.786 [bus notice] <aa
2021-10-28 20:37:22.833 [bus notice] <aa
2021-10-28 20:37:22.836 [bus notice] <1f
2021-10-28 20:37:22.842 [bus notice] <3c
2021-10-28 20:37:22.846 [bus notice] <40
2021-10-28 20:37:22.850 [bus notice] <22
2021-10-28 20:37:22.854 [bus notice] <01
2021-10-28 20:37:22.858 [bus notice] <2d
2021-10-28 20:37:22.863 [bus notice] <d6
2021-10-28 20:37:22.867 [bus notice] <00
2021-10-28 20:37:22.871 [bus notice] <02
2021-10-28 20:37:22.875 [bus notice] <00
2021-10-28 20:37:22.879 [bus notice] <00
2021-10-28 20:37:22.883 [bus notice] <2c
2021-10-28 20:37:22.889 [bus notice] <00
2021-10-28 20:37:22.889 [update notice] received unknown MS cmd: 1f3c4022012d / 020000
2021-10-28 20:37:22.894 [bus notice] <aa
2021-10-28 20:37:22.940 [bus notice] <aa
2021-10-28 20:37:22.943 [bus notice] <1f
2021-10-28 20:37:22.949 [bus notice] <3c
2021-10-28 20:37:22.953 [bus notice] <40
2021-10-28 20:37:22.957 [bus notice] <22
2021-10-28 20:37:22.961 [bus notice] <01
2021-10-28 20:37:22.965 [bus notice] <2e
2021-10-28 20:37:22.971 [bus notice] <d5
2021-10-28 20:37:22.974 [bus notice] <00
2021-10-28 20:37:22.978 [bus notice] <02
2021-10-28 20:37:22.982 [bus notice] <00
2021-10-28 20:37:22.986 [bus notice] <01
2021-10-28 20:37:22.990 [bus notice] <2d
2021-10-28 20:37:22.996 [bus notice] <00
Zitat von: boellner am 28 Oktober 2021, 20:39:21
es sieht immer nach diesem Muster aus:
2021-10-28 20:37:22.355 [bus notice] <aa
2021-10-28 20:37:22.402 [bus notice] <aa
2021-10-28 20:37:22.405 [bus notice] <1f
2021-10-28 20:37:22.411 [bus notice] <3c
2021-10-28 20:37:22.415 [bus notice] <40
2021-10-28 20:37:22.419 [bus notice] <22
2021-10-28 20:37:22.423 [bus notice] <01
2021-10-28 20:37:22.427 [bus notice] <29
2021-10-28 20:37:22.433 [bus notice] <d2
2021-10-28 20:37:22.436 [bus notice] <00
2021-10-28 20:37:22.440 [bus notice] <02
2021-10-28 20:37:22.444 [bus notice] <00
2021-10-28 20:37:22.448 [bus notice] <00
2021-10-28 20:37:22.452 [bus notice] <2c
2021-10-28 20:37:22.458 [bus notice] <00
2021-10-28 20:37:22.458 [update notice] received unknown MS cmd: 1f3c40220129 / 020000
2021-10-28 20:37:22.463 [bus notice] <aa
2021-10-28 20:37:22.509 [bus notice] <aa
2021-10-28 20:37:22.513 [bus notice] <1f
2021-10-28 20:37:22.519 [bus notice] <3c
2021-10-28 20:37:22.523 [bus notice] <40
2021-10-28 20:37:22.527 [bus notice] <22
2021-10-28 20:37:22.531 [bus notice] <01
2021-10-28 20:37:22.535 [bus notice] <2a
2021-10-28 20:37:22.540 [bus notice] <d1
2021-10-28 20:37:22.544 [bus notice] <00
2021-10-28 20:37:22.548 [bus notice] <02
2021-10-28 20:37:22.552 [bus notice] <00
2021-10-28 20:37:22.556 [bus notice] <01
2021-10-28 20:37:22.560 [bus notice] <2d
2021-10-28 20:37:22.566 [bus notice] <00
2021-10-28 20:37:22.566 [update notice] received unknown MS cmd: 1f3c4022012a / 020001
2021-10-28 20:37:22.571 [bus notice] <aa
2021-10-28 20:37:22.618 [bus notice] <aa
2021-10-28 20:37:22.621 [bus notice] <1f
2021-10-28 20:37:22.627 [bus notice] <3c
2021-10-28 20:37:22.631 [bus notice] <40
2021-10-28 20:37:22.635 [bus notice] <22
2021-10-28 20:37:22.639 [bus notice] <01
2021-10-28 20:37:22.643 [bus notice] <2b
2021-10-28 20:37:22.649 [bus notice] <d0
2021-10-28 20:37:22.652 [bus notice] <00
2021-10-28 20:37:22.656 [bus notice] <02
^C2021-10-28 20:37:22.657 [main notice] SIGINT received
2021-10-28 20:37:22.660 [bus notice] <00
2021-10-28 20:37:22.664 [bus notice] <00
2021-10-28 20:37:22.668 [bus notice] <2c
2021-10-28 20:37:22.674 [bus notice] <00
2021-10-28 20:37:22.674 [update notice] received unknown MS cmd: 1f3c4022012b / 020000
2021-10-28 20:37:22.679 [bus notice] <aa
2021-10-28 20:37:22.725 [bus notice] <aa
2021-10-28 20:37:22.728 [bus notice] <1f
2021-10-28 20:37:22.734 [bus notice] <3c
2021-10-28 20:37:22.738 [bus notice] <40
2021-10-28 20:37:22.742 [bus notice] <22
2021-10-28 20:37:22.746 [bus notice] <01
2021-10-28 20:37:22.750 [bus notice] <2c
2021-10-28 20:37:22.756 [bus notice] <d7
2021-10-28 20:37:22.759 [bus notice] <00
2021-10-28 20:37:22.763 [bus notice] <02
2021-10-28 20:37:22.767 [bus notice] <00
2021-10-28 20:37:22.771 [bus notice] <01
2021-10-28 20:37:22.775 [bus notice] <2d
2021-10-28 20:37:22.781 [bus notice] <00
2021-10-28 20:37:22.781 [update notice] received unknown MS cmd: 1f3c4022012c / 020001
2021-10-28 20:37:22.786 [bus notice] <aa
2021-10-28 20:37:22.833 [bus notice] <aa
2021-10-28 20:37:22.836 [bus notice] <1f
2021-10-28 20:37:22.842 [bus notice] <3c
2021-10-28 20:37:22.846 [bus notice] <40
2021-10-28 20:37:22.850 [bus notice] <22
2021-10-28 20:37:22.854 [bus notice] <01
2021-10-28 20:37:22.858 [bus notice] <2d
2021-10-28 20:37:22.863 [bus notice] <d6
2021-10-28 20:37:22.867 [bus notice] <00
2021-10-28 20:37:22.871 [bus notice] <02
2021-10-28 20:37:22.875 [bus notice] <00
2021-10-28 20:37:22.879 [bus notice] <00
2021-10-28 20:37:22.883 [bus notice] <2c
2021-10-28 20:37:22.889 [bus notice] <00
2021-10-28 20:37:22.889 [update notice] received unknown MS cmd: 1f3c4022012d / 020000
2021-10-28 20:37:22.894 [bus notice] <aa
2021-10-28 20:37:22.940 [bus notice] <aa
2021-10-28 20:37:22.943 [bus notice] <1f
2021-10-28 20:37:22.949 [bus notice] <3c
2021-10-28 20:37:22.953 [bus notice] <40
2021-10-28 20:37:22.957 [bus notice] <22
2021-10-28 20:37:22.961 [bus notice] <01
2021-10-28 20:37:22.965 [bus notice] <2e
2021-10-28 20:37:22.971 [bus notice] <d5
2021-10-28 20:37:22.974 [bus notice] <00
2021-10-28 20:37:22.978 [bus notice] <02
2021-10-28 20:37:22.982 [bus notice] <00
2021-10-28 20:37:22.986 [bus notice] <01
2021-10-28 20:37:22.990 [bus notice] <2d
2021-10-28 20:37:22.996 [bus notice] <00
da sehe ich jetzt noch nichts unstimmiges. du hast geschrieben, dass das Senden nicht klappt. mach doch bitte mal noch ein log wie oben, in dem auch der Schreibversuch zu sehen ist
Ich habe an der Anlage eigentlich nichts verändert. Ich kann heute Kommandos absetzen und die Lüftungsstufe ändern (was mir ein angestecktes Display nach 5s überschreibt, ohne Display ca 1-2 Min):
start server mit:
ebusd -f --enablehex --loglevel debug --device=enh:/dev/ttyUSB2 -c /etc/ebusd --latency=20000
ebusctl write -c kwl Ventilatorbetrieb Intensiv
alles gut
2021-10-30 20:41:35.693 [main notice] found messages: 75 (0 conditional on 0 conditions, 61 poll, 0 update)
2021-10-30 20:41:35.693 [main debug] >>> write -c kwl Ventilatorbetrieb Intensiv
2021-10-30 20:41:35.693 [bus info] send message: 313c40a1050003000300
2021-10-30 20:41:35.705 [bus debug] start request 31
2021-10-30 20:41:35.706 [bus debug] arbitration start with 31
2021-10-30 20:41:35.754 [bus debug] arbitration won
2021-10-30 20:41:35.754 [bus debug] arbitration delay 1128 micros
2021-10-30 20:41:35.754 [bus debug] switching from ready to send command
2021-10-30 20:41:35.768 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.782 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.798 [bus debug] send/receive symbol latency 12 ms
2021-10-30 20:41:35.811 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.826 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.840 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.854 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.868 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.882 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.882 [bus debug] switching from send command to send command CRC
2021-10-30 20:41:35.896 [bus debug] send/receive symbol latency 10 ms
2021-10-30 20:41:35.896 [bus info] send/receive symbol latency 10 - 12 ms
2021-10-30 20:41:35.896 [bus debug] switching from send command CRC to receive command ACK
2021-10-30 20:41:35.901 [bus debug] switching from receive command ACK to receive response
2021-10-30 20:41:35.913 [bus debug] switching from receive response to receive response CRC
2021-10-30 20:41:35.917 [bus debug] switching from receive response CRC to send response ACK
2021-10-30 20:41:35.930 [bus debug] send/receive symbol latency 11 ms
2021-10-30 20:41:35.930 [update info] sent MS cmd: 313c40a1050003000300 / 022000
2021-10-30 20:41:35.931 [update notice] sent write kwl Ventilatorbetrieb QQ=31: Intensiv
2021-10-30 20:41:35.931 [bus debug] notify request: done
2021-10-30 20:41:35.931 [bus debug] read res: 313c40a1050003000300
2021-10-30 20:41:35.931 [bus debug] switching from send response ACK to send SYN
2021-10-30 20:41:35.931 [main notice] write kwl Ventilatorbetrieb: done
2021-10-30 20:41:35.931 [main debug] <<< done
2021-10-30 20:41:35.932 [network info] [00001] connection closed
2021-10-30 20:41:35.945 [bus debug] send/receive symbol latency 12 ms
2021-10-30 20:41:36.693 [network debug] dead connection removed - 0
Das ist das Raw log zum Schreiben dazu, aber wie gesagt das geht jetzt:
2021-10-30 21:03:25.316 [main debug] >>> write -c kwl Ventilatorbetrieb Feuchteschutz
2021-10-30 21:03:25.316 [bus info] send message: 313c40a1050000000000
2021-10-30 21:03:25.316 [network debug] [00001] wait for result
2021-10-30 21:03:25.345 [bus notice] <aa
2021-10-30 21:03:25.346 [bus debug] start request 31
2021-10-30 21:03:25.346 [bus debug] arbitration start with 31
2021-10-30 21:03:25.391 [bus notice] <aa
2021-10-30 21:03:25.395 [bus notice] >31
2021-10-30 21:03:25.395 [bus notice] <31
2021-10-30 21:03:25.395 [bus debug] arbitration won
2021-10-30 21:03:25.395 [bus debug] arbitration delay 2240 micros
2021-10-30 21:03:25.395 [bus info] arbitration delay 797 - 2240 micros
2021-10-30 21:03:25.395 [bus debug] switching from ready to send command
2021-10-30 21:03:25.398 [bus notice] >3c
2021-10-30 21:03:25.409 [bus notice] <3c
2021-10-30 21:03:25.409 [bus debug] send/receive symbol latency 10 ms
2021-10-30 21:03:25.409 [bus info] send/receive symbol latency 10 - 12 ms
2021-10-30 21:03:25.412 [bus notice] >40
2021-10-30 21:03:25.423 [bus notice] <40
2021-10-30 21:03:25.423 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.426 [bus notice] >a1
2021-10-30 21:03:25.439 [bus notice] <a1
2021-10-30 21:03:25.439 [bus debug] send/receive symbol latency 12 ms
2021-10-30 21:03:25.441 [bus notice] >05
2021-10-30 21:03:25.452 [bus notice] <05
2021-10-30 21:03:25.452 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.455 [bus notice] >00
2021-10-30 21:03:25.466 [bus notice] <00
2021-10-30 21:03:25.466 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.469 [bus notice] >00
2021-10-30 21:03:25.480 [bus notice] <00
2021-10-30 21:03:25.481 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.483 [bus notice] >00
2021-10-30 21:03:25.495 [bus notice] <00
2021-10-30 21:03:25.495 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.498 [bus notice] >00
2021-10-30 21:03:25.509 [bus notice] <00
2021-10-30 21:03:25.509 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.512 [bus notice] >00
2021-10-30 21:03:25.523 [bus notice] <00
2021-10-30 21:03:25.524 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.524 [bus debug] switching from send command to send command CRC
2021-10-30 21:03:25.526 [bus notice] >a4
2021-10-30 21:03:25.539 [bus notice] <a4
2021-10-30 21:03:25.539 [bus debug] send/receive symbol latency 12 ms
2021-10-30 21:03:25.539 [bus debug] switching from send command CRC to receive command ACK
2021-10-30 21:03:25.542 [bus notice] <00
2021-10-30 21:03:25.542 [bus debug] switching from receive command ACK to receive response
2021-10-30 21:03:25.546 [bus notice] <02
2021-10-30 21:03:25.550 [bus notice] <20
2021-10-30 21:03:25.554 [bus notice] <00
2021-10-30 21:03:25.554 [bus debug] switching from receive response to receive response CRC
2021-10-30 21:03:25.558 [bus notice] <48
2021-10-30 21:03:25.558 [bus debug] switching from receive response CRC to send response ACK
2021-10-30 21:03:25.560 [bus notice] >00
2021-10-30 21:03:25.572 [bus notice] <00
2021-10-30 21:03:25.572 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:03:25.572 [update info] sent MS cmd: 313c40a1050000000000 / 022000
2021-10-30 21:03:25.572 [update notice] sent write kwl Ventilatorbetrieb QQ=31: Feuchteschutz
2021-10-30 21:03:25.572 [bus debug] notify request: done
2021-10-30 21:03:25.572 [bus debug] read res: 313c40a1050000000000
2021-10-30 21:03:25.572 [bus debug] switching from send response ACK to send SYN
2021-10-30 21:03:25.572 [main notice] write kwl Ventilatorbetrieb: done
2021-10-30 21:03:25.573 [main debug] <<< done
2021-10-30 21:03:25.573 [network info] [00001] connection closed
2021-10-30 21:03:25.575 [bus notice] >aa
2021-10-30 21:03:25.587 [bus notice] <aa
2021-10-30 21:03:25.587 [bus debug] send/receive symbol latency 12 ms
2021-10-30 21:03:25.633 [bus notice] <aa
2021-10-30 21:03:25.680 [bus notice] <aa
Neues Problem, nach ca 30s ist die Verbindung unterbrochen und nichts geht mehr. Im log kommt ein:
[bus error] device status: unexpected available enhanced byte 2
Was kann das sein?
2021-10-30 21:08:35.242 [bus debug] send/receive symbol latency 11 ms
2021-10-30 21:08:35.242 [update info] sent MS cmd: 313c40500133 / 0a0000fffe000200010000
2021-10-30 21:08:35.242 [update notice] sent poll-read kwl RHSensorEmpfindlichkeit QQ=31: 0;-2;2;1;0
2021-10-30 21:08:35.242 [bus debug] notify request: done
2021-10-30 21:08:35.242 [bus debug] switching from send response ACK to send SYN
2021-10-30 21:08:35.245 [bus notice] >aa
2021-10-30 21:08:35.257 [bus notice] <aa
2021-10-30 21:08:35.257 [bus debug] send/receive symbol latency 12 ms
2021-10-30 21:08:35.304 [bus notice] <aa
2021-10-30 21:08:35.350 [bus notice] <aa
2021-10-30 21:08:35.397 [bus notice] <aa
2021-10-30 21:08:35.444 [bus notice] <aa
2021-10-30 21:08:35.490 [bus notice] <aa
2021-10-30 21:08:35.536 [bus notice] <aa
2021-10-30 21:08:35.582 [bus notice] <aa
2021-10-30 21:08:35.628 [bus notice] <aa
2021-10-30 21:08:35.674 [bus notice] <aa
2021-10-30 21:08:35.720 [bus notice] <aa
2021-10-30 21:08:35.766 [bus notice] <aa
2021-10-30 21:08:35.813 [bus notice] <aa
2021-10-30 21:08:35.860 [bus notice] <aa
2021-10-30 21:08:35.906 [bus notice] <aa
2021-10-30 21:08:35.952 [bus notice] <aa
2021-10-30 21:08:35.999 [bus notice] <aa
2021-10-30 21:08:36.045 [bus notice] <aa
2021-10-30 21:08:36.091 [bus notice] <aa
2021-10-30 21:08:36.138 [bus notice] <aa
2021-10-30 21:08:36.184 [bus notice] <aa
2021-10-30 21:08:36.231 [bus notice] <aa
2021-10-30 21:08:36.277 [bus notice] <aa
2021-10-30 21:08:36.280 [bus notice] <37
2021-10-30 21:08:36.284 [bus notice] <5e
2021-10-30 21:08:36.288 [bus notice] <40
2021-10-30 21:08:36.294 [bus notice] <a0
2021-10-30 21:08:36.297 [bus notice] <04
2021-10-30 21:08:36.301 [bus notice] <00
2021-10-30 21:08:36.305 [bus notice] <32
2021-10-30 21:08:36.309 [bus notice] <00
2021-10-30 21:08:36.313 [bus notice] <32
2021-10-30 21:08:36.318 [bus notice] <21
2021-10-30 21:08:36.341 [main debug] performing regular tasks
2021-10-30 21:08:36.364 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2021-10-30 21:08:36.372 [bus notice] <aa
2021-10-30 21:08:36.418 [bus notice] <aa
2021-10-30 21:08:36.464 [bus notice] <aa
2021-10-30 21:08:36.510 [bus notice] <aa
2021-10-30 21:08:36.556 [bus notice] <aa
2021-10-30 21:08:36.602 [bus notice] <aa
2021-10-30 21:08:36.648 [bus notice] <aa
2021-10-30 21:08:36.694 [bus notice] <aa
2021-10-30 21:08:36.740 [bus notice] <aa
2021-10-30 21:08:36.787 [bus notice] <aa
2021-10-30 21:08:36.834 [bus notice] <aa
2021-10-30 21:08:36.880 [bus notice] <aa
2021-10-30 21:08:36.930 [bus notice] <aa
2021-10-30 21:08:36.976 [bus notice] <aa
2021-10-30 21:08:37.022 [bus notice] <aa
2021-10-30 21:08:37.068 [bus notice] <aa
2021-10-30 21:08:37.114 [bus notice] <aa
2021-10-30 21:08:37.160 [bus notice] <aa
2021-10-30 21:08:37.206 [bus notice] <aa
2021-10-30 21:08:37.252 [bus notice] <aa
2021-10-30 21:08:37.298 [bus notice] <aa
2021-10-30 21:08:37.344 [bus notice] <aa
2021-10-30 21:08:37.391 [bus notice] <aa
2021-10-30 21:08:37.437 [bus notice] <aa
2021-10-30 21:08:37.483 [bus notice] <aa
2021-10-30 21:08:37.530 [bus notice] <aa
2021-10-30 21:08:37.577 [bus notice] <aa
2021-10-30 21:08:37.623 [bus notice] <aa
2021-10-30 21:08:37.669 [bus notice] <aa
2021-10-30 21:08:37.716 [bus notice] <aa
2021-10-30 21:08:37.761 [bus notice] <aa
2021-10-30 21:08:37.809 [bus notice] <aa
2021-10-30 21:08:37.855 [bus notice] <aa
2021-10-30 21:08:37.901 [bus notice] <aa
2021-10-30 21:08:37.947 [bus notice] <aa
2021-10-30 21:08:37.993 [bus notice] <aa
2021-10-30 21:08:38.039 [bus notice] <aa
2021-10-30 21:08:38.085 [bus notice] <aa
2021-10-30 21:08:38.131 [bus notice] <aa
2021-10-30 21:08:38.178 [bus notice] <aa
2021-10-30 21:08:38.225 [bus notice] <aa
2021-10-30 21:08:38.275 [bus notice] <aa
2021-10-30 21:08:38.321 [bus notice] <aa
2021-10-30 21:08:38.367 [bus notice] <aa
2021-10-30 21:08:38.413 [bus notice] <aa
2021-10-30 21:08:38.459 [bus notice] <aa
2021-10-30 21:08:38.505 [bus notice] <aa
2021-10-30 21:08:38.551 [bus notice] <aa
2021-10-30 21:08:38.598 [bus notice] <aa
2021-10-30 21:08:38.644 [bus notice] <aa
2021-10-30 21:08:38.691 [bus notice] <aa
2021-10-30 21:08:38.737 [bus notice] <aa
2021-10-30 21:08:38.783 [bus notice] <aa
2021-10-30 21:08:38.829 [bus notice] <aa
2021-10-30 21:08:38.875 [bus notice] <aa
2021-10-30 21:08:38.921 [bus notice] <aa
2021-10-30 21:08:38.968 [bus notice] <aa
2021-10-30 21:08:39.014 [bus notice] <aa
2021-10-30 21:08:39.061 [bus error] device status: unexpected available enhanced byte 2
2021-10-30 21:08:39.124 [bus notice] <00
2021-10-30 21:08:39.127 [bus notice] <00
2021-10-30 21:08:39.128 [bus notice] <00
2021-10-30 21:08:39.130 [bus notice] <00
2021-10-30 21:08:39.131 [bus notice] <00
2021-10-30 21:08:39.133 [bus notice] <00
2021-10-30 21:08:39.170 [bus notice] <00
2021-10-30 21:08:39.173 [bus notice] <00
2021-10-30 21:08:39.174 [bus notice] <00
2021-10-30 21:08:39.176 [bus notice] <00
2021-10-30 21:08:39.177 [bus notice] <00
2021-10-30 21:08:39.181 [bus notice] <00
2021-10-30 21:08:39.216 [bus notice] <00
2021-10-30 21:08:39.218 [bus notice] <00
2021-10-30 21:08:39.219 [bus notice] <00
2021-10-30 21:08:39.221 [bus notice] <00
2021-10-30 21:08:39.222 [bus notice] <00
2021-10-30 21:08:39.224 [bus notice] <00
2021-10-30 21:08:39.262 [bus notice] <00
2021-10-30 21:08:39.265 [bus notice] <00
2021-10-30 21:08:39.267 [bus notice] <00
2021-10-30 21:08:39.268 [bus notice] <00
2021-10-30 21:08:39.270 [bus notice] <00
2021-10-30 21:08:39.271 [bus notice] <00
2021-10-30 21:08:39.309 [bus notice] <00
2021-10-30 21:08:39.312 [bus notice] <00
2021-10-30 21:08:39.314 [bus notice] <00
2021-10-30 21:08:39.315 [bus notice] <00
2021-10-30 21:08:39.317 [bus notice] <00
2021-10-30 21:08:39.318 [bus notice] <00
2021-10-30 21:08:39.355 [bus notice] <00
2021-10-30 21:08:39.359 [bus notice] <00
2021-10-30 21:08:39.360 [bus notice] <00
2021-10-30 21:08:39.362 [bus notice] <00
2021-10-30 21:08:39.365 [bus notice] <00
2021-10-30 21:08:39.367 [bus notice] <00
2021-10-30 21:08:39.448 [bus notice] <00
2021-10-30 21:08:39.450 [bus notice] <00
2021-10-30 21:08:39.451 [bus notice] <00
2021-10-30 21:08:39.453 [bus notice] <00
2021-10-30 21:08:39.454 [bus notice] <00
2021-10-30 21:08:39.456 [bus notice] <00
2021-10-30 21:08:39.494 [bus notice] <00
2021-10-30 21:08:39.497 [bus notice] <00
2021-10-30 21:08:39.498 [bus notice] <00
2021-10-30 21:08:39.501 [bus notice] <00
2021-10-30 21:08:39.502 [bus notice] <00
2021-10-30 21:08:39.505 [bus notice] <00
2021-10-30 21:08:39.540 [bus notice] <00
2021-10-30 21:08:39.542 [bus notice] <00
2021-10-30 21:08:39.543 [bus notice] <00
2021-10-30 21:08:39.545 [bus notice] <00
2021-10-30 21:08:39.546 [bus notice] <00
2021-10-30 21:08:39.548 [bus notice] <00
2021-10-30 21:08:39.633 [bus notice] <aa
2021-10-30 21:08:39.680 [bus notice] <aa
2021-10-30 21:08:39.726 [bus notice] <aa
2021-10-30 21:08:39.772 [bus notice] <aa
2021-10-30 21:08:39.818 [bus notice] <aa
2021-10-30 21:08:39.864 [bus error] device status: unexpected available enhanced byte 2
2021-10-30 21:08:39.877 [bus notice] <00
2021-10-30 21:08:39.879 [bus notice] <00
2021-10-30 21:08:39.881 [bus notice] <00
2021-10-30 21:08:39.884 [bus notice] <00
2021-10-30 21:08:39.978 [bus notice] <00
2021-10-30 21:08:39.981 [bus notice] <00
2021-10-30 21:08:39.983 [bus notice] <00
2021-10-30 21:08:39.984 [bus notice] <00
2021-10-30 21:08:39.986 [bus notice] <00
2021-10-30 21:08:39.987 [bus notice] <00
2021-10-30 21:08:40.070 [bus notice] <00
2021-10-30 21:08:40.072 [bus notice] <00
2021-10-30 21:08:40.074 [bus notice] <00
2021-10-30 21:08:40.075 [bus notice] <00
2021-10-30 21:08:40.077 [bus notice] <00
2021-10-30 21:08:40.078 [bus notice] <00
2021-10-30 21:08:40.116 [bus notice] <00
2021-10-30 21:08:40.119 [bus notice] <00
2021-10-30 21:08:40.121 [bus notice] <00
2021-10-30 21:08:40.122 [bus notice] <00
2021-10-30 21:08:40.124 [bus notice] <00
2021-10-30 21:08:40.125 [bus notice] <00
2021-10-30 21:08:40.162 [bus notice] <00
2021-10-30 21:08:40.164 [bus notice] <00
2021-10-30 21:08:40.166 [bus notice] <00
2021-10-30 21:08:40.167 [bus notice] <00
2021-10-30 21:08:40.169 [bus notice] <00
2021-10-30 21:08:40.170 [bus notice] <00
2021-10-30 21:08:40.208 [bus notice] <00
2021-10-30 21:08:40.213 [bus notice] <00
2021-10-30 21:08:40.256 [bus notice] <aa
2021-10-30 21:08:40.302 [bus error] device status: unexpected available enhanced byte 2
2021-10-30 21:08:40.368 [bus notice] <00
2021-10-30 21:08:40.370 [bus notice] <00
usw
Zitat von: boellner am 30 Oktober 2021, 21:13:08
Neues Problem, nach ca 30s ist die Verbindung unterbrochen und nichts geht mehr. Im log kommt ein:
[bus error] device status: unexpected available enhanced byte 2
Was kann das sein?
was hängen denn noch für USB Geräte dran (du nutzt ja den 3. Port)? Und läuft sowas wie FHEM, das ohne die richtige Einstellung alle USB Devices durchprobiert?
Kann ich bei dem Vaillant VRC700 die Punkte Ein Tag Zuhause und ausser Haus manuell auf den Bus schreiben ohne das dieser vom Regler überschrieben wird?
Zitat von: john30 am 30 Oktober 2021, 22:14:07
was hängen denn noch für USB Geräte dran (du nutzt ja den 3. Port)? Und läuft sowas wie FHEM, das ohne die richtige Einstellung alle USB Devices durchprobiert?
Ja richtig, ich nutze Ioboker und es hängen 2 Smartmeter USB Adapter dran.
ich die jetzt mal abgesteckt und den Raspberry neu gestartet, danach lief es stabil.
Die Dienste zu stoppen und die beiden Adapter abziehen half nichts.
Jetzt kann ich noch versuchen die Adapter in anderer Reihenfolge zu stecken.
edit:
ebus hängt jetzt an ttyUSB0 und damit funktionieren derzeit alle 4 USB Schnittstellen parallel
jetzt laufen die anderen Schnittstellen instabil mit Datenaussetzer, jedenfalls hängt sich so nichts auf
Zitat von: boellner am 31 Oktober 2021, 17:42:40
ebus hängt jetzt an ttyUSB0 und damit funktionieren derzeit alle 4 USB Schnittstellen parallel
jetzt laufen die anderen Schnittstellen instabil mit Datenaussetzer, jedenfalls hängt sich so nichts auf
nimm doch lieber den device Pfad mit der ID vom UART anstelle des dynamosch zugeordneten ttyUSB. Das wäre z.B. sowas und der Pfad bleibt dann identisch nach nem Reboot, wenn Du nicht nochmal umsteckst, wogegen ttyUSB davon abhängt, wann das Gerät eingesteckt wurde (bzw. erkannt):
/dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
Zitat von: sonbaty1 am 21 Oktober 2021, 17:22:44
Habe ich Ebus adapter v2.2 und habe ich mir einen Ebus 3 fur sicherheit bestellt.
Du kannst noch mit "--latency=20" versuchen und/oder ebusd laufen lassen und die Heizung kurz stromlos machen, dann sollte sie sich selbständig am Bus bekannt machen
Das ganze Konstrukt ist relativ instabil. Nach einigen Tagen Betrieb mit nur dem Ebus Adapter
2021-11-06 18:31:50.396 [bus notice] device invalid
2021-11-06 18:31:55.396 [bus error] unable to open usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_-if00-port0: ERR: element not found
ein
cat /dev/serial/by-id/usb-Silicon_Labs_CP2102N_
bleit leer
gibts zumindest die Möglichkeit das USB Gerät neu zu Starten? Abstecken hat nicht geholfen.
Zitat von: boellner am 06 November 2021, 18:42:16
Das ganze Konstrukt ist relativ instabil. Nach einigen Tagen Betrieb mit nur dem Ebus Adapter
2021-11-06 18:31:50.396 [bus notice] device invalid
2021-11-06 18:31:55.396 [bus error] unable to open usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_-if00-port0: ERR: element not found
ein
cat /dev/serial/by-id/usb-Silicon_Labs_CP2102N_
bleit leer
gibts zumindest die Möglichkeit das USB Gerät neu zu Starten? Abstecken hat nicht geholfen.
da hast dann aber irgendwie ein ganz anderes Problem, wenn auch die anderen USB Devices nicht stabil registriert bleiben. Ich würde mal auf eine ungenügende Stromquelle tippen und die als erstes mal gegen eine andere tauschen.
Zitat von: Cihan am 31 Oktober 2021, 11:36:01
Kann ich bei dem Vaillant VRC700 die Punkte Ein Tag Zuhause und ausser Haus manuell auf den Bus schreiben ohne das dieser vom Regler überschrieben wird?
Ja, das geht. Für "1 Tag ausser Haus" muss z1SFMode auf 4 gesetzt werden.
Zitat von: john30 am 06 November 2021, 20:14:45
da hast dann aber irgendwie ein ganz anderes Problem, wenn auch die anderen USB Devices nicht stabil registriert bleiben. Ich würde mal auf eine ungenügende Stromquelle tippen und die als erstes mal gegen eine andere tauschen.
Netzteil sollte eigentlich gut sein, ich habe extra eines von Raspberry gekauft weil ich in Vergangenheit mit anderen Probleme hatte.
Hallo Zusammen,
kann mir jemand am Beispiel erläutern wie ich einzelne Werte vom Ebus gezielt auslesen kann?
Konfig:
ebusd:
# Options to pass to ebusd (run "ebusd -?" for more info):
EBUSD_OPTS="-d /dev/ttyebus --configpath=http://ebusd.eu/config/ --scanconfig --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.178.30 --mqtttopic=ebusd/%circuit/%name"
pi@raspberrypi:~ $ ebusctl info
version: ebusd 21.3.v21.2-207-g4d26b75
update check: revision v21.3 available
device: /dev/ttyebus
access: *
signal: acquired
symbol rate: 34
max symbol rate: 122
min arbitration micros: 2
max arbitration micros: 60
min symbol latency: 4
max symbol latency: 4
reconnects: 0
masters: 3
messages: 652
conditional: 3
poll: 0
update: 10
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0609;HW=5502", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=70000;SW=0209;HW=4103", loaded "vaillant/15.700.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 52: slave, scanned "MF=Vaillant;ID=VR_70;SW=0109;HW=2903", loaded "vaillant/52.vr_70.csv"
Es sind ja 3 CSVs geladen (vaillant/08.bai.csv,vaillant/15.700.csv, vaillant/52.vr_70.csv)und daten kommen nach FHEM jedoch ist nicht alles gefüllt. Nur ein paar Werte (siehe Bilder)
Wie bekomme ich den Rest in FHEM "rein" (siehe Fhem Bilder)? Wie kann ich gezielt ein Modul abfragen? Vllt liegt es auch nur am Template. Wo gibt es gute Templates?
Beispiele würden genügen. Vielen Dank im Voraus!
Beispiel, definiere dir einen Timer und frage ab was du willst:
define EBUS.MQTT at +*00:10:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;;\
set ebusMQTT publish ebusd/430/HwcTempDesired/get;;\
set ebusMQTT publish ebusd/700/WaterPressure/get;;\
set ebusMQTT publish ebusd/700/FlowTemp/get;;\
set ebusMQTT publish ebusd/700/ReturnTemp/get;;\
set ebusMQTT publish ebusd/700/FanSpeed/get;;\
set ebusMQTT publish ebusd/700/WPPWMPower/get;;\
set ebusMQTT publish ebusd/700/Status02/get;;\
set ebusMQTT publish ebusd/700/HcHours/get;;\
set ebusMQTT publish ebusd/700/HwcStarts/get
Hier wird alle 10 Minuten eine MQTT Abfrage ausgelöst, passe dir das so an was und wann du benötigst. Kannst ja auch mehre Timer machen, da ja manche Daten wie Wasserdruck etc. ja alle paar Stunden ausreicht.
Aber hole dir nur die Daten die du wirklich brauchst, nicht alle 652! Jede Datenabfrage geht über den eBus und blockiert diesen dann umsonst, das ist so in einem Multimaster Betrieb!
LG
Reinhart
Moin Zusammen,
da muss ich doch glatt nach etwas mehr als einem Jahr meinen alten Post wieder hervor holen. ;-)
Zitat von: Martin Fischer am 14 November 2020, 14:59:58
Hallo zusammen,
eigentlich wollte ich erst einen eigenen Thread aufmachen. Doch hier scheint das geballte Wissen bereits versammelt zu sein ;)
Ich habe eine Vaillant atmoTEC classic VCW 194/3-C-HL Gas-Kombitherme in Betrieb. Vor langer Zeit hatte ich mal experimentell ein paar Daten über die X6 Schnittstelle abgegriffen, lies das Projekt aber einschlafen. Schnittstelle funktionierte soweit, konnte das auch mit vrDialog verifizieren. Nun möchte ich das Projekt "VCW" erneut angehen; diesmal über eBus. Und da hat sich ja in den Jahren hier sehr viel getan.
Mein Gerät unterstützt leider eBus nicht out-of-thebox. Also habe ich kurz recherchiert und mir das Vaillant VR 39 Zusatzmodul besorgt. Klemme 7-8-9 ist bei mir vorhanden, X6 ebenfalls.
Nun wollte ich heute das Zusatzmodul einbauen und musste feststellen, das meine Anlage etwas von der Einbauanleitung abweicht. Schaut man sich die zwei Seiten der Einbauanleitung an, so sollte das Zusatzmodul links neben der Hauptplatine gesteckt werden. Hier ist jedoch bei mir kein entsprechender Platz vorgesehen.
Dies beunruhigt mich erst einmal nicht. Es würde sich schon ein Plätzchen für die Platine finden, doch anders als auf der Zeichnung dargestellt, hat mein Zusatzmodul unten noch 4 Steckkontakte. Desweiteren ist in einer Installationsanleitung, die ich im Web gefunden habe, oben am Rand der Platine noch ein kontaktfreier Steckplatz, den ich gemäß Zeichnung nicht einordnen kann. Ich vermute mal, dass das ein Abstandshalter ist. Gemäß der Installationsanleitung besteht ja nur eine Verbindung über RJ-12 / 6P6C zwischen dem Modul und der Hauptplatine.
Ist das Zusatzmodul VR 39 für meine Anlage geeignet? Hat da jemand schon Erfahrungen?
Tatsächlich ruhte das Projekt mangels Zeit für diesen Zeitraum. Seit Ewigkeiten habe ich hier einen eBus 2.1 und einen eBus 3 Adapter liegen. Auch mit Reinhart hatte ich mich schon ausgetauscht, doch das war bevor ich die Adapter hatte.
Heute habe ich dann mal alles, nach meinem Verständnis, zusammen gesteckt. Also via RJ12 die Vaillant VCW 194/3-C mit dem VR 39 Adapter verbunden. Siehe dazu auch die Bilder im Ursprungsbeitrag (https://forum.fhem.de/index.php/topic,29737.msg1101131.html#msg1101131).
Dann den VR 39 mit dem eBus Adapter 3 (USB) verbunden und selbigen via USB an den Server. Firmware ist auch aktuell, sprich die letzte verfügbare. ebusd installiert und konfiguriert und es passiert:
NÜSCHTS!
Selbst im Debugmodus bekomme ich keinerlei "Funkverkehr auf dem Kanal":
root@fhem01:/usr/local/src# ebusd -f -d /dev/ebus -p 8888 --latency=10000 --receivetimeout=100000 -l /var/log/ebusd.log --scanconfig=full --httpport=8889 --htmlpath=/var/ebusd/html --logareas bus --loglevel info --lograwdata=bytes
2021-12-22 16:38:48.957 [bus notice] bus started with own address 31/36Über die X6 Schnittstelle konnte ich seinerzeit vrDialog betreiben. Also "spricht" die Anlage also per se über diesen Port. Allerdings ist mir (immer noch) nicht klar, was genau der VR 39 macht. Und irgendwie kann ich mir nicht vorstellen, dass der nur via RJ12 und EBUS angeschlossen wird. Woher bezieht dieser seine Spannung die er für die ganzen SMD Bautteile braucht?
Im Moment fehlt mir gerade der Ansatz zum Debuggen.
Die X6 Schnittstelle an VCW geht (mit vrDialog lassen sich Wrte auslesen, ebenso mit meinem eigenen Perlscript und DIY-Lösung). Doch wie teste ich das Vaillant VR 39 Zusatzmodul, bzw. den eBus Adapter?
Muss denn der eBus Adapter via eBusd irgendetwas melden, wenn er da so ganz allein angeschlossen ist? Bzw. wie bekomme ich ihn dazu etwas zu melden, also zumindest mal so ein "Hello World!". ;-)
Um hier noch einmal "alte" Konversationen aus dem Hut zu zaubern:
Es stand die Aussage im Raum, dass ich zwingend eine calorMATIC nachrüsten müsse. In einem Austausch mit Reinhart, schrieb er dazu:
Zitat von: ReinhartUm den eBus Adapter zu betreiben, brauchst du keine zusätzliche Calormatic, den das Heizgerät selbst hat ja einen eBus und liefert dann halt nur jene Daten die es ohne optionale Regler hergibt.
In diesem Sinne: Wenn sich jemand erbarmt, dass ganze mit mir zu debuggen, dann bin ich dankbar.
Zitat von: Martin Fischer am 22 Dezember 2021, 17:15:52
In diesem Sinne: Wenn sich jemand erbarmt, dass ganze mit mir zu debuggen, dann bin ich dankbar.
Dies noch als Ergänzung. Es scheitert wohl schon am "no signal".
localhost: info
version: ebusd 21.3.v21.3
device: /dev/ebus
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd
Zitat von: Martin Fischer am 22 Dezember 2021, 18:41:28
Dies noch als Ergänzung. Es scheitert wohl schon am "no signal".
hast du denn denn adapter 3 im enhanced mode oder non-enhanced? das ist entscheidend. für enhanced mode muss statt "-d /dev/ebus" dann "-d enh:/dev/ebus" verwendet werden.
Und der Adapter hängt am eBUS der Heizung und nicht an irgendwas anderes hoffe ich?
Vermute mal Spannungsversorgung über eBus.
Man könnte mal am STM32 an den VDD_X pins messen, ob da 2 ... 3.6V anliegen. Aber verdammt Vorsicht - keinen Kurzen bauen. Vielleicht gibt es in der Umgebung von der eBus Schaltung bessere Punkte. Dazu müsste man die Schaltung rückerkennen, wenigstens teilweise.
Zitat von: john30 am 23 Dezember 2021, 17:54:42
hast du denn denn adapter 3 im enhanced mode oder non-enhanced? das ist entscheidend. für enhanced mode muss statt "-d /dev/ebus" dann "-d enh:/dev/ebus" verwendet werden.
Der enhanced mode war der entsprechende Hinweis! Danke dafür!
localhost: info
version: ebusd 21.3.v21.3
update check: OK
device: /dev/ebus, enhanced
signal: acquired
symbol rate: 25
max symbol rate: 32
min arbitration micros: 244
max arbitration micros: 598
min symbol latency: 11
max symbol latency: 17
reconnects: 0
masters: 2
messages: 12
conditional: 0
poll: 0
update: 4
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=V3x00;SW=0118;HW=9902"
address 31: master #8, ebusd
address 36: slave #8, ebusdAllerdings kann ich mich nicht entsinnen, dass irgendwo gelesen zu haben. Was ist der Unterschied?
Sodele... nachdem die Anbindung nun scheinbar steht, habe ich folgende Einträge im Log:
2021-12-28 21:59:21.501 [main notice] ebusd 21.3.v21.3 started with full scan on enhanced device /dev/ebus
2021-12-28 21:59:24.542 [main error] error reading config files from http://ebusd.eu/config/: ERR: element not found, last error:
2021-12-28 21:59:24.544 [bus notice] device status: resetting
2021-12-28 21:59:24.545 [bus notice] bus started with own address 31/36
2021-12-28 21:59:24.549 [bus notice] signal acquired
2021-12-28 21:59:25.118 [bus notice] device status: reset, supports info
2021-12-28 21:59:34.546 [main notice] starting initial full scan
2021-12-28 21:59:37.031 [bus notice] new master 03, master count 2
2021-12-28 21:59:37.031 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2021-12-28 21:59:37.031 [update notice] store 08 ident: done
2021-12-28 21:59:37.031 [update notice] sent scan-read scan.08 QQ=31: Vaillant;V3x00;0118;9902
2021-12-28 21:59:37.032 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2021-12-28 21:59:47.583 [main error] unable to load scan config 08: list files in vaillant ERR: element not found
2021-12-28 21:59:47.583 [main error] scan config 08: ERR: element not found
Warum startet ebusd bereits mit einem Fehler, dass die Konfigurationsdateien auf http://ebusd.eu/config/ nicht gefunden werden?
Und später dann der Fehler, dass ein entsprechendes Element nicht gefunden werden kann.
Kann es an dem Aufbau liegen, dass für diese Konstellation (VCV 194/3-C -> X6 -> VR 39 Adapter -> eBus Adapter 3) noch keine Konfiguration bereitgestellt werden konnte? Wenn ja, was kann ich beitragen?
ZitatAllerdings kann ich mich nicht entsinnen, dass irgendwo gelesen zu haben. Was ist der Unterschied?
Im Enhanced Mode findet die Arbitrierung im Prozessor auf der eBus Platine statt und damit wird die Spezifikation zu 100% eingehalten.
Im Non-Enhanced Mode werden die Pakete 1:1 an den ebusd weitergereicht, was meistens wegen der großen Latenz eine Verletzung der Spezifikation und manchmal auf dem eBus eine Kollision zur Folge hat.
Ist aber klar, dass ebusd und die Platine jeweils immer die "gleiche Sprache" sprechen müssen.
Die "Sprache" auf der Platine wird übrigens per Jumper eingestellt. Beim ebusd erfolgt das über den "enh:" Zusatz.
@Martin
Das Problem ist, dass es keine Konfigurationsdatei für die V3x00 gibt, deshalb kommt die Fehlermeldung "not found".
Du musst daher die Config lokal laden mit --configpath=/etc/ebusd/ und ein bisschen aus den Files zusammen kopieren. Schau bitte hier (https://forum.fhem.de/index.php/topic,79600.msg753714.html#msg753714)und hier (https://forum.fhem.de/index.php/topic,29737.msg829290.html#msg829290), die beiden haben auch den gleichen Device v3x00 vor allem der erste Post von JayPee sollte dir helfen!
Nachdem du den configpath in der "/etc/default/ebusd" geändert hast musst du natürlich auch die Configs einmal vom Github (https://github.com/john30/ebusd-configuration/releases) laden. Die sollten dann lokal in /etc/ebusd liegen. Im Verz. "vaillant" findest du dann alle csv. Nach der Config Änderung und dem Download der Configs den Dämon neu starten damit der dann die Files neu einliest.
LG
was JayPee da schreibt mit der 15.470.csv entfällt bei dir, da du die Calormatic ja nicht hast, es geht nur rein um die neu erstellte 08.v3x00.csv! Vielleicht liest er ja hier mit und kann dir die csv hier posten die er jetzt am Laufen hat dann brauchst du das Rad nicht neu erfinden!
LG
Hallo Reinhart,
vielen Dank für die ganzen Hinweise! Ich habe nur kurz einen Blick in die anderen Threads geworfen und bin über die Register gestolpter. Da ist mir meine, in 2010 erstellte, Tabelle eingefallen, in der ich schon alle Register erfasst hatte. Ich hänge sie mal dran. Kann ich darauf aufbauen?
Auch müsste ich im meinem Hardwarezoo noch ein altes Acer Aspire One Notebook mit vrDialog liegen haben. Ist auch das ggf. dienlich?
Und ja, ein Calormatic ist nicht am Bus; derzeit auch nicht geplant. Mir reicht es, wenn ich Werte polle und - wenn überhaupt - schreiben kann. Durch mein HCS Modul konnte ich ja bereits eine Steuerung realisieren, die die Heizung bedarfsgerecht schaltet. Mal sehen, was noch optimierbar ist.
Im Anhang die alte Tabelle..
Viele Grüße
@galileo:
Danke für die Erklärung. Las ich so zum ersten Mal. Bisher hatte ich lediglich beim ebusd nur kurz den Hinweis auf enh: gesehen aber keine Erklärung dazu.
Zitat von: galileo am 29 Dezember 2021, 04:33:53
Ist aber klar, dass ebusd und die Platine jeweils immer die "gleiche Sprache" sprechen müssen.
Die "Sprache" auf der Platine wird übrigens per Jumper eingestellt. Beim ebusd erfolgt das über den "enh:" Zusatz.
Auf der Website der Platine sehe ich auch keinen Hinweis bzgl. Jumper und der "Sprache". Oder ich sichte die falschen Quellen. ???
ZitatAuf der Website der Platine sehe ich auch keinen Hinweis bzgl. Jumper und der "Sprache".
Du hast recht, das ist ein wenig versteckt. Auf https://adapter.ebusd.eu/ (https://adapter.ebusd.eu/) sieht man es im letzten Bild, ganz unten.
Ist alles IMHO gar nicht wichtig, denn wer will schon das "schlechtere" Protokoll haben, wenn er das bessere haben kann....
Wie man dort sehen kann, ist "enhanced" bei offenem Jumper eingestellt, also Default. Nur für das alte, Non-Enhanced, muss man den Jumper setzen.
Martin ich glaube du warst im ganz normalen Wiki für allgemeinen eBus. Für die V3 gibt es ein eigenes, weil die sich komplett von der alten Varriante unterscheidet!
Hier (https://adapter.ebusd.eu/) gehts zum V3 Wiki!
und alles was V3 mit Inbetriebnahme betrifft versuche ich hier in diesem Thread (https://forum.fhem.de/index.php?topic=118143.msg1125668#msg1125668) zu sammeln! Gleich im ersten Thread sind alle wichtigen weiterführenden Threads verlinkt um die Suche zu erleichtern!
LG
Danke Euch beiden!
Nein, ich war schon im "richtigen" Wiki. Ich habe bzgl. der Jumper jedoch nur in die Tabelle geschaut und nicht die Tabelle mit dem Bild auf fehlende Angaben geprüft. :D Jetz, beim zweiten Hinsehen, sehe ich auch die Anmerkung im Bild bzgl. enhanced und ja, auch die Hinweise im Text habe ich nun gelesen. Das habe ich komplett überlesen. Aus der Gewohnheit heraus, "fühlt" sich ein "-d /dev/..." nicht falsch an. Das ein "enh:" Prefix gesetzt werden muss, habe ich schlicht dort überlesen.
Mea culpa ;)
@Reinhart:
Danke für den Hinweis mit dem entsprechenden Thread. DAS hat mir gefehlt. Bevor ich nun die 24 Seiten durchgehe, kurz zurück zu meiner Frage bzgl. meiner Tabelle. Kann ich daraus die nötigen Angaben bereits ableiten und ggf. eine entsprechende CSV generieren?
Zitat von: Martin Fischer am 30 Dezember 2021, 11:43:48
Danke für den Hinweis mit dem entsprechenden Thread. DAS hat mir gefehlt. Bevor ich nun die 24 Seiten durchgehe, kurz zurück zu meiner Frage bzgl. meiner Tabelle. Kann ich daraus die nötigen Angaben bereits ableiten und ggf. eine entsprechende CSV generieren?
Das Problem ist vorerst das wir nicht wissen auf welchem Register die Timer deiner Anlage sitzen, deshalb wäre das fertige File von JayBee schon sehr hilfreich, schreibe ihm eventuell eine PN, er ist sicher sehr hilfsbereit!
Wenn du dir die 08.bai.csv anschaust, dann werden hier je nach Hard und Software verschiedene inc Files nachgeladen. Im wesentlichen sind das die timer.inc, timerhc.inc und timerhwc.inc. Schau dir die Files an und du siehst die unterschiedlichen Register wo der Eintrag steht, daher musst du vorher etwas experimentieren um dahinter zu kommen wo die tatsächlich sitzen. Bei mir ist das die timer.hc, indem du einen Warmwasserspeicher hast könnte das bei dir vermutlich die timerhwc.sein.
Kopiere dir zb: als Grundgerüst einfach die bai.308523.inc als BASIS und gebe den Inhalt der timerhwc.inc dazu und teste ob auf diesen Registern deine Timer kommen. Ansonsten die nächste timer.inc nehmen. Dazwichen natürlich immer den Dämon neu starten oder einen reload.
Wegen der ods Datei, ich muss ehrlich sagen das ich noch eine ods importiert habe. Wenn ich was brauche dann hole ich mir gleich die fertigen Configzeilen aus den entsprechenden Files, aber bei meiner Hardware ist das kaum notwendig weil alles gefunden wird. Aber pah hat das glaub ich schon mal beschrieben in den ersten paar Post in diesem Thread!
LG
Reinhart
"Der JayBee" aus dem entsprechendem Beitrag exisitert als User nicht mehr. Es gibt zwar wieder einen "neuen", muss ich noch klären ob es die selbe Person ist.
Bzgl. der ods-Datei:
Da habe ich mich wohl falsch ausgedrückt. Ich habe dort ja seinerzeit die ganzen Register samt default Werte und Bezeichung für meine Anlage aufgeführt. Die Frage zielte eher darauf, ob diese Informationen hilfreich für den Aufbau einer entsprechenden Konfig sein könnte.
Ich schaue mir das die Tage mal näher an. Im Moment tanze ich gerade (beruflich bedingt) auf zu vielen Hochzeiten. :(
Viele Grüße und derweil einen guten Start ins neue Jahr!
für den Aufbau der csv ist das eigentlich nicht so wichtig, weil du ja versuchst in der csv möglichst viele Definitionen zu integrieren die bei deinem Device möglich sind. Ob du diese Definitionen bzw. Konfigurationen dann nutzt ist ja eine andere Sache. Aber zur Definition der Abfragen in Fhem wirst du die brauchen.
Ich habe bei meiner Hardware 452 Definitionen (automatisch erkannt) und nutze davon maximal so an die 15, das hängt von der gewünschten Verwendung des Anwenders ab und ist individuell. Diese ganzen Definitionen in der csv sind ja mehr oder weniger nur eine komfortable Übersetzung der übertragenen Datensätze in beide Richtungen. Doch außer den Broadcast wird nix automatisch übertragen, die musst du per poll dann abholen und kannst durch diese Definitionen sie per Klartext benutzen.
pi@eBus:~ $ ebusctl i
version: ebusd 21.1.v21.1-27-gb805cfe
update check: version 21.3 available, vaillant/08.bai.csv: newer version available, vaillant/hcmode.inc: newer version available
access: *
signal: acquired
symbol rate: 22
max symbol rate: 154
min arbitration micros: 6
max arbitration micros: 304
min symbol latency: 3
max symbol latency: 11
reconnects: 2
masters: 4
messages: 452
conditional: 16
poll: 0
update: 10
address 01: master #6, ebusd
address 03: master #11
address 06: slave #6, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/bai.0010006101.inc" ([PROD='']), "vaillant/08.bai.csv"
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
address 31: master #8
hier siehst du meine 3 erkannten Files die geladen wurden und das ergibt in Summe die 452 Messages.
Danke, dir auch einen guten Start in 2022!
So, nun bin ich einen Schritt weiter aber noch nicht am Ziel.
Ich habe eine 08.v3x00.csv angelegt und nach bestem Wissen befüllt. Die entsprechenden Diagnose Codes (d.00 ... d.91) darin, werden laut Vaillant für meine Anlage unterstützt, siehe dazu auch meine hochgeladene .ods Datei hier im Thread. Die Werte decken sich auch mit meinen frühen Erfahrungen via X6 Schnittstelle, siehe dazu auch (Vaillant X6 Schnittstelle (https://old.ethersex.de/index.php/Vaillant_X6_Schnittstelle)).
Meine ebusd Konfiguration ist:
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=10000 --receivetimeout=100000 -d enh:/dev/ebus --address=ff --configpath=/etc/ebusd"
Mein Vaillant VR 39 Adapter wird gefunden und die 08.v3x00.csv wird geladen:
version: ebusd 21.3.v21.3
update check: OK, broadcast.csv: newer version available, vaillant/broadcast.csv: newer version available, vaillant/errors.inc: newer version available, vaillant/hcmode.inc: newer version available
device: /dev/ebus, enhanced
access: *
signal: acquired
symbol rate: 25
max symbol rate: 51
min arbitration micros: 210
max arbitration micros: 797
min symbol latency: 11
max symbol latency: 23
reconnects: 0
masters: 2
messages: 96
conditional: 0
poll: 0
update: 8
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=V3x00;SW=0118;HW=9902", loaded "vaillant/08.v3x00.csv"
address ff: master #25, ebusd
Scanne ich den Bus, liefert das Logfile folgende Infos:
2022-01-01 22:08:48.341 [update notice] sent scan-read scan.08 QQ=ff: Vaillant;V3x00;0118;9902
2022-01-01 22:08:48.341 [bus notice] scan 08: ;Vaillant;V3x00;0118;9902
2022-01-01 22:08:55.867 [main notice] read common config file vaillant/broadcast.csv
2022-01-01 22:08:55.867 [main notice] read common config file vaillant/scan.csv
2022-01-01 22:08:55.872 [main notice] read scan config file vaillant/08.v3x00.csv for ID "v3x00", SW0118, HW9902
2022-01-01 22:08:55.873 [main notice] found messages: 95 (0 conditional on 0 conditions, 0 poll, 8 update)
2022-01-01 22:08:56.545 [update notice] sent unknown MS cmd: ff08b5090124 / 09003231323033393030
2022-01-01 22:08:57.318 [update notice] sent scan-read scan.08 id QQ=ff:
2022-01-01 22:08:58.088 [update notice] sent scan-read scan.08 id QQ=ff:
2022-01-01 22:08:58.862 [update notice] sent scan-read scan.08 id QQ=ff: 21;20;39;0020139898;0082;005436;N8
2022-01-01 22:08:58.862 [bus notice] scan 08: ;21;20;39;0020139898;0082;005436;N8
Nun wollte ich testen ob ich auch Werte bekomme:
root@fhem01:/etc/ebusd/vaillant# ebusctl read -f FlowTemp
ERR: invalid position in decode
Und das Logfile liefert:
2022-01-01 22:09:55.115 [update error] unable to parse read v3x00 FlowTemp from ff08b509030d1800 / 0100: ERR: invalid position
2022-01-01 22:09:55.115 [main error] read v3x00 FlowTemp: decode ERR: invalid position
Und hier endet jetzt mein Ausflug, da ich weder sehe wo der Fehler ist, noch wo ich ansetzen muss. Für entsprechende Hilfestellungen wäre ich dankbar!
Zitat von: Martin Fischer am 01 Januar 2022, 22:46:00
2022-01-01 22:09:55.115 [update error] unable to parse read v3x00 FlowTemp from ff08b509030d1800 / 0100: ERR: invalid position
2022-01-01 22:09:55.115 [main error] read v3x00 FlowTemp: decode ERR: invalid position
Und hier endet jetzt mein Ausflug, da ich weder sehe wo der Fehler ist, noch wo ich ansetzen muss. Für entsprechende Hilfestellungen wäre ich dankbar!
der Slave 08 antwortet mit nur einem Byte an Nutzdaten mit Wert 0x00. Das passt nicht zum Datentyp tempsensor, der in der _templates definiert ist und aus Temperatur plus Sensorstatus zusammengesetzt ist.
Ergo: entweder ist die Definition falsch (unwahrscheinlich) oder der v3x unterstützt die Nachricht nicht.
Hallo John,
vielen Dank für Einschätzung. Ohne Deine Expertise in Frage stellen zu wollen, kann ich mir nicht vorstellen, dass das (ausschliesslich) am VR 39 Adapter liegt.
Neben mir, gibt es ja mind. zwei weitere die damit experimentieren: einmal ein ehemaliger User namens Jaypee(?) hier im Forum und dann bei Dir via github (siehe hier (https://github.com/john30/ebusd-configuration/issues/193)). Die letzte Quelle diente mir als Basis, die ich dann um weitere Codes, die ich wie bereits bechrieben, aus meinen "alten X6" Versuchen, entnommen haben. Die Adressen, scheinen demnach zu stimmen.
Ehrlich gesagt, kann ich mir nicht vorstellen, dass Vaillant den VR 39 Adapter "für den Anschluss eines nicht eBUS-fähigen Wärmeerzeugers (Schnittst. 7-8-9) an einen eBUS Regler" vermarktet, der dann nicht einmal in der Lage sein sollte, essentielle Informationen wie Vor- oder Rücklauf an einen Regler am Bus weitergeben zu können.
Seitens der Hardware ist es ja folgendes Anschlußschema:
"Wäremeerzeuger" Schnittstelle X6 -> eBus Adapter (VR39) -> eBus fähige Geräte
So wird auch ein eBus Regler die Werte des "Wärmeerzeugers" benötigen um die Anlage überhaupt steuern zu können. Ohne wird es nicht gehen.
Ich stelle mir also die Frage, was nun der Ursprung des durch Dich analysierten Ergebnisses führt. Können es andere Faktoren sein, die dazu führen?
Z.B. die Länge meiner eBus Zuleitung (ca. 2.5 Meter zwischen VR 39 und eBus Adapter )?
Unklar ist für mich auch immer noch die Kontaktschnittstelle am VR 39 Adapter selbst. Es ist immer die Rede von "Elektronikbox". Diese hat mein Gerät nicht und in der Installationsanleitung ist die Schnittstelle weder eingezeichnet, noch beschrieben, dass da etwas angeschlossen werden muss.
Wie kann ich (mit Eurer Unterstützung) hier weiter debuggen?
Zitat von: Martin Fischer am 02 Januar 2022, 11:28:13
Ehrlich gesagt, kann ich mir nicht vorstellen, dass Vaillant den VR 39 Adapter "für den Anschluss eines nicht eBUS-fähigen Wärmeerzeugers (Schnittst. 7-8-9) an einen eBUS Regler" vermarktet, der dann nicht einmal in der Lage sein sollte, essentielle Informationen wie Vor- oder Rücklauf an einen Regler am Bus weitergeben zu können.
du wirst jetzt hoffentlich nicht erwarten, dass eine so alte und rudimentäre Schnittstelle wie die 7-8-9 wesentlich mehr als einen Sensor und eine Modulation unterstützt, oder??
Zitat von: john30 am 02 Januar 2022, 11:58:05
du wirst jetzt hoffentlich nicht erwarten, dass eine so alte und rudimentäre Schnittstelle wie die 7-8-9 wesentlich mehr als einen Sensor und eine Modulation unterstützt, oder??
Ich erwarte nicht, aus Sch...e Gold zu machen. Aber ich denke schon, dass die Werte, die ich über die X6 Schnittstelle bekommen habe, auch über den VR 39 Adapter bereitgestellt werden.
Zitat von: Martin Fischer am 02 Januar 2022, 12:10:12
Ich erwarte nicht, aus Sch...e Gold zu machen. Aber ich denke schon, dass die Werte, die ich über die X6 Schnittstelle bekommen habe, auch über den VR 39 Adapter bereitgestellt werden.
Hi Martin,
vielleicht hilft dieser Link:
https://www.mikrocontroller.net/topic/126250?goto=1456906#1456906 (https://www.mikrocontroller.net/topic/126250?goto=1456906#1456906)
Grüße von der stürmischen Küste
Det :)
Zitat von: Martin Fischer am 02 Januar 2022, 12:10:12
Ich erwarte nicht, aus Sch...e Gold zu machen. Aber ich denke schon, dass die Werte, die ich über die X6 Schnittstelle bekommen habe, auch über den VR 39 Adapter bereitgestellt werden.
nach kurzer Recherche: X6 ist eine serielle Schnittstelle wogegen 7-8-9 lediglich eine Pulsweitenmodulation und evtl. noch eine unterschiedliche Amplitude erlaubt. Also:
- 7-8-9: max. ein Wert raus und ein Wert rein
- X6: alles in beide Richtungen denkbar durch RS232
Was Du wahrscheinlich gebraucht hättest, wäre ein X6 interface samt Auswertungstool oder einen VR (o.ä.) Adapter, der X6 nach eBUS konvertieren kann und vice versa
Hallo Det.
Danke für den gut gemeinten Hinweis. Es geht mir in erster Linie nicht darum, was in Deinem Link beschrieben ist. Rund um meine Heizungsanlage, habe ich schon einiges in den letzten Jahren entwickelt. Für das Gesamtbild erlaube ich mir, dies hier darzustellen:
- In 2008 entwickelte ich für FHEM die initiale 1-wire Anbindung via OWTEMP und OWFS um meine Heiz- und Warmwasserkreise zu überwachen. Dies half mir schon einmal dabei, dass Verhalten der Anlage zu analysieren und entsprechend enzustellen. Siehe dazu auch: 1-Wire Integration in FHEM (https://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html) und Heiz- und Warmwasserkreis überwachen (https://www.fischer-net.de/hausautomation/haustechnik/1-wire/36-heiz-und-warmwasserkreis-ueberwachen.html)
- In 2012 entwickelte ich das FHEM Modul HCS um damit direkt in die Steuerung der Heizungsanlage einzugreifen. In dem Beitrag FHEM Modul zur (erweiterten) Heizungssteuerung (https://www.fischer-net.de/hausautomation/fhem/53-fhem-modul-zur-erweiterten-heizungssteuerung.html) schildere ich, wie ich die "Klemme 3-4-5" in Verbindung mit HCS erfolgreich einsetze. Ich konnte meinen Strom- und Gasverbrauch dadurch nennenswert reduzieren.
Mit der Anbindung der Heizungsanlage direkt über eBus möchte ich zum einen die "echten" Werte aus der Anlage (und nicht erst 10 bis 20 cm entfernt, ausserhalb am Rohrnetz) abnehmen aber auch ggf. die Heizkurve in den kritischen Bereichen (bei mir 12° Außentemperatur) eingreifen. Dies kann ich nämlich nicht mit meiner derzeitigen Lösung. Der Rest der auszulesenden Werte sind nice to know und eher statistischer Grundlage. Vielleicht dient der eine oder andere Wert noch für eine Optimierung. Das müsste sich nach längerer Beobachtung ergeben.
In 2010 experimentierte ich mit der X6 Schnittstelle, die meine Heizungsanlage ja bereitstellt. Über die X6 Schnittstelle, die Stand heute auch "das Bindeglied" zwischen "alter Anlage und eBus via V 39 Adapter" ist, habe ich damals bereits relevante Werte auslesen können. Siehe auch das (unfertige?) Python Script im Anhang. Das ist nun schon so lange her, das ich mich heute tatsächlich nicht mehr erinnere, ob der Quelltext aus meiner Feder stammt oder er aus anderer Quelle ist.
Nachteil der Lösung war, dass das nicht stabil war. Vermutlich ähnlich wie vrDialog, dass auch nur für Kurzzeitmessungen eingesetzt wird. Oder aber, weil es einfach bei mir nicht stabil lief. Das kann ich heute nicht mehr nachvollziehen. Fakt ist, dass das ein Grund war, dass Thema via X6 nicht weiter zu verfolgen.
10 Jahre später, mit der Diskussion um den eBus Adapter und ebusd, "flammte" das Thema bei mir wieder auf. Nach ein wenig Recherche stieß ich auf den VR 39 Adapter für ebensolche Anlagen, die keine eBus, sondern nur die X6 Schnittstelle bereitstellen. Die Klemme "3-4-5" oder "7-8-9" spielt hierbei keine Rolle.
Abweichend zu Johns letzter Vermutung, vermute ich, dass nicht direkt der VR 39 Adapter der Schuldige ist, sondern ggf. die Anbindung an meine Anlage. Um das zu bestätigen, bedarf es jedoch der Info anderer, die diesen Adapter einsetzen oder ihn im Detail näher kennen. In der originalen Anleitung, die mir vorliegt, ist es halt nicht näher beschrieben und so bleiben die Kontaktlaschen (siehe linkes Bild im Anhang) am Adapter eine Blackbox für mich.
Da der Adapter ja zwischen X6 und eBus "geklemmt" wird, sollte dieser die Werte wohl auch dolmetschen können. Dies war auch die Vermutung von Reinhart. Die Frage ist wie und so wie es sich für mich darstellt, tut er das zumindest bei zwei weiteren Anwendern auch. Vielleicht tut er es bei mir nicht, weil eben diese "Kontaktlaschen" bei mir nicht "bedient" werden. Es gibt in meiner Anlage halt keine "Elektronikbox" zum Reinstecken des Adapters.
Um die Ursache "fehlende Elektronikbox" und somit kein Anschluß über die 4 Kontaktlaschen am Adapter auszuschliessen, fehlt mir die Information. Fakt ist ja, das ich den Adapter nur zwischen X6 und eBus Adapter angeschlossen habe und er erkannt wird.
Wenn ich "ebusctl info" als eBus Laie richtig interpretiere, "hängen" nach meiner Interpretation mehrere Geräte am Bus:
address 03: master #11
address 04: slave #25, ebusd
address 08: slave #11, scanned "MF=Vaillant;ID=V3x00;SW=0118;HW=9902", loaded "vaillant/08.v3x00.csv"
address ff: master #25, ebusdff ist nach meinem Verständnis der eBus Adapter, da ich "--address=ff" als Attribut bei Start übergebe.
08 ist (vermutlich) der VR 39 Adapter.
03 und 04 weiß ich nicht.
Ich habe gerade auch noch einmal mein vrDIALOG/2 Version 2.0.0.10 heraus gekramt und an die X6 Schnittstelle angeschlossen. Nur um zu prüfen, ob noch Daten gesendet wurden und dem war so.
Wenn mir jemand sagt, wie ich den eBus Adapter 3 unter Windows eingebunden bekomme (ich "arbeite" zu 98,9999% nur unter unixoiden Systemen ;) ), dann könnte ich auch vrDIALOG 810/2 mit eBUS Anbindung testen. Da wäre es aus meiner Sicht interessant, wie der Hersteller direkt seine Geräte erkennt und was geliefert wird.
Letzteres wäre halt noch eine Option zu testen / debuggen. Oder jemand kennt eine andere Möglichkeit, vrDIALOG an den eBUS anzuschliessen.
Zitat von: john30 am 02 Januar 2022, 15:48:09
Was Du wahrscheinlich gebraucht hättest, wäre ein X6 interface samt Auswertungstool oder einen VR (o.ä.) Adapter, der X6 nach eBUS konvertieren kann und vice versa
Und genau für letzteres ist der VR 39 gedacht. Der Hinweis von Vaillant bzgl. der "Schnittstelle 7-8-9" hat m.M.n. nichts mit dem Adapter zu tun, sondern soll die Kunden darauf hinweisen, dass die Anlage, die über einen Regler, der an "Schnittstelle 7-8-9" anzuschliessen wäre (bzw. angeschlossen ist), nach der Erweiterung mit dem VR 39 Modul auch eBus versteht und entsprechend Geräte angeschlossen werden können. Der Hinweis auf "Schnittstelle 7-8-9" ist vermutlich die Abgrenzung zu anderen Geräten, die diese Schnittstelle nicht haben UND dadurch vermutlich auch nicht die X6 Schnittstelle. Es gibt auch keinerlei Hinweise oder Installationsanweisungen, dass da irgendetwas an 7-8-9 anzuschliessen sei.
Zitat aus der Funktionsbeschreibung des VR 39 Adapters:
Zitatfür den Anschluss eines nicht eBUS-fähigen Wärmeerzeugers (Schnittst. 7-8-9) an einen eBUS Regler
Ich interpretiere das wie folgt:
ZitatEin Adapter, der an die X6 Schnittstelle eines Wärmeerzeugers, der über die Schnittstelle 7-8-9 verfügt, angeschlossen wird, um einen(?) Regler anstatt über die "alte Schnittstelle 7-8-9", am eBUS einsetzen zu können.
Hello guys,
Is there any knowledge on the S-Bus protocol used by Oventrop?
I have an Oventrop Regusol solar panel controller and I would like to be able to connect to it mainly in order to read temp. sensors and circulation pump load.
Here is a link to their dedicated S-Bus adapter, which unfortunately costs around 130€ and I am not even sure if it can act as a gateway:
https://www.oventrop.com/en-GB/productssystems/articledetails/1369531
https://www.oventrop.com/article/1369531
Installation and Operating Manual:
https://www.manualslib.com/manual/2143748/Oventrop-Regtronic-S-Bus.html#product-Regtronic%20S-Bus
Is there any solution to read the sensor values and persist them towards a smart-home eco system? (such as to a mqtt broker)
Perhaps this protocol is compatible with e-bus?
thanks a lot,
Cristian
Zitat von: john30 am 12 Oktober 2021, 19:40:28
das ist der contrib Ordner vom ebusd clone. Du bräuchtest wenn dann einen clone von ebusd-configuration (https://github.com/john30/ebusd-configuration/) und würdest dann den configpath auf einen Ordner darin umstellen.
Wenn Du eigene CSVs erzeugen willst, ist der "kleine Umweg" über Libreoffice o.ä. auf jeden Fall hilfreich, denn sonst muss man schon sehr genau schauen, in welche Spalte was rein kommt. Hilfreich könnte dabei aber noch das relativ junge "define" Kommando des ebusd CLI (https://github.com/john30/ebusd/wiki/3.1.-TCP-client-commands#define) sein.
Hi John,
ich habe es genauso mal probiert. Ich habe mit den Ordner kopiert und die CSV selbst erzeugt. Die CSVs hat es auch eingelesen und alles hat weiterhin funktioniert.
Ausnahme bleibt weiter das ich folgenden Werte nicht lesen kann
ebusctl r -c sc Col
Ich erhalte nach wie vor diesen Fehler:
ERR: invalid position in decode
Anbei der Auszug aus der CSV (ec.sol.sc.csv)
r,,Col,KOL,,,,400,,,tempsensor,,,value and sensorstate of the collector sensor,,,
Einige andere Werte lassen sich problemlos aus dieser CSV auslesen.sc Col = ERR: invalid position in decode
sc ColKickPumpTime = ERR: invalid position in decode
sc ColKickTempDelta = ERR: invalid position in decode
sc CollPump = ERR: invalid position in decode
sc CurrentASCStateforASI = 0
sc CurrentASCStateforExternals = 2
sc currenterror = -;-;-;-;-
sc CurrentSolTempDesired = 504
sc CurrentVPMLoadingMode = 7
sc D1Temp = ERR: invalid position in decode
sc D2Temp = ERR: invalid position in decode
sc Date = ERR: invalid position in decode
sc DateAndTimeIsSet = 6
sc EDFunction = ERR: invalid position in decode
sc EnableScProtection = ERR: invalid position in decode
sc errorhistory = ERR: end of input reached
sc ExternalHcRequest = off
sc ExternalHcTempDesired = 48
sc ExternalHwcRequest = off
sc ExternalHwcTempDesired = 48
sc FlowRate = ERR: invalid position in decode
sc FrostProtectionEnabled = ERR: invalid position in decode
sc FrostProtectionLimit = ERR: invalid position in decode
sc Hc1PumpKol1PP1Port = ERR: invalid position in decode
sc Hc2aLegPumpP2Port = ERR: invalid position in decode
sc Hc2zPort = ERR: invalid position in decode
sc HydraulicScheme = ERR: invalid position in decode
sc InitCircuit = ERR: invalid position in decode
sc IsInBoostMode = ERR: invalid position in decode
sc KickFunction = ERR: invalid position in decode
sc LpZpMaPort = ERR: invalid position in decode
sc MAPreferredStorage = ERR: invalid position in decode
sc MaximalTemp = ERR: invalid position in decode
sc MaximalTemp2 = ERR: invalid position in decode
sc MonitorMatlabLast5minSolAverage = 0
sc MultifunctionOutput = ERR: invalid position in decode
sc Ntc1RawData = ERR: invalid position in decode
sc Ntc1Sensor = 28.25;ok
sc Ntc2RawData = ERR: invalid position in decode
sc Ntc2Sensor = 28.12;ok
sc Ntc3RawData = ERR: invalid position in decode
sc Ntc3Sensor = 27.19;ok
sc Ntc4RawData = ERR: invalid position in decode
sc Ntc4Sensor = 25.69;ok
sc OMultifunction = ERR: invalid position in decode
sc PumpAntiLockingFlags = ERR: invalid position in decode
sc QuickVetoStart = ERR: invalid position in decode
sc ResetSolGain = ERR: invalid position in decode
sc RuntimeCollPump = ERR: invalid position in decode
sc RuntimeCollPumpSeconds = ERR: invalid position in decode
sc RunTimePump1Hours = 1744
sc RunTimePump1Minutes = 57
sc ScProtectionHysteresis = ERR: invalid position in decode
sc ScProtectionLimit = ERR: invalid position in decode
sc ScProtectionTime = ERR: invalid position in decode
sc SolCollPumpDcIntegrator = ERR: invalid position in decode
sc SolCollPumpED = ERR: invalid position in decode
sc SolGain = ERR: invalid position in decode
sc SolOperationMode = ERR: invalid position in decode
sc SolPumpPower = 0
sc SolPumpRelay = off
sc SP1 = ERR: invalid position in decode
sc SP2 = ERR: invalid position in decode
sc SumSolGain = ERR: invalid position in decode
sc SumSolGainDayBefore = ERR: invalid position in decode
sc SystemMode = ERR: invalid position in decode
sc TempDifferenceOff = ERR: invalid position in decode
sc TempDifferenceOff2 = ERR: invalid position in decode
sc TempDifferenceOffTD12 = ERR: invalid position in decode
sc TempDifferenceOn = ERR: invalid position in decode
sc TempDifferenceOn2 = ERR: invalid position in decode
sc TempDifferenceOnTD12 = ERR: invalid position in decode
sc Time = ERR: invalid position in decode
sc Weekday = ERR: invalid position in decode
sc YieldLastYear = ERR: invalid position in decode
sc YieldThisYear = ERR: invalid positionIch möchte halt den Temperaturfühler des Kollektors auf dem Dach auslesen. An meiner Vaillant Station kann ich auch den Wert manuell ablesen, so dass ich sicher gehen kann das der Sensor intakt ist.
Hast du noch eine Idee?
@tlc:
ZitatPerhaps this protocol is compatible with e-bus?
No, it is not.
Regards
pah
@Dre83:
ZitatEinige andere Werte lassen sich problemlos aus dieser CSV auslesen.
Das sehe ich aber im Beispiel nicht - sondern der Fehler tritt überall auf.
Wie ich schon vor Jahren geschrieben habe, und John30 gerade auch wieder bestätigt hat: besser NICHT in den CSV-Dateien herumeditieren, sondern einen Import/Export über LibreOffice machen. Viel komfortabler und fehlerfreier. Und im Übrigen vlt. einfach mal versuchen, das Protokoll zu verstehen, etwa an Hand der geposteten Dokumente.
LG
pah
Hallo pah,
ich habe gestern auch den Ipmort und dann wieder Export mit Excel 2016 gemacht. Geht das nicht auch?
Oder brauche ich da zwingend libre office?
VG André
Nö, Excel geht auch - für Openoffice hatte wir aber schon die richtigen Makros, so dass der Export mit einem Mausklick möglich war. Wenn das in Excel auch funktioniert, ist das hervorragend.
LG
pah
Frage wegen currenterror reading
ich frage meine Heizung per
#Fehler Therme
get Error cmd {"r -f -c bai currenterror \n"}
get Error expect "d+\;\d+\;\d+\;\d+\;\d+\n\n"
get Error postproc { s/(\d+)\;\d+\;\d+\;\d+\;\d+\n\n/$1/;;$_}
# ab.
leider komme ich bei der regex nicht weiter, er matched nicht.
im Standartfall sieht die Message ja so aus -;-;-;-;-
im Fehlerfall so 27;-;-;-;-
nun ist ja "-" keine Zahl also geht \d+ nicht.
wie müsste expect und postproc aussehen um den ersten Fehler zurück zugeben oder den kpl. string?
und wie kann ich das ; gegen ein anderes symbol tauschen, da dieses später in fhem Probleme macht.
Danke für die Hilfe
Maik
Nach 2 Tagen Lesen habe ich die 226 Seiten dieses Beitrags auch durch und möchte dazu ein paar Anmerkungen machen. Erst einmal Respekt für die geleistete Arbeit (sowohl zeitlich als auch qualitativ gesehen)! Habe mich für das Thema interessiert, weil ich anfangs davon ausgegangen war, meine Vaillant würde eBus sprechen. Zu diesem Zeitpunkt war auf der Vaillant Seite nur von "eBus" zu lesen und ich war davon ausgegangen, dass alle aktuellen Vaillant Gerräte das auch könnten. Informationen zum eBus waren nur als eBus-Vereinsmitglied mit entsprechenden horrenden Mitgliedsbeiträgen zu bekommen und ich habe daher die Automatisierung erst mal pausiert. Leider habe ich erst sehr herausgefunden, dass meine Vaillant gar kein eBus kann dafür aber die (viel einfachere) X6-Service-Schnittstelle hat. Da genügt ein einfacher RS232-TTL-Wandler als Hardware und (mangels Multimaster) ist auch keine zeitkritische Arbitrierung notwendig. Protokoll findet sich mehr oder weniger auf zwei Seiten im Netz, der Großteil des Rests ergibt sich aus der Datenbank der Vaillant-Software.
Den Sinn einer Umsetzung von der Serviceschnittstelle auf eBus erschließt sich mir nicht, es wird weder schneller kommuniziert noch werden zusätzliche Parameter zur Verfügung gestellt.
Zitatnach kurzer Recherche: X6 ist eine serielle Schnittstelle wogegen 7-8-9 lediglich eine Pulsweitenmodulation und evtl. noch eine unterschiedliche Amplitude erlaubt.
Das mag für ältere Geräte gelten, bei neueren Geräten wird da definitiv drüber kommuniziert, vermutlich aufmoduliert auf das ursprüngliche Analogsignal. Man muss nur mal in die Bedienungsanleitung eines Reglers schauen, beispielsweise die "Partyschaltung"
ZitatDiese erlaubt es Ihnen, daß die Heiz- und Warmwasserzeiten über den nächsten Abschaltpunkt hinaus fortgesetzt werden.
Wie soll das über ein Analogsignal funktionieren?
Dann die Uhrzeit selber: Der DCF-Empfänger ist an der Elektronik der Therme angeschlossen, angezeigt wird die Uhrzeit aber auch am Regler. Wie soll das gehen ohne Kommunikation?
ZitatEs ist immer die Rede von "Elektronikbox"
Das ist in der Vaillant Sprachweise nichts anderes als der Platz im Kunststoffgehäuse der Hauptelektronik. Da ist an der Seite Platz vorgesehen für eine Zusatzelektronik wie z.B. das Multifunktionsmodul.
Dann zu den Steckern:
- X6 = Serviceschnittstelle mit TTL-Pegel, 5V und 24V.
- X30 = eBus Schnittstelle.
Was ich nicht ganz verstanden habe wenn hier über Schaltungsversionen mit/ohne Poti diskutiert wird: der eBus-Verein hat zwei Schaltungsversionen veröffentlicht, einmal ohne und einmal mit galvanischer Trennung. Haben diese nicht funktioniert oder weshalb macht man da was Eigenes?
Dann noch was Allgemeines: wenn ich hier lese, dass die Vaillant Elektronik öfters stirbt: meine hat mittlerweile 15 Jahre auf dem Buckel. Ich wäre diesbezüglich vorsichtig mit allem was Parameter schreibt. Man muss damit rechnen, dass die Parameter jedesmal in den Flash/Eeprom-Speicher geschrieben werden. Das geht nicht unbegrenzt oft.
Moin,
seit einem Update von ebusd (auf Version 22.3) und ttyebus (auf Version 1.8 ) treten häufig (ca. zweimal pro Stunde) Fehler beim Lesen/Schreiben auf dem ebus auf (ich lese im 2-Minuten-Abstand Werte aus der Heizungsanlage):
Zitat2022-07-19 15:14:02.255 [bus error] send to 08: ERR: arbitration lost, retry
2022-07-19 15:14:02.446 [bus error] send to 08: ERR: arbitration lost, retry
2022-07-19 15:14:02.635 [bus error] send to 08: ERR: arbitration lost
2022-07-19 15:14:02.635 [bus error] send message part 0: ERR: arbitration lost
Kann mir da jemand weiterhelfen, wie ich diese Fehler abstellen kann?
Mit den alten Versionen (ebusd: 3.2, ttyebus: 1.5) hatte ich gar keine Probleme.
VG Günter
So... nun wird es mal Zeit, hier DANKE zu sagen. Ich habe es durch das Forum mit viel Try-and-Error nun geschafft, meinen Esera Ebus-Koppler in Betrieb zu nehmen und die ersten Auswertungen zu starten.
Hier sieht man direkt den sagenhaften Effizienzwert meiner Solaranlage (exakt 0%! - zu wenig Druck, bzw. Luft im System). Ohne die anschaulichen Chats (s. Anhang) wäre mir das fast gar nicht aufgefallen.
Jetzt muss ich mal herausfinden, was es noch so alles für Werte in meiner Anlage gibt, und welche sich davon sinnvoll aufbereiten lassen. Vielleicht hat ja noch jemand Tipps?
Also noch mal vielen Dank an die ganzen Experten hier!
Gruß Swen
Eine Frage schieb ich noch nach. Die Einträge zur einmaligen Speicherladung sind ja alle schon ein wenig älter. Wie bekomm ich das am elegantesten gelöst? Ich würde gern Warmwasser-Heizzeiten auf ein Minimum begrenzen und wenn man dann doch mal außer der Reihe warmes Wasser braucht, hätte ich gern einen Knopf, um den Speicher einmalig zu laden. Wie habt ihr das gelöst?
Meine Vaillant-Heizung läuft mit dem eBUS Adapter 3.0 sehr stabil. Jetzt hab ich aber eine Frage, auf die ich noch keine Antwort gefunden habe: Als Regler setze ich calormatic 470f ein, also funkgebunden. Da sind gerade die Batterien fast alle. Ich hätte gedacht, dass ich das überwachen kann und eine Benachrichtigung auslösen kann, hab aber bislang kein Reading gefunden, woraus ich die Information gewinnen könnte. Hat das jemand einen Tipp?
Oh man, micht hats grad bei nem Update vom ebusd blöde erwischt ???
Ich habe mittels dpkg -P ebusd die alte Installation entfernt.
Neu installiert, soweit alles gut.
Da ich zwei Ebus Controller habe, habe ich auch zwei Service Files
RPI2 mit Buster, ist also ein systemd System.
Die Service Files liegen beide in /etc/systemd/system
Beide Files wurden nicht verändert und liefen auch vorher schon.
Automatisch gestartet werden beide services auch, also systemctrl enable ebusd-air.service und ebusd-heat.service
Status:
systemctl status ebusd-heat.service
● ebusd-heat.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd-heat.service; enabled; vendor preset: enabled)
Active: activating (start) since Sat 2022-09-24 10:21:41 CEST; 43s ago
Process: 599 ExecStart=/usr/bin/ebusd -d /dev/ttyebus -p 8888 -l /var/log/ebusd-heat.log --scanconfig=full --httpport=8889 --latency=20000 --receivetimeout=50000 --enablehex (code=exited, status=0/SUCCESS)
Tasks: 4 (limit: 2059)
CGroup: /system.slice/ebusd-heat.service
└─600 /usr/bin/ebusd -d /dev/ttyebus -p 8888 -l /var/log/ebusd-heat.log --scanconfig=full --httpport=8889 --latency=20000 --receivetimeout=50000 --enablehex
Sep 24 10:21:41 R2D2 systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Sep 24 10:21:42 R2D2 systemd[1]: ebusd-heat.service: Can't open PID file /run/ebusd-heat.pid (yet?) after start: No such file or directory
Status:
systemctl status ebusd-air.service
● ebusd-air.service - ebusd, the daemon for communication with eBUS heating systems.
Loaded: loaded (/etc/systemd/system/ebusd-air.service; enabled; vendor preset: enabled)
Active: activating (start) since Sat 2022-09-24 10:21:37 CEST; 1min 20s ago
Process: 597 ExecStart=/usr/bin/ebusd -d enh:/dev/ttyUSB0 -p 8898 -l /var/log/ebusd-air.log --scanconfig=full --httpport=8899 --latency=20000 --receivetimeout=50000 --enablehex (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 2059)
CGroup: /system.slice/ebusd-air.service
Sep 24 10:21:37 R2D2 systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
Sep 24 10:21:38 R2D2 systemd[1]: ebusd-air.service: Can't open PID file /run/ebusd-air.pid (yet?) after start: No such file or directory
Das mit dem PID verstehe ich nicht warum es da zu einem Fehler kommt?
Und warum lädt er nicht den air service?
Muss ich den Standard Service ebusd auch enable setzen, nach meinen Verständnis nicht?
Ok Fehler gefunden.
Anscheinend war es vorher kein Problem den Services verschiedene PID zu geben.
Nun scheint es aber anders zu sein und die PID's sollten bei beiden Services /var/run/ebusd.pid sein.
So laufen nun beide Services wieder.
Zitat von: Wolpertinger am 24 September 2022, 11:15:58
Ok Fehler gefunden.
Anscheinend war es vorher kein Problem den Services verschiedene PID zu geben.
Nun scheint es aber anders zu sein und die PID's sollten bei beiden Services /var/run/ebusd.pid sein.
So laufen nun beide Services wieder.
nein, aber man muss die Anpassung des PID File auch dem systemd mitteilen in der entsprechenden /etc/systemd/system/ebusd-heat.service
Hallo john30,
bei einem Update der Konfigfiles ist mir ein Fehler in den englischen Files aufgefallen:
Im File
ebusd-configuration/ebusd-2.1.x/en/vaillant/0a.pmw.hwc.csv
sollte in Zeile 18 für OperatingMode das Template wieder auf "hwcmode2" geändert werden.
Mit mcmode passieren leider recht überraschende Dinge...
Gruß
Stef
Hallo zusammen,
mein MQTT Problem ist endlich gelöst.
Nun gibt es nur noch eines, nämlich, dass meine calormatic 470/3 nicht erkannt wird.
Siehe Details hier:
https://github.com/john30/ebusd-configuration/issues/282 (https://github.com/john30/ebusd-configuration/issues/282)
In der ebusd-log läuft ein Fehler auf - hängt das damit zusammen?
[main error] scan config 15:ERR: wrong symbol received
Hat da jemand einen Tipp für mich?
VG und Danke
Zitat von: Physman am 05 November 2022, 12:33:58
Nun gibt es nur noch eines, nämlich, dass meine calormatic 470/3 nicht erkannt wird.
Siehe Details hier:
https://github.com/john30/ebusd-configuration/issues/282 (https://github.com/john30/ebusd-configuration/issues/282)
In der ebusd-log läuft ein Fehler auf - hängt das damit zusammen?
[main error] scan config 15:ERR: wrong symbol received
wie schon hier geschrieben https://forum.fhem.de/index.php/topic,46098.msg1244241.html#msg1244241
Liebe Gemeinde,
kennt jemand den Unterschied zwischen den beiden Werten einer Vaillant BAI-Anlage TargetFanSpeed (0x2400 / d.33) und TargetFanSpeedOutput (0x9f00)?
Ich habe die Frage im eBus-Repository unter #755 (https://github.com/john30/ebusd/discussions/755) hinterlegt und würde mich freuen, wenn jemand weiterhelfen könnte.
Schöne Grüße
Christian
Hallo Zusammen,
ich habe eine Vaillant geotherm VWL 81/3. Ich lese die Anlage per ebus Platine 2.0 aus.
Funktioniert und er findet auch einige Sache. Ich bekomme jedoch die bai nicht aufgelistet, sprich die ganzen Informationen der Ausseneinheit.
ebusconfig:
EBUSD_OPTS3="-d /dev/ebuswpusb -p 8890 --loglevel=info --pidfile=/var/run/ebusdgeothermusb.pid --logfile=/var/log/ebusd/ebusdgeothermusb -c http://cfg.ebusd.eu/ --scanconfig=full --pollinterval=300 --mqtthost=localhost --mqttport=1883 --mqttjson --mqtttopic=ebusd/%circuit/%name"
localhost: scan result
08;Vaillant;EHP00;0412;7201;??;??;??;??????????;????;??????;??
15;Vaillant;UIH00;0362;6901;21;10;29;0020101780;0907;005256;N5
23;Vaillant;EHP00;0412;7201;??;??;??;??????????;????;??????;??
25;Vaillant;EHP00;0412;7201;??;??;??;??????????;????;??????;??
50;Vaillant;EHP00;0412;7201;??;??;??;??????????;????;??????;??
Den Full Scan habe ich schon bei laufender Außeneinheit ausgeführt, er findet diese aber nicht.
Hat jemand erfolgreich seine Ausseneinheit ausgelesen und hat jemand ein Idee, was ich evtl. tun kann?
@john30: Hast du einen Tipp, was ich da noch machen kann?
Gruß
Servus,
warum bai?
Gleiche Anlage läuft bei mir mit 08.ehp.csv
Servus,
meine Vaillant VWL wurde vor einiger Zeit resettet.
Wie bekomme ich den alten Zählerstand wieder in die Anlage.
15.uih.csv wäre es YieldSum zum auslesen, das geht auch, aber wie kann ich den alten Wert setzen?
Zitat von: Wolpertinger am 24 Januar 2023, 15:39:54
Servus,
warum bai?
Gleiche Anlage läuft bei mir mit 08.ehp.csv
Hi,
Wie kannst du den die Ausseneinheit auslesen. Lüfterdrehzahl der Anlage wäre interessant.
In der ehp hab ich dazu nichts gefunden.
Gruss
Ich habe vor, meine beiden USB Anschlüsse (Vaillant Therme und Vaillant VRS620) auf einen neuen Raspi mit frischem Debian (Bullseye) zu übertragen.
Zur Info: Da ich keine Standardinstallation (Heizung) habe, sind Therme und Regler nicht über ein und denselben Ebus zu erreichen und dürfen das auch nicht, da sie sich sonst falsche Sollwerte zuwerfen.
Jedes Gerät hat einen eigenen Konverter V2.0
Neueste Version ebus ist nun installiert, ein Gerät ist angebunden.
pi@raspberrypi:~ $ ebusctl info
version: ebusd 23.1.23.1
device: /dev/ttyUSB0
signal: acquired
symbol rate: 41
max symbol rate: 195
min arbitration micros: 508
max arbitration micros: 1764
min symbol latency: 4
max symbol latency: 6
reconnects: 0
masters: 3
messages: 538
conditional: 9
poll: 0
update: 10
address 10: master #2
address 15: slave #2, scanned "MF=Vaillant;ID=UI ;SW=0324;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd
address 3f: master #23
address 44: slave #23, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301"
address 50: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, scanned "MF=Vaillant;ID=SOLSY;SW=0306;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
Der Anschluss bei einem Gerät klappt also und wird gefunden, die Werte erhalte ich auch in FHEM.
Folgende /etc/default/ebusd Konfiguration ist in Benutzung:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
# EBUSD_OPTS="--scanconfig"
EBUSD_OPTS="-d /dev/ttyUSB0 -p 8888 -l /var/log/ebusd.log --scanconfig --latency=20000 --receivetimeout=50000"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Um nun den zweiten ebus/USB Anschluss auszulesen, verstehe ich es richtig, das ich einfach 2 der Zeilen unten einrücke und dem oberen einen # voranstelle oder muss an anderer Stelle in anderen Dateien/Verzeichnissen auch noch editiert werden?
Schnittstellenabfrage gibt mir folgendes (zweiter Konverter ist noch nicht angeschlossen, hängt noch auf dem alten Raspi):
pi@raspberrypi:~ $ sudo dmesg | grep -i tty
[ 0.000000] Kernel command line: coherent_pool=1M snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=Composite-1:720x480@60i vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyAMA0,115200 console=tty1 root=PARTUUID=e39fdea4-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000655] printk: console [tty1] enabled
[ 2.976504] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 114, base_baud = 0) is a PL011 rev2
[ 2.976911] printk: console [ttyAMA0] enabled
[ 6.348494] systemd[1]: Created slice system-getty.slice.
[ 6.352946] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 10.653008] usb 1-1.4: cp210x converter now attached to ttyUSB0
Zitat von: theotherhalf am 27 Januar 2023, 16:52:31
Um nun den zweiten ebus/USB Anschluss auszulesen, verstehe ich es richtig, das ich einfach 2 der Zeilen unten einrücke und dem oberen einen # voranstelle oder muss an anderer Stelle in anderen Dateien/Verzeichnissen auch noch editiert werden?
einfach EBUSD_OPTS behalten und zusätzlich EBUSD_OPTS1 konfigurieren (sofern das OS nicht systemd basiert ist)
Hallo!
Heizgräte von Vaillant und auch anderer Hersteller sind wohl Smart Grid Ready (SG-Ready). Wie ich das verstehe, nimmt diese "Smart Grid Schnittstelle" nur einen trockenen Kontakt entgegen und in der Heizanlage wird dann z.B. der Speicher höher aufgeheizt wenn PV-Überschuss oder ein günstiger Stromtarif zur Verfügung steht.
Meine Frage daher: Gibt es einen Wert dafür am ebus (Vaillant Wärmepumpe) bzw. wie könnte ich den finden? Es wäre schon elegant wenn man SG über ebus ansteuern könnte und nicht nebenher aus FHEM ein Relais schalten müsste welches dann die SG Information an die Heizung liefert.
Danke, Michael
Hallo zusammen,
habe eine Vaillant ecoTEC plus mit VCR710 und internet VR921.
ebus ist installiert auf rpi 3 mit externem ebus Adapter usb.
Der ebus scheint zu laufen und ich bekomme auch Daten über MQTT (Status01,Status02.....)
ebusctl i liefert:
version: ebusd 23.1.23.1-8-g9c0af7b9
update check: revision 23.1 available
device: /dev/ttyUSB0
access: *
signal: acquired
symbol rate: 23
max symbol rate: 114
min arbitration micros: 334
max arbitration micros: 562
min symbol latency: 5
max symbol latency: 13
reconnects: 1
masters: 3
messages: 225
conditional: 3
poll: 0
update: 10
address 00: master #1
address 03: master #11
address 08: slave #11, scanned "MF=Vaillant;ID=BAI00;SW=1002;HW=7603", loaded "vaillant/bai.308523.inc", "vaillant/08.bai.csv"
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanning
Ich wollte jetzt noch das Zeitprogramm abfragen, das gelinkt nicht da er die Parameter nicht kennt.
Habe ich bei der Instalation etwas vergessen oder wie kann ich ihm beibrigen diese Daten zu holen?
Mit der App auf dem Handy funktioniert das problemlos und der VR921 hängt ja auch am ebus.
für einen Hinweis wäre ich sehr dankbar.
Gruß
Ulrich
@UvG
welche config hast du und welchen eBus-Adapter?
LG
Ben
Hallo Ben
Als Adapter verwende ich den ESERA eBus Koppler USB.
config:
# /etc/default/ebusd:
# config file for ebusd service.
# Options to pass to ebusd (run "ebusd -?" for more info):
#EBUSD_OPTS="--scanconfig"
EBUSD_OPTS="--scanconfig=full -p 8888 -l /var/log/ebusd.log -d /dev/ttyUSB0 --latency=20 --httpport=8081 --mqttjson --mqtttopic=ebusd/%circuit/%name --configpath=http://cfg.ebusd.eu --mqtthost=192.168.188.39 --mqttport=1883 --mqttuser=<MQTT-USERNAME> --mqttpass=<MQTT-PASSWORT> --accesslevel=* --scanconfig=full"
# MULTIPLE EBUSD INSTANCES WITH SYSV
# In order to run multiple ebusd instances on a SysV enabled system, simply
# define several EBUSD_OPTS with a unique suffix for each. Recommended is to
# use a number as suffix for all EBUSD_OPTS settings. That number will then be
# taken as additional "instance" parameter to the init.d script in order to
# start/stop an individual ebusd instance instead of all instances.
# Example: (uncomment the EBUSD_OPTS above)
#EBUSD_OPTS1="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p 8888 -l /var/log/ebusd1.log"
#EBUSD_OPTS2="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900acTF-if00-port0 -p 8889 -l /var/log/ebusd2.log"
#EBUSD_OPTS3="--scanconfig -d /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A900beCG-if00-port0 -p 8890 -l /var/log/ebusd3.log"
# MULTIPLE EBUSD INSTANCES WITH SYSTEMD
# In order to run muiltiple ebusd instances on a systemd enabled system, just
# copy the /lib/systemd/system/ebusd.service file to /etc/systemd/system/
# with a different name (e.g. ebusd-2.service), remove the line starting with
# 'EnvironmentFile=', and replace the '$EBUSD_OPTS' with the options for that
# particular ebusd instance.
Zitat von: HaWe68 am 22 Oktober 2021, 18:43:15Hallo,
Kann mir jemand mit einer Vaillant-Therme sagen, wie man die Solarpumpe per ebus starten kann ?
Programm P0 , SP lässt die Pumpe laufen, um den Volumenstrom einstellen zu können oder zu entlüften.
Im Winter wäre es praktisch, bei Schnee auf den Kollektoren die Solarpumpe laufen zu lassen, damit der Schnee antaut und dann schneller abrutschen kann, da das warme Wasser aus der Therme zu den Kollektoren kommt ...
Ich möchte die Frage nochmal stellen, da bisher leider nichts passendes dazu geschrieben wurde.
Das Programm P0/SP muss ander Therme gewählt werden. Könnte das auch per ebus-Adapter gestartet werden ?
Nach neun Jahren klagloser Dienstleistung hat jetzt der allererste selbst zusammengelötete EBUS-Adapter, mit dem ich diesen Thread begonnen habe, seinen Geist aufgegeben. Ich steige deshalb jetzt auf einen EBUS-Adapter 2.2 um, der direkt auf die Schnittstelle des Raspberry Pi aufgesetzt wird.
Das erste, was ich feststellte: Der Link im FHEMWiki auf die neueren Informationen lief ins Leere, habe ich gleich ausgebessert.
Ansonsten finde ich es eigentlich sehr befriedigend, was aus dieser Sache geworden ist...
LG
pah
Das sieht so aus, als ob die Synchronisation mit den Signalen auf dem Bus nicht richtig funktioniert. Ich kenne die Technik hinter dieser Adapter-Version nicht, aber die scheint außer Takt zu geraten.
Bei meinen allerersten Versuchen 2014 trat Ähnliches auf, weil der Raspberry Pi (Model 1, also Steinzeit) seine serielle Schnittstelle nur emuliert.
LG
pah
Zitat von: Rainer1 am 12 November 2023, 11:28:36Ich habe ständig Fehler auf dem Bus mit dem neuen Adapter V5. Das ist natürlich sehr unzuverlässig, da Werte fehlen um eine Grafik zu erzeugen, gerade wenn sich Werte schnell ändern. Sollte mit dem neuen Adapter nicht alles besser werden ?
Der Adapter hängt im WLAN, kann es sein, dass das zum Problem führt ?
Auch werden oft Werte per MQTT nicht geschrieben - ist der Bus überlastet ?
Die ebusd.log ist nach 1,5h bereits 250k groß, macht am Tag 4MB !!!
Der Fehler "[bus error] poll 470 YieldThisYear failed" tritt mit dem neuen Adapter V5 sehr viel häufiger auf, als mit dem TTL-Adapter (Poti-Version)
die WIFI Anbindung ist von je her schwierig, weil du für einen vernünftigen Betrieb Latenzzeiten unter 20ms bräuchtest. Das ist je nach Überlagerung benachbarter Netze oder mit entsprechender Auslastung des eigenen flott mal unmöglich.
Der Adapter V5 ist Geschichte ! - keine Zeit und Nerven mehr um das irgendwie ans Laufen zu bekommen. Komisch dass der alte Adapter (habe auch noch 1 Ersatz ;) ) reibungslos, bis auf eine Ausnahme nach Umstellung auf MQTT, läuft.
Wie kann das Polling "poll 470 YieldThisYear" deaktiviert werden ? Das scheint erst in den neueren ebusd-Versionen umgesetzt worden zu sein ?
ZitatHier ist ja gar nichts mehr los !
Nicht doch. Das ist eher ein Zeichen dafür, dass die Dinge problemlos laufen und gut dokumentiert sind.
pah
Hallo Zusammen,
ich habe aktuell ein Problem meinen eBusd zum Laufen zu bringen.
Ich verstehe aktuell, dass mein Gateway wohl nicht schreiben kann? Ist der Ansatz richtig? Was kann ich hier dann tun um das Problem zu lösen?
Folgendes Setup:
- Esera Eco ECO305_MCU3 Ebus Gateway
- ebusd auf Ubuntu (ebusd 23.2.23.2-71-g53fcc90f)
- Vaillant Gas Hybrid Heizungssystem mit:
- - Vaillant AroTherm 125/5 WP
- - Vaillant EcoVit VKK 476/4 Gasheizung
- - Vaillant VR71 Mischermodul
Meine Ebusd Settings in /etc/default/ebusd
EBUSD_OPTS="--configpath=http://cfg.ebusd.eu -d 10.0.0.83:5001 -p 8888 --logareas all --loglevel debug -l /var/log/ebusd.log --scanconfig=full --httpport=8889 --htmlpath=/var/ebusd/html"ebusctl info
version: ebusd 23.2.23.2-71-g53fcc90f
device: 10.0.0.83:5001, TCP
signal: acquired
symbol rate: 113
max symbol rate: 184
min arbitration micros: 1
max arbitration micros: 340
min symbol latency: 23
max symbol latency: 42
scan: finished, some messages pending
reconnects: 0
masters: 1
messages: 11
conditional: 0
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd, scanningLogfile nach Start des Ebusd
2023-12-25 10:09:47.078 [bus notice] device status: transport opened
2023-12-25 10:09:47.079 [main info] registering data handlers
2023-12-25 10:09:47.079 [main info] registered data handlers
2023-12-25 10:09:47.079 [main notice] ebusd 23.2.23.2-71-g53fcc90f started with full scan on device: 10.0.0.83:5001, TCP
2023-12-25 10:09:47.079 [main info] loading configuration files from http://cfg.ebusd.eu/
2023-12-25 10:09:47.107 [main info] reading templates /
2023-12-25 10:09:47.135 [main info] read templates in /
2023-12-25 10:09:47.135 [main info] reading file broadcast.csv
2023-12-25 10:09:47.161 [main info] successfully read file broadcast.csv
2023-12-25 10:09:47.161 [main info] reading file memory.csv
2023-12-25 10:09:47.190 [main info] successfully read file memory.csv
2023-12-25 10:09:47.190 [main info] read config files, got 11 messages
2023-12-25 10:09:47.190 [bus notice] bus started with own address 31/36
2023-12-25 10:09:47.191 [bus notice] signal acquired
2023-12-25 10:09:47.729 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:48.207 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:48.842 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:49.337 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:49.438 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:09:49.810 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:49.812 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:49.823 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:49.919 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:50.050 [bus notice] max. symbols per second: 133
2023-12-25 10:09:50.132 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:50.138 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:50.407 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:50.502 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:50.757 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:51.008 [bus notice] max. symbols per second: 156
2023-12-25 10:09:51.026 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:51.136 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:51.386 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:51.389 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:51.495 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:51.583 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:51.586 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:51.807 [bus debug] ERR: read timeout during receive command CRC, switching to skip
2023-12-25 10:09:52.006 [bus notice] max. symbols per second: 184
2023-12-25 10:09:52.015 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:52.019 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:52.184 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:52.300 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:52.547 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:52.733 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:52.845 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:53.096 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:53.279 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:53.819 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:53.945 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:53.951 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:54.631 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:55.569 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:09:57.191 [main debug] performing regular tasks
2023-12-25 10:09:57.191 [main notice] starting initial full scan
2023-12-25 10:09:57.191 [bus info] scan 02 cmd: 3102070400
2023-12-25 10:09:57.367 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:57.371 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:57.375 [bus debug] start request 31
2023-12-25 10:09:57.375 [bus debug] arbitration start with 31
2023-12-25 10:09:57.444 [bus debug] arbitration won
2023-12-25 10:09:57.444 [bus debug] arbitration delay 1 micros
2023-12-25 10:09:57.444 [bus info] arbitration delay 1 - 1 micros
2023-12-25 10:09:57.444 [bus debug] switching from ready to send command
2023-12-25 10:09:57.471 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:09:57.471 [bus info] send/receive symbol latency 27 - 27 ms
2023-12-25 10:09:57.499 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:09:57.525 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:09:57.525 [bus info] send/receive symbol latency 25 - 27 ms
2023-12-25 10:09:57.553 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:09:57.553 [bus info] send/receive symbol latency 25 - 28 ms
2023-12-25 10:09:57.553 [bus debug] switching from send command to send command CRC
2023-12-25 10:09:57.580 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:09:57.580 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:09:57.645 [bus debug] notify request: ERR: read timeout
2023-12-25 10:09:57.645 [bus info] scan 04 cmd: 3104070400
2023-12-25 10:09:57.645 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:09:58.083 [bus debug] start request 31
2023-12-25 10:09:58.083 [bus debug] arbitration start with 31
2023-12-25 10:09:58.152 [bus debug] arbitration won
2023-12-25 10:09:58.152 [bus debug] arbitration delay 1 micros
2023-12-25 10:09:58.152 [bus debug] switching from ready to send command
2023-12-25 10:09:58.179 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:09:58.206 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:09:58.231 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:09:58.231 [bus info] send/receive symbol latency 24 - 28 ms
2023-12-25 10:09:58.256 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:09:58.256 [bus debug] switching from send command to send command CRC
2023-12-25 10:09:58.281 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:09:58.281 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:09:58.289 [bus debug] switching from receive command ACK to receive response
2023-12-25 10:09:58.380 [bus debug] notify request: ERR: read timeout
2023-12-25 10:09:58.380 [bus info] scan 05 cmd: 3105070400
2023-12-25 10:09:58.380 [bus debug] ERR: read timeout during receive response, switching to skip
2023-12-25 10:09:58.789 [bus debug] start request 31
2023-12-25 10:09:58.789 [bus debug] arbitration start with 31
2023-12-25 10:09:58.874 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:09:58.879 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:09:58.932 [bus debug] arbitration won
2023-12-25 10:09:58.932 [bus debug] arbitration delay 2 micros
2023-12-25 10:09:58.932 [bus info] arbitration delay 1 - 2 micros
2023-12-25 10:09:58.932 [bus debug] switching from ready to send command
2023-12-25 10:09:58.958 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:09:58.984 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:09:59.009 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:09:59.035 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:09:59.035 [bus debug] switching from send command to send command CRC
2023-12-25 10:09:59.061 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:09:59.061 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:09:59.066 [bus debug] switching from receive command ACK to receive response
2023-12-25 10:09:59.157 [bus debug] notify request: ERR: read timeout
2023-12-25 10:09:59.157 [bus info] scan 06 cmd: 3106070400
2023-12-25 10:09:59.157 [bus debug] ERR: read timeout during receive response, switching to skip
2023-12-25 10:09:59.157 [bus debug] start request 31
2023-12-25 10:09:59.157 [bus debug] arbitration start with 31
2023-12-25 10:09:59.576 [bus debug] arbitration lost
2023-12-25 10:09:59.576 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:09:59.664 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:09:59.664 [bus debug] start request 31
2023-12-25 10:09:59.664 [bus debug] arbitration start with 31
2023-12-25 10:10:00.110 [bus debug] arbitration lost
2023-12-25 10:10:00.110 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:00.199 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:00.199 [bus debug] start request 31
2023-12-25 10:10:00.199 [bus debug] arbitration start with 31
2023-12-25 10:10:00.667 [bus debug] arbitration won
2023-12-25 10:10:00.667 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:00.667 [bus debug] switching from ready to send command
2023-12-25 10:10:00.693 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:00.728 [bus debug] send/receive symbol latency 35 ms
2023-12-25 10:10:00.728 [bus info] send/receive symbol latency 24 - 35 ms
2023-12-25 10:10:00.754 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:00.779 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:00.779 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:00.829 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:00.829 [bus info] scan 08 cmd: 3108070400
2023-12-25 10:10:00.829 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:00.829 [bus debug] start request 31
2023-12-25 10:10:00.829 [bus debug] arbitration start with 31
2023-12-25 10:10:01.288 [bus debug] arbitration lost
2023-12-25 10:10:01.288 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:01.377 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:01.377 [bus debug] start request 31
2023-12-25 10:10:01.377 [bus debug] arbitration start with 31
2023-12-25 10:10:01.847 [bus debug] arbitration won
2023-12-25 10:10:01.847 [bus debug] arbitration delay 1 micros
2023-12-25 10:10:01.847 [bus debug] switching from ready to send command
2023-12-25 10:10:01.873 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:01.900 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:01.925 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:01.951 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:01.951 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:02.001 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:02.001 [bus info] scan 09 cmd: 3109070400
2023-12-25 10:10:02.001 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:02.002 [bus debug] start request 31
2023-12-25 10:10:02.002 [bus debug] arbitration start with 31
2023-12-25 10:10:02.460 [bus debug] arbitration lost
2023-12-25 10:10:02.460 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:02.563 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:10:02.564 [bus debug] start request 31
2023-12-25 10:10:02.564 [bus debug] arbitration start with 31
2023-12-25 10:10:02.609 [bus debug] arbitration lost
2023-12-25 10:10:02.610 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:02.702 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:03.141 [bus debug] start request 31
2023-12-25 10:10:03.141 [bus debug] arbitration start with 31
2023-12-25 10:10:03.248 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:10:03.272 [bus debug] arbitration won
2023-12-25 10:10:03.272 [bus debug] arbitration delay 301 micros
2023-12-25 10:10:03.273 [bus info] arbitration delay 1 - 301 micros
2023-12-25 10:10:03.273 [bus debug] switching from ready to send command
2023-12-25 10:10:03.302 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:03.332 [bus debug] send/receive symbol latency 30 ms
2023-12-25 10:10:03.359 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:03.385 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:03.385 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:03.435 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:03.435 [bus info] scan 0a cmd: 310a070400
2023-12-25 10:10:03.435 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:03.435 [bus debug] start request 31
2023-12-25 10:10:03.435 [bus debug] arbitration start with 31
2023-12-25 10:10:03.920 [bus debug] arbitration won
2023-12-25 10:10:03.920 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:03.920 [bus debug] switching from ready to send command
2023-12-25 10:10:03.947 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:03.972 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:03.998 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:04.023 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:04.023 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:04.052 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:04.052 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:04.117 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:04.117 [bus info] scan 0b cmd: 310b070400
2023-12-25 10:10:04.117 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:04.117 [bus debug] start request 31
2023-12-25 10:10:04.117 [bus debug] arbitration start with 31
2023-12-25 10:10:04.661 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:10:04.666 [bus debug] arbitration lost
2023-12-25 10:10:04.666 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:04.758 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:04.758 [bus debug] start request 31
2023-12-25 10:10:04.758 [bus debug] arbitration start with 31
2023-12-25 10:10:05.229 [bus debug] arbitration won
2023-12-25 10:10:05.229 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:05.229 [bus debug] switching from ready to send command
2023-12-25 10:10:05.254 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:05.281 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:05.308 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:05.339 [bus debug] send/receive symbol latency 29 ms
2023-12-25 10:10:05.339 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:05.365 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:05.365 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:05.430 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:05.430 [bus info] scan 0c cmd: 310c070400
2023-12-25 10:10:05.430 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:05.431 [bus debug] start request 31
2023-12-25 10:10:05.431 [bus debug] arbitration start with 31
2023-12-25 10:10:05.971 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:10:05.998 [bus debug] arbitration won
2023-12-25 10:10:05.998 [bus debug] arbitration delay 76 micros
2023-12-25 10:10:05.998 [bus debug] switching from ready to send command
2023-12-25 10:10:06.023 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:06.048 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:06.074 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:06.101 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:06.101 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:06.128 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:06.128 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:06.193 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:06.193 [bus info] scan 0d cmd: 310d070400
2023-12-25 10:10:06.193 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:06.193 [bus debug] start request 31
2023-12-25 10:10:06.193 [bus debug] arbitration start with 31
2023-12-25 10:10:06.655 [bus debug] arbitration won
2023-12-25 10:10:06.655 [bus debug] arbitration delay 1 micros
2023-12-25 10:10:06.655 [bus debug] switching from ready to send command
2023-12-25 10:10:06.686 [bus debug] send/receive symbol latency 31 ms
2023-12-25 10:10:06.721 [bus debug] send/receive symbol latency 34 ms
2023-12-25 10:10:06.746 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:06.772 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:06.772 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:06.797 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:06.797 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:06.862 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:06.863 [bus info] scan 0e cmd: 310e070400
2023-12-25 10:10:06.863 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:06.863 [bus debug] start request 31
2023-12-25 10:10:06.863 [bus debug] arbitration start with 31
2023-12-25 10:10:07.191 [main debug] performing regular tasks
2023-12-25 10:10:07.305 [bus debug] arbitration lost
2023-12-25 10:10:07.305 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:07.388 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:07.388 [bus debug] start request 31
2023-12-25 10:10:07.388 [bus debug] arbitration start with 31
2023-12-25 10:10:07.840 [bus debug] arbitration lost
2023-12-25 10:10:07.840 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:07.922 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:07.925 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:07.925 [bus debug] start request 31
2023-12-25 10:10:07.925 [bus debug] arbitration start with 31
2023-12-25 10:10:07.967 [bus debug] arbitration lost
2023-12-25 10:10:07.967 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:08.096 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:08.096 [bus debug] start request 31
2023-12-25 10:10:08.096 [bus debug] arbitration start with 31
2023-12-25 10:10:08.560 [bus debug] arbitration won
2023-12-25 10:10:08.560 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:08.560 [bus debug] switching from ready to send command
2023-12-25 10:10:08.586 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:08.613 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:08.639 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:08.665 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:08.665 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:08.715 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:08.715 [bus info] scan 12 cmd: 3112070400
2023-12-25 10:10:08.715 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:08.715 [bus debug] start request 31
2023-12-25 10:10:08.715 [bus debug] arbitration start with 31
2023-12-25 10:10:09.171 [bus debug] arbitration lost
2023-12-25 10:10:09.171 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:09.254 [bus debug] ERR: read timeout during receive command, switching to skip
2023-12-25 10:10:09.254 [bus debug] start request 31
2023-12-25 10:10:09.254 [bus debug] arbitration start with 31
2023-12-25 10:10:09.735 [bus debug] arbitration won
2023-12-25 10:10:09.735 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:09.735 [bus debug] switching from ready to send command
2023-12-25 10:10:09.759 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:09.787 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:09.816 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:09.843 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:09.843 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:09.893 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:09.893 [bus info] scan 14 cmd: 3114070400
2023-12-25 10:10:09.893 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:09.893 [bus debug] start request 31
2023-12-25 10:10:09.893 [bus debug] arbitration start with 31
2023-12-25 10:10:10.348 [bus debug] arbitration lost
2023-12-25 10:10:10.349 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:10.426 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:10.431 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:10.431 [bus debug] start request 31
2023-12-25 10:10:10.431 [bus debug] arbitration start with 31
2023-12-25 10:10:10.484 [bus debug] arbitration won
2023-12-25 10:10:10.484 [bus debug] arbitration delay 3 micros
2023-12-25 10:10:10.484 [bus debug] switching from ready to send command
2023-12-25 10:10:10.510 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:10.538 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:10.565 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:10.592 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:10.592 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:10.642 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:10.642 [bus info] scan 15 cmd: 3115070400
2023-12-25 10:10:10.642 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:10.642 [bus debug] start request 31
2023-12-25 10:10:10.642 [bus debug] arbitration start with 31
2023-12-25 10:10:11.120 [bus debug] arbitration won
2023-12-25 10:10:11.120 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:11.120 [bus debug] switching from ready to send command
2023-12-25 10:10:11.147 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:11.179 [bus debug] send/receive symbol latency 31 ms
2023-12-25 10:10:11.206 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:11.231 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:11.232 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:11.282 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:11.282 [bus info] scan 16 cmd: 3116070400
2023-12-25 10:10:11.282 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:11.282 [bus debug] start request 31
2023-12-25 10:10:11.282 [bus debug] arbitration start with 31
2023-12-25 10:10:11.761 [bus debug] arbitration won
2023-12-25 10:10:11.762 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:11.762 [bus debug] switching from ready to send command
2023-12-25 10:10:11.787 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:11.814 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:11.839 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:11.864 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:11.864 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:11.893 [bus debug] send/receive symbol latency 29 ms
2023-12-25 10:10:11.893 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:11.958 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:11.959 [bus info] scan 18 cmd: 3118070400
2023-12-25 10:10:11.959 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:11.959 [bus debug] start request 31
2023-12-25 10:10:11.959 [bus debug] arbitration start with 31
2023-12-25 10:10:12.399 [bus debug] arbitration lost
2023-12-25 10:10:12.399 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:12.471 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:12.477 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:12.477 [bus debug] start request 31
2023-12-25 10:10:12.477 [bus debug] arbitration start with 31
2023-12-25 10:10:12.484 [bus debug] ERR: SYN received during receive command, switching to ready
2023-12-25 10:10:12.488 [bus debug] arbitration lost
2023-12-25 10:10:12.488 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:12.564 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:12.570 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:12.570 [bus debug] start request 31
2023-12-25 10:10:12.570 [bus debug] arbitration start with 31
2023-12-25 10:10:12.640 [bus debug] arbitration won
2023-12-25 10:10:12.640 [bus debug] arbitration delay 1 micros
2023-12-25 10:10:12.640 [bus debug] switching from ready to send command
2023-12-25 10:10:12.666 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:12.693 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:12.727 [bus debug] send/receive symbol latency 33 ms
2023-12-25 10:10:12.754 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:12.754 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:12.782 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:12.782 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:12.786 [bus debug] switching from receive command ACK to receive response
2023-12-25 10:10:12.830 [bus debug] switching from receive response to receive response CRC
2023-12-25 10:10:12.834 [bus debug] notify request: ERR: CRC error
2023-12-25 10:10:12.834 [bus info] scan 19 cmd: 3119070400
2023-12-25 10:10:12.834 [bus debug] ERR: CRC error during receive response CRC, switching to send response ACK
2023-12-25 10:10:12.926 [bus debug] ERR: read timeout during send response ACK, switching to skip
2023-12-25 10:10:12.926 [bus debug] start request 31
2023-12-25 10:10:12.926 [bus debug] arbitration start with 31
2023-12-25 10:10:13.370 [bus debug] arbitration won
2023-12-25 10:10:13.370 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:13.370 [bus debug] switching from ready to send command
2023-12-25 10:10:13.400 [bus debug] send/receive symbol latency 29 ms
2023-12-25 10:10:13.425 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:13.450 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:13.479 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:13.479 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:13.504 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:13.504 [bus debug] switching from send command CRC to receive command ACK
2023-12-25 10:10:13.570 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:13.570 [bus info] scan 1a cmd: 311a070400
2023-12-25 10:10:13.570 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2023-12-25 10:10:13.570 [bus debug] start request 31
2023-12-25 10:10:13.570 [bus debug] arbitration start with 31
2023-12-25 10:10:14.036 [bus debug] arbitration won
2023-12-25 10:10:14.036 [bus debug] arbitration delay 1 micros
2023-12-25 10:10:14.036 [bus debug] switching from ready to send command
2023-12-25 10:10:14.064 [bus debug] send/receive symbol latency 27 ms
2023-12-25 10:10:14.089 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:14.114 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:14.143 [bus debug] send/receive symbol latency 29 ms
2023-12-25 10:10:14.143 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:14.194 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:14.194 [bus info] scan 1b cmd: 311b070400
2023-12-25 10:10:14.194 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:14.194 [bus debug] start request 31
2023-12-25 10:10:14.194 [bus debug] arbitration start with 31
2023-12-25 10:10:14.647 [bus debug] arbitration lost
2023-12-25 10:10:14.648 [bus debug] ERR: arbitration lost during ready, retry
2023-12-25 10:10:14.730 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:14.736 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:14.736 [bus debug] start request 31
2023-12-25 10:10:14.736 [bus debug] arbitration start with 31
2023-12-25 10:10:14.854 [bus debug] ERR: CRC error during receive command CRC, switching to receive command ACK
2023-12-25 10:10:14.859 [bus debug] ERR: ACK error during receive command ACK, switching to skip
2023-12-25 10:10:14.890 [bus debug] arbitration won
2023-12-25 10:10:14.890 [bus debug] arbitration delay 3 micros
2023-12-25 10:10:14.890 [bus debug] switching from ready to send command
2023-12-25 10:10:14.916 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:14.941 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:14.967 [bus debug] send/receive symbol latency 25 ms
2023-12-25 10:10:14.992 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:14.992 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:15.042 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:15.042 [bus info] scan 1c cmd: 311c070400
2023-12-25 10:10:15.042 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:15.042 [bus debug] start request 31
2023-12-25 10:10:15.042 [bus debug] arbitration start with 31
2023-12-25 10:10:15.518 [bus debug] arbitration won
2023-12-25 10:10:15.518 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:15.518 [bus debug] switching from ready to send command
2023-12-25 10:10:15.543 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:15.572 [bus debug] send/receive symbol latency 29 ms
2023-12-25 10:10:15.602 [bus debug] send/receive symbol latency 30 ms
2023-12-25 10:10:15.628 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:15.629 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:15.679 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:15.679 [bus info] scan 1d cmd: 311d070400
2023-12-25 10:10:15.679 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:15.679 [bus debug] start request 31
2023-12-25 10:10:15.679 [bus debug] arbitration start with 31
2023-12-25 10:10:16.154 [bus debug] arbitration won
2023-12-25 10:10:16.154 [bus debug] arbitration delay 2 micros
2023-12-25 10:10:16.154 [bus debug] switching from ready to send command
2023-12-25 10:10:16.179 [bus debug] send/receive symbol latency 24 ms
2023-12-25 10:10:16.209 [bus debug] send/receive symbol latency 30 ms
2023-12-25 10:10:16.235 [bus debug] send/receive symbol latency 26 ms
2023-12-25 10:10:16.264 [bus debug] send/receive symbol latency 28 ms
2023-12-25 10:10:16.264 [bus debug] switching from send command to send command CRC
2023-12-25 10:10:16.314 [bus debug] notify request: ERR: read timeout
2023-12-25 10:10:16.314 [bus info] scan 1e cmd: 311e070400
2023-12-25 10:10:16.314 [bus debug] ERR: read timeout during send command CRC, switching to skip
2023-12-25 10:10:16.314 [bus debug] start request 31
2023-12-25 10:10:16.314 [bus debug] arbitration start with 31
2023-12-25 10:10:16.770 [bus debug] arbitration lost