Und genau deshalb gibt es auch einen Splitter, weil Du das gefragt hattest. Public Funktionen sind nämlich auch vom User in der Console aufrufbar, was nicht ideal ist das musst Du dann zumindest mit Exceptions abfangen, außerdem sollten solche Funktion an sich nicht für den Nutzer sichtbar sein. Aber dafür ist wie gesagt der Datenaustausch da. In sofern ist das HUE Modul von traxanos, auch wenn dies super funktioniert, vielleicht nicht das passende Beispiel für den Datenaustausch in IP-Symcon, da würde ich eher mal in Module von nall chan schauen der macht das sauber über den Datenaustausch.
Das mit dem Datenfluss hab ich immer noch nicht so verstanden … und ich hab beruflich schon ne Menge an Kommunikationstreibern geschrieben.
In meinem Modul wird durch einen Timer zyklisch die Methode HP_SyncStates($bridgeId) aufgerufen.
Dieses SyncStates macht eine allgemeine Datenanfrage an den Homepiloten, der dann mit einem Array von Objekten Antwortet. Pro Aktor/Sensor ein Objekt.
Die Methode SyncStates sucht dann für jedes Objekt eine Symcon Instanz und übergibt wenn gefunden das Objekt an die Instanz via HP_ApplyData/HPSensor_ApplyData. Die kümmert sich dann um die Zuordnung an die einzelnen Variablen.
Aber was ist mit der Deklaration der RequestAction Methode??
Wieso in der doku erst mit string deklariert und dann im Beispiel ohne? Das ist doch nicht stringent oder?
Schau Dir doch mal meine Beta Vorlage an da ist alles drinnen auch ein Splitter das kannst Du 1:1 übernehmen. Kopierst Dir einfach die module.json mit den GUIDs und die Funktionen innerhalb der Instanzen. Dann hast Du schon einen funktionieren Datenfluss ohne public Funktionen. Aktualisierung hatte ich nicht drinnen aber da kann man ja selber ein Event anlegen bzw. Du legst vom Modul eins an.
Die Funktion SyncStates bekommt die Daten -> Weiterleitung an den Splitter. Der macht gegeben falls noch was mit den Daten und reicht diese dann an die Instanz. Diese nimmt die dann mit
public function ReceiveData($JSONString)
entgegen und dann kannst Du in der Instanz die Daten abspeichern.
Da gebe ich Dir recht das kann aber wohl nur Paresy beantworten.
Na ja … die Bridge bekommt die Daten als JSON Antwort. Die muss überprüft und dekodiert werden bevor sie an Splitter/Instanzen weitergereicht werden kann.
D.h. ich müsste das dekodierte Objekt wieder in JSON wandeln an den Splitter weiterreichen der es dann wieder decodiert …
Klingt für mich nach unnötiger Verschwendung von Performance.
Ich könnte die ApplyData Funktion auch in die Bridge verlagern und dann für den Zugriff auf die Instanzen nur auf öffentliche Funktionen zurückgreifen.
Ich werde mal sehen wie ich das public / protected Problem in den Griff bekomme. In C++ wäre das alles kein problem 
Ja das mag sein aber so wäre es sauber. Und Du gibst ja nur das als JSON weiter was Du auch brauchst den Rest kannst Du gleich verwerfen. Auf der anderen Seite verweist Du ja auch auf die Dokumentation. Außerdem kannst Du dann auch die weiteren dokumentierten Funktionen nutzten wie
senddebug
damit ist es dann sowohl Dir als auch dem Nutzer möglich so wie in IP-Symcon vorgesehen im Debug Fenster den Datenfluss zu verfolgen und zu sehen was eigentlich genau passiert.
Ich könnte meinen Instanzen z.B. ein public Member spendieren (da hat ja kein Anwender über Befehl testen Zugriff drauf) über den ich von der Bridge aus die zu Verarbeitenden Daten hinterlege bevor ich dann ExtApplyData ohne Parameter aufrufe. Das ExtApplyData könnte dann eine nun protected ApplyData Methode mit Übergabepointer aufrufen. Nach dem Verarbeiten kann ich das Member dann wieder auf nullptr setzen. Ein Aufruf durch den Benutzer würde dann einfach ins leere Laufen da das zu verarbeitende Objekt ja null ist.
Gute Idee?
Ich glaube das ist keine gute Idee… ist halt kein C++
Aber ein Splitter verkompliziert in meinen Augen das ganze Handling der Daten.
Als Kompromiss könnte ich $data in der Bridge in einen string wandeln und in der Instanz wieder zurückwandeln.
Das macht meinen Code nicht komplizierter und IP-Symcon ist glücklich
Du verschwedest aber selber viel mehr, weil du das hier machst:
Beim Datenaustausch kümmert sich IPS um die Weitergabe der Daten an die Korrekten Instanzen.
Vorausgesetzt man setzt einen ReceiveFilter ist IPS zig mal schneller als du in PHP
Ich nutzt z.B. bei dem HMExtended-Modul einen Splitter welcher ebenfalls per Timer Daten holt.
Das JSON enthält ebenfalls mehrere Geräte und wird somit einmal pro Geräte aufgeteilt.
Das ganze dann einfach mit SendDataToChildren weitersenden und fertig.
Die Geräte-Instanzen setzten einen Filter (SetReceiveDataFilter) und erhalten somit automatisch nur Ihre Daten in der Methode ReceiveData.
Schau es dir einfach mal an, es ist einfacher und übersichtlicher als man glaubt 
Michael
Quelle: IPSHomematicExtended/module.php at master · Nall-chan/IPSHomematicExtended · GitHub
Splitter:
$Result = $this->GetInterfaces(); // Liefert ein Objekt stdClass
foreach ($Result as $ProtocolID => $Protocol)
{
if (!is_array($Protocol)) // Skip empty Protocol
continue;
foreach ($Protocol as $InterfaceIndex => $Interface)
{
$this->SendDebug("Proto" . $ProtocolID . " If" . $InterfaceIndex, $Interface, 0);
$Interface->DataID = "{E2966A08-BCE1-4E76-8C4B-7E0136244E1B}";
$Data = json_encode($Interface);
$this->SendDataToChildren($Data);
}
}
IPSHomematicExtended/module.php at master · Nall-chan/IPSHomematicExtended · GitHub
Device
public function ApplyChanges()
{
parent::ApplyChanges();
$Address = $this->ReadPropertyString("Address");
$this->SetSummary($Address);
if ($Address !== "")
$this->SetReceiveDataFilter('.*"ADDRESS":"' . $Address . '".*'); // Set filter for ReceiveData
else
$this->SetReceiveDataFilter(".*9999999999.*"); // bail out all data
}
public function ReceiveData($JSONString)
{
$Data = json_decode($JSONString);
unset($Data->DataID);
unset($Data->ADDRESS);
$this->SendDebug('Receive', $Data, 0);
foreach ($Data as $Ident => $Value)
{
if ($Value === "") // skip empty value
continue;
$Profil = "";
if ($Ident == "DUTY_CYCLE")
$Profil = "~Intensity.100";
switch (gettype($Value))
{
case "boolean":
$Typ = vtBoolean;
break;
case "integer":
$Typ = vtInteger;
break;
case "double":
case "float":
$Typ = vtFloat;
break;
case "string":
$Typ = vtString;
break;
default:
continue; // skip child objects
}
$vid = @$this->GetIDForIdent($Ident);
if ($vid === false)
{
$this->MaintainVariable($Ident, $Ident, $Typ, $Profil, 0, true);
$vid = @$this->GetIDForIdent($Ident);
}
SetValue($vid, $Value);
}
}
Was ist den die ‚Bridge‘ aktuell für ein Typ von Instanz, ein IO ?
Ist ja egal, der kann genauso funktionieren. Völlig egal ob Splitter oder IO.
Zusätzlich brauchst du eigentlich keinen.
Außer du hängst noch unter einem echten IO bestehend aus z.B. ClientSocket oder SerialPort. Dann wäre dein Typ von Instanz auf jedenfall Splitter.
Michael
Hab jetzt erstmal die ApplyData Funktion auf JSON String umgestellt.
Damit ist IP-Symcon glücklich - und ich auch
Und alles funktioniert so reibungslos wie bisher!
Was anderes - Ich bekomme beim Aktualisieren meines Moduls via git manchmal die Warnmeldung InstanzCount >1 …
Was hat das zu bedeuten?
Es ist ein I/O Modul.
Damit das mit der Übergabe noch klarer ist habe ich die public function nun HP_ApplyJsonData umbenannt. Damit sollte sich die Art der übergabe besser selbst erklären.
Ausserdem habe ich die README.md noch mal angepasst und um die Methoden für HPSensor_… ergänzt.
Ich denke damit könnte das Modul nun in die Liste der verfügbaren Module von IP-Symcon aufgenommen werden.
Ich habe übrigens beim Aktualisieren des Moduls wieder folgende Fehlemeldung im Log gesehen:
05.03.2017 16:48:02*| InstanceManager*| Referenzzähler >1 (=2) für Instanz #58520
Kann man da was gegen unternehmen oder muss man das so tolerieren?
Da Du das Gerät ja besitzt hast Du eine Möglichkeit gefunden eventuell einen Socket zu nutzten oder geht eine Abfrage und Aktualisierung der Daten immer nur per Pull und Curl?
Da es keine offene Schnittstelle des Homepiloten gibt nutze ich mit dem IP-Symcon Modul die JSON Kommunikation die auch durch die Webseite des Homepiloten selber genutzt wird.
Also immer nur per Pull und Curl.
Hallo,
ich habe auf das neue Modul gewechselt, weil ich mit diesem Modul auch die aktuelle Position des Rollos auslesen kann - klasse arbeit 
Im Objektbaum werden mir die Rollmotoren aber als Schalter erkannt. Die Gurtwickler und der RolloTron Comfort werden einwandfrei erkannt und alle notwendigen Variablen aufgelistet (Zustand, Position, etc.).
Was muss ich tun, damit die Rollmotoren auch richtig erkannt werden?
Herzlichen Dank,
Klaus
Hallo Klaus,
Es freut mich das dir mein Modul gefällt. Da ich selber keine Rollmotoren im Einsatz habe konnte ich die Steuerung bisher nicht testen.
Ich denke aber das ich die notwendigen Änderungen hinbekomme. Eventuell benötigte ich noch ein paar Infos von dir.
Da ich derzeit aber im Urlaub bin kann ich mich frühesten ab 27.04 darum kümmern.
Lassen sich die Rollmotoren den zumindest auf/zu fahren?
Grüße von Fuerteventura
Hallo Urlauber,
vielen Dank für die Rückmeldung. Mach erst einmal Urlaub und ich helfe dann gerne bei Rückfragen weiter! Ich habe auch noch das „Vorgänger-Modul“ im Einsatz. Mit diesem Modul fahre ich den Rollmotor rauf und runter. Leider nicht mit Deinem Modul, weil dies ja nur einen Schalter für den Rollmotor bereit stellt.
Noch eine schöne Zeit,
klaus
Hallo Klaus,
ich habe gestern auf IP-Symcon 4.2 aktualisiert und musste direkt einen Fehler korrigieren der dazu geführt hatte, das die zyklische Abfrage der Werte nicht funktionierte. Des Weiteren habe ich eine Logmeldung eingebaut die bei einem unbekannten Typ zu einer Logmeldung führt.
Für die Unterstützung der Rollmotoren brauche ich die genaue Bezeichnung (Mit groß/klein Schreibung) die in der Instanz unter Knotentyp für die Rollmotoren eingetragen wurde.
Das müsste auch die Bezeichnung sein die nun in den Meldungen als unbekannter Typ ausgegeben wird.
Hallo,
wenn ich http://homepilotip/deviceajax.do?devices=1
im Browser eingebe, bekomme ich die Liste. Der Rohrmotor ist eingetragen als
productName „Rohrmotor“
Ksaus
Hallo Klaus,
habe den Typ „Rohrmotor“ erstmal so wie Rohrmotoraktor eingebaut.
Bitte das Modul aktualisieren, ggf. die bereits angelegte Instanz löschen und Knoten bei synchronisieren.
Dann wüsste ich gerne ob der „Rohrmotor“ sich genauso verhält wie ein Rollotron Gurtwickler.
Also Position hoch/runter/stop und via Slider Ansteuerung beliebiger Positionen.
Bruno