Neues Modul für das PHC-Bussystem von Peha

[StefanStrobel]

Hallo Henrik,

bei einem AMD hat man ja einen sinnvollen Zustand je Kanal (ein/aus).
bei einem EMD dagegen kommen einfach nur Messages wie ein>0, ein>1, aus>0 ...
Was soll denn in einem Reading je EMD-Kanal drinstehen?
die letzte Funktion, so wie auch schon ein Event erzeugt wird?
Was wäre der Mehrwert?
Du könntest übrigens auch so schon per Fhem Notify Readings nach Deinem Geschmack erzeugen ...

Gruss
   Stefan

[StefanStrobel]

Hallo,

anbei eine neue Version zum Testen.
Es gibt ein neues Attribut "EMDReadings".
Wenn dieses auf 1 gesetzt wird, erzeugt das Modul Readings je Eingangskanal mit dem letzten Befehl des Kanals.

Gruss
   Stefan

[mcp]

Hallo Stefan,

vielen Dank.

Ich hab bei mir im Haus (letztes Jahr so gekauft) leider auch das PHC System (STM v2 mit etlichen AMDs, EMDs, JRMs, DIMs and whatnot)

Ich bin ziemlich neu in Sachen Smarthome und kompletter Neuling in Sachen FHEM (ca. 1 Monat)

Ich habe dein Modul lauffähig und es funktioniert soweit auch, habe allerdings erst einen Lichtschalter getestet/konfiguriert
Bin sehr erleichtert darüber dass es sowas für FHEM gibt, ich dachte schon ich müsste hier im Haus alles austauschen.

Ich habe jedoch ein paar Fragen zu deinem Modul.

- Wieso muss/sollte man die virtuellen Kanäle (z.B. virtEMD10C01Name) komplett in der Peha Software neu erstellen und quasi die ganze Programmierung doppeln?
  Ich habe mir dein Intro zum Modul im ersten Post x-mal durchgelesen aber blicke nicht wieso, außer das es Probleme gibt (aber welche?
  Ich habe das testweise mal mit einem vorhandenen EMD gemacht, klappt ebenso ohne Probleme.
  Ich frage weil ich eigentlich keine Lust habe die ganze Programmierung quasi doppelt machen zu müssen bzw. doppelt zu haben.

- Irgendwie können die Dimmer Beschreibungen nicht richtig in die Readings umgesetzt werden
  Nicht so schön wie die anderen, dort stehen die Namen wie sie auch in der PHC Software sind.
  Anbei mal ein Bild mit roter Markierung, dann siehst Du was ich meine.

- Uhren und Merker unterstützt dein Modul nicht oder?


Vielen Dank für Deine Arbeit!

--
ciao, Marc

[StefanStrobel]

Hallo Marc,

Das mit den virtuellen EMDs ist sauberer als wenn Fhem an Stelle eines vorhandenen EMDs eine Meldung an das Steuermodul macht und das Steuermodul dann eine Bestätigung über den Bus zurücksendet, mit der das EMD dann nichts anfangen kann. Aber es funktioniert so auch, zumindest wenn Fhem den "Toggle"-Status des EMDs schon mal auf dem Bus gesehen hat. Falls nicht kann es sein, dass Fhem beim ersten Mal den falschen Status verwendet und dann muss man die Nachricht eben noch mal senden.
Ich hatte im Wiki des PHC-Forums mal eine Doku des PHC-Protokolls soweit ich es verstanden habe abgelegt. Aber das Wiki wurde leider abgeschaltet. Zumindest ein PDF davon habe ich aber noch. Ich hänge es mal an.

Das mit der Beschreibung der Dimmer sieht nach einem Bug aus. Offenbar interpretiere ich hier die Nachricht vom Dimmer an das STM noch falsch. Das war mir noch gar nicht aufgefallen. Vermutlich hat Henrik das auch gemeint ...
Ich schau mir das noch mal genauer an.

Uhren und Merker existieren im Steuermodul. Wenn Du eine neuere Steuerung mit Ethernet-Anschluss hast, kann man da vermutlich über eine Art Webservice ran. Mein Modul hängt ja im Bus. Allerdings kann man zumindest die Uhren vermutlich über den Bus auch darstellen und ändern. Nur müsste sich dafür jemand nochmal ausführlicher mit dem Protokoll beschäftigen. Ich nehm's mal auf die Wunschliste

Gruß
    Stefan

[Henne16]

Hallo Stefan,

ich versuche gerade die Module und Ein – Ausgänge richtig zu benennen, (attr MyPHC channel(EMD|AMD|JRM|DIM|UIM|MCC|MFM)[0-9]+[io]?[0-9]+description) leider bekomme ich es nicht hin. Kannst Du mir ein Beispiel geben was ich beim Attribut eintragen muss.

Ich bekomme immer folgende Fehlermeldung.

Code Auswählen Erweitern


MyPHC: bad attribute name 'channel(EMD|AMD|JRM|DIM|UIM|MCC|MFM)[0-9]+[io]?[0-9]+description' (allowed chars: A-Za-z/\d_\.-)


Das Reading für den Eingang funktioniert bestens.

Vielen Dank für die Erweiterung.

Gruß Henrik

[StefanStrobel]

Hallo Henrik,

Beispiel:

Code Auswählen Erweitern


attr PHC channelEMD05i14description WC OG - Taster
attr PHC channelAMD04o00description Garage - Deckenlampe


die Angabe in der Doku ist als Regex zu lesen.

Gruß
    Stefan

[mcp]

Hallo Stefan,

Ich hatte im Wiki des PHC-Forums mal eine Doku des PHC-Protokolls soweit ich es verstanden habe abgelegt. Aber das Wiki wurde leider abgeschaltet. Zumindest ein PDF davon habe ich aber noch. Ich hänge es mal an.

danke für das PDF, hat aber irgendwie 0 Byte?!

Das mit der Beschreibung der Dimmer sieht nach einem Bug aus. Offenbar interpretiere ich hier die Nachricht vom Dimmer an das STM noch falsch. Das war mir noch gar nicht aufgefallen. Vermutlich hat Henrik das auch gemeint ...
Ich schau mir das noch mal genauer an.

danke!

Uhren und Merker existieren im Steuermodul. Wenn Du eine neuere Steuerung mit Ethernet-Anschluss hast, kann man da vermutlich über eine Art Webservice ran. Mein Modul hängt ja im Bus. Allerdings kann man zumindest die Uhren vermutlich über den Bus auch darstellen und ändern. Nur müsste sich dafür jemand nochmal ausführlicher mit dem Protokoll beschäftigen. Ich nehm's mal auf die Wunschliste

ich hab' leider noch ein STM v2. Ein v3 ist ja doch ziemlich teuer wie ich finde, selbst gebraucht muss man noch 400-500 Euro hinblättern, das finde ich irgendwie zu viel. Wobei ich ja eigentlich auch ein Ersatz Modul brauche, denn wenn das STM mal kaputt geht ... ;-/

[StefanStrobel]

Hallo,

Ich habe den Dateianhang oben korrigiert.

Gruß
    Stefan

[mcp]

Hallo Stefan,

vielen Dank.

Wie hast Du eigentlich Deine PHC Installation in FHEM eingebunden?

Ich hab' das jetzt so laufen (erstmal ein EMD welches Licht schaltet):

Code Auswählen Erweitern


Internals:
   DEF        Peha_PHC:Keller_Buero_Deckenlampe_vorne
   DEVICE     Peha_PHC
   FUUID      5eadaf61-f33f-b956-01b6-41f4d1383810fad2
   NAME       PHC_BL_Keller_Buero_Deckenlampe_vorne
   NOTIFYDEV  Peha_PHC,global
   NR         97
   NTFY_ORDER 50-PHC_BL_Keller_Buero_Deckenlampe_vorne
   READING    Keller_Buero_Deckenlampe_vorne
   STATE      off
   TYPE       readingsProxy
   CONTENT:
     Peha_PHC   1
   READINGS:
     2020-05-06 15:47:44   lastCmd         off
     2020-05-06 15:47:44   state           off
Attributes:
   genericDeviceType light
   room       23_Homekit,PEHA_Labor
   setFn      {
        # $NAME gibt's hier sonst leider nicht
my ($hash) = @_;
my $NAME = $hash->{NAME};

my $peha_switch = "PHC_SW_Keller_Buero_Deckenlampe_vorne";

my $STATE = ReadingsVal($NAME,'state','0');

Log (3, "<DEBUG> Peha_PHC DEVICE:  " . $DEVICE);
Log (3, "<DEBUG> Peha_PHC READING: " . $READING);
Log (3, "<DEBUG> Peha_PHC NAME:    " . $NAME);
Log (3, "<DEBUG> Peha_PHC STATE:   " . $STATE);
Log (3, "<DEBUG> Peha_PHC CMD:     " . $CMD);

if ( ("$CMD" eq "off") && ("$STATE" eq "off") ) {
Log (3, "<DEBUG> Peha_PHC: aus bleibt aus");

} elsif ( ("$CMD" eq "on") && ("$STATE" eq "on") ) {
Log (3, "<DEBUG> Peha_PHC: an bleibt an");

} elsif ("$CMD" eq "on") {
fhem("set Peha_PHC $peha_switch ein>0");
}
else {
fhem("set Peha_PHC $peha_switch aus<1");
}
   }
   setList    on off
   siriName   PHC_BL_Keller_Buero_Deckenlampe_vorne
   valueFn    {($VALUE == 0)?"off":"on"}
   webCmd     on:off


also ein ReadingsProxy.

Das funktioniert im Prinzip wunderbar, sowohl via FHEM als auch via den FHEM Apps als auch Homebridge usw.

Nur bin ich damit irgendwie noch nicht glücklich, vor allem wegen dem setFn Code, den ich ja für jedes einzelne EMD manuell eintragen muss (ok kann man scripten) aber trotzdem

Wie hast Du das gemacht bzw. hast Du eine andere/bessere Idee?

Vielen Dank!

[StefanStrobel]

Hallo,

ich habe virtuelle EMDs definiert. Das Modul erzeugt dazu dann automatisch eine Set-Option für ein>0 etc.
Probiers doch mal aus.
Ich könnte aber auch für existierende EMDs eine komfortablere Set-Funktion ins Modul bauen.
Nur bisher hat das keine benötigt

Gruss
   Stefan

[mcp]

Ok ich teste das mal.

Ja wenn du das einbauen könntest, was einem Sachen vereinfacht, wäre ich sofort dafür

Ein Freund von mir hat mich überzeugt das doch nicht mit den existierenden EMDs zu machen. Ich hab im Peha Setup viel mit Ausschaltverzögerung usw. via Funktionsprogrammierung und das normale schalten via Basis, was sich zusammen mit FHEM beißt. Und da ich das existierende Setup im Peha nicht wegoptimieren will für den Fall der Fälle ... Insofern würde ich wohl auch virtuelle EMDs anlegen müssen (Christoph: )

[mcp]

Hallo Stefan,

mir ist ja aufgefallen dass das mit der Dimmer Beschreibung nicht richtig passt, du sagtest dass das wohl ein Bug ist.

Ich habe weiterhin gesehen dass das wohl auch auf fast alle anderen Module zutrifft.

Wieso gibt's da Readings, z.B.: DIM??-o?? und mal DIM??o??, also mal mit und mal ohne Bindestrich? Das gleiche bei den AMDs.

Und mit Bindestrich bei den EMDs usw. ...

Ich wollte dann mal testweise die channel description ändern aber man darf keine Bindestriche benutzen ...

Die Dimmer Module haben Kanal 0 und 1 und jeweils ein Rückmeldungskanal dazu. Im FHEM Modul sehe ich allerdings immer 00 bis 07? wobei 07 immer den Status 1 hat?

So ganz blicke ich Dein Modul noch nicht

Dann noch eine Frage: hast Du eine Idee wie ich mit dem FHEM Peha PHC Modul feststellen kann ob eine Rolllade auf oder zu ist? Das Reading der Rolllade ist leider immer 0.
In der Peha Software habe ich es mit einem Krückenbehelf gemacht, mit einem Merker, der einfach davon ausgeht dass man die Rollladen immer komplett auf oder zu fährt und je nach Status dann ein Merker gesetzt wird ... Aber Merker gibt's in dem FHEM Modul ja nicht insofern ...

[mcp]

Hallo Stefan,

hattest Du evtl. schon Zeit wegen den Bugs zu schauen?

[StefanStrobel]

Hallo mcp,

ich bin leider noch nicht dazu gekommen, mich wieder mit dem PHC-Modul zu beschäftigen.
Ich habe in den letzten Monaten an einer neuen Version des ArduCounters gearbeitet. Die ist jetzt langsam fertig und dann komme ich auch wieder zu PHC.

Gruss
   Stefan

[mcp]

Hallo Stefan,

uih, nicht schlecht. Cool was du so alles programmieren kannst

Leider hab ich noch ein Bug gefunden, wobei ich mir nicht sicher bin ob es dein Modul ist oder die Peha selbst.

Ich habe ein Notify auf eine Rolllade damit ich mitbekomme wann und was sich da tut. Das klappt soweit auch gut nur wenn der Sonnensensor die Rollladen für 10 Sekunden runter fährt feuert das Notify 3x hintereinander zur gleichen Sekunde, ist zwar unschön aber das ist nicht das Haupt-Problem, das Problem ist dass "Sensor senken" offensichtlich für 1 Minute gesendet wird?! Erst danach kommt "FB_Senken_Aus".

FHEM denkt dann natürlich dass die Rolllade dann definitiv zu ist, bei einer normalen Laufzeit von 26 Sekunden von auf nach zu, wobei sie tatsächlich bei der Hälfte vom Fenster steht.

Das Gleiche passiert übrigens auch wenn der Sensor die Rollladen wieder hochfahren lässt.