ich baue gerade an einem OpenSprinkler (ist eine Gartenbewässerungscomputer basierend auf Raspi) Modul und grundsätzlich funktioniert das soweit. Die grundsätzliche Struktur bereitet mir aber etwas Kopfzerbrechen.
Es gibt einen Controller (physikalisches Device), der mehrere Regnerstationen steuert. Ich kommuniziere per http mit dem Controller, um die Konfiguration abzufragen oder zu ändern genauso wie Konfiguration und Status aller Stationen. Letztere polle ich zyklisch.
Der Controller verwendet im Konfigurationsmodul einen Configurator, um die vorhandenen Stationen anzulegen. In welchem Fall sollte man nun ein separates Konfigurator Modul bauen?
Und baue ich nun ein separates IO Modul oder mache ich den Controller zu einem IO Modul?
Verwende ich ein separates IO Modul, kann ich den Controller und die Regner als Symcon Devices in einem Ordner anlegen, habe aber zusätzlichen Programmieraufwand für die ganze Kommunikation (SendDataToParent, SendDataToChildren, ReceiveData, ForwardData, …) zwischen Controller und IO.
Ohne separates IO Modul können aber Controller und Stations nicht miteinander kommunizieren - oder verstehe ich da was falsch? Also muss ich meinen Controller zum IO Modul machen. Dann liegt er aber im „I/O Instanzen“ Folder, was für ein Gerät wiederum unschön ist.
Den passenden Datenfluss kannst Du ja weitgehend vom den Grundeinstellungen mit dem Modul Generator erzeugen.
Wenn Du regelmäßig abfragst macht ein IO Sinn, dann fragt nämlich nur eine Instanz an und verteilt die empfangen Daten dann an die einzelnen Geräte anstatt das jedes Gerät für sich anfragen würde. Also am ehesten und saubersten ist das halt mit einem IO, Konfigurator und Device Instanzen gelöst.
also einen Controller als IO-Modul zu machen funktioniert auch nur bedingt, weil man m.E. nach unterhalb eine IO-Instanz keine Variablen anlegen kann (soll?)
Ich nehme an, das zu jeden Controller es Variable gibt, die man halten möchte oder übergreifende Aktionen auslösen.
Und zu jedem Controller gibt es x Zonen / Beregnungskreise, die jeweils auch Variablen haben.
eine IO-Instanz, die die Kommunikation mit der API und die Kommunikation der Instanzen untereinander realisiert
eine Konfigurator-Instanz, mit Hilfe derer ich Controller anlegen kann
und eine Geräte-Instanz, die von dem Konfigurator angelegt wird und die wiederum zusätzlich zu der eigentlichen Funktionalität ein Konfigurator für die Zonen ist
und eine Geräte-Instanz, die eine Zone / Beregnungskreis darstellt
Die Konfigurator-Instanz mach hier Sinn, weil ich zu einem Account grundsätzlich mehr als eine Controller haben kann.
Ich verstehe schon, das man mit den Nachrichten-ID’s etwas Knoten im Hirn bekommt
Ist der Controller hier nur das „Gateway“ zu dem System oder kann der auch eigenständig verwendet werden?
In ersterem Fall wäre der Controller wohl der Splitter. Daran hängen sich dann der Konfigurator, der die Erstellung von Stationen ermöglicht und natürlich die Stationen selbst, die dann via Datenfluss mit dem Controller kommunizieren. Ob du an den Splitter dann noch einen zusätzlichen I/O hängst, ist dir überlassen. Ich kann mir aber gut vorstellen, dass du dir das ganze durch die Verwendung eines ClientSocket erleichtern kannst. Das wäre auch so der „klassische“ Aufbau mit Gateway als Splitter und den Geräten und Konfigurator daran.
Wow, das Modul sieht ja mal sauber strukturiert aus. Das werde ich mir auf jeden Fall zur Orientierung genauer ansehen.
Ein Unterschied zwischen OpenSprinkler und Hydrawise scheint zu sein, dass es beim OpenSprinkler keinen übergreifenden Web Service gibt. Jeder Controller selbst hat seinen eigenen direkten lokalen Web Service Zugang. Daher hatte ich den erst auch als Device mit Configurator in der Konfiguration angelegt.
Denkbar ist natürlich eine separate Configurator Instanz, über die ich dann manuell Controller anlege (Discovery ist nicht vorgesehen) und für alle angelegten Controller die Stationen. Ich weiß aber nicht, ob das den Aufwand lohnt, denn typischerweise wird man vermutlich eher nur einen Controller haben und vielleicht ein Erweiterungsboard mit weiteren Sprinkler Stationen (ein Controller kann bis zu 64 Stationen verwalten).
Das mit den Nachrichten IDs ist in der Tat sperrig…
Der Controller hat selbst auch Konfigurationsoptionen (Beregnungsprogramme, Wetter, …), steuert aber in erster Linie die Stationen. Hardwaretechnisch ist es ein Raspi mit acht oder auch mehr Schaltaktoren für die Ventile.
Warum würde ich einen Splitter zwischenschalten? Was ist der Unterschied, ob ich einen Controller und acht Stationen per ConnectToParent() an einen Splitter hänge, der wiederum ein IO Modul hat gegenüber dem, dass ich die Module alle an das IO Modul hänge?
Den Client Socket bzw. den HTTP Client habe ich mir noch nicht genauer angesehen, in den meisten Modulen, die ich mir angesehen habe, wurde einfach CURL verwendet, das sind ein paar Zeilen Code. Welchen Vorteil habe ich durch Eure fertigen IO Module?
Wenn der Controller per Netzwerk auffindbar ist, wäre das aber tatsächlich eine separate Discovery-Instanz, in der Symcon Logik.
Du kannst natürlich in einem Configurator-Element auch einen Baum darstellen und so auch aufzeigen welche Module bzw Instanzen wo zusammenhängen.
Hier nutze ich das für Geräte und Sensoren. Wobei sie im Datenfluss aber einfach alle am IO hängen.
Dort wird auch CURL benutzt, da es keine andere Schnittstelle als polling per HTTP gibt, habe ich auf den IO von Symcon verzichtet. Mein IO ist also Splitter als auch IO in einem.
Michael
Hallo,
ein Splitter hat m.M. nach eine besondere Bedeutung, wenn die Datenmenge groß sind und Daten von allen/vielen Childs enthalten. Der Splitter würde ja bewirken, dass nur eine Teilmenge zu jedem Device geschickt wird bzw nur zu dem Device, für das Daten enthalten sind.
Ich habe bisher noch kein Splitter-Modul programmiert, weil meine Datenmenge, die ich von die API’s bekomme, sehr überschaubar sind. Zudem betreffen die Nachrichten fast immer alle Geräte-Instanzen des Typs, da könnte ich bestenfalls die kommunizierte Daten spezifisch im Splitte minimal verkleinern.
demel
Ist bei mir ähnlich. Die Datenmenge ist in der Tat sehr gering. Beim OpenSprinkler ist es so, dass ich mit einem einzigen Call die komplette Konfiguration samt Status der Stationen abfragen kann. Von der Umsetzung ist es dann natürlich trivial, das einfach an alle Children zu schicken und jeder sucht sich das raus, was er braucht. Gutes Design ist das dann aber natürlich nicht, aber IP-Symcon macht es einem da nicht ganz so einfach, da ich Nachrichten nicht gezielt an andere Devices, sondern nur an alle Children schicken kann…
ja, man kann Nachrichten nicht gezielt an eine bestimmte Device-Instanz schicken, aber es gibt etwas Vergleichbares.
Es gibt die Möglichkeit, einen Filter zu setzen ( SetForwardDataFilter, SetReceiveDataFilter )
dann „erreichen“ die Nachrichten den Client nicht.
Man muss nur in der Nachricht eine Identifikation des Client haben (z.B. eine Seriennummer o.ä.), einen entsprechenden regulären Ausdruck mit SetReceiveDataFilter() setzen.
Das setze ich auch so ein, aber wenn der Empfänger den Filter selbst setzen kann/muss, dann habe ich ja keinen nennenswerten Vorteil gegenüber dem gezielten Zugriff auf die richtigen Werte in der ReceiveData Funktion.
Der entscheidende Vorteil ist Performance.
Symcon filtert schneller als dein PHP Modul, und es belegt dadurch auch weniger PHP Slots.
Da nur neue Threads für die Child Instanzen starten, wenn der Filter passt.
Michael
Das werde ich mir auf jeden Fall zur Orientierung genauer ansehen.