…der Text müsste wohl irgendwie decode/encode werden…
Wenn ich vor dem Aufruf
utf8_decode("dims=".$Value."\xFF\xFF\xFF");
benutze und im Parent
$Command = utf8_encode($data->Command);
wir daraus ein
Command: dims=50???
Muss ich für decode/encode etwas anderes benutzen?
Joachim
Tausch mal encode und decode 
Michael
Hallo Leute,
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 
Gruß
iMaxxx
Vielleicht ein ; vergessen. Wie sieht denn Zeile 3 und 4 aus?
…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…
Joachim
Danke! Manchmal steht man einfach auf dem Schlauch und sucht an der falschen Stelle! Läuft jetzt.
Hallo Michael,
so rum oder anders herum:
JSON Parser-Fehler in /usr/share/symcon/scripts/__ipsmodule.inc.php on line 290
Ich habe versucht den Code etwas zu „bereinigen“:
$Message = utf8_decode("dim=".$Value).chr(255).chr(255).chr(255);
$this->SendDataToParent(json_encode(Array("DataID"=> "{A0DAAF26-4A2D-4350-963E-CC02E74BD414}", "Function" => "write_bytes_serial", "Handle" => GetValueInteger($this->GetIDForIdent("Handle")), "Command" => $Message)));
Ich weiß aber leider auch nicht, ob der Fehler hier oder bei der „Gegenseite“ aufläuft:
$Command = utf8_encode($data->Command);
IPS_LogMessage("GPIO Write Bytes Serial", "Handle: ".$data->Handle." Command: ".$Command);
$this->CommandClientSocket(pack("L*", 81, $data->Handle, 0, strlen($Command)).$Command, 16);
Joachim
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
Hallo Michael,
abermals Dank!
…bei dem ganzen hin- und her passiert dann auch mal so etwas! 
Joachim
Hallo Leute,
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?
Joachim
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
Hallo Leute,
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?
Joachim
__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
Hallo Michael,
abermals Dank für Deine Antwort!
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…
Joachim
__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
Hallo Michael,
ich habe das mit der Destroy Funktion mal getestet.
Instanz angelegt und danach gelöscht, läuft aber offenbar nicht in die Funktion…
Joachim
4.1 oder 4.0 ?
Michael
…bin noch auf der 4.0…
Geht erst ab 4.1…
Michael