KONNEKTING Gehversuche

[mm83]

Hallo, ich mache gerade meine ersten Gehversuche mit Konnekting und komme leider aktuell nicht weiter, vielleicht kann mir hier jemand einen Tipp geben.

Mein Aufbau sieht derzeit so aus:

KNX-Bus -- BCU (Siemens 5WG1117-2AB12) -- Pegelwandler (5V-3,3V) -- ESP8266 (Wemos D1 Pro)

• Gehe ich mit einem FTDI232 direkt an die BCU erhalte ich eine Ausgabe wenn ein Telegram über den KNX-Bus läuft
• Gehe ich mit einem FTDI232 über den Pegelwandler an die BCU erhalte ich ebenfalls eine Ausgabe wenn ein Telegram über den KNX-Bus läuft
• der ESP hängt an einer ausreichend dimensionierten Spannungsversorgung, nicht am PC
• auf der ESP läuft der "Communication Test"-Sketch mit Softwareserial-Ausgabe
• Über den Softwareserial erhalte ich mit dem FTDI232 unten angegebene Ausgabe
• Verbinde ich TX mit RX und RX mit TX vom ESP8266 mit dem Pegelwandler und klemme den FTDI232 dazu, so bekomme ich über diesen keine Ausgabe mehr, weder auf der 3,3V noch auf der 5V Seite. Trenne ich die Verbindung zwischen ESP8266 und Pegelwandler, liefert der FTDI232 wieder eine Ausgabe

Hat jemand eine Idee wo mein Fehler steckt? Danke!

18:32:24.801 -> SDK:2.2.2-dev(38a443e)/Core:3.0.2=30002000/lwIP:STABLE-2_1_2_RELEASE/glue:1.2-48-g7421258/BearSSL:6105635
18:32:27.812 -> DEBUG! free ram: 51832 bytes
18:32:27.882 -> Initialize KonnektingDevice
18:32:27.882 -> 15/7/255 = 0x7fff
18:32:27.882 -> Toggle ProgLED, actual state: 0
18:32:27.882 -> PrgLed 0
18:32:27.882 -> PrgState 0
18:32:27.882 -> Manufacturer: 0xdead Device: 0xff Revision: 0x00
18:32:27.882 -> numberOfCommObjects: 2
18:32:27.882 -> memRead: index=0x00 using fctptr data=0x7f
18:32:27.882 -> _deviceFlags: 01111111
18:32:27.882 -> ->EEPROM
18:32:27.882 -> memRead: index=0x01 using fctptr data=0x10
18:32:27.882 -> memRead: index=0x02 using fctptr data=0xc7
18:32:27.882 -> memRead: index=0x0a using fctptr data=0x3f
18:32:27.882 -> memRead: index=0x0b using fctptr data=0x07
18:32:27.882 -> memRead: index=0x0c using fctptr data=0x80
18:32:27.882 -> ComObj index=0 HI=0x3f LO=0x07 GA=0x3f07 setting=0x80 active=1
18:32:27.882 -> memRead: index=0x0d using fctptr data=0x3f
18:32:27.882 -> memRead: index=0x0e using fctptr data=0x08
18:32:27.882 -> memRead: index=0x0f using fctptr data=0x80
18:32:27.882 -> ComObj index=1 HI=0x3f LO=0x08 GA=0x3f08 setting=0x80 active=1
18:32:27.882 -> IA: 0x10c7
18:32:27.882 -> Reset triggered!
18:32:27.882 -> Reset attempts: 9
18:32:28.848 -> Reset attempts: 8
18:32:29.885 -> Reset attempts: 7
18:32:30.853 -> Reset attempts: 6
18:32:31.859 -> Reset attempts: 5
18:32:32.865 -> Reset attempts: 4
18:32:33.857 -> Reset attempts: 3
18:32:34.849 -> Reset attempts: 2
18:32:35.853 -> Reset attempts: 1
18:32:36.863 -> Reset attempts: 0
18:32:37.867 -> Reset failed, no answer from TPUART device
18:32:37.867 -> Init Error!
18:32:37.867 -> KnxDevice startup status: 0x02
18:32:37.867 -> Knx init ERROR. Retry after reboot!!
18:32:38.386 -> ESP restart
18:32:38.560 ->

[Albatros62]

Zunächst erst einmal Willkommen im Club.
Wenn ich das richtig interpretiere, dann schaltest du zwei Ausgänge (Tx FTDI und Tx ESP) auf einen Eingang (Rx BCU). Das kann nicht funktionieren. Du Kannst ein und denselben UART auch nicht für KNX-Kommunikation und Debugging benutzen. Wenn du mit dem FTDI den Busverkehr mitlesen möchtest, dann lass Tx weg. Benötigst du Debugging, dann nimm dafür einen anderen UART.

Konnekting initialisiert die BCU und wartet dabei auf eine Antwort. Kommt die Antwort nicht, dann gibt es einen Init Error und der ESP wird neu gestartet.

Gruß
Frank

[mm83]

Hallo Frank, danke für das Feedback!

Den Tx fom FTDI habe ich bei all den o.g. Aktionen nicht verwendet, ich habe den nur stellenweise den Rx des FTDI dazugeklemmt um zu sehen ob sich da was tut.

Einen Fehler habe ich evt. gefunden (wer lesen kann ist klar im Vorteil), im Code des Sketches steht für den ESP8266, der Kommentar:

// swaped Serial on D7(GPIO13)=RX/GPIO15(D8)=TX

ok, damit habe ich den Pegelwandler auf die beiden PINs gesetzt. Jetzt erhalte ich über den Tx des ESP die folgende Ausgabe (die Ausgabe kommt mit 74880 Baud, eingestellt sind für den Debug eigentlich 115200 Baud), und eigentlich sollte als Debug PIN 4 laufen, hierüber erhalte ich aber nichts brauchbares, weder mit 74880 Baud, noch mit 115200 Baud)

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

waiting for host

Ob ich damit jetzt wirklich weiter bin kann ich noch nicht sagen...

[Albatros62]

Allzu viel habe ich mit dem ESP noch nicht gemacht, deshalb alles nur theoretisch ohne praktische Erfahrung. Konnekting ruft Serial.swap() auf, so dass der UART0 auf D7 und D8 liegt. Hier muss die BCU über den Pegelwandler angeschlossen werden. Zum Debuggen wird UART1 verwendet. Daher muss der FTDI auf GPIO2 (D4) angeschlossen werden (nur Rx des FTDI).
Was meinst du mit PIN 4?

[mm83]

[...] UART0 auf D7 und D8 liegt. Hier muss die BCU über den Pegelwandler angeschlossen werden. Zum Debuggen wird UART1 verwendet. Daher muss der FTDI auf GPIO2 (D4) angeschlossen werden (nur Rx des FTDI).

So gemacht

Was meinst du mit PIN 4?

Damit meinte ich D4 🙈

Aktueller Status:

• Ausgabe erfolgt über D4 und Tx (jeweils mit 74880 Baud, statt mit dem im Sketch definierten 115200 Baud)

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

waiting for host

Nachtrag: Die Meldung ist wohl auf einen Fehler im ESP zurückzuführen und nicht KONNEKTING spezifisch. Hat generell jemand die Kombi KNX - BCU - ESP8266 erfolgreich mit KONNEKTING in Betrieb nehmen können? Was gibt es dabei ggf. noch zu berücksichtigen?

[Techi]

Also allgemein zum ESP8266
GPIO0 (D3), GPIO2 (D4), GPIO15 (D8) sind mit Bedacht zu verwenden.
Diese 3 Pins in Kombination werden im Bootcode des ESP8266 ausgewertet und entscheiden wie der weitere Bootvorgang stattfindet.
Wenn du ganz normal , also dein eigenes Program aus dem Flash starten möchtest, dann müssen die Pegel an diesen drei Pins wie folgt sein
GPIO0 (D3) = 1 (3.3V) , GPIO2 (D4) = 1 (3.3V), GPIO15 (D8) = 0 (0V/GND)
Ich vermute, dass durch deine aktuelle Beschaltung (z.B. durch Pegelwandler/232 Chip) genau dieser zustand während dem Powerup nicht vorhanden ist.

Noch ein Hinweis.
Wenn du für dein Projekt nicht unbedingt WLAN benötigst, dann würde ich dringen empfehlen keinen ESP8266 zu verwenden.
Ich hab gerade bezüglich Stromversorgung über KNX damit keine gute Erfahrung gemacht.

[Eugenius]

Hi,
ESP8266 ist ein wenig "speziell"... abgesehen von sehr hohem Energievebrauch, und aus dem Grund nicht direkt aus dem KNX Bus versorgbar, sondern nur mit exnerner Energiequelle und einer optischen Isolierung zur BCU, switschen wir direkt im Code die UART pins...
https://gitlab.com/konnekting/Konnek...pUart.cpp#L118

d.h. man nutzt nicht mehr 1/3 sondern 13/15:
http://arduino.esp8266.com/Arduino/v...reference.html

Das Problem bei ESP8266 ist, dass er nur einen nutzbaren UART hat und wenn da dran noch CH240 oder FTDI oder was auch immer hängt, funktionieren viele BCUs nicht mehr korrekt. Mit der SWAP-Funktion kann man es umgehen, verliert aber 2 PINs... wir schauen ob wir diese Funktion doch ausbauen, dann kann jeder selbst entscheiden ob er das will oder nicht.

[mm83]

Vielen Dank für Euer Feedback Techi und Eugenius, zumindest kenne ich jetzt die Ursache.

Ich habe aktuell bereits einige ESP8266 am laufen, die hätte ich gerne um die KNX-Anbindung erweitert, aber unter den Umständen nehme ich vielleicht zu Beginn erst einmal einen weniger "speziellen" µC, bevor ich mich dann an die Probleme mit dem ESP heranwage.

Könnt ihr mir einen anderen preisgünstigen & kompakten (für Unterputzdose geeigneten) 32bit µC empfehlen, der für den Einstieg geeignet ist (ohne große Ansprüche an PINs und Funktionen, noch weniger als der ESP werden wohl die meisten nicht haben)?

Für den zweiten Schritt: Gibt es für den ESP8266 einen Referenzaufbau oder Liste von Hardwarekomponenten (Serielles Interface für die Entwicklung/Debug, Pegelwandler, Isolierung gegenüber dem Bus), welche in Kombination erfolgreich getestet wurden?

[Albatros62]

Ich habe aktuell bereits einige ESP8266 am laufen, die hätte ich gerne um die KNX-Anbindung erweitert, aber unter den Umständen nehme ich vielleicht zu Beginn erst einmal einen weniger "speziellen" µC, bevor ich mich dann an die Probleme mit dem ESP heranwage.

Sehr gute Idee.

Könnt ihr mir einen anderen preisgünstigen & kompakten (für Unterputzdose geeigneten) 32bit µC empfehlen, der für den Einstieg geeignet ist (ohne große Ansprüche an PINs und Funktionen, noch weniger als der ESP werden wohl die meisten nicht haben)?

Der Seeeduino XIAO wäre da ein Kandidat. Es ist ein ATSAMD21G18A-MU und entspricht damit dem Standardprozessor für Konnekting. Er ist sehr klein, kann aber über I2C oder SPI erweitert werden. USB für Programmierung bzw. Debugging ist vom UART für Konnekting getrennt. Falls mehr Platz vorhanden ist, kann man auch einen Zero o.Ä. nehmen.

[Ing-Dom]

Adafruit ItsyBitsy M0
Wemos SAMD Mini

[mm83]

Irgendwie habe ich mit diesem Projekt kein Glück, ein Seeeduino XIAO ist gestern eingetroffen, prinzipiell funktioniert er (wird erkannt, Blink-Sketch wird geflasht und läuft), auch den Konnekting Communication_test kann ich flashen, allerdings kann ich wieder keine Verbindung zum Bus herstellen.

Serielle Ausgabe:

DEBUG! free ram: 28531 bytes
Initialize KonnektingDevice
15/7/255 = 0x7fff
Toggle ProgLED, actual state: 0
PrgLed 0
PrgState 0
Manufacturer: 0xdead Device: 0xff Revision: 0x00
numberOfCommObjects: 2
memRead: index=0x00 using fctptr data=0x7f
_deviceFlags: 01111111
->EEPROM
memRead: index=0x01 using fctptr data=0x10
memRead: index=0x02 using fctptr data=0xc7
memRead: index=0x0a using fctptr data=0x3f
memRead: index=0x0b using fctptr data=0x07
memRead: index=0x0c using fctptr data=0x80
ComObj index=0 HI=0x3f LO=0x07 GA=0x3f07 setting=0x80 active=1
memRead: index=0x0d using fctptr data=0x3f
memRead: index=0x0e using fctptr data=0x08
memRead: index=0x0f using fctptr data=0x80
ComObj index=1 HI=0x3f LO=0x08 GA=0x3f08 setting=0x80 active=1
IA: 0x10c7
Reset triggered!
Reset attempts: 9
Reset attempts: 8
Reset attempts: 7
Reset attempts: 6
Reset attempts: 5
Reset attempts: 4
Reset attempts: 3
Reset attempts: 2
Reset attempts: 1
Reset attempts: 0
Reset failed, no answer from TPUART device
Init Error!
KnxDevice startup status: 0x02
Knx init ERROR. Retry after reboot!!
SAMD SystemReset

Leider überlebt der serielle Monitor den Neustart des XIAO nicht, da das Gerät beim Neustart jedes mal bei Windows aus dem Gerätemanager fliegt, d.h. der serielle Monitor muss nach jedem SystemReset neu gestartet werden.

Darf ich nochmal nach Anregungen hinsichtlich der Fehlersuche fragen?

Rx müsste auf D0, RX auf D1 liegen, soweit ich das gesehen habe https://gitlab.com/konnekting/Konnek...n_test.ino#L31
Habe es auch auf den UART-Pins Tx/Rx (= D6/D7) ohne Erfolg versucht.

20211105_074431 (Groß).jpg

[Ing-Dom]

Die Ausgaben bedeuten, dass der µC keine Antwort von der BCU erhält.
Das liegt höchstwahrscheinlich an deiner Verkabelung, die ich jetzt aber nicht anhand der Fotos prüfen will, das musst du schon selbst tun. Ich würde als erstes mal rx/tx vertauschen...

Ich habe selbst bei sowas schon stundenlang Fehler gesucht und dann wars ein blöder Fehler im Wiring...

Daher hab ich mir auch extra Adapter-Boards designed um sowas auszuschließen.

https://gitlab.com/knx-makerstuff/kn...dboard-Adapter
https://shop.sirsydom.de/Zubehoer/BC...d-Adapter.html

Geht auch mit Siemens BCU (wobei die NanoBCU mit 3v3 Pegel vieles erspart...)
IMG_20210105_155521760.jpg

Genau genommen ist das mit dem Pegelwandler auch Mist, denn ohne verbindest du KNX-GND mit deinem PC-GND. Da gehört eine galvanische Trennung hin.

[Albatros62]

Du nimmst die falschen Pins für den UART. D6 ist Tx und muss auf Rx der BCU, D7 ist Rx und muss auf Tx der BCU. SirSydom hat natürlich recht, eine galvanische Trennung kann manches Problem ersparen. Ich selbst habe meine Steckbrettschaltung, um den XIAO zu testen, auch ohne an einem kurzen Testbus betrieben.

Andere Anwender hatten bei ihren ersten Tests auch Kontaktprobleme zwischen Prozessor und BCU. Auf Wackelkontakte überprüfen.

Reset failed, no answer from TPUART device
Init Error!

Dies ist die entscheidende Aussage. Wenn der Prozessor keine Antwort vom TPUART bekommt, dann kann der TPUART dem Prozessor auch keine Busdaten schicken.

[mm83]

Danke euch für eure Mühe!!! Es klappt! Nachrichten sind auf dem Bus 😊.

Die richtigen PIN's waren das Problem, hatte ich zwar probiert, aber nicht über Kreuz getauscht... Den Rest bekomme ich hin, da bin ich jetzt sehr zuversichtlich und werde mit der NanoBCU mit 3,3V weitermachen (@SirSydom hat gerade Post von mir erhalten).

2021-11-05 09_22_17-ETS5™.png

[Ing-Dom]

(@SirSydom hat gerade Post von mir erhalten).

Habs gesehen du steigst ja gleich im große Stil ein

Ich hoffe du hast gesehen dass der nächste planmäßige Versandtermin erst in einem Monat ist...