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:
PatamiFramework.YesNo (Wahr = Ja und Grün, Falsch = Nein und Rot)
PatamiFramework.YesNo.IC (Wahr = Ja und Rot, Falsch = Nein und Grün)
PatamiFramework.YesNo.NC (Wahr = Ja, Falsch = Nein, keine Farben)
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
@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.
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.
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
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.
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.
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.
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?