Hallo zusammen,

heute möchte ich mal eine weitere Lösung für die bekannten Probleme mit Powered Up zeigen:

- kein Smartphone nötig
- Krokodil o.ä. lässt sich mit der FB regeln
- Zwei Motoren gegenläufig mit derselben Taste der FB
- Wenn es heute geht, geht es auch in 10 Jahren noch
- Plug and play (s.u.)

Das „Geheimnis“ ist ein kleiner Microprozessor, nur 3x3 Noppen groß.

Die Hardware

Es ist ein ESP32 „M5Stack ATOM Matrix“. Das Schöne daran: er hat oben eine 5x5 LED Matrix, und diese Fläche ist auch ein Taster.
Außerdem ist er genau 3x3 Noppen groß und grau ...

Das Testprogramm

Es handelt sich um ein c++ - Programm und nutzt die legoino-Bibliotheken von Cornelius Munz.
Ich habe das so gestaltet, dass der ATOM das Programm fest eingebaut hat, dennoch aber aus mehreren Optionen (Profilen) gewählt werden kann.

Die Idee

- Man überlegt sich eine Anwendung (z.B. FB mit Regelung für alle Motoren)
- Schreibt das Programm dazu (das gibt es als Beispiel auch zum Download)
- schreibt das fest in den Controller
- fertig

Ab dann macht dieser Prozessor nach dem Einschalten (1 sec) immer genau das und nur das.
(Bis jemand was neues reibschreibt, aber das muss man ja nicht….)

Dazu braucht er nur noch 5V, mehr nicht. Kein PC, kein SmartDevice, nichts von alledem. Vor allem: keine Ahnung was der überhaupt wie macht.

Und erweitert…

Im Video zeige ich wie man auch mehrere „Profile“ anlegen kann, also wie Remote und Hub agieren sollen, bei welchen Tastendrücken was wie passieren soll. Aber man könnte auch ein Profil „Haunted House“ oder „Karussell“ oder irgendwas anderes hinzufügen, in denselben Baustein.

Die Kosten

Die ATOM starten bei ca 6 $ beim Chinamann, der Matrix kostet da um 8$, meiner hat 16 € bei Bezug in D gekostet. Das war‘ schon.

In 10 Jahren …

… läuft das immer noch genauso, wenn nichts kaputtgeht (und man es sich verkneift, das LEGO Hub upzudaten….)

Für Entwickler

Man braucht
- die Arduino IDE
- die legoino-Bibliothek
- die ESP32-Bibliotheken
- einen PC

Das hat man in einer Viertelstunde zusammengesammelt, wenn man sich mittel bis wenig auskennt. Es gibt etliche Tutorials im Netz, da hab ich mein Weisheiten auch her. (habe aber länger gebraucht, da ich gar kein c++ kannte)

Plug and Play

Doch, schon.
Irgendwer (mit Ahnung)
- schreibt ein Programm („2 beliebige Motoren gegenläufig“)
- kauft den ATOM für x €
- schafft das Programm drauf (max. 5 Minuten Arbeit)
- und verkauft das Ganze für x +y € weiter

Der Empfänger steckt es an sein USB-Ladeteil, fertig.

Oder man hat in der Bekanntschaft jemanden der das kann. Wenn die Programme irgendwo vorliegen braucht man das nur zuammenzuklicken.

Ausblick

Was fehlt sind also Ideen, was man überhaupt programmieren kann und will und braucht, und Leute die des Ganzen mächtig sind.

Grüße

Werner

Ps:
Hier als Teaser mal das "Profil1", das ist schon sehr überschaubar....

void control1() {

int sstep = 10;
int sdelay = 400;
int vmax = 75;

if (FB.isLeftRemoteUpButtonPressed()) Speed = min(vmax, oldSpeed + sstep);
if (FB.isLeftRemoteDownButtonPressed()) Speed = max(vmax * -1, oldSpeed - sstep);
if (FB.isLeftRemoteStopButtonPressed()) Speed = 0;

if ( Speed != oldSpeed) {
TrainHub.setMotorSpeed(portA, Speed * 1);
TrainHub.setMotorSpeed(portB, Speed * -1);
oldSpeed = Speed;
disSpeed(Speed);
delay(sdelay);
}
}

---

---

Dirk1313 , RobbyRay , asper , hassel62 , cubo , MTM , Legoben4559 , aap134 , SuklaaTalvella , Ben® , Xris , Garbage Collector , tastenmann , freakwave , SirJoghurt , UncleTom , JuL gefällt das (17 Mitglieder)

---

Hallo Werner,

sehr interessant!
Wie funktioniert das bei dem ESP32 mit den multiplen Bluetooth-Verbindungen?
Bei meiner Steuerung des BLE-Nano (Arduino) über mein Smartphone (Serial Bluetooth Terminal) bekomme ich nur eine Verbindung hin.
Informationen über die leguiono-Bibliothek habe ich auf die Schnelle bei google auch nichts gefunden.

Gruß Andreas

---

---

@Andreas
Du must die Rollenverteilung bei einer BLE Verbindung beachten.
Bezogen auf den Beispiel ist das gesteuerte Element dein Nano, das steuernde Element das Telefon.

Dein Telefon hat hier die selbe "Rolle" wie der ESP32. Kann also sicher Verbindungen zu mehreren Nano aufnehmen.
Dein Nano hat hier eine aehnliche "Rolle" wie Hub und FB.

Marc

---

---

Hallo Andreas,

aap134 hat geschrieben:

Der ESP32 baut die Verbindung zu mehreren Hubs auf. Er ist der "Chef".

aap134 hat geschrieben:Natürlich nicht
Das Zeug heißt legoino, sorry für den Tippfehler, hab's jetzt korrigiert.
https://github.com/corneliusmunz/legoino

Wenn Du die Arduino-IDE installiert hast kannst Du das einfach über den Library Manager auswählen. Aber es wird mit dem Nano nicht gehen, es ist für ESP32.


Grüße

Werner

---

---

Sehr interessant! Danke fürs Vorstellen.

Ich kann da also fertige Programme draufladen, die beim Einschalten bzw. auf Knopfdruck starten.

Wenn ich den Hub mit einem 9V-Netzteil und den ATOM mit einem 5V-Netzteil versorge, läuft das Ganze von morgens bis abends bzw. bis ich es ausschalte.

In den Programmen auf dem ATOM kann ich Werte von Sensoren verarbeiten, die ich an den Hub anschließe?

Man könnte also sagen, so ein ATOM in Verbindung mit einem 4-fach-Hub ersetzt mir einen teuren Spike-Zentralbaustein, sofern ich mich mit vier Anschlüssen zufrieden gebe.

Viele Grüße

Matthias

---

---

PS: In den ATOM-Spezifikationen steht "IR: Infrarot-Übertragung". Das könnte rein theoretisch sogar die Steuerung von PF-Komponenten ermöglichen, wenn da jemand eine entsprechende Bibliothek schreiben würde? Nur mal so als Gedanke...

---

---

AdmiralStein hat geschrieben:

Es gibt auch eine größere Ausführung (knapp 7x7) die zahlreiche Sensoren inkludiert hat und zudem über Lego-kompatible Noppena- und Technic-Pin-nschlüsse verfügt. Gibt es sicher auch anderswo günstiger.

---

Gruß
Thomas

mein Blog
meine Eisenbahnräder - mit funktionierendem Download

---

Hallo Andreas,
verwendest du ein Arduino Nano 33 BLE Board, mit Arduino BLE Bibliothek ?
Schau map hier:https://github.com/arduino-libraries/ArduinoBLE/issues/55

Offenbar hat Version 1.4 hier ein Problem die Bibliothek is no charge nichto gut a us bereft in Hinblick auf die Rolleston "Central", also die "steuernde" Rolle, aehnlich deinem Telefon.


Das Problem liege also in Lib /Middleware, nicht am Chip selber.

Alternativen:
1. Du kannst das Board das Board auch kit dem "MBED" Framework verwenden.
2. Du kannst das Board auch kit dem Adafruit Blue fruit Framework verwenden, dazu ms test Du Aber eine andere Firmware flashen,vermutlich zu schwierig, da man auch eine JTAG Programmer braucht.

Kurz:Wenn du beim nRF52840 Chip bleiben magst empfehle ich direct ein "Adafruit nRF Feather Express"
Wenn nicht Ist ESP32 sicker eine Blickling wert.

Hoffe das hilt ein wenig weiter.

Marc

---

---

Hallo Matthias,

AdmiralStein hat geschrieben:

genau, das Ding startet unter 1 sec, im Video haben die "Connect" Anzeigen ein delay von 0,4sec, bevor sie die Farbe wechseln, auch das grün beim Einschalten bleibt 0,2 sec stehen, sonst würde man es gar nicht sehen.
Und nein, das Programm startet *immer". Du kannst natürlich als ersten Befehl reinfummeln "warte bis Taste gedrückt". Oder "warte bis HUB connected".

AdmiralStein hat geschrieben:
Ja. Und macht alle 5min mal für 30 sec das Karussel an, oder alle Stunde die Kuckusuhr oder in Zufallszeiten mal den Aufzug vom Haunted House. Und es muss dafür auch nicht im "LEGO-Regal" liegen, sondern irgendwo in Funkreichweite.

AdmiralStein hat geschrieben:Ja. Aber mit der von mir benutzten Legoino-Programm-Bibliothek habe ich damit ein wenig Probleme, aber ja, auch sowas habe ich zum Laufen bekommen; da müsste nochmal jemand mit Programmier-Sachverstand drüberschauen.

AdmiralStein hat geschrieben:Prinzipiell ja, in der Realität wohl nicht.

Aber das wird jetzt eine sehr theoretische Diskussion.

Für "simple" Anwendungen bestimmt. Aber Du musst die Dinge programmiert bekommen. Legoino kennt m.E. kein "4-fach-Hub". Aber der Programmierer ist sehr aufgeschlossen - und schnell. Meine Anregung hatte er nach drei Stunden umgesetzt. Es mag auch andere Bibliotheken geben. Ich kenne mich da bei weitem nicht aus. Wie geschrieben: ohne dass sich jemand mit dem Kram auskennt werden wir nicht weiterkommen.

Je nachdem was Du machen willst (um mal wieder auf die Praxis zu kommen )
Ohne FB nur mit dem 4fach Hub macht das PyBricks schon eine ganze Weile. Auch mit weit mehr Befehlen.
Wenn Du mal schreibst was konkret(!) es tun soll kann ich mal schauen, ob ich sowas zusammenbekomme.
Und mit welchem Tool.

Grüße

Werner

---

---

AdmiralStein hat geschrieben:

Ja. Aber das alles gibt es ja schon seit Jahren, ich habe hier ein Beispiel da steht

J.A. Korten for Railbricks
Library by Roland Wiersma
November 2012
#include <legopowerfunctions.h> // this imports the LEGO PF library
Beschreibungen gab es seinerzeit in Railbricks.

Oder aber : man steckt am ATOM hinten(!) einfach eine IR-Diode ein, die die Signale der PF-FB empfängt -> LEGO Drehregler!

---

---

Thomas52xxx hat geschrieben:

Natürlich, beim Chinesen:
https://www.banggood.com/...E&cur_warehouse=CN

Das Ding hat keine LED-Matrix, sondern einen 320x240 TFT-LCD Bildschirm.....

---

---

tastenmann , hassel62 gefällt das

---

Hi,

Lok24 hat geschrieben:

Doch, "technic" 4-fach Hub geht auch seit 3 Wochen...
Ich gehe jetzt nochmal das "Sensor"-Problem an, aber das kann bei mir liegen. Mal schauen.

---

---

Lok24 hat geschrieben:

Das ging bereits wesentlich früher, man muss dazu lediglich mal aufmerksam die entsprechenden Punkte im Github verfolgen
Sagen wir so Cornelius ist etwas unorganisiert wenn es um die Zuordung der Funktionalitäten zu den Klassen der jeweiligen Hubs geht.

Das ist aber nicht schlimm: Mein Tip:

Nicht verwirren lassen, im Zweifel die konkreten Klassen für bestimmte Hubs Ignorieren, am besten die Basisklasse verwenden auf der die anderen Ableitungen aufbauen.

---

---

Hallo Marc,

vielen Dank für die Ergänzung.

Ruppie hat geschrieben:

Ich weiß weder was die "entsprechenden Punkte" wären noch wie man in Github etwas verfolgt.

Ruppie hat geschrieben:Ich weiß weder was Basisklassen sind noch was Ableitungen sind.

Eigentlich interessiert mich das auch alles nicht

Ich möchte nur ein funktionierendes Programm haben.
Da ich in dem Bereich aber völlig unterbelichtet bin hatte ich vor geraumer Zeit hier
https://www.1000steine.de...amp;id=442027#id442027
bereits um Hilfe gebeten, hat sich aber keiner erbarmt.

Egal, ich denke das Video zeigt ja die Idee, die wir beide schon länger diskutiert hatten:
Ein kleines $Irgendwas mit Gehäuse, Basisanzeigen und rudimentärer Bedienung, ganz ohne Elektronik-Bastelei.
Bezahlbar.

Grüße

Werner

---

---

Tag Werner;


Die Bibliothek basiert auf dieser Javascript Library :
https://github.com/nathankellenicki/node-poweredup

Die Basisklasse der Bibliothek ist "nur" die Transformation der Javascript Lib in C++ gemäß:
"Lpf2Hub.h - Arduino base class for controlling Powered UP and Boost controllers"

Die Klasse Lpf2Hub beschreibt die Basisklasse welche alle Grundfunktionalitäten enthält, also die gemeinsame Grundmenge Gleicher Funktionen:

"BoostHub", "PoweredUpHub", "PoweredUpRemote sind Ableitungen davon = Stelle dir Zweige oder "Kinder " vor.
Ähnlich Kindern ergeb diese von dem Vater Eigenschaften haben aber anderen Eigenschaften.

Das war in der Vergangenheit Grund der Verwirrung;
Die Klasse "PoweredUpUp" verfügte eine ganze Zeit nicht über 4 Ports, die BoostHub Klasse wohl.
Man konnte aber auch die Boosthubklasse mit einem PoweredUp hub verwenden und bereits alle 4 Ports des Powered Up Hubs nutzen.



Daher mag es für den Begin praktisch sein die konkreten Klassen zu verwenden.
Für speziellere Anwendungen ist es aber ( meiner Meinung nach) besser die Klasse "Lpf2" zu verwenden.
Im Zweifel setzt man die Funktionalitäten in einer eigeen Klasse zusammen wie man diese benötigt.

Wie immer; Hier liegen eben die Grenzen im gerauch einer Lib von "jemanden".

---

---

Hi Marc,

vielen Dank für die ausführliche Antwort.

Ich habe leider kein Wort verstanden, was aber nicht an Dir liegt.
Es liegt eher daran, dass ich mich dafür Null interessiere (hatte ich auch schon geschrieben .

Das einzige was mir weiterhilft sind funktionierende Beispiele.
Dann gelingt es mir gelegentlich aus 2 Beispielen ein Programm zu machen.

Derzeit scheitert es an der Sensor-Erkennung, das habe ich aufgegeben (mangels Idee, wie Fehler zu suchen).


Grüße

Werner

---

---

Lok24 hat geschrieben:

Hallo Werner,

Ich habe mich schon eine Weile nicht mehr mit der legoino lib befasst, hole ich demnächst nach
Das Problem mit der Sensorerkennung und Auswertung über das LEGO Bluetooth Protokoll ist, das die Sensoren Ersteinmal zur Übertragung der Werte konfiguriert werden müssen.
In Teilen ist das bestimmt schon in der Lib drin, man kann da doch bestimmten "weg" fahren sofern ich mich erinnere, nicht nur "An" Aus.

Bezüglich Hilfe:
Neben Hilfe von Conelius bit du hier auch falsch: Such dir mal ein ESP32 Forum.
Zur Einarbeitung sehr empfohlen: https://randomnerdtutorials.com

Wie du schreibst: Im grunde ist das alles nicht für dich von Interesse dich mit den Grundlagen zu beschäftigen, ist in Ordnung.
Ich sage es mal so: So wirst du aber immer primär von den Arbeiten dritter sein. Wenn dir das Genügt, auch ok.

Wenn du den Grad der "Abhängigkeit von dritten minimieren wilst geht es eben nur in Eigenleistung.

Wie gesagt; deine Endscheidung




PS:
Tip wenn du es mehr selber erforschen willst:
https://infocenter.nordic...iffer_ble%2Fintro.html

Es gibt günstig einen USB Dongle wie da Beschrieben
https://www.mouser.de/Pro...wLWEAQYASABEgKIOfD_BwE

> Ich benutze sowas ähnliches

oder dies;

https://www.adafruit.com/product/2269
das geht auch
https://www.adafruit.com/product/2267


Der trick geht wie folgt:
Es gibt ein Wireshark Plugin damit kannst du mit den beschriebenen (funktionierte zuletzt bei mir jedoch nur mit Wireshark 3.07 nicht neuer).

Nun kann man den Datenverkehr, beispielsweise der " Powered Up App" oder Control +, oder eben FB und Zug Hub mitverfolgen.
Da sieht man dan beispielsweise genau diezeichenketten, welche du schon bei deinen PI projekten gesehen hast.

Insbesondere Interessant ist es sich die "Handshake" oder Startsequent zwischen Technic Hub und Beispielsweise Control+ einmal anzusehen.
Da stehen dann auch die Telegramme drin, welche die Sensoren für den Datentransfer zur App konfigurieren,
Du musst diese dann "nur" noch gemäß LEGO BLE Doku nachvollzihen.


Ich habe momentan wenig Zeit.
Ich habe mal "Schmierversuche gemacht" mit den unterschiedlichen Sensoren, wenn ich die noch finde schreibe ich mal kurz was dazu
PS:
Vielleicht hilft dir im dr. Bricks Forum oder bei Eurobricks auch nochmal jemand.

---

---

Thomas52xxx gefällt das

---

Hallo Marc,

Ruppie hat geschrieben:

Wenn Du das sagst...
Es gibt bei legoino ein Beispiel, das funktioniert mal, mal nicht.

Ruppie hat geschrieben:Das bin ich bei meinem Fernseher auch, den kaufe ich fertig Laden.
Und, immer bedenken: ich habe derzeit gar keine Anwendung für sowas! Ich brauche das nicht.
Und wenn ich was programmieren will kann ich die LEGO App nehmen.

Ruppie hat geschrieben:
Du könntest mir durchaus helfen, indem Du mir einfach die vier Progammzeilen für dieses "lpf2" hier postest.
Lauffähig, keine verbale Beschreibung. Dann würde ich das mal probieren.

Momentan sieht das so aus:

#include "PoweredUpHub.h"

PoweredUpHub TrainHub;
PoweredUpHub:: Port portA = PoweredUpHub:: Port::A;

TrainHub.init();

---

---

Lok24 hat geschrieben:

Empfehlung:
Schau dir mal die Doku zum LEGO Protokoll an: https://lego.github.io/le...ut-format-setup-single

Abschnitt 3.3 Message Type Definitions - PORT(s) related

Mit 0x41h konfigurierst du einen Port zur Übergabe eines einzelnen Sensorwertes
Mit 0x42 konfigurierst du einen Port zu Übergabe mehrere Sensorwerte, sofern verfügbar, Ein Motor kann etwa Speed und Winkel zurükgeben

0x45h, und 0x46h sind die entsprechenden Messagecodes für die Datentelegramme welche dann mit den Sensorwerten zurückgeschickt werden.

Es ist von der Konfiguration Abhängig, ob die Daten automastisch bei Wertänderung, oder nur auf Anforderung gesendet werden.
Die Konfiguration der Port sensoren ist immer eine Sequenz:
- Übertragung sperren
- Parametrieren
- freigeben


Ohne Garantie, habe ich mal bei mir etwas herumgespielt, eis aber nicht mehr wlcher stand das war , nur als Grobe Richtung in einer meiner Init Routinen:


Ohne Gewähr: Beispiel für Port D, kann Spuren von Unfug enthalten

#1 SendData[]={0x0a,0x00,0x41,0x03,0x01,0x10,0x00,0x00,0x01,0x00};
#2 SendData[]={0x08,0x00,0x42,0x03,0x01,0x00,0x10,0x20};
#3 SendData[]={0x05,0x00,0x42,0x01,0x02};
#4 SendData[]={0x0a,0x00,0x41,0x01,0x01,0x02,0x00,0x00,0x00,0x01};
#5 SendData[]={0x05,0x00,0x42,0x01,0x03};
#6 SendData[]={0x08,0x00,0x81,0x03,0x11,0x51,0x00,0x00};

Für Port A
#1 {0x0a,0x00,0x41,0x01,0x02,0x02,0x00,0x00,0x00,0x01};


Für "Andere Ports" hier Port "0x63"
SendData_17[]={0x0a,0x00,0x41,0x63,0x00,0x01,0x00,0x00,0x00,0x01};



Erinnerung: Info. welcher Port was macht ist hier beschrieben:https://www.eurobricks.com/forum/index.php?/forums/topic/162288-powered-up-a-tear-down/&page=23
Im unteren Bereich nach meinem Post insbesondere mal die Anmerkungen von AlecDGeneric und Mr Hobbles vom 12.02.
ansehen und die Links

Hoffe das hilft

Marc

---

---

Hallo Marc,

Ruppie hat geschrieben:

Nein, hilft mir leider gar nichts.

Ich rufe das Beispielprogramm "legoino -> TrainColor" auf,
mal liefert es 0 als Sensorwert, mal > 0.
(> 0 wäre richtig)

Das kann eigentlich nicht richtig sein?

Das (und nur das) ist mein Problem.
Ein legoino-Problem. Oder mein ESP 32?

---

---

Lok24 hat geschrieben:

Ich habe in der lib auch nur die folgenden Implementierungen zu Sensoren gefunden:

double getDistance();
int getColor();
int getRssi();
int getBatteryLevel();
double getHubVoltage();
double getHubCurrent();
int getBoostHubMotorRotation();
int getTiltX();
int getTiltY();
int getFirmwareVersionBuild();
int getFirmwareVersionBugfix();
int getFirmwareVersionMajor();
int getFirmwareVersionMinor();
int getHardwareVersionBuild();
int getHardwareVersionBugfix();
int getHardwareVersionMajor();
int getHardwareVersionMinor();


In der Summe aller dinge offenbar eben nicht vollständig (nur eine Vermutung)

In den Beispielen gibt es ja ein bisschen was zu den Sensoren, hast du ja schon gefunden.

Zu deiner Frage: Im Zweifel ein Fehler in der Implementierung in der Bibliothek oder ein Fehler in der Anwendung am Vesten du fragst Cornelius.


Im Kern das Problem was ich meinte: Mittelfristig wirst du nicht darum herum kommen dir ein eigenen "Framework " aus Funktionen zu erarbeiten.
Ansonsten bist du stets "von den Happen" abhängig welche dir andere hinwerfen, keine Wertung nur eine Meinung,

---

---

Lok24 hat geschrieben:

Sagen wir mal so:
Wenn "0" ein ungültiger Farbwert ist kann es ein schlecht abgefangener Lesefehler sein.
Die Frage ist, ob du zwische gültigen und ungültigen Farbwerten ein Muster erkennst, oder ob die "0" Werte zufällig "eingestreut" erscheinen.

Wie der Sensor arbeitet ist ja nicht genau belegt (oder bei Philo schauen) im Zweifel ist eben nicht garantiert, das der Hub die fehlerhaften Werte nicht mitüberträgt
Wie beschrieben, Mal Cornelius fragen oder selber ausfiltern in deinem Programm.

Giancann hat doch eine eigene Implementierung mit dem Farbsensor und ESP32 gemacht, frag den doch mal, er ist doch so hilfsbereit

---

---

Lok24 hat geschrieben:

Mal was anderes:

1. achte mal ein wenig auf die Form deiner Ansprache, sei einfach nicht traurig wenn mir schlicht die Zeit fehlt dir den Arsch zu pudern, um es mal deutlich zu sagen.
2. Wie ich dir bereits mehrfach sagte: Derzeit mit anderen Projekten Busy. ESP32 , leguino... sind momentan "out of scope".
3. Wir haben nun genügend oft erörtert das unserer Projekte Verschieden sind, daher gibt es keine Codebasis zum tauschen, du wirst dich also mit den verbalen Hilfestellungen begnügen müssen.


Eine feine Zeit

---

---

Hallo,

Ruppie hat geschrieben:

Ja, sicher. Und es funktioniert manchmal, manchmal nicht.

Ruppie hat geschrieben:
Das hatte ich heute vor, komme aber nicht dazu

Ruppie hat geschrieben:
Nein, das habe ich ja vor Jahren schon auf meinem Raspberry (ohne alle externen Libraries, direkt auf dem LWP3 aufsetzend) getan. Deswegen kenne ich auch das Protokoll und wie man Sensoren entsprechend ansteuert (notifications), damit sie rückmelden, muss man ja für die FB sowieso auch machen.

Und ich muss das nicht nochmal tun, ich kann, wenn das nicht läuft, es einfach sein lassen.
Wie gesagt, ich brauche das überhaupt gar nicht.

Das was ich machen wollte steht im Eingangspost, und das tut es ja.
Eben etwas sehr einfaches.

---

---

Ruppie hat geschrieben:

*seufz* Wenn das Programm 0 anzeigt zeigt es immer 0, egal welche Farben man ihm zu fressen gibt.
Wenn es beim Start 255 zeigt zeigt es in der Folge auch die Farben korrekt.

Ruppie hat geschrieben:
Darum geht es halt gar nicht, er arbeitet manchmal gar nicht.

Ruppie hat geschrieben:Das ist er, aber ich wüsste nicht mal wie ich die Frage formulieren sollte.
Ich brauchte ein Beispiel. Aber das schrieb ich schon.

---

---

Hallo,

Ruppie hat geschrieben:

Ich bin nicht traurig. Ich verstehe allerdings nicht warum Du, statt einfach vier(!) Programmzeilen zu tippen, mir seitenlange Tipps gibt was ich alles wie machen könnte.
Das ist sicher gut gemeint, aber für das was ich machen möchte völlg oversized.

Ruppie hat geschrieben:
Codebasis tauschen? Es war doch nicht mein Vorschlag, irgendeine andere Bibliothek zu nehmen, sondern Deiner?

Nichtdestotrotz vielen Dank für Deine Bemühungen.

---

---

Lok24 hat geschrieben:

Dann formuliere ich die Frage mal für dich und warum:
Giancann hat, wie im Video gezeigt, ein Beispiel erstellt wie der ESP32 ,it dem Farbsensor arbeitet.

Wichtig:
In seinem Beispiel aber vollständig ohne LEGO und Bluetooth, es geht darum, wie die Farbwerte über die Serielle Schnittstelle übertragen werden
Wenn du so willlst ist das ein Beispiel, wie der Hub mit dem farbsensor interagiert, bevor er die Werte per BLE überträgt.

Das Beispiel ist also im Prinzip "eine Ebene" unter der Leguino Lib.

Aber nach welchem Beispiel suchst du noch wenn es zunächst mal um das Grundverständniss geht.
Hier kannst du dann explizit die Werte sehen,w elche der Sensor überträgt.

Damit hast du ein "low level" Prüfmittel ob der Fehler im Sensor liegt oder in der späteren Übetragung in BLE.


Die Frage für dich an Giancann würde also sinngemäß lauten: "Kannst du mir bitte dein Beispiel aus dem Video geben zur Ansicht"
PS:

Frag ihn ausserdem mal welches ESP32 Board er da verwendet hat, da du den Sensor ja nunmehr an.
Er mag dir einfach das Program geben mit Angaben zum Board und Anschlussbeschreibung, fertig.

Was ist daran nun so schwierig diese frage an ihn zuj stellen ?

---

---

Lok24 hat geschrieben:

Hallo,
Wenn du mal in die *.h Dateien siehst, steht da in den Definitionen zur Farbe; Black =0
0 wäre also schwarz.

Wenn das öfter passiert, obwohl Farbe nicht schwarz ist tippe ich auf einen nicht ordnungsgemäß funktionierenden Sensor ?!
Wie beschrieben; Die Arbeit von Giancarlo ist prima geignet den Sensor zu prüfen

---

---

Vielen Dank, wie gesagt, ich muss das nochmal testen.
Aber an meinem Rechner läuft das alles gar nicht, und der andere war heute belegt.

Ich vermute ein Problem mit dem Timing. Der Sensor an dem Hub geht mit allen anderen Programmen einwandfrei.
Evtl braucht das "Notifications" mal länger als erwartet. Das Ganze läuft ja offenbar nicht in Threads.

---

---

Lok24 hat geschrieben:

Hallo Werner , kleiner Nachtrag um die zu (entwirren).

Sieh dir hierzu auch mal die Dateien : Lpf2Hub.h,PoweredUpHub.h,BoostHub.h an.


Auszug aus PoweredUpHub.h
class PoweredUpHub : public Lpf2Hub <--- Die Klasse PoweredUpHub "erbt" oder ist Ableitung von der "Basisklasse" :LPf2Hub
{ Solange keine Eigenschaften "überschrieben" werden hat die Klasse alle Eigenschaften von LPf2Hub
public:



//Port definitions specific to PowerdUp Hubs <--- Das ist das "problem", in Lpf2Hub und Boosthub Klasse sind mehrere Ports definiert
enum Port Da die Auflistung hier berschrieben / Angepasst wird, sind in dieser Klasse die urprünglichen
{ Definitionen nicht mehr verwendbar, da eben überschrieben.
A = 0x00,
B = 0x01
};



Vergleiche mit Boosthub

class BoostHub : public Lpf2Hub
{
public:
//Port definitions specific to Boost Hubs
enum Port
{
A = 0x00,
B = 0x01,
AB = 0x10,
C = 0x02,
D = 0x03,
TILT = 0x3A,
CURRENT = 0x3B,
VOLTAGE = 0x3C
};


Eine Lösung: Übernimm doch einfach die Port enum genauso in die PoweredupHub Klasse, wenn es für dich so angenehmer ist.


Mir war unklar warum wir nicht bei einer Klasse bleiben können, da ja stets ähnliche Dinge beschrieben sind.
Tip:


Kopiere Boosthub.cpp und Boosthub.h in Werner.CPP und Werner.h, erstelle also einen Wernerhub wo du einfach die sachen so aus den klassen zusammenkopierst wie du es brauchst.

Einzige Regel:

class WernerHub : public Lpf2Hub

Viel Spass

---

---

Hallo, dankeschön.

1.) Boosthub mit MoveHub läuft einwandfrei
2.) Boosthub mit TrainHub läuft garnicht
3.) mit Lpf2Hub läuft gar nichts
4.) die enums für die Ports sind in BoostHub und poweredupHub gleich
5.) das Beispiel TrainColor läuft mal und mal nicht
6.) mein Programm läuft mal und mal nicht

5 und 6 könnten nicht sein, wenn die enums falsch wären.
Meine Folgerung: leguino funktioniert nicht zuverlässig in meiner Umgebung.

---

---

Hallo Marc,

so, geht jetzt alles.
Auch mit dem PoweredUp Hub, alle Libraries unverändert.
Color, Distance und Rotation.

Aber: ein steiniger Weg.

Power On
seriellen Monitor starten
Reset des ATOM
Connect -> Connected
- > alle drei Werte 0

bei laufendem Hub:
Reset des ATOM
seriellen Monitor neu starten
Alle Werte da.

Also irgendeine Unverträglichkeit/Delay/Timing beim Startverhalten/Conncet Programm/ATOM

Nichtsdestrotz. Als Laie halte ich das legoino immer noch für falsch.
Es darf nicht 0 ausgeben, wenn gar nix da ist.

---

---

Lok24 hat geschrieben:

Hallo Werner,
ich weis nicht genau wie der Farbsensor arbeitet: Vermutung er strahlt ein element an und wertet das Reflektierte Lich aus-

Wenn das so ist, wird eben in dem Falle, wo du nix vor den Sensor innerhalb des "erlaubten" Bereiches vor sen Sensor hälst auch nix reflektiert.
Nix refelxtieren wäre aber gleichbedeutend mit Schwarz = 0. Oder vereinfacht, vermutlich erhälst du 0 für alle nicht interpretierbaren Farben.

Wie beschrieben, ohne Doku zum Sensor nur geraten.

---

---

Moin Marc,

Ruppie hat geschrieben:

Nein. Es gibt definierte Farben (5,6,7 etc, auch da sind die Beispiele falsch).
Und es gibt schwarz = 0.
Und es gibt undefined = 255, das ist das was Du meinst. Das liefert er auch, wenn er denn arbeitet.

Aber der Sensor arbeitet ja gar nicht.
Eine sinnvolle und korrekte Ausgabe wäre also NULL statt 0.
(gilt auch für Distance und Rotations)

---

---

Lok24 hat geschrieben:

Ich hab den kleinen jetzt hier - was mir aber noch fehlt wäre das Beispielprogramm aus dem Video. Das wäre extrem nützlich, damit man "Profile" tauschen kann und eine gemeinsame Entwicklungsbasis hat (und nicht jeder das gleiche für sich entwickelt ^^)

Ich habe schon verschiedene Dinge mit Bricknil umgesetzt - fand es aber immer etwas aufwendig erst das Raspberry pi herauszuholen.

Alternativ würde sich übrigens der Odroid Go anbieten. Das ist ein Gameboy Clone mit Esp32 - also Tasten und Display. Damit könnter man sogar sehr viel mehr live konfigurieren.

---

---

Hallo,

ElTentakel hat geschrieben:

Leider hast Du die Privatnachrichten abgeschaltet....sonst hätte ich es da schnell eingestellt.

Aber es ist nichts viel anderes als das Legoino PoweredUpRemote-Beispiel, halt bißchen garniert mit den Anzeigen.
Das control3 ist außer Betrieb.

Natürlich müsste man das noch besser strukturieren und Funktionen und LOG/Display evtl. auslagern.
Wichtig ist am Anfang: was soll es tun? Denn danach richten sich ja die Anzeigen und Konfigurationen (wenn überhaupt nötig)

---

---

Lok24 hat geschrieben:

Jap - ich habe bereits mein eigenes Beispiel damit gebaut und frage mich ob man es schafft trotz der wenigen Anzeigeelemente eine Konfigurierbarkeit zu schaffen, die es in einem begrenzten Maße möglich macht auch ohne PC einfache Szenarien zu konfigurieren.

Defakto hat man ja mit einer PoweredUp Fernbedienung 6 frei programmierbare Knöpfe. Der M5Stack Atom hat zudem einen Beschleunigungs- und Neigungssensor. Man könnte z.B. den Display Knopf nehmen um in einen Menu-Modus zu kommen, in dem man Motoren per Fernbedienung miteinander Verknüpfen oder entgegensetzen kann. Farben helfen für die Visualisierung. Das wäre für viele Hilfreicher als eine feste Programmierung mit Profilen. Auch Servos ließen sich so konfigurieren.

Das muss so schnell gehen, dass es nicht nervt, es nach jedem Anschalten neu machen zu müssen. Ggf. kann man Profile auch per EEPRom speichern. Es würde ja (erstmal) reichen, wenn das letzte Profil gespeichert bleibt.

---

---

ElTentakel hat geschrieben:

---

---

Hallo,


ElTentakel hat geschrieben:

Ja, natürlich.
Leider wird das jetzt wieder theoretisch, die Frage ist doch: wer braucht das?

ElTentakel hat geschrieben:
Wer sind die "vielen", und was wollen sie damit machen?

ElTentakel hat geschrieben:
Wie willst Du die bedienen?

ElTentakel hat geschrieben:Es wird nerven. Es widerspricht auch meiner ursprünglichen Idee vom Plug&Play.

ElTentakel hat geschrieben:
Ja, richtig.

Insgesamt ist das alles nicht schwierig, weil der ATOM ja auch Texte ausgeben kann.
Und Zahlen. Und Farben. Und Symbole. Aber, viel wichtiger als Rückmeldung ist doch das Modell selbst. Man sieht doch, was es tut.

Also: ohne eine tiefergehende Analyse der möglichen Anwendungen (Ich sehe ungefähr drei) wird man keine sinnvollen Möglichkeiten finden.
Ich finde Deine Ideen gehen in die die richtige Richtung, sind aber schon zu kompliziert.

---

---

Lok24 hat geschrieben:

Ich denke da brauch es keine tiefgreifende
Analyse. Sollte ich die Zeit finden, das Vorhaben zu implementieren würde ein Test viel mehr Aussagekraft haben als eine Diskussion ohne Gefühl für das Ergebnis. Es braucht keine komplizierten Menüs für das Vorhaben - nur ein Verständnis für minimalistische intuitive Symbolgebung und Farbsetzung.

Profile haben das Problem das sie erklärt werden müssen. Sie schrenken auch die Kreativität ein - Eigenkreationen mit Speicherplätzen schafft mehr Raum für Kreativitat und endspricht eher der ursprünglichen Lego Idee.

Noch zum Verständnis: Die Konfigurierbarkeit ist komplett durch Fernbedienung und das Gerat selbst gegeben - also alles Plug and Play.

---

---

Hallo,

ja, verstehe. Ich habe vielleicht keine glücklichen Begriffe gewählt.

Die "Profile" weisen auf bestimmte Sets, z.B. CityTrain, Krokodil, Haunted House, Karussell, Achterbahn etc.
Die "Konfiguration" weist auf die Art wie es zu bedienen ist, also z.B. mit oder ohne FB, bei Tastendruck etwas tun, oder Toggle etc.
Und die "Parameter" legen individuelle Einstellungen fest, also z.B. wie schnell sich das Karussell drehen soll. Oder wie lange.

Aber erstmal müsste man klären wie man das Sensor-Problem und das Verbindungsproblem mit legoino löst.

---

---

Phlox gefällt das

---

Hallo,
ich bin neu im Sektor powered up/ boost.
Den Personenzug gab es Weihnachten 2019 und jetzt gehts es mal ans Programmieren, bevor ein Boost ins Haus kommt. Leider muss dann immer die App laufen.

Ich suche nach einer Möglichkeit nur mit der Bluetooth Fernbedienung (also ohne App) neben dem Zugmotor (der auf Kanal A bereits mit + , - und Stop zu bedienen ist)
1. einen Farbsensor auf Kanal B auszuwerten und farbspezifisch Befehle auszuführen.
2. Weiter möchte ich die noch freie rechte Seite der Fernbedienung verwenden (3 Tasten, also + - und Stop), um 3 Weichen mit jeweils einem HUB 88009 per
Tastendruck umzuschalten.

Es wären also 4 HUBs (1 HUB im Zug, wobei Kanal B den Farbsensor erhält; und die 3 anderen bei den Weichen) anzusprechen.

Ist sowas möglich mit dem M5Stack Atom und entsprechender Programmierung? Oder verlange ich da zuviel von so einem Atömchen, oder von den verfügbaren Bibliotheken? Lautsprecher wären natürlich auch noch super....

Danke für jede Antwort, auch für vernichtende

Schöne Grüße

Phlox

---

---

Hallo,

schöne Idee. Im Prinzip geht das alles.
Und ich weiß es nicht, bin mir aber sehr sicher: das geht auch mit dem Atom.

Aber:
Ich hatte im anderen Post (den Du ja gelesen hast) darauf hingewiesen, dass man das mit der derzeitigen legoino - Bibliothek nicht so einfach lösen kann.

Hier müsste man nochmal ein wenig "Jugend forscht" betreiben.
Mit andern Worten: es müsste mal jemand, der gut C++ kann, da drauf schauen.

Evtl fehlen da nur eine Handvoll Programmzeilen.

---

---

Lok24 hat geschrieben:

---

---

Hallo Marc,

vielen Dank, das ist mir bekannt, geht aber leider am Zweck vorbei.

Denn für WLAN brauchst Du die IDE und die serielle Verbindung, um einmalig SSID und Key einzurichten.
Also nichts für Plug & Play.

Grüße

Werner

---

---

Lok24 hat geschrieben:

Ja, mir ist auch schon aufgefallen, das keine Callbacks unterstützt werden. Da ich insbesondere den Tacho Motor als Servo konfigurierbar hätte, ist das natürlich ein Deal Breaker. Auch ist ein ständiges Abfragen sehr ungenau.

Aber dennoch kann ich es ja mal bei Gelegenheit umsetzen, denn für mich wäre der Nutzen sehr groß endlich mal meine schweren Loks mit zwei Motoren auszustatten oder einen Tracked Racer ordentlich steuern zu können, ohne das beim Lenken gleich die 2. Kette blockiert. Auch Anfahrkurven zum schonen von Zahnrädern wären echt angenehm. Mir gehts halt eher um Mocs und RC Nachrüstungen als um bestehende Lego Sets.

---

---

Hallo,

ElTentakel hat geschrieben:

Bist Du als Stefx im legoino-chat unterwegs?

ElTentakel hat geschrieben:
Ist mir nicht klar, Du brauchst doch den Motor nur um x Grad nach links und recht bewegen, warum benötigst Du da eine Rückmeldung, was habe ich übersehen?

ElTentakel hat geschrieben:
Das habe ich gerade programmiert. Mal schauen was sich da ergibt.

---

---

Lok24 hat geschrieben:

Nein - aber ich hab die Dokumentation gelesen

Lok24 hat geschrieben:

Ich weiß nicht, wann der Motor das Ziel erreicht habe - Für Schalter bzw. Prozesse ist das aber relevant. Servos sind nicht nur zum lenken da. Aber ich denke das Projekt würde vielen auch ohne garantierten Servoeinschlag sehr nützen - ggf. kommte es ja noch später.

Lok24 hat geschrieben:

Ich habe die GUI zum einstellen fertig. Ich muss jetzt noch den Anmeldevorgang vollenden und die Motorfunktionen implementieren - und die passende GUI im Statusmodus. Ich finds sehr benutzar - sobald ein minimales Funktionsset fertig ist, melde ich mich noch mal. Das kann aber wieder ein wenig dauern .

---

---

Lok24 gefällt das

---

So, ich habe jetzt ein erstes funtkionsfähiges Proof of Conzept:

OpenPowerBrick bei Github

Es ist alles andere als fertig oder schick, aber schon recht vielversprechend.

Mir ist beim drehen des Videos auch aufgefallen, dass die Status-Anzeigematrix gedreht ist .

Geplant sind noch die Unterstützung vom Control+ Hub. Wenn möglich sollen auch zwei PoweredUp! Hubs gleichzeitig gehen, aber ich hab so schon Probleme mit dem Pairing. Das muss erstmal stabilisiert werden. Der Versuch zwei Fernbedienungen anzuschließen ist jedenfalls grandios gescheitert - aber das probiere ich später noch mal.

Aber erstmal möchte ich den Code aufräumen (Modularisierung) und ggf. ein paar Motorfunktionen hinzufügen.

/Edit: Als grundlegende Erklärung:

Oben sind die Eingänge (Fernbedienung) und links die Aktoren (Motoren) - mit dem M5 Schalter drückt man die Statusfenster und die Eingänge durch. Mit der linken PU Controllerseite wählt man die Aktoren aus und dann kann man mit der rechten PU Controllerseite eine der bisher vier Funktionen wählen. Mit Hilfe des Stop Knopfes soll man später auch einen weiteren Parameter (z.B. Maximum, Winkel, Farbe, je nach Aktor/Eingang etc) steuern können.

---

---

Lok24 , Tad16o , Beobachter74 , Thomas52xxx , JuL gefällt das (5 Mitglieder)

---

So, ich habe jetzt noch einen 8-Stufen Motor modus hinzugefügt und ein Release für alle erstellt, die einfach nur das fertige Binary flashen wollen:

https://github.com/ElTent...rick/releases/tag/v0.2

Ich habe das ganze mit einer Lok mit zwei Motoren getestet - die eine hat Stufenwahl Vorwärz, die andere Rückwärts: es funktioniert einwandfrei.

---

---

Nabend!
Habt ihr schon gesehen was MattzoBricks so treibt?
Er nutzt u.a. auch einen ESP-32 als Controller für PUP.
Ziel seiner Architektur ist zwar Voll-Automation (über RocRail), aber zumindest für die (BT-) Verbindung zwischen ESP-32 und dem PUP Hub hat er ja Dinge entwickelt bzw. integriert.
MattzoBricks

Grüße

Benjamin

---

---

Beobachter74 hat geschrieben:

Spannend finde ich auch hier den Trend auf gekaufte Hardware zu verzichten da wird sich Werner freuen (auch wenn der keine Züge mag oder besitzt
Das RocRail Project ist cool ich bin aber ebenfalls kein Eisnbahnfan.
Danke für das Teilen dennoch.

---

---

Hallo Benjamin,

Das ist aber schon völlig anders als das was ich hier vorgestellt habe.

Es erfüllt auch einen anderen Zweck.
Dennoch: es ist schon sehr komplex, um nicht "nerdig" zu sagen.

Verstehe nicht warum für PF extra Motorshields braucht. Eine einfach Ansteuerung des IR-Empfängers würde schon genügen.
Und zu bedienen ist das ganze auch schwierig, mal eben einen Zug fahren geht ja nicht. Du brauchst: Monitor, Maus, Tastatur, PC und musst den PC erst booten.
Sinn macht das auch nur für große und vollautomatisierte Anlagen, also eine Materialschlcht.

Ein Anbindung an 4Dbrix Wifi (gibts das überhaupt noch?) aber es fehlen Buwizz (auch 3.0) und Sbrick.
Manches ist merkwürdig: man muss die "Firmware" neu laden in den ESP?
Man soll den ESP im Zug mitfahren lassen? Und bei Lokwechsel?
Und dann beseitigt man jedes Reichweitenproblem mit WiFi?
(Übrigens steuert mein microHub die Züge auch via WLAN, wenn gewünscht )

Und was meint den das hier:
"Der Controller ist fertig, getestet und betriebsbereit.
Die Bauanleitung findet sich hier."

Ich glaube das ist insgesamt sehr speziell.

Grüße

Werner

---

---

Lok24 hat geschrieben:

Meiner Meinung erfüllt es einen ähnlichen Zweck nur mit einem anderem Ansatz.
Lok24 hat geschrieben:
"Nerdig" gefällt mir nicht klingt mir zu ähnlich zu "neidig".
Sagen wir einfach es ist eine erwachsenere oder reifere Lösung, da eben von vorhandenen Produkten weitestgehend unabhängig.
Lok24 hat geschrieben:
Eben um nicht von kaufbaren Vorhandenen Lösungen abhängig zu sein.
Lok24 hat geschrieben:
Einfach ein etwas anderer Ansatz zum "Train Automation Project" wieauf Eurobricks vorgestellt.
Lok24 hat geschrieben:
Die fehlen nicht die wurden bewusst nicht berücksichtigt, in diesem Ansatz braucht die niemand, das ist eben die Idee hinter dem "Eigenbau".
Lok24 hat geschrieben:
Was genau ist daran merkwürdig ? Ohne ein Program macht ein ESP32 nix, das ist bei dir nicht anders.
Lok24 hat geschrieben:
Die Idee ist, das eben im Zweifel jede Lok ein eigenes Antriebsystem, bestehend aus: ESP32 - Motortreiber - Motor -Akku, verbaut hat
Es ist gar kein Wechsel vorgesehen, genauso wie du ja die Trainhubs in den Legozügen nicht dauern umtauschts, jeder Zug hat einen.
Lok24 hat geschrieben:
Warum nicht ?
Lok24 hat geschrieben:
Bezweifelt keiner
Lok24 hat geschrieben:
Ist deine Löung auch, ist immer so, macht die Welt bunter
Lok24 hat geschrieben:

Ebenso

---

---

Hi Marc,

Ruppie hat geschrieben:

Nein, der Zweck ist doch, eine 30qm große Anlage komplett automatisiert zu betreiben, auf der 4-5 Züge gleichzeitig fahren. Mit 100(!) Sensoren im Gleis. Das eben managed Rockrail. Und es gibt hunderte von Selbstbaupojekten für die Modllbahnkomponeneten, die man direkt über Rockrail steuern könnte. Wäre zu einfach

Ruppie hat geschrieben:
Ja, eben. Dafür gibt es DCC via Wifi.

Ruppie hat geschrieben:
Warum nutzt er dann die PoweredUp Hubs? Oder hab ich was verpennt?

Ruppie hat geschrieben:
Das würde ich mal als Anwendungsprogramm bezeichnen und nicht Firmware.

Ruppie hat geschrieben:
Weiß nicht. Man betreibt (als Beispiel) die LEGO-Züge mit der LEGO FB. Oder auch alles andere.
Aber eine Lösung für eine komplett automatisiert EB-Anlage, die nur(!!!) mit Rocrail funktioniert ist m.E. schon speziell. Nichtsdestotrotz: ich finde das sehr faszinierend was er da baut.
Ich hätte nur, ausgehend von Rocrail, andere Lösungen gesucht.
Wie ich es sehe baut er viel mit 4DBrix, und das ist schon sehr proprietär.
Und wie lange es da noch was zu kaufen gibt ist ja seit Monaten unklar.
Die Software von denen taugt jedenfalls offenbar nix.

Grüße

Werner

---

---

Lok24 hat geschrieben:

Ohne zu religös oder klugscheißerig zu werden : Im Bereich der Microcontrollerprogrammierung / Embedded Systeme sind die Begriffe zunächst mal gleichwertig verwendbar.

---

---

Lok24 hat geschrieben:

Nur so eine Vermutung, etwa wie folgt: "Ja wir könnten auch fertige Antriebssysteme einbinden sofern vorhanden, nötig diese für teures Geld zu erwerben ist es aber nicht."

Lok24 hat geschrieben:
Eben: Andere Leute, andere Ansätze, das meinte ich mit "bunt"

PS:
Ulkiger weise scheint es einen Trend zu geben Antriebssysteme für die Loks aus vorhandenen Tein selber zusammen zu stellen.

https://www.youtube.com/watch?v=G2ZoPt2Lfb4

Stell ihm doch mal dein System vor -)

---

---