Verfasste Forenbeiträge
-
Beiträge
-
Gut, freut mich. Dein Durchhaltevermögen ist offenbar enorm, daher gehe ich davon aus, dass Du noch länger am Ball bleibst. Daher wirst Du in jedem Falle mehrere MTC4BTs benötigen. Das aktuelle Limit liegt bei 5 Hubs pro MTC4BT.
Grundsätzlich brauchst Du nur die jeweiligen Infos in den Konfigurationsdateien im data Verzeichnis bereitstellen und die Dateien auf den jeweiligen Controller hochladen. Vorher natürlich die Firmware hochladen.
Hier noch ein paar Tipps für Fortgeschrittene zum MTC4BT, wenn man groß hinaus will:
– Finde alle MAC-Adressen Deiner Hubs heraus und klebe Dir kleine Aufkleber mit den MAC-Adressen an die Hubs. Glaube mir, das hilft… 🙂
– Abstrahiere Deine loco Konfigurationen ab der ersten Sekunde von den controller_config.json Dateien. Das heißt: lege Dir eigene loco_* files an und referenziere diese von den controller_config.json Dateien. Sichere die in einem eigenen Verzeichnis irgendwo. Mach von diesem Verzeichnis regelmäßige Backups. Die loco files sind wichtiger und aufwendiger wieder herzustellen als die controller_config.json Dateien.
– Lege Dir im data Verzeichnis Unterverzeichnisse für Deine MTC4BT controller an. Kopiere die jeweiligen loco Files in diese Verzeichnisse und referenziere sie von den controller_config.json Dateien. Damit platform.ui die Konfigurationen von diesem Verzeichnis hochlädt, muss die data_dir Variable in Deiner my_platformio.ini Datei angepasst werden.
– Bringe OTA bzw. OTW zum laufen (Update des Controllers per Wifi / Ethernet, also ohne USB-Kabel).Das dürften erst einmal genug Aufgaben sein. Musst Du auch nicht alle sofort erledigen.
Versuch mal bitte, die MAC-Adressen der PU hubs kleinzuschreiben (z.B. 90:84:2b:0c:d2:05 statt 90:84:2B:0C:D2:05).
Du benötigst in der Konfigurationsdatei mindestens einen Trigger, um die Lampen anzubekommen. Schau Dir dazu mal ein Beispiel an, z.B. loco_EST.json. Das findest Du in src/MTC4BT/data_example/loco_examples.
Interessant, danke für die Info. Das Problem kannten wir bislang nur von anderen ESP32-S3 boards. Die beschriebene Problemlösung ist bei diesen Boards tatsächlich korrekt. Der Hersteller würde vermutlich sagen: Bootloader Taste gedrückt halten, dann kurz Reset drücken. 🙂
Finde ich gut, dass so schnell nach dem Release schon die ersten Leute mit dem Seeed ESP32-S3 auftauchen. Bin auf weiteres Feedback gespannt!
Thorsten, vielen Dank für diesen hilfreichen Report.
Hier ist eine Prozedur, die helfen sollte:
– my_platformio.ini neu mit der Beispieldatei my_platformio.ini.example überschreiben (vorher Backup falls dort etwas wichtiges drin stand).
– Das Semikolon vor “DRIVERTASKDELAY” entfernen.
– Das platform ui Projekt neu auswählen (in der Toolbar unten auf “env:…” klicken.Dann sollte es funktionieren.
Wir werden das mit V1.2.1 und nachfolgend abmildern. Die genannte Anpassung wird dann nicht mehr notwendig sein.
Deine Konfigurationsdateien hast Du sicherlich nach der Anleitung in ein eigenes Verzeichnis kopiert. Dieses Verzeichnis unterliegt nicht der Versionskontrolle und wird beim Aktualisieren des Sources Codes nicht geändert. Regelmäßige Backups sind vorsichtshalber natürlich trotzdem immer sinnvoll, v.a. wenn man sich mit moderner Software-Entwicklung, git und VSCode noch nicht so gut auskennt.
Schau bitte, dass die Dateien in Firmware 1.2 noch richtig funktionieren. Da haben sich ein paar Details geändert. Schau einfach mal in die Beispieldateien von Firmware 1.2 und in die Doku, dann siehst Du das schon.
Zwei identische Loks haben selten die gleiche Geschwindigkeit. Das hat viele Gründe, und unterschiedliche elektrische Spannungen sind nur einer davon. Du wirst wahrscheinlich feststellen, dass Deine “Ein Stromkreis” Lösung auch nicht dazu führen wird, dass die Loks gleich schnell sind. Wenn sie aber in die selbe Richtung ziehen, gibt es da kein Problem. Der ganze Zug fährt natürlich viel besser wenn hinten auch geschoben wird, da die Tangentialkräfte in Kurven viel gerinter sind, und daher die Radflanken der Waggons auch viel weniger Reibung erzeugen. Daher brauchen Pendelzüge mit Loks vorn und hinten auch weniger Power als Loks, die ähnlich lange und schwere Züge ziehen. Daher kann man Pendelzüge auch sehr lang bauen, ohne dass sie in Kurven stecken bleiben. Allerdings sind meine Pendelzüge über 2m lang. Ich habe da keine Kabel durchgelegt, sondern vorn und hinten einen Motor mit eigener Steuerung und Batterie verbaut.
Zu Rocrail-Fragen bitte die Rocrail Website und das Rocrail Forum befragen. Wenn wir das auch noch machen, schaffen wir sonst nichts mehr.
Hmm, knifflig. Es gibt eine gewisse Chance, dass Du hier einem selten auftretenden Bug in der Firmware 1.1 aufgesessen bist. Falls es dieses Problem ist, dann haben wir das mit Release 1.2 mittlerweile ganz gut in den Griff gekriegt (hoffen wir). Zeitplan ist momentan, dass wir das am 14.2 veröffentlichen. Schau Dir auch noch einmal den Hardware-Guide auf der MTC4BT Seite an, den habe ich vor ein paar Tagen fit für 1.2 gemacht.
Stelle bitte sicher, dass Du normale Anführungszeichen (ASCII Code 34) verwendest und keine speziellen Unicode-Anführungszeichen. Die Konfiguration sieht sonst auf den ersten Blick ganz gut aus.
Geh mal gedanklich einen Schritt zurück. Verbinde einfach Deine Powerbank mit der USB-Buchse des Controllers und er läuft. Die Stromversorgung läuft über den USB-Anschluss.
Nein, entscheidend ist “events” Knoten. Ich habe Deine Frage zum Anlass genommen, um für Firmware 1.2 eine Beispiel-Konfiguration für diesen einfachen Anwendungsfall zu basteln. Wollte ich eh noch machen.
Es handelt sich um eine einfache Lokomotive mit Powered Up Hub, an den ein Motor und ein PU-Licht angeschlossen sind. Das Licht lässt sich per F1 manuell an und ausschalten. Außerdem schaltet es bei “Vorwärts” automatisch ein, und erlischt bei “Stop” und “Rückwärts”.
Hier ist die Konfiguration:
{
“address”: 1,
“name”: “SIMPLE_LOCO_with_lights”,
“pwrIncStep”: 10,
“pwrDecStep”: 10,
“bleHubs”: [
{
“type”: “PU”,
“address”: “90:84:2b:21:71:46”,
“channels”: [
{
“channel”: “A”,
“attachedDevice”: “motor”
},
{
“channel”: “B”,
“attachedDevice”: “light”
}
]
}
],
“events”: [
{
“triggers”: [
{
“source”: “rr”,
“eventType”: “fnchanged”,
“identifier”: “f1”,
“value”: “on”
},
{
“source”: “loco”,
“eventType”: “dirchanged”,
“value”: “forward”
}
],
“actions”: [
{
“address”: “90:84:2b:21:71:46”,
“channel”: “B”,
“pwrPerc”: 50
}
]
},
{
“triggers”: [
{
“source”: “rr”,
“eventType”: “fnchanged”,
“identifier”: “f1”,
“value”: “off”
},
{
“source”: “loco”,
“eventType”: “dirchanged”,
“value”: “backward”
},
{
“source”: “loco”,
“eventType”: “dirchanged”,
“value”: “stopped”
}
],
“actions”: [
{
“address”: “90:84:2b:21:71:46”,
“channel”: “B”,
“pwrPerc”: 0
}
]
}
]
}Viel Erfolg!
Schau Dir bitte das Beispiel in MTC4BT/data_example/controller_config.json an. Der Zug “PT60197” in diesem Beispiel verwendet auch Lichter, die manuell geeschaltet werden können und sogar automatisch beim Bewegen und Stoppen des Zuges an und aus gehen.
Mit Firmware Release 1.2 kommen viele weitere Beispiele mit hinzu, die ebenfalls zur Ansicht dienen, wie es gemacht wird.
Hat sich denn der Controller ganz sicher mit dem WLAN verbunden? Falls ja, liegt es am MQTT.
Entweder hast Du den MQTT Service falsch eingerichtet, die IP-Adresse ist nicht korrekt oder eine Firewall blockiert den Zugriff.
Bitte schau noch einmal genau diese Seite hier durch:
Falls Dir Englisch nicht von der Hand geht, so leistet Google Translate gute Dienste.
.. and please check that you are not using special characters for the ‘”‘ characters. In JSON files, it needs to be ASCII characters 34 (decimal) which equals x22 (hexadecimal).
Try it, but my guess is that this is not the problem, but somehow you upload the wrong configuration directory up to the controller.
To validate your finding, you should put the content of loco_simple into the controller_config.json file and test it. The file should look like this:
{
“name”: “MTC4BT”,
“espPins”: [],
“locos”: [
{
“address”: 1,
“name”: “60197”,
“bleHubs”: [
{
“type”: “PU”,
“address”: “90:84:2b:cf:81:47”,
“channels”: [
{
“channel”: “A”,
“attachedDevice”: “motor”
},
{
“channel”: “B”,
“attachedDevice”: “motor”,
“direction”: “reverse”
}
]
}
]
},
{
“address”: 2,
“name”: “60051”,
“bleHubs”: [
{
“type”: “PU”,
“address”: “”,
“channels”: [
{
“channel”: “A”,
“attachedDevice”: “motor”
},
{
“channel”: “B”,
“attachedDevice”: “motor”,
“direction”: “reverse”
}
]
}
]
}
],
“locoConfigs”: []
}Please check:
– You uploaded the new configuration using the platform.io action “Upload Filesystem image” not “Upload”.Try adding a line break ahead of the data_dir line (I know, that’s a very far fetch).
If this doesn’t help, it becomes difficult to help you from remote. But the problem is
surely in this area where we are presently poking.The root cause of your problem is that data_dir is pointing to the wrong directory, or that you have the wrong files in that directory. If you solve this issue, it should work.
I haven’t compiled the MTC4BT on a Mac yet, but basically everything seems to be alright. In the serial log it also shows that you have configured one hub, so that’s very likely okay if you point with the data_dir variable to the directory where your controller_config.json etc. is in. For validation, you could add another hub for testing, the you should see 2 hubs in the serial log.
It is possible that the PU hub does not connect on first try. Try a couple of times in a row.
Other possible causes:
– The ESP32 hardware is broken. Try another one. I had that a couple of times in the post myself.
– The MAC address is wrong. The beginning looks great, though. 90:84:2b:**:**:** is a typical start for a PU hub.