eine etwas allgemeinere Frage. Mich würde interessieren, wie Ihr höhere Logik in IPS implementiert und ob es vielleicht Hilfsmittel gibt, die die Erstellung von Logik flexibler machen.
Hintergrund meiner Frage ist die Beobachtung, dass ich bei allem, was ich mache, immer wieder bei Skripten lande. Hier habe ich die Schwierigkeit, dass alles schnell monolithisch und schwer änderbar wird. Außerdem ist es nur mit Tricks möglich, Skripte generisch für 10 gleichartige Ziele (z.B. Rolladenaktoren) mit jeweils unterschiedlichen Parametern einzusetzen (z.B. nach Helligkeit hoch-/runterfahren, bei Uhrzeit hoch-/runterfahren etc.). Letztendlich lande ich bei einem eigenen „Framework“ aus bestimmten PHP Funktionen und frage mich, ob nicht viele Leute vor mir bereits vor demselben Problem gestanden haben und es vielleicht schon systematisch gelöst haben.
Daher habe ich die Frage, ob es irgendwelche Möglichkeiten gibt, höhere Logik anders als rein per Skript zu implementieren. Als Beispiele fallen mir die Programme in der CCU ein (wenn ich auch sonst nicht gerade ein Fan davon bin, aber für bestimmte Anwendungen sind sie gut geeignet), oder auch so etwas wie http://nodered.org/.
Das Problem hatte ich auch schon… irgendwo gibt es Beiträge von mir dazu… ich suchte insb. die Realisierung von Entscheidungstabellen, fand dazu aber auch nichts. Ich habe probehalber mal die WorkflowEngine Camunda integriert, aber dann nicht mehr den Weg gefunden es zu vollenden…
Ja, da sagt ihr was. Ich habe schon angefangen mir allgemeingültige Klassen für Licht oder Rollos zu schreiben welche dann via Parameter gesteuert werden… Hier liegt gar nicht mein Hauptproblem. Ich suche eine Alternative zu PHP. Und vor allem einer Möglichkeit das Programm zu debuggen!
Das finde ich eine wertvolle Anregung! So ähnlich habe ich auch begonnen, d.h. mit einer primären Gerätestruktur. Allerdings fehlt die Zwischenschicht, mit der ich dann kommuniziere. Vieles ist einfach mit in die Gerätestruktur integriert, z.B. durch Zusatzvariablen. Wenn ein IO Signal für Bewegung steht, dann hängt unterhalb der Instanz eine Variable „Bewegung“, die von einem Skript gesetzt wird.
Was mir noch total fehlt, ist ein konzeptioneller Ansatz, um Eingänge, Ausgänge und Parameter von Programmen (um mal die Homematic Sprache zu benutzen) sinnvoll verwenden zu können.
Ein bißchen Logik würde mir auch ganz gut tun, wenn da jemand eine zündende Iddee hat:loveips:
(PuI heißt übrigens Personen und Imobilien und umfaßt alle Melder)
Für Gruppen und Sammlungen von gleichen Aktionen nutze ich die Baumstruktur von IPS selber, das macht es einfach zu konfigurieren. Damit kann ich z.B. einfach einen Link auf ein Rollo an eine Stelle kopieren und damit ein Rollo dazu nehmen kann. Also anstatt Gruppen zu definieren kann man einfach einen „Ordner“ nehmen und alle da drin befindlichen Rollos gleich behandeln. Die Scripte sind dann eher viele, aber eigentlich enthalten die dann immer nur einen Aufruf einer Funktion die Zentral in einer Script-Datei liegt und damit nur 1x realisiert wird. Das macht es mir sehr einfach umzustrukturieren oder neue Gruppen anzulegen.
For logic that is only used in a single location I use simple scripts. Logic that is used by multiple rooms or devices is contained in a framework that uses a model viewer controller structure (where the viewer in most cases is the presentation of a variable in Webfront or the light output of a luminaire or the action performed by an actor).
In my IPS 3.4 system I use this structure to store lighting scenes in zones:
Whenever someone presses a push button or a motion detector detects presence a script is triggered that loads the framework. The buttonController or presenceController finds out in which zone/room the action takes place and decides what to do (in this case call the lightingController, switch some relays and set the colour of DMX fixtures to the colour specified in the active lighting scene).
This is not a very robust solution. For every zone/room I have to copy and modify many variables and scripts. Also there is no clear distinction between a regular category and a zone/room.
For IPS 4.0 the way forward is to put reusable logic in PHP Modules. I am now building Room Module that contains the actual state of the room (temperature, humidity, lighting etc) with a LightingControl and TemperatureControl module as child instances to control the lighting and temperature in the room. The LightingControl module could have multiple LightingScene modules and a LightingScene module could have multiple Luminaire modules. The advantage of this solution is that you can build highly advanced logic while all code is contained in the PHP Module and settings can be easily maintained using a form. No need to edit scripts. Deployment is much easier because you can easily update the modules from Module Control while you are using your IDE of choice (e.g. PHPStorm) for development.
