[bertr2d2]

Hallo,

weiß jemand von Euch ob der Begriff GFP oder Gleisformatprozessor in irgendeiner Form geschützt ist ?

Gruß

Gerd

[Dölerich Hirnfiedler]

Hallo Gerd,

Es gibt eine ganze Reihe an eingetragenen Wort und Bildmarken "GFP", u.a. für Bankdienstleistungen oder alkoholische Getränke, jedoch keine Eintragung aus dem Spielzeugbereich. Der Begriff "Gleisformatprozessor" ist weder geschützt noch schützbar da es sich um einen Gattungsbegriff handelt (vgl. § 8 Abs. 2 Nr. 2 MarkenG). So wenig wie "Stuhl" für Sitzmöbel oder "Schraube" für Befestigungselemente eintragbar ist.

Zur eigenen Recherche: https://register.dpma.de/DPMAregister/marke/einsteiger

mfg

D.

[bertr2d2]

Hallo D.,
[quote="Dölerich Hirnfiedler" post_id=1986742 time=1561713998 user_id=409]
Hallo Gerd,

Es gibt eine ganze Reihe an eingetragenen Wort und Bildmarken "GFP", u.a. für Bankdienstleistungen oder alkoholische Getränke, jedoch keine Eintragung aus dem Spielzeugbereich. Der Begriff "Gleisformatprozessor" ist weder geschützt noch schützbar da es sich um einen Gattungsbegriff handelt (vgl. § 8 Abs. 2 Nr. 2 MarkenG). So wenig wie "Stuhl" für Sitzmöbel oder "Schraube" für Befestigungselemente eintragbar ist.

Zur eigenen Recherche: https://register.dpma.de/DPMAregister/marke/einsteiger
[/quote]
vielen Dank ! Das hilft mir weiter.

Gruß

Gerd

[Happy Feet]

Hallo Gerd,

schau mal hier:

https://data.epo.org/publication-server/...A1/document.pdf

Gruss Werner

[vikr]

Hallo Dölerich,[quote="Dölerich Hirnfiedler" post_id=1986742 time=1561713998 user_id=409]
Hallo Gerd,

Der Begriff "Gleisformatprozessor" ist weder geschützt noch schützbar da es sich um einen Gattungsbegriff handelt (vgl. § 8 Abs. 2 Nr. 2 MarkenG). So wenig wie "Stuhl" für Sitzmöbel oder "Schraube" für Befestigungselemente eintragbar ist.

Zur eigenen Recherche: https://register.dpma.de/DPMAregister/marke/einsteiger
[/quote]

klingt zwar plausibel, aber ist der Gebrauch eines solchen Gattungs-Begriffes nicht dennoch irgendwie - zumindest in bestimmten Kontexten - einschränkbar, z.B. als Gebrauchsmuster?

Was ist mit "Windows"?

MfG

vik

[bertr2d2]

Hallo Werner,
[quote="Happy Feet" post_id=1986762 time=1561721431 user_id=29880]
Hallo Gerd,

schau mal hier:

https://data.epo.org/publication-server/...A1/document.pdf
[/quote]
vielen Dank für den Link.

Oh Shit. Ich wollte einen OpenSource GFP entwicklen. Mit dem Patent im Rücken der Märklin droht latent Ungemach. Märklin ist ja ziemlich Schräg drauf, wie ich am eigenen Leib erfahren musste.

Ich kann den Plan wohl begraben. Schade.

Gruß

Gerd

PS: Haben Zimo und Co. ein Patentabkommen bzw. Lizenzabkommen ?

[Dölerich Hirnfiedler]

[quote="Happy Feet" post_id=1986762 time=1561721431 user_id=29880]
Hallo Gerd,

schau mal hier:

https://data.epo.org/publication-server/...A1/document.pdf

Gruss Werner
[/quote]

Hallo Werner,

Eine Patentanmeldung oder eine Patenterteilung hat mit dem Markenrecht an einem Begriff nichts zu tun.

mfg

D.

[Dölerich Hirnfiedler]

Zitat

---

klingt zwar plausibel, aber ist der Gebrauch eines solchen Gattungs-Begriffes nicht dennoch irgendwie - zumindest in bestimmten Kontexten - einschränkbar, z.B. als Gebrauchsmuster?

Was ist mit "Windows"?

MfG

vik

---

Hallo vik,

Gebrauchsmuster schützen keine Begriffe. Du wirst keine Eintragung einer Einzelmarke "Windows" für Fenster finden. So wenig wie VW mit seiner Marke "GOLF" den Verkauf von Schlägern verbieten kann. Wenn ich absurderweise eine Marke "REIHENSCHLUSSMOTOR" für Schokolade anmelden würde, würde das sicher genehmigt. Aber ich könnte wettbewerbsrechtlich nicht gegen Hersteller von Motoren vorgehen. Sondern nur gegen andere Hersteller von Schokolade, die ebenfalls "REIHENSCHLUSSMOTOR" heißen will.

Auch die Verwendung von Gattungsbegriffen in Kombinationen ist schützbar. Eine Marke "DÖLERICH WINDOWS" für Fensterbau ist genehmigbar.

mfg

D.

[Schwanck]

Moin Gerd,

das oben verlinkte Patent schützt ein Verfahren bzw. eine Anwendung, in dem/der eine Komponente Gleisformatprozessor (GFP) genannt wurde.
Selbst das Gerät, welches Märklin als Digital-Anschlussbox (Art. Nr. 60116) verkauft, ist durch das Patent nicht geschützt, der Begrif GFP erst recht nicht.
Trotzzdem würde ich bei einer ähnlichen Anwendung diesen Begriff vermeiden und mir einen anderen Namen dafür ausdenken.

[Dölerich Hirnfiedler]

Zitat

---

Oh Shit. Ich wollte einen OpenSource GFP entwicklen. Mit dem Patent im Rücken der Märklin droht latent Ungemach. Märklin ist ja ziemlich Schräg drauf, wie ich am eigenen Leib erfahren musste.

Ich kann den Plan wohl begraben. Schade.

Gruß

Gerd

PS: Haben Zimo und Co. ein Patentabkommen bzw. Lizenzabkommen ?

---

Hallo Gerd,

Es macht wenig Sinn sich nach einer Anmeldung zu richten, wenn das Patent erteilt wurde. Die erteilte Fassung findest Du hier: https://register.dpma.de/DPMAregister/pa...P000002116288B1

Lass Dich nicht kirre machen und lies die Ansprüche genau. Da steht exakt , was wirklich geschützt werden soll. Natürlich schützt das Patent nicht universell Gleisformatprozessoren. Diese sind Stand der Technik seit ~40 Jahren und auf die grundsätzliche Funktionalität gibt es auch keine gültigen Patente mehr. Natürlich hindert das Patent an einer 1:1 Kopie des Märklin-Aufbaus. Aber das ist auch nicht nötig.

mfg

D.

[Happy Feet]

[quote="Dölerich Hirnfiedler" post_id=1986776 time=1561724935 user_id=409]
[quote="Happy Feet" post_id=1986762 time=1561721431 user_id=29880]
Hallo Gerd,

schau mal hier:

https://data.epo.org/publication-server/...A1/document.pdf

Gruss Werner
[/quote]

Hallo Werner,

Eine Patentanmeldung oder eine Patenterteilung hat mit dem Markenrecht an einem Begriff nichts zu tun.

mfg

D.
[/quote]

Hallo Dölerich,
ja, Patent und Markennamen sind zwei Paar Stiefel.
Sowie ich aber Gerd verstanden habe geht es ihm hauptsächlich, um die mit dem Markennamen "verbundene Funktionalität".
Damit kommt sehr wohl das erteilte Patent in den Fokus.

Der im Patent formulierte Hauptanspruch, nur der ist entscheidend, ist sehr zwar sehr allgemein und damit umfassend formuliert.
Das war für mich der Grund, Gerd auf das Patent hinzuweisen, da er ja einschlägige Erfahrungen mit dem Patentinhaber gemacht hat und
vermutlich "unter Beobachtung" steht.

Gruss

Werner

[Happy Feet]

Zitat

---

Hallo Werner,
[quote="Happy Feet" post_id=1986762 time=1561721431 user_id=29880]
Hallo Gerd,

schau mal hier:

https://data.epo.org/publication-server/...A1/document.pdf

---

vielen Dank für den Link.


PS: Haben Zimo und Co. ein Patentabkommen bzw. Lizenzabkommen ?
[/quote]

Hallo Gerd,

ich weiss nicht ob ein so ein Lizenzabkommen besteht. Entscheidend ist das Anmeldedatum des Patents. Es könnte sein, dass zu diesem Zeitpunkt
Zimo eine ähnliche Lösung hatte, diese aber nicht angemeldet hatte. Damit wäre Zimo nicht an das Patent gebunden.

Gruss Werner

[TT800]

Meiner Meinung nach sind GUI und GFP keine geschützten Begriffe, wohl aber die im Patent beschriebene Funktionalität der so bezeichneten Module.

Hallo Gerd,
warum willst Du nicht eine neue Funktionalität entwickeln und Märklin positiv damit beeindrucken?
Vielleicht kaufen sie Dir dann die Entwicklung ab und Du hast keinen Ärger sondern Anerkennung.

[bertr2d2]

Hallo Stephan,

Zitat

---

Hallo Gerd,
warum willst Du nicht eine neue Funktionalität entwickeln und Märklin positiv damit beeindrucken?
Vielleicht kaufen sie Dir dann die Entwicklung ab und Du hast keinen Ärger sondern Anerkennung.

---

mir geht es nicht darum Märklin zu beeindrucken. Ich habe auch schon meine Idee angesprochen - keine Antwort.

Ich denke, es ist an der Zeit eine OpenSource Plattform ins Leben zu rufen, die die Funktionalität vieler bekannter Zentralen bzw. deren Protokolle abdeckt (DCC, MM, mfx, Selectrix, S88, CAN, Xpressnet, BiDiB, Loconet etc.pp). Was mir persönlich aufgefallen ist, das es viele Protokolle gibt die eigentlich recht einfach gestrickt sind und das man diese "nur" mal auf einen Nenner sprich Hardware bringen müsste. Ich habe auch schon eine Hardware in der Entwicklung (PoC RPi HAT) die jedes (Standard) Protokoll abdecken könnte und die nach Leistung (Stromstärke) für klein bis mittlere Modellbahnen ausreichen sollte. Die Software (MCU Firmware) ist natürlich noch nicht fertig aber hier gibt es im Forum so viel Know-How um etwas für alle (Bastler) auf die Beine zu stellen. Daher die Frage ob der Name GFP, um dem Kind mal einen Namen zu geben, geschützt ist.

Aus meiner Historie ist mir Märklin am besten bekannt und daher lag es nahe das Protokoll und die funktionale Beschreibungen als Grundgerüst zu verwenden. Aber das Patent hat mich beeindruckt und ich muss meinen Idee bzw. Design überdenken.

Gruß

Gerd

[volkerS]

Hallo Gerd,
nenn es GPV. GleisProtokollVerarbeiter (Prozessor = Verarbeiter lt. Langenscheid)
Volker

[1001-digital]

Hallo,
irgendwie kommt mir da xkcd in den Sinn:
https://xkcd.com/927/

Viele Grüße
Carsten

[bertr2d2]

Hallo Carsten,

Zitat

---

Hallo,
irgendwie kommt mir da xkcd in den Sinn:
https://xkcd.com/927/

---

definitiv wird es kein neuen "Standard" damit geben. Es wird aber alle etablierten Gleis Formate generieren können - so der Plan

Ich glaube, ich nenne es "UTP - Universal Track Processor".

Gruß

Gerd

[1001-digital]

Hallo Gerd,
so ganz ist mir nicht klar, was du genau bezwecken willst. Oben wirfst du schonmal völlig verschiedene Sachen durcheinander. DCC, SX, MM und mfx sind Protokolle für die Kommunikation von der Zentrale zum Lokdecoder übers Gleis. S88, LocoNet, BiDiB,... sind Rückmeldebusse. Beides ist getrennt zu betrachten. Soll das nun eine Zentrale werden, die möglichst alle Busse abdeckt? Oder eine Art Umsetzer zwischen Bussystemen?

Bei den Gleisprotokollen läufst du schonmal in gewisse Probleme. Baust du beispielsweise SX1 ein, bist du auf Gedeih und Verderb an den SX-Datenrahmen gebunden. Sobald auch nur eine SX1-Lok fahren soll, musst du 13x pro Sekunde den kompletten Satz SX-Daten durchleiern und verbrennst damit viel Übertragungszeit, die du sinnvoller bei den aktuelleren Formaten einsetzen kannst. Es wird wahrscheinlich auch schwierig werden, SX überhaupt komplett einzubauen, da nach meinem Kenntnisstand kaum brauchbare und verlässliche Infos dazu zu bekommen sind. Das gilt beispielweise für die Programmiergeschichte bei SX1 und mehr noch für alles, was SX2 betrifft. Inweit MM und mfx betroffen sind, weiß ich leider nicht, aber da beide quasi Märklin-Hausprotokolle sind, ist da vielleicht auch nicht alles an Infos verfügbar.

Bei den Bussystemen gibts sooooo viele Möglichkeiten... S88, XpressNet, LocoNet, BiDiB, Zimo-CAN, ESU-CAN, Märklin-CAN, R-Bus, RS-Bus, SX-Bus etc. pp. Sie alle basieren teils auf vollkommen unterschiedlichen Architekturen und auch da dürfte es schwer werden jeweils alle nötigen Infos zusammenzubekommen. Ich persönlich sehe ehrlich gesagt nicht, wozu eine Zentrale alle Busse unterstützen müsste. Ein ausreichend leistungsfähiger reicht normalerweise aus. Meine DR5000-Kunden nutzen in aller Regel bestenfalls 2 der vorhandenen Busse, meist S88 und LocoNet. Der Rest liegt brach.

Es ist natürlich deine Sache, wenn du so eine eierlegende Wollmilchsau bauen willst, dann wünsch ich dir viel Spaß und viel Erfolg Aber aus meiner Sicht klaffen anderswo dringender zu schließende Lücken, beispielsweise gibt es nicht einen einzigen wirklich vernünftigen Handregler am Markt, der vielleicht sogar noch mehrere Bussysteme bedient oder gar per WLAN kommuniziert. Zentralen dagegen gibts wie Sand am Meer, da ist eigentlich für jeden was Passendes dabei.

Viele Grüße
Carsten

[bertr2d2]

Hallo Carsten,

vielen Dank für Deine Antwort ! Kritik ist immer wilkommen.

Zitat

---

Hallo Gerd,
so ganz ist mir nicht klar, was du genau bezwecken willst. Oben wirfst du schon mal völlig verschiedene Sachen durcheinander. DCC, SX, MM und mfx sind Protokolle für die Kommunikation von der Zentrale zum Lokdecoder übers Gleis. S88, LocoNet, BiDiB,... sind Rückmeldebusse. Beides ist getrennt zu betrachten. Soll das nun eine Zentrale werden, die möglichst alle Busse abdeckt? Oder eine Art Umsetzer zwischen Bussystemen?

---

Der Unterschied zwischen Gleisprotokoll und Bussystem ist mir klar. Mir geht es darum möglichst viele - sofern nicht zu exotisch - Systeme abzudecken.

Zitat

---

Bei den Gleisprotokollen läufst du schon mal in gewisse Probleme. Baust du beispielsweise SX1 ein, bist du auf Gedeih und Verderb an den SX-Datenrahmen gebunden. Sobald auch nur eine SX1-Lok fahren soll, musst du 13x pro Sekunde den kompletten Satz SX-Daten durchleiern und verbrennst damit viel Übertragungszeit, die du sinnvoller bei den aktuelleren Formaten einsetzen kannst. Es wird wahrscheinlich auch schwierig werden, SX überhaupt komplett einzubauen, da nach meinem Kenntnisstand kaum brauchbare und verlässliche Infos dazu zu bekommen sind. Das gilt Beispielweise für die Programmiergeschichte bei SX1 und mehr noch für alles, was SX2 betrifft. Inwieweit MM und mfx betroffen sind, weiß ich leider nicht, aber da beide quasi Märklin-Hausprotokolle sind, ist da vielleicht auch nicht alles an Infos verfügbar.

---

Der Anspruch ist nicht alle Gleisprotokolle gleichzeitig nutzen zu können was technisch wahrscheinlich auch nicht geht. Aber der UTP kann alle Protokolle sprechen (so der Plan). Wer SX will nimmt die entsprechende Firmware bzw. aktiviert diese über einen spezielles Paket.

Zitat

---

Bei den Bussystemen gibt es sooooo viele Möglichkeiten... S88, XpressNet, LocoNet, Zimo-CAN, ESU-CAN, Märklin-CAN, R-Bus, RS-Bus, SX-Bus etc. pp. Sie alle basieren teils auf vollkommen unterschiedlichen Architekturen und auch da dürfte es schwer werden jeweils alle nötigen Infos zusammen zubekommen.

---

Viele der Bussysteme sind hinreichend beschrieben (S88, BiDiB, Xpressnet und CAN basierende z.B.) oder es gibt im Netz tolle Projekte dazu. Ich denke, das man schon eine ganze Menge an Informationen hat.

Zitat

---

Ich persönlich sehe ehrlich gesagt nicht, wozu eine Zentrale alle Busse unterstützen müsste. Ein ausreichend leistungsfähiger reicht normalerweise aus. Meine DR5000-Kunden nutzen in aller Regel bestenfalls 2 der vorhandenen Busse, meist S88 und LocoNet. Der Rest liegt brach.

---

Das stimmt. Aber es geht nicht darum wirklich alle Protokolle gleichzeitig nutzen zu müssen. Was mir am Anfang meiner Reise in die digitalen Welt der Modellsteuerung ein wenig auf den Geist ging war der der oft auftretende Fanatismus mit der bestimmte Protokolle bzw. Systeme angepriesen bzw verteufelt wurden. Warum nicht dem Nutzer entscheiden lassen was er verwenden will ? Wenn er ein bestimmte System schon hat, warum nicht weiter nutzen lassen ? Wenn er will kann er Geldbeutel schonend peu a peu auf ein neues System migrieren. Mit dem Board wäre das dann möglich.

Zitat

---

Es ist natürlich deine Sache, wenn du so eine eierlegende Wollmilchsau bauen willst, dann wünsch ich dir viel Spaß und viel Erfolg

---

Gerade hier im Stummiforum gibt es einige interessante Projekte auf höchstem Niveau (u.a. Daniel Siggs/Rainer Mülllers Gleissignalerezeugung, Michael Bernsteins MRSystem, Hardis ModeLib, Maxi Goldchschmidts Basteleien, Ingolfs+ Co Z21 Nachbau nach Philipp Gahtow, und ....) die aber meiner Meinung nach ein Problem haben: Sie nutzen keine gemeinsame Basis. Wenn für all diese Projekte eine (Hardware-)Basis da wäre, dann könnte sich das Potential noch stärker entfalten. Klinkt nach Bullshitbingo, aber ich denke das es so ist.

Meine Vorstellung ist eine Singleboard Computer (RPi4 z.B.) mit Aufsteckkarte die potentiell alle Gleisformate und Protokolle kann. So eine Karte entwickle ich gerade. Ich habe alles was ich an Erfahrung mit meinen Basteleien gesammelt habe und Pläne im Netz aufgetrieben und dies in einer Karte vereint. Herzstück neben RPi ist eine H-Bridge mit BTN8982 und dsPIC33, der über den RPi in der Schaltung programmiert werden kann. Neue Software kann so schnell und einfach getestet und eingespielt werden.
Ich stehe noch am Anfang, aber es wird.

Ich bekomme das nie und nimmer alleine hin. Wenn die Hardware einigermaßen steht, lade ich potentielle Entwickler ein um mit zu wirken.

Gruß

Gerd

[1001-digital]

Hallo Gerd,
freut mich, dass du dir nicht auf den Schlips getreten fühlst

Den Raspi, speziell den 4er, find ich bisschen heftig für so ein Projekt. Der langweilt sich doch die meiste Zeit. Dafür muss man ihn immer hoch- und runterfahren... Ich denke, ein Arduino oder sowas wär da sinnvoller, oder?

Allerdings: Was versrichst du dir von einer einheitlichen Plattform? Also welchen Vorteil hätte da z.B. ein Anwender von? Wie gesagt gibts ja eigentlich schon für jeden Anwendungfall ne passende Zentrale. Und viele kaufen ja nicht einfach nur ne Zentrale, sondern ne Art Okösystem mit allen Komponenten vom gleichen Hersteller. Das würde dann wieder fehlen.

Viele Grüße
Carsten

[vikr]

Hallo,

Zitat

---

Allerdings: Was versrichst du dir von einer einheitlichen Plattform? Also welchen Vorteil hätte da z.B. ein Anwender von? Wie gesagt gibts ja eigentlich schon für jeden Anwendungfall ne passende Zentrale.

---

Daß man sich das Passende zusammenstellen und ausprobieren kann, ohne sich das komplette Ökosystem eines Herstellers anschaffen zu müssen.

Ich würde z.B. die Railcomnachrichten meiner Decoder hören können ohne auf das Fahren mit mfx grundsätzlich verzichten zu müssen. Das geht derzeit nur mit der ECoS (vielleicht auch mit der Zimo MX10). Wenn ich die habe, kann ich die Railcomnachrichten aber nur an das ECoS-Gleisbild melden, wenn ich die überteuerten ECoS-Detectoren bzw. ECoS-Booster einsetze. Für ein Modellbahnsteuerprogramm benötige ich noch einen Extra-Rechner. Für eine kleine Testanlage würde zwar ein Arduino als Zentrale ausreichen, ein RPi4 könnte die Zentralenfunktion wahrnehmen und auch noch die Aufgabe des Rocrailservers mitübernehmen.
Könnte ein universeller Einstieg Out of the Box werden... zumindest für Leute die jemanden kennen, der ein wenig mit dem Lötkolben umgehen kann.

MfG

vik

[bertr2d2]

Hallo Carsten,

Zitat

---

Hallo Gerd,
freut mich, dass du dir nicht auf den Schlips getreten fühlst

---

Meinungen sind mir wichtig. Insbesondere dem Projekt gegenüber kritische Meinungen

Zitat

---

Den Raspi, speziell den 4er, find ich bisschen heftig für so ein Projekt. Der langweilt sich doch die meiste Zeit.

---

Der RPi4 ist für seine Leistung preiswert. Wenn er sich langweilt, kann er nebenbei auch noch die Steuerungssoftware (z.B. iTrain oder Rocrail) mit erledigen. Der RPi wäre für mich das einfache Mittel um die ganze Sache ins Netzwerk zu bringen. Dann auch gleich mit WiFi und Bluetooth.
Im Vergleich dazu die MX10 von Zimo: Hier hat man einen Controller mit Ethernet Fähigkeiten gewählt. Nur ist dieser anscheinend zu schwach um vernünftig Netzwerk zu machen ...

Zitat

---

Dafür muss man ihn immer hoch- und runterfahren... Ich denke, ein Arduino oder sowas wär da sinnvoller, oder?

---

nicht zwangsläufig. Mit spezieller Software geht das auch ohne (siehe BPi mit OpenWRT). Und: Die Platine muss nicht unbedingt auf einen RPi gesteckt werden. Der dsPIC33 stellt sozusagen den Arduino dar und läuft auch ohne RPi.

Zitat

---

Allerdings: Was versprichst du dir von einer einheitlichen Plattform? Also welchen Vorteil hätte da z.B. ein Anwender von?

---

Von der einheitliche Plattform verspreche ich mir eine größere Verbreitung. Mehr Nutzer versprechen ein besseres System, weil mehr drauf schauen.
Vor einiger Zeit habe ich Rob Versluis ein RPi-CANBUS interface zur Verfügung gestellt. Rob hat in Windeseile die Unterstützung für Rocrail realisiert. Das gute am CAN-Interface im Vergleich zu der x-mal teureren CC-Schnitte (und die kann nur Märklin): Der Treiber wird ständig durch sehr viele Leute kontrolliert und Fehler, sofern sie noch auftreten, werden behoben. Und es ist abzusehen, das das noch viele Jahre passiert.

Zitat

---

Wie gesagt gibts ja eigentlich schon für jeden Anwendungsfall ne passende Zentrale. Und viele kaufen ja nicht einfach nur ne Zentrale, sondern ne Art Ökosystem mit allen Komponenten vom gleichen Hersteller. Das würde dann wieder fehlen.

---

Die "Zentrale" wird nicht der preiswerte Heilbringer für alle sein. Aber wer etwas technisches Verständnis und Lust an der Technik hat, für den könnte es interessant werden.

Gruß

Gerd

[1001-digital]

Hallo,
ok, für Bastler wird das sicher ne interessante Sache. Ich hab damals ja auch mit ner OpenDCC Z1 angefangen. Musst dir halt nur bewusst sein, dass das ne sehr kleine Nische ist und "normale" Anwender eher abschreckt.

Auf die Schnelle hab ich jetzt nicht rauslesen können, wie das bei deinem Link mit dem Raspi ohne Runterfahren funktioniert. Ist das einfach ein Read-only-System? Für ne reine Zentrale wär das ok, wenn Rocrail verwendet werden soll, fällt das aber flach. Dort muss man ja einige Sachen speichern können. Das Argument mit LAN / WLAN ist aber natürlich gut. Ich hab selber Rocrail auf nem Raspi 3 laufen, den 4er schau ich mir erst an, wenn das mit der Ladebuchse gefixt ist.

Viele Grüße
Carsten