Dann noch eine Frage die mir gerade aufgefallen ist, kann ich für mein HUEDevice ein Profil und eine Aktion im Modul definieren? Weil ohne die beiden Sachen brauche ich erstmal gar nicht weiter machen.
Ja, schau dir mal das Sonos Modul aus meinem Repo an. Dort hast du auch ein Beispiel wie du es zwischenzeitlich mit den Timern bauen kannst.
paresy
ok danke für den tipp. leider doch noch eine frage.
wie kann ich eine übergeordnete instanze auswählen wie bei den Homatics
Hab jetzt HUEBridge und möchte nun HUEDevice mit Referenz zur HUEBridge. Muss ich das selber umsetzen oder gibt es hier einen Trick. Hatte gehofft das passiert per „parentRequirements“ und „childRequirements“ automatisch.
Schau mal hier: SymconTest/module.php at master · paresy/SymconTest · GitHub
Das ConnectParent kümmert sich um das Erstellen der Verbindung. Die implemented/required Sachen sind dafür wichtig, damit IP-Symcon weiß, dass die Module kompatibel sind. Automatisch erstellen tut IP-Symcon aber nicht, da es unter Umständen mehrere Möglichkeiten geben kann 
paresy
Sieht gut aus. Die Verküpfung kann angelegt werden.
Allerdings bekomme ich probleme sobald ich das ConnectParent verwende:
Modul mit der GUID **** nicht gefunden. Ich vermute ich muss bei bauen der Childs einen Parent an die Childs mitgeben. Wie kann ich einem Child, beim anlegen einen einen Parent mitgeben?
Stimmen die GUIDs denn? Du musst als GUID die ModuleID von deinem Parent nehmen.
paresy
Ich vermute ja, ich ich bei manueller Anlage alles geht.
Wobei mit der ModulID es nicht geklappt hat. Ich musste für beide Module eine extra GUID bauen und als Implemented eintragen und referenzieren.
{
"id": "{F6F3A773-F685-4FD2-805E-83FD99407EE8}",
"name": "HUEBridge",
"type": 1,
"vendor": "Philips Hue",
"aliases": [ "Philips Hue Bridge" ],
"parentRequirements": [],
"childRequirements": [ "{0046C3E1-28E6-40CF-9358-4C992F58F9EE}" ],
"implemented": [ "{D792637E-79F8-4EB0-ABC4-A641C2F4CC3B}" ],
"prefix": "HUEE"
}
und
{
"id": "{729BE8EB-6624-4C6B-B9E5-6E09482A3E36}",
"name": "HUEDevice",
"type": 3,
"vendor": "Philips Hue",
"aliases": [ "Philips Hue Device" ],
"parentRequirements": [ "{D792637E-79F8-4EB0-ABC4-A641C2F4CC3B}" ],
"childRequirements": [],
"implemented": [ "{0046C3E1-28E6-40CF-9358-4C992F58F9EE}" ],
"prefix": "HUEE"
}
$this->ConnectParent("{D792637E-79F8-4EB0-ABC4-A641C2F4CC3B}");
//$this->RequireParent("{D792637E-79F8-4EB0-ABC4-A641C2F4CC3B}"); wofür usr ist RequireParent?
So müsste es im Device klappen, dass er eine Bridge bei Bedarf erstellt.
$this->ConnectParent("{F6F3A773-F685-4FD2-805E-83FD99407EE8}");
ConnectParent = Wenn noch nicht verbunden -> Verbinde, falls kompatible Instanz verfügbar, sonst erstelle neu (meisten bei Device für Splitter)
RequireParent = Wenn noch nicht verbunden -> Erstelle eine neue kompatible Instanz, egal ob eine verfügbar wäre (meisten bei Splitter für IO)
ForceParent = Erstelle neu Instanz, wenn keine verbunden, oder nicht genau diese GUID verbunden ist (meisten bei Splitter mit expliziter IO Auswahl)
paresy
Danke teste ich nachher.
Wie kann ich aber beim Anlegen einen korrekten Parent mit zuweisen. Die Lampen werden von der Bridge über einen Button angelegt. Das geht auch schon, aber ich möchte natürlich die ID der Bridge mitgeben, da ich ja mehrere Bridges haben könnte.
Es gibt GUIDs für die verschiedenen Module und dann noch welche für die Interfaces.
Du musst da aufpassen, dass du dich dort nicht verhaust.
Der Grund ist der dass verschiedene Module ja das gleiche Interface nutzen können.
Das sind die GUIDs welche du in den JSON Objekt als DataID nutzt.
Ich habe da mal was zusammen geschrieben. Muss nicht 100% sein, könnte aber helfen.
http://blog.nall-chan.net/ips/PHP-Module.txt
Michael
Am besten anders herum.
Du fragst im ‚Parent‘ also dem IO die Bridge ab.
Dann holst du dir alle Childs und prüfst ob die Lampe schon existiert, sonst wird eine neue Instanz erzeugt.
Schau die mal mein SqueezeBoxModul an , dort macht das der LMS genauso 
IPSSqueezeBox/module.php at master · Nall-chan/IPSSqueezeBox · GitHub
Zeile 144
Michael
Verstehe ich nicht.
Also ich habe Bridge 1 und Bridge 2. Auf Bridge 2 sage ich nun „Gleiche alle Lampen ab“. Der fragt also alle Lampen ab und iteriert diese. Jetzt schaut er nach, ob es die Lampe schon gibt und legt diese ggf an. (Soweit geht schon alles) Jetzt muss ich doch der Lampe sagen, dass Sie zu Bridge 2 gehört und dass kann ich doch nur von der Bridge aus!
Wenn ich es anders herum machen, wie weis die Lampe zu welcher Bridge sie gehört. Soll ich jetzt jede Bridge iterieren und schauen ob diese Lampe hier vorhanden ist? Das ergibt doch keinen Sinn und verursacht viel zu viele unnötige Abfragen auf der Bridge?
Zeile 161 bis 165 prüfe ich ob der Parent der neu angelegten Instanz korrekt ist.
Neu zuordnen mit IPS_ConnectInstance.
Die Lampe (Child) muss nicht wissen welche Bridge sie hat.
Einfach die Daten mit SendDataToParent übergeben. IPS nimmt dann schon das übergeordnete Parent.
Michael
Also doch so wie vor hatte. Und der Befehl ist also IPS_ConnectInstance zum Zuweisen. Danke dir.
EDIT:
Geht auch einwandfrei wie erhofft.
Hab die Skripte heute Mittag mal getestet auf einem System.
Funktionieren mit 4 verschieden Lampenarten!
Wofür ist der Statusabgleich gedacht ?
Falls jemand die Leuchten anders als mit dem Script ändert ?
Ja , wenn die zB. Aus sind über Taster und Co ändert sich die Variable erreichbar oder jemand nutzt parallel die App, dann gleicht es sich so ab
OK, also richtig gedacht
So ich habe nun die erste Version als Modul fertig. Hoffe sind kein als zu großen Fehler drinne, sonst war es meine Erkältung Schuld 
Huhu bin gerade über dein Brand neues Modul gestolpert, Glückwunsch.
Eine Frage, woher bekomme ich die im Modul notwendige Unique ID ?