Verfasste Forenbeiträge
-
Beiträge
-
Thanks!! The Web CMS already notified me about several broken links. I will update that when I have some time.
Thanks for your feedback. I will add the start of the MAC address of your PU hub to the documentation. Do you remember when you bought it?
Note: I Aadded the hints to the documentation on https://mattzobricks.com/automation/train-automation/mtc4bt.
Yes, the LEGO app shows the MAC address indeed.
Good point with the pairing of hub/remote.
Stefan, when you try it, apply the possible solutions one by one, and let us know what the actual problem was, please. This helps to grow our knowledge base.
Just checked, large characters in MAC addresses should be okay.
https://github.com/Mattzobricks/MattzoControllers/issues/112But you can try anyway. Please report if that did the trick, then we’d need to review it.
I agree with Hilbert, my PU hubs all start with 90:84:2b.
It’s weird that the PU hubs don’t show up.
Can you please try to use small letters in the MAC address, so
“address”: “a8:e2:c1:99:52:f0”,
instead of
“address”: “A8:E2:C1:99:52:F0”.
I remember we wanted to fix that, but I am not sure if Hilbert already had done it when we compiled firmware V1.2.2.
You can also try to connect the hubs to the LEGO PU app on your phone, which triggers a firmware update. This also helped me one time.
Diesbezüglich bitte genau die Anleitung auf der Website lesen. Mosquitto ab Version 2 benötigt eine spezielle Konfiguration, damit es klappt.
Important: From mosquitto version 2.0 and above, mosquitto needs a configuration file in order to allow connections from clients that do run on the same machine as mosquitto itself – like the MattzoControllers. The configuration file should be named mosquitto.conf and should be in the mosquitto installation directory. The file needs to contain the following lines:
allow_anonymous true
listener 1883Can you post the content of your data directory? This should contain a controller_config.json and network.json file, and potentially other loco and remote files.
I like the idea, but haven’t used Discord for a while. I will discuss it with the team and see if we follow up upon it.
It guys like you that we are doing this for. I am happy that people actually use all this stuff and enjoy it.
The problem in your configuration is the “sensorIndexBoomsClosed” property of the levelCrossingConfiguration object. It is set to zero. That means that sensor index 0 is triggered when the booms are closed. This is your sensor on D7. This is why the sensor is triggred when the booms are closed.
You can either set sensorIndexBoomsClosed (and for consistency also sensorIndexBoomsOpened) to -1, which would disable sending sensor events upon booms opened or closed; or you define two additional virtual sensors (type VIRTUAL_SENSOR_PIN_TYPE, check out the level crossing example configuration file) and map sensorIndexBoomsClosed and sensorIndexBoomsOpened to those sensor indices. Using those virtual sensors is quite handy, as you can use it to prevent the train going over the level crossing when the booms are not yet closed.
Hi Edwin,
happy to hear that you are working on boom barriers. A nice toy, isn’t it?Could you paste your MLC configuration, please? The controller_config.h would be sufficient.
Thanks!
Your choice, I don’t think we will merge in with the master branch. The reason is that we do not believe that your hall sensors are a good choice. Whatever was wrong with your reed sensor setup, I’d recommend you review that before you dive into this hall sensor adventure.
IMHO, Reed sensors are 100% accurate and work 100% of the time. There is not a lot that you could do wrong with them. This is my and the team’s experience from almost a decade of Mattzobricks.
It’s all in the documentation.
MTC4BT does not require a MattzoController Id, as it holds the connections to its controlled devices via Bluetooth directly.
Hi Venderwel,
a note regarding your sensors. We use reed sensors, no hall sensors. Reed sensors are digital, hall sensors are not. If you really want to use hall sensors, this would require a firmware change, which you’d need to do. The firmware comes with an MIT license, so feel free to give it a try.In general: if you want to use different hardware setup, feel free to try. But please check the documentation pages before, we have outlined in quite some detail what is supported and what is not.
Cheers,
MattzeShouldn’t be a problem, but would require some firmware changes.
Using PF or PU motors would be quite a difference in the end, as they require different setups:
1) PF motors can be controlled directly with a motorshield attached to the MLC. Using the LEGO IR shield would also be an option.
2) PU motors could theoretically also be controlled with motorshields, or you would attach them to a PU hub. The MLC does not work with PU hubs, so these kind of changes would be more significant.My five cents: it would be more economical to drive FX switches with a PF motor using the MLC with an additional motor shield. Maybe a nice little project for winter time.
Hi Kay, thanks for your appreciation.
I assume you want to build a “MTC4PF with battery”, correct? As power switch, you may want to use the 8mm switches listed on the material page, section “trains”.
Wahrscheinlich liegt hier ein Übersetzungsproblem vor. Ich hatte geschrieben: “The railbus can be powered with a simple LEGO Power Functions Motor”. Der Motor für den Bus ist ein Power Functions L-Motor (glaube ich der Erinnerung nach), aber kein Zugmotor.
Das liegt einfach an unserem Code. Siehe Datei “main.cpp” irgendwo in einem MTC4PF Unterverzeichnis. Die Dateinamen sind dort hartkodiert:
#include “../conf/my/controller_config.h”
#include “../conf/my/network_config.h”Ich habe ganz viele Lokomotiven, die alle unterschiedliche Konfigurationsdateien haben. Die liegen alle mit unterschiedlichen Dateinamen bei mir im “my” Verzeichnis. Diejenige, die ich gerade auf einen Controller aufspielen will, kopiere ich jeweils über die controller_config.h Datei und starte den Kompiler. Kann aber jeder machen wie er möchte, da gibt es sicherlich unterschiedliche Wege, die alle zum Ziel führen.
Wir haben die weitere Abstraktion der Konfiguration vom Code projektiert. Ziel ist eine Webkonfiguration, so dass für die Konfiguration und Umkonfiguration die Firmware nicht mehr kompilieren muss. Er Controller muss nicht einmal mehr an den Computer angeschlossen sein, um die Konfiguration zu ändern. Uns fehlt aber derzeit die Zeit, das mal anzupacken.
Noch viel Erfolg bei Deinen weiteren Bemühungen!
1. (falls noch relevant)
In der Datei “network_config.h” bitte die Zeile:const int LOGLEVEL_SERIAL = LOG_INFO;
ändern in:
const int LOGLEVEL_SERIAL = LOG_DEBUG;
Ich denke, wir haben’s aber auch schon… denn:
2.
Die Controller-Konfigurationsdatei muss “controller_config.h” heißen und im “my” Verzeichnis liegen. Wenn das nicht so ist: lösch mal die bisherige und benenne die Datei “MTC4PF_conf_BR24.h” um in “controller_config.h”. Ich denke, dass es dann funktionieren sollte.Wunderbar. Dein Controller empfängt die Button-Klicks auf F1 und F2, aber er findet kein Mapping zu den LEDs auf D1 und D2.
Bitte:
1. Schalte mal in der network_config.h den debug mode für das serial log ein (const int LOGLEVEL_SERIAL = LOG_INFO;). Was gibt das Serial Log jetzt aus?
2. Prüfe bitte einmal, ob die controller_config.h Datei, die wie gesagt aus meiner Sicht eigentlich gut aussieht, wirklich im richtigen Verzeichnis liegt, so dass der Compiler sie beim Kompilieren auch findet und verwendet.