WBcontrol - eine Android-Steuerungssoftware für das Projekt

Benutzeravatar
michaelb
Senior
Beiträge: 121
Registriert: Di 15. Jan 2013, 20:24
Wohnort: Österreich
Kontaktdaten:

Re: WBcontrol - Android-Steuerungssoftware für das Projekt

Beitrag von michaelb » Fr 18. Jan 2013, 21:21

Cornelius hat geschrieben: :idea: Es wird nicht lange dauer bis die Market überschwimmt ist mit Android 2 und höher. Dan wird es doch toll sein das die Besucher eine APP von dir bekommen auf Ihre eigener gerät um die Loks zu steuern. Ich denke an geschwindigkeit, Pfeife und Klingel. Auf deiner Tablet steht dieser APP fertig um herunter zu laden :idea: :D
Hallo Cornelius!

Klar! Genau so werden wir das auch machen. Ob die App aus dem Internet geladen wird, von einem Webserver auf der Anlage (=Raspberry Pi) oder vom Steuerungsgerät des Anlagenbesitzers kommt, ist dann schon Nebensache. Alles ist möglich.

Ein paar weitere Überlegungen von mir:
Es wird auch eine "Anlagen"-Logik im Programm geben. Die Gäste bekommen dann die nötigen Infos über die Anlage (Gleisplan mit Weichen...) beim Programmstart automatisch auf ihr Gerät. Die Infos liefert der Anlagen-Server. Das kann das Steuerungsgerät des Anlagenbesitzers, ein PC oder ein Raspberry Pi sein.

Ich hätte auch gerne eine "Besitzerkennung" in der Lok abgespeichert. Dann könnte man es so einrichten, dass man immer nur die eigenen Loks übernehmen darf. Fremde Loks bekommt man dann vom Besitzer "übergeben".

Zumindest auf meiner Anlage wird es so sein, dass man sich um IP-Adressen nicht kümmern muss. Diese werden automatisch zugewiesen und müssen auch nicht abgespeichert werden :twisted: . Die Identifizierung der Loks soll über frei wählbare Namen erfolgen, die ebenfalls in der Lok abgespeichert sein sollten. Zusammen mit der Besitzerkennung sollte dies eine eindeutige Benennung ermöglichen.

Schöne Grüße,
Michael

Benutzeravatar
michaelb
Senior
Beiträge: 121
Registriert: Di 15. Jan 2013, 20:24
Wohnort: Österreich
Kontaktdaten:

Re: WBcontrol - Android-Steuerungssoftware für das Projekt

Beitrag von michaelb » Fr 18. Jan 2013, 21:48

Cornelius hat geschrieben: es geht Mir um ein gutes Android emulator zu haben um selbst etwas zu experimentieren wie Du gemachst hat. Wan Ich auf Google rundschauen dan gibt es vielen und wen man weiter liest, dan arbeitet es nicht richtig und giebt es viele Problemen. Du hast schon ein guter gefunden der arbeitet, das ist wichtig.
Hallo Cornelius!

Es gibt soweit ich weiß ohnehin nur den einen Android-Emulator von Google. Also auf der Downloadseite auf "Download the SDK ADT Bundle for Windows" klicken, das Archiv herunterladen und auf der Harddisk entpacken.

Den enthaltenen "SDK Manager.exe" starten und alles updaten lassen, was er will.

Danach kann man unter "Tools / Manage AVDs" eigene virtuelle Android-Handies und Tablets erstellen und starten. Der erste Start kann etwas länger dauern. Netzwerk/Internet-Zugriff ist ganz normal möglich - je nachdem, was man hat. Wenn man im "SDK Manager" auch alle alten Android-Versionen auswählt und herunterlädt, kann man diese für die virtuellen Geräte auch frei wählen.

Natürlich wird nicht immer alles funktionieren - aber ist das bei den echten Geräten anders? ;)

Schöne Grüße,
Michael

Benutzeravatar
gatzi
User
Beiträge: 97
Registriert: Di 15. Jan 2013, 21:00
Wohnort: Bremen
Kontaktdaten:

Re: WBcontrol - Android-Steuerungssoftware für das Projekt

Beitrag von gatzi » Sa 19. Jan 2013, 22:00

Ein paar weitere Überlegungen von mir:
Es wird auch eine "Anlagen"-Logik im Programm geben. Die Gäste bekommen dann die nötigen Infos über die Anlage (Gleisplan mit Weichen...) beim Programmstart automatisch auf ihr Gerät. Die Infos liefert der Anlagen-Server. Das kann das Steuerungsgerät des Anlagenbesitzers, ein PC oder ein Raspberry Pi sein.

Hallo Michael,
da müsste man dann eine Tabllenform entwickeln, die ausreichend "Luft" hat, um zukünftige Funktionen aufnehmen zu können, z.B. RFIDs für Blockstellenerkennung oder Auslöser für bestimmte Funktionen (Schranken, Signale, Auslöser für Durchsagen wie "in kürze fährt ein ...") etc. Ich könnte mir eine Tabelle vorstellen mit Überschriften in den entsprechenden Teilen. Sie lässt sich beliebig verlängern und mit zukünftigen Abschnitten ausbauen.


Ich hätte auch gerne eine "Besitzerkennung" in der Lok abgespeichert. Dann könnte man es so einrichten, dass man immer nur die eigenen Loks übernehmen darf. Fremde Loks bekommt man dann vom Besitzer "übergeben".

Mit Besitzer meinst Du wahrscheinlich das jeweilige Bediengerät, dass die "Befehlsgewalt" über die Lok hat, an das sie zur Zeit "gebunden" ist? Wie funktioniert das dann? Den Loks werden doch IPs (fest oder flexibel) zugeordnet, über die sie im Netzwerk erkannt werden. Die "Übergabe" erfolgt doch dann, indem dem Bedienteil mitgeteilt wird, unter welcher Adresse die Lok zu erreichen ist?
Dann könnte es zum einen eine Funktion geben, die bei Betriebsbeginn und dann kontinuierlich im Betrieb die Loks abfragt, welche Bedienungerkennung in ihnen abgespeichert sind, welchen Loknamen sie selbt haben und dieses in eine Tabelle eintragen und mit den jeweiligen IPs verknüpfen. Weiterhin muss das "Masterbedienteil" oder jedes andere (je nach individueller Einstellung des Bedienteils) die Berechtigung haben, diese Tabelle zu ändern. Letzlich müsste es eine Sperre geben, die dafür sorgt, dass die Bediengeräte nur auf die ihnen erlaubten/zugewiesenen Loks zugreifen können.

Die in die Lok eingetragene Besitzerkennung ist sicherlich auch wichtig, um bei Spielende, Servercrash oder Stromausfall die Verknüpfungen per Abfrage rekonstruieren zu können. Andererseits könnte die Lok aus der Liste mit den entsprechenden Daten versorgt werden, wenn, aus welchen Gründen auch immer, diese Daten bei ihr gelöscht sind. Auch könnte sich der Server die Listen von den Bediengeräten ziehen, wenn diese bei ihm nicht mehr vorhanden sind. Damit wären diese Zuordnungen mehrfach gesichert, was sicherlich nicht uninteressant ist, wenn -zig Loks verwaltet werden müssen (Ausstellungsanlage etc.)

Man könnte die "Sperre" in die Bedienteile übertragen, in dem man den Bediengeräten eine Liste vom Server übergibt, die enthält, welches Bediengerät welche Lok "führen" darf. Dabei könnten "Mehrfachnennungen" erlaubt sein, so dass auch Lehrer/Schüler-Verknüpfungen möglich sind. Mehfachnennungen sind überall da wichtig, wo der Bediener in die Funktionen der Lok oder Anlage eingewiesen werden muss, aber einem Zweiten eine "Fahrlehrerfunktion" zukommt.

Die Übergabe würde dann so erfolgen, dass das zur Änderung berechtigte Gerät erst die Bedienerkennung in der Lok neu schreibt. Diese würde in dem Fall die Kennung an den Server weiterleiten oder bei der dann folgenden kontinuierlichen Abfrage der Bedienerkennungen und Loknamen wird diese Änderung in die Liste vom Server übernommen und an (alle) Bediengeräte gesendet.
Mehrfachnennungen müssten dann als erstes vom ursprünglichen Besitzer an den Server als Ausnahme gemeldet werden können. Dann erst sollte die Besitzerkennung in der Lok geändert werden. So bleibt die Lok jederzeit steuerbar. Anders könnte es dazu kommen, dass die Lok an ein Gastbediengerät übergeben wird, das keine Änderungsberechtigung hat und so die Lok nicht mehr freigeben kann.
Oder das Mastergerät/die Zentrale hat ständige Berechtigung. Die Berechtigung, Bedienerkennungen in den Loks ändern zu dürfen, könnte ab- und zuschaltbar in den Bediengeräten verankert werden (z.B. in "Gäste"-/"Kinder"-Geräten abschaltbar).

Treiben wir das aber noch einmal weiter:

Was spricht denn gegen die Hinterlegung von Anlagenname, Besitzerkennung und Lokname in der Lok?
Der Vorteil dieser Methode ist, dass so bei flexiblen vom Anlagen-Server vergebenen IPs eine Lok einfach von einen Anlagenserver auf den nächsten übergeben werden kann: Wird der eindeutige Anlagenname und die dann innerhalb der Anlage eindeutige Besitzerkennung des Bediengeräts eines anderen Anlagenservers in die Lok eingetragen, würde dieser neue Server bei der nächsten "Rundabfrage" die Lok als zu sich gehörig identifizieren und einem Bediengerät zuordnen können. Die Lok wechselt dann auf einfachste Weise sogar die "Zentralenzugehörigkeit". Das kann bei ausreichend schneller Rundabfrage auch in Echtzeit, also im laufenden Betrieb passieren.
Das sollte man 'mal bei DCC versuchen, eine Lok im Vorbeifahren von eine auf die nächste Zentrale zu übergeben ...


Zumindest auf meiner Anlage wird es so sein, dass man sich um IP-Adressen nicht kümmern muss. Diese werden automatisch zugewiesen und müssen auch nicht abgespeichert werden :twisted: . Die Identifizierung der Loks soll über frei wählbare Namen erfolgen, die ebenfalls in der Lok abgespeichert sein sollten. Zusammen mit der Besitzerkennung sollte dies eine eindeutige Benennung ermöglichen.

Wenn die Besitzerkennung ("Smartphone", "PC" oder einfach durchnummeriert) innerhalb des Anlagennetzwerks eindeutig ist, spielt der zweite Teil, die Lokbezeichnung für die Eindeutigkeit keine Rolle.
Wird hingegen ein Anlagenname mit abgespeichert, sollte dieser ebenfalls eindeutig sein (Namen von Bahngesellschaften oder auch z.B. Kombinationen von Namenskürzel und Postleitzahl etc), um eine direkte Übergabe von einer Anlage zur nächsten zu ermöglichen, denn so dürfen sich die Besitzerkennungen unterschiedlichen Anlagen überschneiden.

Endlich kann man seine Loks nach belieben benennen (damit habe ich als Analogbahner natürlich keine Probleme, ich denke da mehr an die DCCler, die bei Fahrtagen ihre Lokkennungen abgleichen müssen, damit keine ID doppelt ist ...).

Viele Grüße
gatzi
Meine Gartenbahn-Website >>>
Mein Gartenbahn- und Modellbau-Blog >>>
Schmalspur 1:22,5 im Garten, Regelspur 1:160 im Haus

Benutzeravatar
Pirat-Kapitan
Senior
Beiträge: 153
Registriert: So 28. Okt 2012, 14:09
Wohnort: Rösrath (bei Köln)
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von Pirat-Kapitan » So 20. Jan 2013, 05:45

Hallo Gatzi,
jedes Funkmodul, also auch unsere WLAN-Empfangsmodule sowie jeder WLAN-Stick etc hat eine individuelle, ihn eindeutig identifizierende MAC-Adresse. Das ist vergleichbar mit dem Fingerabdruck beim Menschen.
Eine weitere Individualisierung ist m.E. nicht erforderlich.
Mit dieser MAC-Adresse läßt sich z.B. die Zuordnung einer festen IP-Adresse vom Router "automatisieren", ebenso Berechtigungen zur Teilnahme am (Funk-)Netzverkehr. (Wenn ich nur bestimmte Geräte zulasse und Dein Handy / Pad ist nicht dabei, kannst Du auf meinem Fahrtag nur zusehen. :roll: Das bringt natürlich immer, wie jede 2Tabelle" einen gewissen Verwaltungsaufwand mit sich, weil diese "Tabelle" immer aktuell gepflegt sein will. Ein Grund mehr, warum ich meist bei Fahrtagen und Demonstrationsveranstaltungen, wo andere mitfahren können sollen, ein offenes Netzwerk ohne Kontrolle dieser MAC-Adressen und ohne Verschlüsselung verwende.)

Schöne Grüße
Johannes
Lenz DCC mit Manhart-Funky, Roco WLM und Rocrail auf RasPi.
Micky Maus Technologie (40MHz R/C) für Echtdampf.

Benutzeravatar
gatzi
User
Beiträge: 97
Registriert: Di 15. Jan 2013, 21:00
Wohnort: Bremen
Kontaktdaten:

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von gatzi » So 20. Jan 2013, 10:56

Hallo Johannes,

im Bitte um Verständnis, wenn folgend meine Gedanken etwas weitschweifend sind, aber ich versuche, 'mal über den Tellerrand hinaus zu sehen, zumal man hier dabei ist, Grundlegendes festzulegen, was auf die nächsten Jahrzehnte Gültigkeit haben soll (die Zeit vergeht schneller als gedacht, man denke nur an die DCC-Historie).

Ja sicher, die MAC-Adresse schwirrte mir auch im Hinterkopf herum. Ich dachte jedoch daran, die Organisation der Berechtigungen von der MAC-Adresse abzukoppeln, um bei der Einbindung der Geräte flexibler zu sein, denn die MAC ist nicht im Microcomputer in der Lok hinterlegt, sondern im Wifi-Baustein, der - so unsere WLAN-Philosophie - jederzeit austauschbar sein soll.
Anders ist die Organisation im Computernetz eigentlich auch nicht, denn die IP und MAC werden für den Zugang und die Anbindung ans Netz benötigt und sind in der Netzwerkkarte hinterlegt, nicht im PC selbst. Dieser erhält eine eigene Kennung. Weiterhin werden die Berechtigungen eines Benutzers noch in Rollen zugeteilt. Die Verwendung von Benutzern macht die Arbeit an mehreren Geräten ja so einfach, weil man z.B. seinen Bildschirm/seine Anwendungen von PC zu PC mitnimmt, ohne den PC neu konfigurieren zu müssen, weil der Server registriert, wenn der Benutzer den Platz/PC wechselt.

Mein Hintergedanke ist, die Verwaltung der Loks (Berechtigungen, Funktionen, Einstellungen etc.) unabhängig vom Nachrichtennetz zu gestalten. WLAN, LAN etc. sind nur einzelne Möglichkeiten von vielen, die Kommunikation mit der Lok aufzubauen und im Grunde der eigentlichen Verwaltung untergeordnet.

Wer die Lok steuert, welche Funktionen sie ausführen darf, sollte unabhängig vom Kommunikationsweg sein, damit auch andere Technologien leichter integriert werden können. Ein (Negativ-)Beispiel sind doch DCC, Selectrix und Co.: Sie verbinden die Kommunikation mit der Stromversorgung. Auch wenn die Bediengeräte inzwischen schnurrlos sind, die letze Strecke geht doch von der Zentrale/dem Booster über Kabel und Schienen zum Dekoder. Die bisherigen Digitalbahnhersteller hätten es einfacher, wenn eben dieser Kommunikantionsweg herausgetrennt und beliebig ausgetauscht werden könnte, je nach Stand der Technik. Die Digitalsteuerung ist da auf dem Niveau von vor 30 Jahren stehen geblieben, auch wenn die Bediengeräte noch so vielseitig und schnurlos sind.

Zieht man nun die MAC heran, macht man den gleichen Fehler wie damals DCC: die Steuerung wird an einen Datenweg festgemacht, nämlich an der MAC im Wifi-Baustein. Vielleicht hat die Welt ja mit der IPv6 und dem Internet das entgültige Kommunikantionsnetz für alle Bereiche des Lebens gefungen. Vor 40 Jahren konnte man sich aber wohl auch keinen anderen Weg vorstellen als über Kabel und Schiene zur Lok ... Wer weis was Stand der Dinge ist, wenn wir 30 Jahre weiter sind?

Wenn aber die Verwaltungssoftware (Steuerungssoftware) unabhängig vom Informationweg funktioniert, bildet sie eine Einheit mit der Lok bei höchstflexiblen Weg dorthin.

Aber zurück zu Beispielen von Heute:
Wie wäre es, wenn jemand zu einem Fahrtag kommt, der nur sein Smartphone, Tablet etc. dabei hat und mitfahren darf? Die Anmeldung ist bei einem offenen Netzwerk zu vernachlässigen. ebenso die insallation der Steuerungssoftware. Anders sieht es aber bei den Berechtigungen und damit mit dem Funktionsumfang und die Anbindung an einzelne Loks aus.
Da wäre es womöglich von Vorteil, dieses auf Benutzerkennungen zu verlagern, damit ihm z.B. die Kennung Gast3 zugewiesen wird und er die entsprechenden Einstellungen automatisch erhält. Von daher wäre es auch interessant, diese Benutzerkennung in den Loks zu speichern, damit auch hier eine eindeutige Zuordnung möglich ist. Das erlaubt, schon beliebig viele Gastzugänge vorzuhalten und diese je nach Schwierigkeitsgrad mit verschienenen Berechtigungen (Rollen) freizuschalten. Sogar Zuordnungen zu (heimischen) Loks wäre möglich.
Sollen Gastloks fahren, sind sie ähnlich einfach zu integrieren: Die Kombination aus Besitzerkennung (z.B. Piratenbahn) und Benutzerkennung (Gast1 ... x) und Loknummer (beliebig, auch mehrfach) würde es ermöglichen, Loks sofort vom gastgebenen Bediengerät aus zu steuern, selbst wenn Loks des Gastgebers und der Gäste gleich Namen haben.

Anderer Fall: Der Wifi-Baustein wird ausgetauscht, dann stellt dieser natürlich automatisch eine Verbindung her. Welche Lok es ist und vor allem welche Funktionen mit ihr verbunden sind, wird aber im Microcomputer der Lok abgespeichert. Der Anlagenserver muss nur prüfen, unter welcher IP diese Kennung zu erreichen ist und aktuallisiert die Tabelle, die dann allen Bediengeräten zur Verfügung gestellt wird. Schon flitzt sie wieder los.
Das funktioniert auch an Stammtischen. Probehalber den Wifi des einen Teilnehmers in die Lok des anderen Anwesenden eingesetzt, schon hat sie wieder Verbindung und funktioniert so wie voher, obwohl sich die MAC und die IP geändert haben, ohne dass extra vom Benutzer etwas geändert werden muss ...

Letztlich kann man so auch die Loks besser updaten. Sollen z.B. bei einem größeren Fuhrpark bestimmte Funktionen geändert werden, kann dies automatisch geschehen, wobei es dann völlig egal wäre, auf welchen Weg die Updates in den MC gelangen, ggf. auch über USB-Kabel, MicroSD oder Prgrammierboard. Diese Updates könnten für alle Loks oder selektiv nur für bestimmte Loks vorgenommen werden.

Letzlich muss ich für den Anwender ohnehin eine einfache Bezeichnung zur Verfügung stellen, damit er sich in der Einrichtung und Wartung des Systems leichter zurechtfindet. Wieso dann nicht auch gleich diese in der Lok hinterlegen, unabhängig von IPs, MACs etc.? Denn dann spielt der Weg, mit dem ich vom Bedienteil die Lok erreiche, keinerlei Rolle mehr.

Diese Frage mag in der jetzigen technischen Umsetzung eine Nuance darstellen, tatsächlich muss man sich jetzt darüber unterhalten, wie universell das System wirklich werden soll: Soll nur der MC universelle Funktionsfähigkeiten haben oder wollen wir auch die Steuerungssoftware so weit wie möglich ohne Grenzen gestalten?

Viele Grüße
gatzi
Meine Gartenbahn-Website >>>
Mein Gartenbahn- und Modellbau-Blog >>>
Schmalspur 1:22,5 im Garten, Regelspur 1:160 im Haus

Benutzeravatar
Pirat-Kapitan
Senior
Beiträge: 153
Registriert: So 28. Okt 2012, 14:09
Wohnort: Rösrath (bei Köln)
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von Pirat-Kapitan » So 20. Jan 2013, 12:00

Hi gatzi,
Du bist mit Deiner Idee sicherlich zukunftsträchtiger als meine MAC-Adresse, allerdings hast Du das gleiche Problem beim Austausch der identifizierungstragenden Komponente wie ich mit der MAC Adresse. Bei mir ist sie an das WLAN- / LAN-Modul gekoppelt, bei Dir z.B. an einen Controller (MC oder PC). Auch dieses Teil kann einen Austausch benötigen.

Aber das alles ist für mich derzeit Zukunftsmusik, ich rüste gerade meine für das WLAN-Projekt vorgesehene Lok wieder auf Digitalbetrieb (DCC) um, weil ich diese Lok zum Schneeräumen brauche. Und, bei allen systembedingten Einschränkungen, DCC funktioniert und ist bereits heute marktgängig !

Schöne Grüße
Johannes
Lenz DCC mit Manhart-Funky, Roco WLM und Rocrail auf RasPi.
Micky Maus Technologie (40MHz R/C) für Echtdampf.

Benutzeravatar
gatzi
User
Beiträge: 97
Registriert: Di 15. Jan 2013, 21:00
Wohnort: Bremen
Kontaktdaten:

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von gatzi » So 20. Jan 2013, 13:28

Pirat-Kapitan hat geschrieben:Hi gatzi,
Du bist mit Deiner Idee sicherlich zukunftsträchtiger als meine MAC-Adresse, allerdings hast Du das gleiche Problem beim Austausch der identifizierungstragenden Komponente wie ich mit der MAC Adresse. Bei mir ist sie an das WLAN- / LAN-Modul gekoppelt, bei Dir z.B. an einen Controller (MC oder PC). Auch dieses Teil kann einen Austausch benötigen.
Ja, Johannes,

vor Austausch ist nichts sicher, das trifft immer und auf alles zu. Das ist im Grunde ein Totschlagargument. ;) Nur habe ich in der Vergangenheit eher defekte Tastaturen, Mäuse, Monitore, Festplatten, Schaltnetzteile und natürlich Netzwerkkarten austauschen müssen als ganze Hauptplatinen.

Die Frage ist nur, wie unkompliziert ich die am MC angehängten Komponenten auswechseln kann und wie wenig Auswirkungen es dann auf das übrige System hat.

Viele Grüße
gatzi

Für den Schneeeinsatz habe ich eine Lok umgerüstet auf RC, auch funktionierend, marktgäng wie nie zuvor und außerdem vom Schienenstrom unabhängig, obwohl schon dreimal so alt wie DCC ... ;)
Meine Gartenbahn-Website >>>
Mein Gartenbahn- und Modellbau-Blog >>>
Schmalspur 1:22,5 im Garten, Regelspur 1:160 im Haus

Benutzeravatar
Pirat-Kapitan
Senior
Beiträge: 153
Registriert: So 28. Okt 2012, 14:09
Wohnort: Rösrath (bei Köln)
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von Pirat-Kapitan » So 20. Jan 2013, 13:44

[quote="gatzi]Für den Schneeeinsatz habe ich eine Lok umgerüstet auf RC, auch funktionierend, marktgäng wie nie zuvor und außerdem vom Schienenstrom unabhängig, obwohl schon dreimal so alt wie DCC ... ;)[/quote]
Hi Gatzi,
das ist auch eine Alternative, zumal der DCC-Decoder auch mit analogem Strom gesteuert werden kann, dazu habe ich einen 2 poligen Umschalter in der Lok. R/C ist für mich als auch Echtdampfer kein Thema, allerdings fahre ich nur 40 MHz-Steuerungen, das neumodische Zeug mit 2,4 GHz tue ich mir nicht an.

Eine meiner Überlegungen ist, wenn Karl zunächst nur mit einer analogen WLAN-Steuerung rauskommt (m.E. hatte er mal so etwas geschrieben), dann kommt das Ganze in die B-Unit (WLAN-Modul, MC, H-Brücke), die dann meine analoge Spannungsversorung der A-Unit darstellt. Im Prinzip ersetze ich dann die vorhandenen R/C-Fernsteuerung, Empfänger, Fahrregler und Polwendeschalter durch das analoge WLAN-Projekt und kann damit Michaels Steuerung verwenden. Immer in der Hoffnung, dass auch irgendwann einmal ein digitales WLAN-Projekt kommt.

Schöne Grüße
Johannes
Lenz DCC mit Manhart-Funky, Roco WLM und Rocrail auf RasPi.
Micky Maus Technologie (40MHz R/C) für Echtdampf.

Tony Cannaerts
User
Beiträge: 28
Registriert: Di 15. Jan 2013, 21:50
Wohnort: Blaasveld (Belgien)
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von Tony Cannaerts » So 20. Jan 2013, 17:13

Ich würde sehr froh sein wenn da einer art 'Gäste' möglichkeit sein wird. Mein Sohn (7 jahre alt) wird auch mit dem zug fahren aber er darf naturlich nichts falses machen konnen.
Sonst siet das ganses schon toll aus!
Deutsch, eine Sprache einfach zum sprechen aber schwer zum schreiben ...

Benutzeravatar
michaelb
Senior
Beiträge: 121
Registriert: Di 15. Jan 2013, 20:24
Wohnort: Österreich
Kontaktdaten:

Re: WBcontrol - eine Android-Steuerungssoftware für das Proj

Beitrag von michaelb » So 20. Jan 2013, 19:00

Hallo Kollegen!

Das Prinzip meiner Anlagensteuerung geht in die selbe Richtung wie das, was Gatzi hier vorgestellt hat, ist aber noch etwas einfacher gehalten. Folgendermaßen habe ich mir das vorgestellt:

Ich möchte sozusagen über die technische Netzwerkebene eine "Gartenbahner"-Ebene legen. Die logische Struktur dieser Ebene ist dann eben so aufgebaut, wie man es auch im Garten vorfindet. Die oberste Einheit dieser Struktur ist dann eben die Anlage. Die Anlage wird durch ein Stück Software ("Anlagenserver") repräsentiert, das irgendwo im Netz der Anlage läuft. Das kann ein PC, ein Notebook, ein Raspberry Pi oder das Steuerungsgerät des Anlagenbesitzers sein. Man kann aber je nach persönlicher Präferenz auch ganz auf diesen Anlagenserver verzichten. Die grundlegenden Funktionen kann sowieso das Steuerungsgerät des Anlagenbesitzers übernehmen.

Die weiteren Einheiten (Geräte), die es auf so einer Anlage gibt, sind "Controller" (die Steuerungsgeräte), "Loks" (eben alles, was mobil ist) und "Bodenstationen" (alle ortsgebundenen Geräte) - alles, was sich einzeln über das Netzwerk ansprechen lässt.

All diese Geräte melden sich nach dem Einschalten im Netzwerk. Sie rufen, damit es alle hören können zB: "Hallo, ich bin da. Ich bin eine Lok mit dem Namen "Taurus WLB". Mein Besitzer ist "michaelb". Diese Meldung wird solange wiederholt (alle 10s), bis eine Verbindung mit einem Controller hergestellt wurde. Bodenstationen senden die Meldung immer, Loks nur, wenn sie nicht mit einem Controller verbunden sind. Somit wird kein Anlagenserver benötigt.
Lokname+Besitzername sollen zusammen schon ziemlich eindeutig sein. Der Anlagenserver oder das Steuerungsgerät des Anlagenbesitzers überwachen die Namensmeldungen (die verwendete IP-Adresse ist auch noch bekannt) und geben dem Chef einen Hinweis, wenn etwas unkoscher erscheint. Das sollte vorerst reichen.

Die Geräte sollen melden können, welche Funktionen und Einstellungsmöglichkeiten sie anbieten, sodass diese automatisch in der Steuerungsoberfläche angeboten werden können. Die Bodenstationen zB. können verschiedenste Aufgaben übernehmen (Weichen schalten, Beleuchtung, Bahnhofsdurchsagen, Umweltsensoren [Tag/Nacht, Regen], diverse Motorsteuerungen...). An eine netzwerkfähige Bodenstation können ja mehrere "dumme" klein-Steuerungsmodule angeschlossen sein - je nachdem was in der Nähe gebraucht wird. Es besteht keine Notwendigkeit, jedes Mini-Teil selbst netzwerkfähig zu machen.

Sowohl die Anlage als auch die Geräte (nur wichtig für Loks und Controller) haben einen Besitzernamen gespeichert. Somit können fremde Loks aussortiert werden und nur eigene Loks werden im Steuerungsgerät angezeigt. Fremde Loks müssen dann vom jeweiligen Besitzer übergeben werden, wenn sie jemand anderer steuern will (gilt auch für eigene Controller im "Gästemodus"). Der Anlagenbesitzer legt fest, ob das so restriktiv gehandhabt wird, oder ob jeder jede freie Lok übernehmen darf.

Die Loks tauchen somit nach dem Einschalten selbständig in einer Liste im Controller auf und können zur Steuerung ausgewählt werden. Wurde eine Lok übernommen, kann dies ebenfalls gemeldet werden, sodass sie sofort aus den Auswahllisten verschwindet.

Eine Lokverbindung per IP-Adresse (wenn man fixe Adressen verwendet) ist aber immer noch möglich und kann im Steuerungsprogramm auch vordefiniert werden.

Es können mit einem Controller auch mehrere Loks gleichzeitig gesteuert werden. Falls das jemand will, kann ein 2. Steuerungsbereich angezeigt werden, über den gleichzeitig eine 2. Lok gesteuert wird. Gedacht ist aber eher, dass zB. noch Makros und Ereignisse für einen automatischen Verkehr definiert werden können. Wenn zB. eine Lok ein RFID-Tag überfährt und ausliest, kann sie ein Ereignis an den Controller melden "RFID-Tag mit der Nummer XY wurde soeben überfahren". Der Controller meldet das (+ den Namen der Lok, die das Ereignis ausgelöst hat) weiter an alle. Jedes Gerät, das sich durch dieses Ereignis angesprochen fühlt, kann darauf reagieren:
in jedem Gerät können Macros als Reaktion auf dieses Ereignis hinterlegt sein. Und zwar nicht nur für sich selbst, sondern jeweils getrennt für jedes beliebige andere Gerät. Somit bleibt es jedem selbst überlassen, wie er seine Steuerungsstrukturen aufbaut, ob alles im Controller oder im Anlagen-Server oder ganz anders.
Dieses System mit den Macros und Ereignissen bietet ein vernünftiges Maß an Flexibilität. Denn diese Komponenten lassen sich leicht verwalten, von einem Gerät zum anderen kopieren und die Befehle im Macro selbst können jederzeit geändert werden. Wenn jemand ein neues Gerät "erfindet", braucht man nur die unterstützen Befehle ins Macro tippen und schon kann man es in die Anlage integrieren.

Wichtig ist aber, das System trotzdem möglichst einfach und flexibel zu halten, um einen reibungslosen und frustfreien Betrieb sowohl in der ich-will-nur-mal-fahren-Umgebung, als auch bei der Garten-Wunderland-mit Gastbetrieb-Bahn zu ermöglichen. Das wird auf jeden Fall spannend!

Schöne Grüße,
Michael

Antworten
[phpBB Debug] PHP Warning: in file [ROOT]/vendor/twig/twig/lib/Twig/Extension/Core.php on line 1275: count(): Parameter must be an array or an object that implements Countable

Zurück zu „Alles rund um die Software“