Anregung: Aktives anliefern statt Polling & Heartbeat

[jwka]

Vorausgeschickt:
Ich beschäftige mich mit Hausautomation/Smart Living sowie "Internet of Things" (IoT) und progge auch selbst Hardware Teile. In der Zukunft wird es immer mehr "Peripherie" geben, die, wie der PoolController, IP "sprechen". Dies hat zur Folge, dass die zentralen Server (z.B. Hausautomationsserver) immer mehr solcher Teile abfragen müssen, und somit der Polling-Aufwand enorm steigt. Dummerweise ändern sich die Daten solcher Geräte i.d.R. wenig, aber zu große Abfrageintervalle sind auch nicht gut, weil so z.B. Start- und Endezeiten von Pumpenläufen nur zu ungenau erfasst werden.

Daher plädiere ich dafür, dass Peripherie-Geräte ihre Stati aktiv anliefern, und zwar als "Heartbeat" zyklisch und zusätzlich bei konkreten "wesentlichen" Änderungen ggf. mit Teildaten (--> "Pumpe ist jetzt ein", "Dosierung abgeschlossen", "x mg Chlor zugeführt"), wobei die Daten natürlich nicht im Klartext sondern als "Code-Pakete" übermittelt werden.

Ich wollte deshalb anregen, in der Software des Controllers ein "aktives ausliefern" von Statuswerten vorzusehen (habe im Manual dazu nichts gefunden). M.E. wären folgende Varianten (oder halt am besten alle) sinnvoll:

- per http-get, denn das ist von den meisten Systemen SEHR leicht auszuwerten und würde es z.B. auch ermöglichen, eine einfache PHP-Webseite (bis hin zu Wordpress & Co) zu basteln, auf der dann Daten verschiedener Systeme nebeneinander angezeigt werden - und das auch von Programmierern, die von der Sache selbst gar keine Ahnung haben (müssen).

- per UDP-Paket

- per TCP-Verbindung

Letzteres hat den Nachteil, dass eine stehende Verbindung her muss und die Reaktionszeit des Servers die Latenz des Senders beeinflussen kann (wenn der Sender kein Multi-Tasking kann). Bei UDP weiss man ggf. nicht, ob das Paket angekommen ist, hat aber beim "broadcast" eine sehr einfache "fire & forget" Lösung mit wenig nötigem config-Aufwand.

Ein Beispiel, wie sowas realisiert werden könnte ist z.B. auch bei den Davis Wetterstationen in Verbindung mit dem Meteobridge-Projekt zu sehen. Ich bin gerne bei der Implementierung behilflich.

[Mario]

So weit ich weis ist doch via "hhtp-get" schon implementiert, der Alex betreibt seinen Controller ja schon so...
Soll heißen der hat nen extra Rechner laufen, wo er mit seiner eigenen Software den Controller steuert und abfragt...

Musst dich mal hier durchlesen wurde auch schon in diversen Threads erwähnt...

z.B. hier:
https://www.poolsteuerung.de/viewtopic.php?f=29&t=29

[jwka]

Nein, bei dem Beispiel ist's eben GENAU ANDERSRUM - was ich ja als "falsch" postuliere, weil ...

Da pollt der Server beim PoolController. Wie schon geschrieben, wenn man ein kurzes Intervall wählt (z.B. typisch 1 Sekunde oder gar kürzer), dann sind 99% aller Anfragen unnötig (weil kein Änderung zum Wert vorher) und belasten den Home Server.

Andersrum wird ein Schuh draus: Der Controller als "Subsystem" meldet beim Home Server (oder einer anderen "Sammelstelle") seine Daten. Und dafür muss in der Controller-Software etwas implementiert werden, eine Parameter-Seite (in etwa wie bei Mail) her, damit die IP Adresse plus Page plus Credientials angegeben werden kann. Bei einer "Ablieferung" der Daten z.B. auf einem Internet-Server entfällt dann auch das Freischalten eines Ports auf dem Router, was nötig ist, wenn von aussen auf den Controller zugegriffen werden muß.

[Alex]

Darum polle ich auch nur alle 60 Sek.

Aber das Problem hast in die andere Richtung auch. Wann soll er Daten schicken? Eine reine Messwertänderung der Sensoren hast Du ständig wenn mal ein paar Sensoren dran hängen... irgendeiner hat immer nen neuen Wert. Wenn der Controller dann jedesmal die Daten aktualisiert verschickt, dann macht er das im worst-case im 10ms Takt.
Also muss man es wieder einschränken, damit es sinnvoll und nicht zu viel wird... und dann kann man auch gleich wieder ein festes Intervall vorgeben.... und dann is man wieder da wo man vorher war.

[jwka]

Das ist m.E. nicht ganz richtig:

Es gibt Werte, deren Änderung "massiv" ist: Pumpe ein/aus, andere deren Änderung "relativ" und in der Regel "minimal" ist: Ph Wert, Chlor Wert etc. So kann man für diese Messwerte z.B. leicht einen Delta-Wert definieren, bei dem es sinnvoll wird, einen neuen Wert zu übermitteln.

Ausgehend von der Methode, alle, sagen wir 3-5 Minuten einen kompletten Datensatz im Zuge des des "Alive" Signals zu senden, genügt es für die typischen Messwerte wir Temperatur, Ph, Chlor/Salzgehalt die Änderung nur bei einer recht großen Schwelle zu liefern (die in den allermeisten Fällen zwischen zwei "alive Sendungen" gar nicht stattfinden wird).

ABER: Der Server bekommt wesentliche (und ggf. sogar abzustimmende) Werte wie "Pumpe ein" oder auch "Kind ins Wasser gefallen" (Bewegungsmelder/Rauschmelder) dennoch sofort übertragen. Das ist mit Polling definitiv nicht hinzukriegen.

[Alex]

hm... ja. Aktoren is klar, das ist eine Zustandsänderung relativ "eindeutig"

Es gibt aber auch z.B. Analogeingänge und Sensoren, die abgesehen von ihrem Grundrauschen sich sehr gerne und auch viel verändern. Pegelstände, Drücke, Schwimmerschalter, Luftfeuchte, Impulsgeber zur Durchflussüberwachung (sind zappelig und liefern ein sehr breites Spektrum an Impulsen)...
Fühler an Absorbern (ändern ihre Temp extrem und auch schnell bei Sonne/Wolke/Sonne/Wolke)

Du brauchst am Ende dann für jeden Sensor und jeden Eingang eine definierbare Range was "normal" ist und was nicht damit das sinnvoll wird... das würde etwas ausarten, denke ich.

[jwka]

Naja, sooo viel braucht's auch nicht:

Je Eingang einen Delta-Wert. "Normal" oder "unnormal" kann dann ja mit der Logik im Empfangssystem abgefangen werden. Der Poolcontroller selbst schickt die Daten eben nur, wenn das Delta vom aktuell gelesenen Wert zum zuletzt gelesenen Wert (die beiden Werte hat man ja in jedem Fall) größer als Delta ist. Dann kommt der neue (gerade gelesene) Wert in die Liste der zu versendenden Daten und das war's schon. Ist der String der zu versendenden Daten nach bearbeiten aller Sensoren ungleich "leer", wird das Datenpaket auf den Weg gebracht.

Natürlich bräuchte es für die Delta Werte eine Page, um sie zu erstellen, andererseits werden diese Werte vermutlich nur von den Leuten gepflegt, die dann diese Art von "Notification" auch wollen. Die wiederum, sollten in der Lage sein, Delta-Werte auch per http-get an das Board zu senden.

Bliebe also eine Variable je Sensor, die im Basiszustand einfach auf 100 gestellt wird (größtes anzunehmendes Delta) und so würde im Normalzustand einfach nie etwas gesendet.

Für die http_get Verarbeitung und das Setzen von Variablen gibt es vermutlich eh eine "globale Setter-Funktion", die den Argument-String abarbeitet und bekannte Argumente in die internen Variablen schreibt? Wenn das noch einer entsprechenden Logik folgt, wäre das auch nicht der riesen Aufwand.

In diesem Zusammenhang: Ist denn der MP-Code irgendwo einsehbar/hinterlegt? Das Projekt ist ja fast sowas wie ein OpenSource Projekt ... dann könnte ich ggf. einfach eine Branch machen und den nötigen Code selbst hinzufügen. Ich nehme an, dass alles in C/C++ oder C# entwickelt ist?

[Frankie]

HI

Code: Alles auswählen

Das Projekt ist ja fast sowas wie ein OpenSource Projekt ... 

ne, ist es nicht, die Sourcen werden bei uns unter Verschluss gehalten
Ist im Prinzip alles nichts neues, Stand der technik quasie , nur in der vorgestellten Form hat das Niemand, ausser im Hochpreis-Segment eventuell

Umsetzungstechnisch , was du beschrieben hast , ist das nichts unmögliches, die Infrastruktur ist ja grundsätzlich vorhanden
naja grenzenlose Resourcen hat der eingesetzte COntroller natürlich auch nicht, ist auch mal irgendwann Schluss.

Obs nun übder den internen HTTP CLient oder auch einfach nur per UDP verschickt wird, mal egal

dann muss man sich noch Gedanken zu Fehlerbehandlung machen , wenn irgendwas nicht ankommt, die Gegenstelle gerade nicht inline ist , all son Zeugs, damit der Controller da brav weitermacht
Würde mal behaupten ist schon einiges an Zeit was man mit der Umsetzung / Test / Freigabe verbringt.

Aber das allerwichtigste , zumindest mal für uns : wer von den Usern hat da Interesse an so etwas
Wenn sich also herrausstellt , das das was ist, added Value, Alleinstellungsmerkmal soll es daran nicht scheitern
im Moment seh ich das noch nicht, hat aber bisher auch noch niemand so eingefordert, müsst man daher mal abwarten ob sich da was rauskristallisiert.
Die User von der Hausautomatisierungsfront "beschaffen" sich die Werte vom Controller
Hatte bisher so den EIndruck das dies auch so gängige Praxis ist
ich selber hab sowas nicht , daher bin ich angewiesen auf Anregungen / Vorschläge / Diskussionen

gruß
Frank

[jwka]

Code: Alles auswählen

Das Projekt ist ja fast sowas wie ein OpenSource Projekt ... 

ne, ist es nicht, die Sourcen werden bei uns unter Verschluss gehalten

Schade eigentlich, denn über OpenSource "zieht" man oft weitere Leute rein, die dann viel Arbeit übernehmen (z.B. diese gewünschte Funktion), aber das ist natürlich jedermanns freie Entscheidung. Auch bei OpenSource Projekten gibt es immer wieder "geschlossene" Implementierungen ... sogar kommerziell. Siehe z.B. OpenWRT, eines der am meisten adaptierten Router-"Betriebssysteme".

Wäre es nicht ne Überlegung wert, ein "OpenPool-OS" anzubieten? Daraus kann ja immer eine "Original" Variante abgeleitet und mit dem Projekt verwendet werden. Und Bayrol & Co halte ich nicht für offen genug, Euer "Know How" zu übernehmen oder abzukupfern.

den internen HTTP CLient

Das klingt ja interessant, dass der schon da ist!

dann muss man sich noch Gedanken zu Fehlerbehandlung machen , wenn irgendwas nicht ankommt, die Gegenstelle gerade nicht inline ist , all son Zeugs, damit der Controller da brav weitermacht

Bei einem Http Client würde ich timeout machen und wenn die Sendung nicht funzt, einfach weiter machen, allerhöchstens eine e-mail. Aber schon das (e-mail) halte ich für überflüssig oder sogar kontra-produktiv, denn wer ein sauberes System hat, der weiss ja nach kurzer Zeit, dass das "Alive" nicht mehr gekommen ist und kann bei sich selbst reagieren. Schickt der Controller immer ne e-mail, muss ich das auch noch abstellen, wenn ich am HomeServer eine Maintenance mache oder ich den "Poolservice" (zeitweise) disablen möchte.

Grundsätzlich wird das IoT Thema darauf hinaus laufen, dass man viele autarke, dezentrale Einheiten hat, die aber zentral melden, damit User gesammelte und summarische Meldungen bekommt. Wer schonmal von 10 oder 20 solcher "Gadget" zugemüllt wurde, weiss, wovon ich spreche.

Wenn sich also herrausstellt , das das was ist, added Value, Alleinstellungsmerkmal soll es daran nicht scheitern
im Moment seh ich das noch nicht, hat aber bisher auch noch niemand so eingefordert, müsst man daher mal abwarten ob sich da was rauskristallisiert.

Ok. dann warte ich auch mal ab.

Die User von der Hausautomatisierungsfront "beschaffen" sich die Werte vom Controller

Das ist hier wie bei anderen Technologien: Solage es weniges gibt, funktioniert das. Aber es kommt gerade eine Welle von IoT Geräten auf uns zu und dann ist der Server schnell nur noch damit beschäftigt, Daten einzusammeln (und auch noch auszuwerten!)

Und genau da liegt ja auch der Vorteil der "abliefer-Methode": Wer weiss den besser, ob etwas relevant war oder nicht, als der Controller? Und wenn ich auf der Server Seite halt nur das bekomme, was auch relevant ist, reduziert sich die Arbeit dort erheblich und ich habe die Rechenleistung ideal verteilt - das wird gerade bei den schwachbrüstigen Servern garantiert wichtig werden (Beispiel: in verschiedenen (OpenSource-)Projekten wird gerade daran gearbeitet, den RasPi als Hausautomationsserver einzusetzen) denn nur, weil der RasPi gerade die letzten Redox-Temp und sontigen Werte des Pools "bearbeitet" soll das Licht nicht mit merklicher Latenz eingeschaltet werden, wenn ich den Lichtschalter drücke. Und bei solchen Vorgängen sprechen wir über 50ms -100ms "merklichkeitsschwelle" - alle Kommunikationspakete (Taster --> RasPi --> Aktor) eingeschlossen!

Aber gut. Ich verstehe Euren Standpunkt und wollte das Thema einfach mal angerecgt haben. Warten wir's einfach ab, wie sich alles entwickelt.

[Frankie]

danke für dein Verständnis
Den Support den man bei OpenSource noch zusätzlich leisten müsste können wir gar nicht stemmen, das muss koordiniert werden
Versionskontrolle, Changemanagement , Releaseverwaltung Doku, der ganze Rattenschwanz
Wir verbringen heute schon zig Stunden nach Feierabend um es allen Recht zu machen , wenn irgendwas nicht klappt etc
Müsste ich meinen aktuellen Job dann an den Nagel hängen

Als quasie Open Source steht das Web interface zur Verfügung, Ermöglicht es dem User sich die Anzeige umzugestalten um damit sowas wie eine peronalisierte Anzeige zu bauen. Wird aber soweit ich weiss kaum genutzt.

Hast mal paar Links wo ich mal gucken kann was das IoT oder wie das heisst ist ?
Wie gesagt da kenn ich nich nicht mit aus, bzw noch keinerlei Berührungspunkte gehabt
Würde daher selber mal zu einer persönlichen Einschätzung kommen ob das zukunftsträchtig aussieht

Also wie gesagt wir nehmen alle Vorschläge ernst , prüfen das, gibt auch sicherlich mal ne klare Absage, aber vieles konnte doch unter Mitwirkung der User implementiert werden.
Versuch mal bei den renommierten Herstellern ne Änderung zu bewirken , lol

Also warten wir mal bischen ab
gruß
Frank

[jwka]

Versuch mal bei den renommierten Herstellern ne Änderung zu bewirken , lol

Messe Dich nie mit den Schlechten, immer nur mit den Guten!

Wie gesagt da kenn ich nich nicht mit aus, bzw noch keinerlei Berührungspunkte gehabt

Na, nicht untertreiben! ... Euer PoolController IST eine IoT-Device!


Links zum Thema ... Google ist Dein Freund. Die haben übrigens für 3.2 Mrd USD einen "Frontrunner IoT" übernommen: NEST. Gib einfach "IoT" ein und wenn Du Zahlen willst, "IoT Gartner" oder "IoT growth". Kickstarter ist voll von IoT Devices, und Arduino, Ras/BananaPi, OpenPicus, Beagle sind bekannte Namen. Selbst Rutenbeck hat inzwischen für 140 EUR ein vierfach Relais Hutschienenmodul, das Du per IP steuern kannst.

IoT ist Gegenwart - zumindest für mich, aber ich beschäftige mich damit auch seit 2006, seit ich in meinem Sabbatical bin.

[Frankie]

hab zwischendurch immer noch mal bischen rumgegoogelt, also so ganz aus dem Kopp geht mir das nicht
sehe das da durchaus Aktivitäten bzgl IoT ( Internet of Things) erkennbar sind, also auch von bekannten Firmen wie Bosch und Apple
denke daher das es durchaus lohnenswert ist sich mal bischen damit auseinanderzusetzen
was ich noch vermisse, bzw noch nicht so richtig geblickt habe:
gibt es irgendwo einen Standard , irgendwas was man implementieren kann um eine Anbindung an Vorrichtungen zu ermöglichen , die dies bereits unterstützen ?
Gibt alle möglichen Artikel dazu , aber bisher noch nichts konkretes gefunden was mir bei einer Umsetzung irgendwie weiterhelfen könnte
Hast du da irgendwas ?
angewendet auf unsere Lösung glaube ich das es irgendwie drauf hinausläuft das jeder einzelne Temperatirsensor eine einzelne IoT Instanz ist
genauso wie jede einzelne Elektrode ( pH und Redox) und eben das was man noch so an die analaog oder digital EIngänge anschliessen könnte

wenn du mir da bischen auf die Sprünge helfen kannst ....
wir haben die Flexibiltät sowas umzusetzen , aber ich brauch ein Packende irgendwie
gruß
Frank

[jwka]

Zuerst einmal: Aus meiner SIcht ist der PoolController EINE IoT device. Wenn an einem Arduino viele Sensoren hängen, spricht man auch nur von einer IoT Device. Und beim PoolController sind die Sensoren ja sogar noch "sehr zentriert".

Es hängt bei der Betrachtungsweise eigentlich eher an der IP Adresse denn daran, wieviele "Properties" eine IoT Device hat. Es können ja sogar mehrere IoT Devices "Dasselbe messen" (z.B. Aussentemperatur)

Extrembeispiel: Ich habe IoT Devices, die mir (jede) Lichtschalter übewachen, UV Strahlungswerte liefern, Fenster-Kontakte auslesen und gleichzeitig noch Relais haben, mit dem ich in (zwei verschiedenen) Zimmern Licht schalte. Es ist trotzdem nur EINE IoT Device - weil eine IP Adresse (oder weil in einem Gehäuse / eine Platine).

gibt es irgendwo einen Standard , irgendwas was man implementieren kann um eine Anbindung an Vorrichtungen zu ermöglichen , die dies bereits unterstützen ?

Nein. Es gibt noch nicht mal ansatzweise so etwas, wobei Cisco, IBM und Qualcomm ehemalige "proprietäre" "Protokolle" inzwischen versuchen als OpenSource zu platzieren in der Hoffnung, dass das dan "der Standard" wird - und behaupten natürlcih auch schonmal es sei der Standard. Bei IBM ist es ein aus dem uralten MQ-Series abgeleiteten RPC Zeug MQTT (<--- google), was man a OASIS gegeben hat, bei Qualcomm ist es die Allseen Alliance ...

Ich würde danach auch nicht schielen (im Zweifel werden dann nämlich trotz "open" Aufdruck Lizenzen fällig) sondfern würe mir auf technischer Ebene eine Sache überlegen, die man dann auch leicht umbauen kann.

Im Prinzip funktionieren ALLE IoT devices mit einem der drei von mir schon oben genannten Protokolle:

- TCP
- UDP
- HTTP-GET

Letzteres wäre natürlich für ne ganze Menge von Möglichkeiten geeigent, weil PHP Server wie Sand existieren (und auch free of charge sehr einfach beim "Privatmann" installierbar sind --> xampp etc) und auch für jedermann bei 1Blu & Co für nen Appel und ein Ei erschwinglich sind.

Wenn Du die Daten mittels http://<webadresse>:<port>/<seite>?temp=X&ph=y&cl=z&......... an einen PHP Server schickst, kann sich der Empfänger mit print_r( $_GET ) alle Daten in einem assoziativen Array ansehen. Das ist SUPEREINFACH ...

Fast genauso einfach ist es in den meisten Systemen, ein per UDP versendetes Paket (ggf. mit derselben Payload wie oben) entgegen zu nehmen und auszuwerten. Die meisten Programmiersprachen haben sowas wie in PHP parse_str(), was diesen standardisierten Datenstring in ein Array aufdröselt und als "Datensatz" zur Verfügung stellt.

UDP ist deshalb auch so nett, weil es keinen Handshake macht sondern ein "fire & forget" Protokoll ist. Da könnte man nun mit Unzuverlässigkeit argumentieren (Empfänger "hört gerade nicht") aber wenn man das Paket alle paar Sekunden/Minuten veschickt, kriegt der Empfänger halt das nächste.

Clevere Lösungen sind eh so gebaut, dass der "Alive" nur als Prfung benutzt wird und man selbst die Daten von Zeit zu Zeit abholt und dann mit den "Alives" nur noch updated. In einem "Alive" würde z.B. per UDP nur die Änderung seit letzten "Alive" mitgeteilt, alle "X-mal" ein Komplettstatus. Damit kann der Empfänger dann selbst festlegen, wie er verfahren will: Einfach übernehmen oder in einen Handshake mit der Device gehen um dann die Daten "verifiziert" abzufragen.

Die "anfälligste" aber auch "sicherste" (und auch über's Internet funktionierende) Verbindung ist dann schließlich TCP.

WESENTLICH ist eigentlich nur, dass man dokumentiert, wie seine Daten aufgebaut sind, wie man die verschickt, und wie eine andere Device die Daten beom PoolController abrufen kann.

Ich helfe Euch gerne bei der Implementierung, habe da etwas Erfahrung ...

[Alex]

Gibt ja noch "Industrie 4.0". Soll sich ja auch mit solchen Dingen und Standards dafür beschäftigen. Zumindest mal mit dem vereinheitlichten Datenaustausch zw Unterschiedlichen "Maschinen". Aber die kommen ja auch nicht voran und is die Frage ob die dann evtl. irgendwann mal festgelegten Standards auch für den Privatbereich übernommen werden.

[jwka]

Industrie 4.0 benutzt "prinzipiell" dieselben Devices oder jedenfalls Microprozessoren und Ethernet als Infrastruktur. Aber beim Protokoll wird es dort sehr viel mehr um Redundanzen und Sicherheit im Sinne der Zuverlässigkeit gehen. Verschlüsselung etc. wird - bei den internen Prozessen jedefalls - eine untergeordnete Rolle spielen. Und: Da es dort von IT-Spezialisten wimmelt, werden die Dinger dort wesentlich komplexer und komplizierter bleiben.

IoT im Endverbraucherbereich wird nach meiner Einschätzung dazu führen, dass der Router eine gänzlich neue Rolle bekomt, nämlich die des heimischen Schutzwalls, und zwar nach innen (Intrusion) wie nach aussen ("Distribution" persönlicher Daten). Gerade letzteres ist inflationär und viel zu viele Geschäftsmodelle versuchen, Cloud Dienste und "externe Intelligenz" (für die es aufgrund der Fortschritte gerade auf Ebene der Device überhaupt keinen Grund gibt) Daten von Verbrauchern in ihre Silos zu bekommen. Das wird irgendwann zu einem gewaltigen "Bums" führen, spätestens wenn mal wieder ein Promi "nackt ausgezogen" dasteht, weil sämtliche Puls-Party-Powerwerte von ihm/ihr im Internet nachlesbar sind.

Das ist auch ein Grund, warum ich für eine "starke" Zentraleinheit bin, bei der dann die Devices ihre Daten aktiv abliefern - denn das verhindert z.B. schon das Auslesen durch Dritte (man denke nur an einen "globalen Bug" in einer Firmware ... 200 Devices im Haus und alle von Hinz und Kunz auslesbar? GAU!

[Frankie]

Interessant
also sagen wir mal wir haben die folgenden Sensoren / Aktoren "anzubieten"
max 4(5) analog Werte ( Kesseldruck , Feuchte sensor, Füllstand, Durchfluss etc + CPU Temperatur )
max 4 digital werte ( Schalter / taster zustände)
max 8 Temperaturwerte
pH
Redox
8/16 Relais zustände

an wen schickt man das denn ? UDP oder TCP zunächst mal egal
da muss ja mal irgendein Rechner permanent online sein , der das entgegen nimmt und auswertet, dessen locale Adresse/ Port muss bekannt/ fixed sein

muss jedes Element eine eindeutige ID haben oder reicht es mehrere textstrings mit Newline zu schicken sowas wie
Temperatur1 (oder Username), gain, offset, Rohwert
Temperatur2 (oder Username), gain, offset, Rohwert
,,,
Relais1 ( oder Username), On oder Off
...
hattest ja mal erwähnt nur bei einer ( konfigurierbaren) Schwelle einen aktuellen Wert zu schicken
also kann die Payload auch mal mehr mal weniger Daten enthalten , der Empfänger muss das auseinander fummeln ?

dann alle x minuten ein komplett Update ALLER Sensoren / Aktoren ?

sowas ?

[jwka]

an wen schickt man das denn ? UDP oder TCP zunächst mal egal
da muss ja mal irgendein Rechner permanent online sein , der das entgegen nimmt und auswertet, dessen locale Adresse/ Port muss bekannt/ fixed sein

Stimmt so nicht ganz:

UDP erlaubt einerseits ein Broadcast --> Semdung "an alle", egal ob online oder nicht.

Andererseits kann (und muss) über timeout auch ein nicht reagierender (oder nicht "eingeschalteter" --> keine IP Verbindung) Rechner "übersprungen" werden.

Ich würde vorschlagen, mit einer UDP Broadcast und einer HTTP-GET Sendung anzufangen. Für beides gibt es vielfache Code-Beispiele im Netz. Bei HTTP-GET sollte aber neben der IP auch der Port einstellbar sein, um bei Zugriff via Internet dem Zielnetz ein NAT zu ermöglichen.

Zum Format:
Ich würde jede Info als "key=value" pair senden und das ganze in einen "parseable string" packen --> siehe mein Beispiel:

nehmen wir ganz allgemein als Beispiel: Poolwerte 1-10 (was auch immer hinter welchem Poolwert steckt) und Relais 1-16:

ein Gesamt-Status wäre dann (http-get Beispiel):

Code: Alles auswählen

<adresse>?t1=10&t2=17&t3=17.5 [...] &t10=21.2&R1=0&R2=1&R3=0&R4=0 [...] &%10=1

Alternativ - aber das ist geschmacksfrage - könnte man die Daten auch in ein JSON oder XML Format verpacken, bekommt dann aber einen größeren Payload.

Denselben String kann man ebensogut in ein UDP Paket verpacken. Vorteil dieser Vorgehensweise ist, dass man später auch verschlüsselt übertragen kann, indem der String einfach verschlüsselt übertragen wird.

Ein Einzelstatus (z.B. innerhalb einer Meldegrenze veränderte Temperatur oder PH-Wert oder eben ein gedrückter Taster) würde mit

Code: Alles auswählen

<adresse>?t7=10.3&t7v=10.1&R4=1

Übertragen. Da bei einem Relais plus Info "Änderung" klar ist, wie vorher der Status war, könnte (muss aber nicht) man bei einem analogen Wert noch den Vorwert mit senden (--> t7v).

Wie ich schon sagte: Es gibt da keinen wirklichen Standard aber wenn man sich an den gesunden Menschenverstand hält, ist es kein Hexenwerk und "Drittanbieter" haben es leicht, eine "Schnittstelle" dafür zu bauen.

Natürlich kann man eine Sendung auch so aufbauen, dass die Stelle des Wertes dessen Ursprung (die Variable) definiert - so haben das ja viele Protokolle getan. Das reduziert die Payload, wenn man eine vollständige Sendung schickt, allerdings ist die Lesbarkeit dann deutlich reduziert und man kann keine Teilsendungen schicken, was die Reduktion des Payload insgesamt wieder auffrisst.

Und wenn Du so ein "parseable Format" benutzt, ist das "auseinanderfummeln" beim Empfänger sehr leicht mit Standardcode und bei vielen Programmiersprachen sogar mit Basis-Funktionen machbar.

Schau Dir mal das Meteobridge Projekt an. Dort haben wir Wetterstationen, und die haben teilweise viel schneller wechselnde Werte. Dort kannst Du sowohl die Implementierung als auch Code ansehen.

[Alex]

Die arbeiten aber auch mit festen Intervallen und nicht mit "bei Änderung neue Daten schicken".

Mal ehrlich, ich seh' den Vorteil nicht.
Mit HTTP-GET, in einem festen Intervall, hast als "Anwender" erstmal das gleiche Problem um das in eine Hausautomation zu integrieren. So oder so musst Du ein Script schreiben das entweder Daten abholt oder wartet und Daten "empfängt", angetriggert durch den GET-Request... Das erzeugt in beiden Fällen den gleichen Traffic. Nachteil sehe ich eher darin, das man mit "Versand bei Werteänderung" keine wirkliche Kontrolle mehr über den entstehenden Traffic und die Netzwerklast hat.

Bei "Versand nach festen Intervall" spielt es aus meiner Sicht dann keine Rolle mehr ob von der Hausautomation geparst wird oder ob der Controller schickt.

"Versand nach Werteänderung per UDP" würde vom Anwender erfordern das er seine Hausautomation dazu bringt auf Port X permanent zu lauschen ob was reinkommt und das dann zu verarbeiten... und ich würde mal meinen dass es den wenigsten geläufig ist, wie sowas um zu setzen ist.

Nicht das ich die Idee grundsätzlich nicht gut finde... stellt sich für mich nur die Frage nach der Anwendbarkeit beim User - es hilft ja nix wenn man (im Moment) was hat was keiner bedienen/nutzen kann.

[jwka]

Die arbeiten aber auch mit festen Intervallen und nicht mit "bei Änderung neue Daten schicken".

Immehin schicken sie es und ich muss nicht abholen. Das ist ja mal meine "Hauptanfrage" ... und ich stehe mit den Machern dort auch in Kontakt, die Datensendungen besser zu segmentieren.

Aber: Das ist auch nicht ganz mit dem PoolController zu vergleichen, denn z.B. Winddaten oder auch Regenmenge ändern sich teilweise ja im Sekundentakt, insofern wird, bei entsprechendem Wetter, ohnehin im sekundentakt gesendet. Und wegen Böhen und der Notwendigkeit, Durchschnitte zu bilden (Wasserkippe z.B. 5x aufsummieren) macht eine sofortige Sendung auch gar kein Sinn.

Taster, bei denen eine Sendung an ein anderes System im Milisekundenbereich erfolgen sollte, um merkliche Latenzen auszuschalten, gibt es dort nicht.

Ich erhalte z.B. alle 3 Sekunden Wetterdaten, um auch entsprechend reagieren zu können.

Aber zum Thema PoolController:

1.) Last

Mit HTTP-GET, in einem festen Intervall, hast als "Anwender" erstmal das gleiche Problem um das in eine Hausautomation zu integrieren. So oder so musst Du ein Script schreiben das entweder Daten abholt oder wartet und Daten "empfängt", angetriggert durch den GET-Request... Das erzeugt in beiden Fällen den gleichen Traffic. Nachteil sehe ich eher darin, das man mit "Versand bei Werteänderung" keine wirkliche Kontrolle mehr über den entstehenden Traffic und die Netzwerklast hat.

Es geht nicht um Traffic/Netzlast (Bandbreite) sondern um Belastung des Servers, das Pollen durchzuführen.

Stell Dir einfach vor, Du hast 200 Devices (ja, das wird kommen. Ich habe zur Zeit rund 90 IP-Devices und es ist kein Ende in Sicht) wie den Poolserver und willst die alle pollen.

Erstens fängt das Problem dort an, wo User-Interaktionen "sofort" festgestellt werden sollen: z.B. Eure Relais bzw. Tastereingänge. Erste Frage: Wie oft polle ich den Poolserver, um das schnell genug mitzubekommen? 10xpro Sekunde? Das bedeutet bei 200 Devices 2000 polls je sekunde.

Will da gar keine Datenrechnung machen, aber ein typischer Scriptdurchlauf kostet z.B. bei meinem Server zwischen 10 und 20 ms. Ich würde sagen, dass dann bei 200 Devices eine Serverlast von bestimmt 20-40% permanente Auslastung wäre.

Mit welchem Ergebnis? Beim Poolserver würden wohl in 99,9% aller Anfragen die Werte der Anfrage zuvor geliefert werden. Da ich aber die Relais und Taster-Funktionen eben sofort eill, bleibt mir nichts anderes übrig, also so oft zu pollen.

Und vor allem: Mit welchem Nebeneffekt? Der Server ist recht ausgelastet, es können maximal 15 Script parallel laufen, lassen wir's 50 Scripte parallel sein. Die Wahrscheinlichkeit, dass ein Benutzer irgendwo einen Taster drückt, aber noch "X" andere Devices gepollt werden müssen, bis die Device mit dem aktuellen Tasterdruck dran ist, ist sehr hoch.

Resultat: Massive Latenz.

Benutzer merken Latenzen ab ca. 100ms zwischen Aktion und Resultat. Wir sprechen da aber über ggf. 2-3 Scriptdurchläufe, bis das Resultat "erscheint". Also bleiben mir 30, max. 40ms "Kerndurchlauf". Da tun 20ms Delay nur wegen Pollingaufgaben schon richtig weh.


2.) UDP / HTTP-GET Implementierung:
Fast jeder Server, den ich kenne, hat eine UDP-Listenfunktion, bei dem in den Parametersn nur der Port anzugeben ist, auf dem gehört wird. Ferner gibt es Bibliotheken (wie z.B. die an der ich gerade schreibe), die dem User das "gefrickel" abnehmen. Auch für den HTTP-Get.

Und wie ich schon geschrieben habe, um ein HTTP-Get entgegen zu nehmen braucht's eigentlich gar nix ... das Script wird nämlich durch den request getriggert (und zwar nur dann, wenn auch was anliegt) und der Code, um die Daten zu kriegen ist NULL, weil der Server (z.B. Apache) mir die Daten bereits wunderbar aufgesplittet in einem assoziativen Array mit Namen $_GET liefert.


3.) Hausautomation

spielt es aus meiner Sicht dann keine Rolle mehr ob von der Hausautomation geparst wird oder ob der Controller schickt.

Darf ich fragen, welche HA Du einsetzt, dass Du sowas postulierst? Muss ein recht schnelles System sein, das würde ich mir gerne ansehen.

[Alex]

Ich setzte gar keine Hausautomation ein, geht mir alles zu langsam
Nein Spass, ich hab wirklich keine. Aber ich verstehe Dein "Problem" schon.

Aber nochmal... wenn Du zeitgesteuertes Polling von Deiner Hausautomation dadurch ersetzt das die Devices (nicht mehr kontrollierbar) "schicken" ... ist Deine HA doch genauso mit dem Empfang und verarbeiten der Daten beschäftigt die sie dann in unkontrollierbaren Intervallen von 200 Devices (um mal bei dem Beispiel zu bleiben) bekommt... und jeder geschickte Datensatz löst ja wieder eine Instanz eines Scriptes in der HA aus, das dann auch durchläuft und auch wieder den Prozessor der HA belastet. Wo genau ist also der Unterschied?

Im Gegensatz könntest Du die Anzahl der Script-Instanzen kontrolliert in Deiner HA reduzieren in dem das Polling in ein Script zusammengefasst wird und pro Scriptdurchlauf möglichst viele unterschiedliche Geräte (von einem Script) nacheinander gepollt werden. Da läuft dann auch nur eine Instanz mit entsprechend niedriger Prozessorlast - darauf hast Du Einfluss. Du hast aber wieder gar keinen Einfluss, wenn jedes Gerät - für den Server unkontrollierbar - schickt, weil dann eben wieder für jeden ankommenden Request eine einzelne Instanz eines Script XY gestartet wird... und bei 15 Instanzen ist meinetwegen Ende oder da beginnen die Latenzen - Systemabhängig halt.
Wenn die 200 Geräte dann noch zeitlich synchronisiert wären (was wohl erstmal nicht der Fall sein wird - aber mal angenommen)... und jedes schickt z.B. alle 5 Minuten einen vollen Datensatz... dann kämen im schlechtesten Fall im 5 Minuten Takt 200 gleichzeitige Requests an Deiner HA an. Gleicht dann eher eine DDOS Attacke. ... Da kommt die auch nicht hinterher.

Latenzen wirst Du aber auch haben, wenn Du den Controller (bzw. dessen DigitalInputs) z.B. als "Schnittstelle" zum Netzwerk und einem Request an die HA verwenden willst. Die HA hätte ja eigene, direkte Eingänge für sowas. Der Controller hat gerade mal nen 50MHz Prozessor mit 64kB(!) RAM... und der tut ja auch noch was anderes nebenbei. Wenn Du einen Digital_Input nutzt um damit einen GET aus zu lösen, den die HA verarbeitet um dann evtl. noch einen Schaltbefehlt an den Controller zurück zu geben... dann wirst Du da immer wieder mit Latenzen zu kämpfen haben - sei es weil der Controller grad mal keine Zeit hat, die HA beschäftigt ist, das TCP Paket zum 3. mal verschickt wird weil's grad an der Netzwerkverbindung hakt... oder warum auch immer.

An was für eine Anwendung (konkret) hast Du denn bei diesem Scenario gedacht. Also das mit Auslösen eines Digital_Input ein Request an die HA raus geht?