Ich wünsche mir MQTT (=> Steuerung in Hardware, PZB, LZB)

[yaRincewind]

Hi,

ich würde mir MQTT zur Kommunikation mit dem MBS wünschen.

Warum?

Ich bin ein echter Fan von "Dingen in die Hand nehmen".

1. Per Maus oder Tastatur irgendwo rumklicken um die Geschwindigkeit einzustellen ist doof (imho).

2. Dinge wie PZB Überwachung etc. kann man so im Handheld realisieren

3. Mehrere Eingabegeräte (Mehrspieler-Modus) sind absolut kein Problem

 

Ich habe dafür 2 Anwendungsfälle:

1. Szenario

Rangieren

Ich würde mir gerne einen ESP2866 oder ESP 32 nehmen und den in ein Gehäuse einbauen, welches die wichtigsten Regler enthält. Eine Google Bildersuche nach "Funkfernbediengerät FBG" liefert sofort ein passendes Bild wie sowas in echt aussieht.

=> Ich könnte mein MQTT - FBG nehmen und meine Rangierlock steuern.

Spieler 2 kann die Wagen abkuppeln 

Spieler 3 könnte Weichen stellen

 

2. Szenario 

PZB 

Hätte hier kein FBG, aber ein kleines Lok-Cockpit 

Auch hier die Steuerung mit echten Tastern, Wippen etc, zusätzlich z.B. das allseits beliebte PZB Gerät mit seinen Leuchtmeldern (das kann alles der ESP machen)

Dazu bräuchte ich aus dem MBS heraus lediglich die Info über welchen Magnet ich gerade gerauscht bin und wie schnell ich unterwegs bin.

Der Controller selbst überwacht dann die Zeit (oder im MBS einen entsprechenden Dummy-Kontakt). Wenn meine Geschwindigkeit dann zu hoch ist, muss er entweder warnen oder Zwangsbremsen. 

Hier würde der Controller dann lediglich die neue Zielgeschwindigkeit an das MBS senden.

 

Für LZB relativ analog.

 

=> Meiner Meinung nach könnte man so den Spielspaß nochmal kräftig erweitern.

Und man könnte Situationen einbauen und bespielen, ohne dass das MBS sich jemals mit diesen  Situationen beschäftigen müsste.

Es muss nur Werte senden und Steuerbefehle erhalten.

 

Liebe Grüße

Rince

 

PS:

Mein persönlicher Zeitplan für die Eingabegeräte ist recht groß, irgendwann Mitte 2023 hätte ich meine selbst gebauten gerne in der Hand.

Wenn das Thema FBG oder so mehr Leute interessiert, würde ich auch so Dinge wie STL Dateien, Stückliste, Programmcode etc. kostenlos zur Verfügung stellen.

 

PPS:

Ich würde nie einen eigenen MQTT - Broker ins MBS aufnehmen. Sondern davon ausgehen, dass der Anwender seinen eigenen betreibt.

Librarys für MQTT gibt es für so ziemlich jede Programmiersprache.

Wenn man einmal die Settings vorgenommen hat, ist das ganze exakt so komplex wie wie mit Println eine Zeichenkette zu schreiben

(Weil mehr tun die Implementierungen im wesentlichen nicht. Das ganze Netzwerk-Kommunikations-Fehlerbehandlung- und Zustellgedöns nimmt einem der Broker ab...

 

 

 

 

 

[HaNNoveraNer]

Hi

Da ist ja irgendwas in der Langzeitplanung von @Neo.
Die interne Schnittstelle muß ja erstmal diese Werte rausgeben und auf Änderungen reagieren können.
Was man dann dahinter hängt ist dann nicht mehr so kompliziert, denke ich.

Gruß
Thomas

[Henry]

äh, ja,

vovon ist hier die Rede? Vor lauter Abkürzungen habe ich nichts verstanden... meint

Henry

[yaRincewind]

vor 7 Minuten schrieb Henry:

äh, ja,

vovon ist hier die Rede? Vor lauter Abkürzungen habe ich nichts verstanden... meint

Henry

Wo genau geht es denn los?

Ich liege mit gebrochener Schulter im Bett und habe viel Zeit zu antworten 😉

[Neo]

Hallo Rince,

das Studio verwendet ein unabhängiges Übertragungsprotokoll (aktuell textbasiert, später vermutlich JSON-RPC). Ich verwende bewusst kein komplexeres Kommunikationsprotokoll, da die Schnittstelle so universal wie möglich bleiben soll. Durch das einfache Protokoll kann der Nutzer beliebige andere Protokolle davorschalten, wie z.B. dein MQTT.

Für die Zukunft ist bei der Steuerschnittstelle ein Zusammenlegen mit der Ereignisverwaltung geplant, sodass per EV beliebige Daten per Steuerschnittstelle gesendet werden können (im entsprechenden Studio-Protokoll). Es würden dann alle Informationen zur Verfügung stehen, die auch in der EV zur Verfügung stehen.

Viele Grüße,

Neo

[yaRincewind]

Hi Neo,

das ist ja mein Problem. Textbasiert ist super, kann MQTT auch.

Mit JSON geht es los. Das muss ich erst mal zerlegen.

 

Bei MQTT mach ich mir im MBS einfach am Broker einige Topics auf, die ich will:

state/Lok/0815/Licht

state/Lok/0815/Geschwindigkeit

state/Lok/0815/Streckenblock

state/Lok/0815/Events

state/Lok/0815/vordereKupplung

state/Lok/0815/hintereKupplung

 

state/Lok/4711/Licht

state/Lok/4711/Geschwindigkeit

state/Lok/4711/Streckenblock

state/Lok/4711/Events

 

state/Hauptsignal001

state/Hauptsignal002

 

Dahinter dann einfach im Klartext die Werte reinschreiben, oder true/false, völlig egal

Zusätzlich kann ich sagen:

Werte immer übermitteln / Werte nur übermitteln bei Veränderung => wird 1x konfiguriert, dann kann man es vergessen

Reduziert heftig die Netzwerklast

 

Wer jetzt diese Werte empfängt, kann dem MBS völlig egal sein. Darum kümmert sich der Broker, nicht mehr unser Bier.

Ich nehme meinen Controller Nummer 1, und abonniere:

state/Lok/0815/Geschwindigkeit

state/Lok/0815/Events

 

Damit weiß ich, wie schnell ich unterwegs bin und ob etwas passiert ist.

Der Rest im am Controller 1 unspannend.

Davon bekommt das MBS nichts mit. Muss sich also nicht drum kümmern.

Wenn ich am Controller sage: Geschwindigkeit runter

würde der Controller zum Broker schicken:

set/Lok/0815/Geschwindigkeit/entsprechenderWert

 

senden kann ich dennoch auf jedem Topic, das ich will:

set/Lok/0815/vordereKupplung/aus

 

Wenn das MBS das Topic "set/Lok/0815/Geschwindigkeit" abonniert hat, wird es diesen Wert vom Broker empfangen

 

 

D.h., außer, dass du einen MQTT Client mit einbaust, musst du dich nicht um so viel kümmern:

Jedem Event oder jedem Prop ermöglichen, ein set und ein state Topic zu öffnen. Dann kann der User selber entscheiden was er wohin sortiert haben will. Und den User festlegen lassen, was bei set abhängig vom Inhalt passieren soll.

 

 

Zu viel Info?

 

Liebe Grüße

 

Rince