Ich benötige dringend eine Lösung, um 230V mit einem FF-Router sicher schalten zu können.
Szenario ist „mehrere (private) Lichtmasten“, die als Freifunk-Träger dienen sollen.
Problem: Derzeit liegt da zentral nur Spannung an, wenn die Leuchtstofflampen leuchten sollen des Nachts.
Um Grabungsarbeiten zu vermeiden gilt es zu prüfen, ob man die Masten mit Dauerstrom versorgt und den Gluon-Router dann mittels eines Solid-State-Relais die Gasentladungslampe schalten lässt.
Wie das theoretisch funktioniert: ist mir klar.
Hat soetwas schonmal jemand von Euch wirklich mit mehreren Geräten über längere Zeit gemacht?
(Klar, dass das dann auch zuverlässig funktionieren muss.)
Details zum Anschluss von den Leuchten und dem Router? Das ganze muss wetterfest sein? Wie ist es denn bisher? Sollen die Lampen zeitgeschaltet werden, oder vom Haus aus bedient?
Hallo, soweit mir bekannt ist haben Strassenlaternen Dauerspannung. Ich habe im Bekanntenkreis einen Schausteller, der mir mal gezeigt hat wie die an neuen Plätzen die noch nicht mit Strom versorgt waren an Strom gekommen sind. Dazu wurden die Klappen an den Laternen geöffnet und man hat sich da hinter der Sicherung angeklemmt.
Soweit mir bekannt ist werden Laternen über Rundsteuerung ähnlich wie beim Nachtstrom geschaltet!
Sorry überlesen, private Laternen die evtl. nicht so arbeiten, bitte ggbfls. löschen!
tjanson: Das Problem ist nicht der mechanische Teil.
Schaltung zentral über einen weiteren Node im Netz, am besten einen WR841er, der das bestehende Schaltsignal der anderen Laternen auswertet und dann weiterreicht.
Worum es mir hier geht ist, wie man das GPIO der vorandenen LEDs sinnvollerweise ansteuert.
Gluon-Modul, chronjob, keine Ahnung.
Dein lokales Wissen mag richtig sein, es ist nur leider am Thema des Threads vorbei.
Oder um es nochmal zu wiederholen: Es geht weder um Laternen im Berliner Stadtgebiet, noch um Laternen auf öffentlichem Grund, sondern um eine private Laterneninstallation auf einem Vereinsgelände. Da gibt es einen zentralen Dämmerungsschalter im Vereinsheim.
Und was die Verkabelung anbelangt wird es schon „schlimm genug“, nur einem Teil der Laternen Dauerstrom zu geben (und den den anderen eben nicht. Denn alle 25m ein Freifunk-Router wäre doch etwas überkandidelt.
Wobei sollte das doch mit einer Rundsteuerungslösung machbar sein! Dauerstrom drauf und in jeden Mast ein Rundsteuerrelais rein! Relais wird so oder so benötigt!
Hm, ich verstehe noch nicht, warum das ganze über die GPIOs der Nanostation laufen soll. Ich hätte dem Verein jetzt ne 433MHz Fernbedienung in die Hand gedrückt. Eventuell an den bestehenden Schalter gekoppelt. Tut das nicht?
Mit welcher Funksteckdose schaffe ich denn zuverlässig 250m Reichweite (legal)?
Rundsteuerempfänger habe ich gerade nirgends halbwegs bezahlbar gefunden. Habt ihr da eine Bezugsquelle?
(ich denke immernoch, dass ein SolidStateRelais für 10€ an einer der LEDs günstiger kommt.)
Da ist dann aber der Programmier- u. Maintenance-Aufwand nicht mit eingepreist. Aber gut, unter der Vorgabe
wäre mein Vorschlag: Am Laternen-Node ein CGI-Skript, das GPIO schaltet. (Dazu könnte man z.B. das gluon-status-page Package forken und durch ein simples Bash-Skript ersetzen.)
Am Sensor-Node ein Skript, dass per cron-Job alle x Minuten das Signal prüft und per wget das CGI-Skript des anderen Nodes triggert.
Hat das schonmal jemand gemacht? Nein. Stabil? Theoretisch schon. Cool? Definitiv.
Habe auch keine Antwort auf die Eigentliche Frage. Aber als Gedanke kommt mir „Powernet“ oder „digitalstrom“. Bei letzterem einfach eine „gelbe Klemme“ in die Leuchte und fertig.
Ich habe mal so geschaut, aber auch da komme ich wieder auf Preise jenseits der 50€ für den „Powerline-Schütz“.
(nicht, dass die das nicht wert wären, aber bei gleichzeitiger Diskussion ob besser Nanosation LocoM2 oder CPE210 „weil 10€ billiger“, wäre natürlich schmerzhaft.)
Wenn du dieses Projekt sinnvoll lösen willst, musst du dir ein paar mehr Gedanken dazu machen.
Wie verhälst du dich nach einem Stromausfall?
Default on? Ist Mist, dann ist nach einem kleinen Ausfall unter Umständen ewig unnötig das Licht an.
Default off? Auch Mist, ein kurzer wackler im Netz während einer Veranstaltung und alle sitzen im Dunkeln.
Es muss also ein bistabiles Relais her. Das verhindert auch, dass bei einem Ausfall oder Reset des Router gleich das Licht ausgeht.
Nein, muss ich nicht. Ob auf einem Gartenweg nach einem Stromausfall eine Minute tagsüber das Licht brennt, oder nachts nicht brennt (nach dem Ausfall): Ziemlich egal.
Und es ist auch egal, wenn während des Bootens da was flackert.
Eine Zeitverzögerung mit einem RC-Glied (oder einem ordentlichen Amtel oder PIC, ich will ja nicht den nächsten Religionskrieg aufbeschwören) baue ich da gerne noch ein.
Wenn da eine Herz-Lungenmaschine und eine Notbeleuchtung dranhinge, dann würde ich es gewiss anders bauen.
Bitte macht Euch doch nur Gedanken über die Fragen, die sich stellen.
Wenn man einen ATMega oder PIC nimmt, kann man den letzten Status auch ins EEPROM legen, und dann gibts keinerlei Proleme bei kurzzeitigen Stromausfällen.
Wenn sowieso ein ATmega im Spiel ist, kannst du den auch mit der seriellen Schnittstelle das Routers koppeln, und nach dem erfolgreichen Start die Konsole von der seriellen abziehen, wirst du stattdessen darüber deine Befehle an den ATMega schicken können.
Wenn du die mit ner simplen Checksum sicherst, stören auch die Ausgaben beim Boot nicht.
Einen Treiber zu programmieren, der über einen GPIO mit dem ATMega kommuniziert ist jedenfalls um Einiges aufwändiger.
Ich würde einfach die Differenz zwischen den LEDs von zwei Lanports nehmen.
Die blinken während des Bootens synchron an/aus, aber nicht nacheinander. Und nach dem uboot(?) hat dann ja das Openwrt die Kontrolle.
Und nein, Status nach reboot ist egal, da reicht mir ein Defaultwert.
Plus eiln Fallbackwert für "Server fortgesetzt nicht erreichbar.
Versteh ich nicht.
Eine Zeile in /etc/inittab auskommentieren, und du hast die Serielle zur exclusiven Verwendung und kannst direkt mit so nem µC kommunizieren - was will man mehr?
Dafür musst du nichtmal in C programmieren - das geht auch via shellscript.
Ich würde bei so einem Vorhaben den Focus darauf legen, Gluon so wenig wie möglich anpassen zu müssen, da vermutlich >90% dieser Anpassungen nicht updatefest sind.
Die Idee mit der Seriellen kam mir auch erst im Verlauf dieses Threads, und in Verbindung mit einem ATMega ist das imho der Königsweg.
Zusätzliche Scripte, die du in- und unterhalb von /etc anlegst sind definitiv updatefest.
Du kannst sogar ein eigenes init-script in /etc/inid.d bauen, und das überlebt ein Update.
Der Rest sind paar Scripte…is ja nix zeitkritisches.
Ich bin mir 100% sicher, dass Pakete, die in der site.mk stehen auch updatefest sind.
Für irgendein Hackscript „LED aus/LED an“ würde ich hier nicht Fragen.
Wie ich oben schireb: Ich suche jemanden, der soetwas schonmal länger Zeit gemacht hat.
(mit Gluon/Openwrt)
Offensichtlich nicht.
Ich schlage mal vor, den Thread zu schliessen, wenn zum Thema nichts mehr kommt.
Aber gut, unter der Vorgabe