Wie es schon einige hier im Forum wissen, habe ich einige meiner Delphi-Module als PHP-Module für IPS V4 neu geschrieben. Vieles ist auf Grund EOL, nicht mehr vorhandenen Geräten bzw. mangelnden Interesse weggefallen. Dafür gibt es für meine alten Scriptlösungen für CUL, AVM und NUT eigene Module.
Es gibt eine Reihe generischer Device-Module für Wetter, Energy und Schalter, die ich von verschiedenen Splittermodulen erzeuge und dann mit Daten versorge. Die Device-Module müssen also nicht manuell angelegt werden. Die ursprüngliche Idee der Nutzung von FS20-Instancen für Schalter habe ich wieder verworfen, demnach braucht man auch kein FHZDummy mehr für Schalter. Das Schalten ist bei CUL und AVMAHA-erzeugten Switch Instancen als Standardaction eingetragen.
Die Module in der Übersicht:
i.d.R braucht man damit nur Instancen der Splittermodule zu erstellen. Jedes Modul hat ein Konfigurationsformular, wo man die eigenen Settings z.B. Wenn notwendig, wird dadurch auch eine Instance eines passenden IO (SerialPort bzw. ClientSocket) erstellt. Diese IO-Instance muss man anschliessend manuell konfigurieren (z.B. den richtigen ComPort zuweisen) und dann aktivieren. Bei Bedarf kann man die IO Module bis auf den WS300PC auch gegen eine kompatible Instance austauschen, z.B. beim CUL den Clientsocket gegen einen SerialPort usw. Wenn technisch möglich habe die SplitterModule auch einen Button im Testcenter, um die Funktion zu Testen. Es gibt auch eine Debug-Property in jedem Modul, welche recht umfangreiche Ausgaben ins Meldungsfenster aktiviert. PHP-Module können leider das Debug-Fenster von IPS nicht nutzen. Bei Problemen bitte diese Option aktivieren und mir dann die Ausgabe schicken
Die Dokumentation auf meinen Webseiten wird noch etwas brauchen, wer möchte, kann sich mit Doxygen aber schon mal die PHP Klassendokumentation erzeugen. Ein Doxyfile ist dabei
Als erstes möchte ich mich bei dir für die super Module bedanken - sowohl die „alten“ in Delphi geschriebenen als auch die neuen PHP-Module.
Ich habe kürzlich deine neuen PHP Module installiert (RasPi Symcon 4.0 vom 23.4.).
Da ich einen WS300 PC II und einen WDE1 im Einsatz habe.
Der WS300 PC II funktioniert einwandfrei.
Mit dem WDE1 habe ich Probleme.
Das Module erkennt den Datensatz nicht und dementsprechend werden die Variablen in den Instanzen nicht aktualisiert (bzw. es werden gar keine Instanzen für die Sensordaten erstellt):
01.05.2016 23:41:14*| WDE1*| (ID #10163) init ::Init entered
01.05.2016 23:41:14*| WDE1*| (ID #10163) SyncParent ::entered
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReceiveData ::Data arrived:{"DataID":"{018EF6B5-AB94-40C6-AA53-46943E824ACF}","Buffer":"$"}
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReceiveData ::24
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReadRecord ::ReadRecord:$
01.05.2016 23:41:40*| VariableManager*| [WDE1\Buffer] = $
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReceiveData ::Data arrived:{"DataID":"{018EF6B5-AB94-40C6-AA53-46943E824ACF}","Buffer":"1;1;;22,2;;;;;;;;;;;;;;;;4,8;89;0,0;43;0;0
"}
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReceiveData ::24313B313B3B32322C323B3B3B3B3B3B3B3B3B3B3B3B3B3B3B3B342C383B38393B302C303B34333B303B300D0A
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReadRecord ::ReadRecord:$1;1;;22,2;;;;;;;;;;;;;;;;4,8;89;0,0;43;0;0
01.05.2016 23:41:40*| WDE1*| (ID #10163) ReadRecord ::No match in inbuf
01.05.2016 23:41:40*| VariableManager*| [WDE1\Buffer] =
Soweit ich das beurteilen kann liegt das an der RegEx in der function ReadRecord($inbuf)
Zeile 428 in ./WDE1/module.php:
if (preg_match("/(S1[0-9,-;]+0$)/", $data, $records)) {
allerdings habe ich nicht genau verstanden, was dort gemacht werden sollte.
Hast du eine Idee, was die Ursache sein könnte, dass bei mir der Datensatz des WDE1 nicht erkannt wird?
Bzw. kannst du mir sagen, was die RegEx genau bewirken sollte?
Die Regex soll einen kompletten Record aus dem Datenstrom isolieren. Die Spezifikation in der Doku war etwas schwierig zu lesen, deshalb habe ich nach dem 5. Bier wohl aus dem $ ein S gemacht:D.
Richtig wäre dann wohl
if (preg_match("/(\$1[0-9,-;]+0$)/", $data, $records)) {
Probiere bitte mal aus, ob es damit geht.
Ich habe das Gerät selber nicht mehr und kann es nicht testen. Auf meine Bitte um entsprechende Unterstützung zur Modulerstellung hatte sich niemand gemeldet, braucht also scheinbar niemand mehr.
neue Caps(Felder) für WSDEV, SwitchDev und EnergyDev Module,
Doku
Das XS1-Modul listet die aktiven Sensoren und Aktoren. Es ist außerdem möglich, Aktoren wie FS20 zu schalten. Dimmen ist nicht implementiert. Es versteht im Moment auch nur die Funktionstypen, die ich selbst habe. Man benötigt dazu das passende Schlüsselwort aus dem json. Leider ist das nicht der Text, den man in der Konfiguration auswählen kann.
Das ws2500pc-Modul benötigt das ws2500 Ausleseprogramm und einen Webserver auf Linux, da es auf Grund des zeitkritschen Timings im Millisekundenbereich nicht direkt mit dem Gerät kommunizieren kann. Siehe Readme…
Hallo tommi,
wieder einmal besten Dank für deine Arbeit.
Ich muss mich mal melden, damit es nicht so aussieht, es würde sich nur einer für deine Arbeit interessiert.
Prima, dass wir deine Module jetzt auch für 4.0 einsetzen können.
Leider habe ich bis jetzt noch nicht die Zeit gefunden, die Änderungen einzubauen, da ich noch einige andere Umstellungen durchziehen muss.
für die Temperatur und Feuchte keine hexdec-Umwandlung stattfinden darf? Der Regen- und evt. (?) auch der Windwert dagegen scheinen richtig zu sein, wenn ich das mit meinen auf andere Weise gewonnenen Messwerten vergleiche.
Ich verwende einen COC, CUL und CUN im Haus. Alle diese empfangen die Temperatursensoren mehr oder weniger regelmäßig. Dadurch werden pro Sensor drei gleiche Devices angelegt. Schön wäre es, wenn man die drei (gleichen) Messwerte jeweils eines Zeitpunktes konsolidieren könnte, so dass nur ein Device angelegt wird. Bei FHEM wird das irgendwie so gemacht.
Die S300TH-Sensoren erhalten normalerweise durch das Modul den Namen „S300TH Sensor x“. Nur ein Sensor gleicher Bauart erhält komischerweise den Namen „WS300 T/F Sensor x“ - was könnte dier Ursache sein?
Beispiel für zwei S300TH:
Line:K7122224124 -> „WS300 T/F Sensor 7“
Line:K11205243F9 -> „S300TH Sensor 1“
(vermutlich liegt das an der „7“ in der ersten ID.
schaue ich mir an. Ich habe leider keinen KS300, um die Werte zu prüfen. Wenn Du mir aus dem Debug die Kxxx Zeile zusammen mit den korrekten Werten schicken könntest kann ich versuchen, mir einen Reim daraus zu machen.
Das Konsolidieren geht so nicht, da bei IPS eine Instance immer nur genau ein Parent haben kann. Außerdem wäre es möglich, das jemand 2 getrennte WS300 Systeme hat, z.B. Wohnung und Ferienhaus. Man könnte aber theoretisch im Script die Prüfung auf den Parent rausnehmen und die Instancen direkt ansprechen.
Hallo Tommi,
ich habe inzwischen die hexdec-Umwandlung für Temperatur und Feuchte entfernt. Damit stimmen nun diese beiden Werte. Hier die Debugzeilen aus deinem Modul:
Line:K1775910400E96AF4
HMS Dev 1 (T/F): T: 17,5 H: 49 W: 0 R: 2793 IR: NO
{„DataID“:"{CD3D1E2D-83ED-4595-90CD-3444A22AAA66}",„DeviceID“:„1“,„Class“:„CUL-WS300“,„Typ“:„KS300“,„WSData“:{„Id“:„1“,„Class“:„CUL-WS300“,„Signal“:-21,„Temp“:17.5,„Hum“:„49“,„Wind“:0,„RainCounter“:2793,„IsRaining“:„NO“,„Typ“:„KS300“}}
und zum Vergleich die richtigen Messwerte aus FHEM:
Die RSSI-Werte sind scheinbar noch falsch. Windwerte > Null habe ich momentan nicht, ich werde das die nächsten Tage mal beobachten.
Man könnte aber theoretisch im Script die Prüfung auf den Parent rausnehmen und die Instancen direkt ansprechen.
Hmm, was bedeuet das dann? Habe ich dann nur noch ein Device pro Sensor?
Meine erste Idee war, das Modul so abzuändern, dass die 3 Messwerte von CUL, CUN und COC immer in dasselbe Device schreiben. Oder man führt für jeden Messwert des Devices eine neue Variable ein, in die dann die drei Messwerte von CUL, CUN und COC bei Aktualisierung reinkopiert werden.
Gruß
Peter
Die RSSi ist falsch, weil ich das falsche Byte genommen habe. Allerdings komme ich trotzdem nicht auf den richtigen wert, selbst wenn ich die Definition vom FHEM nehme
Bei einem Code „F4“ wie bei Dir wären das 244-256=-12 , /2 =-6 , -74=-80
Der Sensor7 wurde anders angezeigt, weil es hier eine Protokoll-Überschneidung gibt. Das ist auch schon ein paar Jahrebekannt. Ich nenne die Geräte jetzt durchgängig „WS300 T/F“. Dadurch werden die Sensoren allerdings neu angelegt.
Das konsolidieren kannst Du auch selber mit einem Variablentrigger von der angezeigten Variabe in Deine eigene Variable machen.
Allerdings komme ich trotzdem nicht auf den richtigen wert, selbst wenn ich die Definition vom FHEM nehme.
Das kann trotzdem richtig sein, da ich die COC nacheinander an den IPS-Server oder an FHEM gehängt habe. Da die RSSI-Werte evt. leicht schwanken ist ein Delta von 6 (80 zu 86) evt. ok.
EDIT: Habe gerade das Update des Moduls gesehen. Bei
$rainc = $a[14] . $a[11] . $a[12];
sollte hexdec aber stehen bleiben, da es HexWerte geben kann.
Man könnte aber theoretisch im Script die Prüfung auf den Parent rausnehmen und die Instancen direkt ansprechen.
Wo kann ich das im Modul anpassen? Ich habe versucht, in der Funktion SendWSData() die Überprüfung der ConnectionID herauszunehmen:
if ($I) { //my child
// if ($I && ($I['ConnectionID'] == $this->InstanceID)) { //my child
Dann wird auch tatäschlich nur ein Device pro Sensor angelegt. Das scheint dann bei neuen Messwerten nicht richtig zu funktionieren. Wenn ein Messwert z.B. über die CUN eintrifft, wird das Device nur dann aktualisiert, wenn das Device vorher von einem ersten CUN-Messwert angelegt wurde.
Kannst Du mir dazu einen Tipp geben, wie ich das anpassen kann?
Danke und Gruß
Peter
Die Parent-Prüfung im Device beinhaltet auch die absendende Klasse und den Typ, welche im Datenpacket übertragen wird
Um dort unabhängig zu sein musst Du im Datenarray des Splitters auch noch in $data ‚Class‘ und ‚Typ‘ auf einen einheitlichen Wert stellen. beim Erstellen des Devices wird das als Property eingetragen und beim Empfangen gegengeprüft. (siehe WSDEV/module.php Funktion ReceiveData)
HI Tommi,
danke für die Infos. Ich habe mich jetzt doch entschieden, das Modul im Originalzustand zu belassen. Ich bastele gerade an einem Copy-Script, dass von allen CUN/CUL/COC-Devices bei Aktualisierung getriggert wird, dann ein virtuelles Device pro Sensor anlegt (falls es noch nicht existiert), und dann die Messwerte dorthin kopiert. Bei neuen Sensoren muss ich dann nur noch die Trigger für diese Sensoren neu anlegen.
Hallo Tommi,
neues Problem: Ich bekomme die Daten meines Gaszählers (EMGZ) nicht in das Device. Das EMGZ-Device wird beim ersten Mal richtig angelegt, und bei neu eintreffenden Daten ändert sich auch das Aktualisierungsdatum, die Werte sind aber bis auf RSSI alle auf Null.
Das Logfile sieht eigentlich ganz gut aus, dort sieht man auch, dass die Werte zunächst richtig gelesen werden:
26.05.2016 08:14:16*| WSDEV*| (ID #42352) ReceiveData :: Data arrived:{„DataID“:"{3C60BF34-7DD3-4234-B865-AF1606BB267C}",„DeviceID“:10,„Typ“:„EMGZ“,„Class“:„CUL-EM“,„ENData“:{„Id“:10,„Class“:„CUL-EM“,„Typ“:„EMGZ“,„Counter“:16826,„PCounter“:16826,„ACounter“:0,„Signal“:-67}}
Zum Vergleich: In FHEM erzeugt der EMGZ folgende Einträge (einige Stunden vorher aufgezeichnet):
