Max T.

[Max T.]

Hallo Zusammen,

ich hatte kürzlich ein ähnliches Problem bei der gleichen Weiche sind mir 2 Servos kaputt gegangen, nach langem probieren, mit neuen Servos HD-1800A die Trixbrix verwendet (sind ja zum Glück für 4,30€ im Netz erhältlich) und ein paar Strommessungen habe ich festgestellt, dass diese eine Weiche etwas sonderbar ist und selbst einen Anschlag hat der früher kommt also das Weichengehäuse selbst…
Gleichzeitig hatte ich mir bei Trixbrix mal aus Interesse einen derer Tasten-Controller bestellt um mal zu schauen was der so kann, dabei ist mir aufgefallen, dass diese Controler die Weichenmotoren immer auf Anschlag fahren und dann sofort wieder um ein paar Grad zurück. Damit schalten die Weichen immer zuverlässig und der Servo wird direkt wieder entlastet ohne, dass sich der Weichenflügel bewegt. Ein Strommessung bestätigt das, der Servo zieht anschließend kaum noch Strom.

@Mattze: Wäre das eine Funktion die Rocrail könnte oder die du in die Programmierung der Weichencontroler aufnehmen könntest?. Das würde die Lebensdauer der Servos glaube ich massiv erhöhen.

Danke, Max

[Max T.]

Sehr interessant. Den Kanal kannte ich auch noch nicht.
Swiss Brick Rail, stand hat hier auch im Gegenstück den Permanentmagnet mit dem Kopf einer Senkschraube ersetzt, damit das ganz funktioniert. Das bedeutet natürlich, dass es vorgegebene Paarungen braucht.
(natürlich kann man auch sagen auf der einen Seite des Waagens permanent Magnet auf der anderen Seite nur Stahl, aber das verringert dann wieder die Haltekraft)
Interessant wäre jetzt noch wie viele Waagen, man bei diesem Magnetfeld an die Lok hängen kann bevor der Elektromagnet aufgibt. Ich befürchte, dass hier schnell Schluss ist.

[Max T.]

Habe witzigerweise das Gleiche heute mit einem Elektroniker besprochen, der meinte aus dem Bauch heraus, dass das Magnetfeld also die resultirende Haltekraft wahrscheinlich zu gering/schwach ist. Aber ja nur Versuch macht klug.
Die andere Sache ist: Wenn das Gegenstück immer noch ein Magnet ist würde der Waagen evtl. immernoch an der Lok “hängen” bleiben, weil der Elektromagnet ja immer noch aus Metall ist. Man müsste also das Gegenstück evtl. ebenfalls austauschen, ob das dann praktikabel für den Spielbetrieb ist kommt natürlich auf die Vorraussetzungen an.

Ich hatte mir eher überlegt einen LEGO Motor an den Hub anzuschließen, der über eine Mechanik eine Achse aus der Lok fährt die den Waagen wegschubst. Müsste man mal Zeit für einen Prototypen finden. Aber auch diesen Elektromotor müsste man dann ja über die Funktionstasten in Rocrail ansteuern können. Das zu programmieren braucht dann evtl. Matzes Hilfe.

[Max T.]

Thanks to a college at work, I found an easy solution to have a “remote control”. Teamviewer. This lets me control everything with the smartphone or the tablet, which is perfect.

Regarding your suggestions, the layout is integrated in a LEGO city and as you know space is limited, so there is no way to expand further. This is why the second level idea was born… to have the ability to still expand.

Maybe I’ve to sent you the layout via mail so you can have a look at my problem: The amount of sensors that would be necessary to automate the layout with trains going in both directions is just overwhelming. There is nobody I can think of how would like to run all the cables…

[Max T.]

I tried out an ESP32 with the V0.5.1 and another one with the V1.0.0 firmware but surprisingly currently both show delays for the locos to react again. Doesn’t matter if there are 3 or 5 receivers programmed in the controller.json or and also when only one hub is active.
So first, I need to find out where these delays are coming from again.
What is your experience is the number ob devices that are logged into the WiFi relevant for the whole Mattzo configuration to work stable. Currently I do have 7 switch-MTCs and 1 MTC4BT running, plus the laptop and the other WiFi devices you normally have at home smartphones…?

[Max T.]

Small update:
I am running 4 trains (one of them with two receivers), so a total of five receivers with one MTC4BT for quite a while now. So far everything stable. Almost no problems, also the delays are surprisingly gone…
Did the new firmware V1.0.1 that you uploaded to github improve the situation of running two MTC4BT simultaneously? Or is this something for future versions.

Thanks Max

[Max T.]

Hi Mattze,

okay got it.
Looking forward for updates.
Thank you and the whole team for this great a project.
I really love the MTC4BT controller although it felt like an unsolvable challenge for me at first it really works great and is really amazing to play with.

Keep up the great work and the community that is evolving around it.

[Max T.]

Hi Mattze,

thank you for your reply.

1. When you we talk about the number of locos which should be kept small per controller do we talk about defined adresses per controller or about the number of trains running simulaneously? For example is it okay to programm for example 10 adresses in one controller if only 3 are running at once?

2. As written in my first post, I already tried to use two MTC4BT controllers at the same time, but “I realized that that in average once per minute one of the PU-boxes loses connection to its MTC4BT. It does reconnect automatically but this is not very practical. The distance between the MTC4BTs had no effect.”
Any idea on this?

Thanks again very much for helping out.

Max

[Max T.]

Hi,

is anybody able to help me on this problem?
I kept trying it out several times, with no luck. While the 0.4.1 switch controller connects without any problem to wifi and the mqtt server. The 0.4.1 sensor controller and the 0.5.1 layout controller do not connect using the same libaries.

I’d be happy for any assistance. Thanks.

[Max T.]

Guys your are awesome.
The train’s running. I’m totally excited.
The Upload Filesytem Image was the key.
After having the Switches alreads running and now the the first train it is time to set up all trains and then move on to get sensors working.
Thanks for your support.

[Max T.]

After your hint I cleaned up the folder a little, ziped and moved away all the example files, after uploading I had for strange reasons the old problem with the “status led attached to ESP pin 23” again so I closed vs code, opened it freshly uploaded again but I’m back to this:
[0] BLE : Discovered unknown device: Smart Hub (90:84:2b:21:07:89).
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[1] BLE : Scanning for 3 hub(s) aborted.
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[1] BLE : Scanning for 3 hub(s)…
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[0] BLE : Discovered unknown device: Smart Hub (90:84:2b:21:07:89).
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0

Any idea where it tells the ESP32 to look for exactly 3 hubs?
I checked the platformio.ini, the MTC4BT-workspace.code-workspace, the network_config.json and the controller_config.json but I can’t find any declaration to look for 3.

Just to double check is my process right:
After every change in one of the config files I save this file make sure platformio.ini and MTC4BT-workspace.code-workspace are opend in vs code, then I click platformIO and there “Upload and Monitor”. I wait till is says connecting, press the boot botton on my esp32 and wait till its done. Is this correct?

Of course next week is alright. Thanks for your help. Happy weekend.

[Max T.]

Thank you Joos for the quick answer. Yes this was the problem I took the example controller.json which propably has to much info in it to start with

Now I changed the controller_config.json to only on Loco, and managed to get the max-adresse ofer a PU hub. I put this into the controller_config.json, please see below.
But I fear the PU does not connect to the ESP32 afterwards, Monitor says:

[0] BLE : Discovered unknown device: Smart Hub (90:84:2b:21:07:89).
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[1] BLE : Scanning for 3 hub(s) aborted.
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[1] BLE : Scanning for 3 hub(s)…
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0
[0] BLE : Discovered unknown device: Smart Hub (90:84:2b:21:07:89).
[E][WiFiUdp.cpp:170] beginPacket(): could not get host from dns: 0

controller_config.json:

{
“locos”: [
{
“address”: 1,
“name”: “GreenRocket”,
“speedStep”: 10,
“brakeStep”: 20,
“bleHubs”: [
{
“type”: “PU”,
“address”: “90:84:2b:21:07:89”,
“channels”: [
{
“channel”: “A”,
“attachedDevice”: “light”
},
{
“channel”: “B”,
“attachedDevice”: “motor”
}
]
}
],
“fn”: [
{
“name”: “f0”,
“device”: “bleHub”,
“address”: “90:84:2b:21:07:89”,
“channel”: “B”
}

]
}

]
}

• This reply was modified 2 years, 3 months ago by Max T..

[Max T.]

@Mattze:
als Ergänzung ich hatte gerade eine Trixbrix Motor wo ich beim min. value sogar auf 35 runter musste.

[Max T.]

Hi, I used the libraries you sent me via mail at the 12th of November.
I guess if they work for you, they should work for me as well. Could you maybe check if you really used this for compiling. Thanks a lot.

[Max T.]

Hi,
does anybody have an idea on my compilation problem above.
I don’t know if it is a libary problem with (FreeRTOS.h) or if I chose the wrong board setting in arduino to compile my ESP32.

Thnaks.

[Max T.]

Hallo,

bei der Kompilierung des MTC4PU controllers bekomme ich folgende Fehlermeldung:

Arduino: 1.8.16 (Windows 7), Board: “ESP32 Dev Module, Disabled, Default 4MB with spiffs (1.2MB APP/1.5MB SPIFFS), 240MHz (WiFi/BT), QIO, 80MHz, 4MB (32Mb), 115200, None”

In file included from C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.cpp:8:0:

C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.h:72:31: error: ‘RingbufferType_t’ has not been declared

Ringbuffer(size_t length, RingbufferType_t type = RINGBUF_TYPE_NOSPLIT);

^

C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.cpp:268:39: error: ‘RingbufferType_t’ has not been declared

Ringbuffer::Ringbuffer(size_t length, RingbufferType_t type) {

^

C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.cpp: In constructor ‘Ringbuffer::Ringbuffer(size_t, int)’:

C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.cpp:272:48: error: invalid conversion from ‘int’ to ‘ringbuf_type_t’ [-fpermissive]

m_handle = ::xRingbufferCreate(length, type);

^

In file included from C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.h:14:0,

from C:\Users\U400\Documents\Arduino\libraries\NimBLE-Arduino\src\FreeRTOS.cpp:8:

C:\Users\U400\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6/tools/sdk/include/esp_ringbuf/freertos/ringbuf.h:69:17: note: initializing argument 2 of ‘void* xRingbufferCreate(size_t, ringbuf_type_t)’

RingbufHandle_t xRingbufferCreate(size_t xBufferSize, ringbuf_type_t xBufferType);

^

Mehrere Bibliotheken wurden für “ArduinoOTA.h” gefunden

Benutzt: C:\Users\U400\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\ArduinoOTA

Nicht benutzt: C:\Users\U400\Documents\Arduino\libraries\ArduinoOTA

Mehrere Bibliotheken wurden für “WiFi.h” gefunden

Benutzt: C:\Users\U400\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\libraries\WiFi

Nicht benutzt: C:\Program Files\Arduino\libraries\WiFi

exit status 1

Fehler beim Kompilieren für das Board ESP32 Dev Module.

Dieser Bericht wäre detaillierter, wenn die Option
“Ausführliche Ausgabe während der Kompilierung”
in Datei -> Voreinstellungen aktiviert wäre.

Ist das ein libary Problem (FreeRTOS.h) oder eher das falsche Board zum Kompilieren gewählt?
Als Board habe ich “ESP32 Dev Module” gewählt. Habe auch diverse andere getestet aber mit ähnlichem Ergebnis.

@ Mattze:
Als libaries habe den gesamten Ordner verwendet den du mir geschickt hast.

[Max T.]

45 ist perfekt. Funktioniert jetzt super. Weiche schaltet auch perfekt.

[Max T.]

Macht Sinn jetzt wie du das so schreibst 🙂

Männer ich bin gerade total aus dem Häuschen die Weiche schaltet, nach Monaten der erste Erfolg, es tut sich was.
Ich habe die Weiche in Rocrail jetzt so gut es ging eingestellt:
Parameter 50 und Wert 82.
Mit 82 läuft der Servo (Trixbrix für Lego Weiche) exakt an den Anschlag.
Mit 50 fährt er auf der anderen Seite allerdings nur bis 2mm vor dem Anschlag. Sobald ich einen Wert kleiner 50 eingebe fährt er nur noch ein kleines Stück von der 82er Postion weg. Das Verstehe ich nicht ganz, welche Logik steckt hinter diesen Werten?
Die Weiche schalten mit dem Wert 50 gerade so, dass heißt es dauert ca. 1-2 Sekunden bis die kleine Feder in der Weiche noch mithilft dass die Weiche gerade so überschnappt.

Ansonsten bin ich jetzt erstmal happy und wage mich jetzt nochmal an den Powered up controller auf dem ESP32. Nicht ganz unwahrscheinlich, dass ich dazu bald wieder im entsprechenden Forum melden.

Danke.

[Max T.]

Sorry hat etwas gedauert, Herbstzeit ist Erkältungszeit.

Ich habe den Controller mit Serial gedebugt.
Der Serielle Monitor loggt folgendes:

MattzoController booting…
Loaded mattzoControllerId from EEPROM: 44066
Connecting as MattzoSwitchController44066 to Wifi —SSID—
fpm close 3
mode : sta(c4:5b:be:61:63:94)
add if0
.
MattzoController setup completed.
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
cnt

connected with —SSID—, channel 11
dhcp client start…
ip:192.168.2.113,mask:255.255.255.0,gw:192.168.2.1
Wifi connected. My IP address is 192.168.2.113.
(Re)connecting to MQTT localhost…
Failed to connect to mqtt, state=-2
(Re)connecting to MQTT localhost…
Failed to connect to mqtt, state=-2
…

Der Teil wiederholt sich ständig:
(Re)connecting to MQTT localhost…
Failed to connect to mqtt, state=-2

Das ist schlecht vermute ich mal. Habt ihr eine Idee?

Problem mit der MattzoController_Network_Configuration.h?
Dort habe ich meine SSID sowie das WLAN Passwort eingetragen sowie:
const char* MQTT_BROKER_IP = “localhost”;
const int MQTT_BROKER_PORT = 1883;

für das OTA password habe ich noch etwas eingetragen aber das spielt akutell keine Rolle vermute ich mal.

Wie gesagt der Rooter zeigt das ein geräte mehr angemeldet ist sobald der Controler Strom hat.

[Max T.]

Wieder genau der richtige Tipp, der mosquitto lief schon als automatisch gestarter Windows Dienst, habe den Windowsdienst gestoppt und mosquitto über mosquitto -v gestartet.
Die gute Nachricht:
Die Signale die auf dem Rocrail server laufen, werden so ähnlich auch auf dem mosquitto angezeigt, da scheint sich also etwas zu tun.
Also habt ihr völlig recht der Fehler liegt wohl eher in der Software auf dem ESP8266 oder in der Verkabelung.
Die Verkabelung habe ich mehrfach geprüft. Müsste stimmen.
Zur roten LED die ich gemäß Schaltplan angeschlossen hab: Beim Starten tut sich da aber gar nichts, ich bekomme sie aber zum blinken wenn ich zum Beispiel die gemeinsame Masseversorgung (vom Board kommend) des Servos und der LED wegnehme. Die Masse der LED wird dann offensichtlich nur noch aus der Masse des Servos versorgt, der wiederum dann eigentlich nur noch an + hängt und irgendwelche Ströme zieht. Ich hoffe das macht halbwegs Sinn was ich da schreibe.

Eine Frage zu meinem nächsten Task:
“die Firmware mit Serial Debug Level “DEBUG” kompilieren”
Ich habe mit der 8266 libary 3.0.2 gearbeitet weil die 2.7.4, wie auf der homepage beschrieben, beim kompilieren immer in Fehler gelaufen ist. Als Board habe ich in ardunino “NodeMCU 1.0 (ESP-12E Module)” gewählt und alle Einstellungen so belassen.
Was muss ich jetzt tun? Bei den Board Einstellungen gibt es noch “Debug port:” der steht auch “Disabled”, muss ich den auf “Serial” stellen? Eins drunter gibt es dann noch “Debug Level:”, da gibt es eine ganze Reihe an Auswahlmöglichkeiten aber kein “DEBUG”
Brauche ich noch andere Libaries dazu? Z.b. “SerialDebug” von Joao Lopes.

Ihr seht bin da gerade etwas lost, lerne hier aber jeden Tag gerade mächtig dazu, dafür und für die Hilfe schon mal danke.

[Max T.]

Also der Tipp von Matthias mit mosquitto debug-mode war glaube ich nicht schlecht, wenn ich das über cmd mache kommt das:

C:\Program Files\mosquitto>mosquitto -v
1637258846: mosquitto version 1.6.9 starting
1637258846: Using default config.
1637258846: Opening ipv6 listen socket on port 1883.
1637258846: Error: Normalerweise darf jede Socketadresse
esse oder Anschluss) nur jeweils einmal verwendet werden.

Wenn ich das “Problem” google kommen viele Foreneinträge von Leuten die ihren eigenen Server programmieren, habt ihr eine Idee was da schief läuft bei meinem mosquitto.

By the Way:
Ich habe für das Mattzo-Projekt hier einen eigenen separaten Laptop in Benutzung, auf dem Rocrail mosquitto und arduino läuft; Windows7, Win-Firewall deaktiviert, kostenloses avira ohne firewall…

[Max T.]

Hallo Max,

mir geht es leider ähnlich ich hatte zuerst riesige Probleme die Firmware auf die Controler zu bekommen (Matthias hat mir dankbarerweise mit allen notwendigen libaries ausgeholfen), beim ESP32 ist mir das auch noch nicht gelungen aber einen Mattzo Switch Controller habe ich mittlerweile bespielt bekommen, er meldet sich laut router auch im Netzwerk an…
Mosquitto 2.0.12 und Rocrail habe ich trotz aller mosquitto.conf datei-Änderungen nicht zum laufen bekommen. Ich habe jetzt mosquitto 1.6.9 installiert und Rocrail zeigt auch keine Fehler mehr.
Im Gleisplan habe ich eine Weiche angelegt und diese entsprechend den Angaben hier eingestellt:
https://mattzobricks.com/de/automation/controllers/mattzoswitchcontroller
Die MattzoID habe ich auch über Arduino ermittelt bekommen.
Die Spannung von Vin auf GND beträgt 4,4V das sollte also passen.
Die Spannung von GND auf D0 bleibt unverändert auf 0,2V egal was ich in Rocrail klicke.
Ich vermute also das das Schaltsignal gar nicht erst am Controler ankommt. Gibt es da eine Möglichkeit den Weg des Signals zu verfolgen um zu ermitteln wo es verloren geht?

Besten Dank T-Max

[Max T.]

Hi Max/Thomas,

thank you for your reply.
But I have to admit I don’t get it.

On the supplied links in the mattzocontroler_libary.h which .h-files have to be downloaded to have it work, which you also mentioned in your post, there is no working “syslog.h” library file for download:
https://github.com/arcao/Syslog#syslog
There is a “syslog.h” in the subfolder called “src” but this causes a lot of errors when I try to compile the mtc4pu.ino

So to be honest I’m not sure if the two needed libraries “syslog.h” and “WiFiUdp.h” are still available under the mentioned link:
https://github.com/arcao/Syslog#syslog
And without having these files I belive there is no way for me to get the controler to work. Thats why I asked if someone could supply those.

I have to admit that for me this is the first contact ever with such controllers, arduino, rocrail, etc. I am just dreaming of atomizing LEGO trains, so for me this is quite a tough challenge and after days of trying out and reading, I did not quite get that far…

As you mentioned I should check my settings, I assume I still need the syslog.h, but is it correct to select the “ESP32 Dev Module” in aduino to bring the mtc4pu.ino onto an ESP32?

Thanks again for your help.

[Max T.]

Okay thank you, sounds great.

I will order parts next week and start the testruns on Powered up.
If I at this Milestone you’ll propably be finished with the MTC4BT :-), otherwise I will for sure write you an e-mail.

Right now I’m watching rocrail tutorial 🙂

[Max T.]

Hi Mattze,

thanks for the reply. Will the MTC4BT be also based on the ESP32 NodeMCU development board?
I’m really looking forward to it… I already created a shopping list for a first test run with all components, to see if I can get it working before I roll out the the big layout.

Thanks

[Author]

Posts