[abgeschlossen] eBUS Adapter 3.0 Betatest

[JimKnopf]

Hi John!

Natürlich, machen wir. (Edit: ich habe die Posts zu meinem alten Adapter hier gelöscht). Sollte ich den Adapter noch für Vergleiche behalten?
Gruß,
Burkhard

[john30]

Natürlich, machen wir. Sollte ich den Adapter noch für Vergleiche behalten?

wenn jetzt soweit alles klappt, brauchst den m.E. nicht mehr aufheben.

[HeikoGr]

Setz Mal in die ebusd_opts noch

Code Auswählen Erweitern


--latency=20000

Das war bei mir der ausschlaggebende Parameter. Sieht bei dir nach Vaillant aus.

Bingo (und ja, mit Vaillant liegst du richtig)

Die Raspi Variante geht damit bei mir auch.
Wäre m.E noch zu klären warum der RPI Variante eine höhere Latenz braucht, als die Wemos Variante? Diese funktioniert auch ohne höhere Latenz.

Edit/Ergänzung:
Ich habe in John's Wiki gerade gelesen, dass die Latenz-Default Werte bei IP (10000) anders sind, als bei USB (0)

[john30]

Bingo (und ja, mit Vaillant liegst du richtig)

Die Raspi Variante geht damit bei mir auch.
Wäre m.E noch zu klären warum der RPI Variante eine höhere Latency braucht, als die Wemos Variante? Diese funktioniert auch ohne höhere Latency-Toleranz.

eine sehr berechtigte Frage und ich wundere mich auch schon. Da werd ich wohl am WE mal vermehrt mit dem Pi testen dürfen
könntest du bitte OS und Kernel Version posten und die ebusd Optionen? Dann stelle ich das mal nach.

[HeikoGr]

Raspi OS mit Kernel 5.4.79-v7+ (tagesaktuell)

Code Auswählen Erweitern


EBUSD_OPTS="-d enh:/dev/ttyAMA0 --scanconfig --latency=10000"


Ich hab die Latenz mal an die default Werte des ebusd für IP Verbindungen angepasst - geht auch.

[JimKnopf]

Hi!

Ich habe momentan recht oft "signal lost". Bin versucht parallel doch nochmal den 2.2 Adapter dran zu hängen.
Gruß,
Burkhard

[HeikoGr]

Gute Neuigkeiten!

Das flashen des PIC über den aufgestecken Raspi per

Code Auswählen Erweitern

ebuspicloader -f 20201210-offset.hex /dev/ttyAMA0

hat auf Anhieb funktioniert. Man muss nur dran denken vorher den ebus-daemon zu stoppen!

Code Auswählen Erweitern

sudo service ebusd stop

und ein Neustart des Raspi reicht nicht aus um den PIC aus dem Bootmodus zu entlassen. Der Raspi musste (zumindest bei mir) Stromlos geschalten werden.

Jetzt fehlt mir nur noch die LAN-Variante zu meinem Glück

LAN-Verbindung hat auch geklappt. Ich habe den Wemos als Volt-Spender genommen, den J4 Jumper nicht gesteckt und den Strom über die entsprechden 3,3V und GND Pins des J5 Steckfelds eingeführt.

[Reinhart]

ADC am Wemos benutzen ( A0 an J6 ) !

Ich habe heute noch den optionalen ADC Anschluß an J6 der Platine getestet.

Zu beachten ist hier eigentlich nur, dass die maximale Spannung des ESP8266 am ADC 1V nicht übersteigen darf. Das gilt aber nicht für den Wemos D1 mini, da dieser schon einen Spannungsteiler integriert hat und eine maximale Spannung an A0 von 3.2V erlaubt. Zur Sicherheit bin ich aber trotzdem auf den 1V geblieben und habe einen Spannungsteiler mit einem Verhältnis von 1:3 gewählt. Wer den vollen Spannungsbereich nutzen will ändert entsprechend den Widerstand.


Eingesetzt habe ich einen NTC mit 10 K und als Spannungsteiler Widerstand 22K gewählt, also etwa 1:3. Der NTC hängt an 3,3V, ( J6 Pin4 ) der Mittelpunkt an A0 ( J6 Pin 6 ) und die 22K an Gnd1 ( J6 Pin 3 ).

Beispiel zur Visualisierung der Temperatur

Code Auswählen Erweitern

define Sensor_json HTTPMOD http://10.0.0.102/pin 600
attr Sensor_json extractAllJSON 1
attr Sensor_json room eBus
attr Sensor_json stateFormat temperature °C
attr Sensor_json userReadings temperature {sprintf("%.1f", ReadingsNum($name,"pins_09_value",0)/27.87)}

Die IP Adresse muss natürlich durch eure des Wemos ersetzt werden.

Die Kalibrierung erfolgt rein an der Ausgabe in Fhem, der Raw Wert wird 1:1 über das jSON Format mitgeteilt. Am Wemos muss in diesem Fall nichts eingestellt werden, da der ADC Anschluß immer aktiv ist!

Code Auswählen Erweitern

{"pins": [{"pin":1,"gpio":5,"direction":"input","state":"H","value":1},{"pin":2,"gpio":4,"direction":"input","state":"L","value":0},{"pin":3,"gpio":0,"direction":"input","state":"H","value":1},{"pin":4,"gpio":2,"direction":"output","state":"H","value":1},{"pin":5,"gpio":14,"direction":"input","state":"L","value":0},{"pin":6,"gpio":12,"direction":"sensor","state":"?","value":-1},{"pin":7,"gpio":13,"direction":"input","state":"H","value":1},{"pin":8,"gpio":15,"direction":"input","state":"L","value":0},{"pin":-1,"adc":true,"direction":"input","state":"H","value":735,"volt":2.296875}]}
JSON String, der letzte Wert ist der ADC

Die Übertragung des eBus wird durch den zusätzlichen Sensor nicht beeinflusst. Bei Temperaturübertragungen sollte jedoch soweit wie möglich der wesentlich genauere DS18b20 oder ähnliches verwendet werden, es zeigt nur eine weitere optionale Möglichkeit der Platine V3. Gemessen kann eigentlich alles werden was den Widerstandswert ändert.


Auf keinen Fall 230 V messen, nur ( Gleichstrom ) Niederspannungen!

LG

[mr_petz]

Hi@all.
So, heute alles fertig gelötet mit verbleiten Zinn.
Dabei ist mir am USR-ES1 Modul die vom Hersteller schief eingelötete Steckleiste aufgefallen. Habe ich begradigt (siehe Bild vorher/danach). Das sollte man vielleicht vor Versand checken. Nicht das der Endnutzer das mit Gewalt reinsteckt und etwas beschädigt.
Als erstes wollte ich den USB Modus (noch ohne angeschlossenen eBus) im Standardmode testen.
Per USB Kabel an RPI gesteckt und mit "lsusb" wurde kein neues Gerät angezeigt.
Gelbe und Grüne LED sind an. Blaue ist gedimmt wie die Gelbe und Grüne (siehe Bild oben/unten).
Danach habe ich auf enhanced umgeswitcht, aber gleiches Ergebnis. Bis auf das die Blaue LED in 3 Stufen heller wurde.
Ich hoffe das es nicht ein allgemeines Problem mit dem CP2102 wie bei HeikoGr???
Oder mache ich noch was Falsch? Pins am J1 und J4 habe ich auch auf Durchgang geprüft.
Habe auch mehrere USB Kabel probiert. Die gehen alle mit Handy am PC...

Edit: mit meinem deaktivierten serial-getty@ttyAMA0.service hat es aber nichts zu tun oder?

Das fiepen im Betrieb, wie bei hErMeS, nehme ich auch war.

Jetzt hatte ich noch schnell den Ethernet Modus getestet.
Blaue LED blinkt zu erst schnell, dann langsam und wenn die DHCP Adresse übermittelt wurde dauerhaft.
Einen Ping habe ich auch mit Erfolg durchgeführt.
Weitere Test folgen...

mfg Thomas

[hErMeS]

Frage an die wo der USB Teil kein Gerät anzeigt,

Habt ihr Mal die Leiterbahnen/Pins geprüft ob die von Anfang bis Ende alle durchgängig sind? So viele Punkte sind dies ja nicht. Für sowas nehme ich gerne eine Krokodilklemme und Taste dann mit einer Nadel ab da die Pins hier am USB Connector und CP.... doch schon sehr klein sind.
Ordentliches Detailfoto? Es könnte ja im ersten Step nur am VCC, D+ D- oder GND liegen. Wenn die LEDs angehen tut der TS1117 seine Arbeit. In dieser Richtung scheint dann nichts falsch zu seien.
Aber noch etwas. Habt ihr mal mit dmesg geprüft ob sich überhaupt irgendetwas versucht hat zu melden?




LAN läuft jetzt schon über einen Tag, USB ist für mich auch abgehakt. Fehlt nur noch WiFi (hier wäre WPA2-Enterprise cool) und die bei mir noch nicht geklappte Raspberry Pi 1 Model B Möglichkeiten

Zusammenfassend bisher:
USB erfüllt sein Ziel
LAN ebenfalls (bis auf das mit dem DHCP Renew bei verloren gegangener LAN Verbindung)
Platine: C1 und C4 erzeugen hochfrequente Geräusche (sind das LOW ESR Kerkos?)
Heute Abend kommt das WLAN dran. Anschließend das noch nicht gehende RPi bei mir

[HeikoGr]

Hier mein aktueller Stand

Variante	Status	offen
USB	defekt?	Leiterbahnen check, USB geht in Schutzschaltung?
Raspberry	funktioniert, fiept	hier will ich dem fiepen nachgehen. klingt vergleichbar zu den Angaben von hErMeS
LAN	funktionert	PoE Adapter
Wifi	funktionert

Mein Plan ist es alle Varianten noch einmal von Beginn an zu testen.
Da ich ohne funktionierenden USB Anschluss zunächst den Fokus darauf gelegt habe die anderen Varianten überhaupt zum laufen zu bekommen.

Wegen der Dokumentation auf der Seite https://adapter.ebusd.eu/ Wann kommt ihr dazu die Erkenntnisse von uns einzupflegen?
Kann ich hierbei helfen?

zu Dokumentation auch noch eine Frage: Was genau bewirkt eigentlich der Reset bei den Anschlüssen J12?

@hErMeS:
Danke für den Tipp mit der Krokodilklemme und Nadel!
Ich mache mir da zwar wenig Hoffnung (2 Powerbank verweigern ihren Dienst mit der Platine und schalten sofort aus...) Aber ich versuche das Problem weiter einzuschränken.

@mr_petz:
Die Pins bei meinem LAN Aufsteckmodul waren auch verbogen, nur nicht so schlimm wie bei dir.

[john30]

Aber noch etwas. Habt ihr mal mit dmesg geprüft ob sich überhaupt irgendetwas versucht hat zu melden?

sehr guter Punkt! Vielleicht ist "nur" der CP2102 nicht gewillt mit dem Host zu sprechen

LAN ebenfalls (bis auf das mit dem DHCP Renew bei verloren gegangener LAN Verbindung)

das ist eigentlich implementiert. könntest Du da mal via tcpdump o.ä. schauen, ob und welche DHCP messages nach reconnect vom/an adapter gehen?

[john30]

Wegen der Dokumentation auf der Seite https://adapter.ebusd.eu/ Wann kommt ihr dazu die Erkenntnisse von uns einzupflegen?

ich habe versucht, das immer gleich nachzuziehen. Was fehlt deiner Meinung nach?
Vielleicht wärs gut, wenn jeder Tester für sich eine Liste von offenen Punkten macht, damit wir nichts vergessen. Ich hab schon wieder große Mühe, hier noch mit zu kommen 

Kann ich hierbei helfen?

klar, ich muss nur mal den push an github machen, dann landet der aktuelle Stand hier.

zu Dokumentation auch noch eine Frage: Was genau bewirkt eigentlich der Reset bei den Anschlüssen J12?

das macht einen Reset im PIC, der diesen auch an Wemos bzw. W5500 weiterleitet. Man könnte z.B. einen Taster anschließen, um einen Reset auszulösen. Sollte aber unter normalen Umständen nicht notwendig sein.

An die mit Problemen beim USB Interface: könntet ihr mal die Leiterbahnen an den CP2102 genau anschauen? Oder ein Foto davon posten also inkl. USB Klemme und CP2102?

[hErMeS]

das ist eigentlich implementiert. könntest Du da mal via tcpdump o.ä. schauen, ob und welche DHCP messages nach reconnect vom/an adapter gehen?

Hatte angestöpselt, MAC in der opnsense anhand DHCP Log ermittelt, Port offline genommen, Mac vlan definiert und Port wieder online genommen. Hier sollte ja der neue DHCP request erfolgen. Reproduzierbar erfolgte das nicht mit offline schalten des Ports. Daraufhin hatte ich den wireshark mit Port Mirroring bemüht was zum gleichen Ergebnis kam. Toten Stille vom eBus Adapter. Nur ein reboot vom Adapter half.

[john30]

Hatte angestöpselt, MAC in der opnsense anhand DHCP Log ermittelt, Port offline genommen, Mac vlan definiert und Port wieder online genommen. Hier sollte ja der neue DHCP request erfolgen. Reproduzierbar erfolgte das nicht mit offline schalten des Ports. Daraufhin hatte ich den wireshark mit Port Mirroring bemüht was zum gleichen Ergebnis kam. Toten Stille vom eBus Adapter. Nur ein reboot vom Adapter half.

ah ok, ich sehe das Problem. Im Moment ist es ja so, dass ebusd mit einer fixen IP Adresse arbeitet. Insofern ist das Szenario "aus Netz A abstecken und im Netz B anstecken" eh nicht relevant, weil dazu ebusd entsprechend neu konfiguriert werden müsste. Ich hatte jetzt eher eine kurze Unterbrechung aber am gleichen Netz im Sinn.
Das könnte man schon im PIC implementieren, aber aus meiner Perspektive bringts nichts.
Oder sehe ich das falsch?