Nur Text | Text mit Bildern

FHEM Forum

Verschiedenes => Bastelecke => Thema gestartet von: Reinhart am 03 Dezember 2020, 17:45:40

Titel: [abgeschlossen] eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 03 Dezember 2020, 17:45:40
Hallo!

Der Betastest ist gestartet und die 7 Tester werden nun in kürze per PN verständigt. Bitte nicht ungehalten sein wenn nicht alle testen können, wir haben nur eine begrenzte Anzahl an Testplatinen ( 10 ) bekommen. John, galileo und Reinhart haben je 1 Stück und die restlichen 7 werden versandt! Wir danken aber allen der regen Nachfrage und sehen uns in unserem Projekt bestätigt.

Wie galileo schon gepostet hat gab es bei den Testplatinen Bestückungsfehler, zu einem ist ein Widerstand falsch (statt 56K wurden 56 Ohm bestückt) und 3 Leds sind verkehrt montiert was allerdings keinen Einfluss auf die Funktion hat. Ich habe auf meiner Platine diese Leds gedreht, das ist aber für ungeübte SMD Löter ( so wie ich ) eine ordentliche Herausforderung bzw. ein gefummel das ruhige Hände und gute Augen voraussetzt!

Wir haben lange diskutiert, sind aber zum Entschluß gekommen den Testern trotzdem die Platinen zu schicken, da es sich sonst vor Weihnachten nicht mehr ausgeht und so wertvolle Zeit verloren geht. Wir testen jetzt auch zu dritt die Funktionen und werden nach und nach darüber hier berichten.

Wie im Bild zu sehen wird so ein (ähnliches) Set kostenlos an die Tester versendet. Leider ist nix wirklich kostenlos und wir erwarten von euch dafür Feedback wie es euch bei der Inbetriebnahme ergangen ist, was eventuell unklar ist, wie die Doku zu lesen ist und stimmt etc. Zusätzlich werden wir euch hier in diesem Thread unterstützen. Bitte um Einsicht wenn John und galileo nicht immer Zeit haben, John arbeitet immer noch an Features und verbessert ständig die Software.

Die Adapter sind fertig geflasht inkl. Bootloader, denn dazu wäre eine eigener Programmer wie PCKit3 oder ähnliches erforderlich. So werden wir auch später ausliefern. Auch der Wemos ist bereits geflasht und sosfort einsatzfähig!


Technische Infos:

Im Bild 1 ist das Test Set zu sehen. Wir liefern euch das so aus, etwas Löterfahrung ist notwendig und an Stift und Buchsenleiste könnt ihr selbst entscheiden was ihr benötigt. Nicht alle werden alle Adapter einsetzen! Der einfachste Fall, Printklemme und die oberen 3-fach Stiftleisten für die Jumper einlöten und USB kann sofort getestet werden.

Im Bild 2 Adapter3_1.png ist in Gelb das Signal direkt am eBUS und in Blau der Trigger, das ist das Schreib-Signal des 3.0 Adapters, nur verwendet um den Trigger-Zeitpunkt festzulegen (Pegel sind falsch wegen des Spannungsabfalls am Brückengleichrichters).
Die immer problematische Rise-Time des Signals liegt hier bei 17 us für die gesamte Höhe. Die eBUS Spec gibt max. 50us für den halben(!) Range vor. Wir denken, das wir hier ganz gut im geforderten Bereich liegen.

Im Bild 3 Adapter3_2.png sieht man den Input-Trigger-Level (Spannungsteiler für Signaldetekor). In Blau den Ausgang des Komparators (Pin5 vom PIC bzw. die grüne LED). In Gelb die Spannung direkt am Bus.
Das System triggert also bei 13,4V (am Bus) und auch das ist ein optimaler Mittelwert zur Signalerkennung.

Im 4. Bild sind die 3 verkehrt bestückten Leds markiert und der falsche hier abgerauchte Widerstand mit 56 Ohm. Die Testplatnen sind daher von uns schon mit dem richtigen Widerstand versehen. Da die Leds keinen weiteren Einfluß zur Funktion haben, müssen diese auch nicht gedreht werden. Wer geschickt im SMD Löten ist, kann dies aber sehr gerne versuchen. Ich bin kein geübter SMD Löter, habe es aber auch geschafft. Bitte keine Kraft beim Auslöten, ich habs mit 2 kleinen Lötkolben gemacht und die Led einfach wegeschubst.

Bei den Test hat sich gezeigt, wer oft den Bus an- und abklemmen muss, der läuft Gefahr das irgendwann die Wago Klemme bricht. Bei den Sets sind daher auch normale Printklemmen dabei. Mit der Bauhöhe sollte es allgemein ja kein Problem geben, außer vielleicht bei der Rpi Variante in einem Gehäuse.


Hinweis vom Hersteller der Platinen:

-   Der jetzige Print für den Betatest ist chemisch verzinnt ( bleifrei ).
-   Es ist jederzeit möglich, die Stecker entweder bleifrei oder besser verbleit einzulöten. Verbleit besser wegen der niedrigeren Temperatur
-   Aber:  Diese chemisch verzinnten Leiterplatten sind prinzipiell nur ca. 6 Monate gut lötbar. Danach kann durch diverse chemische Prozesse keine vernünftige Lötung mehr durchgeführt werden
-   Nimmt man stattdessen eine Vergoldung der Lötstellen, dann kann man den Lötprozess sehr viel weiter hinauszögern.

Wir werden daher bei der endgültigen Bestellung die Platinen vergolden lassen. Für die Betatester ist es daher ratsam alle Stift und Buchsenleisten jetzt schon zu bestücken, egal ob ihr sie braucht oder nicht!

LG
das eBus Team (john30, galileo, chons, Reinhart)

Link zum Wiki Adapter V3 (https://adapter.ebusd.eu/)
ebuspicloader (https://github.com/john30/ebusd/tree/enhanced_device/src/tools)
Pic Firmware (https://adapter.ebusd.eu/picfirmware)
RPI am Raspi4 einrichten (ttyAMA0) (https://forum.fhem.de/index.php/topic,116418.msg1120819.html#msg1120819)
ebusd_enhanced installieren (https://forum.fhem.de/index.php/topic,116418.msg1109955.html#msg1109955)
1-wire Sensor DS18b20 (https://forum.fhem.de/index.php/topic,116418.msg1110105.html#msg1110105)
Temperaturerfassung am ADC des Wemos (https://forum.fhem.de/index.php/topic,116418.msg1111643.html#msg1111643)
Fehlermeldungen und deren Bedeutung (https://forum.fhem.de/index.php/topic,116418.msg1110775.html#msg1110775)

3D-Modell 3.0 Basis (https://a360.co/3nr9HqS)
3D-Modell USB (https://a360.co/3r5xTRA)
3D-Modell RPI (https://a360.co/38dPTR8)
3D-Modell Ethernet (https://a360.co/3gSLwz2)
3D-Modell WIFI (https://a360.co/2LDUdlb)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 03 Dezember 2020, 17:45:54
USB und RPI

Bitte immer das Wiki zum Adapter 3  (https://adapter.ebusd.eu/)benutzen, hier findet ihr die gesamte Konfiguration und die Anleitung. Das hier geschriebene ist nur eine Kurzfassung.

Die USB Variante (https://adapter.ebusd.eu/?t=1#usb) ist die einfachste Art. Es genügt hier die beiden 3-fach Steckerleisten und die Printklemme einzulöten. Den USB Stecker mit dem Raspberry verbinden und den eBus anschließen. Zusätzlich besteht noch die Möglichkeit den "normal" Mode zu aktivieren, der legt dann die Arbitrierung wieder wie früher auf den Dämon zurück, also wieder zeitkritisch. Ohne Jumper ist Default also "enhanced" Protokoll.
Bitte vorher checken ( lsusb ) ob der UART CP2102 am Raspberry sichtbar ist. Das ist der serielle UART der an der Platine verbaut ist.

Code Auswählen
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210                                    x family]
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



Um festzustellen um welchem USB Anschluss es sich handelt, bitte "dmesg" verwenden!
Code Auswählen
dmesg | grep usb

[  217.816444] usb 1-1.4: cp210x converter now attached to ttyUSB0
[  997.030521] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[  997.030629] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[  997.060314] usb 1-1.4: USB disconnect, device number 5
[ 5571.569220] usb 1-1.4: new full-speed USB device number 6 using dwc_otg
[ 5571.705945] usb 1-1.4: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
[ 5571.705970] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5571.705988] usb 1-1.4: Product: CP2102N USB to UART Bridge Controller
[ 5571.706004] usb 1-1.4: Manufacturer: Silicon Labs
[ 5571.706021] usb 1-1.4: SerialNumber: c223af9325deea118442cf149a583cc7
[ 5571.720677] usb 1-1.4: cp210x converter now attached to ttyUSB0



Config Datei ( /etc/default/ebusd )
Je nach Betriebsart muss diese dem Dämon mitgeteilt werden, das geschieht mit der config.

Beispiel einer möglichen Config :
Code Auswählen
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:10.0.0.20:9999 --loglevel=debug --mqttport=1883 --mqttjson --mqtthost=10.0.0.5 --mqtttopic=ebusd/%circuit/%name --address=ff"
Variante Wemos oder Ethernet (https://adapter.ebusd.eu/#wifi) mit MQTT, Ausgabe als JSON und geänderter Adresse auf "ff"
10.0.0.20:9999 = IP/Port von Wemos oder Ethernet
10.0.0.5 = IP  vom MQTT Server/Client/Broker
mqtttopic = Topic des Wemos wie die Messwerte in Fhem eingetragen werden sollen ( ebusd/%circuit/%name = MQTT2_ebusd_bai ) MQTT2_ebusd_bai_ReadingName
loglevel = der Loglevel sollte normalerweise nach einer Inbetriebnahme wieder herabgesetzt werden und dient nur bei Fehlfunktionen zur besseren Fehlersuche

ohne Raw Logging

Code Auswählen
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyUSB0 --loglevel=debug --lograwdata=bytes --address=ff"
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyAMA0 --loglevel=debug --lograwdata=bytes --address=ff"
erste Zeile als USB Variante (https://adapter.ebusd.eu/#usb)
zweite Zeile als RPI Variante (https://adapter.ebusd.eu/#rpi)
beide als Raw Logging ( --lograwdata=bytes )

Die config unter /etc/default ebusd anpassen und den Dämon starten.
Code Auswählen
sudo service ebusd start


Step by Step USB

  1.1 Jumper setzen, J1-USB, J4-USB, J12 alles offen = enhanced Protokkoll
  1.2 config setzen, EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyUSB0 --loglevel=debug --address=ff"
  1.3 eBus an Platine anklemmen
  1.4 Raspberry über USB Kabel mit dem Adapter verbinden
  1.5 grüne Led muss blinken
  1.6 Dämon starten "sudo service ebusd start"

RPI
wer die Variante RPI (https://adapter.ebusd.eu/?t=1#rpi) benutzt, kann auf das USB Kabel verzichten und steckt die Platine direkt auf den Raspberry. Bitte wieder die Jumper J2 + J4 richtig stecken. Es ist KEIN zusätzlicher Treiber erforderlich, die Schnittstelle ttyAMA0 muss aktiviert sein. Wer noch den für 2.x erforderlichen Treiben ttyebus aktiv hat, sollte diesen deinstallieren, da dieser nicht mit allen Kombinationen (z.B. RASPI 4 und Raspbian ab 02/2020) funktioniert und stattdessen wieder ttyAMA0 verwenden.

ACHTUNG: den RPI Connector unbedingt auf der Unterseite einlöten, siehe die letzten beiden Bilder!


Step by Step RPI

  2.1 Jumper setzen, J1-RPI, J4-RPI, J12 alles offen = enhanced Protokkoll
  2.2 config setzen, EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyAMA0 --loglevel=debug --address=ff"
  2.3 eBus an Platine anklemmen
  2.4 Platine am Raspberry aufstecken
  2.5 grüne Led muss blinken
  2.6 Dämon starten "sudo service ebusd start"

Bild1 USB-jp zeigt die Platine und die beiden 3-fach Stiftleisten mit den Jumpern.
Bild2 USB-anschluss die Platine ist mit dem USB Kabel mit dem Raspberry verbunden
Bild3 USB-anschluss-blLed die Platine in Betrieb und die blaue Led.
Bild4 RPI zeigt dann die Belegung für RPI Betrieb, also ohne USB Kabel, dafür steckt der Adapter dann auf dem Raspberry.
Bild5 RPI-unten1 zeigt die richtige Montage des RPI-Connectors auf der UNTERSEITE der Platine
Bild6 RPI-unten1 zeigt die richtige Montage des RPI-Connectors auf der UNTERSEITE der Platine

Schaltplan (https://adapter.ebusd.eu/?t=1#schaltplan) im Wiki


LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 03 Dezember 2020, 17:46:04
Wlan

Wiki Wemos einrichten (https://adapter.ebusd.eu/wemosebus.html)

Die Inbetriebnahme des Wemos (https://adapter.ebusd.eu/#wifi) an der Platine verläuft eigentlich völlig unspektakulär. Die Stabilität ist stark von der Feldstärke abhängig. Bei meiner Umgebung ist ein Rssi Wert bis etwa -74 dBm ok, aber bei schlechterem Wert wird das ganze natürlich instabil und es kann zu Verbindungsunterbrechungen kommen.
Hier empfiehlt sich entweder die Verwendung von Wemos mit Antenne oder ein funktechnisch besserer Aufstellungsort.
Die wesentliche Verbesserung ist, dass es zu keinen Latenzen mehr kommt und das nun gleichzeitig verschiedenste Sensoren mit laufendem eBus Protokoll angeschlossen werden können.
Der Umweg über einen 2. Wemos fällt somit komplett weg!
Im Bild Wemos2 sieht man das ich hier die Stiftleiste um etwa 2 mm gekürzt habe, damit es zu keinen Kurzschlüssen zum Wemos kommen kann. Daher ist auch der rechte Jumper etwas herausgedreht, das ist nur zur besseren Ansicht!

Bei meiner Testversion habe ich den Pin der Antenne aufgekratzt und ein Stück Draht mit 63mm (Lambda 1/2) angelötet, das bringt schon eine bessere Empfindlichkeit. Noch besser ist ein Wemos mit abgesetzter Antenne (https://forum.fhem.de/index.php/topic,116418.msg1111145.html#msg1111145).


Step by Step WIFI

  3.1 Jumper setzen, J1-RPI, J4-offen oder RPI, J12 4-5 =Wifi Check
  3.2 config setzen, EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_wemos:9999 --loglevel=debug --address=ff"
  3.3 eBus an Platine anklemmen
  3.4 Wemos aufstecken, ebusd-esp muss geflasht sein und dann im Webif auf "Adapter 3 RX+TX" eingestellt werden
  3.5 grüne Led muss blinken, blau + orange leuchten
  3.6 Dämon starten "sudo service ebusd start"

Ethernet

Endlich kann nun auch am eBus Adapter Lan verwendet werden. Da zu wird in den vorgesehenen Buchsenleisten einfach ein W5500 Ethernet Adapter (https://adapter.ebusd.eu/picfirmware#ethernet-konfiguration) aufgesteckt und die Platine richtig gejumpert (https://adapter.ebusd.eu/#weitere-anschl%C3%BCsse). Mit dem ebusdpicloader (https://github.com/john30/ebusd/blob/enhanced_device/src/tools/ebuspicloader.cpp) kann auch eine statische IP-Adresse vergeben werden, ansonsten ist per Default alles auf DHCP eingestellt. Am W5500 braucht nichts eingestellt und auch keine Software aufgespielt werden. Die Firmware zu Ansteuerung des W5500 ist alles schon im Pic untergebracht. Die Mac Adresse ist vom Pic abhängig, d.h. werden verschiedene W5500 aufgesteckt erhalten die immer die selbe Mac Adresse! Der W5500 hat keinen eigenen Speicher und bekommt bei jedem Bootvorgang des Pic von diesem die Adresse wenn sie statisch gespeichert wurde, bzw. fordert der Pic die Adresse per DHCP an.
Am Status der blauen Led kann der Zustand erkannt werden.


- blau blinken 4 x pro Sekunde, W5500 ist initialisiert und wartet auf DHCP Adresse
- blau leuchtet permanent, W5500 hat IP Adresse bekommen, kann je nach Router ( DHCP Server ) einige Sekunden dauern

Step by Step Ethernet

  4.1 Jumper setzen, J1-RPI, J4-USB, J12 5-6=eth Modus
  4.2 config setzen, EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:ip_vom_W5500:9999 --loglevel=debug --address=ff"
  4.3 eBus an Platine anklemmen
  4.4 W5500 aufstecken, W5500 muss entweder über DHCP ( gar nix tun ) oder fixe IP gesetzt werden ( ebuspicloader (https://adapter.ebusd.eu/picfirmware#ethernetconfig) )
  4.5 grüne Led muss blinken, blau + orange leuchten
  4.6 Dämon starten "sudo service ebusd start"

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 06 Dezember 2020, 10:27:04
Vorgangsweise für den Betatest!

Es sind schon die ersten Fragen aufgetaucht wie den nun genau vorgegangen werden soll. Wir wollen hier niemand etwas vorschreiben was er tun soll, jeder testet was er vom Adapter erwartet und ihn in Zukunft einsetzen will. Die einen haben mehr Zeit, die anderen können erst später Ergebnisse und Feedback liefern, bitte keinen Stress aufkommen lassen!

so im Allgemeinen würden wir gerne haben:
- Feedback zu dem Anmeldeprozess ( online Anmeldeformular ) , die meisten Tester haben uns dazu schon einige verbesserungswürdigen Punkte gemeldet, die John schon teilweise umgesetzt hat.
- die Platine nach Wunsch bestücken, Stift- und Sockelleisten einlöten und die von euch gewünschten Funktionen Schritt für Schritt testen. Dabei die Logs beachten ob hier Fehler auftauchen und gegebenenfalls uns rückmelden.
- bei Problemen oder Unklarheiten als erstes das Wiki heranziehen (https://adapter.ebusd.eu/?t=1) und uns bekannt geben ob es eine Hilfe war oder doch eher einiges verwirrend. Welche Inhalte könnte man verbessern?
- wir stehen euch jederzeit bei der Inbetriebnahme hier zur Verfügung. Bitte nicht per PN, da ja das Feedback auch für andere wertvoll sein kann.
- in späterer Folge könnt ihr auch gerne die optionalen Fähigkeiten testen, zB: Wemos mit Sensoren bestücken.


Die Testadapter die ich versendet habe wurden alle in vollem Umfang ausgeliefert, mit Wemos und W5500! Wer hier keinen Bedarf hat oder sich nicht darüber wagt muss das natürlich nicht testen, obwohl gerade dann es für uns wichtig wäre.


Die Bestückung der Stift- und Buchsenleisten sollte von euch durchgeführt werden, da nicht jeder alles braucht und speziell ich Probleme mit den Versandkosten habe da diese dann bei 9,90.-  statt 5,50.- liegen würden wenn es als Paket versendet wird. Bis 3cm kann ich mit 5,50- im Luftpolsterkuvert versenden, bei eingelöteten Stiftleisten wird es sehr hoch und die stechen ohne zusätzlichen Schutz durch das Luftpolsterkuvert, mit Schutz wird es dann zu hoch. Mit Beigabe des W5500 bin ich schon hart an der Grenze, dieser hat mit Pinschutz 2,5cm.


Zur Programmierung des PIC brauch ich die Stiftleisten nicht unbedingt!



LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 06 Dezember 2020, 10:48:15
Arbitrierung

Galileo hat die Arbitrierung mit einem Logiganalyser näher untersucht und uns folgende Ergebnisse geschickt!

Im Bild Arbitration_Ebus3 bedeutet die obere Spur: unser Tx Pfad, also Schreiben auf den Bus. Untere Spur: Komparator-Ausgang, also Lesen vom Bus. Die Werte zwischen Cursor A und B sind im Bild ganz rechts unten zu sehen ( 4205 ) .

Noch zur Erinnerung: Die min und max Werte für die Arbitrierung werden in der Spezifikation vom Start-Bit des SYN Signals weg gezählt. Der Min-Wert wurde hier festgelegt mit einem tzmin = 4300us.
Die Zeit von 4205us für unsere Arbitrierung! Das ist der volle Erfolg und damit ist bewiesen dass Latenz-Probleme nunmehr der Vergangenheit angehören. Das ist aber andererseits auch außerhalb der Spezifikation, diesmal aber in der anderen Richtung. WIR SIND ZU SCHNELL und John wird noch ein Dealy einbauen.

Im 2. Bild Arbitration_Vaillant wurde die Arbitrierung zum Vergleich an einem Vaillant Device gemessen. Vaillant hat gemessene 4326us. Deren Arbitrierung läuft dort vermutlich auch über einen Microcontroller, ansonsten würden sie diese guten Zeiten nicht erreichen können.

LG

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 06 Dezember 2020, 12:36:59
Noch als Nachtrag zu den Messungen am eBUS bezüglich Ausgangssignal: Im Bild Adapter3_1.png ist zwar die Rise-time zu erkennen, aber nicht der Low-Pegel des Signals.
Deshalb hier noch diese Messung (direkt am eBUS). Der Low-Level liegt hier bei 10,4V und das ist in Bezug auf die Spezifikation (9V bis 12V) ein schöner Mittelwert (gelbe Kurve).
Ganz links am Rand kann man noch den Low-Pegel eines Vaillant Gerätes erkennen, das liegt nur ein paar mV unter "unserem" Wert.
Die blaue Kurve dient hier nur dem Trigger und ist sonst irrelevant.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 06 Dezember 2020, 14:33:05
Hi,
Ich habe jetzt mal intensiver das Wiki durchgelesen.
Dazu habe ich eine Frage zur Ethernetkonfiguration.
Im Wiki steht ja, man kann eine feste IP vergeben. Das soll mit dem Tool PIC-Loader (Link wird ja noch erstellt) einzustellen sein.
Jetzt steht aber bei:
https://adapter.ebusd.eu/picfirmware#versions (https://adapter.ebusd.eu/picfirmware#versions)
Code Auswählen
Ethernet Minimale ebusd Version: 3.5 (enhanced protocol)
Es gibt doch zur Zeit nur eine v3.4 oder?
Oder verstehe ich was falsch und brauche nur das enhanced protocol?

Noch ein Hinweis/Frage zum Bootloader Host Application von Microchip.
Dort muss man sich Anmelden/Registrieren für den download.
Wollte mich da jetzt nicht anmelden. Ich habe mir jetzt die UnifiedHost-0.1.8-dist besorgt. Kann man die auch verwenden falls es ein Update des Pic gibt? Will nur vorbereitet sein :)

Gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 06 Dezember 2020, 14:41:00
Zitat von: mr_petz am 06 Dezember 2020, 14:33:05
Dazu habe ich eine Frage zur Ethernetkonfiguration.
Im Wiki steht ja, man kann eine feste IP vergeben. Das soll mit dem Tool PIC-Loader (Link wird ja noch erstellt) einzustellen sein.
Jetzt steht aber bei:
https://adapter.ebusd.eu/picfirmware#versions (https://adapter.ebusd.eu/picfirmware#versions)
Code Auswählen
Ethernet Minimale ebusd Version: 3.5 (enhanced protocol)
Es gibt doch zur Zeit nur eine v3.4 oder?
Oder verstehe ich was falsch und brauche nur das enhanced protocol?

Noch ein Hinweis/Frage zum Bootloader Host Application von Microchip.
Dort muss man sich Anmelden/Registrieren für den download.
Wollte mich da jetzt nicht anmelden. Ich habe mir jetzt die UnifiedHost-0.1.8-dist besorgt. Kann man die auch verwenden falls es ein Update des Pic gibt? Will nur vorbereitet sein :)
Hi Thomas,

genau, die feste IP Adresse lässt sich mit dem picloader einstellen. Mit diesem lässt sich auch die PIC Firmware aktualisieren, weil die unified host Applikation echt schlecht zu bedienen ist.
Diesen picloader muss ich noch in den enhanced_device Branch (https://github.com/john30/ebusd/tree/enhanced_device) von ebusd übernehmen und der wird dann in Zukunft einfach Teil des Release.

Version 3.5 von ebusd ist die angepeilte als nächstes kommende Version, die dann enhanced und normal unterstützt. Dazu wird dann nach Abschluss der Tests einfach der enhanced_device Branch in den master gemergt.

D.h. auch für die Tester: für das enhanced proto muss im Moment zwingend enhanced_device (https://github.com/john30/ebusd/tree/enhanced_device) geclont und das auch selbst compiliert werden.

Alles klar?  :)

John
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 06 Dezember 2020, 21:07:34
Zitat von: john30 am 06 Dezember 2020, 14:41:00
genau, die feste IP Adresse lässt sich mit dem picloader einstellen. Mit diesem lässt sich auch die PIC Firmware aktualisieren, weil die unified host Applikation echt schlecht zu bedienen ist.
Diesen picloader muss ich noch in den enhanced_device Branch (https://github.com/john30/ebusd/tree/enhanced_device) von ebusd übernehmen und der wird dann in Zukunft einfach Teil des Release.
der PIC loader ist jetzt auch im ebusd source im enhanced_device Branch (https://github.com/john30/ebusd/blob/enhanced_device/src/tools/ebuspicloader.cpp) und die Adapter 3 Doku Seite (https://adapter.ebusd.eu/) entsprechend aktualisiert.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 08 Dezember 2020, 07:33:27
Hallo zusammen,

nachdem die Tester jetzt fast ausschließlich den Bauteilesatz bekommen haben, anbei ein kleines Bild, das die Zuordnung der Teile auf die jeweilige Position erleichtern soll.

Einzig J11 (die PIC PROG Pinleiste) ist bei meiner Lieferung jetzt nicht dabei, da diese i.d.R. nicht benötigt wird. Um in den Bootloader Modus zu starten, nehme ich hier einfach eine Pinzette und verbinde damit die Pins 3-4 miteinander, bevor ich die Stromzufuhr anstecke.

Bei J9 für den Wemos nehmen wir einfach die Leisten, die beim Wemos dabei sind.

J1 und J4 sind etwas gekürzt bzw. habe ich ein wenig weiter rein geschoben, da die Jumper ansonsten beim Wemos oder USR Modul eine ungewollte Verbindung herstellen könnten.

LG John
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: pc1246 am 08 Dezember 2020, 10:00:26
Mitles
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 08 Dezember 2020, 18:07:47
sieht man hier schön, um 2 mm gekürzt und der Wemos oder W5500 sitzt nicht mehr am Jumper auf!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: harvey637 am 10 Dezember 2020, 14:03:56
Hi,
auch wenn das "erst" der Betatest ist ....
ich möchte mich schon mal in die Liste der definitiven Interessenten eintragen.

Mein Hintergrund: ich habe seit Jahren homematic und iobroker auf raspi mit etlichen homebrew Sensoren/Aktoren im Einsatz. Also ganz nah an der Hard- und Software!
Und ich kenne einen Lötkolben sehr gut :-)

Ich hatte "immer" eine Gasheizung, wo meine eigene Steuerung über Wandthermostate, Sonnenerkennung, über eine Relaissteuerung (Umschaltung Tag/Nacht zum ein-/Ausschalten der Heizung) im Betrieb war. Nach Umrüstung auf Wärmepumpe mit EBUS (Bosch AWMB) kann ich nicht mehr wie bisher einfach ein Relais klackern lassen, da muss was neues her!

Daher das Interesse an dem EBUS-Adapter. Kentnis Raspi/Linux/Shell/iobroker/homematic ist vorhanden.
Step 1 für mich ist das Auslesen der Werte der Anlage (Verbrauch, interne Temperaturen, ...), Step 2 ist z.B. die Ansteuerung der gewünschten Vorlauftemperatur.

Alles nicht zeitkritisch, die Anlage läuft ja wie vom Hersteller vorgesehen. Aber also Homematiker, IOBroker und Asksin++ Verwender ist da ja noch nicht Schluss :-)

Also wenn der Betatest vorbei ist und die Ergebnisse in Version 3.1 eingeflossen sind und entsprechende Bausätze vorhanden sind möchte ich mich gerne bewerben, gegen Zahlung natürlich!

ciao
Harvey637
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 11 Dezember 2020, 21:19:56
Ich danke vielmals bei den ersten dabei seien zu dürfen.
Aktuell bin ich am Einlöten aller Bauteile auf die Platine und hierbei ist mir auch schon die erste Verbesserung am Print auf dem PCB ins Auge gefallen bzw schmerzlich feststellen

Der Anschluss für den Raspberry Pi sollte nicht auf der Oberseite der Platine umrahmt werden, sondern auf der Rückseite da ja auch das Bauteil dort hin kommt.
Mir ist schon während des Einlötens der Stiftleiste vom Gassensor aufgefallen, dass hier etwas nicht stimmen konnte.
Nachdem ich allerdings alles gelötet hatte und versuchte das an den RPi zu halten fiel mir das kleine Malheur letzendlich auf.
Die Buchsenleisten für den D1 Mini und USR-ES1 sollten ebenfalls mit einem Rahmen versehen werden.
Beispielbilder sollten hier ebenfalls etwas Hilfestellung geben, wo z.B. die Pfostenleiste hin kommt.

J4 (Power) scheint an dieser Stelle wirklich etwas unglücklich platziert. Wenn das USR-ES1 Modul verkantet, gibt es hier Kontakt zum RPi 3.3V PIN zur Buchsenleiste. Schlimm wäre es hier vermutlich nicht da nur die Buchsenleiste kontaktiert ist.
Dies könnte alleine schon durch das angesteckte LAN-Kabel geschehen, was das Modul evtl in den Buchsenleisten verkantet und hierdurch den Kondensator auf den PIN drückt. Kürzen der Stifte hilft hier nur bedingt.
Evtl sollte man hier einen weiteren Jumper als Schutz über diesen einen Pin ziehen, wenn USB-Power genutzt wird. Ich selbst habe diese noch von älteren Motherboards da, daher sehe ich bei mir diesbezüglich ersteinmal kein Problem.

Zum Betrieb kann ich noch nix sagen, da ich jetzt die falsch gelötete Buchsenleiste auslöte und auf die richtige Seite bringe.
Es sollen auch alle möglichen Verbindungswege geprüft werden.

Endziel bei mir soll ein SOLO-Betrieb mittels LAN-Dose an der ebus Quelle seien.


Edit:
drei weitere Bilder angehangen.
Beim RPi 1B sollte ebenfalls mit irgendwelchen Abstandshaltern oder ähnlich gearbeitet werden. Die Stiftleisten können hier ebenfalls auf den Elko kommen (ist zwar mit Lack versehen, aber wer weiß was die Zeit bringt?).
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 12 Dezember 2020, 09:35:36
Hallo hErMes,

das tut mir natürlich sehr leid, dass du den Stecker verkehrt herum eingelötet hast. Wenn es dich beruhigt, das ist uns auch schon 2x passiert und wir sollten es eigentlich schon im Schlaf wissen.
Eine Print-Änderung, und das betrifft auch die gedruckten Rahmen, Bezeichnungen, etc. wäre zwar wünschenswert, ist aber für uns mit einem extremen Risiko verbunden, weil sich bei jeder Änderung
auf dem gesamten Weg vom CAD Programm über den Print-Hersteller bis zur Produktion ein (anderer) Fehler einschleichen kann und dann sitzen wir am Ende auf ein paar 100 unbrauchbaren Prints fest.
Ich werde das deshalb nur im Falle eines fatalen Problems nochmals angreifen. Bitte um Verständnis!

Außerdem wird das in der Serie sowieso kein Problem sein, weil ja die einzelnen Varianten schon von uns fertig gelötet ausgeliefert werden.
Ist nur jetzt für die Tester so gemacht worden, damit sie selbst entscheiden können, welche Variante zum Tragen kommt.

Das mit den Stiftleisten ist definitiv ein Fehler, in der endgültigen Version kommen dort kürzere Modelle zum Einsatz.
An alle Tester: bitte diese Stifte, dort wo es notwendig ist, mit dem Seitenschneider um 1-2mm selbst kürzen.

Ich hoffe du schaffst es, diese Buchsenleiste wieder auszulöten. Ist kein einfaches Unterfangen.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 12 Dezember 2020, 10:51:44
Hallo galileo,

die Buchsenleiste war in Bild 5 bereits wieder ausgelötet (Bild habe ich nur zur vollständigkeit gemacht) und anschließend in Bild 3 und 4 korrekt eingelötet mit Aufsatz auf dem Pi und der Feststellung des möglichen Kontakts zum Pi selbst.

Die LEDs sind anscheinend auch schon vor Auslieferung gedreht. Diese habe ich vor dem Einlöten der Leisten auf korrekte Farbe kontrolliert und konnte hier keine Vertauschung mehr feststellen. Sonst wären diese ebenfalls auf den korrekten Platz gerückt. Danke für die Abnahme der Arbeit  :)
Voraussetzung das PCB ist korrekt beschriftet  ::)

Funktionstest folgt heute. Bin am überlegen ob ich temporär ein EIB Kabel für den eBus an meinen Basteltisch ziehe (1DA plus und 1DA minus zwecks Forderung der 1,5 Quadrat) oder das Modul an der Heizung baumeln lasse mit hin und her gehen. Tendiere zum Kabel ziehen da auch noch kein LAN am Zielort anliegt und so komfortabel alles testen kann.

Beim mitgelieferten D1 Mini konnte ich allerdings keine Kontaktstelle der Stiftleisten zum Modul ausmachen. Auch ließ sich der Wemos nicht so verkanten dass es in irgend einer Weise Kontakt geben könnte. Ebenfalls hat der Wemos an dieser Stelle keinen Kupferplayer. Wäre auch etwas blöd im Sinne der Antenne auf der anderen Seite wenn dort Metall ist

Wichtig ist hier auch dass die Stifte kürzer als die Steckbrücken sind, da die überlangen Stifte dann aus der Brücke rausragen. Sieht man gut in Bild 4.
Zu kurz ist auch schlecht da die Brücken dann keinen richtigen Kontakt mehr geben.
Die langen Stiftleisten von unten her durch das PCB zu Stecken wäre auch eine Möglichkeit. Allerdings hat die Brücke dann nur ca gefühlte 1mm halt und musste hier vorher 1-2mm höher gezogen werden. Verlötung dann von oben. Aber in höhere Stückzahlen ist das vermutlich eine schlechte Lösung.

Gruß
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 12 Dezember 2020, 11:32:19
Sorry, wenn das vielleicht nicht noch deutlicher kommuniziert war mit den kürzeren Pinheadern für J1 und J4. Das hatte ich extra hier erwähnt (https://forum.fhem.de/index.php/topic,116418.msg1108474.html#msg1108474) und die Pinleisten zur leichteren Erkennung gleich mit den Jumpern drauf in die Schachtel gepackt.

Die LEDs habe ich alle vor Versand noch gedreht, damit ich auch sehen konnte, dass die Funktion grundsätzlich passt, und damit bei Euren Tests nicht große Fragezeichen aufkommen.

Zitat von: hErMeS am 12 Dezember 2020, 10:51:44
Beim mitgelieferten D1 Mini konnte ich allerdings keine Kontaktstelle der Stiftleisten zum Modul ausmachen. Auch ließ sich der Wemos nicht so verkanten dass es in irgend einer Weise Kontakt geben könnte. Ebenfalls hat der Wemos an dieser Stelle keinen Kupferplayer. Wäre auch etwas blöd im Sinne der Antenne auf der anderen Seite wenn dort Metall ist
Da machst Du mich jetzt etwas stutzig, denn gerade der Wemos ist sehr knapp über den J1 und J4. Nochmal der Hinweis: der USB Anschluss am Wemos muss genau über dem USB Anschluss des Boards liegen!
Aber vermutlich habe ich die J1+J4 Pinheader bei Dir nicht kurz genug gemacht.

Zitat von: hErMeS am 12 Dezember 2020, 10:51:44
Beim RPi 1B sollte ebenfalls mit irgendwelchen Abstandshaltern oder ähnlich gearbeitet werden. Die Stiftleisten können hier ebenfalls auf den Elko kommen (ist zwar mit Lack versehen, aber wer weiß was die Zeit bringt?).
Ach Mist, ich hab bei allen vergessen, den Abstandshalter für RPi beizulegen. Sorry!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 12 Dezember 2020, 12:53:44
Zitat von: john30 am 12 Dezember 2020, 11:32:19
Sorry, wenn das vielleicht nicht noch deutlicher kommuniziert war mit den kürzeren Pinheadern für J1 und J4. Das hatte ich extra hier erwähnt (https://forum.fhem.de/index.php/topic,116418.msg1108474.html#msg1108474) und die Pinleisten zur leichteren Erkennung gleich mit den Jumpern drauf in die Schachtel gepackt.
Das war soweit erkannt. Allerdings beim Einlöten doch gegen den anderen 3er vertauscht da beim umdrehen herausgefallen. Hab den dann auch gekürzt. Am besten kann man die am vergoldeten Kontakt unterscheiden. Die gejumperten sind nicht vergoldet.

Zitat
Die LEDs habe ich alle vor Versand noch gedreht, damit ich auch sehen konnte, dass die Funktion grundsätzlich passt, und damit bei Euren Tests nicht große Fragezeichen aufkommen.
Hatte mich schon so gefreut das zu beheben  ::)
Zitat
Da machst Du mich jetzt etwas stutzig, denn gerade der Wemos ist sehr knapp über den J1 und J4. Nochmal der Hinweis: der USB Anschluss am Wemos muss genau über dem USB Anschluss des Boards liegen!
Glaube es war gestern etwas spät  ;D
Stimmt, konnte aber hier kein wirkliches Problem feststellen da sich der Wemos nicht so stark verkanten lies und der Abstand weit genug ist. Das einzige war der Reset Taster vom D1 Mini der etwas knapp war. Der Rest sah nicht nach Kontaktmöglichkeit aus.
Der USR-ES1 lässt sich allerdings mehr verkanten durch weniger Stifte in den Leisten, weshalb der Abstand weiter seien sollte bzw mit Schutzmaßnahmen (einfach eine Brücke drüber) beheben lässt
Zitat
Ach Mist, ich hab bei allen vergessen, den Abstandshalter für RPi beizulegen. Sorry!
Nicht gravierend. Wie sieht das Teil aus? STL?


Bin auf die Rückmeldung der anderen gespannt
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 12 Dezember 2020, 15:59:31
Zitat von: hErMeS am 12 Dezember 2020, 12:53:44
Der USR-ES1 lässt sich allerdings mehr verkanten durch weniger Stifte in den Leisten, weshalb der Abstand weiter seien sollte bzw mit Schutzmaßnahmen (einfach eine Brücke drüber) beheben lässt
ah ich seh schon, da sollte die Buchsenleiste wohl besser in einer etwas längeren Variante gewählt werden.
Zitat von: hErMeS am 12 Dezember 2020, 12:53:44
Nicht gravierend. Wie sieht das Teil aus? STL?
ich nehme immer Sechskant-Kunstoff-Verbinder mit Schraubgewinden, aber sowas geht auch (https://www.reichelt.de/distanzbolzen-rastbefestigung-aussen-m3-10mm-vt-dkr-10mm-p231501.html).
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 12 Dezember 2020, 16:43:59
Noch etwas wichtiges:
Bei allen Testadaptern muss die PIC Firmware nochmal aktualisiert werden auf den letzten Stand vom 10.12. (https://adapter.ebusd.eu/firmware/20201210-offset.hex), siehe hier (https://adapter.ebusd.eu/picfirmware.html#versions).
Ansonsten klappt je nach "zickigem" Router/Switch das Aushandeln einer IP Adresse via DHCP in der Ethernet Variante nicht und bei allen Varianten brauchte es auf der eBUS Seite auch noch kleine Korrekturen.
Dazu wie in der Doku beschrieben (https://adapter.ebusd.eu/picfirmware.html#firmware-update) vorgehen, also:

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 13 Dezember 2020, 00:53:08
ebusd geclont und kompiliert
Firmware Update gemacht
ein make install auf das kompilierte gemacht
configuration nach /etc/ebusd aus dem Release und git clone (kein Unterschied)
Adapter verkabelt (grüne LED flackert, Blaue LED wird heller, gelbe LED leuchtet ebenfalls)

Und hier hört es bei mir auf. Ich habe keine Ahnung wie das jetzt Softwareseitig komplett zusammen hängt. ebusd ist ein lokaler daemon, ebusctl ein client dafür.
Den daemon nach einigem lesen und testen und probieren habe ich zumindest jetzt den ebusd am laufen
Es wird jedoch wird nichts geloggt in die angegebene file.
Code Auswählen
ebusd -f --logfile=/root/ebusd.log --loglevel=debug -d /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_623e3a4826deea11b6d2d3149a583cc7-if00-port0 --configpath=/etc/ebusd -D
2020-12-12 22:58:07.038 [main notice] ebusd 3.4.v3.4-96-g96d5623 started
2020-12-12 22:58:07.038 [main info] loading configuration files from /etc/ebusd
2020-12-12 22:58:07.038 [main info] reading templates /
2020-12-12 22:58:07.039 [main info] read templates in /
2020-12-12 22:58:07.039 [main info] reading file broadcast.csv
2020-12-12 22:58:07.040 [main info] successfully read file broadcast.csv
2020-12-12 22:58:07.040 [main info] reading file memory.csv
2020-12-12 22:58:07.041 [main info] successfully read file memory.csv
2020-12-12 22:58:07.041 [main info] reading dir  vaillant
2020-12-12 22:58:07.041 [main info] reading templates vaillant
2020-12-12 22:58:07.044 [main info] read templates in vaillant
2020-12-12 22:58:07.044 [main info] reading file vaillant/3c.rcc.5.csv
2020-12-12 22:58:07.045 [main info] successfully read file vaillant/3c.rcc.5.csv
2020-12-12 22:58:07.045 [main info] reading file vaillant/15.heb.csv
2020-12-12 22:58:07.049 [main info] successfully read file vaillant/15.heb.csv
2020-12-12 22:58:07.049 [main info] reading file vaillant/50.v61.mc.csv
2020-12-12 22:58:07.054 [main info] successfully read file vaillant/50.v61.mc.csv
2020-12-12 22:58:07.054 [main info] reading file vaillant/75.v81.csv
2020-12-12 22:58:07.055 [main info] successfully read file vaillant/75.v81.csv
2020-12-12 22:58:07.055 [main info] reading file vaillant/35.v81.1.csv
2020-12-12 22:58:07.057 [main info] successfully read file vaillant/35.v81.1.csv
2020-12-12 22:58:07.057 [main info] reading file vaillant/15.370.csv
2020-12-12 22:58:07.058 [main error] error reading config files from /etc/ebusd: ERR: duplicate entry, last error: vaillant/15.370.csv:10: ERR: duplicate entry, duplicate ID
2020-12-12 22:58:07.060 [bus notice] bus started with own address 31/36
2020-12-12 22:58:07.060 [main info] registering data handlers
2020-12-12 22:58:07.060 [main info] registered data handlers
2020-12-12 22:58:07.068 [bus notice] signal acquired
2020-12-12 22:58:17.061 [main debug] performing regular tasks
2020-12-12 22:58:17.065 [main notice] found messages: 265 (4 conditional on 3 conditions, 0 poll, 4 update)
2020-12-12 22:58:27.065 [main debug] performing regular tasks
2020-12-12 22:58:30.681 [network info] [00001] client connection opened 127.0.0.1
2020-12-12 22:58:32.095 [network debug] [00001] wait for result
2020-12-12 22:58:32.095 [main debug] >>> i
2020-12-12 22:58:32.095 [main debug] <<< version: ebusd 3.4.v3.4-96-g96d5623
signal: acquired
symbol rate: 23
max symbol rate: 54
reconnects: ...
2020-12-12 22:58:37.096 [main debug] performing regular tasks
2020-12-12 22:58:40.100 [network info] [00001] connection closed
2020-12-12 22:58:40.691 [network debug] dead connection removed - 0
^C2020-12-12 22:58:46.995 [main notice] SIGINT received
2020-12-12 22:58:47.230 [main notice] ebusd stopped


mit ebusctl komme ich dahin:
Code Auswählen

localhost: i
version: ebusd 3.4.v3.4-96-g96d5623
signal: acquired
symbol rate: 23
max symbol rate: 54
reconnects: 0
masters: 1
messages: 265
conditional: 4
poll: 0
update: 4
address 31: master #8, ebusd
address 36: slave #8, ebusd

localhost: ^C



Auch nehme ich ein fiepen ab weniger als 1m Abstand zur Platine wahr. Ein Spektogramm vom Handy gibt mir hier recht dass hier irgendetwas Schwingt.
Die Hauptfrequenz scheint um die 19,2 kHz zu liegen.
Der untere Teil vom Rainfall Diagramm ist Mikrofon direkt am Adapter. Oberer Teil Mikrofon/Smartphone vom Adapter entfernt.


Bild vom verkabelten Zusammenbau im Anhang.

Bin gespannt auf die Lösung
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 13 Dezember 2020, 10:49:25
Hallo hErMes,

schade das mit Rpi Pinheader, ein Foto weiter oben vor deinem ersten Post hättest den Pinheader gesehen das dieser nach unten eingelötet werden muss.
Ja, auch ich habe vergessen die Abstandshalter ( so wie bereits in der V 2.x benötigt ) beizulegen.  Das Loch in der Platine ist dafür vorgesehen den einzuklippen!
Das Auslöten ist ja mitunter etwas kompliziert um die Platine nicht zu beschädigen! Hoffentlich lesen hier genug mit!

Im angehängten Bild (https://forum.fhem.de/index.php?action=dlattach;topic=84636.0;attach=96706) sieht man and der V2.x den eingeklingten Abstandhater!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 13 Dezember 2020, 11:06:20
1-wire Sensor DS18b20 an der Platine V3 am Wemos anhängen!

Um den Sensor an der Platine anzuhängen ist nur eine 3-adrige Verbindung notwendig! KEIN Widerstand etc. am Sensor anbringen, der sitzt schon auf der Platine. Angehängt wird dieser an der Stiftleiste J7! Wer die Temperatur direkt am Adapter messen will, kann den DS18b20 asuch direkt über eine Stiftleiste anlöten ( siehe letztes Bild ) .

Den Sensor dann direkt im Webinterface des Wemos aktivieren. Die Beschriftung des J7 bezieht sich allerdings auf den Rpi Connector, daher steht hier GPIO4. Am Wemos ist der allerdings als GPI12 verdrahtet, daher den D6 konfigurieren. Dazu einfach bei "Set Current" und "Set Initial" den Button "Sensor" anklicken.  Nicht vergessen die Configuration zu speichern!

In Fhem kann dann der Sensorwert ganz einfach mit HTTPMOD erfasst werden.

Code Auswählen
define DS18b20_temp HTTPMOD http://10.0.0.20/sensors 60
attr DS18b20_temp userattr reading01Name reading01Regex
attr DS18b20_temp reading01Name temperature
attr DS18b20_temp reading01Regex 28ff5c3db11501</td><td>([\d\.]+)
attr DS18b20_temp room eBus
attr DS18b20_temp stateFormat temperature °C
In der Regex muss die Sensor-ID für den 1-wire Kennung eingetragen werden ( hier 28ff5c3db11501 ). Diese kann im Webif unter "Sensors" abgelesen werden. Da hier mehrere  Sensoren angeschlossen werden können, einfach weitere readings ( reading02Name ) anlegen und die die entsprechende ID eintragen!
Im Define natürlich eure IP-Adresse des Wemos eintragen! Der Wert dahinter ( hier 60 ) sind die Sekunden in welchen der Wert geholt werden soll.


Bei mehreren Sensoren empfiehlt es sich allerdings direkt den Json String auszuwerten da hier alle Sensoren auf einmal aufgelistet werden. Bei mehreren Sensoren diese einfach parallel hängen, sie unterscheiden sich dann an der 1-wire Adresse!

Code Auswählen
define DS18b20_json HTTPMOD http://10.0.0.20/sensor 120
attr DS18b20_json extractAllJSON 1
attr DS18b20_json room eBus
attr DS18b20_json stateFormat sensors_01_value °C


LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 13:01:54
Hi!
Vielen Dank für das Testkit!
Ich habe erst mal alles eingelötet, mal sehen welche Versionen ich alle testen werde.
Zunächst wollte ich das Firmwareupdate machen und wollte den picloader nehmen. Leider ist der im git clone nicht enthalten, obwohl auf der git Webseite der picloader unter tools erscheint, mache ich was falsch?
Hatte gehofft ebuspicloader wird beim compilieren automatisch mit erstellt.
Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 13 Dezember 2020, 13:10:31
hast du den Link vom ersten Post genommen?

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 13:13:18
Hi!
Danke ja, aber das war nicht das Problem.
Wenn man die cloneadresse von der Webseite nimmt, wird der branch nicht mit kopiert. Es muss aber heißen:
git clone https://github.com/john30/ebusd.git --branch enhanced_device (https://github.com/john30/ebusd.git%20--branch%20enhanced_device)
Das hat es erst mal gelöst.

Vorschlag für eine Anleitung:
Erforderliche Programme installieren falls nicht vorhanden:
apt update
apt install git autoconf automake g++ make libmosquitto-dev
In ein arbeitsverzeichniss wechseln, dass keinen Ordner ebusd enthalten darf. Ggf Ordner erstellen z.B.:
cd /home/pi
mkdir ebusdSRC
cd /home/pi/ebusdSRC
Respository clonen:
git clone https://github.com/john30/ebusd.git --branch enhanced_device (https://github.com/john30/ebusd.git%20--branch%20enhanced_device)
Programm erstellen:
./autogen.sh
make install


Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 13:56:52
So, nun steh ich vor dem nächsten Problem.
Die  LOLIN D1 mini sind ja schon geflasht, er taucht bei mir aber nicht als Accespoint auf. Wie bekomme ich den nun mit meinem Netzwerk verbunden?
Falls er noch geflasht werden müsste, welche Firmware ist für ihn die richtige?
Über Terminal, nicht angesteckt bekomme ich nur die Ausgabe SC_STATUS_FIND_CHANNEL.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 16:07:39
Sooooo.
Wir haben den D1 mini bekommen also die Firmware aus https://github.com/john30/ebusd-esp ebus-v3_d1mini.bin.
Einmal konnte ich die Firmware flashen. Habe dann mein Heimnetzwerk eingestellt und neu gestartet.
Seit dem bekomme ich im seriellen Monitor nur noch:
ets Jan  8 2013,rst cause:4, boot mode:(3,7)

wdt reset
load 0x4010f000, len 3584, room 16
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld

in immer wiederkehrenden Abständen.
Sprich ein Watchdog spricht immer wieder an. Ein neuflashen bringt keine Lösung. In das Configmenu komme ich nicht rein und über WLan ist er auch nicht zu erreichen.
Ich hatte noch einen Wemos rumliegen. Den habe ich jetzt genau so geflasht und der läuft auch so. Inklusive Board. Hängt jetzt auch am ebus und ich kann den nächsten Schritt machen.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 13 Dezember 2020, 16:10:02
Zitat von: JimKnopf am 13 Dezember 2020, 13:13:18
Wenn man die cloneadresse von der Webseite nimmt, wird der branch nicht mit kopiert. Es muss aber heißen:
...

Hi Burkhard,

vermutlich hast Du meinen Artikel hier weiter oben (https://forum.fhem.de/index.php/topic,116418.msg1109955.html#msg1109955) nicht gesehen. Da hatte ich das eigentlich sehr klar formuliert (dachte ich).
Final wird ebuspicloader dann natürlich Teil des normalen Release, insofern ist für die nicht-Tester dann nichts besonderes mehr zu tun (Stichwort enhanced branch).

Die grundsätzliche Anteilung zum compilieren steht auch im ebusd wiki (https://github.com/john30/ebusd/wiki/1.-Build-and-install), insofern hab ich das nicht nochmal im Detail aufgeführt.

LG John

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 13 Dezember 2020, 16:13:11
Zitat von: JimKnopf am 13 Dezember 2020, 13:56:52
Die  LOLIN D1 mini sind ja schon geflasht, er taucht bei mir aber nicht als Accespoint auf. Wie bekomme ich den nun mit meinem Netzwerk verbunden?
Falls er noch geflasht werden müsste, welche Firmware ist für ihn die richtige?
Über Terminal, nicht angesteckt bekomme ich nur die Ausgabe SC_STATUS_FIND_CHANNEL.
Die Wemos sind im Testkit ja noch verpackt, also natürlich nicht mit passender Firmware geflasht.
Firmware gibt es prinzipiell mehrere, aber für den Einsatz im Adapter 3 jetzt erstmal ebusd-esp (https://github.com/john30/ebusd-esp).
Die Wemos sind zuweilen sehr "zickig". Zum einen in puncto Stromversorgung und zum anderen auch beim Flashen, da es mehrere spezielle Speicherbereiche gibt. Ich hab mir angewohnt, immer erst mal ein erase zu machen (z.B. mit esptool.py) und danach zu flashen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 17:07:05
Hi John!

Ich konnte den Wemos wiederbeleben. Ich habe ihn erneut geflasht und unter Advanced die Speichergröße auf 16 MByte gestellt, in der Hoffnung dass der Speicher oberhalb des Programms gelöscht wird.
Jetzt komme ich wieder in das Konfigurationsmenü aber die Werte werden nicht gespeichert. Regelmäßig wird noch immer ein Reset ausgeführt. Eine andere Spannungsversorgung habe ich ausprobiert, kein Unterschied.
Code Auswählen
Enter your choice: F
Performing hard factory reset...
EEPROM reset, rebooting...

ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3584, room 16
tail 0
chksum 0xb0
csum 0xb0
v2843a5ac
~ld


Welcome to eBUS adapter 3, build 20201122
Configured as WIFI access point EBUS without password.
For configuration with web browser, connect to this WIFI and open http://192.168.4.1/
Entering configuration mode.
Chip ID: 009BC25D
Hostname: ebus-9bc25d

Factory-Reset funktioniert leider auch nicht. Anscheinend kommt die Firmware nicht an den Speicher ran.
EDIT: Jetzt konnte ich den Wemos vollständig wiederbeleben. Wichtig!: wer mit NodeMCU unter Windows flasht sollte unbedingt die neuste Version verwenden. Zu finden unter: https://github.com/marcelstoer/nodemcu-pyflasher/releases (https://github.com/marcelstoer/nodemcu-pyflasher/releases)
Hier unter Erase Flash : "yes, wipes all data" auswählen, damit der Speicher wirklich vollständig gelöscht wird, nicht nur der Bereich vom neuen Programm überschrieben wird.
Bei mir hat das geholfen.

Jetzt zum eigentlichen testen.
Der Adapter 3 hängt parallel mit dem bisherigen Adapter 2 (selbst gefädelt) zusammen mit der ISM7 von Wolf an der Heizung.
Während der Adapter 2 weiterhin recht ordentlich Daten liefert, hat der Adapter 3 (während Adapter2 nur passiv ist) probleme mit pollen von Daten:
Ja, wer lesen kann ..... ,,enh:" musste noch vor die ip, jetzt läufts.


Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 13 Dezember 2020, 19:03:33
zum Problem mit den Wemos, wie John schon schreibt sind die manchmal etwas zickig. Ich habe daher in den Testkits die ich versendet habe die alle schon geflasht und getestet ob sich der AP aufspannt!

Aber wie auch JimKnopf schon festgestellt hat, ist bei Fehlfunktionen oft ein totaler Reset notwendig und den Dingern wieder Leben einzuhauchen.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 19:11:35
Ich habe jetzt auch erste Ergebnisse:
Größtenteils läuft alles perfekt. Recht selten kommt aber folgendens:
Code Auswählen
2020-12-13 19:07:22.082 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Kesselpumpeaus;51.69;-;-;60.0;-
2020-12-13 19:07:22.137 [bus error] device status: eBUS comm error: framing
2020-12-13 19:07:22.138 [bus error] arbitration start error
2020-12-13 19:07:22.320 [update notice] sent poll-read regler WarmwasserSoll QQ=01: 60.0


Soll ich das ISM7 noch abnabeln? Nicht dass das dazwischen funkt.Ich habe es abgehängt, bzw. den Strom weggenommen. Fehler bleiben.Habe jetzt log="all error" mit in den Aufruf genommen.
Gruß,Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 13 Dezember 2020, 20:33:42
Zitat von: JimKnopf am 13 Dezember 2020, 19:11:35
Ich habe jetzt auch erste Ergebnisse:
Größtenteils läuft alles perfekt. Recht selten kommt aber folgendens:
Code Auswählen
2020-12-13 19:07:22.082 [update notice] received write feuerung betrd QQ=10: Brauchwasser_Heizen;Kesselpumpeaus;51.69;-;-;60.0;-
2020-12-13 19:07:22.137 [bus error] device status: eBUS comm error: framing
2020-12-13 19:07:22.138 [bus error] arbitration start error
2020-12-13 19:07:22.320 [update notice] sent poll-read regler WarmwasserSoll QQ=01: 60.0


Soll ich das ISM7 noch abnabeln? Nicht dass das dazwischen funkt.Ich habe es abgehängt, bzw. den Strom weggenommen. Fehler bleiben.Habe jetzt log="all error" mit in den Aufruf genommen.
Gruß,Burkhard
Das ist jetzt ein neuer Detailgrad, der erst mit dem Adapter 3 möglich ist. Hier ist jetzt erkennbar, dass eine Arbitrierung regulär vom ebusd verloren wurde, was dann auch gleichzeitig zu einem RS232 Framing Error geführt hat.
Aber ich sehe schon, das als Fehler einzustufen ist etwas zu krass, denn es handelt sich um völlig normales und zu erwartendes Verhalten an einem Multi-Master Bus wie diesem.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 13 Dezember 2020, 21:38:56
Meinen Fehler mit dem ebusd Daemon habe ich mittlerweile gefunden. Das kleine, aber nicht wegzulassende "enh:" beim Device direkt davor.
Jetzt erhalte ich auch Meldungen.
Wird das in einer späteren Version automatisch abgeprüft so dass man das eventuell weg lassen kann? Anleitung genau lesen, ich weiß. 4 kleine Zeichen die über Erfolg und Misserfolg entscheiden.



Weisen folgende Meldungen (alles auf bus gefiltert) auf irgendein Problem hin?

Code Auswählen
2020-12-13 20:17:16.919 [main notice] ebusd 3.4.v3.4-96-g96d5623 started
2020-12-13 20:17:16.920 [main info] loading configuration files from /etc/ebusd
2020-12-13 20:17:16.972 [main error] error reading config files from /etc/ebusd: ERR: duplicate entry, last error: vaillant/15.370.csv:10: ERR: duplicate entry, duplicate ID
2020-12-13 20:17:16.975 [bus notice] bus started with own address 31/36
2020-12-13 20:17:17.015 [bus notice] signal acquired
2020-12-13 20:17:17.401 [bus notice] device status: reset
2020-12-13 20:17:17.401 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:17:17.452 [bus info] arbitration delay 286 - 286 micros
2020-12-13 20:17:17.463 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:17:25.402 [bus notice] new master 10, master count 2
2020-12-13 20:17:25.463 [bus notice] new master 03, master count 3
2020-12-13 20:17:25.464 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:17:25.516 [bus info] arbitration delay 219 - 286 micros
2020-12-13 20:17:25.527 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:17:35.485 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:17:35.536 [bus info] arbitration delay 219 - 288 micros
2020-12-13 20:17:35.547 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:17:45.544 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:17:45.607 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:17:55.605 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:17:55.656 [bus info] arbitration delay 219 - 343 micros
2020-12-13 20:17:55.667 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:18:05.669 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:18:05.731 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:18:15.725 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:18:15.787 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:18:25.785 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:18:25.847 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:18:33.756 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:18:34.240 [bus info] arbitration delay 219 - 366 micros
2020-12-13 20:18:34.251 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:18:39.161 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:18:39.644 [bus info] arbitration delay 219 - 529 micros
2020-12-13 20:18:39.655 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:18:45.005 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:18:45.086 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:18:55.963 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:18:56.025 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:19:06.028 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:19:06.090 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:19:16.083 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:19:16.146 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:19:26.143 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:19:26.206 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:19:36.208 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:19:36.270 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:19:46.269 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:19:46.331 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:19:56.333 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:19:56.396 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:20:06.358 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:20:06.420 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:20:16.413 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:20:16.475 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:20:26.472 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:20:26.534 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:20:36.536 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:20:37.092 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:20:46.628 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:20:46.691 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:20:56.647 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:20:56.711 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:21:06.710 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:21:06.773 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:21:16.771 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:21:16.834 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:21:26.839 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:21:26.901 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:21:36.903 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:21:36.965 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:21:46.959 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:21:47.021 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:21:57.019 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:21:57.082 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:22:07.080 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:22:07.143 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:22:17.144 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:22:17.206 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:22:27.208 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:22:27.271 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:22:37.237 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:22:37.299 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:22:47.289 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:22:47.351 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:22:57.349 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:22:57.412 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:23:07.414 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:23:07.476 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:23:17.471 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:23:17.533 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:23:27.531 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:23:27.593 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:23:37.591 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:23:37.654 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:23:47.659 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:23:47.722 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:23:57.720 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:23:57.783 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:24:04.438 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:24:04.933 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:24:10.041 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:24:10.330 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:24:17.831 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:24:17.894 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:24:27.899 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:24:27.961 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:24:37.963 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:24:38.025 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:24:48.027 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:24:48.091 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:24:58.048 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:24:58.111 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:25:08.111 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:25:08.173 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:25:18.160 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:25:18.222 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:25:28.224 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:25:28.286 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:25:37.322 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:25:37.944 [bus error] poll heb Yield failed: ERR: read timeout
2020-12-13 20:25:48.336 [bus info] poll cmd: 3115b509030d1f00
2020-12-13 20:25:48.399 [bus error] poll heb CollPumpHRuntime failed: ERR: read timeout
2020-12-13 20:25:58.400 [bus info] poll cmd: 3115b509030d1e00
2020-12-13 20:25:58.462 [bus error] poll heb Yield failed: ERR: read timeout


Jetzt habe ich aber noch auf dem Raspberry Pi 1b ein kleines Problem. Der will auf /dev/ttyAMA0 nichts rausrücken. Das Device ist vorhanden.
Code Auswählen
ebusd -f -d enh:/dev/ttyAMA0 --scanconfig --loglevel=debug
2020-12-13 19:36:44.129 [main notice] ebusd 3.4.v3.4-96-g96d5623 started with auto scan
2020-12-13 19:36:44.132 [main info] loading configuration files from http://ebusd.eu/config/
2020-12-13 19:36:44.172 [main info] reading templates /
2020-12-13 19:36:44.218 [main info] read templates in /
2020-12-13 19:36:44.220 [main info] reading file memory.csv
2020-12-13 19:36:44.263 [main info] successfully read file memory.csv
2020-12-13 19:36:44.265 [main info] reading file broadcast.csv
2020-12-13 19:36:44.311 [main info] successfully read file broadcast.csv
2020-12-13 19:36:44.313 [main info] read config files
2020-12-13 19:36:44.318 [main info] registering data handlers
2020-12-13 19:36:44.320 [main info] registered data handlers
2020-12-13 19:36:44.324 [bus notice] bus started with own address 31/36
2020-12-13 19:36:54.327 [main debug] performing regular tasks
2020-12-13 19:36:57.438 [network info] [00001] client connection opened 127.0.0.1
2020-12-13 19:36:57.442 [main debug] >>> i
2020-12-13 19:36:57.445 [main debug] <<< version: ebusd 3.4.v3.4-96-g96d5623
signal: no signal
reconnects: 0
masters: 1
messages: 11
conditio ...
2020-12-13 19:36:57.447 [network debug] [00001] wait for result
2020-12-13 19:36:57.458 [network info] [00001] connection closed
2020-12-13 19:36:58.442 [network debug] dead connection removed - 0
2020-12-13 19:37:02.447 [main debug] performing regular tasks
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 13 Dezember 2020, 23:59:44
Hi!

Ist es eigentlich grundsätzlich möglich zwei Temperatursensoren an dem Wemos anzuschließen?
Eine Anwendung wären z.B. Vorlauf- und Rücklauftemperatur vom Brauchwasser. Da habe ich jetzt zwei Funk-Temperatursensoren, würde aber gerne die Funklast im Haus reduzieren.
J7 ist ja für einen vorgesehen, könnte man noch direkt an den Wemos gehen?
Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 14 Dezember 2020, 00:28:00
Hier noch einmal die letzten interessanten Meldungen:
Code Auswählen
2020-12-13 20:07:32.677 [bus error] device status: eBUS comm error: framing
2020-12-13 20:08:22.322 [bus error] poll solar SolarErfolg failed: ERR: SYN received
2020-12-13 20:25:09.060 [bus error] signal lost
2020-12-13 20:25:12.704 [bus error] send to 30: ERR: no signal, give up
2020-12-13 20:25:12.704 [bus error] send message part 0: ERR: no signal
2020-12-13 20:25:12.704 [mqtt error] write regler Mode: ERR: no signal
2020-12-13 20:32:08.815 [bus error] device status: eBUS comm error: framing
2020-12-13 20:32:08.815 [bus error] arbitration start error
2020-12-13 20:35:42.402 [bus error] poll regler HGStatus failed: ERR: read timeout
2020-12-13 20:38:59.121 [bus error] poll regler Raumtemperatur failed: ERR: read timeout
2020-12-13 20:40:54.217 [bus error] device status: eBUS comm error: framing
2020-12-13 20:40:54.218 [bus error] arbitration start error
2020-12-13 20:42:57.354 [bus error] poll regler Raumtemperatur failed: ERR: read timeout
2020-12-13 20:58:25.022 [bus error] device status: eBUS comm error: framing
2020-12-13 21:02:33.067 [bus error] signal lost
2020-12-13 21:08:50.498 [bus error] device status: eBUS comm error: framing
2020-12-13 21:14:34.029 [bus error] poll regler HGPWMPumpe failed: ERR: SYN received
2020-12-13 21:20:15.264 [bus error] send to 30: ERR: read timeout, retry
2020-12-13 21:21:17.071 [bus error] device status: eBUS comm error: framing
2020-12-13 21:21:17.071 [bus error] arbitration start error
2020-12-13 21:23:18.059 [bus error] signal lost
2020-12-13 21:34:44.130 [bus error] device status: eBUS comm error: framing
2020-12-13 21:34:44.131 [bus error] arbitration start error
2020-12-13 21:35:56.752 [bus error] device status: eBUS comm error: framing
2020-12-13 21:36:46.797 [bus error] device status: eBUS comm error: framing
2020-12-13 21:36:46.797 [bus error] arbitration start error
2020-12-13 21:43:15.116 [mqtt error] communication error: connection lost
2020-12-13 21:43:28.119 [mqtt error] publish: The client is not currently connected.
2020-12-13 21:43:46.161 [mqtt error] publish: The client is not currently connected.
2020-12-13 21:47:34.238 [bus error] poll regler Unbekannt1 failed: ERR: SYN received
2020-12-13 21:49:17.369 [bus error] device status: eBUS comm error: framing
2020-12-13 21:52:09.345 [bus error] poll solar ruecklauftemp failed: ERR: read timeout
2020-12-13 21:54:36.169 [bus error] poll regler Raumtemperatur failed: ERR: read timeout
2020-12-13 22:04:07.417 [bus error] device status: eBUS comm error: framing
2020-12-13 22:04:07.417 [bus error] poll solar ruecklauftemp failed: ERR: read timeout
2020-12-13 22:05:08.103 [bus error] device status: eBUS comm error: framing
2020-12-13 22:05:08.104 [bus error] arbitration start error
2020-12-13 22:06:47.198 [bus error] device status: eBUS comm error: framing
2020-12-13 22:06:47.199 [bus error] arbitration start error
2020-12-13 22:07:22.173 [bus error] poll regler HGPWMPumpe failed: ERR: read timeout
2020-12-13 22:08:03.232 [bus error] device status: eBUS comm error: framing
2020-12-13 22:11:48.414 [bus error] device status: eBUS comm error: framing
2020-12-13 22:19:18.756 [bus error] device status: eBUS comm error: framing
2020-12-13 22:20:33.832 [bus error] device status: eBUS comm error: framing
2020-12-13 22:20:33.832 [bus error] arbitration start error
2020-12-13 22:21:36.094 [bus error] poll regler Unbekannt1 failed: ERR: read timeout
2020-12-13 22:30:34.314 [bus error] device status: eBUS comm error: framing
2020-12-13 22:30:34.314 [bus error] arbitration start error
2020-12-13 22:34:22.151 [bus error] poll solar durchfl failed: ERR: read timeout
2020-12-13 22:35:09.485 [bus error] device status: eBUS comm error: framing
2020-12-13 22:47:07.054 [bus error] device status: eBUS comm error: framing
2020-12-13 22:47:07.054 [bus error] arbitration start error
2020-12-13 22:51:00.215 [bus error] device status: eBUS comm error: framing
2020-12-13 22:54:20.372 [bus error] device status: eBUS comm error: framing
2020-12-13 22:56:25.489 [bus error] device status: eBUS comm error: framing
2020-12-13 22:56:25.489 [bus error] arbitration start error
2020-12-13 22:56:48.227 [bus error] poll regler WarmwasserSoll failed: ERR: SYN received
2020-12-13 22:57:01.288 [bus error] poll regler HGStatus failed: ERR: read timeout
2020-12-13 22:57:40.680 [bus error] poll regler Unbekannt2 failed: ERR: wrong symbol received
2020-12-13 23:03:09.120 [bus error] device status: eBUS comm error: framing
2020-12-13 23:03:09.120 [bus error] arbitration start error
2020-12-13 23:16:51.412 [bus error] device status: eBUS comm error: framing
2020-12-13 23:36:12.356 [bus error] poll solar durchfl failed: ERR: read timeout
2020-12-13 23:37:22.112 [bus error] poll regler HGPWMPumpe failed: ERR: read timeout
2020-12-13 23:38:32.384 [bus error] poll regler Raumtemperatur failed: ERR: wrong symbol received
2020-12-13 23:38:32.388 [bus error] device status: eBUS comm error: framing
2020-12-13 23:39:47.466 [bus error] device status: eBUS comm error: framing
2020-12-13 23:43:29.824 [bus error] device status: eBUS comm error: framing
2020-12-13 23:43:34.425 [bus error] poll regler Unbekannt1 failed: ERR: SYN received
2020-12-13 23:43:44.376 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:43:50.254 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-13 23:44:19.858 [bus error] poll solar durchfl failed: ERR: read timeout
2020-12-13 23:44:52.513 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:44:54.930 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-13 23:45:51.780 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:45:55.825 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-13 23:46:58.562 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:47:00.201 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-13 23:48:05.555 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:48:10.341 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-13 23:58:08.311 [bus error] device status: eBUS comm error: framing
2020-12-13 23:58:12.155 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-13 23:58:15.595 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 00:06:43.866 [bus error] poll regler WarmwasserSoll failed: ERR: wrong symbol received
2020-12-14 00:08:18.417 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 00:08:20.405 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 00:09:06.911 [bus error] device status: eBUS comm error: framing
2020-12-14 00:09:06.911 [bus error] arbitration start error
2020-12-14 00:11:57.194 [bus error] device status: eBUS comm error: framing
2020-12-14 00:11:57.195 [bus error] arbitration start error
2020-12-14 00:18:23.679 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 00:18:25.371 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 00:21:29.386 [bus error] device status: eBUS comm error: framing
2020-12-14 00:23:57.282 [bus error] poll solar ruecklauftemp failed: ERR: wrong symbol received
2020-12-14 00:23:57.294 [bus error] device status: eBUS comm error: framing
2020-12-14 00:26:04.604 [bus error] device status: eBUS comm error: framing
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Dezember 2020, 09:52:13
Zitat von: JimKnopf am 13 Dezember 2020, 23:59:44
Hi!

Ist es eigentlich grundsätzlich möglich zwei Temperatursensoren an dem Wemos anzuschließen?
Eine Anwendung wären z.B. Vorlauf- und Rücklauftemperatur vom Brauchwasser. Da habe ich jetzt zwei Funk-Temperatursensoren, würde aber gerne die Funklast im Haus reduzieren.
J7 ist ja für einen vorgesehen, könnte man noch direkt an den Wemos gehen?
Gruß,
Burkhard

Ja das geht ohne Probleme, da ja jeder Sensor eine eigene 1-wire ID bekommt. Habe ich hier in einem Beispiel (https://forum.fhem.de/index.php/topic,116418.msg1110105.html#msg1110105) schon geschrieben, nimm dann aber die JSON Variante zur Auswertung da brauchst sonst in Fhem weiter nix zu tun und die Sensoren sollten auftauchen. Du kannst auch so wasserdichte Sensoren (https://de.aliexpress.com/item/32827810300.html?spm=a2g0o.productlist.0.0.5ce16a0fzPFuHu&algo_pvid=46867ef8-6c1d-45a6-b705-1f9e9d5950db&algo_expid=46867ef8-6c1d-45a6-b705-1f9e9d5950db-0&btsid=0bb0624616079358425925802e1973&ws_ab_test=searchweb0_0,searchweb201602_,searchweb201603_) mit Kabel nehmen, die haben wir auch schon bei der Platine 2.x verbaut.

Code Auswählen
{"sensors": [{"sensor":0,"pin":6,"gpio":12,"address":"28ff1347b11501","value":23.6}]}
der JSON String sieht so aus.

Code Auswählen
{"sensors": [{"sensor":0,"pin":6,"gpio":12,"address":"28ff5c3db11501","value":22.9},{"sensor":1,"pin":6,"gpio":12,"address":"28ff1347b11501","value":27.1}]}
bei mehreren kommen halt mehrere mit unterschiedlicher Adresse.

Ich nehme die wasserdichten Sensoren auch zur Erfassung der Pooltemperatur!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 14 Dezember 2020, 11:34:12
Hi!

Die Wifi Variante läuft bei mir bis jetzt soweit stabiel, habe jetzt mal auf Ethernet gewechselt. Läuft jetzt seit 5 min ohne Probleme. Ausgaben durch "all error" poste ich dann später, wenn sich was gesammelt hat.
Meine Anlage habe ich mal soweit in die Signatur eingetragen. Aufgabenstellung bei mir: mitlesen von Telegrammen, pollen von gezielten Werten und schreiben des Modus der Heizungsanlage (Timer, nur Warmwasser) in Abhängigkeit der Öffnungsgrade der MAX! Heizkörperthermostate.
Bei nächster Gelegenheit werde ich mir mal ne Tüte Sensoren mitbestellen  ;D.

EDIT: nach einer Stunde betrieb, hier die Ausgaben:
Code Auswählen
pi@raspberrypi:~ $ $ ebusd -f -enh:192.168.2.190:9999 -l /var/log/ebusd.log --latency=20000 --address=01 --configpath=/etc/ebusd/de --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.2.101 --mqtttopic=ebusd/%circuit/%name --pollinterval=10 --enablehex --enabledefine --log="all error"
2020-12-14 11:28:02.564 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 11:28:08.511 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 11:29:09.258 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 11:29:12.871 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 11:30:15.778 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 11:30:18.502 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 11:31:46.975 [bus error] poll solar SolarErfolg failed: ERR: read timeout
2020-12-14 11:35:55.337 [bus error] poll solar ruecklauftemp failed: ERR: read timeout
2020-12-14 11:40:20.657 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 11:40:23.370 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 11:42:07.339 [bus error] device status: eBUS comm error: framing
2020-12-14 11:42:07.339 [bus error] arbitration start error
2020-12-14 11:50:25.020 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 11:50:28.042 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 11:58:09.192 [bus error] poll solar durchfl failed: ERR: read timeout
2020-12-14 12:00:31.609 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 12:00:33.887 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 12:01:46.523 [bus error] poll solar SolarErfolg failed: ERR: read timeout
2020-12-14 12:10:36.344 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 12:10:38.991 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 12:16:12.869 [bus error] device status: eBUS comm error: framing
2020-12-14 12:17:27.924 [bus error] device status: eBUS comm error: framing
2020-12-14 12:18:17.962 [bus error] device status: eBUS comm error: framing
2020-12-14 12:20:41.555 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 12:20:43.864 [mqtt error] decode scan.08 : ERR: argument value out of valid range
2020-12-14 12:21:56.347 [bus error] poll solar ruecklauftemp failed: ERR: read timeout
2020-12-14 12:22:03.135 [bus error] device status: eBUS comm error: framing
2020-12-14 12:25:23.293 [bus error] device status: eBUS comm error: framing
2020-12-14 12:30:47.269 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
2020-12-14 12:30:49.269 [mqtt error] decode scan.08 : ERR: argument value out of valid range


Im Vergleich zu Wifi kein nennenswerter Unterschied, TOP!  :D.
Ihr habt nen super Job gemacht! Danke!!
Die RPI Version wollte ich nicht unbedingt testen, wäre aber zur Not möglich.
Ich bin jetzt bereit auf Wunsch Dinge gezielt zu testen, bzw. Situationen herbeizuführen wenn gewünscht.
Sagt einfach was ich machen soll. Falls keine besonderen Wünsche anstehen würde ich morgen wieder auf Wifi wechseln und lasse solange die Ethernetversion laufen lassen.
Gruß,
Burkhard

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: pc1246 am 14 Dezember 2020, 12:28:08
Moin zusammen
Wenn auch nur Mitleser, so doch zwei Anmerkungen von mir.
@JimKnopf: Kannst du das bitte in Codetags setzen was Du in #36 gepostet hast! Das ghet auch nachtraeglich!

Und zur WEMOS Problematik kann ich sagen, dass ich schon mal keinen neuen mehr bei mir zu Hause im WLAN finden konnte.
Letztendlich lag das wohl an der Fritte, die da irgendwie schlappgemacht hat. Also ganz zur Not bei solch einem Problem mal kurz das WLAN ausmachen, dann sollte man das loesen koennen.

Ich lese weiter gespannt mit!
Gruss Christoph
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 14 Dezember 2020, 12:45:32
Hi Christoph!

Mit den Codetags habe ich erledigt.
Das mit dem Wemos kann ich so bestätigen. Bei mir ist noch der vom Adapter 2.2 aktiv, taucht aber auch nicht immer in der Fritzbox auf.
Könnte evtl. daran liegen, dass er zwar im WLan hängt, aber sich nicht meldet. Den Adapter 2.2 spreche ich normalerweise nicht mehr an. Da war er auch nicht im WLan. Ich habe ebusd mit dessen IP zusätzlich aufgerufen. Hat sofort reagiert und tauchte dann auch im WLan wieder auf.
Vielleicht könnte man den Wemos, wenn er nicht von außen angesprochen wird, ein ping senden lassen, damit er nicht vergessen wird.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 14 Dezember 2020, 15:42:59
Hab eine Nachfrage zu den LED Stati

Die gelbe (Power) leuchtet ja dauerhaft wenn die Sekundärseite (Isolierter ebus Bereich) Strom durch die Primärseite (Eth, Pi, USB) hat.
Die blaue nur beim in Betrieb gehen? Denn die ist bei mir aus. Diese geht nur noch an während Daten auf den ebus gesendet werden. Hier allerdings auch teils mit unterschiedlicher Helligkeit während des Sendens. Beschreibung hierzu scheint nicht ganz zu passen.
Die grüne flackert fast durchgehend (Signalisierung des Empfanges von validen Datenpaketen oder einfach nur Daten?)
Die rote nur beim Senden.


edit:
Im Log taucht jetzt öfters teilweise auch mehrfach hintereinander  ERR: read timeout during receive command ACK, switching to skip auf.

Code Auswählen

2020-12-14 18:23:40.515 [update info] received BC cmd: 10feb510020601
2020-12-14 18:23:45.744 [main debug] performing regular tasks
2020-12-14 18:23:47.881 [update info] received MS cmd: 1008b5110101 / 094c417006496d0100ff
2020-12-14 18:23:48.149 [update info] received MS cmd: 1008b5100900004cffffff000000 / 0101
2020-12-14 18:23:55.714 [bus debug] ERR: read timeout during receive command, switching to skip
2020-12-14 18:23:55.745 [main debug] performing regular tasks
2020-12-14 18:23:55.792 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:56.329 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:57.043 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:57.580 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:58.295 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:58.834 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:23:59.580 [update info] received MS cmd: 1008b5110101 / 094b414006496d0100ff
2020-12-14 18:23:59.847 [update info] received MS cmd: 1008b5100900004cffffff000000 / 0101
2020-12-14 18:24:05.745 [main debug] performing regular tasks
2020-12-14 18:24:07.950 [update info] received MS cmd: 1008b5110101 / 094b404006496d0100ff
2020-12-14 18:24:08.217 [update info] received MS cmd: 1008b5100900004cffffff000000 / 0101


Code Auswählen

2020-12-14 18:18:38.890 [update info] received MS cmd: 1008b512020064 / 00
2020-12-14 18:18:39.131 [update info] received MS cmd: 1008b5120204ff / 0101
2020-12-14 18:18:39.373 [update info] received MS cmd: 1008b513020508 / 00
2020-12-14 18:18:39.587 [update info] received BC cmd: 10feb510020601
2020-12-14 18:18:39.814 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:40.059 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:40.303 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:40.547 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:40.792 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:41.036 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:41.281 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:41.525 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:41.770 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:42.013 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:42.258 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:42.502 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:42.748 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:42.992 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:43.236 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:43.477 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:43.721 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:43.965 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:44.209 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:44.453 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:44.697 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:44.939 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:45.183 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:45.428 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:45.670 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:45.914 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:46.158 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:46.438 [update info] received MS cmd: 1008b5110101 / 094c4170064a6d0100ff
2020-12-14 18:18:46.706 [update info] received MS cmd: 1008b5100900004cffffff000000 / 0101
2020-12-14 18:18:46.935 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:47.180 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:47.424 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:47.631 [main debug] performing regular tasks
2020-12-14 18:18:47.667 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:47.912 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:48.156 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:48.400 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:48.645 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:48.890 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:49.134 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:49.379 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:49.624 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:49.868 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:50.112 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:50.357 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:50.599 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:50.844 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:51.089 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:51.333 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:51.578 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:51.822 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:52.066 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:52.311 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:52.555 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:52.800 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:53.044 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:53.288 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:53.532 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:53.777 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:54.019 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:54.264 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:54.508 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:54.751 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:54.958 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:55.489 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:55.732 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:55.976 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:56.054 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:56.725 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:57.306 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:57.978 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:58.733 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:18:59.521 [update info] received MS cmd: 1008b5110101 / 094c4170064a6d0100ff
2020-12-14 18:18:59.789 [update info] received MS cmd: 1008b5100900004cffffff000000 / 0101
2020-12-14 18:19:00.018 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:00.263 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:00.507 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:00.752 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:00.996 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:01.240 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:01.484 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:01.729 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:01.972 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 18:19:06.326 [update info] received MS cmd: 1008b5110101 / 094c4170064a6d0100ff

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Dezember 2020, 19:58:15
die blaue Led (https://adapter.ebusd.eu/picfirmware#led) zeigt die Kommunikation mit dem Pic an, kann aber je nach Betriebsart unterschiedlich sein. Leider hats du nicht geschrieben, wie du den Adapter betreibst, USB, Rpi, Wlan oder Ethernet.


Bist du sicher das du die Jumper (https://adapter.ebusd.eu/img/smd-jumper.png) deiner Betriebsart entsprechend richtig gesetzt hast?

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 14 Dezember 2020, 20:35:25
Zitat von: Reinhart am 14 Dezember 2020, 19:58:15
Bist du sicher das du die Jumper (https://adapter.ebusd.eu/img/smd-jumper.png) deiner Betriebsart entsprechend richtig gesetzt hast?
Betrieb aktuell per USB. Habe von den LED's auch ein Video gedreht falls man sich das Anschauen möchte.

Jeglicher scan command schlägt bei mir fehl. Liegt dies am anderen ebus-Device?
Es ist bisher immer ein ziemlich großer Zeitversatz (nicht nur Minuten) bis die devices hier komplett benannt werden.
Code Auswählen

scan.08  = no data stored
scan.15  = Vaillant;70000;0613;6903


Code Auswählen

2020-12-14 19:24:38.645 [network info] [00002] connection closed
2020-12-14 19:24:39.329 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:39.329 [update notice] received unknown MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:39.521 [network debug] dead connection removed - 0
2020-12-14 19:24:40.644 [main debug] performing regular tasks
2020-12-14 19:24:40.644 [bus info] scan 15 cmd: 3115070400
2020-12-14 19:24:48.124 [update info] received MS cmd: 1008b5110101 / 094d420006416b0100ff
2020-12-14 19:24:48.124 [update notice] received unknown MS cmd: 1008b5110101 / 094d420006416b0100ff
2020-12-14 19:24:48.124 [bus debug] start request 31
2020-12-14 19:24:48.124 [bus debug] arbitration start with 31
2020-12-14 19:24:48.177 [bus debug] arbitration won
2020-12-14 19:24:48.177 [bus debug] arbitration delay 275 micros
2020-12-14 19:24:48.177 [bus info] arbitration delay 275 - 375 micros
2020-12-14 19:24:48.177 [bus debug] switching from ready to send command
2020-12-14 19:24:48.188 [bus debug] notify request: ERR: read timeout
2020-12-14 19:24:48.188 [main error] scan config 15: ERR: read timeout
2020-12-14 19:24:48.188 [bus debug] ERR: read timeout during send command, switching to skip
2020-12-14 19:24:48.913 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:48.913 [update notice] received unknown MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:50.189 [main debug] performing regular tasks
2020-12-14 19:24:58.143 [update info] received MS cmd: 1008b5110101 / 094d420006416b0100ff




edit:
hier hat ebusd nach dem reload die Gerätedaten erhalten können (die vaillant csv files in den config ordner kopiert), allerdings ebenfalls erstmal ein timeout
Log ist um die update notice received unkown cmd gekürzt

Code Auswählen
2020-12-14 19:38:17.075 [network info] [00005] client connection opened 127.0.0.1
2020-12-14 19:38:17.075 [network debug] [00005] wait for result
2020-12-14 19:38:17.075 [main debug] >>> reload
2020-12-14 19:38:17.075 [main info] loading configuration files from /etc/ebusd
2020-12-14 19:38:17.075 [main info] reading templates /
2020-12-14 19:38:17.076 [main info] read templates in /
2020-12-14 19:38:17.076 [main info] reading file broadcast.csv
2020-12-14 19:38:17.077 [main info] successfully read file broadcast.csv
2020-12-14 19:38:17.077 [main info] reading file memory.csv
2020-12-14 19:38:17.078 [main info] successfully read file memory.csv
2020-12-14 19:38:17.078 [main info] read config files
2020-12-14 19:38:17.078 [main debug] <<< done
2020-12-14 19:38:17.079 [network info] [00005] connection closed
2020-12-14 19:38:17.486 [bus notice] new master 03, master count 2
2020-12-14 19:38:17.512 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:38:18.076 [network debug] dead connection removed - 0
2020-12-14 19:38:22.078 [main debug] performing regular tasks
2020-12-14 19:38:22.078 [bus info] scan 08 cmd: 3108070400
2020-12-14 19:38:22.572 [bus notice] new master 10, master count 3
2020-12-14 19:38:22.631 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:38:22.631 [bus debug] start request 31
2020-12-14 19:38:22.631 [bus debug] arbitration start with 31
2020-12-14 19:38:22.683 [bus debug] arbitration won
2020-12-14 19:38:22.683 [bus debug] arbitration delay 377 micros
2020-12-14 19:38:22.683 [bus info] arbitration delay 275 - 377 micros
2020-12-14 19:38:22.683 [bus debug] switching from ready to send command
2020-12-14 19:38:22.694 [bus debug] notify request: ERR: read timeout
2020-12-14 19:38:22.694 [bus debug] ERR: read timeout during send command, switching to skip
2020-12-14 19:38:22.694 [main error] scan config 08: ERR: read timeout
2020-12-14 19:38:23.303 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:38:23.874 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:38:24.695 [main debug] performing regular tasks
2020-12-14 19:38:24.695 [bus info] scan 15 cmd: 3115070400
2020-12-14 19:38:32.714 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:38:32.715 [bus debug] start request 31
2020-12-14 19:38:32.715 [bus debug] arbitration start with 31
2020-12-14 19:38:32.767 [bus debug] arbitration won
2020-12-14 19:38:32.767 [bus debug] arbitration delay 237 micros
2020-12-14 19:38:32.767 [bus info] arbitration delay 237 - 377 micros
2020-12-14 19:38:32.767 [bus debug] switching from ready to send command
2020-12-14 19:38:32.778 [bus debug] notify request: ERR: read timeout
2020-12-14 19:38:32.778 [bus debug] ERR: read timeout during send command, switching to skip
2020-12-14 19:38:32.778 [main error] scan config 15: ERR: read timeout
2020-12-14 19:38:33.504 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:38:33.757 [update info] received MS cmd: 1008b5110102 / 06033c9646826e
2020-12-14 19:38:34.779 [main debug] performing regular tasks
2020-12-14 19:38:42.770 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:38:42.770 [update notice] received unknown MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:38:43.038 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:38:44.779 [main debug] performing regular tasks
2020-12-14 19:38:52.827 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:38:53.094 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:38:54.779 [main debug] performing regular tasks
2020-12-14 19:39:02.891 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:39:03.159 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:39:03.434 [update info] received MS cmd: 1008b5040100 / 0a03053920141201200006
2020-12-14 19:39:03.690 [update info] received MS cmd: 1008b5110102 / 06033c9646826e
2020-12-14 19:39:03.928 [update info] received BC cmd: 10feb516080003392014120120
2020-12-14 19:39:04.192 [update info] received MS cmd: 1008b5110100 / 086b021426040f0081
2020-12-14 19:39:04.410 [update info] received BC cmd: 10feb51603010006
2020-12-14 19:39:04.653 [update info] received MS cmd: 1008b5100305ff01 / 0101
2020-12-14 19:39:04.780 [main debug] performing regular tasks
2020-12-14 19:39:04.889 [update info] received MS cmd: 1008b512020064 / 00
2020-12-14 19:39:05.131 [update info] received MS cmd: 1008b5120204ff / 0101
2020-12-14 19:39:05.372 [update info] received MS cmd: 1008b513020508 / 00
2020-12-14 19:39:05.584 [update info] received BC cmd: 10feb510020601
2020-12-14 19:39:07.435 [bus debug] ERR: read timeout during receive command, switching to skip
2020-12-14 19:39:07.514 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:08.052 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:08.764 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:09.302 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:10.016 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:10.555 [bus debug] ERR: read timeout during receive command ACK, switching to skip
2020-12-14 19:39:11.337 [update info] received MS cmd: 0315070400 / 0ab5373030303006136903
2020-12-14 19:39:11.337 [bus notice] scan 15: ;Vaillant;70000;0613;6903
2020-12-14 19:39:11.337 [update notice] store 15 ident: done
2020-12-14 19:39:12.948 [update info] received MS cmd: 1008b5110101 / 094d420006406b0100ff
2020-12-14 19:39:13.215 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:39:14.780 [main debug] performing regular tasks

An was liegt es dass das Gerät beim scannen nicht erkennbar wird?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Dezember 2020, 20:46:10
wie hast du denn die Adresse des ersten Adapters eingestellt, läuft der auch auf Adresse 31?

Poste doch bitte einmal die config und wenn möglich kannst du ein Foto der Platine machen?

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 14 Dezember 2020, 21:34:43
Addresse einstellen? Kompiliert laut Firmware Update und dieses mit make install ins system gebracht. Sonst nichts weiter.
Jetzt am experimentieren mit der ebusd-configuration (csv files), aber will irgendwie nicht.

3.3V und TX Header sind auf USB gebrückt. Auf J12 ist nichts gebrückt.
Habe versucht Screenshots zu machen in dem Video mit den unterschiedlichen LED Zuständen. Zustand Gelb Rot Grün war schwierig einzufangen
Screenshot_2020-12-14-21-17-26-902_com.miui.gallery -> direkt nachdem ebusd scan ausgeführt wird (Sendevorgang)
Screenshot_2020-12-14-21-17-04-544_com.miui.gallery -> direkt nachdem ebusd scan ausgeführt wird (Sendevorgang)
Screenshot_2020-12-14-21-20-01-565_com.miui.gallery -> zustand der LEDs vor und nach dem Senden


Jetzt habe ich den Adapter einmal Stromlos gemacht (auf USB Seite) und neu angeschlossen. Die Blaue LED leuchtet jetzt wieder nebst blinkender grünen LED.
5 Minuten später wieder kein Blau.

Nebenbei habe ich die hochfrequente Geräuschquelle ausmachen können. Im ganzen sind es 2. Eine Abhängigkeit der Frequenz konnte ich noch nicht finden, da jetzt der PEAK bei 17kHz liegt.
Es ist der C1 und der C4? (der Große am Sekundär VCC). Berührt man diese beiden mit einem härteren Gegenstand, so werden diese lauter.
Die Frequenz ist denke mal abhängig von der Stromversorgung.


edit:
ebusctl i liefert jetzt folgendes:
Code Auswählen
version: ebusd 3.4.v3.4-96-g96d5623
update check: revision v3.4 available
signal: acquired
symbol rate: 23
max symbol rate: 98
min arbitration micros: 280
max arbitration micros: 280
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=70000;SW=0613;HW=6903"
address 31: master #8, ebusd
address 36: slave #8, ebusd
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Dezember 2020, 21:50:07
mit Adresse einstellen meine ich die Adresse mit der sich der Adapter am eBus anmeldet!
Diese Adresse stellst du in der /etc/default/ebusd ein, wird nichts eingestellt so vergibt der Dämon die Adresse 31. Wenn du nun 2 Adapter am Bus angeschlossen hast, kollidieren die! Soweit du geschrieben hast, hast du 2 Adapter am eBus.

Code Auswählen
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:10.0.0.20:9999  --address=ff"
Besipiel, du vergibts die Adresse ff!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 14 Dezember 2020, 22:07:05
Zitat von: Reinhart am 14 Dezember 2020, 21:50:07
Code Auswählen
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:10.0.0.20:9999  --address=ff"
Besipiel, du vergibts die Adresse ff!

LG
Habe nur die eine Beta-Testplatine  ::)
aber der Command hat mir anscheinend schon weitergeholfen.
adress ist irrelevant. Allerdings hab ich mit dem latency Parameter anscheinend ins schwarze getroffen.
Die Heizung nebst Steuerung sind jetzt nicht einmal 30 Sekunden nach start des ebusd auflistbar.

Code Auswählen
$ ebusctl i
version: ebusd 3.4.v3.4-96-g96d5623
signal: acquired
symbol rate: 27
max symbol rate: 123
min arbitration micros: 247
max arbitration micros: 378
min symbol latency: 11
max symbol latency: 14
reconnects: 0
masters: 3
messages: 599
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" ([PROD='0010015596']), "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


Jetzt muss ich nur noch herausfinden wie ich die restlichen Werte in der Heizung (Brennerauslastung, Pumpenleistung, Wasserumlaufmenge, Anlagendruck, ...) erfassen kann
Code Auswählen
$ ebusctl find|grep -v "no data"
bai DateTime = sync;-:-:-;-.-.-;6.000
bai SetMode = auto;38.5;-;-;0;0;1;0;0;0
bai Status01 = 38.5;32.5;6.000;31.5;52.5;on
bai Status02 = auto;60;75.0;70;65.0
broadcast outsidetemp = 6.000
broadcast vdatetime = 22:03:31;14.12.2020
scan.08  = Vaillant;BAI00;0202;9602
scan.08 id = 21;17;39;0010015596;3100;008552;N9
scan.15  = Vaillant;70000;0613;6903
scan.15 id = 21;19;46;0020266797;0082;073259;N4
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Dezember 2020, 22:12:41
ja, sieht gut aus so!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 15 Dezember 2020, 07:36:09
Zitat von: JimKnopf am 14 Dezember 2020, 11:34:12
EDIT: nach einer Stunde betrieb, hier die Ausgaben:
Code Auswählen
pi@raspberrypi:~ $ $ ebusd -f -enh:192.168.2.190:9999 -l /var/log/ebusd.log --latency=20000 --address=01 --configpath=/etc/ebusd/de --accesslevel=* --mqttport=1883 --mqttjson --mqtthost=192.168.2.101 --mqtttopic=ebusd/%circuit/%name --pollinterval=10 --enablehex --enabledefine --log="all error"
2020-12-14 11:28:02.564 [update error] unable to parse scan-read scan.08  from ff08070400 / 0a500106334202091b5130: ERR: argument value out of valid range
...
2020-12-14 11:28:08.511 [mqtt error] decode scan.08 : ERR: argument value out of valid range
...
2020-12-14 11:31:46.975 [bus error] poll solar SolarErfolg failed: ERR: read timeout
...
2020-12-14 11:42:07.339 [bus error] device status: eBUS comm error: framing
2020-12-14 11:42:07.339 [bus error] arbitration start error


Im Vergleich zu Wifi kein nennenswerter Unterschied, TOP!  :D.
Ihr habt nen super Job gemacht! Danke!!
Danke  :D

Ich hab mal Deine error auf die unterschiedlichen runtergebrochen:
Sieht also in Summe erstmal in Ordnung aus.
Die letzte Firmware Version vom PIC (20201210) hast Du geflasht, richtig?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 15 Dezember 2020, 07:44:58
Zitat von: hErMeS am 14 Dezember 2020, 20:35:25
Code Auswählen

2020-12-14 19:24:38.645 [network info] [00002] connection closed
2020-12-14 19:24:39.329 [update info] received MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:39.329 [update notice] received unknown MS cmd: 1008b5100900004dffffff000000 / 0101
2020-12-14 19:24:39.521 [network debug] dead connection removed - 0
...

Du hast hier die "debug" Messages aktiviert, womit man ziehmlich "zugemüllt" wird und was ich für den normalen Betrieb nicht empfehlen würde.
Da ist dann auch die gesamte Statemachine mit dabei, die einen eben normalerweise nicht wirklich interessiert.
Deshalb die "debug" Messages am besten entweder deaktivieren oder ansonsten erstmal ignorieren, es sei denn ich frage danach  ;D

Zur blauen LED: die primäre Funktion ist im Moment, den Bootprozess des PIC zu visualisieren, damit man dafür den Einblick bekommt, was los ist.
Danach wird diese zu diversen Gelegenheiten getoggelt. Aber guter Punkt, das muss ich nochmal präzisieren, damit das auch Aussagekraft hat. Und dokumentieren - puh, das nimmt kein Ende  ;)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 15 Dezember 2020, 11:27:56
Was mir immer noch irgendwie sorgen bereitet ist das Pfeifen der ?Keramikkondensatoren?

Wenn dieses wahrnehmbar ist, ist ja dort eine Bewegung/Schwingung vorhanden (Piezo-Verhalten)
Reduziert sich hierdurch die Lebensdauer des Bauteiles? Evtl sogar der Lötstelle?

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 15 Dezember 2020, 17:26:47
Zitat von: john30 am 15 Dezember 2020, 07:36:09
Die letzte Firmware Version vom PIC (20201210) hast Du geflasht, richtig?


Hi John!

Ja, die letzte Firmware habe ich drauf, könnte ich noch mit in meine Signatur aufnehmen. Ist, glaube ich, eh eine gute Idee, wenn zumindest die Tester eine kurze Beschreibung ihrer Anlage in die Signatur schreiben.
Bin heute nicht dazu gekommen nochmal auf Wifi zu wechseln, aber macht ja nichts, läuft ja  ;D.
Edit: Die Timeouts habe ich auch mit dem Adapter 2.0 und natürlich auch "out of range" Fehler beim scannen.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 15 Dezember 2020, 23:39:39
so... meine Beta-Platine läuft jetzt endlich.
Löten war kein Problem - die falsch gelöteten LED habe ich NICHT korrigiert.

Hier meine Anmerkungen:

Die Bilder der Platine in fertig gelötetem Zustand sollten auch auf der https://adapter.ebusd.eu/ Seite eingebunden werden.

Dabei ist mir aufgefallen, dass das Bild https://adapter.ebusd.eu/img/smd-jumper.png irreführend/falsch ist. Laut dem Bild muss für den enhanced Modus bei J12 die Pins 1 und 2 gebrückt werden? Soweit ich den Text verstehe ist enhanced der neue "Standard" (d.h. ohne Brücke)

Evtl. hab ich was kaputt gemacht. Ich habe das Modul mit meinem PoE fähigen Switch verbunden. Strom habe ich über den USB Anschluss eingespeist.
Eigentlich dürfte hier ja nichts passieren. Geräte ohne PoE Fähigkeit sollen ja auch an PoE Ports funktionieren. Der PoE auf LAN/USB Splitter kommt erst morgen. Die blaue LED hat (soweit ich weiß) 4x geblinkt. danach nichts mehr. auch wenn ich die Platine ohne Ebus/Lan an USB anschließe leuchtet keine LED mehr. Hier werde ich die nächsten Tage noch mehr nachforschen. Hat jemand ideen, wie ich hier testen kann?

Also habe ich den Adapter auf Wifi umgebaut (Jumper umgesteckt). Hier kam zuerst keine Wifi-Verbindung zustande. Auf meinem Adapter Ebus-Adapter 2.0 hat die Verbindung stets funktiniert. Straht die neue Platine mehr Störsignale aus? Ich habe jetzt temporär eine Wlan-Sender neben den Adapter installiert (ein LAN Kabel habe ich ja... Damit ist auch das Kabel als Fehlerquelle ausgeschlossen).

Evtl. wäre es sinnvoll die Signalstärke im default auf "Hoch" zu stellen. Hat bei mir aber nicht ausgereicht...

Habt ihr eigentlich irgendwo geschrieben, dass die ESP Firmware eine neue Option bekommen hat, welche gesetzt werden muss?
Code Auswählen
eBUS RX+TX PINs: Adapter 3 RX+TX (GPIO3+1)
Falls ja hab ich es zunächst übersehen :-D

Soweit fürs erste... Mehr kommt noch
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 16 Dezember 2020, 04:18:59
Hi!
Ich finde das Bild mit den Jumpern recht eindeutig und habe meine Jumper auch genau so gesteckt.
Reinhard hat die Wemos vor Auslieferung geflasht, bei mir ging er leider auch nicht. Ich musste ihn neu flashen und hatte dann Probleme mit Resten im Speicher.
Es ist sinnvoll  ein flash-Programm zu nehmen, dass den Speicher komplett löscht. Siehe Post #30.

Wie ist denn jetzt Dein aktueller Stand? Du schreibst im ersten Satz die Platine läuft endlich und später dass nichts mehr blinkt. Die LED sind vor Auslieferung bereits korrigiert worden.
Es sind hier schon sehr viele Posts zusammengekommen, da kann es schnell passieren das man was übersieht.
Wenn ich das richtig verstanden habe:
Schritt 1: ebusd wie im Post #19 beschrieben kompilieren. Wenn möglich mit einem Adapter 2.0 - 2.2 testen.
Schritt 2: Adapter ohne Ethernet oder Wifi per USB mit Rechern/Raspberry verbinden. J4 muss auf USB gesteckt sein. Gelbe LED prüfen, blaue LED bewundern. Wenn gelb fehlt, prüfen ob Jumper J4 richtig gesetzt ist.
Schritt 2: Firmware des PIC aktualisieren, siehe Post #19!
Schritt 3: Adapter 3.0 mit Anlage verbinden, LEDs beobachten. Gelb: Stromversogung vorhanden, grün flackert: Daten auf dem ebus. Wenn gelb fehlt, prüfen ob Jumper J4 richtig gesetzt ist.
Schritt 4: Adapter 3.0 mit ebusd ansprechen
Bei Verbindung über Lan/Wlan beachten dass im enhanced Modus vor die IP des Adapters noch "enh:" gesetzt werden muss.
Bei Anbindung über den Wemos/Wifi muss die Stromversorgung an den Wemos angeschlossen werden und J4 auf RPI gesteckt werden (also NICHT auf USB).

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 06:54:12
Guten Morgen Burkhard,

Vielen Dank für deine Antwort. Und sorry, wenn mein letzter Post vielleicht etwas wirr ist. Gestern war ein langer Tag - ich wollte aber das wichtigste schonmal hier schreiben, dass ich nichts vergesse. Ich muss dir recht geben - Der Endzustand geht nicht deutlich genug hervor:
Die Platine läuft (im Sinnne von "Ebus Daten kommen in FHEM an").


Ich finde nicht, dass aus dem Bild hervorgeht, dass man für den enhanced Modus keinen Jumper setzt. Man kann das Bild auch so interpretieren, dass hier ein Jumper zu setzen ist.

Die Platine läuft seit gestern Abend/Nacht zuverlässig in folgendem Zustand: Power über USB, mein "alter" Wemos ohne umflaschen (von Platine 2.2 in Version 20201122 - ich hatte diese Version schon am laufen) im enhanced Modus. Dafür musste ich lediglich im ESP Webinterface die Konfigurationspunkte 5 (Adapter 3) und 6 (enhanced) ändern. Es leuchten die blauen LED (Wemos und Ebus-Platine)

Deine Aussage, dass die LEDs korrigiert wurden kann ich daher (bei mir) nicht bestätigen. Bei mir funktioniert nur die blaue LED.

Mein ursprünglicher Plan war es die Platine über LAN anzubinden. Das hat - wie ich geschrieben habe - nicht funktioniert. Auf die Fehlersuche gehe ich erst noch.

(ich habe deine Schritte neu nummeriert)
Schritt 1: hatte ich gestern tatsächlich gemacht. Leider ohne den Post #19 zu lesen - hätte mir vermutlich 20 Minuten Zeit gespart, das selbst rauszufinden...
Schritt 2: steht noch aus, ist bei mir nicht so einfach (Ort des EBUS Adapters). Was ich sagen kann: mit USB Power (ohne USB-Datenleitung) und mit/ohne EBUS-Leitung geht gar keine LED An :-(
Schritt 3: den Post habe ich komplett überlesen. Evtl. liegen meine Probleme hier dran. VIELEN DANK für den Hinweis!
Schritt 4: wie gesagt: alle LED (außer blau) bleiben dunkel. auch in diesem Szenario
Schritt 5: mit Wemos geht alles (außer die Lichtershow).

"enh:" hatte ich gesetzt.
Stromversorgung/Jumper habe ich immer 3x geprüft bevor ich getestet habe (bei sowas bin ich penibel)

Randnotiz:
da ich vermutete, dass der Wifi-Part des "neuen" Wemos evtl. schwächer ist habe ich meinen "alten" Wemos genommen. Heute abend werde ich den "neuen" Wemos testen. Ich erwarte aber, dass er geht da ich ihn im Wohnzimmer (stärkeres WLAN Signal) problemlos einbinden konnte. Schließlich habe ich direkt neben dem Ebus Adapter seit gestern Abend ein tiptop Wlan-Signal...

Meine nächsten Schritte

@John, Reinhard, chons, galileo: Für den alten Adapter hattet ihr Testpunkte für einen Multimeter angegeben. Gibt es das auch wieder?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Dezember 2020, 07:19:09
Zitat von: HeikoGr am 16 Dezember 2020, 06:54:12
Ich finde nicht, dass aus dem Bild hervorgeht, dass man für den enhanced Modus keinen Jumper setzt. Man kann das Bild auch so interpretieren, dass hier ein Jumper zu setzen ist.
Guten Moren Heiko,
das Bild habe ich kürzlich erneuert, aber dennoch ist es Absicht, dass an J12 die Verbindung Pin 1-2 mit enhanced protocol beschriftet ist, da wir es auch so ausliefern werden, anstatt den Jumper nur beizulegen und damit Verwirrung zu stiften.
In der PIC Firmware ist derzeit die Verbindung 1-2 irrelevant und lediglich 2-3 führt zu anderem Verhalten. Zu einem späteren Zeitpunkt (neuere Firmware) könnte sich das aber ändern.
D.h. im Moment kann man den Jumper auch weglassen, aber wie gesagt, wir liefern mit aus für (hoffentlich) weniger Fragen ala "wo soll denn der 4. Jumper hin?".

Zitat von: HeikoGr am 16 Dezember 2020, 06:54:12
Die Platine läuft seit gestern Abend/Nacht zuverlässig in folgendem Zustand: Power über USB, mein "alter" Wemos ohne umflaschen (von Platine 2.2 in Version 20201122 - ich hatte diese Version schon am laufen) im enhanced Modus. Dafür musste ich lediglich im ESP Webinterface die Konfigurationspunkte 5 (Adapter 3) und 6 (enhanced) ändern. Es leuchten die blauen LED (Wemos und Ebus-Platine)

Deine Aussage, dass die LEDs korrigiert wurden kann ich daher (bei mir) nicht bestätigen. Bei mir funktioniert nur die blaue LED.
Die LEDs habe ich bei meinen Testbelieferungen zuvor noch gedreht, bei Deiner Lieferung von Reinhart ist das m.W. nicht der Fall, d.h. es funktioniert nur die blaue.
Sorry wenn es hier Verwirrung gibt!

Zitat von: HeikoGr am 16 Dezember 2020, 06:54:12
Mein ursprünglicher Plan war es die Platine über LAN anzubinden. Das hat - wie ich geschrieben habe - nicht funktioniert. Auf die Fehlersuche gehe ich erst noch.
hier wäre natürlich gut, wenn wir noch rausbekommen, was hier schief geht.
PoE hat erstmal keine Auswirkung, wenn nicht die entsprechenden Leitungen am USR-ES1 manuell verkabelt werden.

Zitat von: HeikoGr am 16 Dezember 2020, 06:54:12
@John, Reinhard, chons, galileo: Für den alten Adapter hattet ihr Testpunkte für einen Voltmeter angegeben. Gibt es das auch wieder?
Wenn Du magst kannst Du die Finalisierungsschritte (https://adapter.ebusd.eu/finalization) anschauen, die ich eher für mich notiert hatte. Dort sind auch ein paar Spannungsbpegel notiert, die ich aber nochmal nachprüfen müsste.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 07:27:42
Zitat von: john30 am 16 Dezember 2020, 07:19:09
"wo soll denn der 4. Jumper hin?".

Dann schuldet Reinhart mir strenggenommen noch einen 4. Jumper - bei mir waren nur 3 dabei :-D
Also die Firmware bitte, bitte nicht ändern, bis ich in meiner Bastelkiste einen neuen/alten Jumper gefunden habe!

LAN will ich auch unbedingt zum laufen bekommen. Ich wollte nur gestern abend alles andere (LanKabel, PIC, EBUS, USB-Power) als Fehlerquelle ausschließen und habe auf Wemos umgebaut. Zielbild ist immer noch LAN mit PoE. Die Finalisierungsschritte helfen mir dabei evtl. auch. Vielen Dank!



Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Dezember 2020, 07:28:52
Zitat von: HeikoGr am 15 Dezember 2020, 23:39:39
Die Bilder der Platine in fertig gelötetem Zustand sollten auch auf der https://adapter.ebusd.eu/ Seite eingebunden werden.
richtig, dafür habe ich mir TODO's in die Doku notiert.

Zitat von: HeikoGr am 15 Dezember 2020, 23:39:39
Die blaue LED hat (soweit ich weiß) 4x geblinkt. danach nichts mehr. auch wenn ich die Platine ohne Ebus/Lan an USB anschließe leuchtet keine LED mehr. Hier werde ich die nächsten Tage noch mehr nachforschen. Hat jemand ideen, wie ich hier testen kann?
Nutzt Du DHCP oder eine feste IP?

Zitat von: HeikoGr am 15 Dezember 2020, 23:39:39
Straht die neue Platine mehr Störsignale aus? Ich habe jetzt temporär eine Wlan-Sender neben den Adapter installiert (ein LAN Kabel habe ich ja... Damit ist auch das Kabel als Fehlerquelle ausgeschlossen).
ich habe eher das Gefühl, dass die neue Charge an Wemos deutlich schlechtere Verbindung zum WLAN hat. Selbst ohne Adapter drunter hab ich an gleicher Position zuweilen schlechtere Verbindung. Ich bin noch nicht dazu gekommen, das final zu testen (z.B. alte Firmware auf neuen Wemos und mal ein anderes/älteres SDK verwenden).

Zitat von: HeikoGr am 15 Dezember 2020, 23:39:39
Evtl. wäre es sinnvoll die Signalstärke im default auf "Hoch" zu stellen. Hat bei mir aber nicht ausgereicht...
im Prinzip ja, aber ich hätte nur ungern einen Adapter, der per se erstmal mehr strahlt als vielleicht unbedingt notwendig.

Zitat von: HeikoGr am 15 Dezember 2020, 23:39:39
Habt ihr eigentlich irgendwo geschrieben, dass die ESP Firmware eine neue Option bekommen hat, welche gesetzt werden muss?
Code Auswählen
eBUS RX+TX PINs: Adapter 3 RX+TX (GPIO3+1)
Das ist bei Dir jetzt evtl. ein spezielles Szenario, da wir die Adapter ja künftig fix und fertig ausliefern, also inkl. geflashtem Wemos.
Aber ja, es ist im Changelog (https://github.com/john30/ebusd-esp/blob/master/Changelog.md#build-20201120) notiert. Vielleicht sollte das noch in die Adapter 3 Doku.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 07:36:50
Zitat von: john30 am 16 Dezember 2020, 07:28:52
Nutzt Du DHCP oder eine feste IP?

DHCP (FritzBox Cable 6591)

Zitat von: john30 am 16 Dezember 2020, 07:28:52
ich habe eher das Gefühl, dass die neue Charge an Wemos deutlich schlechtere Verbindung zum WLAN hat. Selbst ohne Adapter drunter hab ich an gleicher Position zuweilen schlechtere Verbindung. Ich bin noch nicht dazu gekommen, das final zu testen (z.B. alte Firmware auf neuen Wemos und mal ein anderes/älteres SDK verwenden).

Das habe ich auch schon mehrfach im Netz gelesen - daher habe ich auch meinen "alten" Wemos zur Gegenprobe genommen. Leider zunächst ohne Erfolg. Mit altem Ebus-Adapter habe ich (mit "altem" Wemos) eine Wlan Verbindung gehabt - mit neuem Ebus-Adapter und "altem" Wemos nicht mehr. Daher meine Frage zur Störstrahlung.

Gelöst habe ich das Problem - wie bereits geschrieben - mit einem neuen Wifi-Mesh Knoten direkt neben dem Ebus-Adapter.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 11:04:30
Betreffend der Wemos habe ich gestern schon eine Galerie mit Antenne bekommen die ich gerade teste. Das Signal verbessert sich dabei spürbar, aber die neuen Typen von "Wemos" erreichen nicht mehr die RSSI Werte der alten, das haben wir bereits festgestellt. Es spricht daher nichts dagegen, wenn ihr alte besitzt diese weiter zu verwenden, aber UNBEDINGT die neue Firmware esp3 drauf flashen!

Wichtig: der 0 Ohm Widerstand muss von der internen auf die externe Antenne umgelegt werden! So wie im letzten Bild nach unten, also 90 Grad drehen! Im oberen Bild steht er noch auf interner Antenne!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 11:27:32
Test bei gleichem Standort am Wemos betrachtet:

Wemos ohne Ant. Signal 78%  -61dBm
Wemos mit   Ant .Signal 100%  -45dBm

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 16 Dezember 2020, 14:52:17
Hi@all.
Heute ist das Set angekommen. Poststempel vom 03.12.20.
Da hat die Post sich aber Zeit gelassen :)

Jetzt geht es erstmal ans löten...
Die 3 Led´s drehe ich zuerst. (Set von Reinhart)(ist aber nicht schlimm)

mfg Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 16:56:26
Bitte bei dem RPI Connector aufpassen, verkehrt rum einlöten, Steckverbindung unten!

Ja die Post, bei 1,3 Millionen Pakete täglich geht ihnen die Luft aus!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 17:12:00
Zitat von: JimKnopf am 16 Dezember 2020, 04:18:59
Reinhard hat die Wemos vor Auslieferung geflasht, bei mir ging er leider auch nicht. Ich musste ihn neu flashen und hatte dann Probleme mit Resten im Speicher.
Es ist sinnvoll  ein flash-Programm zu nehmen, dass den Speicher komplett löscht. Siehe Post #30.

Ja das ist komisch, ich habe geflasht und dann am AP mit Browser auf 192.168.4.1 angemeldet, eingestellt habe ich natürlich nix weil ich ja die Credentials von euch nicht kenne.
Aber so ist es richtig wenn keine Kommunikation möglich ist, alles löschen und neu flashen!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:15:44
kurzes Update zu meinem Ethernet Problem.

Wenn ich den Ebus Adapter in den Flash-Mode versetzen möchte leuchtet keine blaue LED. Bei Stromversorgung via Wemos leuchtet die blaue LED.
Habe ich meinen USB Host-Chip gegrillt?? Kann ich diesen auch umgehen um den PIC neu zu programmieren?

Arduinos und/oder ein FTDI Board sind vorhanden.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Dezember 2020, 17:19:11
Zitat von: HeikoGr am 16 Dezember 2020, 17:15:44
Wenn ich den Ebus Adapter in den Flash-Mode versetzen möchte leuchtet keine blaue LED. Bei Stromversorgung via Wemos leuchtet die blaue LED.
has Du J1+J4 entsprechend auf USB gestellt und USR-ES1 + Wemos entfernt?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:19:55
Ja
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Dezember 2020, 17:21:31
Zitat von: HeikoGr am 16 Dezember 2020, 17:19:55
Ja
Und für Flash Mode am PROG (!) Jumper die Pins 3+4 verbunden, bevor die Spannungsversorgung angeschlossen wurde?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:23:04
ja, auch das hab ich gemacht.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:24:40
per USB an Raspberry angeschlossen.
- lsusb zeigt kein (passendes) Device

Code Auswählen
ebuspicloader -f 20201210-offset.hex  /dev/ttyUSB0
unable to open /dev/ttyUSB0


:-\
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 16 Dezember 2020, 17:39:20
Ich hatte das auch. Bis ich draufgekommen bin dass das Kabel, welches ich vom Ladegerät genommen habe :-) nur die Versorgung aber keine Datenleitungen hatte...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:41:05
Ich habe verschieden Kabel ausprobiert.
Die blaue LED müsste doch trotzdem in jedem Fall leuchten, oder?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Dezember 2020, 17:43:56
Zitat von: HeikoGr am 16 Dezember 2020, 17:24:40
per USB an Raspberry angeschlossen.
- lsusb zeigt kein (passendes) Device

Code Auswählen
ebuspicloader -f 20201210-offset.hex  /dev/ttyUSB0
unable to open /dev/ttyUSB0

kannst du mal schauen, ob die Pins 2 +3 am J4 verlötet sind? die sehen so "trocken" aus.
Sonst miss doch mal GND vom USB Stecker gegen J4 Pin 3. Dort sollten 3,3V anliegen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 17:59:31
Einen Lötfehler kann ich nicht ausschließen.
Ich löte heute abend mal nach. Auch von der anderen Seite.

Zum messen komm ich erst, wenn die Brut im Bett liegt...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 19:31:53
J12 sieht etwas mager gelötet aus, aber sonst dürfte es passen.
Du hast ja die Platine schon erfolgreich in Variante USB und Wemos in Betrieb gehabt!

Versuche doch noch einmal in reinen USB Betrieb zu gehen, aber solange "lsusb" kein Ergebnis liefert hast den CP2102 vermutlich doch beleidigt, obwohl die Dinger einiges aushalten. Und ja, das mit den USB Kabeln hatte ich auch schon mehrmals, weil du von außen nie erkennst ob die Data Verbindungen auch durchgeschliffen sind.
Jetzt wäre natürlich gut, wenn auch die grüne Led funktionieren würde.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 19:36:12
Nein, USB hatte ich noch nicht in Betrieb.

An das umlöten von 3 SMD Leds trau ich mich nicht. Ich habe es schonmal probiert und einen einzelnen SMD Widerstand gelötet - hat ewig gedauert. Und da war mehr Platz!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 16 Dezember 2020, 19:37:31
ich habs mit 2 kleinen Lötkolben gleichzeitig gemacht, ist aber fuselig.

Aber "lsusb" genügt ja auch!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 16 Dezember 2020, 19:58:29
Zitat von: HeikoGr am 16 Dezember 2020, 17:41:05
Ich habe verschieden Kabel ausprobiert.
Die blaue LED müsste doch trotzdem in jedem Fall leuchten, oder?

In deinem Foto fehlt die Brücke für die 3.3V Versorgung von USB. Eventuell vergessen bzw Brücke im eBUS Teil gesteckt? (Da Reinhart eine weniger geliefert hat)
Dann würde das vermutlich klar seien wieso das nicht erkannt wird, aber die 3.3V vom WEMOS kommen können
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: McFire am 16 Dezember 2020, 22:38:43
Hi Reinhart, ich habe auch großes Interesse an dem 3er EBUS Adapter in Verbindung mit dem esp wifi wemos.

Eine wichtige Sache. Wenn du eine Antenne mit den Dingern nutzen möchtest musst du den 0 Ohm Widerstand um 90 Grad g.d. Uhrzeigersinn drehen und neu verlöten damit das Signal am ipex Stecker ankommt. Auf den Beispiel Bildern geht das Signal noch zur Onboard Antenne.

Viele Grüße
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 22:42:06
Zitat von: hErMeS am 16 Dezember 2020, 19:58:29
In deinem Foto fehlt die Brücke für die 3.3V Versorgung von USB.

Meinst du das Foto mit dem schwarzen Hintergrund? Hier läuft die Platine im Wifi Betrieb mit Wemos. Das Bild habe ich zum zeigen der Lötstellen aufgenommen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 22:49:16
So, ich habe ein bisschen weiter getestet.

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 16 Dezember 2020, 23:04:11
anbei meine Rückmeldung zum LAN-Part

DCHP Request erfolgt nur beim Einschalten der Platine.
Einen Renew konnte ich mit Deaktivieren des Switch-Ports (was dem Ziehen vom LAN-Kabel gleich kommt) nicht provozieren.
Hier müsste der Link gegengecheckt werden und bei wieder vorhandenem Link ein Renew des DHCP Lease / reinitialisierung PIC erfolgen. Nicht durch ziehen der Stromversorgung der ebus Platine.

Das ist mir aufgefallen, da ich MAC-VLAN auf dem Switch nutze und ich anschließend nach Reset vom Port keinen neuen Lease angefordert bekam. Auch nochmals mit Port Mirroring gegengeprüft.

Wird überhaupt die Gültigkeit des DHCP Lease mit dem PIC beachtet und vor Ablauf neu angefragt?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 16 Dezember 2020, 23:31:02
Hallo HeikoGr,

hast du mal ein anderes USB Kabel getestet?
Ich habe bestimmt 4 Kabel bei denen die zwei Datenadern nicht durchgeschaltet sind und daher nur zur Stromversorgung geeignet sind.
Jedes mal eine Sucherei nach dem einen was Vollbeschaltung hat.

Zeigt sich der D1 Mini am USB / lsusb? Wenn nicht scheint dies direkt auf das USB Kabel zu zeigen. Wäre noch ein Versuch das Kabel auszuschließen.

Gruß
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 16 Dezember 2020, 23:47:19
Das Kabel ist sicher nicht die Ursache:

Ich bin mir mittlerweile sehr sicher, dass ich hier etwas gegrillt habe:
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 06:37:03
Wenn ich mir den Schaltplan (https://adapter.ebusd.eu/img/smd-circuit.png) anschaue müsste die RPI Schaltung funktionieren, wenn die Wemos Variante läuft, oder?
Ich werde die RPI Schaltung heute abend noch einmal in Angriff nehmen.

Alternativ: spricht was dagegen, wenn ich die 3,3 V andersweitig zuführe um den LAN Adapter zu testen? Der USB Anschluss wird bei der LAN Variante "nur" für die Stromversorgung genutzt, oder?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 07:38:21
Zitat von: HeikoGr am 17 Dezember 2020, 06:37:03
Wenn ich mir den Schaltplan (https://adapter.ebusd.eu/img/smd-circuit.png) anschaue müsste die RPI Schaltung funktionieren, wenn die Wemos Variante läuft, oder?
richtig

Zitat von: HeikoGr am 17 Dezember 2020, 06:37:03
Alternativ: spricht was dagegen, wenn ich die 3,3 V andersweitig zuführe um den LAN Adapter zu testen? Der USB Anschluss wird bei der LAN Variante "nur" für die Stromversorgung genutzt, oder?
spricht nichts dagegen, das geht natürlich auch

hattest du denn die PIC Firmware schon mal geflasht? dann hätte da ja noch alles funktioniert
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 07:39:02
Update

RPI Variante funktioniert auch.

Was war mein Fehler? Reinhart hat ganz am Anfang geschrieben, das "ttyAMA0" aktiviert sein muss. => Ja, war aktiv ("ls /dev/ttyAMA*" gibt "/dev/ttyAMA0" aus)
Nur ist mir heute morgen (ganz klassisch beim duschen) eingefallen, dass hier ja noch Default mässig die Console draufliegt und für einen vollwertigen UART das BT-Overlay "miniuart-bt" aktiviert werden muss...

Das muss unbedingt noch im WIKI ergänzt werden. galileo hat auf Github beim ttyEBUS Treiber ja eine schöne Anleitung dazu.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 07:44:51
Zitat von: john30 am 17 Dezember 2020, 07:38:21
hattest du denn die PIC Firmware schon mal geflasht? dann hätte da ja noch alles funktioniert

nein... leider noch nicht. Wie bereits geschrieben vermute ich, dass der CP2102 gleich zu anfang einen Schaden genommen hat.

Kann ich die PIC Firmware auch über RPI und ttyAMA0 flashen?
Oder kann ich einen FTDI nutzen? Das einzig fummelige wäre hierbei PIN5 beim IC3 abzugreifen... Oder liege ich hier komplett falsch?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 08:02:24
Zitat von: HeikoGr am 17 Dezember 2020, 07:44:51
nein... leider noch nicht. Wie bereits geschrieben vermute ich, dass der CP2102 gleich zu anfang einen Schaden genommen hat.

Kann ich die PIC Firmware auch über RPI und ttyAMA0 flashen?
ja das sollte auch gehen, hat aber m.W. noch keiner probiert.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 08:07:15
spricht was dagegen, wenn ich es versuche?
Ich möchte das jetzt nicht auf eigene Faust ohne Rücksprache machen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 08:08:30
Zitat von: HeikoGr am 17 Dezember 2020, 08:07:15
spricht was dagegen, wenn ich es versuche?
Ich möchte das jetzt nicht auf eigene Faust ohne Rücksprache machen.
nö, mach ruhig. wichtig ist dann natürlich, v.a. J4 auf RPI zu stecken. J1 muss auch auf RPI, damit der TX Zweig passt.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 08:16:04
Ok. Das teste ich heute abend. Komm jetzt nicht an das Gerät und somit den jumper zum flashen dran.

Das die RPI variante bei mir läuft ist auch nur die halbe wahrheit.

Code Auswählen
version: ebusd 3.4.v3.4-96-g96d5623
update check: revision v3.4 available
signal: acquired
symbol rate: 23
max symbol rate: 97
min arbitration micros: 5
max arbitration micros: 5
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

Ich habe ein Signal, aber es fehlen mir die Geräte...

Config:
Code Auswählen
EBUSD_OPTS="-d enh:/dev/ttyAMA0 --scanconfig"

Der Raspi hat eine funktionierende Internetverbindung
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 08:26:15
Zitat von: HeikoGr am 17 Dezember 2020, 08:16:04
Das die RPI variante bei mir läuft ist auch nur die halbe wahrheit.
da musste mal in ebusd log file schauen
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 08:31:43
gerne:
Code Auswählen
2020-12-17 07:24:52.057 [main notice] update check: revision v3.4 available
2020-12-17 07:24:54.165 [update notice] received unknown MS cmd: 1008b51009000096ffffff000000 / 0101
2020-12-17 07:25:04.195 [update notice] received unknown MS cmd: 1008b51009000096ffffff000000 / 0101
2020-12-17 07:25:04.453 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:25:14.265 [update notice] received unknown MS cmd: 1008b51009000096ffffff000000 / 0101
2020-12-17 07:25:24.339 [update notice] received unknown MS cmd: 1008b51009000096ffffff000000 / 0101
2020-12-17 07:25:34.901 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:25:44.158 [update notice] received unknown MS cmd: 1008b5110101 / 098f7ad0085a620000ff
2020-12-17 07:25:54.224 [update notice] received unknown MS cmd: 1008b5110101 / 098576d0085a620000ff
2020-12-17 07:26:04.302 [update notice] received unknown MS cmd: 1008b5110101 / 097f71d0085a620000ff
2020-12-17 07:26:04.832 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:26:35.201 [update notice] received unknown MS cmd: 1008b5110101 / 09726ad00859620000ff
2020-12-17 07:26:36.001 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:26:36.964 [update notice] received unknown MS cmd: 1008b5100305ff01 / 0101
2020-12-17 07:26:37.201 [update notice] received unknown MS cmd: 1008b512020064 / 00
2020-12-17 07:26:37.438 [update notice] received unknown MS cmd: 1008b5120204ff / 0101
2020-12-17 07:26:37.677 [update notice] received unknown MS cmd: 1008b513020508 / 00
2020-12-17 07:26:44.745 [update notice] received unknown MS cmd: 1008b5110101 / 096f68d00859620000ff
2020-12-17 07:27:04.611 [update notice] received unknown MS cmd: 1008b5110101 / 096b66d00859620000ff
2020-12-17 07:27:05.141 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:27:14.676 [update notice] received unknown MS cmd: 1008b5110101 / 096a65d00859620000ff
2020-12-17 07:27:34.775 [update notice] received unknown MS cmd: 1008b5110101 / 096864d00859620000ff
2020-12-17 07:27:35.578 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:27:36.086 [update notice] received unknown MS cmd: 1008b5110100 / 084003170007080082
2020-12-17 07:27:44.840 [update notice] received unknown MS cmd: 1008b5110101 / 096763d00859620000ff
2020-12-17 07:28:05.513 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:28:35.148 [update notice] received unknown MS cmd: 1008b5110101 / 096462d00858620000ff
2020-12-17 07:28:35.952 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:28:36.455 [update notice] received unknown MS cmd: 1008b5110100 / 082603170007080082
2020-12-17 07:28:45.174 [update notice] received unknown MS cmd: 1008b5110101 / 096462d00858620000ff
2020-12-17 07:28:55.248 [update notice] received unknown MS cmd: 1008b5110101 / 096462d00858620000ff
2020-12-17 07:29:05.852 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:29:35.459 [update notice] received unknown MS cmd: 1008b5110101 / 096462d00857620000ff
2020-12-17 07:29:36.002 [update notice] received unknown MS cmd: 1008b5040100 / 0a0336290817120420d008
2020-12-17 07:29:36.263 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:29:36.765 [update notice] received unknown MS cmd: 1008b5110100 / 082103170007080082
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 08:32:56
Zitat von: HeikoGr am 17 Dezember 2020, 08:31:43
gerne:
Code Auswählen
2020-12-17 07:24:52.057 [main notice] update check: revision v3.4 available
2020-12-17 07:24:54.165 [update notice] received unknown MS cmd: 1008b51009000096ffffff000000 / 0101
...

da brauch ich dann aber schon alles, also vor allem den anfang, wenn die scans losgehen.
kannst mir auch gern per PM/mail schicken
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 08:36:59
Ich hab die log Datei mal geleert und den Service neu gestartet:

Code Auswählen
2020-12-17 07:34:21.777 [main notice] ebusd 3.4.v3.4-96-g96d5623 started with auto scan
2020-12-17 07:34:21.952 [bus notice] bus started with own address 31/36
2020-12-17 07:34:21.978 [bus notice] signal acquired
2020-12-17 07:34:22.438 [bus notice] device status: reset
2020-12-17 07:34:25.043 [bus notice] new master 03, master count 2
2020-12-17 07:34:27.028 [bus notice] new master 10, master count 3
2020-12-17 07:34:27.090 [update notice] received unknown MS cmd: 1008b5110101 / 095d5cd00854610000ff
2020-12-17 07:34:37.157 [main error] scan config 08: ERR: read timeout
2020-12-17 07:34:38.420 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:34:38.920 [update notice] received unknown MS cmd: 1008b5110100 / 08e802170007080082
2020-12-17 07:34:47.204 [update notice] received unknown MS cmd: 1008b5110101 / 095c5bd00854610000ff
2020-12-17 07:34:47.223 [main error] scan config 15: ERR: read timeout
2020-12-17 07:35:07.303 [update notice] received unknown MS cmd: 1008b5110101 / 095c5ad00853610000ff
2020-12-17 07:35:07.833 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:35:38.313 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:35:47.570 [update notice] received unknown MS cmd: 1008b5110101 / 095b59d00853610000ff
2020-12-17 07:36:08.186 [update notice] received unknown MS cmd: 1008b5110102 / 06033c9646826e
2020-12-17 07:36:17.721 [update notice] received unknown MS cmd: 1008b5110101 / 095a59d00852610000ff
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 08:38:30
Zitat von: HeikoGr am 17 Dezember 2020, 08:36:59
Ich hab die log Datei mal geleert und den Service neu gestartet:

Code Auswählen
2020-12-17 07:34:21.777 [main notice] ebusd 3.4.v3.4-96-g96d5623 started with auto scan
...
2020-12-17 07:34:37.157 [main error] scan config 08: ERR: read timeout
...

sieht aus als könnte nichts auf den bus geschrieben werden. hast du den TX Jumper J1 richtig gesetzt?[/code]
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 08:43:14
Ich denke schon. Ich habe heute früh von wemos auf rpi umgebaut und nur den Strom Jumper umgesteckt.  Sicher kann ich dir das erst heute nachmittag beantworten.

Dann weiss ich wenigstens wo ich weitermachen kann. Danke!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 17 Dezember 2020, 08:48:50
Zitat von: McFire am 16 Dezember 2020, 22:38:43
Hi Reinhart, ich habe auch großes Interesse an dem 3er EBUS Adapter in Verbindung mit dem esp wifi wemos.

Eine wichtige Sache. Wenn du eine Antenne mit den Dingern nutzen möchtest musst du den 0 Ohm Widerstand um 90 Grad g.d. Uhrzeigersinn drehen und neu verlöten damit das Signal am ipex Stecker ankommt. Auf den Beispiel Bildern geht das Signal noch zur Onboard Antenne.

Viele Grüße

Danke für den Hinweis, habe die Dinger auch das erste Mal in der Hand und wenn man sie mit der Lupe betrachtet ist das klar. Also Default werden sie für die interne Antenne ausgeliefert. Durch das Umlegen des Widerstandes ist das Signal auf 100% angestiegen!
Habe die Fotos und den Thread korrigiert!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 17 Dezember 2020, 11:23:53
so manch einer kann sich da noch erinnern als der eBus laufen lernte!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 17 Dezember 2020, 12:13:32
Wow, Reinhart, dass du dir das aufgehoben hast...
Rechts oben sieht man den ersten Versuch vom eBUSAdapter 3.0 auf Lochraster. Ist schon so lange her...
Drunter den jetzigen 3.0 Print mit den (leider) verdrehten LEDs.
Und auch sonst können wir bald ein Museum aufmachen.
Danke an alle die da die letzten Jahre mitgezogen sind.
Ich finde es toll dass es hier soetwas wie eine "Open Source" Scene gibt, wo alle davon profitieren.
Frohe Weihnachten an alle und möge das Jahr 2021 besser sein als dieses verunglückte 2020.
LG
Eduard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Lafarik am 17 Dezember 2020, 12:30:05
Hi Burkhard,

ich wäre sehr dran interessiert. Bitte per PM Zahlungsdaten.
Gruß,
Georg
Edit: Wie oben von JimKnopf schon erwähnt, hab gedacht es geht um den 3.0. Also doch noch warten. Also währe der wieder verfügbar...

Zitat von: JimKnopf am 17 Dezember 2020, 12:19:53
Hi!
Mein Adapter 3.0 läuft bislang perfekt. Hat Ihr noch Vergleiche mit dem alten Adapter vor? Falls nicht würde ich den jetzt für 15 € an einen ungeduldigen abgeben.
Ich habe ja auch noch die Bauteile für einen weiteren 2.2 Adapter. Den könnte ich zusammen klöpeln und ebenfalls für 15 € abgeben.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 17 Dezember 2020, 13:01:05
Zitat von: HeikoGr am 17 Dezember 2020, 08:16:04
Das die RPI variante bei mir läuft ist auch nur die halbe wahrheit.

Code Auswählen
version: ebusd 3.4.v3.4-96-g96d5623
update check: revision v3.4 available
signal: acquired
symbol rate: 23
max symbol rate: 97
min arbitration micros: 5
max arbitration micros: 5
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

Ich habe ein Signal, aber es fehlen mir die Geräte...

Config:
Code Auswählen
EBUSD_OPTS="-d enh:/dev/ttyAMA0 --scanconfig"

Setz Mal in die ebusd_opts noch
Code Auswählen

--latency=20000

Das war bei mir der ausschlaggebende Parameter. Sieht bei dir nach Vaillant aus.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 13:13:26
Zitat von: JimKnopf am 17 Dezember 2020, 13:10:25
2.2 Platinen waren leider nicht mehr verfügbar, deswegen habe ich selbst gefädelt. Den 2. Bausatz könnte ich dementsprechend auch nur eine Lochrasterplatine beilegen.
Könnt ihr bitte "Verkaufsgespräche" in privat verlegen? Es ist hier fehl am Platz und eh schon mühsam bei all den Nachrichten noch hinterher zu kommen...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 17 Dezember 2020, 13:19:18
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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 13:20:38
Zitat von: JimKnopf am 17 Dezember 2020, 13:19:18
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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 13:43:06
Zitat von: hErMeS am 17 Dezember 2020, 13:01:05
Setz Mal in die ebusd_opts noch
Code Auswählen

--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)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Dezember 2020, 13:46:41
Zitat von: HeikoGr am 17 Dezember 2020, 13:43:06
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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 13:57:26
Raspi OS mit Kernel 5.4.79-v7+ (tagesaktuell)

Code Auswählen

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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 17 Dezember 2020, 14:50:13
Hi!

Ich habe momentan recht oft "signal lost". Bin versucht parallel doch nochmal den 2.2 Adapter dran zu hängen.
Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 17 Dezember 2020, 15:54:58
Gute Neuigkeiten!

Das flashen des PIC über den aufgestecken Raspi per

Code Auswählen
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
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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 17 Dezember 2020, 16:46:20
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 (https://secure.reichelt.at/at/de/ntc-thermistor-10-kohm-0-2--ntc-10k-0-2-p151255.html?&trstct=pol_2&nbc=1) 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
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
{"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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 17 Dezember 2020, 21:48:12
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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 18 Dezember 2020, 08:09:29
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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 08:37:27
Hier mein aktueller Stand


VarianteStatusoffen
USBdefekt?Leiterbahnen check, USB geht in Schutzschaltung?
Raspberryfunktioniert, fiepthier will ich dem fiepen nachgehen. klingt vergleichbar zu den Angaben von hErMeS
LANfunktionertPoE Adapter
Wififunktionert

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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 18 Dezember 2020, 09:06:51
Zitat von: hErMeS am 18 Dezember 2020, 08:09:29
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

Zitat von: hErMeS am 18 Dezember 2020, 08:09:29
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?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 18 Dezember 2020, 09:18:25
Zitat von: HeikoGr am 18 Dezember 2020, 08:37:27
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  ::)

Zitat von: HeikoGr am 18 Dezember 2020, 08:37:27
Kann ich hierbei helfen?
klar, ich muss nur mal den push an github machen, dann landet der aktuelle Stand hier (https://github.com/eBUS/adapter).

Zitat von: HeikoGr am 18 Dezember 2020, 08:37:27
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?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 18 Dezember 2020, 09:40:26
Zitat von: john30 am 18 Dezember 2020, 09:06:51
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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 18 Dezember 2020, 09:43:52
Zitat von: hErMeS am 18 Dezember 2020, 09:40:26
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?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 18 Dezember 2020, 09:56:48
Toten Stille traf es nicht, war ja weiterhin mit seiner alten IP erreichbar.
Das Lease müsste sich trotzdem erneuern im Falle von DHCP.
Fixed ist was anderes, dynamic sollte dementsprechend behandelt werden.
Im DHCP Mal schnell eine IP ändern ist ja schnell gemacht. Dementsprechend sollte auch die neue IP bezogen werden. Zugriff erfolgt mit DNS Namen anstatt fester IP bei mir im Netz.

Wenn jemand einen Router tauscht und hierdurch andere Subnetze genutzt werden, muss man zwingend den eBus Adapter neu bestromen. Ist in meinen Augen nicht sehr Consumer freundlich wenn man weiß jedes Gerät holt sich seine neuen Adressen von selbst. Naja, ist auch nicht wirklich ein Consumer Gerät  ::)
Ich sehe es als gravierenden Fehler in der Protokoll Implementierung bzw verhalten an da es nicht dem normalen Verhalten entspricht und auch mich ins Grübeln brachte
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 18 Dezember 2020, 12:35:44
Einstellungen am Raspi betreffend dem USB + Rpi Betrieb!

Bitte "raspi-config" aufrufen und die seriellen Einstellungen checken, siehe dazu die Bilder unten. Dann Kontrolle der config.txt und der cmdline.txt.
Bitte auch unbedingt den ttyebus Treiber sofern dieser für die Version 2.x installiert wurde.

Code Auswählen
cd ~/ttyebus
sudo make uninstall

Code Auswählen
### config.txt ###
[all]
enable_uart=1
dtoverlay=pi3-miniuart-bt

### cmdline.txt ###
console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes root   
relevante Einstellung der config.txt und cmdline.txt ( console ) .

Code Auswählen
### ls -al /dev ###
crw--w----  1 root tty       4,   7 Dez 14 21:17 tty7
crw--w----  1 root tty       4,   8 Dez 14 21:17 tty8
crw--w----  1 root tty       4,   9 Dez 14 21:17 tty9
crw-rw----  1 root dialout 204,  64 Dez 14 21:17 ttyAMA0
crw-------  1 root root      5,   3 Dez 14 21:17 ttyprintk
crw-------  1 root root     10, 239 Dez 14 21:17 uhid
crw-------  1 root root     10, 223 Dez 14 21:17 uinput
crw-rw-rw-  1 root root      1,   9 Dez 14 21:17 urandom
Check ob ttyAMA0 auftaucht!

Code Auswählen

### lsusb ###
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP2102/CP2109 UART Bridge Controller [CP210                                    x family]
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
Auf der Platine richtig jumpern und Platine über USB Kabel anschließen.

ACHTUNG: Viele USB Kabel haben nur Power belegt und schleifen die beiden Data Leitungen nicht durch, solche Kabel sind ungeeignet!

Bei mir ist mindestens jedes 2.Kabel nicht geeignet, das sind meist jene die einem Steckernetzteil beiliegen!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 12:39:33
Braucht man die Anpassungen auch für den USB Betrieb?

Von meinem Verständnis benötigt man die Änderungen doch nur, wenn man die Ebus Platine aufsteckt, oder?

Und das Overlay pi3-minuart-bt ist deprecated, soweit ich weiss.
Heisst nur noch
Code Auswählen
minuart-bt
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 18 Dezember 2020, 13:17:41
ob der miniart-bt so notwendig ist weis ich nicht, einfach austesten, die schreibt ja der raspi-config. Ich habe die Einstellungen von einem Raspi 2B mit Buster entnommen und so funktioniert bei mir auch alles und die notwendigen Schnittstellen tauchen auf.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 18 Dezember 2020, 13:24:59
Zitat von: hErMeS am 18 Dezember 2020, 09:56:48
Ich sehe es als gravierenden Fehler in der Protokoll Implementierung bzw verhalten an
pfff, solche Sätze verderben mir echt den Spaß an so einem Projekt
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 14:34:33
Zitat von: john30 am 18 Dezember 2020, 09:43:52
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?

Ich nutze auch einen DNS Namen und keine IP-Adresse. Insofern wäre das Feature auch für mich relevant.

@john30: Ich kann dich verstehen. Aber du könntest es auch sportlich nehmen. Laut Wikipedia *kann* ein DHCP Client eine neue IP-Adresse anfordern, wenn der DHCP Server verschwindet. Er *darf* seine IP-Adresse noch bis zum Ablauf der Lease Zeit behalten. (Ich hab's jetzt nicht gegen die x-DHCP RFC's gegengelesen...). Zeigt mir bitte ein Gerät, welches die umfassenden DNS/DHCP RFC alle einhält :-D
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 18 Dezember 2020, 14:50:13
Zitat von: john30 am 18 Dezember 2020, 13:24:59
pfff, solche Sätze verderben mir echt den Spaß an so einem Projekt
Ich möchte niemanden angreifen oder schlecht machen.

Es würde doch mit zwei/drei Bedingungen im Code zumindest behebbar seien, so dass es zum neuen Request kommt? (Register abfragen, gegenprüfen lost Link und up again, request initialisieren)
Dass es hier nie eine konforme Behandlung von DHCP geben wird ist mir klar aufgrund des begrenzen ROM. Die lease time wäre mir auch egal.
Ich will auch die ganze Arbeit nicht schlecht reden, im Gegenteil ein großes Lob über das Erreichte.
Aber sind wir nicht da um so etwas auszutesten?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 18 Dezember 2020, 15:11:43
Zitat von: HeikoGr am 18 Dezember 2020, 14:34:33
Ich nutze auch einen DNS Namen und keine IP-Adresse. Insofern wäre das Feature auch für mich relevant.

Hallo Heiko,

der DNS Name hilft dir auch nur mit fester IP bzw DHCP Reservierung. Einen DNS Refresh wird der Adapter nicht machen wenn er bei nem Stromausfall ne neue Lease/IP bekommt. Oder sehe ich das falsch?

LG
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 15:16:29
Jein. Bei Stromausfall geht auch der Adapter aus ;-)

Und da bei mir die Fritzbox sowohl DHCP, als auch DNS macht hab ich auch bei einer geänderten IP keine Probleme
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 18 Dezember 2020, 15:43:26
@John30,@Reinhart

Ich habe mal DI+ und DI- vom Chip bis USB Buchse durchgeprüft. Sind durchgängig.(Bildanhang Leiterbahnen))
Habe auch nochmal nach Anleitung von Reinhart alles am Pi gecheckt. Es bleibt dabei. kein neues Gerät. Ich habe den Adapter auch mal an den PC gesteckt, keine Reaktion von Windoof.
Ansonsten Status wie hier im Beitrag:
https://forum.fhem.de/index.php/topic,116418.msg1111745.html#msg1111745 (https://forum.fhem.de/index.php/topic,116418.msg1111745.html#msg1111745)
k.a. was da los ist.

Jetzt zum Ethernetmodus.
Config sieht so aus:
Code Auswählen
EBUSD_OPTS="--scanconfig=full --accesslevel=* -l /var/log/ebusd.log --latency=20000 -d enh:192.168.0.217:9999 --loglevel=debug --mqttjson --mqtthost=192.168.0.253 --mqttport=1883 --mqtttopic=ebusd/%circuit/%name --address=ff"

ebusd startet nicht mit folgender Meldung:
Code Auswählen
Job for ebusd.service failed because the control process exited with error code.
See "systemctl status ebusd.service" and "journalctl -xe" for details.


im log steht nix drin.
mit "systemctl status ebusd.service" kommt folgendes:
Code Auswählen
â ebusd.service - ebusd, the daemon for communication with eBUS heating systems.
   Loaded: loaded (/lib/systemd/system/ebusd.service; enabled; vendor preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Fri 2020-12-18 15:27:22 CET; 25s ago
  Process: 1564 ExecStart=/usr/bin/ebusd $EBUSD_OPTS (code=exited, status=64)

Dec 18 15:27:22 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
Dec 18 15:27:22 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:27:22 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.


mit "journalctl -xe" kommt folgendes:
Code Auswählen
--
-- Unit ebusd.service has begun starting up.
Dec 18 15:29:54 FEHM-Server ebusd[1601]: /usr/bin/ebusd: unrecognized option '--mqttjson'
Dec 18 15:29:54 FEHM-Server ebusd[1601]: Try `ebusd --help' or `ebusd --usage' for more information.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Control process exited, code=exited status=64
Dec 18 15:29:54 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has failed.
--
-- The result is failed.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:29:54 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Service hold-off time over, scheduling restart.
Dec 18 15:30:24 FEHM-Server systemd[1]: Stopped ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has finished shutting down.
Dec 18 15:30:24 FEHM-Server systemd[1]: Starting ebusd, the daemon for communication with eBUS heating systems....
-- Subject: Unit ebusd.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has begun starting up.
Dec 18 15:30:24 FEHM-Server ebusd[1607]: /usr/bin/ebusd: unrecognized option '--mqttjson'
Dec 18 15:30:24 FEHM-Server ebusd[1607]: Try `ebusd --help' or `ebusd --usage' for more information.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Control process exited, code=exited status=64
Dec 18 15:30:24 FEHM-Server systemd[1]: Failed to start ebusd, the daemon for communication with eBUS heating systems..
-- Subject: Unit ebusd.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Unit ebusd.service has failed.
--
-- The result is failed.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Unit entered failed state.
Dec 18 15:30:24 FEHM-Server systemd[1]: ebusd.service: Failed with result 'exit-code'.
Dec 18 15:30:35 FEHM-Server sudo[1609]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/journalctl -xe
Dec 18 15:30:35 FEHM-Server sudo[1609]: pam_unix(sudo:session): session opened for user root by pi(uid=0)
lines 2817-2859/2859 (END)


Ich verwende diese Version:
Code Auswählen
ebusd 3.4.v3.3-51-g57eae05
Die habe ich auch aktuell im Einsatz mit FDTI UART und Adapter v2.2.
Brauche ich eine andere ebusd Version?
Hatte auch nochmal die ebusd-3.4_armhf-stretch.deb neu gezogen und installiert.

Einen Ping kann ich an das USR-ES1 Modul senden...
Komme gerade nicht weiter :(
Ich hoffe ich stelle mich nicht zu dumm an. erst USB und jetzt das...

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 15:48:01
"journalctl -xe" gibt bei folgendes (mit) aus:
Code Auswählen
unrecognized option '--mqttjson'

@john30: hast du das Debian Paket ohne mqtt gebaut?

https://github.com/john30/ebusd/releases/tag/v3.4
Code Auswählen
Variants of each binary with MQTT support have an additional "mqtt0" (for libmosquitto0) or "mqtt1" (for libmosquitto1) suffix in the name. Those without MQTT support don't have such a suffix.

@mr_petz: du musst das mqtt Paket nehmen
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 18 Dezember 2020, 15:56:53
Zitat von: HeikoGr am 18 Dezember 2020, 15:48:01
@john30: hast du das Debian Paket ohne mqtt gebaut?
für das neue enhanced protocol muss wie hier schon geschrieben (https://forum.fhem.de/index.php/topic,116418.msg1107964.html#msg1107964) der enhanced_device Branch (https://github.com/john30/ebusd/tree/enhanced_device) selbst compiliert werden. binaries/release gibt es noch nicht.
also:
Code Auswählen
git clone https://github.com/john30/ebusd
cd ebusd
git checkout enhanced_device
./autogen.sh
make install
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 18 Dezember 2020, 16:09:22
Zitat von: john30 am 18 Dezember 2020, 15:56:53
für das neue enhanced protocol muss wie hier schon geschrieben (https://forum.fhem.de/index.php/topic,116418.msg1107964.html#msg1107964) der enhanced_device Branch (https://github.com/john30/ebusd/tree/enhanced_device) selbst compiliert werden.

Stimmt. Ich hab mich nur auf die Fehlermeldung konzentriert. Der Fehler wegen "enh:" wäre dann beim nächsten mal gekommen...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 18 Dezember 2020, 16:38:27
Zitat von: john30 am 18 Dezember 2020, 15:56:53
für das neue enhanced protocol muss wie hier schon geschrieben (https://forum.fhem.de/index.php/topic,116418.msg1107964.html#msg1107964) der enhanced_device Branch (https://github.com/john30/ebusd/tree/enhanced_device) selbst compiliert werden. binaries/release gibt es noch nicht.
also:
Code Auswählen
git clone https://github.com/john30/ebusd
cd ebusd
git checkout enhanced_device
./autogen.sh
make install


Ok jetzt läufts. Hatte nicht das make install ausgeführt. wollte erst mit der alten Version den USB Standardmodus testen...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 18 Dezember 2020, 16:50:13
Zitat von: HeikoGr am 18 Dezember 2020, 15:16:29
Jein. Bei Stromausfall geht auch der Adapter aus ;-)


Jein, bei mir hängt eine Powerbank dazwischen.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 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:
Code Auswählen
--logareas=main,bus --loglevel=notice
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 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!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 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 (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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag 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.
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 ...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 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.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 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
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 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..

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 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 (https://github.com/eBUS/adapter) gepusht.
LG und schönen 4. Advent, John
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 10:40:26
Wow, dass sind viele gute Neuigkeiten!
Muss mir nur noch überlegen, wie ich das DHCP zeug testen kann...

Verdammt... dann muss ich mich jetzt tatsächlich mit Formulierungen der Doku beschäftigen  ::)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 20 Dezember 2020, 15:14:40
neue Firmwareupdate des PIC über die RPI pins und externen FTDI UART erfolgreich gemacht.
Jetzt habe ich ausversehen die Option -v statt -V ausgeführt und somit "enable verbose output" aktiviert.
Ist das egal?
sollte man vielleicht noch mal Überdenken ob -v und -V als verschiedene Optionen?

feste IP vergeben. Blaue LED leuchtet bis ebusd fertig gestartet wurde und geht dann aus.

Edit: kann man den CP2102 auf einen Sockel packen, dass er austauschbar ist bei defekt?

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 20 Dezember 2020, 18:05:45
Zitatkann man den CP2102 auf einen Sockel packen, dass er austauschbar ist bei defekt?
Da müssten wir schon alle ICs auf Sockel packen (die es gar nicht gibt - also auf Breakout Boards) und den Platz dazu haben wir ganz einfach nicht.
Das ist halt der Preis für diese hohe Dichte, wenn irgendetwas kaputt ist kann nur mehr das gesamte Modul getauscht werden. Ist bei jeder Waschmaschine so.
Schon klar dass das wünschenswert wäre, aber bitte versteh' uns dass das alles mit SMD-Fremdbestückung, geringem Preis und Logistik nicht ganz so einfach ist wie man sich das vielleicht vorstellt.
Übrigens werden sowieso nur von uns gelötete/getestete Prints ausgeliefert. Die Probleme jetzt sind nur für die Beta-Tester :-(
LG Eduard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 20 Dezember 2020, 18:18:23
Zitates gibt eine neue PIC Firmware
John hat eine neue Firmware released und was er verschwiegen hat ist, dass er das Delay in die Arbitierung eungebaut hat ;-).
Also zur Info, hier die neue Messung:

Die obere Spur SEND zeigt wieder ,,nur unseren" Sender auf dem Bus. RECEIVE zeigt den ,,gesamten" Traffic am Bus. V.l.n.r. sieht man zuerst beim ,,RECEIVE" Aktivität (von einem anderen Bus-Teilnehmer -  - wir sind ,,Idle" !!)
der dann mit einem SYN (AA) abschließt (Cursor ,,A"). Der PIC versucht darauf den Bus zu holen und legt seine Adresse (0xFF – Cursor ,,B") auf den Bus um sich als Sender geltend zu machen (was auch gelingt).
SEND und RECEIVE sind identisch, also sind wir auf dem Bus aktiv!
Der Abstand zwischen SYN und Arbitrierung (Cursor A zu Cursor B) beträgt 4.39ms was rechts unten zu sehen ist.
Damit sind wir in einem perfekten Zeitfenster welches 4.3ms als Minimum voraussetzt.

LG
Eduard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 18:36:08
Zitat von: galileo am 20 Dezember 2020, 18:05:45
Übrigens werden sowieso nur von uns gelötete/getestete Prints ausgeliefert. Die Probleme jetzt sind nur für die Beta-Tester :-(

Das stimmt so nicht, wenn mein Netzteil den CP2102 gekillt hat. Dann kann es jedem passieren  :-\
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 19:04:17
Zitat von: HeikoGr am 20 Dezember 2020, 18:36:08
Das stimmt so nicht, wenn mein Netzteil den CP2102 gekillt hat. Dann kann es jedem passieren  :-\
ich kann mir nur schwer vorstellen, dass ein USB Netzteil den CP2102 killt. Ich würde eher vermuten, dass der schon zuvor im Eimer war. Oder hattest Du schon Erfolg mit dem Adapter als USB Variante oder via USB geflasht?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 19:13:18
Beim allerersten anstecken per Netzstecker gingen die blauen LEDs (Pic und Lan-Board) an. Und dann aus. Und dann nie wieder an (bei Nutzung des USB-Stecker).

Aber ausschließen kann ich einen Defekt von anfang an auch nicht
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 20 Dezember 2020, 19:23:00
Hallo zusammen,

ich habe mal ein Gehäuse für den neuen Adapter - zunächst in der USB Variante - konstruiert. Leider gehöre ich nicht zum Kreis der Betatester, so dass ich die Abmessungen aus den 3D Abbildungen übernehmen musste. Vielleicht schaut mal der ein oder andere drauf und gibt mir seine Meinung/Anregungen (gern per PN). Sollte Bedarf auch für die anderen Varianten bestehen erstelle ich diese gern.

https://www.thingiverse.com/thing:4691693 (https://www.thingiverse.com/thing:4691693)

Gruß
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 20:20:02
Zitat von: HeikoGr am 20 Dezember 2020, 19:13:18
Beim allerersten anstecken per Netzstecker gingen die blauen LEDs (Pic und Lan-Board) an. Und dann aus. Und dann nie wieder an (bei Nutzung des USB-Stecker).
äh, PLural? dann kann das nur der Wemos gewesen sein, nicht das USR-ES1 Modul, denn das hat keine blaue LED
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 20 Dezember 2020, 20:38:24
Zitat von: john30 am 20 Dezember 2020, 20:20:02
äh, PLural? dann kann das nur der Wemos gewesen sein, nicht das USR-ES1 Modul, denn das hat keine blaue LED

Und die eine mittig auf der Unterseite an der Front von der USR-ES1 Platine?
Die leuchtet bei mir auch blau und strahlt den USB Port an.

Vielen Dank für das kleine DHCP Update  :D
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 20 Dezember 2020, 21:03:48
Zitat von: hErMeS am 20 Dezember 2020, 20:38:24
Und die eine mittig auf der Unterseite an der Front von der USR-ES1 Platine?
Die leuchtet bei mir auch blau und strahlt den USB Port an.

Die leuchtet bei mir rot...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 20 Dezember 2020, 21:14:34
Zitat von: mr_petz am 20 Dezember 2020, 21:03:48
Die leuchtet bei mir rot...
Hab sie als blau in Erinnerung. Aber stimmt ist rot. Stehe jetzt gerade wieder davor  :-[
Schande auf mein Haupt

Update auf letzte ROM lasse ich auch gleich wieder laufen.
Der D1 Mini wird dann mein letztes Testobjekt. Hier gehe ich schon aus dass dort soweit alles funktioniert da der Netzwerkstack mit den vorhandenen Libs im ESP abgearbeitet wird.
Beim Pi denke ich ebenfalls dass es hier keine Probleme geben wird (Serial liegt ja dann auf dem Pi anstatt CP2102 mit USB)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:21:57
Zitat von: hErMeS am 20 Dezember 2020, 20:38:24
Und die eine mittig auf der Unterseite an der Front von der USR-ES1 Platine?
Die leuchtet bei mir auch blau und strahlt den USB Port an.
ah ok, dann scheint es verschiedene module zu geben. die war bisher bei mir immer rot.

Zitat von: hErMeS am 20 Dezember 2020, 20:38:24
Vielen Dank für das kleine DHCP Update  :D
klappts damit jetzt?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:29:53
Zitat von: fuso2001 am 20 Dezember 2020, 19:23:00
ich habe mal ein Gehäuse für den neuen Adapter - zunächst in der USB Variante - konstruiert. Leider gehöre ich nicht zum Kreis der Betatester, so dass ich die Abmessungen aus den 3D Abbildungen übernehmen musste. Vielleicht schaut mal der ein oder andere drauf und gibt mir seine Meinung/Anregungen (gern per PN). Sollte Bedarf auch für die anderen Varianten bestehen erstelle ich diese gern.

https://www.thingiverse.com/thing:4691693 (https://www.thingiverse.com/thing:4691693)
cool, sieht gut aus! ich hab zwar keinerlei Erfahrung mit 3D Druck, aber ich kenne jemanden, der mir ein Exemplar bereitstellen können sollte :-)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 21:30:10
Zitat von: john30 am 20 Dezember 2020, 21:21:57
ah ok, dann scheint es verschiedene module zu geben. die war bisher bei mir immer rot.

Asche auf mein Haupt.
Die LED bei mir ist auch rot.

War aber beim ersten Test definitiv das Lan Modul
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:30:35
Zitat von: HeikoGr am 20 Dezember 2020, 10:40:26
Wow, dass sind viele gute Neuigkeiten!
Muss mir nur noch überlegen, wie ich das DHCP zeug testen kann...

Verdammt... dann muss ich mich jetzt tatsächlich mit Formulierungen der Doku beschäftigen  ::)
sorry :-) Die Doku ist in den wichtigsten Teilen jetzt auch auf Englisch online
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:33:10
Zitat von: HeikoGr am 20 Dezember 2020, 21:30:10
Asche auf mein Haupt.
Die LED bei mir ist auch rot.
alles gut
Zitat von: HeikoGr am 20 Dezember 2020, 21:30:10
War aber beim ersten Test definitiv das Lan Modul

  • Hatte ich am Anfang noch nicht die Wemos Pins angelötet
  • Geht die Wemos Variante einwandfrei
vielleicht ist ja nur der Spannungsregler abgeraucht. Kannst du mal schauen, ob CP2102 sich am USB meldet, wenn Du den Spannungsregler (am USB Anschluss) umgehst?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 20 Dezember 2020, 21:35:10
Zitat von: john30 am 20 Dezember 2020, 21:33:10
alles gutvielleicht ist ja nur der Spannungsregler abgeraucht. Kannst du mal schauen, ob CP2102 sich am USB meldet, wenn Du den Spannungsregler (am USB Anschluss) umgehst?

soll ich das auch testen?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:37:47
Zitat von: mr_petz am 20 Dezember 2020, 21:35:10
soll ich das auch testen?
gerne! mehr als noch mehr kaputt kann der CP2101 Zweig ja nicht werden.
Es wäre dann auch gut, wenn einer der defekten wieder zu uns zurück käme, damit wir das mal ganz genau unter die Lupe nehmen können.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 21:42:00
Kannst du mir einen Tipp geben, wie ich das testen soll?
wo kann ich die 5V für den CP2102 sonst einspeisen?

Zumal sich ja garnichts tut, wenn ich den Adapter an USB anschließe.
Der Spannungswandler ist - wenn ich die Schaltung richtig verstehe ja "nur" dafür da die 3,3 V für den restlichen Teil (alles außer CP2102) zur Verfügung zu stellen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 20 Dezember 2020, 21:44:10
Zitat von: HeikoGr am 20 Dezember 2020, 21:42:00
Kannst du mir einen Tipp geben, wie ich das testen soll?
wo kann ich die 5V für den CP2102 sonst einspeisen?

Zumal sich ja garnichts tut, wenn ich den Adapter an USB anschließe.
Der Spannungswandler ist - wenn ich die Schaltung richtig verstehe ja "nur" dafür da die 3,3 V für den restlichen Teil (alles außer CP2102) zur Verfügung zu stellen.
ach stimmt, ich war noch auf dem Trichter, dass der TS1117 den CP2102 mit 3,3V versorgt (das war mal in Diskussion). Dann geht das so leider nicht.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 21:45:40
Zitat von: john30 am 20 Dezember 2020, 21:37:47
Es wäre dann auch gut, wenn einer der defekten wieder zu uns zurück käme, damit wir das mal ganz genau unter die Lupe nehmen können.

Das kann ich gerne machen. Wenn ihr mir dann einen neuen (ich bezahle ihn auch selbstverständlich) bei Gelegenheit zurückschickt.
Mein Adapter in der Version 2 funktioniert ja auch noch.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 20 Dezember 2020, 21:51:21
interessant wäre, in den USB Betrieb gehen, Kabel dran und am Wemos Sockel messen ob die 3,3V da sind.
Ebenfalls kann man an R13-C7 messen ob hier auch die 3,3V vom internen Regler des CP2102 da sind, dann weiß man mehr wo es hapern könnte!

Aber vorsichtig, das beim Messen kein Kurzschluß hergestellt wird.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 22:20:48
Da liegt keine Spannung an.

Ich hab's auch schonmal geschrieben und jetzt schön visuell aufbereitet: Powerbank/USB Adapter gehen in die Schutzschaltung, wenn ich den Ebus-Adapter anschließe.

Zum Testaufbau:

Code Auswählen
USB-Powerbank -> USB-Hub
                        -> Arduino Nano (LED leuchtet, solange Ebus Adapter nicht angestöpselt ist)
                        -> Ebus-Adapter (wird angestöpselt)

Ich hab das ganze danach noch mit einem Iphone-Steckdosenadapter reproduzieren können.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 20 Dezember 2020, 22:36:57
ZitatPowerbank/USB Adapter gehen in die Schutzschaltung, wenn ich den Ebus-Adapter anschließe.

Ich kann das nicht ganz verstehen: was soll das heißen, dass der USB Adapter in die Schutzschaltung geht ?
Der USB Adapter (falls du den USB 3.0 Adapter meinst) hat doch gar keine "Schutzschaltung". Und wofür auch?
Hast du den Adapter jemals an ein normales Netzteil angeschlossen?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 20 Dezember 2020, 22:40:55
ich kenn die Spezifikation nicht, aber die Powerbank geht aus und versorgt auch andere Geräte nicht mehr mit Strom.
(Ich habe auch eine andere Powerbank getestet mit 2 USB Ausgängen. => gleiches Ergebnis)

Die Teststellung aus dem Video habe ich (wie auch in meinem Posting ergänzt) mit einem USB Steckdosenstecker (aber anderem USB-Hub) auch durchgeführt. mit dem gleichen Ergebnis
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 20 Dezember 2020, 22:41:35
Bei mir liegen am C7 und wemos 3,3V an.
Ich hatte ja schonmal geschrieben, dass 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...
gehen aber beide Kabel mit Handy am PC.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 21 Dezember 2020, 00:40:40
Zitat von: mr_petz am 20 Dezember 2020, 22:41:35
Bei mir liegen am C7 und wemos 3,3V an.
Ich hatte ja schonmal geschrieben, dass 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...
gehen aber beide Kabel mit Handy am PC.
Widerstandsmessung zwischen GND und 5V vom USB Stecker aus auf der eBus Platine schon gemacht? Würde zumindest erst einmal einen Kurzschluss feststellen lassen. Ob nun vom CP2102 oder dem TS1117 würde sich wohl nur mit Auslöten vom TS1117 feststellen lassen ohne die Leiterbahnen zu zerstören.




Update der Firmware ist erledigt.
Code Auswählen
~/ebusd/src/tools$ ./ebuspicloader -f 20201219-offset.hex  /dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_623e3a4826deea11b6d2d3149a583cc7-if00-port0
Device ID: 30b0 (PIC16F15356)
Device revision: 0.1
Bootloader version: 1 [0a6c]
Firmware version: 1 [7d22]
MAC address: ae:b0:53:xx:xx:xx
IP address: DHCP

New firmware version: 1 [c5e7]
erasing flash: done.
flashing: 0x0400 - 0x3006

0x0400 ................................................................
0x0800 ................................................................
0x0c00 ................................................................
0x1000 ................................................................
0x1400 ................................................................
0x1800 ................................................................
0x1c00 ................................................................
0x2000 ................................................................
0x2400 ................................................................
0x2c00 ................................................................
0x3000 .
flashing finished.
flashing succeeded.

Dann ist mir noch nebenbei eine kleine Sache in der Beschreibung aufgefallen
bei DHCP sollte eher stehen, set IP address from DHCP oder ähnlich (im Sinne von IP Adresse wird gesetzt oder Nutzung von DHCP)
Code Auswählen
~/ebusd/src/tools$ ./ebuspicloader --help
Usage: ebuspicloader [OPTION...] PORT
A tool for loading firmware to the eBUS adapter PIC.

  -d, --dhcp                 set IP address to DHCP
  -f, --flash=FILE           flash the FILE to the device
  -i, --ip=IP                set IP address (e.g. 192.168.0.10)
  -m, --mask=MASK            set IP mask (e.g. 24)
  -M, --macip                set the MAC address suffix from the IP address
  -r, --reset                reset the device at the end on success
  -s, --slow                 use low speed for transfer
  -v, --verbose              enable verbose output
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

PORT is the serial port to use (e.g./dev/ttyUSB0)


Ein Fehler scheint sich in der Firmware eingeschlichen zu haben.
Im Modus DHCP erfolgen jetzt durchgehend DHCP Request trotz erhaltener und erreichbarer IP (Bild im Anhang)
Workaround ist die Zuweisung einer festen IP. Hier erfolgt der DHCP Inform alle 60s laut Wireshark.

Werde das nächste Update abwarten und dann das DHCP nochmals angehen. Vermute mal eine kleine Bedingung falsch. Vielen Dank vorab.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 09:24:40
Zitat von: mr_petz am 20 Dezember 2020, 22:41:35
Bei mir liegen am C7 und wemos 3,3V an.
Ich hatte ja schonmal geschrieben, dass 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...
gehen aber beide Kabel mit Handy am PC.

d.h. die Platine scheint in Ordnung zu sein, zumindest was die Versorgung betrifft. Der interne Spannungsregler des CP2102 sowie der auf der Platine verbaute Regler ist ok. Es kann dann nur die Data Verbindung Probleme bereiten, entweder Eingang des CP2102 defekt, oder Kabel, oder es kommt wirklich kein Signal vom Raspi.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 09:33:59
Zitat von: HeikoGr am 20 Dezember 2020, 22:40:55
ich kenn die Spezifikation nicht, aber die Powerbank geht aus und versorgt auch andere Geräte nicht mehr mit Strom.
(Ich habe auch eine andere Powerbank getestet mit 2 USB Ausgängen. => gleiches Ergebnis)

Die Teststellung aus dem Video habe ich (wie auch in meinem Posting ergänzt) mit einem USB Steckdosenstecker (aber anderem USB-Hub) auch durchgeführt. mit dem gleichen Ergebnis

Du hast irgendwie eine komische Testumgebung, wie willst du denn da das serielle Signal vom Raspi einspeisen, auch über den Hub? Warum überhaupt ein HUB dazwischen? Eigentlich sollte einfach ein USB Kabel vom Raspi mit der Platine verbunden werden, das machen doch alle so. So wie du es schilderst, scheint ja dann ein kompletter Kurzschluss am Eingang der Platine zu sein!

Ganz nebenbei, so eine Powerbank kann ja immens viel Strom liefern, ist immer gefährlich für reinen Testbetrieb das hier was abraucht wenn was nicht stimmt. Ein Raspi geht in die Knie und fängt booten an.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 09:40:15
Zitat von: mr_petz am 20 Dezember 2020, 22:41:35
Bei mir liegen am C7 und wemos 3,3V an.
Ich hatte ja schonmal geschrieben, dass 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...
gehen aber beide Kabel mit Handy am PC.

Ich glaube dein Adapter wäre für nähere Analysen interessanter zu untersuchen, da hier offensichtlich die Stromversorgung noch funktioniert und trotzdem nicht geht!

Bei HeikoGr scheint ja ein Kurzschluß am Eingang zu sein, warum auch immer!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 21 Dezember 2020, 10:07:37
Zitat von: Reinhart am 21 Dezember 2020, 09:40:15
Ich glaube dein Adapter wäre für nähere Analysen interessanter zu untersuchen, da hier offensichtlich die Stromversorgung noch funktioniert und trotzdem nicht geht!

Bei HeikoGr scheint ja ein Kurzschluß am Eingang zu sein, warum auch immer!

LG

ok. Komplettes Set? und wann und wohin soll ich den senden? zu Dir?
Würde nochmal anderes Kabel und anderen Raspi testen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 10:12:22
Das schreib ich ja schon die ganze Zeit, dass hier irgendwo ein Kurzschluss ist.

Die Testumgebung hab ich ja auch lediglich aufgebaut um zu zeigen, dass ich definitiv kein Strom messen kann, weil Powerbank und Netzteil jegliche Zusamennarbeit verweigern und keinen Strom mehr liefern.

Mein allererster Test war die Lan-Variante (USB nur als Stromspender).
Danach habe ich natürlich auch per Raspi geteste (sie Post #70)!

Ich bastel mir heute abend mal ein USB kabel, bei welchem ich die Daten Leitungen abklemme.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 12:43:50
Zitat von: HeikoGr am 21 Dezember 2020, 10:12:22
Ich bastel mir heute abend mal ein USB kabel, bei welchem ich die Daten Leitungen abklemme.

ah ja, das ist eine gute Idee um den Fehler einzuschränken!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 21 Dezember 2020, 13:32:21
Widerstandsmessung ohne angesteckte Kabel direkt am TS1117 zwischen allen 4 Anschlüssen. Es dürfte nur GND einmal 0Ohm seien da das an zwei Pins anliegt.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 21 Dezember 2020, 13:49:02
Zitat von: john30 am 20 Dezember 2020, 21:29:53
cool, sieht gut aus! ich hab zwar keinerlei Erfahrung mit 3D Druck, aber ich kenne jemanden, der mir ein Exemplar bereitstellen können sollte :-)

Wenn dir das USB Gehäuse zunächst reichen würde wäre das prima. Ich hab die Dateien auf Thingiverse noch einmal geupdatet so dass jetzt alle Dateien in der Vorschau zu sehen sind und man es sich besser vorstellen kann. Dieser ovale Block dient übrigens zum Heruasführen der LED's in den Deckel. Hier kann 2mm² Lichtleitfaser eingebaut werden.

Gruß
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 14:29:51
@fuso2001: Das Gehäuse sieht echt gut aus!

@hErMeS: sicher, dass Gnd 2x vorkommt? Das ist doch out_1 und out_2 (pin2 und blech oben)

Folgende Widerstände habe ich gemessen (Multimeter steht auf 2000)
Pin 1 und Pin 2: 860 Ohm
Pin 1 und Pin 3: 0 Ohm
Pin 2 und Pin 3: 859 Ohm

Pin 2 und das Blech an der Oberkante des TS1117 haben bei der Messung die gleichen Ergebnisse und untereinander keinen Widerstand - sind ja auch über die platinenunterseite verbunden ;)


Ich bin kein Profi bei sowas (Messfehler sind ganz sicher möglich!), aber zwischen eins und drei sollte nicht kein Widerstand sein, oder?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 21 Dezember 2020, 15:11:29
Hast du bei der Widerstandsmessung auch Mal die Messespitzen verdreht?
Dioden können gemein seien

Heut Abend kann ich dir meine Widerstände der Pins untereinander Posten

Pin 1 (große Finne) und 3 sollten GND seien und daher auch 0 Ohm
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 15:16:24
Die spitzen gedreht oder vertauscht? Gedreht ja, vertauscht nicht.

Bist du dir sicher bei den gnd pins?
Wenn ich folgendes Darenblatt nehme:
https://www.mouser.de/datasheet/2/395/TS1117B_H1607-1918589.pdf
Ist die finne und pin 2 (mitte) output
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 21 Dezember 2020, 15:18:05
@fuso2001

Dein Entwurf ist doch für die USB Version (sieht gut aus). Könnte man das Gehäuse auch höher machen, wegen Lan-Modul? Oder sollte/müsste das dann in einer separaten Version erfolgen?
Was wären denn der angepeilte Herstellungs- bzw. Verkaufspreis?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 15:24:30
Hier sieht man die löcher, über die die Finne und pin2 (mitte) auf der rückseite verbunden sind
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 21 Dezember 2020, 16:13:38
Zitat von: mr_petz am 21 Dezember 2020, 15:18:05
@fuso2001

Dein Entwurf ist doch für die USB Version (sieht gut aus). Könnte man das Gehäuse auch höher machen, wegen Lan-Modul? Oder sollte/müsste das dann in einer separaten Version erfolgen?
Was wären denn der angepeilte Herstellungs- bzw. Verkaufspreis?
Ich würde bei Bedarf die beiden anderen Varianten (Wemos und LAN) zur Verfügung stellen. Leider kann ich nicht am "lebenden" Objekt testen (Hoffe, wenn ihr fleißig weiter testet, auf die Auslieferung im Januar ;) ). Zunächt einmal müßte ich aber wissen ob alles passt wie es konstruiert ist. Ansonsten fang ich bei jeder Variante an die selben Änderungen zu machen.

Ich hab eigentlich nicht vor die Dinger herzustellen und zu vertreiben. Wer einen 3D Drucker selbst besitzt oder einen "Bekannten" hat der einen hat kann die Gehäuse mit den STL Dateien selbst fertigen. Ausserdem bestünde noch die Möglichkeit die Teile online fertigen zu lassen. Ein Anbieter ist z.B. https://craftcloud3d.com/ (https://craftcloud3d.com/)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 21 Dezember 2020, 18:30:26
Zitat
Hier sieht man die löcher, über die die Finne und pin2 (mitte) auf der rückseite verbunden sind
Was möchtest du damit sagen? Ja, Pin2 und Pin 4 sind verbunden. Siehst du da ein Problem ?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 18:51:59
Zitat von: galileo am 21 Dezember 2020, 18:30:26
Was möchtest du damit sagen? Ja, Pin2 und Pin 4 sind verbunden. Siehst du da ein Problem ?

Nein, bzw. Nur wenn hErMeS in Post #187 Recht hat...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 18:56:31
Pin 1 und 3 dürfen keine 0 Ohm haben, das ist ein satter Kurzschluss meine ich!
Die 5 V werden dann fix auf Data+ gelegt!

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 21 Dezember 2020, 19:09:32
Hier das Layout mit der Print-Unterseite in Blau (2 und 4 verbunden).
Und dem Bauteil, fotografiert von der Unterseite (kein Kurzschluss möglich).
Sieht dort noch jemand ein Problem?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 19:17:56
Nein Galileo! Du verstehst das falsch. Vermultich hat der TS1117 bei mir einen Kurzsxhluss zwischen Pin 1 + 3 (Nummerierung gemäß Datenblatt).

Das Layout ist in Ordnung

hErMeS hat in einem früheren Posting geschrieben, dass zwischen Pin 2 und 4 (er schrieb Pin 1, Finne, und 3) kein Widerstand zu erwarten sei, da beide Pins ground wären. Ich habe nur in den Raum geworfen, dass - wenn ich es richtig verstehr beide PINs ,,out" sind.

Da will man einfach mal besserwisserisch sein und verwirrt alle... sorry!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 21 Dezember 2020, 20:21:41
Sorry für die Verwirrung mit den PINs
Als entschuldigung habe ich mal gemessen (bei IC's lässt sich eh immer schlecht messen), sollte aber einen Anhaltspunkt geben können
Ca werte da sich der Widerstand nach oben bzw unten schiebt

Code Auswählen
1+ 2- 845Ohm
1+ 3- ca 7MOhm
2+ 1- 845Ohm
2+ 3- ca 1,8MOhm
3+ 1- ca 18MOhm
3+ 2- ca 20MOhm

nur CP2102 Betreffend
4+ 1- ca 12MOhm
1+ 4- ca 12MOhm
5+ 1- ca 12MOhm
1+ 5- ca 12MOhm
4+ 3- ca 5MOhm
5+ 3- ca 5MOhm
3+ 4- nicht messbar
3+ 5- nicht messbar
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 21 Dezember 2020, 20:22:47
ihr habt mich abgehängt...
bevor hier noch weiter spekuliert wird: wäre es nicht schlauer, die zwei Adapter zur Analyse zurückzuschicken, damit wir herausfinden können, was das Problem ist? Nur so als Idee.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 21 Dezember 2020, 20:42:41
Hi, Ich hab es bei mir rausgefunden.
In der Buchse kommt kein Kontakt zu Pin3 (D+) zustande.
Habe es mit 4 verschiedennen Kabeln gemessen.
Vom Lötpunkt zum Leiterpinpunkt (k.a. wie es heisst)(rot) ist Kontakt da. siehe Bild (Häkchen geht durch, X nicht).
Also Buchse defekt. Ist es machbar ne neue rein zu löten? Würde es versuchen.
CP2102 wird nicht defekt sein...

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 20:44:20
Zitat von: john30 am 21 Dezember 2020, 20:22:47
ihr habt mich abgehängt...
bevor hier noch weiter spekuliert wird: wäre es nicht schlauer, die zwei Adapter zur Analyse zurückzuschicken, damit wir herausfinden können, was das Problem ist? Nur so als Idee.

Oje, das war keine Absicht.

Soweit ich das verstehe hat hErMeS keine Probleme mit dem Adapter.
Die Probleme haben mr_petz und ich. Und wir beide haben die Möglichkeit des zurückschickens schon positiv bescheinigt (Posts #171, #181).

Ich bin der einzige mit Problemen... Mir hat nur noch niemand gesagt wo ich den Adapter hinschicken darf  :D
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 21 Dezember 2020, 20:53:56
Zitat von: HeikoGr am 21 Dezember 2020, 20:44:20
Ich bin der einzige mit Problemen... Mir hat nur noch niemand gesagt wo ich den Adapter hinschicken darf  :D
ok, dann schick ihn mir bitte. Adresse schick ich dir gleich
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 21 Dezember 2020, 21:11:04
@john30: super

Noch ein Update zu meinem Problem:

Ich habe ein USB Kabel aufgetrennt und die einzelnen Leiterbahnen variabel schaltbar gestaltet. Auch wenn ich nur Plus und GND mit dem Adapter verbinde habe ich einen Kurzschluss.

Bei der USB Buchse habe ich (optisch) keine Auffälligkeiten.
Mein Hauptverdächtiger ist neuerdings der TS1117. Obwohl ich intuitiv gedacht hätte dieser wäre robuster als so ein CP2102 :D.

Mein nächster Ansatz wäre den TS1117 die Beinchen abzutrennen, auszulöten oder eine Leiterbahn zu kappen. Aber ich schicke ihn wohl besser zu john30 bevor ich was kaputt mache  8)

Da alle anderen Varianten (LAN/WEMOS/RPI) einwandfrei funktionieren erkläre ich die Hardware-Tests hiermit bei mir für beendet. Die nächsten Tage versuche ich dann noch was zum Wiki beizutragen (wenn mein Adapter dann weg ist).
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 21 Dezember 2020, 21:22:03
Hi Zusammen!

Bei mir läuft ja alles stabil!
Soll ich mein Set an einen von Euch bestimmten Tester weiterreichen und mein altes Modul wieder einsetzen?
So könnte man noch mehr Situationen testen. Oder als Muster für die Gehäusebauer.
Oder soll ich noch besondere Umstände testen?
Sonst lass ich dass einfach so laufen.

Liebe Grüße,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 21 Dezember 2020, 21:26:57
reine Info.
seit dem letzten PIC Update kommt bei mir im Log hin und wieder:
Code Auswählen

2020-12-20 17:29:12.493 [bus error] device status: unexpected available enhanced following byte 1
2020-12-20 17:44:08.689 [bus error] device status: unexpected available enhanced byte 2

kam mit der ersten FW Version nicht.
Adapter mit Lan-Modul.

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 21 Dezember 2020, 21:36:02
Zitat von: hErMeS am 21 Dezember 2020, 00:40:40
Im Modus DHCP erfolgen jetzt durchgehend DHCP Request trotz erhaltener und erreichbarer IP (Bild im Anhang)
könntest du bitte die Dekodierung des ACK vom DHCP Server posten?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 21 Dezember 2020, 21:50:06
Zitat von: mr_petz am 21 Dezember 2020, 20:42:41
Hi, Ich hab es bei mir rausgefunden.
In der Buchse kommt kein Kontakt zu Pin3 (D+) zustande.
Habe es mit 4 verschiedennen Kabeln gemessen.
Vom Lötpunkt zum Leiterpinpunkt (k.a. wie es heisst)(rot) ist Kontakt da. siehe Bild (Häkchen geht durch, X nicht).
Also Buchse defekt. Ist es machbar ne neue rein zu löten? Würde es versuchen.
CP2102 wird nicht defekt sein...

gruß Thomas

wenn du gut im Löten bist, sollte das machbar sein. Das Problem ist eher die alte Buchse zu entfernen ohne die Platine und Leiterbahnen zu beschädigen da das Gehäuse ja auch noch verlötet ist, eventuell mit 2 Lötkolben.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 21 Dezember 2020, 22:05:32
Zitat von: Reinhart am 21 Dezember 2020, 21:50:06
wenn du gut im Löten bist, sollte das machbar sein. Das Problem ist eher die alte Buchse zu entfernen ohne die Platine und Leiterbahnen zu beschädigen da das Gehäuse ja auch noch verlötet ist, eventuell mit 2 Lötkolben.

LG

Ich muss mal noch ein besseres Foto von den Pins der Buchse auf der Platine hinbekommen.
Vielleicht ist nur mal nachzulöten?

Dann nochmal nen Detailbild vom inneren der Buchse machen. Vielleicht ein Plastegrad?

Wenn ich die Buchse rauslöte, würde ich erst die 4 Halterungen und Pins sachte kappen und die Reste dann rauslöten. Schwieriger wird das einlöten der Pins. Da muss ich mir erst eine feine Spitze schleifen...

Das wäre meine rangehensweise...

Edit:
Das sollte die richtige sein. Oder?:
https://www.ebay.de/itm/2-Stuck-Micro-USB-Buchse-5-Pin-Stecker-TypB-fur-Elektronik-Robotik-Raspberry-D/323964078438?hash=item4b6dc38966:g:Np8AAOSwaOpexMR5 (https://www.ebay.de/itm/2-Stuck-Micro-USB-Buchse-5-Pin-Stecker-TypB-fur-Elektronik-Robotik-Raspberry-D/323964078438?hash=item4b6dc38966:g:Np8AAOSwaOpexMR5)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 21 Dezember 2020, 22:20:02
Hi!

Kurze Rückmeldung zur neuen Firmware.
Seit dem ich die neue Firmware drauf habe habe ich so gut wie keine Framing error mehr.
Nur noch die timeouts.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 22 Dezember 2020, 00:44:59
USB - keine Probleme feststellbar
RasperryPi 1b - keine Probleme feststellbar auf ttyAMA0; erst nach deaktivierung login shell auf serial port aktivierung serial hardware port (latest raspbian image)
D1 Mini - keine Probleme feststellbar
Platine: C1 und C4 erzeugen hochfrequente Geräusche (vermute hier ein MLCC - Piezoeffekt, wechsel zu Folie in späterer Serie möglich? Je nach Einsatzsort kann es evtl störend werden)
Ethernet - Feste IP kein Problem / weiterer DHCP-Fix ist in Arbeit (durchgehende DHCP Requests trotz zugewiesener IP vom DHCP-Server) / 10 Minuten ohne LAN-Kabel war der adapter anschließend nicht mehr erreichbar im DHCP Modus (Tritt dies auch im Fixed IP Modus auf? noch nicht gegen getestet)

Firmware Version 20201219
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 22 Dezember 2020, 08:25:34
Zitat von: mr_petz am 21 Dezember 2020, 22:05:32
Wenn ich die Buchse rauslöte, würde ich erst die 4 Halterungen und Pins sachte kappen und die Reste dann rauslöten. Schwieriger wird das einlöten der Pins. Da muss ich mir erst eine feine Spitze schleifen...
Moin moin,
wir haben uns jetzt nochmal intern abgestimmt und würden vorziehen, wenn Du uns Deinen Adapter auch zurücksendest, damit wir das Problem "ordentlich" analysieren können. Wir müssen vor der Produktion im Januar unbedingt das eigentliche Problem bestimmen.
Deshalb also die Bitte: nichts auslöten/abklemmen oder sonstiges, sondern alles so lassen und uns den Adapter schicken.
Ich schick dir gleich meine Adresse per PN
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 22 Dezember 2020, 08:50:00
Ok mache ich. Komplettes Set? Ich lege auch noch ein Kabel von mir bei.

gruß Thomas.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 22 Dezember 2020, 08:53:58
Zitat von: mr_petz am 22 Dezember 2020, 08:50:00
Ok mache ich. Komplettes Set? Ich lege auch noch ein Kabel von mir bei.
der Adapter alleine reicht, USR+Wemos kannst Du gern behalten.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 22 Dezember 2020, 10:08:10
Zitat von: JimKnopf am 21 Dezember 2020, 21:22:03
Hi Zusammen!

Bei mir läuft ja alles stabil!
Soll ich mein Set an einen von Euch bestimmten Tester weiterreichen und mein altes Modul wieder einsetzen?
So könnte man noch mehr Situationen testen. Oder als Muster für die Gehäusebauer.
Oder soll ich noch besondere Umstände testen?
Sonst lass ich dass einfach so laufen.

Liebe Grüße,
Burkhard
Moin Burkhard,
wenn du das Set abgeben würdest hätte ich Interesse. Würde mit dem Gehäuse schneller und bequemer weiter kommen. Vorausgesetzt das ist für das "Adapter Team" in Ordnung.

Gruß
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 22 Dezember 2020, 21:19:13
Ok. Habe erstmal den v2.2 Adapter mit den beigelegten Wemos von Reinhart in Betrieb genommen.
Hatte da keine Probleme beim konfigurieren.
Wemos hatte das EBUS WLan aufgespannt, danach alles eingegeben und gespeichert. Fertig.

@John
Schicke morgen früh den v3 Adapter  per Polsterumschlag zu dir.

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 23 Dezember 2020, 09:57:17
So, Adapter ist unterwegs.

Jetzt muss ich noch was zum Betatest loswerden.
Ich denke und spreche auch für andere, dass hier einiges an Beiträgen untergegangen ist.
John hat ja auch geschrieben, dass er nicht richtig mitkommt.
Ich hatte das Gefühl das einige meiner Beiträge nicht beachtet/gelesen worden.
Auch zum Beispiel von hErMeS mit dem fiepen. Darauf hatte ich auch hingewiesen. Zu diesen Thema fiepen gab es keine richtige Aussage von Euch.

Ich denke man hätte/sollte die verschiedenen Versionen (USB, Wemos, RPI etc) vom Adapter in Unterforen packen sollen. Da wäre es vielleicht übersichtlicher abgelaufen. Es ging alles ziemlich durcheinander, weil ja jeder wie und was er getestet hat hier mitgeteilt hat.
Man hätte auch paar Vorgaben machen sollen w.z.B. Loglevel. Oder ging es euch rein um die Funktion der Hardware?

Ich konnte jetzt leider nicht weiter mittesten. Bin da immer bereit zu.
Ich muss natürlich auch noch ein großes Lob an alle Entwickler des Adapter inkl. Software aussprechen. Wenn man richtig liest und alles Verstanden hat, dann ist es kein Problem den Adapter in Betrieb zu nehmen.

Also, ich wünsche gutes gelingen und werde mir dann einen neuen Bestellen wenn die verfügbar sind.

Edit: fehlen nicht noch 3 Tester?

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 23 Dezember 2020, 11:26:38
Ich finde es schon beachtlich, dass überhaupt ein Test gemacht wurde.

Aus Sicht der Entwickler ist es auch eine (strategische) Überlegung wie in einen Test eingegriffen wird. Und natürlich auch eine Frage der vorhandenen Kapazität.

Prinzipiell hast du aber natürlich Recht. insbesondere beim fiepsen wüsste ich auch gerne was Sache ist und ob es Bausteine gibt, welche keine Geräusche von sich geben.

Es zeugt von grossem Vertrauen in diesem Forum diese Kritik hier auch so deutlich zu schreiben.

Vielleicht ist ein lineares Forum aber auch kein geeigneter Ort um verschiedene, einzelne Probleme /Fragen zu diskutieren. Ein Bugtracker wäre vllt. tatsächlich übersichlicher gewesen.

Sei es drum. Es bleibt noch verbesserungspotential für einen Test der Platine 3.1 (oder 4.0?)  8)

Alles in allem bin ich der Meinung, dass durch den Test die Qualität der Hardware bestätigt wurde, die Software verbessert wird und die Dokumentation geschärft werden kann.

Insbesondere die ,,zahlenden Kunden" profitieren ganz klar von unserem Test!

Danke, dass ich teilnehmen konnte/kann.

Allen Entwicklern, Teilnehmern und mitlesenden: Schöne Feiertagen und (je nach Religion) ein besinnliches Weihnachtsfest
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 23 Dezember 2020, 12:54:42
Hi!

Wie sieht es aus @John, @Reinhard. Soll ich meinen 3.0 Adapter weiterreichen und wenn ja wer soll ihn bekommen?
Bei mir läuft bislang alles soweit super.

Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Hispanic am 23 Dezember 2020, 13:04:34
Zitat von: mr_petz am 23 Dezember 2020, 09:57:17

[...]

Edit: fehlen nicht noch 3 Tester?

gruß Thomas

Das sind wahrscheinlich die, denen es wie mir geht. Die Post hat augenscheinlich die Pakete verschlammt.
Seit 08.12.2020 keine Änderung des Abholstatus mehr.
An der Stelle sicher für die Entwickler ärgerlicher als für die, die nicht mittesten konnten.
Nur das keiner denkt der Rest ist faul  ;D
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 23 Dezember 2020, 13:20:55
ZitatIch hatte das Gefühl das einige meiner Beiträge nicht beachtet/gelesen worden.
Auch zum Beispiel von hErMeS mit dem fiepen. Darauf hatte ich auch hingewiesen. Zu diesen Thema fiepen gab es keine richtige Aussage von Euch.

Du kannst sicher sein dass alle Beiträge von uns gelesen wurden. Und das nicht nur ein Mal.
Aber manchmal gibt es zu diesem Zeitpunkt keine andere Antwort als "OK, zur Kenntnis genommen" und das zu posten ist ja auch blöd.

Was das Fiepen betrifft, ist derzeit keine verlässliche Aussage möglich, nur eine Reihe von Vermutungen.
Die müssen jetzt alle verifiziert werden und dann sollte ja auch entweder eine Lösung gefunden werden oder die Feststellung gemacht werden,
dass das einfach so ist (falls z.B. das Fiepen aus dem ISOW7842 käme - unwahrscheinlich aber nicht unmöglich).

Sorry falls das von euch als "Untätigkeit" wahrgenommen wurde - aber alle von uns haben neben diesem Projekt auch noch eine Menge anderer Verpflichtungen die nicht immer unbegrenzt Zeit frei lassen...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 23 Dezember 2020, 13:35:56
@HeikoGr
Das sollte nicht eine Kritik als solches sein.
Eher meine offene Meinung und zugleich ein Verbesserungsvorschlag für weitere/spätere Test´s.
Du hast natürlich Recht, dass nur durch die Test´s von uns allen eine positive Bestätigung/Feedback den Entwicklern gegeben wird und sie wissen dadurch wo sie stehen und der Endnutzer auch.

Wir investieren ja alle unsere Zeit für die Gemeinschaft und machen das ja auch nicht nur zum Spaß :)
Wir wollen ja selber das es nach den wünschen des einzelnen funzt...

@Hispanic
Wird schon noch. bei mir hat es auch lange gedauert...

Edit:
@galileo
Danke und du brauchst dich nicht dafür Entschuldigen.
Ist wie gesagt nur ein Denkanstoß für weitere Test´s...

gruß Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 23 Dezember 2020, 14:38:08
Zitat von: galileo am 23 Dezember 2020, 13:20:55
Was das Fiepen betrifft, ist derzeit keine verlässliche Aussage möglich, nur eine Reihe von Vermutungen.
Die müssen jetzt alle verifiziert werden und dann sollte ja auch entweder eine Lösung gefunden werden oder die Feststellung gemacht werden,
dass das einfach so ist (falls z.B. das Fiepen aus dem ISOW7842 käme - unwahrscheinlich aber nicht unmöglich).
Die zwei Geräuschquellen konnte ich nur mit einem harten Gegenstand verifizieren. Ich hatte hier auch erst die IC als solche in Vermutung, erst mit berühren dieser besagten Kondensatoren kam es zu Veränderungen im Geräusch. Ein berühren ohne aufzudrücken genügte schon. Auch veränderter Druck auf die Kondensatoren ändert das abgegebene Geräusch. Auch die Position des Berührungspunktes auf den Kondensatoren hat einen Einfluss.

Eine Erklärung allerdings auf Englisch ist hier zu finden betreffend der MLCC Typen. https://e2e.ti.com/blogs_/b/powerhouse/archive/2016/08/09/how-to-reduce-acoustic-noise-of-mlccs-in-power-applications#:~:text=When%20an%20electric%20potential%20or,acoustic%20noise%2C%20or%20singing%20noise.&text=Electric%20potential%20operating%20at%20a%20frequency%20within%20an%20audible%20range.

Ich hatte hier auch schon nach Lösungen gesucht und es scheint mehrere zu geben. Wechsel des Typs (Folie, Tantal), Anpassung der Platine, ...
Ohne den genau eingesetzten Typ (MLCC scheint richtig zu seien?) hier zu kennen gehe ich von einer 6,3V Variante aus die allerdings bei 5v ca 50% ihrer eigentlich angegebenen Kapazität haben, weshalb evtl ein entsprechend größer dimensionierter auch schon helfen könnte den Effekt zu verringern. Erklärbar wäre mir dies durch die geringere Kapazität und hierdurch stärkere Feldänderung im Kondensator selbst was den Piezoeffekt noch mehr begünstigt da er ja weniger Ladung speichert.

Ich weiß ich habe hier keinen Anteil an der Entwicklung der Platine, aber Gedanken macht man sich trotzdem da man selbst noch dazu lernen kann.
Klar ist auch, das Alter macht auch einen Unterschied in der Wahrnehmung. Ohne jemanden von euch persönlich zu kennen, der eine kann es hören und der andere nicht. Es sei nicht als Fehler in der Schaltung hingestellt, aufgefallen ist es dennoch.
In allem betrachte ich das als bisher erfolgreichen Beta Test. Funktion passt, und durch Firmware Updates können ggf weitere Funktionen ergänzt werden. Und dafür auch einen großen Dank.

Man findet immer irgendwo Stellen an denen man nochmals kleine Dinge korrigieren kann, so ist nunmal die Entwicklung in allen Bereichen.
Sei es nun das PCB Print, Änderung der Sockelhöhe für den USR-ES1 durch höhere Sockelleisten, ...
Meistens fällt so etwas erst zu spät auf wenn irgendetwas passiert ist. Jeder geht anders heran. Für den einen funktioniert es einfach nur, andere schauen akribisch jedes Detail an.
Wie mit jeder Entwicklung, es gibt Rückschläge aber auch Fortschritte.

Ich musste das jetzt einfach los werden.


Haben sich die anderen Tester schonmal gemeldet?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 23 Dezember 2020, 14:53:59
Hallo zusammen,

nachdem mit hErMeS die Befestigung der Patine zumindest theoretisch validiert wurde habe ich nun ein weiteres Gehäuse konstruiert. Es hat jetzt eine Höhe die den Adapter mit beiden Netzwerkerweiterungen (Wemos & Lan) behrbergen kann. Es sind lediglich die Seitenteile auzutauschen. Für die Wemos Variante können zwei Seiten verwendet werden. Einmal mit externer Antenne (2 Löcher auf der Ebus Seite) oder eben ohne. Ich hoffe die Öffnungen haben alle die korrekte Position...

https://www.thingiverse.com/thing:4694674 (https://www.thingiverse.com/thing:4694674)

Für die Led's sollte m.E. soetwas funktionieren (nicht getestet):
https://www.leds-and-more.de/catalog/20mm-lwl-lichtwellenleiter-lichtleiter-glasfaserkabel-lichtfaser-meter-p-2039.html (https://www.leds-and-more.de/catalog/20mm-lwl-lichtwellenleiter-lichtleiter-glasfaserkabel-lichtfaser-meter-p-2039.html)

Grüße
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 23 Dezember 2020, 19:24:19
Zitat von: JimKnopf am 23 Dezember 2020, 12:54:42
Hi!

Wie sieht es aus @John, @Reinhard. Soll ich meinen 3.0 Adapter weiterreichen und wenn ja wer soll ihn bekommen?
Bei mir läuft bislang alles soweit super.

Gruß,
Burkhard

Wir haben aus euren Testberichten wertvolle Erkenntnisse gewonnen und der Adapter gehört selbstverständlich euch für die Bemühungen und die Zeit die ihr aufgebracht habt! Laß das Ding ruhig laufen, auch ein Langzeittest ist interessant ob sich auch die Stabilität so bewährt.
Es hat ja nicht bei allen so gut geklappt wie bei dir, aber gerade das ist es ja was wir als Info brauchen um das Produkt weiter zu verbessern bevor wir uns vor vielen Beschwerden nicht mehr erwehren können. Einiges läßt sich mit Software beheben bzw. ist schon behoben worden, aber einiges stellt uns auch vor Herausforderungen wie das fiepen dessen Ursache man noch nicht genau zuordnen kann. Uns ist es auf jeden Fall lieber wenn die Fehler jetzt auftauchen und wir noch gegensteuern können, daher auch der Test!

Danke auf jeden Fall für eure unermüdliche Arbeit, wir berichten auf jeden Fall wies weitergeht wenn wir die beiden "defekten" Adapter näher analysiert haben und welche Gegenmaßnahmen und Lösungen wir haben. Wie galileo schon geschrieben hat kann es auch sein das wir gewisse Dinge nicht so leicht ändern können.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 23 Dezember 2020, 19:37:44
@hErMeS

du hast mit deinem Post genau den Kern getroffen! Gerade das fiepsen ist so eine Sache die auch stark vom Gehör des Testers abhängt, ältere Ohren stört das kaum weil sie es nicht so wahrnehmen, ein jüngeres Ohr empfindet das schon anders.
Änderungen an der Platine würden einen Rattenschweif mit sich ziehen, das austauschen von Teilen geht da schon leichter ist aber immer noch im logistischen Sinn kompliziert genug.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: JimKnopf am 23 Dezember 2020, 21:54:06
Hi!

Zum fiepen: manchmal hilft auch ein Tropfen Heisskleber/Kleber. Bei Spulen ist das ja recht üblich. Wäre vielleicht ein Versuch wert. Bein meinem Adapter kann ich nichts feststellen, aber ich bin ja auch schon 53 ;D :P.
Gruß,
Burkhard
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 25 Dezember 2020, 14:29:37
Hallo zusammen,
wie z.T. schon berichtet, sind wir dran an den Themen Fiepsen, Bestückung und DHCP. Auch von mir vielen herzlichen Dank an die Tester! Das war und ist wertvoller Input!

Eine Bitte hätte ich noch an Euch Tester, weil ich nicht alle >200 Beiträge nochmal durchforsten möchte:
Es wäre toll, wenn jeder noch einmal seine gefundenen, aber inzwischen noch nicht gelösten Punkte kurz posten könnte. Dann können wir diese abarbeiten und es geht nichts verloren. Gerne auch via privater Nachricht, wie ihr wollt.

Die Boards an die anderen Tester sind teilweise immer noch nicht angekommen oder wurden intern umdisponiert, also nicht wundern.

@JimKnopf: Du kannst gern deinen Adapter weitergeben wie Du magst. Aus meiner Perspektive haben wir genügend Input in dieser Runde bekommen.

Ich wünsche Euch einstweilen noch schöne Feiertage!
LG John
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 26 Dezember 2020, 15:40:40
Meinerseits jetzt noch das von fuso2001 modelierte Gehäuse fertig zusammengebaut im Anhang.
Ich hatte auch schon mit Ihm Kontakt und das ein oder andere Maß korrigiert. Ganz passend ist der LAN-Port in der jetzigen Version noch nicht.
Allerdings ist hier ja anzumerken, dass es es ich um die Beta Test Platine Handelt und nicht klar ist ob hier noch ein höherer PIN-Header im End-Stadium genommen wird. Hierdurch ist der LAN-Port in der Höhe noch nicht festsetzbar.

Die aktuelle USB/LAN Platte weist um ca 2mm zu weit nach oben platziertes Loch auf wenn die kürzeren PIN-Header genommen werden.
Wird allerdings die gleiche Höhe genommen wie der WEMOS, so ist hier das Loch noch 1mm zu weit oben platziert.
Das soll jetzt kein Niedergang des Gehäuse seien. Die Platte neu ausgedruckt und Thema erledigt. Habe mir hier auf die schnelle mit einem weiteren angepassten Druck geholfen (nach unten ausgeschnitten).
Wenn das Loch jetzt noch auf die korrekte Höhe platziert werden kann, sitzt auch die LAN-Buchse in der Platte ordentlich fest. Jetzt wackelt diese bei mir durch mein zu hohes Loch.
Zusammenbau geht nur wenn gleichzeitig Platte mit LAN-Adapter gesteckt wird. (gut zwecks fixierung LAN-Buchse)

Hoffe der Beitrag ist hier noch passend (ist ja alles Beta)  ::)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 16:38:31
Zitat von: hErMeS am 26 Dezember 2020, 15:40:40
Meinerseits jetzt noch das von fuso2001 modelierte Gehäuse fertig zusammengebaut im Anhang.
cool! das sieht ja toll aus!
Die Höhe der Buchsenleisten ist jetzt einheitlich geplant, also gleiche Höhe für USR-ES1 wie für Wemos, siehe die Reichelt Liste (https://www.reichelt.de/my/1774398).
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 26 Dezember 2020, 16:44:14
Zitat von: john30 am 26 Dezember 2020, 16:38:31
cool! das sieht ja toll aus!
Die Höhe der Buchsenleisten ist jetzt einheitlich geplant, also gleiche Höhe für USR-ES1 wie für Wemos, siehe die Reichelt Liste (https://www.reichelt.de/my/1774398).
Ich hab zunächst auf der Thingiverse Seite ein weiteres Seitenteil mit 2mm nach unten versetztem Lan-Loch hoch geladen. Heisst "EBUS Adapter 3 Gehaeuse - Seite LAN fuer Beta Platine.STL"

Die schlußendliche Version erstelle ich wenn ich irgendwann das "Release" in der Hand habe.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 16:51:51
Zitat von: fuso2001 am 26 Dezember 2020, 16:44:14
Die schlußendliche Version erstelle ich wenn ich irgendwann das "Release" in der Hand habe.
ja klar, macht Sinn.
Wäre es denkbar, das Gehäuse insgesamt kleiner zu bekommen, indem die Oberkante vom USR-ES1 einfach am Deckel abschließt?
und könnte man an den Seitenteilen eine Aussparung der Stege in der Ecke vorsehen, so dass man den Adapter bloß reinkleimmen braucht? Da würden ja vermutlich 2mm pro Seite genügen und die RPI Buchsenleiste wäre dann aj auch nicht verbaut. (ich bin ein Freund von klein und kompakt :) )
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 26 Dezember 2020, 17:18:43
Die USB und D1 Mini Variante sollte die gleiche Gehäuse Höhe erhalten.
Das höhere nur für LAN.
Somit gibt es nur zwei mögliche Varianten die man ausdrucken kann.

(Und was dann noch fehlt ist nur noch das Gehäuse für die verschiedenen Raspberry Pi Varianten)

Hab auch kein Problem meine Pi Buchsenleiste wieder auszulöten um das kompakte dann zu testen
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 26 Dezember 2020, 17:34:28
Zitat von: john30 am 26 Dezember 2020, 16:51:51
ja klar, macht Sinn.
Wäre es denkbar, das Gehäuse insgesamt kleiner zu bekommen, indem die Oberkante vom USR-ES1 einfach am Deckel abschließt?
und könnte man an den Seitenteilen eine Aussparung der Stege in der Ecke vorsehen, so dass man den Adapter bloß reinkleimmen braucht? Da würden ja vermutlich 2mm pro Seite genügen und die RPI Buchsenleiste wäre dann aj auch nicht verbaut. (ich bin ein Freund von klein und kompakt :) )
Denkbar wäre ein Gehäuse in dem man den Adapter hinein schiebt. An den Seiten der Platine bis zu den Pfostenstecker messe ich in der Abbildung 1,1mm. Man könnte also theoretisch ein Gehäuse bauen das im inneren eine Breite von 48mm hat und auf jeder Seite eine Kerbe die die Platine aufnimmt. Also praktisch das Gehäuse auf der Ebus Seite offen und den Deckel die Platine "festklemmen lassen. Ich denke das wäre die kleinst mögliche Version? Allerding wären die Jumper dann schon am Gehäuserand.

Hoffe ich hab mich einigermassen klar ausgedrückt?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 26 Dezember 2020, 17:48:09
Gleich noch eine Gegenfrage zwecks einschieben an die Macher der Platine. Die ausbrech Nasen vom frei Fräsen bleiben an der Platine dran?
Ein Einschieben ist so gesehen dann nicht möglich. Damit bleibt nur etwas zum einclippen oder Schrauben.
Bei mir habe ich neben der USB Buchse die Nase fast weg gefeilt dass es passt wie es sollte
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 17:50:09
Zitat von: fuso2001 am 26 Dezember 2020, 17:34:28
Denkbar wäre ein Gehäuse in dem man den Adapter hinein schiebt. An den Seiten der Platine bis zu den Pfostenstecker messe ich in der Abbildung 1,1mm. Man könnte also theoretisch ein Gehäuse bauen das im inneren eine Breite von 48mm hat und auf jeder Seite eine Kerbe die die Platine aufnimmt. Also praktisch das Gehäuse auf der Ebus Seite offen und den Deckel die Platine "festklemmen lassen. Ich denke das wäre die kleinst mögliche Version? Allerding wären die Jumper dann schon am Gehäuserand.
naja, so klein brauchts ja auch nicht sein :) war nur so ne Idee (ohne jeglichen 3D Druck Background). Dachte nur, so kann mal sich Schrauben zur Befestigung sparen, wenn 3 Ecken der Platine (2 mit Bohrloch, 1 ohne am J8) in eine Aussparung der Stege in den Ecken des Gehäuses reingeschoben würden und dann das Seitenteil bei der USB Buchse die Platine von allein fixiert.

Es würde ja auch schon kleiner werden, wenn die Oberkante vom USR-ES1 direkt an der Unterkante des Deckels anliegt.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 17:50:50
Zitat von: hErMeS am 26 Dezember 2020, 17:48:09
Gleich noch eine Gegenfrage zwecks einschieben an die Macher der Platine. Die ausbrech Nasen vom frei Fräsen bleiben an der Platine dran?
Ein Einschieben ist so gesehen dann nicht möglich. Damit bleibt nur etwas zum einclippen oder Schrauben.
Bei mir habe ich neben der USB Buchse die Nase fast weg gefeilt dass es passt wie es sollte
die sollen natürlich nicht bleiben. für "meine" Tester habe ich die alle abgeschliffen
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 26 Dezember 2020, 17:51:56
Zitat von: hErMeS am 26 Dezember 2020, 17:48:09
Gleich noch eine Gegenfrage zwecks einschieben an die Macher der Platine. Die ausbrech Nasen vom frei Fräsen bleiben an der Platine dran?
Ein Einschieben ist so gesehen dann nicht möglich. Damit bleibt nur etwas zum einclippen oder Schrauben.
Bei mir habe ich neben der USB Buchse die Nase fast weg gefeilt dass es passt wie es sollte
Die Nasen könnte man ja berücksichtigen. Wären dann ein klein wenig tiefere Kerben...
Aber klipsen ginge auch. Jenachdem wie "flexibel" das Material ist...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 26 Dezember 2020, 18:36:02
Bei nem verschraubten Deckel brauch ich schon den Platz für die Stege in denen die Löcher für die Verschraubung sitzt. Ich könnte auch den Deckel klipsbar machen dann fallen die 16mm am linken und rechten Rand weg. Auch hinten könnte noch ein wenig geschrumpft werden. Und in der Höhe bis zum USR-ES1 + 1mm.

hErMeS willst du das testen? Wenn ja ohne RPI Buchsenleiste?

@john30 ist die Höhe der Lan Buchse im RC dann so wie in eurer 3D Abbildung?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 26 Dezember 2020, 19:04:47
Auf die paar Gramm Filament kommt es auch nicht mehr an.
Bin froh wenn ich das Rote Stringing behaftete PETG verbraucht habe  ;D das klebt wie Hölle an der Düse und verschandelt den Druck.
Die Platine war glaube 2,3mm dick.
Die Höhe der Buchsenleiste sollte sich aus der Materialliste ergeben. Vermute gleiche Höhe wie der Wemos?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 26 Dezember 2020, 19:20:40
Zitat von: hErMeS am 26 Dezember 2020, 19:04:47
Die Platine war glaube 2,3mm dick.
Die Höhe der Buchsenleiste sollte sich aus der Materialliste ergeben. Vermute gleiche Höhe wie der Wemos?
Also messen tue ich Stärke Platine USR-ES1 1,6mm + Sockel der Stifte nach unten 2,6mm + Buchsenleiste 8,5 = Abstand Platinenoberseite Adapter bis Platinenoberseite USR = 12,7 + Höhe Buchse mit Füßchen 13,8 = 26,5mm Adapter Oberseite bis Lanbuchse Oberseite.
1mm Spiel baue ich noch ein.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 19:44:50
man könnte den RJ45 aus dem Gehäuse rausschauen lassen, so wie bei diesem Gehäuse hier (https://www.thingiverse.com/thing:559858). Und für die WIFI Variante den Schlitz einfach lassen, damit der Wemos bisschen Luft zum Kühlen bekommt.
Und wenn man zwei Halbschalen konstruiert mit drückbarem Schnappverschluss, braucht es gar keine Schrauben mehr :) Nur so als Anregung :)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 26 Dezember 2020, 19:45:41
Zitat von: hErMeS am 26 Dezember 2020, 19:04:47
Die Höhe der Buchsenleiste sollte sich aus der Materialliste ergeben. Vermute gleiche Höhe wie der Wemos?
hab ich ja geschrieben
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: technikki79 am 27 Dezember 2020, 11:19:41
Zitat von: JimKnopf am 23 Dezember 2020, 21:54:06
Hi!

Zum fiepen: manchmal hilft auch ein Tropfen Heisskleber/Kleber. Bei Spulen ist das ja recht üblich. Wäre vielleicht ein Versuch wert. Bein meinem Adapter kann ich nichts feststellen, aber ich bin ja auch schon 53 ;D :P.
Gruß,
Burkhard

Wenn sich jemand nach Heißkleber umschauen möchte, dann schaut doch mal bei diesem Ratgeber vorbei. Hier findet man recht schnell alle Antworten: https://www.meisterbob.de/heisskleber-test/
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 27 Dezember 2020, 12:52:17
Wieder ein kleines Update:
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fluppie am 27 Dezember 2020, 13:36:56
Mein Internetmodul VR900 ist gestorben, keine Ahnung warum, 5,2 V Netzteil funktioniert immer noch gut.
Ich selbst habe einen Multimatic VRC700 in Kombination mit einem Vaillant Ecotec Plus VCW346 / 5-5. Mit Außensensor und allem an Fußbodenheizung.
Sobald ein Schild verfügbar ist, bitte. Das Haus ist übrigens mit KNX vollautomatisiert.
Oder ob noch Tests möglich sind ...

Mijn internetmodule VR900 is overleden, geen idee waarom, 5.2V voeding werkt nog goed.
Zelf heb ik een Multimatic VRC700 in combinatie met een Vaillant Ecotec Plus VCW346/5-5. Met buitenvoeler en alles op vloerverwarming.
Zodra een bordje beschikbaar is, heel graag. Huis is overigens volledig met KNX geautomatiseerd
Of indien testen nog mogelijk is...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 27 Dezember 2020, 14:41:46
Hallo zusammen,

die nächste Gehäuse Version liegt bei Thingiverse bereit: https://www.thingiverse.com/thing:4698626 (https://www.thingiverse.com/thing:4698626)

Die LAN Buchse schaut bei dieser Version oben raus. Aufgrunddessen konnte das Gehäuse recht flach gehalten werden.
Ausserdem wurde auf Schrauben verzichtet. Der Deckel hat eine Klemmvorrichtung die ebenfalls die Platine einklemmt.

Die Wemos Teile folgen in Kürze. Der Boden wird aber der selbe bleiben.

@hErMeS: Damit du deine PI Leiste nicht auslöten muß habe ich unten einen Ausschnitt für diese gemacht. Müsstest vielleicht nen paar Gummifüße unter kleben. Ebenfalls habe ich ein Seitenteil mit "tiefergelgtem" Lan-Ausschnitt beigefügt.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 27 Dezember 2020, 15:28:42
Kannst du am Deckel bitte noch mit 0,5 fachen Radius der Dicke von der Lasche am Übergang versehen?
(Zwecks besserer Abfangung der Kräfte die beim schließen und öffnen)

Werd es heute Abend Mal in den Druck geben und schauen wie es passt//
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 27 Dezember 2020, 16:01:37
Zitat von: hErMeS am 27 Dezember 2020, 15:28:42
Kannst du am Deckel bitte noch mit 0,5 fachen Radius der Dicke von der Lasche am Übergang versehen?
(Zwecks besserer Abfangung der Kräfte die beim schließen und öffnen)

Werd es heute Abend Mal in den Druck geben und schauen wie es passt//
Ich hab nach innen und zu den Seiten Fasen angesetzt. Die sollten mehr Halt geben. Nach aussen ist kein Platz an der Wand. Müßte sonst auch am Bodenteil Fasen setzen. Ich hoffe das das Material genug nachgibt. Ansonsten müssten die Laschen vielleicht nen bisschen dünner werden!?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 27 Dezember 2020, 16:07:48
Zitat von: fuso2001 am 27 Dezember 2020, 16:01:37
Ich hab nach innen und zu den Seiten Fasen angesetzt. Die sollten mehr Halt geben. Nach aussen ist kein Platz an der Wand. Müßte sonst auch am Bodenteil Fasen setzen. Ich hoffe das das Material genug nachgibt. Ansonsten müssten die Laschen vielleicht nen bisschen dünner werden!?
das sieht sehr cool aus! Danke dafür! ich schau mal, ob mir das ein Kumpel drucken kann.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 27 Dezember 2020, 18:43:03
@john
Ich hoffe morgen oder übermorgen kommt bei dir der Adapter von mir an. Ich hoffe auf eine kleine Rückmeldung bezüglich USB Port von dir ;)
Würde mich schon interessieren ob meine Kabel oder die Buchse einen treffer haben.

Also bis dahin und Danke schon mal...

grüße Thomas
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 27 Dezember 2020, 18:45:26
Zitat von: mr_petz am 27 Dezember 2020, 18:43:03
Ich hoffe morgen oder übermorgen kommt bei dir der Adapter von mir an. Ich hoffe auf eine kleine Rückmeldung bezüglich USB Port von dir ;)
Würde mich schon interessieren ob meine Kabel oder die Buchse einen treffer haben.
Hi Thomas,
er ist schon angekommen! Sorry fürs nicht Zurückmelden (zu viel zu tun schon wieder).
So wie es aussieht war ein Pin an der USB Buchse nicht richtig verlötet. Das muss vermutlich noch genauer analysiert werden.
LG John
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: mr_petz am 27 Dezember 2020, 18:52:41
Danke. Das wäre meine erste Tat gewesen. Nachlöten... ;)

Bis bald...
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 27 Dezember 2020, 19:02:40
Nur als Warnung:
Sollte jemand hier NACHLÖTEN wollen oder müssen, dann bite NUR MIT BLEIFREIEM Zinn und entsprechend hoher Temperatur.
Im Gegensatz zur "nackten" Printplatte, welche chemisch verzinnt ist und nur eine Micrometer-dünne Schicht hat (auf die man auch verbleites Zinn auftragen kann),
sind die Lötstellen der bestückten Prints bereits mit BLEIFREIEM Zinn gelötet. Also bitte nicht mit Blei vermischen, die Lötstelle würde danach nicht mehr funktionieren !!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 28 Dezember 2020, 01:49:53
Das neue Mini Gehäuse habe ich jetzt komplett ausgedruckt. Ich hatte da so eine kleine Vorahnung, die sich anscheinend bestätigte.

Die Führungslöcher müssten vom Innendurchmesser größer werden. Bekomme hier gerade Mal die Hälfte drauf geschoben. Die überschüssige Z Naht ist an den Führungsstiften schon weggeschnitten.
Die M3 Schraublöcher hatten allerdings gepasst (ging nicht zu leicht und nicht zu schwer rein)

Rastnasen benötigen größere Dimensionen. Der Überhang ist hier zu groß bzw auch das Loch in der Wand zu klein.
Auch wenn ich es 180° gedreht ansetze, schnappt es nicht richtig ein. Es ist schon etwas, allerdings mit viel zu wenig Haltekraft
Eventuell würde es hier schon helfen, anstatt der nur auf kompletter Länge vorhandenen Nut gegen Ausbuchtungen an entsprechenden Stellen auszutauschen und das Loch /Haltesteg ins Gehäuse reinzuziehen.

Die Führungen für die Platten benötigen bei mir jetzt auch mehr Toleranz. Durch den Bowden bei mir im Drucker neigt es zur Überextrusion der äußeren Ecken im unteren Bauteil aufgrund der kleinen Fahrtwege. Bei der großen Variante war die Wandung dicker? und hat daher besser gepasst? Wenn ich bei der Platte einen Layer weg lasse müsste das dann auch passen (Drucke mit 0,2mm)
Mit dem Testdruck bekomme ich die Platten nicht in die Führung ohne dass es die Wandungen zur Seite drückt. Platinen Passform ist nicht geprüft

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 28 Dezember 2020, 08:22:06
@john30: hattest du schon Zeit "meine" Platine anzusehen?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 28 Dezember 2020, 11:39:02
Zitat von: HeikoGr am 28 Dezember 2020, 08:22:06
@john30: hattest du schon Zeit "meine" Platine anzusehen?
die ist schon unterwegs zur noch genaueren Untersuchung via Mikroskop u.a., da die Betrachtung per Lupe keine neuen Erkenntnisse brachte.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 28 Dezember 2020, 12:30:00
Zitat von: hErMeS am 28 Dezember 2020, 01:49:53
Das neue Mini Gehäuse habe ich jetzt komplett ausgedruckt. Ich hatte da so eine kleine Vorahnung, die sich anscheinend bestätigte.

Die Führungslöcher müssten vom Innendurchmesser größer werden. Bekomme hier gerade Mal die Hälfte drauf geschoben. Die überschüssige Z Naht ist an den Führungsstiften schon weggeschnitten.
Die M3 Schraublöcher hatten allerdings gepasst (ging nicht zu leicht und nicht zu schwer rein)

Rastnasen benötigen größere Dimensionen. Der Überhang ist hier zu groß bzw auch das Loch in der Wand zu klein.
Auch wenn ich es 180° gedreht ansetze, schnappt es nicht richtig ein. Es ist schon etwas, allerdings mit viel zu wenig Haltekraft
Eventuell würde es hier schon helfen, anstatt der nur auf kompletter Länge vorhandenen Nut gegen Ausbuchtungen an entsprechenden Stellen auszutauschen und das Loch /Haltesteg ins Gehäuse reinzuziehen.

Die Führungen für die Platten benötigen bei mir jetzt auch mehr Toleranz. Durch den Bowden bei mir im Drucker neigt es zur Überextrusion der äußeren Ecken im unteren Bauteil aufgrund der kleinen Fahrtwege. Bei der großen Variante war die Wandung dicker? und hat daher besser gepasst? Wenn ich bei der Platte einen Layer weg lasse müsste das dann auch passen (Drucke mit 0,2mm)
Mit dem Testdruck bekomme ich die Platten nicht in die Führung ohne dass es die Wandungen zur Seite drückt. Platinen Passform ist nicht geprüft
Habe alle Teile überarbeitet:
@hErMeS: Würdest du noch einmal prüfen und ggf. drucken sofern du noch rotes Filament übrig hast...?

Lg Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: DerFranke am 29 Dezember 2020, 12:34:09
Zwei kurze Fragen an die Betatester:
-  um wieviel dicker wird ein Raspi4 mit eBus 3.0 Adapter? Foto reicht auch
- läuft die gesamte Kommunikation über den GPIO Stecker?

Besten Dank,
sagt der Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 29 Dezember 2020, 21:32:13
wenn du dir das 3D Modell anschaust, dann sieht man das Stiftleisten ordentlich an Höhe brauchen. Bis zur Unterseite der Platine sind es 10mm. Die Stiftleisten kannst du dir sparen, indem du statt der Jumper Drähte zum rangieren einlötest und die Klemme durch eine Waggo Klemme ersetzt. Dann solltest du nach oben mit weiteren 5mm auskommen, ansonsten nochmals 10 mm.

Nein, es läuft nicht die gesamte Kommunikation über den Connector, der eBus muss an die Klemme, der Rest inkl. Power über die Steckverbindung.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 30 Dezember 2020, 08:30:11
Das Problem mit dem Fiepen ist gelöst.

Nach vielen Messungen und Versuchen hat sich letztlich herausgestellt, dass nicht die Kerkos selbst fiepen, sondern der ISOW7842 der Verursacher ist.
Im Datenblatt steht ganz klein vermerkt, dass die Kapazität am Ausgang kleiner als jene am Eingang sein muss (ohne Erklärung, warum). Bei der jetzigen Schaltung war das genau umgekehrt.
Eine Änderung von C4 und C6 auf kleinere Werte hat das Fiepen komplett beseitigt.

Wir werden den Schaltplan und somit die endgültige Schaltung entsprechend anpassen.
LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 03 Januar 2021, 13:17:23
eBUS Adapter 3 Reservierung / Reservation

Die Reservierung ist gestartet, Details siehe hier. (https://forum.fhem.de/index.php/topic,117350.0.html)

Reservation has started, see details here. (https://forum.fhem.de/index.php/topic,117350.0.html)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 04 Januar 2021, 00:34:18
@john30
Firmwareupdate ist durchgeführt.
Adapter direkt wieder ins Netz gebracht mit DHCP Setting, jedoch gab es hier einen kuriosen Fehler.

ebusd lief die ganze Zeit. Adapter hat sich die IP geholt, war auch anpingbar, jedoch kam es hier nicht zu einem Reconnect.
Den ebusd neu durchzuladen hat nicht geholfen. Nur ein repower vom Adapter ging letztlich.

Code Auswählen
2021-01-03 22:46:07.429 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 22:46:07.429 [bus notice] device invalid
2021-01-03 22:46:12.434 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 22:46:12.435 [bus notice] device invalid
2021-01-03 22:46:17.436 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 22:46:17.436 [bus notice] device invalid
2021-01-03 22:46:22.441 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 22:46:22.441 [bus notice] device invalid




Jetzt habe ich das LAN-Kabel für kurze Zeit getrennt (1-2 Minuten) und da habe ich den gleichen Fehler (Ping ok, Verbindung nicht) erhalten
Wireshark im Anhang
Ausschnitt vom ebusd.log annähernd an den Wireshark Traffic (anhand der Sekunden und zwei unterschiedlichen Systemen kann ich das nicht genau übereinander legen)
Code Auswählen
2021-01-03 23:23:51.705 [bus notice] device invalid
2021-01-03 23:23:59.726 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 23:23:59.726 [bus notice] device invalid
2021-01-03 23:24:04.728 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 23:24:04.728 [bus notice] device invalid
2021-01-03 23:24:09.729 [bus error] unable to open adapterebusv3:9999: ERR: generic I/O error
2021-01-03 23:24:09.729 [bus error] send to 08: ERR: no signal, give up
2021-01-03 23:24:09.733 [bus error] send message part 0: ERR: no signal
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 04 Januar 2021, 22:31:39
Zitat von: hErMeS am 04 Januar 2021, 00:34:18
Firmwareupdate ist durchgeführt.
Adapter direkt wieder ins Netz gebracht mit DHCP Setting, jedoch gab es hier einen kuriosen Fehler.
Danke fürs Feedback, ich schau mir das am Wochenende an
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 05 Januar 2021, 00:32:14
Nun zur letzten Gehäuse Version, mit dem was ich jetzt noch festgestellt habe

Verbreiterung der Aussparung für die Lasche im Unterteil (Laschen passen nicht in die Aussparung). Ob das nun mit meinem Drucker / Setup zusammenhängt, keine Ahnung.
Hier kommt die Abschrägung der Lasche zum Oberteil, Z-Naht und leichte Überextrusion an den Ecken zu tragen. Habe dies bei mir im Unterteil mit Messer größer geschnitzt.

Erweiterung der Gehäuse-Dimension. Die Platine passt fast ohne Toleranz in das innere. Wenn bei den fertigen Platinen diese Ausbrecher ebenfalls vorhanden sind, sollte John und co eine bessere Antwort liefern können ob hier nach den Seiten die Dimensionen erhöt werden müssen. Ich habe die Überreste bei mir abgemacht dass es dann passte.
Die Bohrungen sitzen, können allerdings minimalst kleiner dimensioniert seien. Habe die Z-Naht weggeschnitten, dann ging es mit etwas drücken rein.
Schaffung einer weiteren Auflage auf der ebus Seite im Bereich vom PI-Header (kommt auch beim Festschrauben vom ebus Kabel zu gute)

Auf Zug geht der Deckel jetzt nicht mehr ab.
Die LAN-Buchse könnte zum Problem werden durch die Nasen im Blech. Es ist gefummel den Deckel auf den LAN-Port zu setzen und die Nasen einzudrücken dass es drüber schnappt. Hier evtl im vorderen Bereich (ca 1/3) die Aussparung um 0,5mm auf beiden Seiten verbreitern.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 05 Januar 2021, 06:58:08
Hallo HeikoGr,
ZitatDas schreib ich ja schon die ganze Zeit, dass hier irgendwo ein Kurzschluss ist.
Du hattest natürlich recht. Der Kurzschluss war auch leicht messbar. Aber ganz schwer zu finden. Er liegt genau unter dem CP2102 Chip und ist so nicht zu sehen.
Ich habe das mit dem Printhersteller abgeklärt und es handelt sich um keinen Serienfehler sondern um einen einmaligen Fehler mit der Lötpaste.
Dass der Fehler bis zu dir durchgedrungen ist liegt nur daran dass wir ja diese Prints bei uns noch nicht getestet hatten.
LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 05 Januar 2021, 11:01:52
@galileo: 1000 Dank für die Info!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 05 Januar 2021, 12:36:21
Betreffend der Gehäuse:

Die Nasen entferne ich mit einem Elektronik Seitenschneider und dann über Schleifpapier gezogen damit die Ränder glatt werden.
Ob das wirklich Sinn macht das Gehäuse für den RPI Connector zu konstruieren bezweifle ich. Wer die RPI einsetzt steckt die Platine auf den Raspberry, da ist das Gehäuse nur störend.

Es hat sich bei den Reservierungen gezeigt, dass 2/3 der Besteller sich für den universellen Adapter entscheiden um zumindest alle Komponenten zu haben. Aber niemand wird Wemos und Ethernet gleichzeitig in der Praxis einsetzen, gleiches gilt ja auch für den RPI Connector, entweder RPI oder USB oder Wemos oder Ethernet. Wenn bei der Bestellung ein universeller Adapter bestellt wird, dann werde ich auch keinen Connector einlöten ( nur beilegen ) weil der dann in 99% der Fälle stören würde, eben beim Einbau in ein Gehäuse. Die Buchsen für Wemos oder W5500 allerdings stören da weniger, auch wenn sie sicher nicht alle gebraucht werden. Wer RPI bestellt, der bekommt den natürlich gelötet, aber der braucht auch dieses Gehäuse nicht weil der Raspi ja nicht Platz hat. Da wäre eventuell zu überlegen, ob ihr nicht ein Gehäuse für Raspi mit Connector herstellt. Aber dann gehen die Problem an, weil es doch einige unterschiedliche Typen von Raspis gibt die verschiedene Öffnungen brauchen. Man kann sich aber auf die neuen Typen einigen, Raspi 3 + 4.

Aber ansonsten finde ich es toll das ihr euch die Mühe macht ein Gehäuse zu konstruieren, obwohl sicher nur wenige einen 3D-Drucker haben.

LG
Reinhart
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 05 Januar 2021, 13:40:20
Zitat von: Reinhart am 05 Januar 2021, 12:36:21
Betreffend der Gehäuse:

Die Nasen entferne ich mit einem Elektronik Seitenschneider und dann über Schleifpapier gezogen damit die Ränder glatt werden.
Ob das wirklich Sinn macht das Gehäuse für den RPI Connector zu konstruieren bezweifle ich. Wer die RPI einsetzt steckt die Platine auf den Raspberry, da ist das Gehäuse nur störend.

Es hat sich bei den Reservierungen gezeigt, dass 2/3 der Besteller sich für den universellen Adapter entscheiden um zumindest alle Komponenten zu haben. Aber niemand wird Wemos und Ethernet gleichzeitig in der Praxis einsetzen, gleiches gilt ja auch für den RPI Connector, entweder RPI oder USB oder Wemos oder Ethernet. Wenn bei der Bestellung ein universeller Adapter bestellt wird, dann werde ich auch keinen Connector einlöten ( nur beilegen ) weil der dann in 99% der Fälle stören würde, eben beim Einbau in ein Gehäuse. Die Buchsen für Wemos oder W5500 allerdings stören da weniger, auch wenn sie sicher nicht alle gebraucht werden. Wer RPI bestellt, der bekommt den natürlich gelötet, aber der braucht auch dieses Gehäuse nicht weil der Raspi ja nicht Platz hat. Da wäre eventuell zu überlegen, ob ihr nicht ein Gehäuse für Raspi mit Connector herstellt. Aber dann gehen die Problem an, weil es doch einige unterschiedliche Typen von Raspis gibt die verschiedene Öffnungen brauchen. Man kann sich aber auf die neuen Typen einigen, Raspi 3 + 4.

Aber ansonsten finde ich es toll das ihr euch die Mühe macht ein Gehäuse zu konstruieren, obwohl sicher nur wenige einen 3D-Drucker haben.

LG
Reinhart
Hallo Reinhart,

ich werde kein Gehäuse für den RPI konstruieren. Es gibt zig Gehäuse für die jeweiligen Ausführungen in denen der Adapter zusätzlich Platz findet. Ein Loch für den EBUS ist da schnell gebohrt. Der Ausschnitt für den RPI Connector wird nach der Testerei auch verschwinden. Dieser war nur vorübergehend, damit der Betatest-Adapter, den hErMeS testet, ins Gehäuse passt.

Da der Adapter wohl bei den meisten Anwendern im Heizungskeller seinen Dienst verrichten wird finde ich es unhübsch wenn er dort "vollstaubt". Dies war für mich Grund genug das Gehäuse zu konstruieren. Ich werde nach den Anpassungen von hErMeS noch einen geschlossenen Deckel für den Wemos kreieren.

Damit sind dann aber auch die "Entwicklungsarbeiten" am Gehäuse abgeschlossen.

Nun warte ich auf den Erhalt meiner Adapter...

LG
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Scooby am 05 Januar 2021, 14:51:33
Hi,
Was haltet ihr von diesem Gehäuse ?
https://de.aliexpress.com/item/1005001849791044.html

Müsste doch eigentlich für die WLAN-Version passen, oder?
Mit Lüftungsschlitzen (auch tauglich mit extra Sensoren), für gerade mal 1,80€

Gruß
Scooby
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 05 Januar 2021, 18:56:00
Das Gehäuse was fuso2001 hier konstruiert ist halt genau auf die Platine abgestimmt und hat schon seine Vorteile. Außerdem ist es selbstgemacht was in diesem Forum viele Anwender schätzen weil es einen gewissen persönlichen Wert darstellt.

Ich habe auch schon mit Gehäuse vom Ali  (https://de.aliexpress.com/item/32888989421.html?spm=a2g0o.detail.1000014.6.7bcb6b87pFJyJk&gps-id=pcDetailBottomMoreOtherSeller&scm=1007.14976.205978.0&scm_id=1007.14976.205978.0&scm-url=1007.14976.205978.0&pvid=7b2530e6-be56-4afc-b33b-f8098f95db5c&_t=gps-id:pcDetailBottomMoreOtherSeller,scm-url:1007.14976.205978.0,pvid:7b2530e6-be56-4afc-b33b-f8098f95db5c,tpp_buckets:668%230%23131923%2361_668%23888%233325%238_4976%230%23205978%2314_4976%232711%237538%23118_4976%233104%239653%237_4976%234052%2318550%2342_4976%233141%239887%231_668%232846%238112%231997_668%232717%237565%23743_668%231000022185%231000066059%230_668%233422%2315392%23427_4452%230%23194213%230_4452%233474%2316498%23668_4452%234862%2322449%23722_4452%233098%239599%23259_4452%233564%2316062%23822)getestet, da gibt es viele, aber keines passt halt so genau wie das von fuso2001 ! Anzug von der Stange kann man auch kaufen, aber keiner passt so gut wie ein Maßanzug.

LG
Reinhart
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 06 Januar 2021, 11:20:47
Zitat von: hErMeS am 04 Januar 2021, 00:34:18
Adapter direkt wieder ins Netz gebracht mit DHCP Setting, jedoch gab es hier einen kuriosen Fehler.

ebusd lief die ganze Zeit. Adapter hat sich die IP geholt, war auch anpingbar, jedoch kam es hier nicht zu einem Reconnect.
Den ebusd neu durchzuladen hat nicht geholfen. Nur ein repower vom Adapter ging letztlich.
Die Firmware ist aktualisiert und sollte jetzt auch remote hang-up erkennen. Bitte mal testen.
Mit DHCP hatte das jetzt m.E. nichts zu tun.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Scooby am 06 Januar 2021, 12:00:24
Zitat von: Reinhart am 05 Januar 2021, 18:56:00
Das Gehäuse was fuso2001 hier konstruiert ist halt genau auf die Platine abgestimmt und hat schon seine Vorteile. Außerdem ist es selbstgemacht was in diesem Forum viele Anwender schätzen weil es einen gewissen persönlichen Wert darstellt.

Ich habe auch schon mit Gehäuse vom Ali getestet, da gibt es viele, aber keines passt halt so genau wie das von fuso2001 ! Anzug von der Stange kann man auch kaufen, aber keiner passt so gut wie ein Maßanzug.

LG
Reinhart

Danke für die Antwort.
Maßgescheidert ist auf jeden Fall besser, aber viele (wie ich) besitzen keinen 3D-Drucker, und Online-Anfertigungen sind weiterhin noch teuer.

Ich bestell mal das Gehäuse von Ali und poste mal ein paar Bilder sobald der Adapter drin sitzt.

Gruß Scooby
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 08 Januar 2021, 01:06:06
Zitat von: john30 am 06 Januar 2021, 11:20:47
Die Firmware ist aktualisiert und sollte jetzt auch remote hang-up erkennen. Bitte mal testen.
Mit DHCP hatte das jetzt m.E. nichts zu tun.

Wo finde ich die neue Version zum vertesten?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 08 Januar 2021, 05:34:19
https://github.com/eBUS/adapter/tree/master/firmware
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 08 Januar 2021, 13:00:34
Hallo,

der neue Maßanzug ist jetzt mit den Anmerkungen von hErMeS versehen:
Auf die Vergrößerung der Innenmaße habe ich verzichtet. Wenn ich es richtig verstanden habe wird der Adapter ohne Nasen ausgeliefert.
Den Ausschnitt für den RPI Stecker habe ich entfernt. (@hErMeS: wenn du nocheinmal drucken möchtest bekommst du ne Version mit dem Ausschnitt und tieferem LAN Adapter)
Auch die Wemos Variante ist jetzt online. Wer die externe Antenne nicht verwenden möchte kann die LAN Seite verwenden. Bei der Version mit Antenne hab ich ein zusätzliches Loch für nen Sensor eingefügt.

Vg Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Gurker am 10 Januar 2021, 09:26:19
Hi Frank,

kannst du die Klipse auch ggf. gegen Schraublaschen austauschen? Ich weiß solche Fragen sind immer doof, aber ich würde das Gehäuse gern drucken. Zur Not würde ich den Teil auch bearbeiten wenn ich ein 3D Modell abstauben könnte. Ansonsten nehm ich deine Arbeit aber auch gern so. Danke im Voraus!

gruß, Alex
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 10:53:25
Hat jemand von den Betatestern eigentlich einen Raspi 4 mit der Platine am laufen?

Wenn ja, was habt ihr in der Datei /boot/config.txt geändert?

Ich habe mich die Tage mal in das UART Thema eingelesen und die Doku versucht zu ergänzen. https://github.com/eBUS/adapter/pull/5

Interessant und neu für mich ist, dass der Raspi 4 mehrere PL011 UARTs hat und Bluetooth nicht mehr mit dem Software UART angesteuert werden muss (wenn man es aktiv lassen möchte). Seiteneffekt ist, dass der ebus Adapter dann auf dem /dev/ttyAMA1 anliegt und Bluetooth auf AMA0 bleibt.

Ich kann das leider derzeit nicht testen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: galileo am 11 Januar 2021, 11:09:36
Hallo an alle Gehäuse Entwickler !
Ich habe jetzt abklären können, dass die "Nasen" an den Print-Rändern in der Serie NICHT mehr vorkommen werden.
Diese waren nur dem ersten Test geschuldet, also nur jenen paar Stück die die Beta-Tester bekommen haben.
LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 11 Januar 2021, 11:12:35
Ich komme aus Zeigründen leider erst jetzt zum Testen, hoffentlich nicht zu Spät.

Ich habe probiert das Modul auf einem Raspi Zero 1.1 zum laufen zu bringen, leider ohne Erfolg.

Hier meine Vorgehensweise:

Neue Installation mit 2020-12-02-raspios-buster-armhf-lite, apt update && apt upgrade. Nach Neustart gemäß Anleitung (ebus-debian) mit apt ebusd installiert. Mir raspi-config die Serielle Konsole deaktiviert.

/boot/config.txt :

[all]
#dtoverlay=vc4-fkms-v3d
enable_uart=0

dtoverlay=miniuart-bt


/boot/cmdline.txt:

console=tty1 root=PARTUUID=6a256b17-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

root@raspberrypi:~# ls -l /dev/ttyA*
ls: cannot access '/dev/ttyA*': No such file or directory

kein ttyAMA0 device vorhanden.

Nun Jumper auf Raspi gesteckt, das Modul auf den Raspi Zero gesteckt (natürlich vorher ausgeschalten), eingeschaltet, die rote und gelbe led (ich habe die led's gedreht) leuchten sofort, die blaue zuerst schwach aber dann gleich stark.

leider immer noch kein device ttyAMA0 verfügbar.

ebusd gestartet:

ebusd.log:

2021-01-11 10:10:35.863 [main info] registered data handlers
2021-01-11 10:10:35.865 [bus notice] bus started with own address ff/04
2021-01-11 10:10:35.865 [bus notice] device invalid
2021-01-11 10:10:40.865 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:10:40.865 [bus notice] device invalid
2021-01-11 10:10:45.866 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:10:45.866 [bus notice] device invalid
2021-01-11 10:10:45.866 [main debug] performing regular tasks
2021-01-11 10:10:50.866 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:10:50.867 [bus notice] device invalid
2021-01-11 10:10:55.867 [main debug] performing regular tasks
2021-01-11 10:10:55.867 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:10:55.867 [bus notice] device invalid
2021-01-11 10:11:00.868 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:11:00.868 [bus notice] device invalid
2021-01-11 10:11:05.867 [main debug] performing regular tasks
2021-01-11 10:11:05.870 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:11:05.871 [bus notice] device invalid

Was kann da nicht richtig sein?

lg
Werner

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 11:13:59
Versuche mal enable_uart=1 in der config.txt
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 11 Januar 2021, 11:27:20
das ist das Ergebnis:

root@raspberrypi:~# ls -l /dev/ttyA*
crw-rw---- 1 root dialout 204, 64 Jan 11 10:24 /dev/ttyAMA0

root@raspberrypi:~# service ebusd start

root@raspberrypi:~# tail -f /var/log/ebusd.log
2021-01-11 10:25:56.736 [main info] reading file memory.csv
2021-01-11 10:25:56.818 [main info] successfully read file memory.csv
2021-01-11 10:25:56.819 [main info] reading file broadcast.csv
2021-01-11 10:25:56.901 [main info] successfully read file broadcast.csv
2021-01-11 10:25:56.901 [main info] read config files
2021-01-11 10:25:56.902 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:25:56.903 [main info] registering data handlers
2021-01-11 10:25:56.904 [main info] registered data handlers
2021-01-11 10:25:56.905 [bus notice] bus started with own address ff/04
2021-01-11 10:25:56.905 [bus notice] device invalid
2021-01-11 10:26:01.905 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:26:01.906 [bus notice] device invalid
2021-01-11 10:26:06.906 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:26:06.906 [bus notice] device invalid
2021-01-11 10:26:06.909 [main debug] performing regular tasks
2021-01-11 10:26:11.910 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:26:11.910 [bus notice] device invalid
2021-01-11 10:26:16.910 [main debug] performing regular tasks
2021-01-11 10:26:16.911 [bus error] unable to open enh:/dev/ttyAMA0: ERR: element not found
2021-01-11 10:26:16.912 [bus notice] device invalid
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 11:32:53
Ok. Da ist zumindest mal das /dev/ttyAMA0.

Kannst du noch EBUSD_OPTS posten? (Datei /etc/default/ebusd)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 11:34:32
Ach... hast du die PIC firmware aktualisiert?

https://adapter.ebusd.eu/picfirmware
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 11 Januar 2021, 11:40:44
EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyAMA0 --loglevel=debug --address=ff"

ich habe probiert die PIC Firmware zu flashen, bin aber am Download von ebuspicloader gescheitert, finde nirgendwo das binary für debian.

Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 11:58:30
Ach... hab in deinem ersten Posting übersehen, dass du eine alte Version von ebusd einsetzt.

Du musst evtl selbst kompilieren, oder schauen was john30 auf github released hat. Ich kann dir erst heute abend weiter helfen. Sorry
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 11 Januar 2021, 12:12:05
Dann warte ich auf heute Abend, danke für das Hilfeangebot.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 14:00:14
@john30: musst du noch dein Debian apt repository updaten? Ich kann noch immer nur 3.4 installieren.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: chons am 11 Januar 2021, 18:13:38
Zitat von: HeikoGr am 11 Januar 2021, 10:53:25
Hat jemand von den Betatestern eigentlich einen Raspi 4 mit der Platine am laufen?
Ja, ich.
Zitat von: HeikoGr am 11 Januar 2021, 10:53:25
Wenn ja, was habt ihr in der Datei /boot/config.txt geändert?
Wenn das System neu ist, dann sind folgende Schritte nötig:

[UART aktivieren]
Code Auswählen
sudo raspi-config
- 3 Interface Options
- P6 Serial Port
  - login shell deaktivieren [<no>]
  - serial port hardware aktivieren [<Yes>]
[BT funktion auf mini UART switchen]
Code Auswählen
dtoverlay=miniuart-bt muss in die /boot/config.txt eingetragen werden.
Die /boot/config.txt enthält final folgende Einträge:
Code Auswählen
enable_uart=1
dtoverlay=miniuart-bt
[Reboot]
Code Auswählen
sudo reboot now
[Kontrolle]
Code Auswählen
ls -al /dev/serial*
/dev/serial0 -> ttyAMA0
/dev/serial1 -> ttyS0

ttyAMA0 muss auf serial0 liegen
[Fertig]
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 18:17:53
Zitat von: chons am 11 Januar 2021, 18:13:38
Ja, ich.Wenn das System neu ist, dann sind folgende Schritte nötig:
[...]

Ja, das funktioniert auf jeden Fall!
Interessant für mich wäre aber zu wissen, ob das ganze auch funktioniert ohne
Code Auswählen
dtoverlay=miniuart-bt. Wenn ich es richtig verstehe sollte der ebus Adapter dann auf ttyAMA1 laufen.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: chons am 11 Januar 2021, 18:59:59
Code Auswählen
dtoverlay=miniuart-bt
Switcht nur die BT-Funktion auf den "mini UART" schau mal hier (https://www.raspberrypi.org/documentation/configuration/uart.md)
ttyAMA0 ändert sich dadurch nicht und nein mit /dev/serial1 funktioniert es nicht.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 19:08:35
Genau!

auf der Doku-Seite steht aber auch, dass der RPI4 4 weitere ,,echte" UARTs hat. Daher habe ich recherchiert, ob man Bluetooth bei einem RPI4 wirklich mit der Software emulation eines UART betreiben muss. Das einzige belastbare, was ich dazu gefunden habe, war der Forumeintrag welchen ich oben verlinkt habe. Da schreibt ein Mitarbeiter der Raspi-Foundation, dass man mit enable_uart=1 alleine (ohne weitere Overlays) bewerkstelligt, dass das Bluetooth beim UART1 (ttyAMA0) bleibt und die seriellen Pins GPIO 14 und 15 den UART2 (ttyAMA1) bekommen.

Das würde ich gerne getestet wissen. Reine Neugierde
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 20:23:42
@wseifert: wenn ich es richtig verstehe, hat john30 das repository mit den fertigen Installationspaketen noch  nicht aktualisiert.

Du kannst ebusd also selbst kompilieren (steht glaub ich auf Seite 2 dieses Threads) oder du installierst das binary Paket von Hand.

Das müsste so gehen (kannst gerade nicht testen)

Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 11 Januar 2021, 21:45:59
Zitat von: HeikoGr am 11 Januar 2021, 20:23:42
@wseifert: wenn ich es richtig verstehe, hat john30 das repository mit den fertigen Installationspaketen noch  nicht aktualisiert.

Du kannst ebusd also selbst kompilieren (steht glaub ich auf Seite 2 dieses Threads) oder du installierst das binary Paket von Hand.

Das müsste so gehen (kannst gerade nicht testen)


  • Evtl musst du wget installieren: 'sudo apt-get install wget'
  • mit 'wget https://github.com/john30/ebusd/releases/download/v21.1/ebusd-21.1_armhf-stretch_mqtt1.deb' das aktuelle ebusd laden
  • per 'sudo apt install ~/ebusd-21.1_armhf-stretch_mqtt1.deb' das Paket installieren (wenn es im Homeordner liegt)

Da sehe ich leider nicht durch, bin kein Linux Mann, nur Windows ...
Ich werde wohl oder übel warten bis john30 das Repo aktualisiert hat.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 22:01:19
nachvollziehbar - auch wenn ich dir gerne mehr Mut aufschwätzen würde :-D
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 11 Januar 2021, 22:53:27
wegen RPI4, UART und Bluetooth

ich habe oben einen Forumspost bei RaspberryPi.org versprochen, aber nur im github pull request der Adapter 3 Doku erwähnt:
https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=244827&start=25#p1590882

wenn ich es noch einmal in Ruhe durchlese komme ich zu dem Schluss, dass ich falsch lag.
Man kann die Pins 14 und 15 nur mit dem UART0 (ttyAMA0) oder miniUART (ttyS0) ansprechen.

Ich hatte die Hoffnung, dass man einen von den neuen UARTs hier verwenden kann.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 12 Januar 2021, 11:29:18
Ich habe nun doch probiert mit meinen wenigen Linux Kentnissen die Ratschläge von HeikoGr zu befolgen, siehe da, das manuelle Installieren des Binary Paketes hat funktioniert  :D

eBUS Adapter 3.0 läuft auf einem Raspberry Pi Zero 1.1!

Meine Konfig:

Raspberry Pi Zero 1.1

2020-12-02-raspios-buster-armhf-lite

ebusd-21.1_armhf-stretch_mqtt1.deb

mit raspi-config: Interface Options - Serial Port - login shell over serial <No>, serial port hardware enabled <Yes>

/etc/default/ebusd: EBUSD_OPTS="--scanconfig --accesslevel=* --latency=20000 -d enh:/dev/ttyAMA0 --loglevel=debug --address=ff --configpath=/etc/ebusd"

/boot/config.txt: [all] dtoverlay=miniuart-bt

/boot/cmdline.txt: console=tty1

dann sollte ls -l /dev/ttyA*
crw-rw---- 1 root dialout 204, 64 Jan 11 21:04 /dev/ttyAMA0

bringen und nach dem Start von ebusd

netstat -tulpn | grep LISTEN
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      563/ebusd

bringen, für mich wichtig, da ich mit openHAB3 mein Smarthome "dirigiere" und mittels  des openhab-ebus-binding von csowada (https://github.com/csowada/openhab-ebus-binding) auf den eBUS zugreifen möchte (was auch soweit ich bisher sehe funktioniert).

lg Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 14 Januar 2021, 17:15:58
Nun läuft zwar ebusd, bekommt auch Daten vom eBUS 3 Adapter, aber mit der csv Datei für Ochsner OTE 3 kann ebusd offensichtlich nichts anfangen. Mit ebusctl i bekomme ich folgende Ausgabe:

version: ebusd 21.1.v21.1
update check: version 3.4 available
access: *
signal: acquired
symbol rate: 20
max symbol rate: 105
reconnects: 0
masters: 4
messages: 45
conditional: 0
poll: 0
update: 3
address 01: master #6
address 03: master #11
address 10: master #2
address 13: master #12
address 15: slave #2

Eigentlich sollte bei einer der master Addressen noch mehr stehen, etwa welche Heizung gefunden wurde. Oder liege ich da falsch? Ich verwende die 22102.csv aus ebus 1 da sonst keine csv Dateien für Ochsner OTE zu bekommen sind. Mit eBUS Adapter 2.2 über USB an den Raspi Zero und einer ältern ebusd Version aus 2018 hat es besser funktioniert.
Hat da wer für mich einen Tip oder vielleicht eine csv Datei=

lg Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 14 Januar 2021, 19:38:48
du hast eine uralte Version von ebusd, die kann den enhanced Modus nicht!

Installiere die neueste Version  (https://forum.fhem.de/index.php/topic,116418.msg1109955.html#msg1109955)und passe die config so an dass deine 22102.csv geladen wird!

Code Auswählen
--configpath=/etc/ebusd

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: HeikoGr am 14 Januar 2021, 20:06:29
Ich glaub da liegst du falsch, Reinhart. John30 hat die Versionierung geändert  8)
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 14 Januar 2021, 20:40:59
Das ist die neueste Version, ich habe Sie wie HeikoGr empfohlen mit 'wget https://github.com/john30/ebusd/releases/download/v21.1/ebusd-21.1_armhf-stretch_mqtt1.deb' installiert. Die config ist schon so eingerichtet dass 22102.csv geladen wird. Ohne diese csv geht gar nichts ...

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 14 Januar 2021, 21:08:59
Zitat von: wseifert am 14 Januar 2021, 20:40:59
Das ist die neueste Version, ich habe Sie wie HeikoGr empfohlen mit 'wget https://github.com/john30/ebusd/releases/download/v21.1/ebusd-21.1_armhf-stretch_mqtt1.deb' installiert. Die config ist schon so eingerichtet dass 22102.csv geladen wird. Ohne diese csv geht gar nichts ...
was spricht denn das ebusd Logfile?
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 14 Januar 2021, 21:32:52
Hmmm ..

da hätte ich von selber draufkommen können da nachzuschauen.
Da werden einige der Daten dekodiert, aber nicht alle:

Code Auswählen

2021-01-14 20:20:12.339 [update notice] received unknown MM cmd: 131005030a0100000047ffff3f0000
2021-01-14 20:20:12.925 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e80300006601
2021-01-14 20:20:12.926 [update notice] received read temperature buffer QQ=01: 96;0;0d;02;1000;0;35.8
2021-01-14 20:20:13.962 [network debug] [00007] wait for result
2021-01-14 20:20:13.963 [main debug] performing regular tasks
2021-01-14 20:20:14.082 [update info] received MS cmd: 011506210402b50040 / 0a35810000ff0000000100
2021-01-14 20:20:14.082 [update notice] received read heatpump mode QQ=01: 53;1;00;00;255;0;Heizbetrieb
2021-01-14 20:20:15.191 [update info] received MS cmd: 011506210402c60040 / 0a46410428ffff0000b1ac
2021-01-14 20:20:15.192 [update notice] received unknown MS cmd: 011506210402c60040 / 0a46410428ffff0000b1ac
2021-01-14 20:20:15.968 [network debug] [00007] wait for result
2021-01-14 20:20:16.300 [update info] received MS cmd: 011506210402c80040 / 0a4841042a9f0500002305
2021-01-14 20:20:16.300 [update notice] received unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500002305
2021-01-14 20:20:17.409 [update info] received MS cmd: 011506210400800040 / 0a00800d02f4010cfe0500
2021-01-14 20:20:17.412 [update notice] received read temperature outside QQ=01: 0;0;0d;02;500;-500;0.5
2021-01-14 20:20:17.972 [network debug] [00007] wait for result
2021-01-14 20:20:18.307 [update info] received MM cmd: 031005030a010148644b20ff3f0000
2021-01-14 20:20:18.309 [update notice] received unknown MM cmd: 031005030a010148644b20ff3f0000
2021-01-14 20:20:18.519 [update info] received MS cmd: 011506210400840040 / 0a04800d02e80300004e02
2021-01-14 20:20:18.521 [update notice] received read temperature water QQ=01: 4;0;0d;02;1000;0;59.0
2021-01-14 20:20:19.318 [update info] received MM cmd: 131005030a0100000047ffff3f0000
2021-01-14 20:20:19.323 [update notice] received unknown MM cmd: 131005030a0100000047ffff3f0000
2021-01-14 20:20:19.578 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e80300006601
2021-01-14 20:20:19.580 [update notice] received read temperature buffer QQ=01: 96;0;0d;02;1000;0;35.8
2021-01-14 20:20:19.976 [network debug] [00007] wait for result
2021-01-14 20:20:19.978 [main debug] performing regular tasks
2021-01-14 20:20:20.385 [update info] received MM cmd: 100305010aee5a3c0000a001000000
2021-01-14 20:20:20.387 [update notice] received unknown MM cmd: 100305010aee5a3c0000a001000000
2021-01-14 20:20:20.691 [update info] received MS cmd: 011506210402b50040 / 0a35810000ff0000000100
2021-01-14 20:20:20.693 [update notice] received read heatpump mode QQ=01: 53;1;00;00;255;0;Heizbetrieb
2021-01-14 20:20:21.073 [update info] received MM cmd: 101305010a00000a00000001000100
2021-01-14 20:20:21.075 [update notice] received unknown MM cmd: 101305010a00000a00000001000100
2021-01-14 20:20:21.668 [update info] received BC cmd: 10fe070009800026552114010421
2021-01-14 20:20:21.671 [update notice] received update-read master datetime QQ=10: 0.500;21:55:26;14.01.2021
2021-01-14 20:20:21.925 [update info] received MS cmd: 011506210402c60040 / 0a46410428ffff0000b1ac
2021-01-14 20:20:21.927 [update notice] received unknown MS cmd: 011506210402c60040 / 0a46410428ffff0000b1ac
2021-01-14 20:20:21.983 [network debug] [00007] wait for result
2021-01-14 20:20:22.940 [update info] received MS cmd: 011506210402c80040 / 0a4841042a9f0500002305
2021-01-14 20:20:22.942 [update notice] received unknown MS cmd: 011506210402c80040 / 0a4841042a9f0500002305
2021-01-14 20:20:23.988 [network debug] [00007] wait for result
2021-01-14 20:20:24.097 [update info] received MS cmd: 011506210400800040 / 0a00800d02f4010cfe0500
2021-01-14 20:20:24.099 [update notice] received read temperature outside QQ=01: 0;0;0d;02;500;-500;0.5
2021-01-14 20:20:25.203 [update info] received MS cmd: 011506210400840040 / 0a04800d02e80300004e02
2021-01-14 20:20:25.205 [update notice] received read temperature water QQ=01: 4;0;0d;02;1000;0;59.0
2021-01-14 20:20:25.992 [network debug] [00007] wait for result
2021-01-14 20:20:25.994 [main debug] performing regular tasks
2021-01-14 20:20:26.315 [update info] received MS cmd: 011506210400e00040 / 0a60800d02e80300006601
2021-01-14 20:20:26.317 [update notice] received read temperature buffer QQ=01: 96;0;0d;02;1000;0;35.8
2021-01-14 20:20:26.510 [update info] received MM cmd: 031005030a010148644b21ff3f0000
2021-01-14 20:20:26.512 [update notice] received unknown MM cmd: 031005030a010148644b21ff3f0000


Offensichtlich liegt das Problem beim eBUS Binding von OpenHAB, da bekomme ich nichts rüber.

LG Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: pc1246 am 15 Januar 2021, 07:26:48
Moin
@wseifert: Kannst Du nicht bitte auch Codetags benutzen!? Das geht auch nachtraeglich! Das ist der Button mit dem "#" ueber den Smilies!
Danke und Gruss
Christoph
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 15 Januar 2021, 09:11:55
Zitat von: pc1246 am 15 Januar 2021, 07:26:48
Moin
@wseifert: Kannst Du nicht bitte auch Codetags benutzen!? Das geht auch nachtraeglich! Das ist der Button mit dem "#" ueber den Smilies!
Danke und Gruss
Christoph

Danke für den Hinweis, war gestern Abend nach der Jagt auf eine 4-Beinige Ausreisserin etwas Erledigt.

LG Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 15 Januar 2021, 10:32:20
Zitat von: HeikoGr am 14 Januar 2021, 20:06:29
Ich glaub da liegst du falsch, Reinhart. John30 hat die Versionierung geändert  8)

ah ja, das habe ich dann verschlafen, habe gerade auf Github nachgeschaut, die ist tatsächlich von 3.4 auf 22.1 gewechselt!
Danke für den Hinweis!

Code Auswählen
21.1

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 16 Januar 2021, 16:45:47
Hallo @john30,

kann es sein das in der Wemos Firmware noch ein kleiner Bug steckt? Möglicherweise habe ich eine ähnliche Meldung auch übersehen.
Im Bild siehst du rot markiert das Gateway, hier angegeben mit 255.255.255.0. Ich denke das es sich hierbei nicht um das Gateway sondern um die Subnetzmaske handelt. Diese ist allerdings mit der Angabe 24 als Feld Mask-length schon angegeben.
Im Normallfall ist das wohl nicht so wichtig weil wahrscheinlich selten ein Ebus-Daemon über ein Subnetz hinaus mit dem Adapter kommuniziert. Vielleicht magst du das aber ja noch korrigieren bevor ihr die Adapter versendet...

Gruß
Frank
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 16 Januar 2021, 16:48:24
Zitat von: fuso2001 am 16 Januar 2021, 16:45:47
Im Bild siehst du rot markiert das Gateway, hier angegeben mit 255.255.255.0. Ich denke das es sich hierbei nicht um das Gateway sondern um die Subnetzmaske handelt. Diese ist allerdings mit der Angabe 24 als Feld Mask-length schon angegeben.
bei DHCP wird die Einstellung der Maske und des Gateways nicht genutzt. Mir war es nur zu mühsam, auch noch Javascript einzubauen, um die irrelevanten Felder zu verstecken.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: fuso2001 am 16 Januar 2021, 16:56:02
Zitat von: john30 am 16 Januar 2021, 16:48:24
bei DHCP wird die Einstellung der Maske und des Gateways nicht genutzt. Mir war es nur zu mühsam, auch noch Javascript einzubauen, um die irrelevanten Felder zu verstecken.
Ja, kann ich gut verstehen. Bin selber Software-Entwickler und weiss wovon du redest :)
Wenn das Feld bei der festen IP korrekt verdrahtet ist passt das ja dann auch.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 17 Januar 2021, 16:15:33
Kurze Info, weil das anscheinend für Verwirrung gesorgt hat:
Inzwischen ist der Support fürs enhanced protocol im git master Branch gelandet und ein neues Release gibt es auch schon, nämlich Version 21.1 (https://github.com/john30/ebusd/releases/tag/v21.1).
Der enhanced_device Branch ist damit hinfällig und wird nicht weiter fortgesetzt.
Wenn also von Euch nochmal den letzten Stand testen mag, dann mitte auf den master Branch schwenken mit
Code Auswählen
git checkout origin/master.
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: hErMeS am 17 Januar 2021, 21:37:12
Von mir auch noch eine kleine Info, falls jemand keinen Unix Rechner zur Hand haben sollte zwecks Firmware-Update oder ähnlichem.

Durch WSL (Windows Subsystem for Linux) ist es möglich mittels Windows ein Unix laufen zu lassen.
Ich habe hier jetzt den ebusd (Ubuntu im WSL) kompliliert und anschließend endlich mal die letzte Firmware installiert, da die Platine nach drei Resets immer noch keinen Reconnect mit dem ebusd wollte  :o
(habe meinen ebusd Testrechner umgebaut und musste den daher offline nehmen)

Code Auswählen
Device ID: 30b0 (PIC16F15356)
Device revision: 0.1
Bootloader version: 1 [0a6c]
Firmware version: 1 [32f6]
MAC address: ae:b0:53:22:11:90
IP address: DHCP

New firmware version: 1 [a220]
erasing flash: done.
flashing: 0x0400 - 0x3806

0x0400 ................................................................
0x0800 ................................................................
0x0c00 ................................................................
0x1000 ................................................................
0x1400 ................................................................
0x1800 ................................................................
0x1c00 ................................................................
0x2000 ................................................................
0x2400 ................................................................
0x2800 ................................................................
0x2c00 ................................................................
0x3500 .................................................
flashing finished.
flashing succeeded.

Mal sehen ob die letzte Firmware das Problem behebt  :D


edit:
Fehler nicht mehr vorhanden
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 19 Januar 2021, 08:34:55
Zitat von: hErMeS am 17 Januar 2021, 21:37:12
Von mir auch noch eine kleine Info, falls jemand keinen Unix Rechner zur Hand haben sollte zwecks Firmware-Update oder ähnlichem.

Durch WSL (Windows Subsystem for Linux) ist es möglich mittels Windows ein Unix laufen zu lassen.
Ich habe hier jetzt den ebusd (Ubuntu im WSL) kompliliert und anschließend endlich mal die letzte Firmware installiert, da die Platine nach drei Resets immer noch keinen Reconnect mit dem ebusd wollte  :o
(habe meinen ebusd Testrechner umgebaut und musste den daher offline nehmen)
das geht auch mit einer Cygwin Umgebung und mit Docker für Windows, sowie mit Hypervisor und Virtualbox. Es wäre sogar denkbar, zumindest den ebuspicloader auch für Windows native zu komplieren, muss ich mir mal anschauen.

Zitat von: hErMeS am 17 Januar 2021, 21:37:12
Mal sehen ob die letzte Firmware das Problem behebt  :D
Fehler nicht mehr vorhanden
super, Danke fürs Testen!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: wseifert am 19 Januar 2021, 12:21:29
Ich habe heute wie in diesem Thread am Anfang beschrieben die Firmware auf meinem eBUS 3.0 Adapter auf den neuesten Stand (20210106-offset.hex) gerbracht. Hat auf dem Pi Zero 1.1 anstandslos funktioniert. Ich betreibe den Pi Zero mit einem USB-LAN Adapter von plugable (USB2-OTGE100), der wird native unterstützt und hat nur ein paar € gekostet. Einfach in den USB Port gesteckt und LAN geht.
Mit top zeigt sich dass die Resourcen des Pi Zero völlig ausreichend sind:

Code Auswählen

top - 11:19:40 up 13 min,  1 user,  load average: 0.20, 0.26, 0.25
Tasks:  73 total,   1 running,  72 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  2.4 sy,  0.0 ni, 97.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    431.9 total,    191.7 free,     32.1 used,    208.1 buff/cache
MiB Swap:    100.0 total,    100.0 free,      0.0 used.    347.2 avail Mem


lg Werner
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 19 Januar 2021, 17:30:31
ah super wenn das am Zero genau so gut geht!
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 19 Januar 2021, 17:41:28
Ich habe heute mal mit einem Raspi mit Display experimentiert!

Im Prinzip geht das sehr gut, man muss sich lediglich in Fhem einen eigenen Raum mit den Dingen zurecht richten, die dann auch angezeigt werden sollen. Das Display ist einfach zu installieren, steckt aber am Expansionsport und somit ist die Variante RPI nicht möglich weil der Connector schon mit dem Display belegt ist.
Wer den Raspi in der Nähe am Heizgerät sitzen hat, der hat dann gleich eine Kontrolle der Messwerte die am eBus kommen ohne dazu etwas ändern zu müssen als man eh schon in Fhem hat. Auf diesem Raspi muss auch kein Fhem laufen, weil es einfach eine Browseranwendung ist. Mit F11 läßt sich ein Vollbild darstellen und die Linkleisten verschwinden.

Zusätzlich eine kleine Tastatur erleichtert die Eingabe, speziell wenn Passwörter etc eingegeben werden müsse. Ich habe für das Display mit Gehäuse 14.- € bezahlt. Getestet habe ich auch auf einem Raspi 2, da ist es sehr langsam, aber auf einem Raspi 3b geht das schon wesentlich flotter. Das Display hat eine Auflösung von 480 x 320 und ein Eingabestift für den Touchscreen ist mit dabei.

LG
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: john30 am 19 Januar 2021, 20:31:40
Zitat von: HeikoGr am 11 Januar 2021, 14:00:14
@john30: musst du noch dein Debian apt repository updaten? Ich kann noch immer nur 3.4 installieren.
das repo ist inzwischen auch aktualisiert
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 22 Januar 2021, 17:07:49
Der Versand der ersten Charge der eBus Adapter (https://forum.fhem.de/index.php/topic,117350.msg1124607.html#msg1124607) beginnt!

LG
Reinhart
Titel: Antw:eBUS Adapter 3.0 Betatest
Beitrag von: Reinhart am 25 Januar 2021, 10:37:07
für die Inbetriebnahme der V3 gibt es jetzt einen eigenen Thread (https://forum.fhem.de/index.php/topic,118143.msg1125668.html#msg1125668), deshalb habe ich den  Betatest hier geschlossen!
Danke an alle die hier mitgemacht haben und uns wertvolles Feedback lieferten!

LG
Reinhart
Nur Text | Text mit Bildern