opendata-stuttgart / meta

Opendata Stuttgart organisiert und reguliert.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Fernzugriff - Ist so etwas möglich?

iceweasel1 opened this issue · comments

Hallo Zusammen,

gibt es eine Möglichkeit auf einen Sensor via Fernzugriff zuzugreifen?

Szenarien könnten zum Beispiel sein:

• dass man den Sensor neu starten müsste
• dass man in/an der Konfiguration was ändern müsste
• dass man einen Sensor deaktivieren müsste (Störung, defekt)
• dass man einen Sensor, der verbaut und angeschlossen ist, zum Tag X aktiviert
• dass man die Messintervall ändern müsste
• dass man Änderungen an den API-Einstellungen vornehmen müsste
• dass man Updates durchführen möchte

Die generelle Frage des Fernzugriff bezieht sich auf:

• da sich der Sensor nicht im direkten (Heim)-Netzwerk befindet
• da sich der Sensor am Standort X befindet, also komplett außerhalb seines eigenen Reviers

Im aktuellen Fall habe ich jetzt 10 Feinstaubsensoren angeschafft und zusammengebaut. Einer läuft bereits bei mir, die restlichen 9 (irgendwann kommen definitiv weitere dazu) werden in meinem Landkreis verteilt (Schwerpunkt stark befahrene Straßen, bzw. Hotspots). Aus dem Bekanntenkreis konnte ich 9 "Plätze" gewinnen wo diese das Projekt mit Strom und Internet gerne unterstützen. Auskennen tut sich sonst keiner mit dem Thema, Bau, Einstellungen etc., was auch nicht so wichtig ist.

Die Szenarien sind oben fiktiv durchgespielt. Es wird natürlich nicht immer was sein, jedoch wird es mal der Fall sein, das man auf den Sensor darauf zugreifen müsste. Logistisch wäre es ein Aufwand, die jeweiligen Standorte aufsuchen zu müssen, Termine mit den Bekannten ausmachen zu müssen usw.

Da in der Regel nicht jeder einen gleichen Internetzugang bzw. Router (Marke) haben wird, eine einmalige Einrichtung einer VPN/DynDNS-Verbindung daher 50/50 sein wird, ist die Frage, ob dies auch anders möglich sein könnte? Bspw. dass man in der (Firmware) Konfiguration des Sensors z. B. eine DynDNS-Verbindung einpflegen könnte?

Grüße
René

Hallo René,
ich gehe mal die Fälle einzeln durch. Dabei gehe ich davon aus, daß die Sensoren auf meine.luftdaten.info alle auf dich angemeldet sind.
• dass man den Sensor neu starten müsste
Das erfolgt meist durch kurzes Trennen vom Strom, sollte also von den meisten Leuten auch ohne Fernzugriff durchgeführt werden können
• dass man in/an der Konfiguration was ändern müsste
Teamviewer? Bisher haben das alle installiert bekommen, bei denen ich eine Fernwartung machten wollte/musste. Das setzt natürlich ein Teamviewer-taigliches gerät im Netz des Sensors voraus.
• dass man einen Sensor deaktivieren müsste (Störung, defekt)
Stecker ziehen, auf meine.luftdaten.info als inaktiv markieren
• dass man einen Sensor, der verbaut und angeschlossen ist, zum Tag X aktiviert
auf meine.luftdaten.info als inaktiv markieren und wieder aktiv schalten, wenn Tag X da ist
• dass man die Messintervall ändern müsste
Teamviewer? Siehe weiter oben
• dass man Änderungen an den API-Einstellungen vornehmen müsste
Teamviewer? Siehe weiter oben
• dass man Updates durchführen möchte
Es sollte bis auf wenige Fälle das Auto-Update aktiviert bleiben. Sonst Teamviewer.

Die Teamviewer-Lösung benötigt natürlich die von dir angemerkte Abstimmung mit den Bekannten.
Aber selbst bei einem DynDNS-Client auf dem Sensor müsste eine Portweiterleitung auf dem Router eingerichtet werden. Wobei die Chancen eigentlich relativ gut stehen, daß halbwegs aktuelle Router sowohl DynDNS als auch Port-Weiterleitungen können. Die Chancen stehen also etwas besser als 50/50.

Wir schrammen beim Speicherbedarf der Firmware schon ziemlich an der Grenze des Möglichen, daher ist das Einbauen eines DynDNS-Clients nicht wirklich eine Lösung.

commented

Nur als zusätzlicher Input, falls es wirklich am DynDNS-Client scheitern sollte: Der sollte extrem einfach und speicherschonend zu implementieren sein. Häufig wird da ja nur eine URL per HTTP aufgerufen und das ist es. So zumindest beim von mir favorisierten Dienst afraid.org.

Das löst aber nicht das Problem, daß es immer noch ein Portforwarding auf den Routern braucht.

Zum Speicherbedarf: wir haben nur 80kByte RAM, wovon schon gut die Hälfte belegt ist. Beim Flash sieht es ähnlich aus.
Wir haben zwei Möglichkeiten:
Sparsam beim Flash: Die Konfiguration des DynDNS-Clients liegt komplett im RAM. Um flexibel genug zu sein brauchen wir dann eine URL, einen Benutzernamen und ein Passwort. Alles zusammen wahrscheinlich um die 100 Byte zusätzlich im RAM. Zum Vergleich: wir können nur 2048-Bit -Zertifikate nutzen, weil 4096 Bit schon zu groß für den RAM sind. (Das sind nur 265 Byte Unterschied)
Sparen beim RAM: Wir müssten die URLs der gebräuchlisten Dienste alle in der Firmware hinterlegen und dann immer noch Benutzernamen und Passwort abfragen.

DynDNS im Router aktivieten, Port freigeben, Passwort aktivieren. Fertig.