TXT Problem Access Point und zweiten TXT 4.0 damit verbinden (MQTT)

[fishfriend]

Hallo...
Im Grunde geht es darum zwei TXT 4.0 über MQTT zu verbinden. Das Endziel ist (auch) einen ESP32 über MQTT einzubinden.
Es scheitert an der Verbindung. Ich kriege es gerade nicht hin, den zweiten TXT(2) beim Access Point vom ersten TXT(1) anzumelden.
Ich stelle mich gerade wie ein DAU an. Ich möchte alles Schritt für Schritt nachvollziehen.
Was mir Auffällt. das man nicht immer mit 1883 vom PC aus drauf zugreifen kann. Aber das ist erst mal nebensächlich.
Am besten wäre es wenn man den Access Point vom TXT (1) über Robo Pro Coding und den Client TXT (2) über die STEM machen könnte.
Nun erst mal nur die erste Sache:
1. Möglichkeit TXT 4.0 (1) <---> TXT 4.0 (2)
Access Point vom einem TXT 4.0 (1) der andere soll angemeldet werden.
Ich dachte erst es liegt am Passwort. Blöde Frage welches Passwort? Ich meine alle ausprobiert zu haben.
Ich vermute schon fast, dass die neuste STEM oder Robo Pro Coding Version einen Bug hat.
Aber das Problem sitzt ja eher 30cm vor dem Bildschirm.
Deswegen die Bitte ob mal jemand Schritt für Schritt mich da durchleiten kann.

Ich habe auch ein Verständnissproblem. Ist es in einem WLAN Netzwerk möglich einen TXT 4.0 Broker zu betreiben der nicht einen Sccess Point eingeschaltet hat? Wie würde man darauf zugreifen?
Mit freundlichen Grüßen
Holger

[calliope]

Ich verwende nicht das häusliche WLAN.
1. txt40-sWp6 Access Point starten, zeigt sein WLAN Passwort an.
2. txt40-TYMx WLAN Client damit verbinden, Passwort vom 1. eingeben.
3. WLAN am Windows PC ebenfalls mit txt40-sWp6 Access Point verbinden
4. ROBO Pro Coding einen TXT40 verbinden

Screenshot 2026-06-17 200820.png (65.48 KiB) 1016 mal betrachtet

5. ROBO Pro Coding 'Neues Fenster' zweite Instanz der App starten und den anderen TXT40 verbinden

In zwei Fenstern ROBO Pro Coding können beide TXT40 getrennt voneinander gesteuert werden.

Bei MQTT kommt es auf die TXT40 Firmware an. Bei 3.x kommst du nicht auf den internen MQTT Broker.
Es ist aber einfach einen eigenen mosquitto Prozess im Linux zu starten.
Suche im GitLab nach calliope/MQTT_Broker_Basic und calliope/MQTT_Publisher.
Das auf die beiden TXT40 übertragen müsste funktionieren. (Den Broker auf den Access Point, den Publisher auf den WLAN Client.)
In den zwei ROBO Pro Coding Fenstern sind die Ausgaben in der Konsole zu sehen.

UPDATE: Bei TXT 4.0 Firmware 3.1.11-24 und 5.0.1-25 läuft dauerhaft ein MQTT Broker auf Port 3883. Standard-Zugangsdaten: ft / fischertechnik
Der ist über die WLAN / LAN IP Adresse von außen erreichbar.
Zum Koppeln wäre ROBO Pro Coding 6.5.2 erforderlich, die ist aber noch nicht veröffentlicht.
Ab welcher TXT 4.0 Firmware Version der MQTT Broker auf 3883 läuft, weiß ich nicht.

Mein Profilbild ist übrigens ein MQTT Sender für den TXT40 Broker.

[fishfriend]

Hallo...
Es klingt blöde, aber geht nicht.
Ich hab momentan die aktuelle Firmware 3.1.10 drauf.
Soweit ist das ausprobiert habe:
Interner Broker läuft, mit einem Programm auf dem TXT 4.0 (1).
Zugriff auf externen Broker geht.
Ich hab keinen Zugriff auf Access Point. Vom meiner Warte her würde ich sagen, dass ich alle Passwörter ausprobiert habe.
Frage: Welches Passwort muss ich nehmen?

Das (Verständniss-) Problem das ich auch habe ist, dass man ja nur "eine" IP nutzen kann. Ich kann also nicht auf dem TXT 4.0 (2) sagen, ich möchte den Broker 127.0.0.1 auf dem TXT4.0 (1) mit der IP 192.168.... nutzen. Wenn das ginge, könnte ich ja auch aus dem WLAN zugreifen.
Ich vermute schon fast, dass das geht.
Aber wie gesagt ich komme nicht weiter.
Mit freundlichen Grüßen
Holger

[calliope]

Hallo Holger,
wir müssen TCP/IP und MQTT unterscheiden.
Jeder Controller ist ein Host. Jeder Host hat die IP Adresse 127.0.0.1 = localhost. Damit kann z.B. Python auf dem eigenen Gerät etwas machen. Auch wenn der Controller mit keinem Netzwerk verbunden ist. Mit 127.0.0.1 kann NIE auf einen anderen Host zugegriffen werden.

Der Host kann auch mit einem oder mehreren TCP/IP Netzwerken (WLAN, LAN, PAN) verbunden werden. In jedem Netzwerk bekommt der Host eine zusätzliche IP Adresse. Der Controller hat also mehrere IP Adressen.

Ein Dienst (Service) wie der MQTT Broker mosquitto bekommt beim Start gesagt auf welchen IP Adressen er horchen soll. Entweder nur auf 127.0.0.1 oder auf allen IP Adressen.

Um die vielen Dienste zu unterscheiden, bekommt jeder eine Port Nummer. Die wird beim verbinden zusätzlich zur IP Adresse gebraucht.

Auf dem TXT 4.0 läuft ein MQTT Broker nur auf 127.0.0.1:2883. Der horcht nicht auf den (WLAN) IP Adressen und kann deshalb von einem anderen Controller aus nicht erreicht werden. (Der wird vom Display gebraucht.) Den Broker kannst du zum koppeln nicht gebrauchen.

Es muss ein zweiter MQTT Broker auf einem anderen Port laufen, der auf allen IP Adressen horcht.


Ob die beiden Controller im häuslichen WLAN sind oder einer Access Point und der andere WLAN Client, ist egal. Sie müssen jeder eine IP Adresse im selben Subnetz haben.

Welches Passwort suchst du? Bei dem einen ist Access Point aktiviert. Tippst du darauf wird SSID und Passwort angezeigt.

Bei dem anderen ist WLAN aktiviert. Tipps du darauf wird die SSID vom anderen in der Liste der WLAN zu finden sein. Dort muss über die Bildschirmtastatur "Passphrase" eingegeben werden.

FG Lutz

[fishfriend]

Hallo...
Danke das du dir dafür Zeit nimmst.
Sorry, wenn ich mich blöd anstelle, aber ich versuche nun Schritt für Schritt meine Fehler zu finden.

Hallo Holger,
wir müssen TCP/IP und MQTT unterscheiden.
Jeder Controller ist ein Host. Jeder Host hat die IP Adresse 127.0.0.1 = localhost. Damit kann z.B. Python auf dem eigenen Gerät etwas machen. Auch wenn der Controller mit keinem Netzwerk verbunden ist. Mit 127.0.0.1 kann NIE auf einen anderen Host zugegriffen werden.

Also:
TXT 4.0 (1) hat z.B. die Adresse 198.168..1 und hat selbst auch 127.0.0.1
TXT 4.0 (2) hat die Adresse 198.168..2 und hat selbst auch 127.0.0.1

Der Host kann auch mit einem oder mehreren TCP/IP Netzwerken (WLAN, LAN, PAN) verbunden werden. In jedem Netzwerk bekommt der Host eine zusätzliche IP Adresse. Der Controller hat also mehrere IP Adressen.

Die IPs des TXT bekommt er vom jew Router.

Ein Dienst (Service) wie der MQTT Broker mosquitto bekommt beim Start gesagt auf welchen IP Adressen er horchen soll. Entweder nur auf 127.0.0.1 oder auf allen IP Adressen.

Tja, da geht es schon los. Wie sind denn die Einstellungen?
Es läuft ja ein Moquitto Broker auf (jedem?) TXT 4.0. So wie ich das sehe kann man da nichts einstellen.

Um die vielen Dienste zu unterscheiden, bekommt jeder eine Port Nummer. Die wird beim verbinden zusätzlich zur IP Adresse gebraucht.

Man hat also :1883 :2883 (GUI) :3883 und :8883 zumindest werden die ab und an in MQTT Programmen benutzt.
Im Grunde von MQTT (nach Anleitung) sind es X883, wobei nur 1883 ohne Passwort sein soll.

Auf dem TXT 4.0 läuft ein MQTT Broker nur auf 127.0.0.1:2883. Der horcht nicht auf den (WLAN) IP Adressen und kann deshalb von einem anderen Controller aus nicht erreicht werden. (Der wird vom Display gebraucht.) Den Broker kannst du zum koppeln nicht gebrauchen.

Wenn ich das richtig verstehe, läuft auf dem TXT 4.0 ein MQTT Broker, der nur für die Node-Red Darstellung genutz wird. Und man nicht darüber hinaus mit dem machen.
Wobei man eventuell über Node-Red dann verbindung mit anderen aufnehmen kann?

Es muss ein zweiter MQTT Broker auf einem anderen Port laufen, der auf allen IP Adressen horcht.

Tja, wie startet man den und mit welchen EInstellungen (auf dem TXT 4.0 ?
Es wird scheinbar sonst auf einem anderen Gerät Pi, PC (Router) ... ein Broker gestartet wo denn der/die TXT 4.0 zugreifen.

Ob die beiden Controller im häuslichen WLAN sind oder einer Access Point und der andere WLAN Client, ist egal. Sie müssen jeder eine IP Adresse im selben Subnetz haben.

Welches Passwort suchst du? Bei dem einen ist Access Point aktiviert. Tippst du darauf wird SSID und Passwort angezeigt.

Tja, ich vermute da ist ein Fehler bei mir.
"Tippst du darauf" Oh man... Ja da gibt es noch einen Menüpunkt.

Bei dem anderen ist WLAN aktiviert. Tipps du darauf wird die SSID vom anderen in der Liste der WLAN zu finden sein. Dort muss über die Bildschirmtastatur "Passphrase" eingegeben werden.

Da muss ich noch ausprobieren.

FG Lutz

Danke schon mal.
Der Rest kommt später
Mit freundlichen Grüßen
Holger

[fishfriend]

Hallo...
Schritt 1 Verbinden ist schon mal geschafft.
Nun kommen die anderen.

Ich finde es Interessant, das es noch mehr zu MQTT von fischertechnik gibt.
In der facotry lib und in der facotry_variablen lib gibt es z.B. fur MQTT: set_client (so ähnlich)
Steht in der Lib der Factory_Main unter Importe.
Ich vermute, dass es mehrere Wege gibt einen Client zu machen.
Kann ja sein, dass man da auch den Broker beeinflussen kann.

Aber das ist eine andere Baustelle.
Mit freundlichen Grüßen
Holger

[calliope]

Hallo Holger ... ich war inzwischen bei einem 100. Geburtstag in der Verwandtschaft ...

Also es gibt außer der 127.0.0.1 = localhost, die jeder Computer der Welt hat, auf dem TXT 4.0 diese Möglichkeiten:
192.168.7.2 USB
192.168.8.2 WLAN Access Point
192.168.9.2 Bluetooth PAN
Die Adresse hat der immer, wenn sich ROBO Pro Coding über das entsprechende Protokoll verbindet.
Man kann sagen, der TXT 4.0 ist in dem Netzwerk Router, was aber nur interessant ist, wenn ein dritter Host in dem Netzwerk ist, zu dem es eine Route gibt. Das kann ich mir nur beim WLAN Access Point vorstellen.

Der TXT 4.0 (2) verbindet sich als Client mit den WLAN von (1). Das hast du inzwischen geschafft. Dort bekommt er eine IP Adresse 192.168.8.x aber nicht 192.168.8.2. Auf dem WLAN Client wird die (vom Router erhaltene) IP Adresse oben im Display angezeigt.

Jetzt sind beide im selben IP Netz und wenn der PC mit ROBO Pro Coding auch mit dem WLAN (1) verbunden ist, und eine andere Adresse 192.168.8.x hat, kann ROBO Pro Coding im Verbindungsdialog zwei TXT 4.0 sehen. (Oder man gibt die 192.168.8.2 und 192.168.8.x bei BENUTZERDEFINIERT ein.)
- Siehe Bild oben.


Jetzt MQTT:
Den existierenden Broker auf Port 2883 können wir nicht gebrauchen, weil der auf jedem TXT 4.0 nur auf 127.0.0.1 horcht, und die nicht von einem anderen Host erreichbar sind. Wir können den auch nicht ändern, und dann würde das Display nicht mehr funktionieren.
Node Red läuft ja auch lokal auf dem Host. Aber das kenne ich überhaupt nicht. Brauchen wir hier nicht.

Der MQTT Broker auf Port 1883 ist vom alten TXT Controller übrig geblieben und wird ab Firmware 5 nicht mehr vom System benutzt. Aber der Port ist für die Lernfabrik reserviert.

Bei der neuen Firmware 3 und 5 existiert ein (dritter) MQTT Broker auf Port 3883. Ob das bei dir der Fall ist, kannst du ausprobieren.

Screenshot 2026-06-21 201527.png (32.5 KiB) 596 mal betrachtet

Das müsste auf beiden TXT 4.0 funktionieren, (wenn sie mit WLAN verbunden sind).

Wenn die WLAN Verbindung steht und ROBO Pro Coding in zwei Fenstern mit beiden verbunden ist, kannst du meine oben genannten Beispiele von GitLab laden. Die starten einen eigenen MQTT Broker mosquitto im Linux.

Sonst kann ich das Starten eines eigenen mosquitto mit Portnummer und Benutzername / Passwort hier erklären.
Oder du wartest auf die neue Firmware, die soll vor den Sommerferien veröffentlicht werden. (Ich bin beta Tester.)
Dann ist vieles von dem, was du früher aufgeschrieben hast, nicht mehr wahr.

FG Lutz

[baikal]

Ist auf den TXTs "lsof" vorhanden?

Code: Alles auswählen

lsof -i

als root würde die offenen Ports + an welche v4/v6 Adresse der jeweilige Dienst gebunden ist.

Alternativ sollte es eine mosquitto.conf geben und dort die optionen

Code: Alles auswählen

bind_address

oder

Code: Alles auswählen

bind_interface

welche das Verhalten des brokers steuern. Wenn es eine aktuellere Version ist könnte es aber auch eine

Code: Alles auswählen

listener

Direktive geben.
Siehe auch https://mosquitto.org/man/mosquitto-conf-5.html

Wenn Du schon per ssh auf den Controllern bist, ein

Code: Alles auswählen

ip addr show

wäre noch interessant.

[fishfriend]

Hallo...
Echt interessant.
Es funktioniert nicht. Ich muss dazusagen bei welchem Schritt ich bin.
Also, Ich habe mich beim TXT 4.0 (1) vom PC über WLAN beim Access Point angemldet.
Robo Pro Coding findet ihn aber nicht.
Ich vermute mal, dass entweder schon durch die bestehende WIndows-TXT 4.0 Verbiindung die Robo Pro blokiert wird oder aber das nicht alle Netze durchsucht werden. Ich hab ja auch noch das LAN an.
Ich muss da noch mal etwas testen.
Mit freundlichen Grüßen
Holger

[calliope]

Hallo Holger,
ich habe auch das LAN Kabel am PC und das WLAN brauche ich eigentlich nicht. Deshalb kann ich das zum TXT 4.0 (1) verbinden.
Gib mal nach WLAN Verbindung zu (1) an der Windows Eingabeaufforderung ein: ipconfig

C:\Users\lutz3>ipconfig

Windows-IP-Konfiguration

Ethernet-Adapter Ethernet RJ45:
Verbindungsspezifisches DNS-Suffix: digi.box
IPv4-Adresse . . . . . . . . . . : 192.168.2.41
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.2.1

Drahtlos-LAN-Adapter WLAN:

Verbindungsspezifisches DNS-Suffix:
Verbindungslokale IPv6-Adresse . : fe80::576b:5a61:79b5:e8d9%28
IPv4-Adresse . . . . . . . . . . : 192.168.8.81
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :

Du siehst das LAN und das WLAN vom TXT 4.0 (der Access Point hat ja die Adresse 192.168.8.2).
Ein Problem hast du nur, wenn das Ethernet LAN auch eine 8 hat: 192.168.8.x Dann musst du das Netzwerkkabel raus ziehen.
Du kannst auch ping 192.168.8.2 machen:

C:\Users\lutz3>ping 192.168.8.2

Ping wird ausgeführt für 192.168.8.2 mit 32 Bytes Daten:
Antwort von 192.168.8.2: Bytes=32 Zeit=38ms TTL=64
Antwort von 192.168.8.2: Bytes=32 Zeit=24ms TTL=64
Antwort von 192.168.8.2: Bytes=32 Zeit=31ms TTL=64
Antwort von 192.168.8.2: Bytes=32 Zeit=11ms TTL=64

Ping-Statistik für 192.168.8.2:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 11ms, Maximum = 38ms, Mittelwert = 26ms

Wenn der (1) nicht angezeigt wird:

Screenshot 2026-06-22 194137.png (80.65 KiB) 452 mal betrachtet

kannst du mit BENUTZERDEFINIERT WLAN Access Point auswählen oder die Adresse 192.168.8.2 eingeben.

Screenshot 2026-06-22 194231.png (45.07 KiB) 452 mal betrachtet

[fishfriend]

Hallo...
Es geht leider nicht.

Drahtlos-LAN-Adapter WLAN:

Verbindungsspezifisches DNS-Suffix:
Verbindungslokale IPv6-Adresse . : fe80:2520:4d6d:ac10%14
IPv4-Adresse . . . . . . . . . . : 192.168.8.115
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :

Ethernet-Adapter Bluetooth-Netzwerkverbindung:

Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:

C:\Users\holge>ping 192.168.8.115

Ping wird ausgeführt für 192.168.8.115 mit 32 Bytes Daten:
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.

Ping-Statistik für 192.168.8.115:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),

Ich habe es nun mit beiden TXT 4.0 als jew Access Point versucht. Oben nun der Zweite TXT 4.0, aber mit dem Selben Ergebniss.
WIndows 11 verbindet sich aber. Unter "Netzwerke und Internet" / WLAN / TXT4.0-... wird auch die IP angezeigt:

SSID: TXT4.0-...
Protokoll: 802.11g
Sicherheitstyp: WPA2-Personal
Hersteller: Intel Corporation
Beschreibung: Intel(R) Wi-Fi 6 AX200 160MHz
Treiberversion: 23.150.0.4
Netzwerkband (Kanal): 2,4 GHz (1)
Aggregierte Verbindungsgeschwindigkeit (Empfangen/Senden): 54/54 (Mbps)
Verbindungslokale IPv6-Adresse: fe80:2520:4d.........
IPv6-DNS-Server: fec0:0:0:f........ (unverschlüsselt)
fec0:0:0:ff..... (unverschlüsselt)
fec0:0:0:ff..... (unverschlüsselt)
IPv4-Adresse: 192.168.8.115
Physische Adresse (MAC): 9C:FC:E....

Hab mal den Klartext etwas gekürzt.
Ich komme so nicht weiter.
Verbind steht, aber kein Ping ???
Ich versuche als nächstes mal LAN abzuklemmen und nur WLAN zu aktivieren.
Danach werde ich mal einen anderen Rechner ausprobieren.
Mit freundlichen Grüßen
Holger

[calliope]

Hallo Holger,
du müsstest eigentlich ping zu 192.168.8.2 machen, das ist der TXT40. Die 192.168.8.115 ist die Adresse, die dein PC vom WLAN Access Point bekommen hat. Ich habe mal Copilot gefragt:

Wenn **Ping auf die eigene DHCP‑Adresse (z. B. 192.168.8.115)** den Fehler *„Allgemeiner Fehler“* ausgibt, dann stimmt etwas Grundlegendes im lokalen Netzwerk‑Stack nicht. Das ist **nicht normal** und hat sehr spezifische Ursachen.
Damit du es sauber einordnen kannst, hier die präzise Analyse.
---
## **Was bedeutet es technisch, wenn Ping auf die eigene IP fehlschlägt?**

Windows muss beim Ping auf die eigene IP **gar nicht ins Netzwerk gehen**.
Es prüft nur intern:

1. Ist die IP an einen Adapter gebunden?
2. Ist der Netzwerk‑Stack funktionsfähig?
3. Kann ARP für die eigene Adresse korrekt aufgelöst werden?

Wenn einer dieser Schritte scheitert → **„Allgemeiner Fehler“**.
---
## **Die 4 wahrscheinlichsten Ursachen (in der Praxis)**

### **1. Der IPv4‑Stack ist beschädigt oder nicht korrekt gebunden**
Das ist der *mit Abstand häufigste* Grund.

Typische Symptome:
- `ping 127.0.0.1` funktioniert
- `ping 192.168.x.x` → „Allgemeiner Fehler“
- Internet kann trotzdem funktionieren (!)

Warum?
Weil Loopback (127.0.0.1) ein eigener Treiber ist, unabhängig vom IPv4‑Stack.
---
### **2. Firewall / Security Suite blockiert ICMP lokal**
Einige Programme blockieren ICMP **auch für die eigene Adresse**.

Typische Kandidaten:
- Kaspersky
- Bitdefender
- Norton
- G‑Data
- Unternehmens‑Policies

### **3. Der WLAN‑Adapter ist im „Zombie‑Zustand“**
Windows zeigt eine IP an, aber der Treiber ist intern nicht korrekt initialisiert.

Symptome:
- IP vorhanden
- Ping auf Router geht nicht
- Ping auf eigene IP geht nicht
- Neustart des Adapters hilft oft
---
### **4. IP‑Konflikt im Netzwerk**
Wenn ein anderes Gerät dieselbe IP hat, kann Windows die eigene ARP‑Zuordnung nicht korrekt setzen.

Test:
```
arp -a
```
Wenn deine eigene IP dort mit **einer fremden MAC‑Adresse** steht → IP‑Konflikt.
---
## **Bitte teste kurz diese drei Dinge**

### **Test 1: Loopback**
```
ping 127.0.0.1
```
→ Wenn das geht, ist der TCP/IP‑Stack nicht komplett kaputt.

### **Test 2: ARP‑Eintrag prüfen**
```
arp -a
```
→ Steht deine eigene IP dort?
→ Wenn ja: Welche MAC‑Adresse?

### **Test 3: IP‑Konfiguration**
```
ipconfig /all
```
→ Wichtig: „Medienstatus“, IPv4‑Adresse, Gateway, DHCP‑Server.
---
## **Sofortmaßnahme, die in 80 % der Fälle hilft**
``
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
```

→ Danach **Neustart**.

---

## Wenn du willst, schauen wir es gemeinsam an
Schick mir bitte die Ausgaben von:

```
ping 127.0.0.1
ping 192.168.8.115
arp -a
ipconfig /all
```

Dann kann ich dir ziemlich genau sagen, *welcher* der oben genannten Fälle bei dir zutrifft.

[fishfriend]

Hallo...
Also. ich hab mal auch etwas gelesen.
Ich habe mich gefragt woher die 192.168.8.2 Adresse kommt.

Dazu muss man wissen das 192.168.8.1 der Router selbst ist. Die KI sagt: " Die Standard-Gateway-Adresse (Router-IP). Sie dient als zentrale Steuerungseinheit, über die Sie das Web-Interface des Routers aufrufen und Einstellungen verwalten.

Im Unterschied zu 192.168.8.2 KI: " Eine Standard-Client-IP. Dies ist die erste automatisch zugewiesene Adresse für ein angeschlossenes Endgerät (z.B. ein Laptop, Smartphone oder ein separater Repeater)"

Um also ein (das erste) Gerät am Access Point vom TXT 4.0 anzusprechen, muss man 192.168.8.2 nehmen. In diesem Fall ist es aber nicht das "erste Gerät", sondern der TXT 4.0 selbst, der den Access Point zur verfügung stellt.

192.168.8.115 ist in diesem Fall der PC in dem vom Access Point aufgespannten WLAN Netz. Der DHCP-Router/AP vom TXT 4.0 stellt diese Adresse, weil er so scheinbar eingestellt ist.

Man muss es nur wissen...
So steht es ja nicht in einer Anleitung drinn, da ja meinstens ein externer Router (PI/Fritzbox...) benutzt wird.

Gut also ich kann nun vom PC (Browser) aus auf den TXT 4.0, über die Adresse 192.168.8.2 zugreifen.
Benutzername: ft
Passwort: fischertechnik

Was ich interessant finde ist, das man nun bei Robo Pro Coding kein Passwort oder API Schlüssel eingeben muss.
Es verbindet sich einfach so. (Das Browserfenster ist im Hintergrund noch offen.)
Das ist schon mal geschafft. Danke schonaml dafür!

So, nun gehts weiter, mit dem zweiten TXT 4.0 (2)...
Mit freundlichen Grüßen
Holger

[fishfriend]

Hallo...
Zwischenstand.
So TXT 4.0 (2) ist schon mal am Access Point angemeldet
Er hat auch seine eigene IP mit ....143

Wenn man versehendlich auf Verbinden drückt, wärend er sich verbindet, kann es sein das der TXT 4.0 abschmiert.
Aber OK ist halt Bedienfehler.
Mit freundlichen Grüßen
Holger
PS Robo Pro Coding (2. Fenster) greift nun auch auf den TXT 4.0 (2) zu.

[calliope]

Hallo Holger,
wie hast du denn dein Netz wieder ganz gemacht?

Was die KI da sagt, ist "grundsätzlich" richtig. Und gilt für deinen Internet Router - LAN Kabel. Die .1 ist der Router.

Beim TXT40 ist das anders, der macht ein zweites Netz (WLAN) und ist eigentlich kein Router. In dem Netz gibt es keine .8.1.
Die erste Adresse ist dort 8.2 und das ist die eigene Adresse vom TXT40, wenn er Access Point ist.

Welche Adressen der an seine Clients "least", steht im DHCP Pool. Der fängt irgendwo mittendrin an und meistens nicht bei 2. Also die 8.115 und 8.143 ist schon in Ordnung.

Viel wichtiger ist die 8 vor der letzten Ziffer. Du kannst nicht zwei IP Netze mit 192.168.8.x gleichzeitig haben.

Also dein Internet Router - LAN Kabel darf nicht zufällig auch den Adressbereich 192.168.8.x haben. (Bei mir hat der Telekom Router die 192.168.2.x).
Oder war das die Ursache dass es nicht funktionierte?

FG Lutz

DHCP: Dynamic Host Configuration Protocol

[fishfriend]

Hallo...
Scheinbar ist die .1 auch der AP. Ich tippe mal drauf, dass man da auch Steuercodes senden kann. Dazu hab ich aber noch viel damit gemacht.
Ohne mich da genau eingelesen zu haben, Ich vermute mal das ein Router genutzt wird der "nur" als AP arbeitet.

Die Schwierigkeiten:
Als erstes fällt mir der Unterschied Paho und Mosquitto auf. Jeder spricht von Mosquitto obwohl Paho richtig ist.
Mit Paho greift man auf den Mosquitto Broker zu.
Warum auch immer die das von Eclipse getrennt haben...

Für Leute die damit schon mal was gemacht haben, ist es klar war gemint ist. Deswegen habe ich als DAU noch mal bei 0 angefangen, um Fehlerquellen auszuschließen. Es ist ja auch schon eine Zeit her, dass ich mit dem Thema beschäftigt habe. Wir hatten aber auch die ft-Cloud und den Mosquitto-Server und dessen Test-Broker genommen. Da hatte man nicht das Problem, dass man sich in "unterschiedlichen" Netzwerken befindet. Der Router gibt die IP vor und man hat dann nur noch die Mosquitto-IP vom www. Man meldet den TXT 4.0 ja auch über einen anderen/weiteren Schlüssel an, den man auf dem TXT 4.0 erzeugt.

Ich sags mal so. Die Beschreibungen über die Funktion vom Access Point beim TXT 4.0 sind "-Erweiterngswürdig-".
Ich hab mir eine Tabelle gemacht, wo ich alle Kennwörter, Passwörter, Schlüssel, MAC Adressen, Firmware, API, Linuxversionen und IPs zu den jew. TXTs aufgeschrieben habe. Das ist wichtig, da man sonst total durcheinander kommt.

Eine IP im klassischem Sinne war eine Adresse. Bei den heutigen Betriebssystemen steckt aber auch manchmal ein Treiber dahinter, wo dann noch ab und an, ein Port dazukommt. Zum Port z.B. beim MQTT-Broker gibt es Beschreibungen, die aber nicht unbedingt zutreffen, wie 1883, 1884,... 1888, wo man durch erhöte Sicherheit auch noch Benutzername und Kennwörter vorgeben "-kann-". Die Frage ist welche es sind oder welche sogar vorgegeben sind. Das es auch -ohne- geht, hab ich so noch nicht gelesen. Aber man denkt selber manchmal zu kompliziert.

Ich finde, die größte Schwierigkeit ist, wann welches Passwort/Kennwort gebraucht wird.
Auch z.B. die Access Point "EInstellung" bzw dass es noch mal ein extra Passwort dafür gibt und -wo- man es findet, sind Schwierigkeiten die einen Anfänger scheitern lassen. Mal will Robo Pro Coding den API Schlüssel haben, mal nicht...

Auch so kleine "Triks" wie über:

client_id = os.uname().nodename
mqtt_client = MqttClient(client_id)

wo man über eine interne Betriebssystemfunktion geht, machen es nicht leichter es genau zu verstehen.
ft selbst hat ja teilweise auch in seinen Beispielen nicht die normalen Blöcke genommen sondern Python-Code. Es ist ja nicht dokumentiert.
Wobei man auch noch sagen muss: -Welche- Version von welchem Programm. Teilweise haben die sich zwischenzeitlich auch geändert.

Ich werde noch mal alles zusammenschreiben, was man wie machen muss.
Auch wirklich einfachste MQTT Programme werde ich noch mal programmieren.
Die also wirklich nur eine Sache machen.

Ich finde es auch zu Anfang schwer zu verstehen, dass auf dem TXT 4.0 nicht nur der Access Point sondern auch ein Broker -und- ein Client ist.
Wenn nun eine Verbindung zustande gekommen ist, wird beim Broker ein Client gestartet, der den eigenen Broker abfragt.
Schwierig / überraschend für mich, das z.B. wenn die Verbindung zum anderen TXT 4.0 abbricht, der "eigene" Client weiterläuft.

Ich hab mich auch schwer damit getan, wo welches Programm hingehört.
Als Tipp solte man beide Robo Pro Coding Instanzen auf dem Bildschirm so anordnen, wie bei einem selbst die TXTs liegen.
Dann hat der Client ja auch noch den Namen "Publisher".
Ich gebe zu, das mag etwas kleinkariert klingen, aber für mich als "DAU", ist es echt ein Hinderniss.
Man muss es einfach nur wissen.

Aber danke nochmals, das es bis hierher schon mal läuft.
Ich hätte es in den letzten drei Wochen sonst nicht alleine geschaft.

Nun hab ich ja noch eine "Herausforderung" um einen ESP32 mit dem TXT 4.0 Access Point zu verbinden.
Dann werde ich die Sachen von weiter oben noch mal abarbeiten.
Danach werde ich nochmal versuchen ob man EInstellungen ändern kann, wobei ich schon fast vermute, dass man nicht die Rechte hat, um es zu machen.
Wir werden sehen... und ich hab bestrimmt noch mehr Fragen

Mit freundlichen Grüßen
Holger