Anregung: Aktives anliefern statt Polling & Heartbeat

[jwka]

Lies doch bitte nochmals meine vorherigen Beiträge. Dort habe ich auf alle Fragen schon geantwortet.

Zusammenfassend:

Ein System, bei dem bestimmte Änderungen "sofort" detektiert werden sollen, diese aber sehr selten vokommen, zu pollen ist Unfug.

Entweder du pollst mit hoher Frequenz, dann ist die Wahrscheinlichkeit, dass Du ein Ereignis WIRKLICH DANN realisierst, wenn es Eintritt (und nicht x Zeiteinheiten später) recht groß. Oder Du pollst mit niedriger Frequenz, dann wirst Du in aller Regel ein Ereignis "zu spät" entdecken. Bei manchen ist das nicht schlimm, bei anderen im Zweifel komplett in Frage stellend.

Das "chaining" von Polls hilft überhaupt nicht, im Gegenteil, es wird dazu führen dass praktisch jeder Poll "zur Unzeit" (m.a.W.: zu spät) kommt. Zudem blockiert jedes zu langsam antwortende Device (z.B. Ausfall) das Pollen jedes anderen. Das ist so ziemlich die schlechteste Load Balancing Methode, die ich kenne.

Willst Du etwas annähernd in Echtzeit mitbekommen, bleibt nur eine hohe Frequenz plus paralleles Verarbeiten von Anfragen an Devices, weil Du nur so "rum kommst", weil Du Antwortzeiten schon wieder für Anfragen nutzen kannst.

Beim Event-Gesteuerten Ablauf wird nur dann gearbeitet, wenn auch etwas zu tun ist.

Nochmals: Beim PoolController sprechen wir wohl von einem Ratio von 1:1.000 Abfragen:Ereignisse bei einer Polling Frequenz von 1x pro Sekunde? Das wären 86 "Ereignisse" pro Tag, die gesendet würden? Polle ich wie oben geschrieben 5 x pro Sekunde (was als deutliche Latenz spürbar wäre) ist's ein Ratio von 1:5000 usw.


Das Beispiel:
Ich hätte gerne in der Visualisierung sofort gesehen, wenn z.B. ein Taster für das Poollicht gedrückt wurde. Und wenn der Hauseigentpümer dann noch sagt: Wenn ich das poollicht einschalte, möchte ich die Beleuchtung der Palmen auch damit geschaltet haben, dann hast Du bereits die Verkettung. Und da sieht eine Latenz zwischen Poollicht und Gartenbeleuchtung ganz "Panne" aus.

Weitere Verkettung gefällig? Wenn ich in der Hausautomation "Abwesenheit" gewählt habe, möchte ich gerne:
- dass das Poollicht NICHT geschaltet werden kann
- bei betätigen des Tasters die Alarmstufe um eins erhöht wird (ei, wer ist denn da?)

[Alex]

Hält einen ja nichts davon ab in einem Script auch über mehrere Verbindungen, simultan Clients zu pollen. Und das die Request nur mit passend gewählten Timeouts laufen, versteht sich ja von selber.
Aber mit Load Balancing hat das alles, wovon Du schreibst, auch nichts zu tun. Du lagerst was aus, was in Summe dann doch wieder das gleiche am gleichen Gerät ergibt (HA Server). Möglicherweise sprechen wir aber auch von unterschiedlichen Voraussetzungen und haben da gerade eine völlig unterschiedliche Auffassung welche Sensoren wie oft Daten liefern müssten... Du sprichst auch immer davon das sich die Werte am Controller nur selten ändern. Die Analogwerte "ändern" sich im 10ms Takt, ebenso die Messwerte der Sonden, wenn es sein muss.
Das ist ja das Thema das ich angesprochen hatte mit der einstellbaren "Range".. was ist "normal", was nicht. Nachdem Du das ganze aber ja eher "Global" betrachtest... stelle ich in Frage das es in absehbarer Zeit z.B. einen Raumthermostat oder eine Wetterstation geben wird der man auch noch sagen kann "schicke erst wenn Werteänderung um X°". Muss also was parktikableres her, was womöglich eher Anwendung finden wird.


Das Beispiel Deiner "Verkettung"... entweder verstehe ich es nicht oder es macht wenig Sinn.
Wenn Du am Controller einen DigitalInput nutzt um ein Licht zu schalten und es soll auch ein anderes Licht geschaltet werden, dann konfiguriere das intern. Dann gibt es keine Latenzen und wird direkt geschaltet. Ein abgeschickter GET dient nur noch der Signalisierung in der HA.

Wenn der Digital_Input nur dafür benutzt werden soll das der Controller einen GET an die HA schickt, diese den verarbeitet und dann einen Schaltbefehlt (per GET oder POST) zurück an den Controller schickt... wirst Du Latenzen haben, ob Du willst oder nicht. Das bringt diese Struktur dann zwangsläufig mit sich. Wobei das in der Praxis im Privatbereich fast ausschliesslich dem "Zustand" des Netzwerkes in die Schuhe zu schieben ist und nicht das die beteiligten Geräte gerade überfordert wären.

>>Weitere Verkettung gefällig? Wenn ich in der Hausautomation "Abwesenheit" gewählt habe, möchte ich gerne:
>>- dass das Poollicht NICHT geschaltet werden kann
>>- bei betätigen des Tasters die Alarmstufe um eins erhöht wird (ei, wer ist denn da?)
Gefällig ist gar nix. Dann müssen Deine Taster eben auch gesammelt und direkt an die HA und nicht an den Controller. Sonst endet das aus obigen Gründen zwischendurch immer in Latenzen. Und "Zwischendurch" wäre nach meinem Empfinden für so eine Anwendung (Licht an) schon wenig zumutbar - deswegen gehören solche Anforderungen imho auch nicht um 2 Ecken übers Netzwerk geleitet sondern in dem Fall direkt an die HA Hardware.

[jwka]

IoT geht davon aus, dass IP --> Erthernet --> das Netzwerk der neue "Automations-Bus" ist. Insofern ist - in dieser Denke - jedes IP Device "direkt" an die HAS (HA Server) angeschlossen.

Bei meinen Devices (ich mache selbst Entwicklungen) spricht der Licht-Taster mit dem Lampen-Relais via UDP/TCP. Der HAS kriegt alles mit und "überschreibt ggf. sogar Telegramme.

Wir haben wahrscheinlich zu unterschiedliche Blickwinkel. Am sinnvollsten wäre vielleicht ein Gespräch, die Posts hier nehmen viel zuviel Zeit und wir drehen und im Kreis.

[Mario]

Also ich hab das ganz aufmerksam verfolgt, auch wenn ich nur die Hälfte von verstehe...

Du beforzugst also das der Controller in gewissen Abständen (welche auch immer und wie auch immer die angetriggert werden) seine Daten schickt.

90% (wenn nicht sogar mehr) der Leute hier nutzen den so wie der von Frank kommt.
Einer (kenne zumindest nur einen, steuert den fern via Server und nen paar (kenne bis dato auch nur 2-3) haben ne Hausautomatisation.

Heist ich schließe das Teil an und wenn ich Lust habe (das ist in der Regel nicht öfterst wie 5 mal am Tag) schaue ich mir am Handy, Laptop oder am PC mal an was da so los ist.
Und das kann ich z.B. mit dem Handy machen egal wo ich bin.
Woher weis jetzt der Controller, dass ich das auf meinem Handy haben will und unter Umständen mit ständig wechselnder IP, da ich ständig unterwegs bin,teils über WLan oder LTE?
Also ich habe keine Hausautom. und keinen Server und plane auch nix derartiges (wie vermutlich die restlichen 90% der Leute hier).

Wenn ich also nur 5 mal am Tag da drauf schaue, wozu soll der da im sec. Rythmus seine Daten schicken, wobei sich dabei die Frage stellt, wohin der die bei mir schicken soll????

Vielleicht verstehe ich das aber auch einfach nicht richtig und ihr könntet mich mal aufklären, aber bitte so das ich es verstehe

[Frankie]

ich kann deine Begeisterung für Hausautomation ungefähr nachvollziehen
ich hab auch Bekannte die sowas haben , und schärmen davon das sie jeden Taster im Haus und jede Lampe umprogrammieren können , aber mache tun sie das letzendlich doch nur einmal
würde mal sagen , das ganze HA Thema ist genauso wie der private Pool die Carrera Bahn des erwachsen gewordenen Jungen.
da kann man sich ewig mit beschäftigen, immer wieder was neues hinzubauen usw, man sollte aber das gelegentliche Baden nicht vergessen

Eine Komplettlösung wie den Controller einzubinden ist bischen kniffelig: was soll die HA noch machen was der Controller nicht besser und schneller selber kann.
Also nur die Werte in 20ms statt in 5s abzuliefern ? Sitzt keiner den ganzen Tag davor und schaut den Relais in Echtzeit beim Schalten zu
Glaube das sowas sinnvoll sein kann , wenn man alle Sensoren / Aktoren die man am Controller anschliessen kann einzeln und netzwerkfähig bekommen kann, dann könnte ? man die Steuerung / Dosierung in die HA integrieren. Ein gewisses zu lösendes Risiko besteht schon noch wenn man es übers Netzwerk nicht mehr schafft die laufende Dosierung zu stoppen
Aktuell sehe ich den Nutzen nur darin das man die Controller Werte mit in die HA Visualisierung einbinden kann, was ja von einigen via HTTP GET genutzt wird , sodass man alles in der HA drin hat , eher jedoch "nur zum Gucken"

gruß
Frank

[michaelv]

Ja auch ich habe hausautomatisierung über fhem im Einsatz mir reicht es vollkommen wenn ich die Werte mir über http holen kann um sie dann zu visualisieren den Rest macht doch der controller automatisch

Gruss michael

[jwka]

ok.

[jwka]

Achtung Feind!

Nochmals ein Versuch (ich würde so ein Teil gerne kaufen statt mir eine eigene Lösung zu schaffen, weil ich genügend andere Themen vor der Brust habe, die noch wichtiger sind aber in der jetzigen Form kommt es für mich nicht in Frage):

Mein Wunsch:
Nur den PoolControler (und ausschliesslich diesen) im Poolhaus. Der soll neben Pool- und Gartenlicht auch den Wasserstand automatisch halten, hierzu gibt es Schwimmer-Schalter, die das Signal zur Befüllung geben. Diese soll aber nur dann erfolgen, wenn die Pumpe aus ist, denn die Befüllung erfolgt durch den Filter mit anschließendem Rückspülen.

Da die Wasserzufuhr zum Grundstück (und somit auch zum Pool) über ein elektronisches Ventil geregelt ist, welches wiederum (aus vielerlei Gründen: zu wenig Wasserdruck, also darf Befüllung nur zu bestimmten Zeiten erfolgen, Zisterne, manchmal gar kein Wasser --> Druckkontrolle, Leckagekontrolle usw.) von der Automation gesteuert wird, muss der Controller zunächst eine Meldung an die HA senden, diese dann wiederum ein "ok" an den Controller. Erst dann kann er das Wegeventil umsetzen und das Ventil für die Wasserzufuhr einschalten.

Mit diesem Szenario ist meine Anforderung zwar noch ein wenig komplexer geworden (Controller wartet auf "ok"), aber der Rest ist im Prinzip genau dasselbe.


Noch ein paar Antworten:

Ich setzte gar keine Hausautomation ein, geht mir alles zu langsam

Das geht heute noch vielen so, das ist eine EIB/KNX Krankheit. Das System setzt Übertragungstechnik von 1990 ein - 9600 BAUD. Daher setze ich auf IoT und Ethernet als "Bus". Wie viele neue Geräte heutzutage. NEST dürfte wegen der Übernahme durch Google das prominenteste sein.

ich hab auch Bekannte die sowas haben , und schärmen davon das sie jeden Taster im Haus und jede Lampe umprogrammieren können , aber mache tun sie das letzendlich doch nur einmal

DAs ist auch nicht Sinn der HA und typisch nachgeplappetrtes Verkaufsargument vom Elektriker. 90% der Hausautomatisierungen, die ich kenne (und ich kenne einige, auch wohlhabender Leute, die viiiiiel Geld dafür bezahlt haben) sind schlicht elektronische Lichtschalter. Von "smart home" und damit also von genau solchen Dingen, wie sie der PoolController machen will, nämlcih dem Besitzer Arbeit und Wege abzunehemn sind viele entfernt.

HA Visualisierung einbinden kann, was ja von einigen via HTTP GET genutzt wird , sodass man alles in der HA drin hat , eher jedoch "nur zum Gucken"

Das ist eben genau auch die veraltete Denke und mag für klassische (Bewertung siehe oben) Hausautomatisierungen zutreffen. Dort ist auf dem Server eh meist Patchwork und die Latenzen sind eh System-immanent. Smart Cities, Smart Grid, Smart Homes, Smart Devives werden das aber verändern. Es wird auch eines Tages kommen, dass nicht nur der Verbrauch effektiv sondern auch der Strom-Peak in die Kostenbewertungen eingeht. Oder dass derjenige mit einer "knappen" Solar-Eigenversorgung keinen zusätzlichen Strom aus dem Netz ziehen will ... dann möchte man z.B. nicht die Poolpumpe/Poolheizung UND die Waschmaschine/Wäschetrockner/Backofen gleichzeitig laufen lassen. Nur, wie kopple ich das ohne zentrale Intelligenz und damit dem Thema "aktives Daten-Anliefern"? Soll FRau gucken ob Poolpumpe läuft, Knöppsche drücken und dann die Wama erst einschalten? Was ist mit der Zeitsteuerung der Wama?

Eine Komplettlösung wie den Controller einzubinden ist bischen kniffelig: was soll die HA noch machen was der Controller nicht besser und schneller selber kann.

Wie ich schon schrieb: Das sehe ich anders. Relais --> sofortige Meldung, Bevorstehende Aktion --> sofortige Meldung plus ggf. Warten auf "OK", Messwerte via Delta in "großen" Schritten Melden: "PH ist jetzt seit [3] Minuten" auf Y, PH für [10] Minuten unter "X"

Letzteres Beispiel könnte ja auch heißen "Behälter leer" denn wenn der Regler ordentlich funktioniert sollten ja kritische Werte nie unter oder überschritten werden?

[Frankie]

Hi
nix Feind, quatsch
lass uns lieber überlegen wie wir zu einer Lösung kömmen , mit der du zufrieden bist , und die uns auch nicht in Bedrängnis bringt Einzellösungen einzubauen
Für dein Vorhaben ist deine Mitwirkung erforderlich , ein aktives, unaufgefordertes Senden ist erstmal nicht vorgesehen
eine Möglichkeit :
Schwimmerschalter an einem digitalen Eingang
du sammelst alle die Infos ein , wertest diese aus und schaltest das Befüllungsrelais von der HA wenn
Filterpumpe = Aus
Schwimmerschalter zeigt Nachfüllen an
Randbedingungen ( Wasserverfügbarkeit) erfüllt

wenn man das noch bischen safer machen will, kann man durch geschickte Verdrahtung der Versorgungsspannungen auch dafür sorgen
das zumindest zwei Bedinungen auch rein elektrisch abgesichert sind, nämlich Filterpumpen relais aus und Schwimmerschalter Relais ON
der Digitale Eingang muss dann ebenfalls ein Relais schalten, kann man ja so konfigurieren )
erst dann erfolgt überhauot eine Freigabe der Versorgungsspannung an einem dritten Relais , welches ausschliesslich von deiner HA gesteuert wird und quasie das finale GO gibt, dann wärst auch gegen EInzel ausfälle halbwegs sicher unterwegs.
ein Wischerrelais würde dem ganzen dann noch dei Krone an Safety aufsetzen
der würde dann spätestens nach sagen wir 1h ?? der Dauerbefüllung ein Ende bereiten , sodass man auch hier hohen Wasserechnungen entgegen wirken könnte
gruß´
Frank

[jwka]

Hmmm.

Vielleicht hilft folgendes, meine Position besser zu verstehen:

Wenn ich nicht alles im Pool und Garten vom Poolcontroller aus machen kann (was er ja könnte - ausser die Rückmeldung), muss ich ohnehin zusätzliche Kompnenten im Poolhaus installieren (von da geht die 1/3 der Gartenbeleuchtung ab) un muss alles mit der HA verbinden.

Daraus folgt: PoolController reduziert sich auf PH-Wert Messung, weil ich dann alles andere eh über die HA machen werde, es wird dann im Poolhaus nämlich entweder eine Comexio oder eine UNIPI installiert, beide sind frei programmierbar und können - wenn ich es nicht "ranprogrammiere", das Thema PH Wert Ermittlung "nicht von Haus aus", haben aber beide alle nötigen Komponenten, um es zu realisieren.

Das bedeutet, dass ich mir überlegen muss, ob ich zusätzlich das Geld für den PoolController ausgeben will oder ...

1.) erstmal manuell PH Einstellung betreibe
2.) die Funktiuon in den Comexio/UNIPI programmiere

Insofern ist das halt - in meinem Fall, und ich denke, dass es in Zukunft sicher noch ein paar mehr geben wird - eine ja/nein Frage pro oder contra PoolController.

Und Polling des Controllers kommt für meine Anwendung absolut nicht in Frage.

[Frankie]

HI

Daraus folgt: PoolController reduziert sich auf PH-Wert Messung, weil ich dann alles andere eh über die HA machen werde

dann ist unser PoolController keine Alternative für dich, warum machst dann die pH Steuerung nicht auch gleich über die HA ?
irgendeinen günstigen pH Messumformer wird man wohl auftreiben können

ob ich zusätzlich das Geld für den PoolController ausgeben will oder ...

du hast Bedenken , so les ich das mal raus, unsere Lösung ist aktuell nicht dafür ausgelegt in dem von dir anvisiertem Umfeld mitzuspielen.
ich will auch nicht versuchen dich zu irgendwas überreden,

was mich so klein wenig ärgert ist :
ich habe versucht ein paar Optionen aufzuzeigen, mir Gedanken gemacht , wie man das bei dir mit den gegebenen Mitteln umsetzen kann, paar Safety Aspekt noch mit dabei, das es sicher läuft
bist aber auch nirgendwie nicht so recht zu Kompromissen bereit , also das man sich quasie auf halber Strecke begegnet und guckt das man das Beste draus macht, sodass sich niemand über Gebühr verrenken muss, das wäre m.M nach ne faire Sache

Und Polling des Controllers kommt für meine Anwendung absolut nicht in Frage.

dann ist unsere Lösung einfach nix für dich , musst das dann beim "MItbewerber" versuchen , oder irgendwas anderes zusammenbasteln

das einzige was mit vertretbarem Aufwand kurzfristig denkbar wäre, der Controller schickt optional & periodisch ( Intervall x sekunden ) alle Infos per UDP zu einer IP Adresse mit Port X. letzendlich die gleichen Daten , die man auch beim Abpollen erhalten würde
deine HA muss das dann auseinander friemeln ( ist alles ASCII text kann man leicht parsen), das kriegste sicherlich hin, denk ich mal
brauchen dann allerdings weitere EInträge in der Netzwerkdatei für die UDP adresse und den Port ( und das Intervall )

mehr geht aktuell beim besten Willen nicht, jeder hat so eine bestimmten Vorstellungen , was er noch so alles hätte , da bist sicherlich nicht der Einzige, wir müssen auch immer den Blick aufs Ganze behalten , wenn wir was ändern , wer ist davon betroffen . wer muss was ändern , hat extra Arbeit dadurch usw
gruß
Frank

[schka17]

Hallo,

mein erster Post und das dann gleich zu dieser interessanten Diskussion (für mich). Ich habe den Poolcontroller erst letzte Woche bekommen und bin gerade dabei zumindest mal softwareseitig alles vorzubereiten, wenn dann die restlichen Installationsteile da sind, gehts an die Pooltechnik und die HW-Installation.
Auch ich beschäftige mich schon seit vielen Jahren mit Hausautomatisierung, die Bezeichnung gab es halt damals noch nicht. Ich habe mit der Automatisierung (Beschattung/Fensteröffnung und Heizung) meines Wintergarten begonnen, damals noch mit der C-Controlunit von Conrad und mit wenigen Sensoren, also Innen/Aussen-temperatur, Helligkeit usw.
Heute habe ich ca. 300 Sensoren und Aktoren im Einsatz und die Poolsteuerung ist die letzte Komponente die mir noch fehlt (ich denke danach wird mir schon noch was einfallen). Ich habe hier in den letzten 15 Jahren ziemlich viel ausprobiert und für mich entschieden dass ich für bestimmte spezielle Aufgaben, also z.B. Heizung, Sicherheit, Alarmierung, Multimediasteuerung, Presence, GUI, Ereignissteuerung, und eben Poolsteuerung jeweils eigene, autark arbeitende Einheiten sind und jede für sich auch alleine funktioniert. Alles läuft natürlich an einer Stelle zusammen und auch hier habe ich einiges ausprobiert, am besten kam ich mit meinen Anforderungen mit Openhab und FHEM zurecht, letzteres ist jetzt auch seit zwei Jahren mit mehreren Instanzen in Produktion. Als nicht-Programmierer muss ich mich hier mit vielen Sprachen herumschlagen (Perl, Java, Shell, HTML.....) und das treibt mich teilweise zur Verzweiflung, dafür bin ich bisher nirgendwo an Grenzen der Integration gestossen, ausser bei meiner Daikin Klimaanlage, aber das ist nur eine Frage der Zeit. Ich bin dann auf MQTT und Node-Red gestossen und beginne jetzt, wenn möglich, alle neue Sensoren oder Aktoren über MQTT einzubinden. Und wenn ich mir etwas wünschen könnte für die Integration des Poolcontrollers, dann wäre das ein MQTT-Client (oder im einfachsten Fall einen telnetport den ich mit netcat auslesen kann). MQTT habe ich mittlerweile auch mit den Arduions (über das mySensors MQTT Gateway) und testweise mit dem ESP8266 im Einsatz -> das wäre vielleicht auch eine Idee um den Controller Wlan Fähig zu machen.
Und wenn man dann alle diese Aktoren und Sensoren am MQTT angebunden hat dann kann man damit auch als nicht-programmierer schon sehr viel machen, z.b. mit Node-red visuell eigene Regeln erstellen oder auch eigene GUI's.

Es gibt zwar zwei FHEM Module für den Poolcontroller, die erfüllen aber beide nicht meine Anforderungen, muss mir was eigenes schreiben, verwende zurzeit testweise das Perl script von Alex und werde es ein bischen modifizieren. Meine bisherigen Tests damit haben jedenfalls gezeigt dass das pollen im 1s Abstand scheinbar keine Auswirkungen auf den Controller hat und auch im Netzwerk und auf meinem zentralen Rechner keine messbare Last erzeugt, also kann ich damit mal sehr gut leben.
Ich teile die vorher abgebenen Meinungen dass ich nicht alle Messwerte bei jeder Änderung benötige, der Controller soll ja grundsätzlich autark arbeiten, aber Statusänderungen bei den Tastern oder Relais hätte ich schon gerne sehr zeitnah, darunter verstehe ich ca. 1-2s. Das reicht natürlich nicht für die Bedienung beispielsweise eines Lichtschalters, weil in einer früheren Phase hatte ich das mal ausprobiert und alles über Regeln gesteuert, und alle Reaktionszeiten > 300ms war eine Katastrophe (also Lichtschalter ein bis Licht angeht).
Also zusammengefasst, pollen ist O.K., Relais schalten funtkioniert auch, aber was mir jetzt noch massiv helfen würde, wenn man zu jeweiligen Wert in der GetState.cav noch eine Typ mitbekommen könnte, damit man je nach "Gerätetyp" unterschiedlich mit den Daten weiterarbeiten kann, also z.B R=Relais, T=Temperatur, A/D=analog/digitaleingang. Jetzt verwende ich halt den Namen, aber hier muss ich dann Abstriche in der Lesbarkeit machen.

Gruß
Karl

[schka17]

Also zusammengefasst, pollen ist O.K., Relais schalten funtkioniert auch, aber was mir jetzt noch massiv helfen würde, wenn man zu jeweiligen Wert in der GetState.cav noch eine Typ mitbekommen könnte, damit man je nach "Gerätetyp" unterschiedlich mit den Daten weiterarbeiten kann, also z.B R=Relais, T=Temperatur, A/D=analog/digitaleingang. Jetzt verwende ich halt den Namen, aber hier muss ich dann Abstriche in der Lesbarkeit machen.

Nachtrag, habs einfach über eine Zähler gelöst, das ist auch eindeutig

Code: Alles auswählen

Uhrzeit: 16:23 h
1: ADC0: 188.19 mV
2: ADC1: 114.69 mV
3: Kesseldruck: -400.00 mBar
4: ADC3: 0.00 mV
5: CPU Temp: 53.54 C
6: Redox: -2505.12 mV
7: pH: 49.37 pH
8: Pool: 23.75 C
9: Aussen: 0.00 C
10: Ruecklauf: 0.00 C
11: S4: 0.00 C
12: S5: 0.00 C
13: S6: 0.00 C
14: S7: 0.00 C
15: S8: 0.00 C
16: Pumpe: 1.00 --
17: Chlor: 0.00 --
18: pH-: 0.00 --
19: pH plus: 0.00 --
20: Relais5: 0.00 --
21: Relais6: 0.00 --
22: Relais7: 0.00 --
23: Relais8: 0.00 --
24: TASTER1: 0.00 --
25: TASTER2: 0.00 --
26: TASTER3: 0.00 --
27: TASTER4: 0.00 --
28: EXT REL1: 0.00 --
29: EXT REL2: 0.00 --
30: EXT REL3: 0.00 --
31: EXT REL4: 0.00 --
32: EXT REL5: 0.00 --
33: EXT REL6: 0.00 --
34: EXT REL7: 0.00 --
35: EXT REL8: 0.00 --
36: CL Rest: 100.00 %
37: pH- Rest: 100.00 %
38: pH+ Rest: 100.00 %

[Alex]

Jo, die Werte kommen immer an der gleichen Stelle raus. Darüber kannst zuordnen, was was ist.

Warum musst/willst Du jede Sekunde pollen?

[schka17]

Jo, die Werte kommen immer an der gleichen Stelle raus. Darüber kannst zuordnen, was was ist.

Warum musst/willst Du jede Sekunde pollen?

Hallo Alex,

das war nur mal ein Lasttest, muss nicht sein, aber um Schaltvorgänge zeitnah mitzubekommen (mir geht es nur um die Relais, ein, aus, automatik, die Tasterfunktion bekomme ich so sowieso nicht mit) muss ich halt relativ oft pollen. Habe dann gestern noch das skript erweitert und damit den MQTT Server gefüttert und damit das entsprechende FHEM Device upgedated. Alles nur um mal die Last zu testen. Das führt jedoch deutlicher Last am Server, etwa 20% CPU also verdopplung der Grundlast. Das pollen alleine ist nicht messbar, der nächste Schritt ist eben nur die Änderungen an den MQTT Server zu pushen, die reinen Messwerte reichen alle paar Minuten wie bei den anderen Sensoren.

[Alex]

Das mit dem MQTT hab ich noch nicht ganz verstanden. Hast Du irgendwelche Sensoren die das nativ unterstützen?
Wenn nicht, musst Du doch jedes Protokoll, mit dem Du einen Sensor abfragen kannst, umsetzen auf MQTT... was ja immer Rechenleistung/Prozessorlaufzeit des Servers beansprucht und somit höhere Latenzen verursacht?

[schka17]

Ja, natürlich,
habe ein paar temperatur/feuchtigkeitssensoren gebaut, mit ESP8266 und DHT22, die liefern die Werte an den MQTT server. Auch für Arduino gibts fertige MQTT library, ausserdem gibt es ein MQTT Gateway für mySensors, ich bin gerade dabei einige unterscheidliche Sensoren und Aktoren damit zu bauen, für das Gateway warte warte ich nur noch bis ich endlich den Arduino Uno bekomme, dann implemtiere ich das auch. Und für die Kommunikation zwischen den FHEM Instanzen nutze ich teilweise auch MQTT. Alles was ich selbst integriere mache ich über MQTT anstatt z.b. Web Apis zu verwende. Das was es für mich so interessant macht ist die Möglichkeit die Daten aus der Queue beliebig zu verwenden, also z.b. Um verschiedene Visualiserungen oder Bedienungskomponenten zu bauen. Und in weiterer Folge dann mit Node-Red auch die Ereignissteuerung zu realisieren. Was die Latenzen betrifft, ich habe schon mal testweise mehrere hundert events pro sekunde generiert, ohne wirklich merkbare Latenzen, also da werde ich mit meiner HA eher nicht an die Grenzen stossen. Wenn ich dann mit Perl oder shellscripte die Webschnittstellen z.b. von Openhab oder FHEM bediene ist bei 40-50 Events/s die Schemrzgrenze erreicht, wobei deutliche Latenzen schon viel eher auftreten. Speziell bei FHEM das single theraded ist und auf Perl aufsetzt kommt man da schnell an die Grenzen. Ich meine da ist je nach HW bei 10 events/s schluss.

[Sevensworld]

Hi zusammen,

ich finde die Idee von jwka eigentlich auch ganz toll und würde mir so eine Funktionalität wünschen. (UDP bzw. TCP Verbindung)
Eine Art Telnet Server auf dem Controller, der zum einen die Daten bereit stellt und zum anderen auch auf Befehle per Datentelegramm reagiert.

- Relais Stati EIN/AUTO/AUS setzen
- Live Senden von (wichtigen) Zustandsänderungen
usw.

Habt Ihr noch mal darüber nachgedacht so etwas für HA User zu realisieren oder kommt das überhaupt nicht in Frage ?



Gruß
Jens

[Mario]

Nen Raspi dazwischen der das erledigt?

[Sevensworld]

Inwiefern soll das weiter helfen?
Der Raspi selber müsste ja auch wieder "pollen" um die Infos zu bekommen bzw. dann die Kom. zum Controller realisieren. Das ist dann doch doppelt gemoppelt !?
Ziel ist ja auch das lästige Polling los zu werden ... oder gibt es bereits ein Raspi Projekt dazu ??