[abgeschlossen] eBUS Adapter 3.0 Betatest

mr_petz · 18 Dezember 2020, 19:05:35

Mal ne Frage in die Runde.
Welcher Loglevel läuft bei euch? Was macht sinn zum testen?
Ich habe:

--logareas=main,bus --loglevel=notice

Reinhart · 18 Dezember 2020, 21:11:26

ich habe normalerweise gar keinen, aber wenn es Probleme gibt gehe ich auf "debug" um bessere Übersicht der Fehlerquellen zu bekommen.
Wenns wirklich kritisch ist dann schalte ich RAW Logging ein um zu sehen was die Platine sendet bzw. empfängt und die Zeiten zu analysieren.
Es werden bei Normalbetrieb die Logs sonst zugemüllt.

Reinhart · 18 Dezember 2020, 21:32:38

Betreffend der DHCP Problematik die hier diskutiert wird, finde ich es vollkommen ausreichend so wie es jetzt läuft. Man muss sich die Funktion der Platine vor Augen führen und die primäre Funktion ist nun mal der eBus. Der Pic kümmert sich um die Arbitrierung und das sollte seine Hauptaufgabe bleiben.

Das nun der Pic auch bei der Initialisierung den an und für sich "dummen" W5500 auch eine Ip Adresse verpasst ist ja unumgänglich. Aber während der Laufzeit einen Watchdog laufen zu lassen der sich um die Lebenserhaltung des W5500 kümmert finde ich eigentlich übertrieben, speziell wenn wir dadurch eventuell die Primärfunktion gefährden. Ich persönlich würde mit einer statischen Adresse auskommen, da ist DHCP während der Initialisierungsphase eh schon ein Komfortgewinn. Ich bin kein Pic Programmierer, aber das Interrupthandling des Pic ist ja alles andere als komfortabel. Mich wundert es überhaupt, das John noch zusätzlich die gleichzeitige Unterstützung von 1-wire am Wemos geschafft hat ohne einbußen des Zeitdiagrams am eBus zu haben.

Jetzt noch alle Regeln der RFC zu beachten wäre eigentlich schon purer Luxus. Bei einer Änderung des Netzwerkes oder deren Konfiguration finde ich es nicht übertrieben den Adapter neu zu starten. Der eBus wird ja auch nur bei Start des Dämons gescannt und nicht während der Laufzeit, da kein Mensch auf die Idee kommt während der Dämon läuft die Therme auszutauschen.

Aber auf der anderen Seite ist es gut so, das sich die Tester auch darüber Gedanken machen! Betrachtet daher das oben geschriebene als meine persönliche Meinung zu dem Thema.

HeikoGr · 19 Dezember 2020, 07:04:02

Kann jemand mit funktionierenden USB bitte die Angaben von Reingard (Post #121) und mir (Post # 122) überprüfen?

Ich bin der Überzeugung, dass der native USB Anschluss (RPI -> EBUS Adapter) vollkommen ohne Konfigurationsänderungen funktioniert. Das wäre doch wirklich Anwenderfreundlich.

mr_petz · 19 Dezember 2020, 07:54:19

so, erste Nacht gelaufen im eth-mode.
Folgende Logeinträge:

Code Auswählen


2020-12-18 18:14:15.000 [bus notice] max. symbols per second: 106
2020-12-18 18:28:48.014 [bus notice] max. symbols per second: 111
2020-12-18 18:37:12.022 [bus notice] max. symbols per second: 113
2020-12-18 20:17:24.812 [bus error] device status: eBUS comm error: framing
2020-12-18 22:06:40.316 [bus error] device status: eBUS comm error: framing
2020-12-18 22:21:48.063 [bus error] device status: eBUS comm error: framing
2020-12-18 22:33:55.019 [bus notice] max. symbols per second: 117
2020-12-18 23:01:47.438 [bus error] device status: eBUS comm error: framing
2020-12-18 23:58:06.669 [bus error] device status: eBUS comm error: framing
2020-12-19 00:11:47.535 [bus error] device status: eBUS comm error: framing
2020-12-19 01:02:14.023 [bus notice] max. symbols per second: 133
2020-12-19 06:00:23.068 [bus error] device status: eBUS comm error: framing

zu den eBUS comm error: framing hattest du ja schon erläutert.
Was bedeutet max. symbols per second? Das hatte ich aber auch schon mit der alten Version.
Alle Funktionen gehen wie gewohnt.

Hier noch die conf:

Code Auswählen


EBUSD_OPTS="--scanconfig=full --configpath=/etc/ebusd --accesslevel=install -l /var/log/ebusd.log --logareas=main,bus --latency=20000 -d enh:192.168.0.217:9999 --loglevel=notice --mqttjson --mqtthost=192.168.0.253 --mqttport=1883 --mqtttopic=ebusd/%circuit/%name --address=ff"

ps. reine Info: in einem DHCP Server erscheint der Adapter als aebus3220940.

Edit: Achso, hängt zur Zeit an der VR630/1 mit VR90. Ich teste auch noch die VR630/3.
Eigentlicher Grund zur Benutzung des Adapters war, dass das Display der 630/1 und 630/2 ja das bekannte Streifenproblem haben. Ich habe auch die Pinbelegung/welcher Chip etc am Display ist, aber das war mir dann zu aufwändig was zu Basteln.

gruß Thomas

john30 · 19 Dezember 2020, 08:54:33

Zitat von: mr_petz am 19 Dezember 2020, 07:54:19
Was bedeutet max. symbols per second? Das hatte ich aber auch schon mit der alten Version.

das wird ausgegeben, sobald die bis dahin gezählten Symbole pro Sekunde ein neues Maximum erreichen. Ist eher informativ und könnte im Prinzip auch in den debug level wandern.

Zitat von: mr_petz am 19 Dezember 2020, 07:54:19
ps. reine Info: in einem DHCP Server erscheint der Adapter als aebus3220940.

"aebus3" ist der fixe Präfix und der Rest ist der variable Suffix, der sich auch in der MAC findet und aus Teilen der Seriennr. des PIC geildet wird.

Reinhart · 19 Dezember 2020, 09:20:19

Zitat von: HeikoGr am 19 Dezember 2020, 07:04:02
Kann jemand mit funktionierenden USB bitte die Angaben von Reingard (Post #121) und mir (Post # 122) überprüfen?

Ich bin der Überzeugung, dass der native USB Anschluss (RPI -> EBUS Adapter) vollkommen ohne Konfigurationsänderungen funktioniert. Das wäre doch wirklich Anwenderfreundlich.

... eben nicht wenn der ttyebus installiert ist! All jene die vorher keinen V2.x hatten werden da keine Probleme haben. Nur die serielle Konsole am Raspi muss abgeschaltet sein, daher habe ich ja die ganzen Einstellungen gepostet so wie sie bei mir funktionieren!
Ansonsten sollte es klappen!

mr_petz · 19 Dezember 2020, 10:00:48

@john30
nochmal der Hinweis für die configs der 630.
Bei mir gehen die set Befehle nur so wie auch hier schon erwähnt:
https://forum.fhem.de/index.php/topic,79600.msg1058908.html#msg1058908
ich hatte da lange ausgetestet. könntest ja evtl. in den Online configs anpassen wenn du die Zeit findest.
Es gab damals keine Reaktion auf den Beitrag. Ich weiß auch das nicht alles Namenskonform ist.
Ich weiß auch nicht ob es für die 620 so geht. Eine 620 Habe ich auch zum Testen. die hat aber glaube ne macke...

Edit: passende _template angehangen

gruß Thomas

HeikoGr · 19 Dezember 2020, 10:05:20

Warum sollte das nicht funktionieren?

Ebus-Adapter direkt auf Raspberry aufgesteckt
Hier müsste das von dir geschriebene gelten:
- serielle Konsolenausgabe deaktivieren
- minuart-bt Overlay laden
- ttyebus deinstallieren

Ebus-Adapter nicht auf Raspberry aufgesteckt, sondern per Kabel an den Mini-USB Anschluss angeschlossen
hier müsste alles out of the Box funktionieren.
uart-enable interessiert hier nicht, genauso wie die Bluetooth Konfiguration

Meine Theorie dazu
der UART (PL011) Anschuss betrifft doch NUR die GPIO PINs 14 und 15. Alles was ich hier mache ist den USB-Anschlüssen doch egal...

...

schlagt mich, wenn ich falsch liege ...

hErMeS · 19 Dezember 2020, 10:24:34

USB geht ootb und meldet sich laut dmesg wie im Anhang. Egal ob latest raspbian auf pi1b oder aktuellstes Ubuntu Server 64bit auf x86 Hardware

Raspberry Pi muss ich auf dem ttyAMA0 nochmal prüfen. Der lief mit dem latest raspbian image nicht ootb.

Beides sind frisch installierte OS.

HeikoGr · 19 Dezember 2020, 11:27:39

@hErMeS: Danke

@john30, galileo, chons, Reinhart: gibt es noch etwas was getestet werden muss/soll und noch nicht getestet ist?

@john30: ja, bitte push die Doku vom Adapter 3 auf Github, dann kann ich ein paar pull requests zur Doku beisteuern ist vllt einfacher als hier übers Forum.

Reinhart · 19 Dezember 2020, 17:59:05

Zitat von: HeikoGr am 19 Dezember 2020, 10:05:20
Warum sollte das nicht funktionieren?

Ebus-Adapter direkt auf Raspberry aufgesteckt
Hier müsste das von dir geschriebene gelten:
- serielle Konsolenausgabe deaktivieren
- minuart-bt Overlay laden
- ttyebus deinstallieren

Ebus-Adapter nicht auf Raspberry aufgesteckt, sondern per Kabel an den Mini-USB Anschluss angeschlossen
hier müsste alles out of the Box funktionieren.

Unser CP2102 ist ja ein USB seriell Wandler und steckt normalerweise am USB Port ttyUSB0. Hier sind keine Einträge in irgend einer Datei notwendig.
uart-enable interessiert hier nicht, genauso wie die Bluetooth Konfiguration

Meine Theorie dazu
der UART (PL011) Anschuss betrifft doch NUR die GPIO PINs 14 und 15. Alles was ich hier mache ist den USB-Anschlüssen doch egal...

...

schlagt mich, wenn ich falsch liege ...

ja genau, oberes gilt für den RPI (PL011) und unteres für den USB.
Die interne serielle Schnittstelle wird vom RPI benutzt und sitzt deim Raspi 2 auf ttyAMA0.
Beim Raspi 3+4 ist das dann ttyS0, einfach auf den Link serial0 schauen wohin der verweist. Man muss hier immer aufpassen weil das bei den versch. Raspi Versionen unterschiedlich ist.
Der Eintrag enable_uart=1 dient zur Aktivierung der Schnittstelle, das war ab einer gewissen Kernelversion auf 0 gesetzt daher aktivieren!
Der Eintrag dtoverlay=pi3-miniuart-bt schaltet sicherheitshalber Bluetooth ab damit der keine Schnittstelle mehr belegt.

Wenn bei dir RPI funktioniert, dann geht die interne Schnittstelle ttyAMA0. Wenn die USB nicht funktioniert ist der Weg vom USB Raspi zum Konverter 3 irgendwo unterbrochen oder defekt. Steck doch mal einen USB Stick an und schaue ob der mit lsusb sichtbar, wenn ja dann kann nur mehr der CP2102 hinüber sein sofern das USB Kabel funktioniert.

Könntest du dir erklären warum der CP2102 defekt geworden ist?

LG

mr_petz · 19 Dezember 2020, 21:33:49

Zitat von: Reinhart am 19 Dezember 2020, 17:59:05

Könntest du dir erklären warum der CP2102 defekt geworden ist?

LG

Frage ist zwar nicht an mich gerichtet, aber kann es auch durch einen Schluss oder Überspannung an den Pin´s DI+ und DI- oder defekten USB Kabel liegen? Bei mir geht es ja auch nicht.

Bei einem Kabel von mir passiert am RPI garnichts und beim anderen geht die gelbe LED am RPI aus und die Telnetverbindung bricht ab und ist für ne weile nicht erreichbar...

Sollte man vielleicht eins mit beilegen für den Endnutzer?

gruß Thomas

HeikoGr · 19 Dezember 2020, 22:19:26

Ja, kann ich mittlerweile.
Alle weiteren Tests/Versuche sind weiterhin negativ ausgefallen.

Ich hab mich jetzt noch einmal mit dem Schaltnetzteil (Raspberry Original - Stontronics DSA-13PFC-05) beschäftigt, welches ich zuallererst genommen hatte.
Das Netzteil ist mit 5,1 Volt spezifiziert, mit 5% Toleranz (max. also 5,36 Volt).

Mit meinem Multimeter (günstiges Modell) messe ich 5,26 Volt am USB Anschluss eines Wemos, den ich zum testen genommen habe.
Einschaltstrom kann also nochmals höher sein, kann ich aber nicht zuverlässig messen.

Zum Vergleich, USB und der CP2102 sind bis 5,25 spezifiziert..

john30 · 20 Dezember 2020, 10:07:45

Moin zusammen,
es gibt eine neue PIC Firmware, die die DHCP nach link loss Lücke adressiert und bei fixer IP via DHCPINFORM sich selbst am Router bekannt macht.
Darüber hinaus wurde auch der ebuspicoader erweitert um die Anzeige der checksum der Firmare und des Bootloaders. Somit ist leichter festzustellen, ob die richtige Version drauf ist.
Des weiteren wurden die Bilder auf der Doku Seite verbessert und die Doku wird jetzt auch immer ins git gepusht.
LG und schönen 4. Advent, John