wie angekündigt, neuer Faden zum Thema Öffentlicher iSpindel Server auf Basis der bestehenden Lösung.
Bin immer noch stark eingespannt, wollte aber dies hier jetzt schnellstmöglich mal zumindest auf den Weg bringen.
Was viele von uns haben wollen, ist eine von Ubidots unabhängige Option, die Daten der iSpindel speichern und auswerten zu können, ohne dafür selber einen Lokalen Server betreiben zu müssen; somit den verbundenen Aufwand zu umgehen (der für nicht-IT-ler ja durchaus einschüchternd sein kann).
Wer mitmachen kann und will, liest jetzt weiter; alle Anderen können hier aufhören...
Interesse und natürlich jederzeit Anregungen dürft Ihr aber gerne äußern, denn das ist noch nötig, um uns hinreichend zu motivieren...
Im verlinkten Faden findet Ihr die aktuellen Repos von mir und Markus (Kiki).
Letzteres ist momentan meilenweit voraus, wird aber dieser Tage von mir integriert werden.
Momentan ist das alles noch Teil von Sams iSpindel Projekt, zuhause im /tools Verzeichnis ebendort.
Ich denke aber, es ist an der Zeit, dass wir das in die nächste Phase überführen, und für den iSpindel Public Server ein neues Projekt anlegen.
Mit Sams Arbeit hat das nur noch indirekt zu tun und auf die zusätzliche Belastung wird er glaub ich gern verzichten.
Die Domains "ispindel.de" und "ispindle.de" sind für diesen Zweck schon mal reserviert.
Die unter dem obengenannten Link, Lokaler Server, erwähnte Lösung lässt sich problemlos "aufbohren" für Multi User Zugriff.
Das sollte das nächste Ziel sein.
Mit sehr geringem Aufwand lässt sich das Ganze nämlich so erweitern, dass wir am Ende alle was davon haben.
Man braucht dann nicht mehr unbedingt einen eigenen Raspi oder sonstigen Server (auch wenn das natürlich immer nice-to-have sein wird, falls der Server mal ausfällt oder man im Keller braut oder sich sonstwie außerhalb der Reichweite des eigenen WLANs befindet).
Was Ubidots betrifft, mit deren "Hochverfügbarkeit" können wir auch ohne Hochseil Akrobatik locker mithalten.
Ein angemieteter Server fällt üblicherweise 4 mal im Jahr für ein paar Stunden aus, und die sind angekündigt.
Es bleibt natürlich auch weiterhin die Möglichkeit, beide Systeme parallel zu nutzen und so das Beste aus zwei Welten zu erhalten.
Das dürfte man dann wohl tatsächlich als (beinahe) "hochverfügbar" titulieren.
Technisch besteht "meine" Lösung aus einem Python (2.7) Skript, welches pro eingehender Verbindung forkt, also durchaus bereits jetzt multi-threaded auch die Daten mehrerer Spindeln "gleichzeitig" empfangen kann; da geht also nichts verloren.
Die Daten werden gruppiert anhand der Hardware-ID, welche jede einzelne Spindel eindeutig identifiziert.
Als Datenbank kommt MySQL zum Einsatz. Schön Standard.
Apache 2 als Webserver. Ebenfalls "schön Standard".
Das noch sehr rudimentäre http Handling (Visualisierung, setzen von Flags zum Gärende bzw. -beginn) ist in PHP realisiert, mit Highcharts.js (JavaScript) als Library für die Diagramme.
Letzteres ist nur für private Nutzung kostenlos. Da muss man nochmal nachschauen. Ich habe den starken Verdacht, dass Ubidots dieselbe Library verwenden.
Was ich dort bisher realisiert habe, ist mehr oder weniger als Template (Schablone) zu verstehen, da kann man noch viel viel mehr rauskitzeln.
Die Grundgerüste sind also da, und funktionieren.
Man kann sich da dran austoben. Ich habe den Source Code bisher ganz bewußt extrem simpel gehalten.
Dass ich das aber letzten Endes nicht alles alleine stemmen kann, ist klar.
Da ich bereits einen Virtual Server (bei Host Europe) betreibe, also hierdurch erst mal keinerlei extra Kosten entstehen, würde ich sagen, während der Entwicklung fangen wir damit an. Wenn er dann mal abraucht, legen wir zusammen und mieten einen Root Server.
Meiner Meinung nach dauert das aber, erstmal tut der das und kostet gar nix (extra).
Da will ich auch nix für, das spendier ich.
Der Server ist relativ frisch angemietet/migriert und läuft unter CentOS Linux Release 7.3. Nagelneu also.
Admin Accounts für SSH und FTP unter der ispindle.de Domain sind eingerichtet, ebenso die Datenbank.
SSL Zertifikate habe ich nicht. Die müssten wir dann dazukaufen, sobald das Ganze steht. Momentan geht's auch mit selbstsignierten, denke ich.
Kostet ein Schweinegeld, sowas, und bringt erst mal nix.
Zum "Pflichtenheft":
- Das Python Skript und die Datenbank werden erweitert um User ID, Username, Email Adresse und Passwort (JOIN über die Hardware ID der Spindel(n)).
Weiterleitung von Server zu Server wird eingebaut, mit Retry, dasselbe JSON Format benutzend wie bisher schon zwischen iSpindel und Raspi (trivial).
Das mach ich, da brauch ich nur 1-2 Stunden Zeit demnächst. - Sam hat heute das iRelay bzw. iRelais angekündigt. Das unterstützen wir natürlich.
Muss ich mir aber erst in Ruhe anschauen. Die Aussicht, Gärverlauf und Temperaturkurven in die Temperatursteuerung des Gärgefäßes einfließen zu lassen, ist Mega. Genau das will ich letzlich auch haben. Ist aber was dieses Thema betrifft (noch) ein Nebenkriegsschauplatz.
Repeater (auch ganz simpler Art) unterstützen wir bereits durch den Punkt weiter oben.
Weitere Eingangsprotokolle einzubauen ist sicher kein Hexenwerk. - Userverwaltung (php, denke ich mal). Nur die Daten bereits registrierter Spindeln werden angenommen und der entsprechenden UserID zugeordnet.
- Eine Art User Token ähnlich wie bei Ubidots werden wir zur Authentifizierung brauchen, damit nicht Hinz und Kunz da irgendwas abschicken und die Datenbank DoS mäßig vollmüllen können. Da kann man ja problemlos auch das originale Ubidots Token verwenden, falls vorhanden.
- Damit verbunden: Konfigurationsoberfläche. Einzelne Sude können "archiviert" werden, indem das von Markus implementierte "Reset" Flag zum Tragen kommt.
Alarmbedingungen (vor allem wichtig: Temperatur) konfigurieren, Benachrichtigung erst mal per Email. Hierfür kann eventuell eine zweite Email Adresse hinterlegt werden (Push, Notfall). - Diagramme aufbohren (php und JS). Möglichkeit schaffen, archivierte Gärkurven über Weboberfläche zu wählen und anzuzeigen.
- Administration des Servers. Bei Ausfall oder Hackerangriff eingreifen.
Wenn wir das Team beinander haben, diskutieren wir den Rest am besten auf github.
Die bisherigen Freiwilligen (aus dem iSpindel Faden):
- Markus (kiki) - Diagramme
- Alex (Ant2Alex) - Server Administration, Front End
- Bob (Bobeye) - Visualisierung
- Peter (beryll) - Programmierung Python, PHP, JS, MySQL
- Alex (Alien_TM) - Server/Administration
- Hendrik (Waldmumie) - Entwicklung
- inem - Test
- Clemens (clmnsk) - Entwicklung
- Joe (schwarzwaldbbq) - Test
- Stephan (Tozzi) - Python, Datenbank, Administration, GIT
Lasst uns loslegen, weitere Freiwillige gerne willkommen. Wir können ganz sicher noch ein paar Leute brauchen.
Hexenwerk ist das alles nicht.
Und ich muss da drüber auch nicht den Hut aufbehalten.
Erst mal muss es halt jemand ins Leben rufen, dann schauen wir weiter.
Das wird jetzt dann endlich was g'scheit's, hoffentlich...