Ziel ist die Bedienung vermeintlich neu auftauchender Schnittstellen. Bspw. angenommen ich wöllte ein HID-I2C Gerät unterstützen. (Das könnte man sicherlich mit ein paar Tricks und Kniffen über einen seriellen Port realisieren, doch Ziel ist die Entwicklung eines dedizierten Client-Moduls.)
Ich hätte vermutet, dass es möglich ist, einen Thread zu erstellen, welcher dann entsprechend irgendwann SendDataToChildren aufruft, bzw. auf ForwardData reagiert und für die zu speichernden Daten einen thread-sicheren Buffer verwenden. Dieses Vorgehen ist bei mir leider aufgrund der Abhängigkeit zu Thread, welche nicht aufgelöst werden konnte, gescheitert.
In der Dokumentation und in den Webinaren wurde recht ausführlich erklärt, wie Module jeglicher Arten erstellt werden können. Ich verstehe, dass die Entwicklung neuer IO Module vermutlich ein eher seltener Use-Case ist, jedoch wäre es dennoch interessant zu wissen, ob neue Hardware (egal in welcher Form) in IPS integrierbar ist und wenn ja, wie?
So selten ist das nun auch nicht, das ein oder andere PHP Modul bringt einen eigenen IO mit. Die Frage ist vielmehr auf welche Art und Weise die anzubindende Hardware Daten versendet. Meist reicht da ein Standard IO von IP-Symcon vollkommen aus, relevant ist dann der Splitter der individuell die Daten des IO gezielt aufbereitet. In der Regel erfolgt die Kommunikation mit Hardware aber immer über einen der verfügbareren IOs von IP-Symcon.
Am besten ist es wohl wenn Du konkret eine Hardware im Auge hast, die Du an IP-Symcon anbinden willst, diese näher zu benennen. Dann kann man Dir auch eher eine Antwort geben ob das dann mit einem Standard IO von IP-Symcon und einem passenden Splitter zu lösen ist oder ob Du in der Tat einen eigenen IO für den Zweck anbieten müstest.
Das meiste ist tatsächlich in IPS verfügbar, vielen Dank an dieser Stelle an alle die fleißig den Module-Store füllen. Für mich ist allerdings wichtig, dass, falls eine solche Situation auftritt, ich damit umgehen kann und die Schnittstelle einfach nachrüste.
Als Use-Case könnte man allerdings zum Beispiel das Auslesen und Reagieren auf Daten aus einer named pipe, unter der Voraussetzung das IPS auf einem Linux-System läuft, annehmen. Wie würde man einen solches IO Modul aufsetzen?
Ich habe letzte Woche schon einmal nach Projekten gesucht, welche einen eigenen IO implementieren. Nach längerer Suche fand ich ein Projekt von @paresy in welchem ein eigener IO definiert wurde. So ganz schlau werde ich daraus allerdings nicht. Keiner der Clients implementiert SendDataToChildren oder ForwardData. Ohne dass ich mich mit Netatmo auskenne, würde ich doch erwarten diese Funktionen wiederzufinden. Wie kann sonst ein Datenfluss realisiert werden?
Im Wesentlichen verstehe ich nicht, wie ich Asynchronität in das IO Modul bekomme. Einen eigenen Thread zu erstellen ist (aus sinnvollen Gründen) nicht erlaubt.
Du kannst leider nur schwer „dauerhafte“ PHP Skripte am Laufen haben. Deswegen sind I/Os, welche hardwarenah sind, eher schwieriger zu erstellen. Oder du musst diese Pollen, was wiederum ineffizient ist.
Bei den Named Pipes hast du genau das Problem. Du kannst die Pipe zwar erstellen, aber am Ende wird das Skript irgendwann Beendet und somit auch die Pipe. Ich würde somit eher sagen, dass dein Vorhaben sehr schwer bzw. unmöglich zu realisieren ist, wenn es performant sein soll.
In diesem Fall würde es Sinn ergeben, dass du deinen Use-Case gut erklärst und wir ggf. einen performanten I/O dafür erstellen.
Eine Alternative statt einer named pipe wäre ein TCP oder UDP Socket zu verwenden. Dafür gibt es schon IO Module incl. vieler Bespiele.
Wenn es ein Gerät gibt,das das nicht kann bietet es sich an ein Programm zu schreiben, was die IO Funktionalität kapselt und auf der anderen Seite eine von IPS unterstütze Schnittstelle besitzt. So mache ich es z.B. mit dem TE923 Modul, was HID auf HTTP mappt.
Hallo tommi, danke für deinen Tipp. Ja, man könnte für jegliche Hardware mit beliebiger Programmiersprache einen externen Adapter basteln, eine IPS-interne Lösung hätte ich allerdings natürlich vorgezogen, daher der Thread…
Sicher, ich hätte auch gerne die Möglichkeiten der alten Delphi-DLLs wieder zuück. Da hatte ich auch I2C Devices angebunden. Gibt es aber nicht mehr und auch nicht jeder hat Linux als Basis für IPS.
Im Prinzip haben wir ein Native SDK - der Aufwand dies zu Nutzen ist aber echt hoch und am Ende wirst du kaum in der Lage sein für alle von IP-Symcon unterstützen Plattformen dies zu kompilieren. (Was wieder doof ist, weil jemand sich auf dein Modul freut und es dann aber nicht nutzbar wäre)
Deswegen haben wir dort noch nichts veröffentlich Wir hatten schon überlegt, ob man native Module über unsere eigene CI Struktur kompiliert wird (das würde das oben genannte Problem lösen), aber der Aufwand das bereitzustellen und zu pflegen ist ebenfalls recht hoch.
Die Native SDK fände ich sehr interessant, im Zweifel auch in einem „only if you know what you’re doing“-Zustand.
Hinsichtlich einer gewerblichen Nutzung von IPS spielt die Plattformunabhängigkeit eine kleinere Rolle, da A) die Verwaltung der Infrastruktur nicht den Endnutzern obliegt, und B) man in einem solchen Rahmen IPS in die ggf. bestehende Infrastruktur integriert. Es kann hierbei auch durchaus sein, das IPS auf eigenentwickelter Hardware läuft, und somit Plattformunabhängigkeit so oder so „für die Katz“ wäre.
Eure CI für die Kompilierung und ggf. Tests zu nutzen halte ich auch für einen zu großen Aufwand. Dafür ist der Edge-Case vermutlich zu selten relevant.
Falls du da einen expliziten Bedarf für größere gewerbliche Projekte hast, meld dich mal bei uns über die Kontaktseite. Dann können wir Projektbezogen eine gute Lösung ausarbeiten und dir ggf. Zugriff/Ressourcen für ein natives SDK liefern.
Wir hatten schon überlegt, ob man native Module über unsere eigene CI Struktur kompiliert wird (das würde das oben genannte Problem lösen), aber der Aufwand das bereitzustellen und zu pflegen ist ebenfalls recht hoch.