Ich nutze einen Buffer zum Hochzählen einer Message-ID. Beim IPS Shutdown muss ich den Stand in eine Property sichern, damit ich beim Neustart nicht wieder bei Null anfange. Dazu hatte ich die Message KR_UNINIT registriert. Scheinbar wird die Message aber nicht verschickt, so das der letzte Stand nach dem Neustart nicht zur Verfügung steht.
Was ist der vorgesehene Weg innerhalb eines Moduls den Buffer zu sichern? Ich wollte eigentlich nicht permanent jede einzelne Änderung in die Property schreiben und auch nichts in ein zentrales Shutdown-Script frickeln.
Du kannst dich nicht direkt auf UNINIT registrieren, sondern nur global auf KERNELMESSAGE
Siehe ähnliche Frage von dir und meine Antwort von hier: Fragen zu RegisterMessage und MessageSink
Grundsätzlich funktioniert dies auch, aber leider kann IPS, wenn der Shutdown eingeleitet wird, keine Scripte und somit auch keine Methoden der PHP-Module mehr aufrufen
Also aktuell keine funktionierende Lösung, leider.
Nehme jetzt eine Variable. finde ich zwar doof, geht aber.
BTW: Stehe gerade auf dem Schlauch: wie verhindere ich einen Loop, wenn ich innerhalb von ApplyChanges eine Funktion verwenden muss die eine Property ändert und die dann natürlich seinerseits mit ApplyChanges festschreiben will.
Ich reisse das Zitat mal aus dem Zusammenhang, weil man das m.E. nicht so generell sagen kann:
Im Modul Event Control, das bei V3.4 zu den Kern Instanzen gehört, kann man doch ein „Herunterfahr-Skript“ definieren.
Ich habe dort jede Menge Skript-Aufrufe stehen (z.B. Benachrichtigung vom Raspi an den Hauptserver per JSON), die auch regelmäßig durchkommen, wenn z.B. Linux einen Shutdown einleitet.
Wenn ich unter Windows „den Dienst beenden“ will, hab ich eher das Problem. dass ich IPS irgendwann über den Windows Task-Manager beenden muß. Liegt bei mir vielleicht daran, dass ich „Langzeit-Skripts“ laufen habe, die sich erst nach einigen Minuten beenden.
Was ich sagen will: m.E. läßt IPS beim Shutdown jede Menge Zeit für noch laufende Skripte.
Ich habe mir da mit einer zweiten Eigenschaft beholfen, diese setzte ich mit, damit ich im nächsten Durchlauf weiß dass dieses ApplyChanges quasi durch sich selbst aufgerufen wurde.
In deinem Fall würde ich aber erstmal auf eine IPS-Variable ausweichen.
Da hast du recht, nur genau das wollt tommi nicht nutzen und hier geht es auch auch primär um die PHP-Module.
Wie die genaue Logik beim Shutdown aussieht weiß nur paresy.
Dass das EventControl das Shutdown-Script noch vor dem finalisieren der ScriptEngine ausführt ist klar (gilt nicht nur für 3.4, sondern auch für 4.x).
Dann müssten eigentlich die Nachrichten an alle Registrierten PHP-Instanzen versendet werden und erst dann die ScriptEngine finalisiert werden.
Leider scheint dies aber aktuell so nicht der Fall zu sein, so dass die PHP-Instanzen gegen die Wand laufen…
14:19:08 | 00000 | WARNING | Kernel | Service Shutdown requested!
14:19:08 | 00000 | MESSAGE | Kernel | Deinitialisiere...
14:19:08 | 00000 | MESSAGE | ScriptEngine | Waiting for all script threads to terminate...
14:19:08 | 00000 | MESSAGE | TimerPool | Waiting for 8 timer threads to finish...
14:19:09 | 00000 | MESSAGE | DataServer | Stoppe Server...
14:19:09 | 00000 | ERROR | KernelMT | InstanzManager: Fehler bei Instanz #45222 , Meldung IPS_KERNELMESSAGE: Scripts können nicht gestartet, sobald Abschaltung eingeleitet wurde
14:19:09 | 00000 | ERROR | KernelMT | InstanzManager: Fehler bei Instanz #31909 , Meldung IPS_KERNELMESSAGE: Scripts können nicht gestartet, sobald Abschaltung eingeleitet wurde
14:19:09 | 00000 | ERROR | KernelMT | InstanzManager: Fehler bei Instanz #46535 , Meldung IPS_KERNELMESSAGE: Scripts können nicht gestartet, sobald Abschaltung eingeleitet wurde
Hätte ich ja selber drauf kommen können… diese Nachrichten sind ja auch im Delphi-SDK vorhanden.
Dort ist aber IPS_KERNELSHUTDOWN = 10001 und 10002 als IPS_KERNELSTARTED gelistet
EDIT: Ein Schnellversuch eben hat noch nicht zum Erfolg geführt, aber eventuell ich ich auch gerade zu müde dafür
Michael
Ich muss mal selber pushen… Jemand noch ein Idee ?
Zumal nicht nur der Shutdown, sondern auch das löschen (Destroy) ordentlich knallt.
IPS versucht dann noch den MessageSink auszuführen (Löschen von untergeordneten Variablen)-> Meldet aber gleichzeitig das die eigene Instanz nicht existiert
Der array_key_exists Fehler kommt daher, dass natürlich auch GetBuffer fehlschlägt.
04.01.2017 21:13:47*| ScriptEngine*| Ergebnis für Text (Länge: 0)
<br />
<b>Warning</b>: Instanz #50224 existiert nicht in <b>C:\IP-Symcon\scripts\__ipsmodule.inc.php</b> on line <b>391</b><br />
<br />
<b>Warning</b>: Instanz #50224 existiert nicht in <b>C:\IP-Symcon\scripts\__ipsmodule.inc.php</b> on line <b>260</b><br />
<br />
<b>Warning</b>: Instanz #50224 existiert nicht in <b>C:\IP-Symcon\scripts\__ipsmodule.inc.php</b> on line <b>373</b><br />
<br />
<b>Warning</b>: array_key_exists() expects parameter 2 to be array, boolean given in <b>C:\IP-Symcon\modules\HomematicExtended\Systemvariablen\module.php</b> on line <b>91</b><br />
Dann kommt auch noch mal der Destroy, welche mit den gleichen Fehler.
foreach Fehler kommt auch durch den fehlerhaften GetBuffer.
04.01.2017 21:13:47*| HMSystemVariable*| <br />
<b>Warning</b>: Instanz #50224 existiert nicht in <b>C:\IP-Symcon\scripts\__ipsmodule.inc.php</b> on line <b>373</b><br />
<br />
<b>Warning</b>: Invalid argument supplied for foreach() in <b>C:\IP-Symcon\modules\HomematicExtended\Systemvariablen\module.php</b> on line <b>60</b><br />
(Und ein rechtsklick auf diese Meldung bringt noch eine Fehlermeldung der Console)
Zugriffsverletzung bei Adresse 009AC5C1 in Modul 'ips_console.exe'. Lesen von Adresse 00000008.
muss das Thema nach oben pushen, nachdem ich es nicht gebacken bekomme.
Ich starte aus einem Modul einen externen Prozess, den ich beim Beenden des Symcon Dienstes wieder beenden möchte bzw es muss, weil sonst Symcon hängen bleibt:
Einen Server Sent Events client direkt in Symcon / PHP zu realisieren ist sicherlich eine nette Herausforderung :D.
Ich habe derzeit leider die Zeit nicht und habe es daher in javascript umgesetzt.