ich versuche jetzt seit gestern das Grundgerüst mit wenig Inhalt für ein neues Modul zum Laufen zu bringen. Wenn ich das Gerät anlege erhalte ich aber eine Fehlermeldung aus der ich aber nicht schlau werde und auch nichts zu finde.
Ok…wo liegt mein Fehler? Es ist bestimmt nur eine Kleinigkeit
…der Name (bei Dir „name“: „Wolf-Smartset“) in der module.json und der Funktion-Aufruf in der module.php Zeile 3 (bei Dir class WolfSmartset extends IPSModule ) stimmen nicht überein…
Chr(255) steht ja außerhalb vom decode, was aber ein encode sein muss.
Du musst schon alle Bytes (also den ganzen String) vorher behandeln, weil json_encode braucht utf8.
Michael
noch mal eine Frage:
Wie bekomme ich am saubersten im Splitter mit, wenn die übergeordnete Instanz - hier ein Client Socket - einen Fehler hat (z.B. weil die Verbindung unterbrochen ist)?
In der 4.1 geht das dann ja vielleicht über die neue Funktion der Nachrichten, aber in der 4.0?
In der 4.0 nur wenn du sendest, ich meine dann gibt es einen Fehler.
Darum stelle ich alles auf 4.1 um, weil dort endlich mit MessageSink diese Möglichkeit gegeben ist.
Auch bekommt man dann mit ob der Kernel gerade hochgefahren ist und du deinen IO initialisieren kannst, die Verbindung zum IO getrennt wurde oder der IO in Fehler geht.
Michael
zu meinem Verständnis (und weil ich im Detail noch ein paar Verbesserungen erreichen möchte), welche der im Modul erstellten Funktionen (__Construct, Create, ApplyChanges, Destroy…) werden in welcher Reihenfolge durchlaufen?
beim Erstellen der Instanz
beim Start von IPS
beim Beenden von IPS
Hintergrund: In meinem Modul läuft im „Normalbetrieb“ alles gut, nach dem Start benötige ich (zumindest manchmal) noch einen „Anschupser“…
Vielleicht kann man das auch mal als Information in der Dokumentation hinterlegen, die Texte selbst sind für einen Anfänger da noch sehr „interpretationsfähig“…
__construct gar nicht nutzen, Da es immer aufgerufen wird und du zu dem Zeitpunkt nicht weißt in welchen Zustand IPS oder deine Instanz ist.
Create wird sowohl beim starten von IPS als auch beim erstellen einer Instanz im laufenden Betrieb aufgerufen.
Appylchanges unmittelbar nach create sowie wenn die Config manuell übernommen wird.
Vermutlich braucht dein Modul ein Anschups, weil IPS noch nicht komplett hochgefahren ist, wenn es das erste mal Appylchanges ausführt.
Zu dem Zeitpunkt sind noch nicht alle Funktionen in IPS verfügbar (schau mal in das Log).
Beste Lösung ist auf 4.1 umzusteigen und dort sich auf die Kernelmessage zu registrieren.
Dann führt IPS beim wecken der Nachrichtenschlange (=IPS ist hochgefahren und wechselt in den Normalbetrieb) die Funktion MessageSink aus deinem Modul aus und du kannst dann z. B. noch mal selbst ein Appylchanges ausführen.
Bei Runterfahren ist es aktuell so, dass hier nichts funktioniert… weil ab dem Zeitpunkt IPS keine Scripte und somit auch keine PHP-Module mehr ausführt.
Eigentlich sollte dann aber Destroy aufgerufen werden. Sowohl beim Shutdown, als auch wenn die Instanz gelöscht wird.
Michael
Die „__construct“-Funktion soll ich überall löschen? Wofür ist (oder war) die denn eigentlich gedacht?
Die Destroy-Funktion würde dann so aussehen?
// Überschreibt die interne IPS_Destroy($id) Funktion
public function Destroy() {
// Diese Zeile nicht löschen.
parent::Destroy();
$this->SendDataToParent(json_encode(Array("DataID"=> "{A0DAAF26-4A2D-4350-963E-CC02E74BD414}", "Function" => "i2c_destroy", "DeviceAddress" => $this->ReadPropertyInteger("DeviceAddress"))));
}
(unabhängig von meiner Zeile „Privat-Code“)
Mit dem Upgrade auf 4.1 habe ich auch schon geliebäugelt, weiß aber immer nicht so genau, wie viele User dem so folgen würden solange die noch nicht „Stable“ ist…
__construct ist der Konstruktor den PHP jedesmal aufruft wenn aus deiner Klasse eine Instanz erzeugt wird.
Das passiert immer wenn IPS irgendwas mit deiner Instanz machen möchte.
Destroy kannst du so nutzen, Aber wie gesagt beim Shutdown wirft IPS dort Fehler und führt den Code aktuell nicht aus.
(Ich sollte mal die Bug-Liste pflegen… Ups )
Michael