Forum Replies Created
-
Posts
-
Ja, Bilder hochladen geht hier im Forum leider noch nicht. Müssen das ganze Forum eh mal neu aufsetzen.
Der reinen Lehre nach: nein. Such Dir im Internet einen Widerstands-Rechner für LEDs, berechne die notwendigen Widerstände für Deine parallel geschalteten roten und die grüne LED, und bau die korrekten Widerstände ein.
Praktische Antwort: klar, kein Problem. Probier mal mit verschiedenen Widerständen herum, z.B. irgendetwas zwischen 220 und 430 Ohm, und schau Dir die Leuchtkraft der LEDs an. Nimm das, was Dir am besten gefällt. Wenn grün zu dunkel und rot zu hell ist, dann verwende getrennte Widerstände für die Leitungen. Die LEDs und der Controller halten das aus (Aussage wie immer ohne Gewähr).
Ich persönlich mag schön leuchtende Farben bei Signalen und baue separate Widerstände in alle Einzelleitungen ein. Dann ändert sich die Leuchtkraft auch nicht, wenn Du zwischen Aspekte umschaltest, die unterschiedliche Gesamtströme benötigen (z.B. von grün auf grün/gelb). Außerdem vorteilhaft: wenn man die Steuerleitungen alle mit Widerstände versorgt hat, brennt einem nicht gleich der Controller durch, wenn man versehentlich mal einen Kurzschluss erzeugt.
Hallo Stefan,
das kann sehr gut sein. Die Winkel, die ich in der Dokumentation Firmware als Startwinkel angegeben habe, funktionieren meines Erachtens ganz gut für Trixbrix-Weichenstellmotoren für Trixbrix-Weichen. Du hast sicherlich für Deine Bluebrixx-Weichen die Trixbrix-Weichenstellmotoren für LEGO-Weichen gekauft. Meine Theorie wäre, dass diese andere Winkel haben könnten.Ich hatte mal so eine Bluebrixx-Weiche in der Hand und würde dann doch schon eher eine LEGO-Weiche empfehlen. Ich selbst verwende wegen der fantastischen Geometrien ausschließlich Trixbrix-Weichen. Auch da gibt es natürlich Qualitätsschwankungen, aber in der Regel funktioniert das einwandfrei, so dass man damit auch im Automatik-Betrieb, der bekanntlich keine Weichenstellfehler verzeiht, keine Probleme hat.
Hallo zusammen,
Pin D4 hat, wie die meisten anderen Pins am ESP-8266, einen internen Pull-up Widerstand, den wir seit irgendeiner Firmware-Version von ca. Anfang 2021 auch standardmäßig aktivieren.Richtig ist, dass weder D3 noch D4 auf Masse ziehen darf, wenn der Controller bootet. Steht eine Lok auf dem Sensor, gibt es Boot-Probleme. Daher sollte man die Pins nur dann als Sensor verwenden, wenn man keine Alternativen hat. Analog gilt dies auch für D8, wobei dieser einen Pull-down Widerstand hat und beim Booten nicht auf 3.3 gezogen werden darf.
Details, auch zu Pin D8, finden sich in der Dokumentation.
Hast Du die Konfigurations-Datei für Mosquitto 2.x wie in der Dokumentation beschrieben eingerichtet?
Siehe hier: https://mattzobricks.com/de/automation/controllers/general
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.