Anzeige:
THEMA: WLAN-Belegtmelder
da ich kürzlich mit Begeisterung die Arduino-Welt für mich entdeckt habe und schließlich auf ESP8266, in Gestalt des nodemcu-Entwicklerboards, https://www.ebay.de/itm/NodeMCU-V3-Arduino-ESP...p2057872.m2749.l2648 für 5,75€ einschließlich Versand gestoßen bin, denke ich über einen WLAN-basierten Rückmelder nach.
Dieses Board hat 7 verwendbare GPIO, so dass ich mit den von mir favorisierten Punktmeldern, nämlich Reedkontakten, ganz einfach potenzialfrei diese GPIO gegen Masse schalten kann und darüber eine Ausgelöst/nicht ausgelöst - Information gewinnen kann. Das Board baut beim Hochfahren eine WLAN-Verbindung mit meinem Netz auf und könnte darüber den Belegtzustand an meine Steuersoftware melden.
Im Board würde ich noch eine Entprellung programmieren. Sicher gibt es eine gewissen Latenzzeit über das WLAN, aber die ist meiner Meinung nach unerheblich. Ich müsste mich noch zwischen UDP und TCP entscheiden, glaube aber auch, dass TCP ausreichend wäre und dafür einfacher zu benutzen.
Ich könnte also sehr preiswert diese kleinen Boards unter der Anlage verteilen, über einen darauf befindlichen Webserver konfigurieren, und hätte außer der 5V-Stromversorgung keine Verkabelung.
Was haltet ihr davon?
Viele Grüße
Frank
technisch kann ich das nicht beurteilen...
Die Idee finde ich aber gut! Es muss viel mehr "ohne Kabel" geben
Auf der anderen Seite: der wesentliche Verkabelungsaufwand besteht bei mir durch die Verkabelung der Gleisfreimelder mit dem Gleis, du müsstest die Reedkontakte ja ebenfalls anbinden. Da kommt es auf das Netzwerkkabel vom Belegtmelder zur Zentrale eigentlich fast nicht mehr an.
Viele Grüße,
Simon
du hast schon recht. Zum einen ist es der Forscherdrang (geht es?), zum anderen hätte ich 9 Segmente mit ein RS-Bus zu verkabeln: mir Übergangsstecker zu überlegen und Stichstrecken zu den einzelnen Rückmeldern zu machen, das ist auch Aufwand. Dann die nicht ganz unerheblichen Kosten für die Rückmeldebausteine, manchmal brauche ich nur sehr wenige pro Segment, dann liegen einige Anschlüsse brach und haben doch Geld gekostet.
Viele Grüße
Frank
TCP vs. UDP: UDP ist für ein sicherheitsrelevantes System völlig ungeeignet, da es keinerlei Transportsicherung gibt. Ob das Paket ankommen wird oder nicht kann man nicht feststellen und erhält auch keinen Fehler wenn es nicht ankommt. UDP ist für Streaming-Lösungen, Broadcasts, etc, bei denen das einzelne Paket unwichtig ist. Hier hingegen wäre auf jeden Fall TCP wichtig, und die Steuersoftware muß auf jeden Fall den Belegtmelder auf rot ziehen sobald die Verbindung abbricht.
Die Kosten der Rückmelder entstehen aber ja nicht aus der drahtgebundenen Schnittstelle heraus, eine zuverlässige drahtgebundene Schnittstelle kostet dich weit weniger als das billigste WLAN-Modul und sticht es in Sachen Zuverlässigkeit immer aus.
@Simon:
eigentlich müßte es viel weniger Funkbasiertes Zeug geben, denn schon jetzt sind die verfügbaren Frequenzen teils völlig überlastet, dank Mobil- und Funktelefonen, WLAN, diversen Funkthermometern, "Smart"-Devices, ... Wer in einem Mehrfamilienhaus wird das sicherlich auch schon öfter gemerkt haben, wenn das WLAN mal wieder plötzlich abbricht oder rumlahmt. Ist halt nichts anderes als ob man hunderte Leute in den gleichen Raum steckt, die sich über verschiedene Themen unterhalten wollen. Selbst wenn per "Redekärtchen" immer nur eine reden darf sind die Gespräche dann sehr langwierig. Aber Redekärtchen gibts keine, es plappern also alle durcheinander und müssen merken das nur noch Kauderwelchs ankommt und dann eine zufällige Zeit ruhig sein in der Hoffnung so einen ruhigen Moment zu erwischen in dem kein anderer plaudert. Je weiter zwei Teilnehmer auseinander sind, oder je näher zwei unterschiedliche "Themengruppen" sich sind, desto schlimmer wirds natürlich. Und wir reden nicht über eine Villa mit zig 100 Räumen... beim WLAN im 2,4GHz-Band haben wir genau 3 parallel nutzbare Räume die sich nicht gegenseitig beeinflussen.
Gruß,
Daniel
Zitat
UDP ist für ein sicherheitsrelevantes System völlig ungeeignet,
UDP wird gerade bei sicherheitsrelevanten Systemen verwendet, da ein verlorenes Paket nicht zur Verzögerung der gesamten Übertragung führt. TCP würde warten, bis es die verlorenen Daten nachgereicht bekommt und wieder zu einem Stream zusammen führen. Das ist in Echtzeitsystemen mit kleinen Latenzzeiten ungeeignet. Daher wird UDP eingesetzt und die Sicherungsebene mit einer Störungserkennung an anderer Stelle realisiert.
Zitat
auf jeden Fall den Belegtmelder auf rot ziehen sobald die Verbindung abbricht.
Das wäre nur dann hilfreich, wenn die Freimeldung dann auch weiterhin ausbleiben würde, wenn das Gerät wieder eine Verbindung bekommt. Denn bei einer Störung "Rotausleuchtung" zu zeigen und bei wiederkehrender Verbindung wieder "frei" zu melden, würde ggf. Auflösebedingungen erzeugen, die dann katastrophale Auswirkungen hätte.
Die Moba mit im "Spielzeugfunk-Frequenzband" zu betrieben, mag ja gehen, aber ich hätte keine Lust den Betrieb einzustellen, nur weil bei den Nachbarn gerade mal wieder ein Babyphon Amok läuft. Mit den eigenen Modulen dann auch ggf. die Streamingdienste des Fernsehers zu blockieren, würde mir auch nicht gefallen. Von daher bin ich ganz eindeutig für eine ordentliche Drahtschnittstelle. Ob die wirklich billiger wird als ein WLAN Modul inklusive CPU möchte ich aber stark bezweifeln.
Gruß
Klaus
ich brauche ja keine SIL4-Lösung. Aber lass mich darauf zurückkommen, wenn ich soweit bin und erste Tests gemacht habe. Trotzdem wäre UDP möglich, man müsste aber dann ein Quittungsprotokoll draufsetzen, dann ist man praktisch schon bei TCP. Derzeit neige ich in Richtung Websockets, da wird eine geringe Latenz versprochen - klar, nicht besser als das unterliegende WLAN, aber es ist ein dediziertes, ich kann den Kanal setzen, ich habe kaum Nachbarn, also ist die Umgebung beherrschbar.
Ich schrieb ja: "Forscherdrang". Außerdem nervt mich die gesamte Modellbahntechnik, die auf dem Stand der 80er Jahre stehen geblieben ist. Ein solcher Rückmelder wird eine Konfiguration über Web ermöglichen, da kann ich dann bequem über das Smartphone zugreifen und muss nicht unter die Anlage, um irgendwelche Knöpfe lang zu drücken. Ich könnte auch nette Dinge einbauen wie - sofern der Testmodus über die Web GUI konfiguriert ist - einen Ton absenden, um gleich eine lokale Rückmeldung zu Testzwecken zu haben, ohne irgendwohin schauen zu müssen.
Klar, ein Kabel ist im Aspekt Zuverlässigkeit besser, aber mir kommt es eben (auch) auf andere Eigenschaften an.
Hallo Arne,
Klasse! Das werde ich mir ansehen, danke für den Hinweis!
Edit: erstes Anschauen: das Sensorprinzip ist anders, aber trotzdem jede Menge Interessantes zum Stöbern.
Viele Grüße
Frank
Zitat
Trotzdem wäre UDP möglich, man müsste aber dann ein Quittungsprotokoll draufsetzen, dann ist man praktisch schon bei TCP.
Genau das ist der Gedankenfehler! TCP blockiert so lange, bis es alle "verlorenen" Pakete bekommen hat. Bei UDP gehts weiter, nur daß man halt selber bemerken muß, das was fehlt. UDP + Quittung blockiert nicht, TCP bleibt beim ERSTEN fehlenden Paket hängen oder wirft sogar die komplette Verbindung ab, wenn der Timeout zuschlägt. UDP + Quittung ist etwas völlig anderes als TCP.
Zitat
ich brauche ja keine SIL4-Lösung.
Darum gehts auch nicht. Nur wenn man anfängt Dinge falsch zu lösen, dann kommt der Frust halt früh. Störung -> Rotausleuchtung, Störung weg -> Freimeldung führt halt zu falscher Zugortung und Fahrstrassenauflösung, zumindest da, wo die Steuersoftware den Zug auf Basis der Belegtinformation verfolgt. Insofern ist diese "einfach Nicht-Lösung" einfach keine
Zitat
Außerdem nervt mich die gesamte Modellbahntechnik, die auf dem Stand der 80er Jahre stehen geblieben ist.
Kann ich nicht nachvollziehen. Es gibt zahlreiche Bussysteme, die alle ihre Vor- und Nachteile haben. Und für Belegtmelder würde in der Tat auch der alte S88 Bus reichen.
Wenn der Belegtmelder nur das Objekt ist, mit dem man seinen Spieltrieb mit WLAN, IoT, Web usw. stillen kann, dann ist das ja 'ne super Idee.
Gruß
Klaus
Zitat - Antwort-Nr.: 3 | Name:
eigentlich müßte es viel weniger Funkbasiertes Zeug geben
technisch hast du da recht. Funktional bleibe ich dabei und habe meine Wünsche: wenn wir den Strom drahtlos in die Züge übertragen könnten, hätten wir nicht nur bei der Modellbahn einen Vorteil, sondern die gesamte Aufwände Oberleitung des Originals könnte entfallen
Zitat - Antwort-Nr.: | Name:
Außerdem nervt mich die gesamte Modellbahntechnik, die auf dem Stand der 80er Jahre stehen geblieben ist.
Kann ich nicht nachvollziehen. Es gibt zahlreiche Bussysteme, die alle ihre Vor- und Nachteile haben.
Genau die zahlreichen Bussysteme mit ihren Vor- und Nachteilen sind das Problem. Keiner ist richtig gut.
Es bräuchte einen herstellerübergreifenden, standardisierten Bus, mit dem ich alle Elemente von Zentral ansprechen und komfortabel konfigurieren kann. DCC Super+
Für Gleisfreimeldung nutze ich S88-N, das funktioniert wunderbar. Aber ist ein Kabel mehr...
Viele Grüße,
Simon
Zitat - Antwort-Nr.: | Name:
herstellerübergreifenden, standardisierten Bus, mit dem ich alle Elemente von Zentral ansprechen und komfortabel konfigurieren kann.
BiDiB. Leistungsfähig. Offen. Jeder Hersteller kann ihn implementieren.
Und BiDiB wird auf LAN/WLAN gebracht. https://forum.opendcc.de/viewtopic.php?f=21&t=4980#p53612
Gruss
Markus
ich habe die Befürchtung, das wird in einem Glaubenskrieg enden. Ich bin dann mal raus, bis ich vorzeigbare (Zwischen-)Ergebnisse habe. Den Forscherdrang lasse ich mir jedenfalls nicht nehmen.
Viele Grüße
Frank
Zitat - Antwort-Nr.: | Name:
Ein solcher Rückmelder wird eine Konfiguration über Web ermöglichen, da kann ich dann bequem über das Smartphone zugreifen und muss nicht unter die Anlage, um irgendwelche Knöpfe lang zu drücken.
Über den Zaun geschaut in den Süden (oder Norden, je nach Position) nach Genarp: http://mollehem.se hat ihre Steuerkomponenten auf LocoNet basiert, das Ganze ist aber auch mit einem Adapter über Smartphone konfigurierbar. Habe das nicht selber aber ein gutes Demo gesehen. Ich denke das ist ein guter Mix zwischen Kabel und Wireless.
Genau, auf keine Fälle! (mein Beitrag soll dir das nicht nehmen, nur dass du es weisst).
Grüße,
Harald.
naja, vorzeigbare Ergebnisse habe ich noch nicht. Aber Zeit im Urlaub, wieder die Gedanken aufzunehmen.
Derzeit beschäftigt mich die lokale Stromversorgung. Ich bräuchte 5V DC und habe an jedem Segment 16V AC anliegen, eine neue Stromversorgung will ich nicht verkabeln. Ich habe keine Step-Down-Regler gefunden, die geeignet wären, gleihzeitig AC auf DC zu bringen.
Kann mir jemand ein preiswertes Bauteil empfehlen, welches einfach zu benutzen ist? Oder muss ich Spannung-Runterregeln und Gleichrichten trennen?
Viele Grüße
Frank
Edit: wäre soetwas geeignet https://m.ebay.de/sch/i.html?_from=R40&_tr...mp;_nkw=332645362868 schöner wäre es, wenn es kleiner wäre...
wäre es nicht interessant über PoE (Power over Ethernet) Lösungen nachzudenken?
Kabellos geht es nicht, die Stromversorgung benötigst du in jedem Fall!
(nur einmal ein anderer Gedanke )
und da wären wir wieder ganz dicht am S88-Bus
LG
Günter
"kabbellos geht es nicht" - in der Tat. Nur liegt bereits ein Bus von 16V in jedem Segment, LAN/PoE wäre noch extra zu verlegen. Ich möchte noch ein wenig beim Gedanken WLAN bleiben und da fehlt eben noch die 5V-Stromversorgung ...
Viele Grüße
Frank
ich hatte mir dieses auch für ein Arduino-Projekt bestellt:
https://www.ebay.de/itm/DC-DC-9V-12V-24V-to-5V-...p2057872.m2749.l2649
aber leider immer noch nicht erhalten
Gruß
Günter
oder diesen hier:
https://www.ebay.de/itm/10Stk-Mini-360-DC-DC-4-...047675.c100005.m1851
Ich würde UDP verwenden. Sicherheitsgerichtete Protokolle über UDP sichern die Daten über eine Checksumme ab und verwenden Zeitstempel.
Die Daten werden dann dauernd gesendet. Das System muss dann so konfiguriert sein, dass es mindestens einen Paketverlust verträgt. Wird kein Datenpaket empfangen schlägt ein Time-Out zu und das System geht in den sicheren Zustand.
Für deine Anwendung würde es genügen wenn du alle 0.1 Sekunden Daten sendest. Empfänger die Zentrale während 0.5 s keine Daten gibt es eine Störung.
Gruss Matthias
Grüße
Harald
zur Stromversorgung: Deine Schaltung benötigt doch vermutlich nicht viel Strom. Dann würde genügen:
Brückengleichrichter, Elko, Festspannungsregler 7805 (ohne Kühlkörper), Elko + 100nF Folie- / Keramikkondensator. Das Ganze dürfte bei 1 bis 2 € liegen. Wenn Du Gleichspannung hättest, würde sogar der Brückengleichrichter entfallen. Der 7805 verträgt ohne Kühlkörper etwa 2 W, das wären etwa 100 mA. Dann genügen für die Elkos 100 µF.
Viele Grüße, Joni
danke für für Links, aber das sind leider alles DC-DC-Wandler, ich bräuchte AC-DC.
@Harald
ich habe nur 16V AC (eben nicht DC) als verfügbare Ausgangsspannung (übliche Zubehörspannung).
@Joni
Zum einen bin ich kein Elektronikbastler (so einer hätte mit deiner Liste etwas anfangen können und losbasteln können; ich bräuchte den Schaltplan). Zum anderen würde ich mit Schaltplan das vielleicht hinkriegen, aber ich hätte gern was Fertiges, um mir den Aufwand zu ersparen.
Viele Grüße
Frank
Google Mal nach
schaltung festspannungsregler 7805
U.a. so kommt zur besserem Verständnis auch
https://de.m.wikipedia.org/wiki/Datei:Prinzip-Netzteil.svg
Grüße
Harald
parallel hatte ich auch noch etwas recherchiert. Wenn es denn scheinbar kein Bauteil gibt (aber mein Link in #12), was mir direkt 16V AC in 5V DC wandelt, könnte ich doch folgendes machen: Brückengleichrichter wie z.B. https://www.amazon.de/SODIAL-R-Stück-KBL4...l;ckengleichrichter, dann Glättung durch Kondensator. Jetzt hätte ich (16V-2V)*1,41 rund 20V DC. Jetzt Stepdown-Regler auf 5V. Drei Bauteile.
Wäre das so ok?
Viele Grüße
Frank
Grüße
Harald
genau so hatte ich es mir gedacht.
bei diesem StepDown-Modul sind die Elko´s bereits drauf:
https://www.ebay.de/itm/DC-DC-Spannungsregler-L...p2057872.m2749.l2648
nur noch den Brückengleichrichter dran und gut ist.
Gruß
Günter
ein Zwischenstand: nun sind alle Teile aus China angekommen und ich habe die Platine bestückt. Der NodeMCU ist gesteckt, damit er ggf. ausgetauscht werden kann.
Links oben wird die Stromversorgung gesteckt (16V~). Darunter der Gleichrichter, darunter der Step-Down. Ganz rechts 7 Steckverbinder, an denen die Halleffektsensoren angeschlossen werden (+/-/Signal - D1 bis D7). Nach unten ist sein USB-Anschluss, um ihn programmieren zu können.
Nun eine Frage: Wenn ich auf der Rückseite der Platine (Lötaugen) Verbindungen herstellen möchte, hatte ich auf Bildern gesehen, dass einfach das Lot zwischen die Lötaugen gezogen wurde, und so konnten zwei benachbarte verbunden werden. Das funktioniert bei mir nicht: der Lötstopplack verhindert das. Welchen Trick gibt es? Bislang habe ich mich mit Drähten beholfen, was über größere Distanzen ja auch die einzige Möglichkeit ist, aber bei Nachbarlöchern?
Und noch etwas: auf welche Leerlaufspannung sollte ich den Step-Down einstellen, um 5V für den NodeMCU zu bekommen? Möglicherweise ist die Antwort: Ausprobieren - ich bin aber ein vorsichtiger Mensch.
Viele Grüße
Frank
Die von Lio zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
im Zweifel geht es auch bei benachbarten Lötstellen mit dem Draht.
Damit das leichter zu handeln ist, zuerst fertig löten und danach erst den Draht abschneiden...
Gruß
Roger
Zitat - Antwort-Nr.: 19 | Name: Lio
@Harald
ich habe nur 16V AC (eben nicht DC) als verfügbare Ausgangsspannung (übliche Zubehörspannung).
Hallo Frank, So ublig finde ich das nicht. Früher war es ja logisch um AC Spannung zu gebrauchen. Aber heutzutage ist eigentlich DC viel besser. Da immer mehr auf LED umgewandelt wird für Beleuchtung, und beim digital betrieb ist eigentlich jeden decoder oder anderes Zubehör mehr oder weniger auf DC Spannung ausgelegt. (sind eigentlich immer intern DC Spannung nun ist meistens ne Gleichrichter drinnen).
Eigentlich sind Nur Magnetschalter für weichen die gern AC Spannung wollen.
Also wann du nicht festgelegt bist auf AC wegen andere componenten kauf dir doch ne 12Vdc (etwa 6A reicht meistens) Netzteil aus china. Und 12Vdc geht auch über denn 2 Drähtchen die du jetzt für 16Vac nutzt. ;)
Also das alles nur als Side-info
Ich bin gespannt ob du das hin kriegst. Ich finde es auf jedenfalls technisch interessant und verstehe deine Herausforderung, aber persönlich finde ich REED + WLAN Verbindung eigentlich nicht wirklich das beste Ausgangspunkt. Aber wie gesagt las dir nicht ärger von mein Kommentar und ruhig weiter so.
MFG Joost van Dijk
ich habe an jedem der 9 Segmente 16V AC zur Verfügung und auch bei anderen Verbrauchern in Benutzung, daher bleibe ich dabei. Wenn ich neu bauen würde, könnte ich mir das neu überlegen...
Reed habe ich inzwischen zu Gunsten von Halleffektsensoren aufgegeben.
Viele Grüße
Frank
kleiner Fortschritt. Die Platine ist nun fertig und auf diesem Video https://www.youtube.com/watch?v=pCdXxmmhwbA ist die Funktion ersichtlich. Ganz oben kommen zwar über den Dupont-Stecker drei Litzen herein, aber ich hatte gerade keinen anderen: hier sind nur zwei belegt für die Stromversorgung.
Mein Halleffektsensor-Testgleis ist dreipolig (5V/0V/Signal) wie ein Servo angeschlossen auf einem von 7 Pfostensteckern.
Dass die LED flackert, ist kein Zeichen von fehlender Entprellung, sondern testweise optische Rückmeldung.
Die Software meldet auch schon drahtlos die Belegung, jetzt kommt das Gegenstück.
Viele Grüße
Frank
noch ein Update. Inzwischen habe ich eine kleine Serienfertigung. Die abgewandelte Bauform von Nummer 3 hat keine eigene 16V~ zu 5V= - Wandlung und ist als Erweiterung eines "Standard"-Rückmelders gedacht und greift von ihm über Pfostenstecker die 5V-Versorgung ab. Nummer 3 bekommt auch noch rechts neben den Ausgängen D0 bis D8 (nutzbar: D1 bis D7) die Pfostenstecker.
ist nur für eingeloggte User sichtbar: Login
Und hier die Zutaten, ergibt ca. 1€ pro Melddkanal:
ist nur für eingeloggte User sichtbar: Login
Viele Grüße
Frank
Die von Lio zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
mal wieder ein Update.
Damit ich einen einmal programmierten Baustein individuell konfigurieren kann (bisher: Daten in der Firmware geändert und dann neu heruntergeladen), habe ich nun einen Webserver auf dem ESP8266 als nächsten Schritt (siehe Bild). So stelle zumindest ich mir die Konfiguration von Decodern vor statt umständlich unter die Anlage zu kriechen und Taster zu drücken und vorher von der Zentrale/dem Handregler aus Befehle zu schicken usw. usf. Wenn ich noch Lust habe, implementiere ich ein OTA-Update, dann brauche ich für Firmwareänderungen kein (langes) USB-Kabel mehr.
Hier im Chrome auf PC, das Layout ist responsive und passt auch in den Handybrowser.
Viele Grüße
Frank
Die von Lio zu diesem Beitrag angefügten Bilder können nur von registrierten Usern gesehen werden - Login
sollte es jemand interessant finden, gibt es hier https://www.stummiforum.de/viewtopic.php?f=21&t=169476 eine geschlossenere Darstellung des Bausteins und seiner Möglichkeiten.
Viele Grüße
Frank
klasse, wie weit du gekommen bist!
Denkst du daran, den Freimelder/Rückmelder eines Tages zu vermarkten bzw. jemanden zur Vermarktung zur Verfügung zu stellen?
Viele Grüße,
Simon
vielen Dank!
Ob kommerziell oder frei verfügbar - die Ansprüche an die Realisierung würden natürlich (zu Recht) steigen - bisher ist es reines Privatvergnügen und macht mega Spaß.
In #4 https://www.stummiforum.de/viewtopic.php?f=21&t=169476#p1971672 hatte ich dazu etwas geschrieben. Ich denke, der Haupthinderungsgrund wäre meine proprietäre Umgebung (eigene Steuerung), aber es wäre natürlich ein Gateway denkbar, welches an die gängigen Rückmeldebusse angeschlossen werden könnte.
Viele Grüße
Frank
alles klar, verstehe.
Halte uns auf dem Laufenden! Auch wenn ich mir selbst die Arduino-Welt vorgenommen habe, werde ich in absehbarer Zukunft nicht die Zeit haben, mich selbst derart tief einzuarbeiten
Die viel Erfolg, mich freuen die derartige Lösungen auch nur vom lesen
Viele Grüße,
Simon
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;