Fragen zur Modulstruktur

[Carpi]

Hallo zusammen,

ich arbeite nach meinem JVC Projektor Modul (das außer mir selbst scheinbar niemand braucht ) jetzt an einem neuen Modul. Es soll die automatische Gartenbewässerung mit OpenSprinkler gesteuert werden. Den Controller hat eine API, die über HTTP ansprechbar ist.

Der Controller kann acht bis 64 Stationen verwalten, die würde ich als Geräteinstanzen über einen Konfigurator (da kämpf ich mich dann durch…) anlegen.

Nun habe ich zwei Implementierungsfragen:

1. Konfiguration und Status aller Stationen kann ich über einen einzigen API Call auslesen. Das würde ich dann zyklisch in einer IO Instanz machen und die einzelnen Stations-Instanzen mit SendDataToChildren aktualisieren, oder?

2. Ich frage eine API über HTTP ab. In den meisten Beispielen wird hier curl verwendet. Das funktioniert auch soweit. Wann würde ich das vordefinierte HTTP Request IO Modul ({4CB91589-CE01-4700-906F-26320EFCF6C4}) verwenden?

Und dann noch eine Best Practice Frage: Die Konfiguration des Controllers ist im Grunde statisch, es sei denn, man konfiguriert was um. Würde man dann eher erwarten, die Konfiguration nur über die Instanzkonfiguration explizit zu aktualisieren (über ein „Auslesen“ Button oder auch in ApplyChanges) oder sollte die Konfiguration jederzeit implizit beim zyklischen Auslesen aktualisiert werden. Da kann dann auch mal eine Sprinkler Station dazukommen oder wegfallen.

Und abschließend: Hat jemand einen OpenSprinkler und Interesse, das Modul zu testen, wenn es soweit ist?

VG
Bernd

[Nall-chan]

@Carpi

Nun habe ich zwei Implementierungsfragen:

1. Konfiguration und Status aller Stationen kann ich über einen einzigen API Call auslesen. Das würde ich dann zyklisch in einer IO Instanz machen und die einzelnen Stations-Instanzen mit SendDataToChildren aktualisieren, oder?

Jein. Kurze Grundlage:

• SendDataToChildren sendet aber immer an alle Child-Instanzen. Du entscheidest also bei SendDataToChildren nicht wo die Daten landen.
• Immer alle Daten zu senden an alle Childs, kann ein System stark beanspruchen.
• Eine Child-Instanz kann aber einen Filter setzen, auf Datensätze welche sie empfangen möchte.

Somit wäre der eine Call bestimmt die beste Wahl.
Dann aber das Ergebnis zerlegen in je einen Datensatz pro Station und Diese einzelnen Datensätze auch
einzeln mit SendDataToChildren versenden.
Im Child den ReceiveFilter setzen; dann kommt nur der eine gewünschte Datensatz auch in dieser einen Instanz an.

@Carpi

2. Ich frage eine API über HTTP ab. In den meisten Beispielen wird hier curl verwendet. Das funktioniert auch soweit. Wann würde ich das vordefinierte HTTP Request IO Modul ({4CB91589-CE01-4700-906F-26320EFCF6C4}) verwenden?

Dafür habe ich selber auch noch keine Verwendung (in einem PHP-Modul). Ich benutze auch direkt PHP-curl.

@Carpi

Und dann noch eine Best Practice Frage: Die Konfiguration des Controllers ist im Grunde statisch, es sei denn, man konfiguriert was um. Würde man dann eher erwarten, die Konfiguration nur über die Instanzkonfiguration explizit zu aktualisieren (über ein „Auslesen“ Button oder auch in ApplyChanges) oder sollte die Konfiguration jederzeit implizit beim zyklischen Auslesen aktualisiert werden. Da kann dann auch mal eine Sprinkler Station dazukommen oder wegfallen.

Verstehe jetzt nicht wirklich was du hier meinst.
Wenn eine Station hinzukommt, dann kannst du das im Konfigurator anzeigen.
Anlegen muss die Instanz aber der User. Entweder manuell über Instanz hinzufügen, oder über deinen Konfigurator.
Beim löschen ebenso; manuell löschen oder über den Konfigurator.
Michael

[Carpi]

Hallo Michael,

danke für das Feedback.

@Nall-chan

Jein. Kurze Grundlage:

• SendDataToChildren sendet aber immer an alle Child-Instanzen. Du entscheidest also bei SendDataToChildren nicht wo die Daten landen.
• Immer alle Daten zu senden an alle Childs, kann ein System stark beanspruchen.
• Eine Child-Instanz kann aber einen Filter setzen, auf Datensätze welche sie empfangen möchte.

Somit wäre der eine Call bestimmt die beste Wahl.
Dann aber das Ergebnis zerlegen in je einen Datensatz pro Station und Diese einzelnen Datensätze auch
einzeln mit SendDataToChildren versenden.
Im Child den ReceiveFilter setzen; dann kommt nur der eine gewünschte Datensatz auch in dieser einen Instanz an.

Wenn ich es richtig verstehe, dann führt SetReceiveDataFilter() dazu, dass IPS die Nachricht auf Basis von regex auswertet und an die richtigen Children sendet. Dadurch, dass das Child den Filter selbst setzt, wäre es dann aber auch kein großer Unterschied, wenn das Child die ganze Config bekommt und sich seinen Teil entsprechend rausziehen, oder?

@Nall-chan

@Carpi

Und dann noch eine Best Practice Frage: Die Konfiguration des Controllers ist im Grunde statisch, es sei denn, man konfiguriert was um. Würde man dann eher erwarten, die Konfiguration nur über die Instanzkonfiguration explizit zu aktualisieren (über ein „Auslesen“ Button oder auch in ApplyChanges) oder sollte die Konfiguration jederzeit implizit beim zyklischen Auslesen aktualisiert werden. Da kann dann auch mal eine Sprinkler Station dazukommen oder wegfallen.

Verstehe jetzt nicht wirklich was du hier meinst.
Wenn eine Station hinzukommt, dann kannst du das im Konfigurator anzeigen.
Anlegen muss die Instanz aber der User. Entweder manuell über Instanz hinzufügen, oder über deinen Konfigurator.
Beim löschen ebenso; manuell löschen oder über den Konfigurator.

Das beantwortet meine Frage aber auch schon.
Stationen kommen in zwei Fällen dazu oder weg: Wenn man ein Erweiterungsboard in den Controller einbaut oder wenn man eine Station Controller-seitig aktiviert/deaktiviert.
Der erste Fall passiert natürlich zwischen selten und nie, der zweite kann schon eher mal auftreten, aber sicher auch nicht regelmäßig.
Klingt also eher nach was, was man dann manuell aktualisiert.
Das könnte man dann vermutlich auch mit einer Discovery Instanz lösen.

VG
Bernd

[Nall-chan]

Discovery Instanzen sind dazu gedacht Geräte im Netzwerk oder an anderen physikalischen Schnittstellen zu erkennen.
Das Auslesen der Konfig von deinem Controller und darstellen der verfügbaren Stationen wäre ein Konfigurator.

@Carpi

Wenn ich es richtig verstehe, dann führt SetReceiveDataFilter() dazu, dass IPS die Nachricht auf Basis von regex auswertet und an die richtigen Children sendet.

Technisch eher so daß er Nachrichten verwirft, wenn der Filter nicht passt. Nur wenn der Filter stimmt, geht ein Datensatz durch.

@Carpi

Dadurch, dass das Child den Filter selbst setzt, wäre es dann aber auch kein großer Unterschied, wenn das Child die ganze Config bekommt und sich seinen Teil entsprechend rausziehen, oder?

Könnte schwierig werden, weil der Filter auf den String vom Datenaustausch greift. Das ist ein json kodiertes Objekt.
Und da man ja das im ReceiveData vom Child wieder dekodieren muss, benutzt man den Filter immer so daß er einen ganzen Datensatz durchlässt.
Michael

[Carpi]

@Nall-chan

Discovery Instanzen sind dazu gedacht Geräte im Netzwerk oder an anderen physikalischen Schnittstellen zu erkennen.
Das Auslesen der Konfig von deinem Controller und darstellen der verfügbaren Stationen wäre ein Konfigurator.

So habe ich es jetzt auch gebaut. Die Discovery Instanz wäre eher was, um es einfach mal gemacht zu haben, denn dass ein neuer OpenSprinkler im Netzwerk dazukommt ist doch eher selten… und auch die Anzahl der Stationen ändert sich normal nicht.

@Nall-chan

@Carpi

Wenn ich es richtig verstehe, dann führt SetReceiveDataFilter() dazu, dass IPS die Nachricht auf Basis von regex auswertet und an die richtigen Children sendet.

Technisch eher so daß er Nachrichten verwirft, wenn der Filter nicht passt. Nur wenn der Filter stimmt, geht ein Datensatz durch.

@Carpi

Dadurch, dass das Child den Filter selbst setzt, wäre es dann aber auch kein großer Unterschied, wenn das Child die ganze Config bekommt und sich seinen Teil entsprechend rausziehen, oder?

Könnte schwierig werden, weil der Filter auf den String vom Datenaustausch greift. Das ist ein json kodiertes Objekt.
Und da man ja das im ReceiveData vom Child wieder dekodieren muss, benutzt man den Filter immer so daß er einen ganzen Datensatz durchlässt.

Ich glaube, das muss ich einfach mal ausprobieren, was besser passt…

VG
Bernd

[Tuxtom007]

@Carpi

So habe ich es jetzt auch gebaut. Die Discovery Instanz wäre eher was, um es einfach mal gemacht zu haben, denn dass ein neuer OpenSprinkler im Netzwerk dazukommt ist doch eher selten… und auch die Anzahl der Stationen ändert sich normal nicht.

Ich habe gestern eine Schwachstelle von Opensprinkler in Verbindung mit MQTT gesehen - wenn wirklich mehrer Controller im Netzwerk sind, was nicht abwägig ist - bei mir lieber gerade zwei neue mit EPS8266 frisch geflacht auf dem Schreibtisch - dann ist eine Unterscheidung der einzelnen Controller nicht mehr möglich. Opensprinkler schickt keine eindeutige MQTT-Topis, z.b. Seriennummer oder Hostname oder sonst, sondern nur: „opensprinkler/…“

Auch bei den Station werden diese nur mit Topic „opensprinkler/station/xxx“ bezeichnet"

Ich muss mal suchen, ob es zu dem Thema schon einen Feature-Request auf Github gibt. Eine eindeutige Kennung währe doch praktischer, vor allen wenn man mehrere Controller nutzen will die per WLan gekoppelt werden.

[Carpi]

Das ist natürlich unschön, Es gibt aber einen „Workaround“: Man kann die Geräte in einer Master/Slave Kombination betreiben.

Ich habe auch zwei Geräte. Auf dem Master sehe ich dann im Web UI auch die Kreise des Slaves (siehe im Screenshot Vorgarten West und Ost, die haben dann ein Funk Symbol). Auch die MQTT Nachrichten kommen dann für diese Sprinkler mit opensprinkler/station/9,10,…

[soenkefischer]

Hallo Bernd,

auch ich habe schon länger vor Opensprinkler in Symcon zu integrieren.

Gibt es das Modul schon irgendwo?

VG Sönke

[Carpi]

Hall Sönke,

der aktuelle Entwicklungsstand ist auf GitHub.

Seit letztem Sommer habe ich daran aber nicht weitergearbeitet und ich bin mir auch noch nicht sicher, ob ich das noch machen werde. Ich mag PHP einfach nicht und werde mir eher auf Basis von C# etwas zusammenbauen.

Der Stand ist aber zumindest so, dass man den Status der Sprinkler sieht und auch Programme starten oder Sprinkler direkt starten und stoppen kann.

VG
Bernd

[soenkefischer]

Hallo Bernd,

ich habe nun mich mit dem Thema wieder ein wenig beschäftigt und versucht dein Modul in Betrieb zu nehmen …

Leider scheitere ich bereits bei der Anmeldung des Controllers in der IO Instanz:

Fehler beim Übernehmen der Änderungen

Fatal error: Uncaught TypeError: Return value of OpenSprinklerIO::InitController() must be an instance of SprinklerController, null returned in /mnt/data/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php:173
Stack trace:
#0 /mnt/data/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(127): OpenSprinklerIO->InitController()
#1 /mnt/data/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(89): OpenSprinklerIO->InternalUpdateStatus(false, false)
#2 /-(3): OpenSprinklerIO->ApplyChanges()
#3 {main}
thrown in /mnt/data/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php on line 173
(Code: -32603)

Hast du eine Idee was da schief läuft?

Ich nutze Symcon 6.3 (aktueller Stand)

Im Debug der IO Instanz sehe ich das 63 Byte rausgehen und 2016 reinkommen. Die eingehenden Daten sehen auch plausibel aus. Dennoch schaltet die Instanz nicht auf Aktiv.

VG

Sönke

[Carpi]

Hallo Sönke,

wenn 2.2016 Bytes zurückkommen, sieht das schon mal ganz gut aus, das dürfte der ganze Settings Block sein. Was steht denn im Symcon Statusprotokoll zu diesem Fehler?

VG
Bernd

[soenkefischer]

Hi,

das hier steht im Meldungsfenster:

09.04.2023, 19:14:52 | OpenSprinklerIO | UpdateStatus Error: Section [stations/stn_seq] missing from json

Ich habe vor kurzem ein Firmwareupdate für OpenSprinkler gemacht. Kann es sein das sich dort etwas an der Struktur verändert hat?

09.04.2023, 19:16:56 | ExecuteCommand | Attempt 1: Result={„settings“:{„devt“:1681067815,„nbrd“:3,„en“:1,„sn1“:0,„sn2“:0,„rd“:0,„rdst“:0,„sunrise“:393,„sunset“:1207,„eip“:2728279729,„lwc“:1681064429,„lswc“:1681064429,„lupt“:1681064423,„lrbtc“:99,„lrun“:[0,0,0,0],„pq“:0,„pt“:0,„nq“:0,„RSSI“:-34,„otc“:{},„otcs“:0,„mac“:„48:3F:DA:5D:XX:XX“,„loc“:„53.90893,10.66271“,„jsp“:„https://ui.opensprinkler.com/js",„wsp“:„weather.opensprinkler.com“,„wto“:{„key“:„“,„pws“:„“},„ifkey“:„“,„mqtt“:{„en“:1,„host“:„192.168.XX.XX“,„port“:1883,„user“:„XXX“,„pass“:„XXX“},„wtdata“:{„wp“:„Manual“},„wterr“:0,„dname“:„OpenSprinkler“,„curr“:0,„sbits“:[0,0,0,0],„ps“:[[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]],„gpio“:[]},„programs“:{„nprogs“:0,„nboards“:3,„mnp“:40,„mnst“:4,„pnsize“:32,„pd“:[]},„options“:{„fwv“:230,„tz“:56,„ntp“:1,„dhcp“:1,„ip1“:192,„ip2“:168,„ip3“:30,„ip4“:29,„gw1“:192,„gw2“:168,„gw3“:30,„gw4“:1,„hp0“:80,„hp1“:0,„hwv“:32,„ext“:2,„sdt“:0,„mas“:0,„mton“:0,„mtof“:0,„wl“:100,„den“:1,„ipas“:0,„devid“:0,„dim“:15,„uwt“:0,„ntp1“:0,„ntp2“:0,„ntp3“:0,„ntp4“:0,„lg“:1,„mas2“:0,„mton2“:0,„mtof2“:0,„fwm“:1,„fpr0“:100,„fpr1“:0,„re“:0,„dns1“:192,„dns2“:168,„dns3“:30,„dns4“:1,„sar“:0,„ife“:0,„sn1t“:0,„sn1o“:1,„sn2t“:0,„sn2o“:1,„sn1on“:0,„sn1of“:0,„sn2on“:0,„sn2of“:0,„subn1“:255,„subn2“:255,„subn3“:255,„subn4“:0,„wimod“:42,„reset“:0,„dexp“:2,„mexp“:8,„hwt“:172,„ms“:[0,120,120,0,120,120]},„status“:{„sn“:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],„nstations“:24},„stations“:{„masop“:[255,255,255],„masop2“:[0,0,0],„ignore_rain“:[0,0,0],„ignore_sn1“:[0,0,0],„ignore_sn2“:[0,0,0],„stn_dis“:[0,0,0],„stn_spe“:[0,0,0],„stn_grp“:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],„snames“:[„S01“,„S02“,„S03“,„S04“,„S05“,„S06“,„S07“,„S08“,„S09“,„S10“,„S11“,„S12“,„S13“,„S14“,„S15“,„S16“,„S17“,„S18“,„S19“,„S20“,„S21“,„S22“,„S23“,„S24“],"maxlen“:32}}, Status=200

VG Sönke

[soenkefischer]

Firmware 2.2.0(1) API Document - (Dec 23, 2022)

2. Major Changes
   Compared to previous firmwares, some of the major changes in this firmware that affect the APIs include:
   ● For OS v3 only: support for remote access via OpenThings Cloud (OTC); also support for Over-the-Air (OTA) firmware update via both WiFi and
   wired Ethernet.
   ● Support for sequential groups (which generalizes and replaces the previous per-zone sequential flag); program date range (i.e. support setting a
   start date and an end date of a program); pausing and resuming station runs; shift stations forward when manually stopping a zone; negative
   master on adjustment time and positive master off adjustment time

Das „stn_seq“ Attribut existiert seit der Firmware 2.2 nicht mehr …

Hast du dich schon entschieden ob das das weiterentwicklen möchtest?

Würde sonst gerne die Anpassungen auf Basis deines Moduls machen und dir dann gerne zur Verfügung stellen.

VG

Sönke

[Carpi]

Ja, das liegt am Fehlen des stn_seq der Firmware 2.20 und höher. Ich habe das jetzt einfach ausgebaut und zeige auch die Firmware in der Controller Configuration an. Deiner meldet sich scheinbar mit 2.30…

Lass mich wissen ob es mit dem Update klappt.

VG
Bernd

[Carpi]

Und zur zweiten Frage noch: Das war jetzt (hoffentlich) eine Kleinigkeit, aber viel Zeit möchte ich nicht mehr investieren. Ich kann gerne Anpassung von Dir übernehmen oder Dir auch Zugriff auf das Github Repo geben.

[soenkefischer]

Sehr cool. Danke. Hat scheinbar geklappt.
Konnte nun erfolgreich IO, Controller und die automatisch gefundenen Stations anlegen.

Damit komme ich auf jeden Fall schon mal ein riesen Schritt weiter.

2.3 liegt daran das ich eine erweiterte Firmware von dem deutschen Opensprinkler Shop Betreiber verwende. Der ergänzt die immer noch ein wenig. Ob man das braucht …
Basiert aber vollständig auf der originalen 2.2.

[soenkefischer]

Das ist natürlich schade, denn die von dir geschaffene „Basis“ ist wirklich super.

Es gäbe schon noch ein paar sehr interessante Dinge (z.B. die neue sequentielle Zonensteuerung, Rückmeldung der Restlaufzeiten der einzelnen Stations, Ansteuerung des Master, …)

Auch eine coole Anbindung an das (neue) Webfront wäre cool. Ich finde die Lösung von HomeAssist sehr schön gelöst.

Wenn ich Ergänzungen mache, dann kann ich diese ja als Pullrequest einreichen

VG Sönke

[Tuxtom007]

@soenkefischer

Das ist natürlich schade, denn die von dir geschaffene „Basis“ ist wirklich super.

Es gäbe schon noch ein paar sehr interessante Dinge (z.B. die neue sequentielle Zonensteuerung, Rückmeldung der Restlaufzeiten der einzelnen Stations, Ansteuerung des Master, …)

Sieht gut aus.

Gibt es die Möglichkeit, das Modul schon zu testen ? Ich wäre interessiert.

Worauf lasst ihr euren OpenSprinkler laufen - RasPi oder EPS8266 ?
Bei mir macht der RasPi komische Sachen, sobald ein Programm läuft, kommt man nicht mehr an die WebGUI - werde das mal mit einem EPS8266 testen müssen.

[Nall-chan]

@Tuxtom007

Gibt es die Möglichkeit, das Modul schon zu testen ? Ich wäre interessiert.

Link zu GitHub ist weiter oben.

@Carpi

der aktuelle Entwicklungsstand ist auf GitHub .

[DeeAge]

Hallo …
ich habe das Opensprinkler Modul von Carpi installiert. Ich benutze die Raspi Version mit Aufsteckmodul mit der neuen Firmware 2.2.0(1). Meine IPSymcon Ver. ist noch auf 5.5 (shame on me
Leider bekomme beim Anlegen der IO Instanz folgende Fehler …
Ist die Firmware zu neu, oder mache ich ich etwas falsch ?

LG Dirk

Fehler beim Übernehmen der Änderungen

Fatal error: Uncaught TypeError: Return value of OpenSprinklerIO::InitController() must be an instance of SprinklerController, null returned in /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php:173 Stack trace: #0 /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(127): OpenSprinklerIO->InitController() #1 /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(89): OpenSprinklerIO->InternalUpdateStatus(false, false) #2 /-(3): OpenSprinklerIO->ApplyChanges() #3 {main} thrown in /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php on line 173
Abort Processing during Fatal-Error: Uncaught TypeError: Return value of OpenSprinklerIO::InitController() must be an instance of SprinklerController, null returned in /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php:173 Stack trace: #0 /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(127): OpenSprinklerIO->InitController() #1 /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php(89): OpenSprinklerIO->InternalUpdateStatus(false, false) #2 /-(3): OpenSprinklerIO->ApplyChanges() #3 {main} thrown Error in Script /var/lib/symcon/modules/SymconOpenSprinkler/OpenSprinklerIO/module.php on Line 173 (Code: -32603)