Neues Modul für das PHC-Bussystem von Peha

Begonnen von StefanStrobel, 23 April 2017, 21:18:08

Vorheriges Thema - Nächstes Thema

StefanStrobel

Hallo,

Anbei ein Prototyp für ein Modul zur Anbindung von Fhem an den PHC-Bus von Peha.
Zur Verbindung benötigt man einen RS485-Adapter. Ich verwende einen Digitus DA-70157.
Der Adapter wird mit drei Adern (GND, +Data und -Data) direkt an den Modul-Bus angeschlossen.

Folgendes ist damit machbar:
Mitlesen aller Nachrichten auf dem Bus soweit sie vom Modul schon unterstützt werden. Dabei werden die Zustände aller Ein- und Ausgangsmodule verfolgt und in Readings abgebildet. Innerhalb von Fhem kann man so auf Taster an PHC-Eingangsmodulen oder den Status von PHC-Ausgangsmodulen reagieren.

Das Modul unterstützt bisher die typischen Eingangsmodule, Ausgangsmodule, Rolladenmodule, das MMC, Infrarotmodul, Enocean-Funkmodul, und Dimmer-Module. Weitere Module oder fehlende Protokollnachrichten sollten sich in den meisten Fällen durch ergänzen von Tabellen im Modul-Code ergänzen lassen.

Das Modul kann ein Kanalliste mit der Beschreibung aller Module und Ein- / Ausgänge, die man mit der PHC-Systemsoftware von Peha exportieren kann, in Fhem importieren und dann zur Benennung der Ein- und Ausgänge verwenden. Die Modultypen und Namen der Ein- und Ausgänge werden dabei als Attribute angelegt.

Um Nachrichten an das PHC-Steuermodul schicken zu können, kann das Fhem-Modul ein 16-Kanal Eingangsmodul simulieren und so Tastendrücke an das PHC-Steuermodul schicken. Ausgangsmodule lassen sich leider nicht simulieren. Dafür ist Fhem auf einem Raspberry nicht schnell genug. Um innerhalb von Fhem auf einen Tastendruck im PHC-System zu reagieren, muss man einfach auf die Änderung des Readings für das Eingangsmodul reagieren. Da das Modul alle Nachrichten auf dem Bus mitliest und daraus Readings erzeugt, ist das mit den normalen Fhem-Boardmitteln leicht möglich.

Generell ergeben sich einige Einschränkungen aus der Funktionsweise des PHC-Bussystems. Als Zentrales Element ist hier ein PHC-Steuermodul von Peha vorgesehen. Auf dieses Modul wird ein Programm geladen, das mit der PHC-Systemsoftware erzeugt wird. Es empfängt und bestätigt Nachrichten von Eingangsmodulen wenn z.B. eine Taste gedrückt wurde und gibt Befehle an Ausgangmodule um z.B. Lampen zu schalten. Jede Nachricht muss von der Gegenseite sehr schnell bestätigt werden. Auf die Nachricht eines Eingangsmoduls kommt sofort ein Ack vom Steuermodul und auf den Befehl des Steuermoduls an ein Ausgangsmodul muss auch dieses sofort eine Bestätigung schicken.

Deshalb kann Fhem auch einfach ein Eingangsmodul simulieren. Das Fhem-Modul schickt dazu einfach eine entsprechende Nachricht auf den Bus und das PHC-Steuermodul bestätigt diese. Wenn Fhem jedoch ein Ausgangsmodul simulieren soll, dann müsste Fhem auf einen Befehl des PHC-Steurmoduls schnell eine Bestätigung schicken. Das dauert mit Fhem jedoch zu lange.

Es ist auch nicht möglich, parallel zum PHC-Steuermodul direkt mit Ausgangsmodulen zu reden. Soweit ich das Protokoll bis jetzt verstanden habe,  wird so eine Nachricht zwar vom Ausgangsmodul  verstanden und ausgeführt, aber leider sind die Nachrichten auf dem Bus zustandsabhängig und nicht eindeutig.

Ein und dieselbe Nachricht könnte von einem Ausgangsmodul an das Steuermodul gesendet werden oder vom Steuermodul an das Ausgangsmodul. Beide Nachrichten haben unterscheidliche Bedeutungen. Da normalerweise nur ein PHC-Steuermodul Nachrichten an die Ausgangsmodule sendet, ist das kein Problem. Wenn aber nun Fhem auch mit den Ausgangsmodulen redet, dann versteht das Ausgangsmodul die Nachricht auf eine Art und das Steuermodul die gleiche Nachricht auf eine andere. Beide bestätigen dann die Nachricht quasi gleichzeitig.
Das Steuermodul hat durch seine Programmierung auch eine Liste der vorhandenen Modul mit ihren Adressen und dem Typ des Moduls. Leider gibt es im PHC-Protokoll auch Nachrichten, die identisch aussehen, aber z.B. für ein Rolladenmodul eine andere Bedeutung haben als für ein Ausgangsmodul. Damit Fhem damit kein Problem bekommt, hat das Fhem-Modul einen Lernmodus, der aus den Nachrichten, die eindeutig einem Modultyp zugeordnet werden können, den Typ des Moduls erkennt und in einem Attribut abspeichert. Beim Import der Kanalliste werden aber diese Typen ebenfalls in Attributen gespeichert.

Das Modul ist sicher noch nicht fehlerfrei und könnte noch an einigen Stellen erweitert werden. Wer es ausprobiert und sein Fhem an den PHC-Bus anklemmt, muss dies auf eigene Gefahr tun. Im schlimmsten Fall könnte das PHC-System beschädigt werden und wer sein ganzes Haus damit steuert, hätte dann ein Problem.
Vielleicht kann es aber dennoch auch so schon jemand brauchen ;-)

Definition mit:

define MyPHC PHC /dev/ttyRS485


wenn das Attribut verbose für MyPHC auf 4 oder 5 gesetzt wird, sollte man im Log nun die Nachrichten auf dem Bus sehen.
Zudem sollten Readings erscheinen.

Gruss
   Stefan

EDIT: angehängtes Modul entfernt (neue Version in späterem Post)

Henne16

Hallo Stefan,

das hört sich sehr interessant an.
Ich werde mir mal einen Adapter besorgen.

Gruß Henrik


Gesendet von iPhone mit Tapatalk
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

Henne16

Hallo Stefan,

nun ist der Adapter angekommen.
Wenn ich das Modul installiere bekomme ich einen disconnected.
Wie importiere ich die Systemmtree.xml oder besser gefragt wo hast Du deine abgelegt.

Was bewirkt genau das attr MyPHC channel(EMD|AMD|JRM|DIM|UIM|MCC|MFM)[0-9]+[io]?[0-9]+description, sowie attribute module[0-9]+description, attribute module[0-9]+type und attribute virtEMD[0-9]+C[0-9]+Name.
Oder bessergefragt was muss man dort angeben.


Gruß Henrik
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

StefanStrobel

Hallo Henrik,

nach dem define mit dem richtigen USB-Device solltest Du kein disconnected sondern opened als Status bekommen. Dabei ist es sogar egal ob die Verbindung zum Modul-Bus steht oder nicht. Fhem DevIO setzt openend sobald die serielle Schnittstelle "geöffnet" wurde.

Die exportierte Kanalliste habe ich im Fhem-Wurzelverzeichnis (bei mir /opt/fhem) abgelegt. Dann kann man beim Import einfach den Dateinamen ohne weiteren Pfad angeben. Der Import erzeugt dann die von Dir angefragten Attribute zum festlegen des Typs und der Bezeichnungen der Module und Kanäle. Der Inport kann je nach Größe der XML-Datei einige Sekunden dauern. In der Zeit blockiert auch Fhem, aber da man das ja nicht täglich macht, habe ich es noch nicht optimiert.

Die Bezeichnungen werden später beim Logging und für die Readings verwendet.

Gruss
   Stefan

StefanStrobel

Hallo Henrik,

Vielen Dank für's Testen und Dein Feedback per PM.
Bestehende virtuelle Eingangsmodule erzeugen keine Nachrichten auf dem Bus. Deshalb sieht das Fhem-Modul nichts davon.
Um einen Dimmer von Fhem aus anzusteuern würde ich ein weiters virtuelles Eingangssmodul in der PHC Systemsoftware definieren, dann ebenfalls in der PHC-Software einen Eingangakanal davon in der Basisprogrammierung oder Fuktionsprogrammierung verwenden.
In Fhem würde ich dann den virtuellen Kanal per Attribut definieren:
Z.B.:

attr MyPHC virtEMD25C2Name FhemTasterFuerDimmer

Für ein virtuelles EMD mit Adresse 25 und einem Kanal 2 als Taster für den Dimmer.

Dann kannst Du mit

set MyPHC FhemTasterFuerDimmer ein>0


Die Nachricht für einen Taster, der kurz angetippt wurde von Fhem an das PHC-Steuermodul schicken.
Dort müsste Dann Dein PHC-Programm eine Verbindung enthalten:
Wenn EMD 25 Kanal 2 ein>0 heller dimmen
Oder ähnlich.

Leider kann man nicht mit Ausgängen kommunizieren. Das sollte immer das PHC-Steuermodul tun.

Gruß
    Stefan

Gruß
     Stefan

StefanStrobel

#5
Anbei eine neue Version, bei der ein Fehler im Zusammenhang mit virtuellen EMDs behoben ist.

Gruss
   Stefan

EDIT: angehängtes Modul entfernt, aktuelle Version ist eingecheckt.

Henne16

Hallo Stefan,

ich bin zurzeit leider viel unterwegs und kann nur wenig testen.
Ich werde die neue Version mal einspielen.

Vielen Dank für das Modul.

Gruß Henrik
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

draa

Hallo,
ich mache gerade mit FHEM meine ersten Schritte mit dem Ziel die Phillips Hue und meine PHC-Haussteuerung zu verbinden. Ich habe die PHC-Steuereinheit ohne LAN-Modul und will aktuell auch nicht umsteigen.

Insofern habe ich  das PHC-Modul ausprobiert und bin davon begeistert. Aktuell läuft bereits der erste PHC-Schalter und ich schalte damit die HUE-Lampen. In den nächsten Schritten werde ich die Steuerung verfeinern

Viele Grüße
Dieter

StefanStrobel

Hallo,

ich habe nochmals ein paar kleinere Bugs behoben und eine neue Version eingcheckt, so dass sie per update verteilt wird.
Neu ist z.B. dass alle Kommandos vom PHC-Bus auch in Fhem als Events erzeugt werden. Damit kann man mit Notify etc. auf Tastendrücke im PHC-System reagieren.

Gruss
   Stefan

Henne16

Hallo Stefan,

vielen Dank für das Modul.

Dann werde ich am Wochenende mal testen.

Gruß Henrik.
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

Henne16

Hallo Stefan,

ich habe nun mal etwas Zeit gehabt und mich mit dem PHC Modul etwas beschäftigt.
Mir ist aufgefallen das die EMD Module nicht in den Readings stehen.
Hast Du schon einen weg gefunden die Dimmer zu bedienen, bzw. eine Rückmeldung aus den Events herauszufiltern.

Beste Grüße Henrik.
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

StefanStrobel

Hallo Henrik,

für die EMDs setzt das Modul bisher keine Readings, es erzeugt aber Events für alle Befehle, auch die von EMDs, so dass man darauf reagieren kann.
Den letzten Befehl eines EMDs in ein Reading je Kanal zu packen wären vermutlich weniger als fünf Zeilen Perl, falls es mal jemand braucht.

Wenn ich von Fhem aus etwas über den PHC-Bus steuern möchte, dann mache ich das über ein virtuelles EMD, bei dem Fhem die EMD-Befehle sendet und die PHC-Steuerung dann die AMDs oder Dimmer ansteuert. Das erscheint mir die sauberste Lösung, bei der Fhem nicht in Konflikte mit der Steuerung gerät.

Was meinst Du mit Rückmeldung in diesem Kontext?

Gruss
   Stefan

Henne16

Hallo Stefan,

mit der Rückmeldung meinte ich wie der Dimmer zustand ist, also nicht nur an oder aus sondern auf welcher Dimm Stufe er sich befindet.
Auch für das hoch- oder runterdimmen fehlt mir im Moment noch der Ansatz.

Grüße Henrik.
FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer

StefanStrobel

Hallo Henrik,

ich habe mich seit dem Herbst 2018 nicht weiter mit dem PHC-Protokoll beschäftigt. Ob die Dimmer-Module überhaupt den aktuellen Stand senden, kann ich nicht sagen.

Gruss
   Stefan

Henne16

Hallo Stefan,

könntest Du vielleicht die Readings der Eingangmodule noch mit einbauen, wie Du es beschreibst ist es nicht der größte Aufwand.
Die Dimmer erzeugen ja ein Event, mal schauen ob ich daraus schlau werde.

Liebe Grüße Henrik

FHEM 6 PI4, Fhem2Fhem, Homematic IP CCU3, HMLAN, div. Thermostate, HM IP Wired Ein-Ausgang, Dimmer