Steuerung über externe Schnittstelle

[Timba]

Hallo @Neo

mich würde mal interessieren, ob die im Wiki beschriebene "Steuerung über externe Schnittstelle" weiterhin gepflegt wird oder ob es sich dabei um ein Auslaufmodell handelt. Es ist momentan nicht akut wichtig für mich, aber als Projekt würde es mich vielleicht reizen, mir eine Windows-App zur Anlagensteuerung zu basteln. Irgendwann mal. Nur fehlen in der Kommando-Liste ja die ganzen Neuerungen, also z.B. die Behandlung von Fahrstraßen (aktivieren, deaktiveren, abfragen) fehlt komplett. Gegenwärtig würde das also wenig Sinn machen. Deshalb meine Frage. Falls nicht die Absicht besteht, das zu aktualisieren, kann ich den Gedanken begraben und mich mit den Dingen beschäftigen, die es bereits gibt.

Gruß Timba

[Neo]

Hallo Timba,

die Schnittstelle in ihrer jetzigen Form ist ein Auslaufmodell. Allerdings wird sie (irgendwann) durch eine neue Schnittstelle ersetzt, die direkt mit der EV verschmolzen wird, d.h. die EV wird um Netzwerkfunktionen erweitert, mit deren Hilfe externe Programme angesprochen werden können. Es lassen sich dadurch beliebige Kommandos an das Studio senden und es stehen in der Schnittstelle alle Funktionen und Eigenschaften zur Verfügung, die auch über die EV zur Verfügung stehen.

In diesem Zusammenhang wird das einfache Textprotokoll auch durch ein moderneres, standardisiertes Übertragungsprotokoll ersetzt.

Viele Grüße,

Neo

[yaRincewind]

Hi Neo,

wie ist der aktuelle Plan bezüglich der EV / Netzwerk - Umsetzung?

Wenn er noch nicht so weit gediehen ist, dürfte ich auf die Vorzüge von MQTT als Kommunikationsprotokoll hinweisen?

 

Das Protokoll ist ziemlich einfach und läuft sogar auf Arduinos.

Was das bringt?

 

Zum Beispiel wären Handregler und Lokfernsteuerungen relativ einfach implementierbar. Oder ein simples Stellwerk.

 

Sinnvoll vor allem wenn ein Spieler die Lok steuert, ein anderer die Weichen stellt und so weiter...

[Neo]

Hallo,

als Kommunikationsprotokoll ist JSON RPC geplant, weil es nativ von vielen Programmiersprachen unterstützt wird.

Viele Grüße,

Neo

[hoffmi]

Hallo Neo,

für wann ist denn eigentlich die neue Schnittstelle geplant?

[martin51]

Hallo @hoffmi , @Neo 

mit dem @ Zeichen wird das Forun-Mitglied direkt verständigt.

Hier deine Nachricht,

Hallo Neo,

für wann ist denn eigentlich die neue Schnittstelle geplant?

Viele Grüße Martin

[Neo]

Hallo,

einen konkreten Zeitplan gibt es für die neue Steuerschnittstelle noch nicht. Auf welche konkreten Funktionen wartest du? Grundsätzlich kannst du auch um die jetzige Steuerschnittstelle herum programmieren, das Protokoll ist dann später schnell angepasst.

Viele Grüße,

Neo

[hoffmi]

Hallo Neo,

mir ging es um das Ermitteln von Gleislängen im Schattenbahnhof -- das habe ich mittlerweile tatsächlich auf der alten Schnittstelle implementiert. Mir war aber aufgefallen, dass die auf Namen basierenden Zugriffe gerade bei Gleisen (aber nicht nur dort) etwas einschränkend wirken, weil Objekte aus dem Katalog gern mal gleiche Namen bekommen. Und speziell bei Gleisen ist es kaum praktikabel, manuell eindeutige Namen zu vergeben. Mich interessiert die neue Schnittstelle prinzipiell aus technischer Sicht und meine Frage wäre, ob die neue Schnittstelle dann Zugriffe auf Basis von Objekt-IDs anstelle von Namen unterstützt!?

Viele Grüße

[Goetz]

vor 11 Minuten schrieb hoffmi:

bei Gleisen ist es kaum praktikabel, manuell eindeutige Namen zu vergeben

Hallo hoffmi,
mit einem Lua Script kannst du das sehr bequem in einem Rutsch für alle Gleise tun.
Das hilft dir eventuell, solange du auf die Verwendung von Objektnamen angewiesen bist?

Viele Grüße
Götz

[Roter Brummer]

Ergänzend zu Götz:

Es gibt auch das Plugin "Gleissetz-Tools". Im Bruchteil einer Sekunde hast du garantiert keine gleichlautenden Gleise mehr.

HG
Brummi

[hoffmi]

Okay, man kann Gleisnamen eindeutig machen -- das ist aber nicht mein primäres Ziel. Zum Beispiel funktioniert dann ja auch die Stückliste nicht mehr wie geplant. Das mit den Gleisnamen war nur ein Beispiel für vom MBS uneindeutig vergebene Objektnamen. Ich denke, es wäre zielführender, wenn man allgemein an der Schnittstelle IDs anstelle von Namen verwenden könnte, um einzelne Objekte eindeutig zu identifizieren. Deshalb meine Frage nach der neuen Schnittstelle...

[EASY]

Hallo,

vor einer Stunde schrieb hoffmi:

Ich denke, es wäre zielführender, wenn man allgemein an der Schnittstelle IDs anstelle von Namen verwenden könnte, um einzelne Objekte eindeutig zu identifizieren.

... was ich daran icht ganz verstehe: die ID, die ja vom System vergeben wird sobald das Objekt auf der Platte landet, ist zwar für jedes Objekt eindeutig, aber woher weiß ich wo es verortet ist (oder um was es sich überhaupt handelt)?
Wenn ich  z.B. wissen möchte, ob sich ein Fahrzeug auf einem bestimmten Gleis befindet, wie erkenne ich einfach dessen ID (außer ich klicke es an und merke mir diese [wenn sie denn angezeigt würde])? Ist das nicht Sinn und Zweck einer "sinvollen" Namensgebung (oder von Schlagworten)?

Wie gesagt, ich verstehe es noch nicht ganz wie es nur über IDs funktionieren soll... kannt Du mir da etwas auf die Sprünge helfen?

Gruß
EASY

[Dad3353]

@EASY...

An ID, in the context of MBS, is really only designed for System use, as it has no significance for Humans. Think of it as a book's ISBN N°, such as 978-1-784-75649-9 (just a book I have on hand...), much easier to reference using its title 'The Complete Uxbridge English Dictionary'. Library systems work better with ISBN ID's. 
For our rail systems, it becomes complicated when there are so many similar (but not identical, to the System...) items. It helps if one adopts a naming system in that case, giving meaningful names to relevant items. If there are many, so be it. It would appear that the German language is particularly long-winded, so I don't know how my system could apply, but I always name items with a 4-letter name, extending to further groups of 4 letters if need be, and  numbers. If I needed to name trees, for instance (I can't think why I would..!), I'd name them 'Beec_001', 'Beec_002' etc (for beech trees...), or 'Fore_Oak_001', 'Fore_Oak_002' etc for forest oaks. I would never use System ID for anything, unless programming at System level. Even then, I would probably create a sort of 'dictionary' of equivalence ID : Names, so as to know what the items are in Human terms.
Does this help..? 

Eine ID im Kontext von MBS ist wirklich nur für die Systemnutzung konzipiert, da sie für Menschen keine Bedeutung hat. Betrachten Sie es als die ISBN-Nummer eines Buches, wie z. B. 978-1-784-75649-9 (nur ein Buch, das ich zur Hand habe ...), viel einfacher zu referenzieren, wenn Sie den Titel "The Complete Uxbridge English Dictionary" verwenden. Bibliothekssysteme funktionieren besser mit ISBN-IDs.
Für unsere Schienensysteme wird es kompliziert, wenn es so viele ähnliche (aber nicht identische, mit dem System ...) Artikel gibt. Es hilft, wenn man in diesem Fall ein Benennungssystem anwendet und den relevanten Elementen aussagekräftige Namen gibt. Wenn es viele sind, soll es so sein. Es scheint, dass die deutsche Sprache besonders langatmig ist, daher weiß ich nicht, wie mein System angewendet werden könnte, aber ich benenne Artikel immer mit einem 4-Buchstaben-Namen, der sich bei Bedarf auf weitere Gruppen von 4 Buchstaben ausdehnt, und Zahlen . Wenn ich zum Beispiel Bäume benennen müsste (ich weiß nicht, warum ich das tun sollte ...!), würde ich sie "Beec_001", "Beec_002" usw. (für Buchen ...) oder "Fore_Oak_001" nennen. 'Fore_Oak_002' usw. für Waldeichen. Ich würde die System-ID niemals für irgendetwas verwenden, es sei denn, ich programmiere auf Systemebene. Selbst dann würde ich wahrscheinlich eine Art „Wörterbuch“ der Äquivalenz ID: Namen erstellen, um zu wissen, was die Elemente in menschlicher Hinsicht sind.
Hilft das..? 

Douglas 

[EASY]

Hi,

vor 38 Minuten schrieb Dad3353:

Does this help..? 

...not really, since it's my thoughts on it.
I want to understand why it should be better to work with the IDs...

...nicht wirklich, da es meinen Gedanken dazu entspricht.
Ich möchte verstehen, warum es besser sein soll mit den IDs zu arbeiten...

EASY

[hoffmi]

Das Identifizieren von Objekten mit Hilfe von Namen hat gegenüber IDs immer den Nachteil, dass Namen nicht zwingend eindeutig sind, d.h. es birgt die Gefahr, die falschen Objekte anzusprechen. Das Verwenden von IDs schließt dieses Problem prinzipiell aus.

Ein kleines Beispiel (zugegeben, in der Praxis nicht übermäßig sinnvoll, aber es dient ja auch nur zur Veranschaulichung):
Angenommen, man möchte mit einem externen Programm mit Hilfe des Events "Lok erreicht Gleis" (150) das Gleis, das ein bestimmtes Fahrzeug gerade überfährt, irgendwie hervorheben (Selektion, Tauschtextur, wie auch immer). Das wird mit der Namens-basierten API nur verlässlich funktionieren, wenn die Namen aller beteiligten Objekte (Fahrzeuge und Gleise) tatsächlich eindeutig sind, d.h. vom Anwender vorher irgendwie eindeutig gemacht wurden, denn MBS erzwingt ja nicht deren Eindeutigkeit. Würde der Event jedoch nicht die Namen, sondern die IDs der Objekte liefern, dann wäre sichergestellt, dass so etwas unabhängig von der (mit Recht freien) Namensvergabe funktioniert.

Selbstverständlich müsste die API es auch ermöglichen, anhand der ID eines Objekts auf dessen andere Eigenschaften, wie z.B. seinen Namen, zuzugreifen...

[EASY]

Hallo,

vor 26 Minuten schrieb hoffmi:

Selbstverständlich müsste die API es auch ermöglichen, anhand der ID eines Objekts auf dessen andere Eigenschaften, wie z.B. seinen Namen, zuzugreifen...

... so kann ich es schon besser nachvollziehen... allerdings müßte ich mich (um den Überblick zu behalten) doch um eine sinvolle Namensgebung bemühen

Gruß
EASY

[Neo]

Hallo,

bei der neuen Schnittstelle geht es zunächst nicht um solche ID-Thematiken. Die Schnittstelle hat eher zum Ziel, direkt in der EV auf Netzwerkkommandos zu reagieren und Befehle zu versenden. Welche Daten dabei versendet werden entscheidet der User, ähnlich den benutzerdefinierten Ereignissen, bei denen auch die Argumente vom Nutzer vorgegeben werden.

Direkt mit IDs zu arbeiten ist im Kontext des Studios immer etwas schwierig, denn die IDs sind sehr dynamisch. Spätestens beim Neuladen einer Anlage werden allen Objekten neue IDs zugeteilt, es ist daher aktuell nicht garantiert, dass ein Objekt dauerhaft immer die gleiche ID besitzt.

Wenn die Schnittstelle in die EV integriert ist, kannst du aber beliebige eigene Mechanismen nutzen, um Objekte gezielt anzusprechen, z.B. über Schlagwörter oder eigene "ID-Variablen".

Viele Grüße,

Neo

[KoalDerDritte]

Hallo @Neo,

ich habe einige Zeit mit einer Ampelsteuerung verbracht, die ich in VB.NET über die externe Schnittstelle realisiert habe. Das funktioniert sehr gut. 

Jetzt wollte ich eine Parkplatzsteuerung hinzufügen, sehe aber, dass es kein Kommando für die Festlegung des Ziels eines Fahrzeug gibt. Ist das vielleicht nicht dokumentiert? Oder könntest du das im nächsten Update einpflegen?

An der geplanten neuen Schnittstelle bin ich ebenfalls sehr interessiert.

Vielen Dank

KoalDerDritte

[gmd]

Das laesst sich alles ueber namen der elemente und variablen machen und mit generic scripts.  Neo hat ja angedeutet dass die schnittstelle erneuert werden soll und im grunde "alles" ermoeglicht was das studio kann. Allerdings fehlen mir nur ein paar wenige Kommandos, das meiste mache ich ueber namen.

Gruss aus Australien

Gmd