Ich schau mal, ob ich das Fake-Type-Hinting auch in das PHP Strorm include bekommen. Dann müsste PHPStorm ruhe geben 
Geht leider nicht. PHPStorm frisst das nicht… Du kannst auf PHP7.x umstellen… Aber ggf. kannst du dann schneller 5.6 inkompatiblen Code bauen.
paresy
Ist bei NetBeans ähnlich.
Bevor es PHP 7 Unterstützung enthielt, funktionierten die Typen aus der __ipsmodule.php
Jetzt muss ich das Projekt auch mit PHP 7 erstellen, allerdings habe ich es noch nicht geschafft inkompatiblen Code zu bauen 
Michael
Probiert bitte mal aus, ob in der aktuellen Version im „test“ Branch die Fehler noch auftreten.
Außerdem habe ich noch ein weiteres Problem:
Ich erzeuge drei Variablenprofile:
Bei den booleschen Statusvariablen der PatamiFramework Instanz werden diese verwendet, und es wird auch der korrekte Text angezeigt. Die Farben der IC und NC Profile greifen jedoch nicht.
Was mache ich falsch?
Konntest Du Dir meine Antwort schon anschauen?
Bei Fonzo tritt das Problem wohl immer noch auf, ich habe nach wie vor keine Fehler im Log, wobei ich die von euch gemeldeten Probleme gefixed habe.
Bzw. was ich im Log habe, ist sowas wie:
01:12:03 | 48237 | ERROR | InstanceManager | <br />
<b>Warning</b>: InstanceInterface is not available in <b>C:\IP-Symcon\modules\ipspatami\Alexa Custom Skill Intent\module.php</b> on line <b>510</b><br />
<br />
<b>Warning</b>: InstanceInterface is not available in <b>C:\IP-Symcon\modules\ipspatami\Alexa Custom Skill Intent\module.php</b> on line <b>522</b><br />
Nach einigem Experimentieren scheint das daher zu kommen, dass in ApplyChanges (oder auch GetConfigurationForm, aber das habe ich nicht verifiziert) Properties ausgelesen werden, und das beim Start (noch) nicht funktioniert. Ähnliche Meldungen werden aber auch von Modulen anderer protokolliert.
Ich bekomme die Meldungen weg, indem ich bei ApplyChanges prüfe, ob der Kernel READY ist, und wenn nicht, abbreche, aber das ist aus meiner Sicht auch nicht sinnvoll, denn dann werden nach einem Reboot meine Messages nicht registriert und so.
Ich bin sicher, das kann kein großes Issue sein bei meiner Library, aber so ganz ohne Logs wird’s echt schwer… :-/
Eigentlich passiert das nur wenn du andere Instanzen versuchst anzusprechen.
Man kann auch RegisterMessage ganz am Anfang vom ApplyChanges einbauen und dann die Abfrage ob KRReady
Dein Datenaustausch in dem Framework ist leider auch nicht zu gebrauchen, da du immer als Index Buffer nutzt. Jedoch ist außer DataID alles andere immer unterschiedlich, je nach Interface zwischen den Instanzen.
Michael
Bahnhof. Was genau meinst Du?
Dein SendEncodedDataToChildren und SendEncodedDataToParent akzeptieren als $data mixed, aber in GetEncodedData wird immer nur ‚Buffer‘ unterstützt:
return json_encode(array(
'DataID' => $dataId,
'Buffer' => $data
));
Aber es kann anstatt Buffer auch ganz andere und mehr Felder geben.
Beispiel HM:
"Protocol" => 0,
"MethodName" => "listBidcosInterfaces",
"WaitTime" => 5000,
"Data" => $data
Oder der ServerSocket:
"ClientPort" => (int) $this->LastPort,
"ClientIP" => $this->ReadPropertyString('ClientIP'),
"Buffer" => $data
Michael
@patami: Die Fehlermeldungen kommen aus der Funktion HasCustomIntentName und GetIntentName. Wer ruft die auf? Die Instanz selber kann es ja nicht sein, da die noch nicht initialisiert ist? Rufst du die Funktionen von extern auf? Wenn ja, darf dies erst passieren sobald der Kernel Runlevel KR_READY ist. Erst dann sind alle Instanzen verfügbar. Du kannst dich per RegisterMessage auf IPS_KERNELSTARTED registrieren, falls du das ganze „sofort“ nach dem Start machen musst.
paresy
Danke, gut zu wissen.
Ist das irgendwo dokumentiert für die mitgelieferten Instanzen?
Aber es ist ja kein Problem, das allgemeiner zu fassen im Framework.
Danke, ich schau’s mir an.
Nein, zumal die Interfaces von PHP-Modulen ja auch ‚meistens‘ nicht dokumentiert sind.
Ich dokumentiere sie auch nur dann, wenn es für andere Entwickler sinnvoll ist sich hinter mein Modul zu hängen.
z.B: GitHub - Nall-chan/IPSWebSockets: WebSocket Protocol for IP-Symcon
Michael
Danke, ich dachte fälschlicherweise, dass es immer „Buffer“ ist.
Aber das ist ja schnell angepasst.
Issue schon offen.
Grund war, dass das Modul in seinem ApplyChanges() die anderen Instanzen mit demselben Parent prüft, ob diese ggf. denselben IntentName haben. Den Part habe ich jetzt mit einer Prüfung auf den Kernel Run Level rausgenommen.
Außerdem haben die WebHook- und WebOAuth Basisklassen noch WebHooks und OAuth-Endpunkte registriert beim Startvorgang, und da sind die WebOAuth und WebHook Instanzen ja auch noch nicht soweit. Fixed.
Hat noch jemand Fehler?
Hm, noch was: Prinzipiell laufe ich in das Problem mit dem Prüfen der IntentName Eigentschaft der Schwesterinstanzen des Alexa Custom Skill Intents ja auch dann rein, wenn ich mein Modul aktualisiere. Zumindest kommen dann auch dieselben Fehlermeldungen… ist das an der Stelle auch problematisch?
@paresy: Hast Du eine Idee, wieso ich die Fehlermeldungen teilweise nicht sehe? Oder ist dies evtl. komplett Random und hängt von der (zufälligen?) Ladereihenfolge der anderen Module ab?
Ich habe die Basisklasse nun geändert, sodass sie beliebige Datenstrukturen akzeptiert. Die Gira HomeServer Module leiten die Methoden ab, um aus einem String die Datenstruktur mit „Buffer“ zu machen.
Das kann sehr gut sein, dass bei dir zufällig die Instanz erst nach den Instanzen erstellt werden, welche du ansprichst. Somit kann es auch sehr gut sein, dass bei dir keinerlei Fehlermeldungen auftreten.
Das mit dem Modulupdate hast du richtig erkannt. Da habe ich gar nicht daran gedacht, dass du zu dem Zeitpunkt ja auch den Runlevel KR_READY hast, aber deine Instanzen (da diese auch aktualisiert werden) ggf. nicht verfügbar sein müssen. Du könntest jedoch alternativ (wodurch du beide Probleme abfangen können solltest) direkt auf IPS_GetInstance($id)[‚InstanceStatus‘] != 201 (IS_NOTCREATED) überprüfen.
paresy
Danke.
Leider scheint das nicht zu tun:
Es werden zwei Instanzen nacheinander geladen.
In beiden Instanzen läuft eine Schleife über alle Instanzen.
Wie Du sehen kannst, tritt bei der ersten das Warning auf, bei der zweiten nicht.
Der Status ist aber immer 102.
Ergänzung: Beim Neustart ist der Status 201, also da tut es.
Wie löse ich das beim Update?
@paresy: Hast Du eine Idee?
Ich denke, dass alle Probleme beim Neustart nun gelöst sind.
Führen die Issues beim Update eigentlich auch potenziell dazu, dass die betroffenen Instanzen „leer“ sind?
