Proxy für HomeMatic Konfig Software in FHEM

[Guest]

Originally posted by: <email address deleted>

Hallo,

wäre es machbar einen "Proxy" in FHEM zu integrieren welcher der HomeMatic
Konfigurationssoftware ein Netzwerk-Interface vorgaukelt? Die Geräte würden
also mit FHEM gepaart und die Konfig-SW kann die Geräte dann virtuell auf
sich pairen und konfigurieren ohne dass die Geräte vorher von FHEM unpaired
werden müssen.

...Alex

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Im Moment macht FHEM überhaupt kein richtiges Pairing, weil das wohl auch
nicht so trivial ist. Insbesondere direkte Verknüpfungen lassen sich meiner
Kenntnis nach damit nicht anlegen.

Außerdem nutzt die ConfigSoftware BidCos als höhere Abstraktionsschicht.
FHEM arbeitet auf einem unteren Level auf dem direkt die Funk-Codes erzeugt
werden.

Ich denke hier sprechen wir von einem eher langfristigen ENtwicklungsziele.

Am Mittwoch, 29. Februar 2012 22:36:49 UTC+1 schrieb Alexander Brickwedde:
>
> Hallo,
>
> wäre es machbar einen "Proxy" in FHEM zu integrieren welcher der HomeMatic
> Konfigurationssoftware ein Netzwerk-Interface vorgaukelt? Die Geräte würden
> also mit FHEM gepaart und die Konfig-SW kann die Geräte dann virtuell auf
> sich pairen und konfigurieren ohne dass die Geräte vorher von FHEM unpaired
> werden müssen.
>
> ...Alex
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Im Moment macht FHEM überhaupt kein richtiges Pairing, weil das wohl auch

Fhem hat Probleme beim Anlernen (pairing) mancher HM-Fernbedienungen.  Wenn
fhem ein Geraet erkannt und angelegt hat, heisst es noch lange nicht, dass das
Geraet fhem auch als Auftraggeber akzeptiert, "CommandAccepted" im
Detail-Ansicht sollte ein Hinweis sein, ob es tut. Wenn nicht angelernt, dann
kann fhem zwar die Befehle mitlauschen, aber nicht quittieren, insb. da die
Fernbedienung diese weiterhin nicht an fhem schickt. Ohne Quittierung kein
gruenes Licht.


> Insbesondere direkte Verknüpfungen lassen sich meiner Kenntnis nach damit
> nicht anlegen.

Ich konnte erfolgreich eine Direktverknuepfung zw. einem Wandschalter und eine
Unterputzschalter herstellen, siehe auch devicepair.


> Außerdem nutzt die ConfigSoftware BidCos als höhere Abstraktionsschicht.

Bist Du sicher, dass dieser Schicht als "BidCos" zu bezeichnen ist? Ich dachte
BidCos ist der Name des Funk-Protokolls.

Die Configurations-Software benutzt das sog. XML-RPC, das muss von einem
rpd.exe nach "Lowlevel" umgesetzt werden. rpd.exe gibt es bisher nur fuer
Windows bzw. in der CCU fuer ARM, letzteres leider altes Byte-Endian, nicht
einfach auf aktuelle Debians kopierbar, mit qemu klappt es aber

Fuer XMLRPC existiert ein von Oliver in das fhem/contrib gestellte HMRPC Modul,
weiss aber nicht wie vollstaendig es ist.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Am Donnerstag, 1. März 2012 10:22:15 UTC+1 schrieb Rudolf Koenig:
>
>
>
> > Insbesondere direkte Verkn�pfungen lassen sich meiner Kenntnis nach
> damit
> > nicht anlegen.
>
> Ich konnte erfolgreich eine Direktverknuepfung zw. einem Wandschalter und
> eine
> Unterputzschalter herstellen, siehe auch devicepair.
>
DAS ist interessant, das werde ich nachher versuchen nachzuvollziehen.
Sorry wenn ich das hier falsch dargestellt habe. Die Sache ist halt die,
dass hier HM viel komplexer ist als FS20. Eine Verknüpfung enthält bis zu
60 Einstellungen pro Verknüpfung, diese werden dabei im Empfänger
gespeichert.

Ich habe seit gestern meinen neuen CUL-Stick und habe schon fleissig die
RAW-Daten mitgelesen. Das schöne ist, ich habe auch eine CCU und ich kann
den Payload der vom CUL hin- und hergeschickt wird sehr schön mit dem
vergleichen, den ich habe, wenn ich die CCU nutze. Eine interessante
Entdeckung habe ich schon gemacht. Bei meinem Funkdimmaktor sendet FHEM per
CUL zum Beispiel beim Ausschalten etwas, was die CCU gar nicht kann. Das
Licht geht nämlich HART aus. SChaltet man per CCU ab, geht es weich aus,
also mit einer Rampe. Offenbar können die Aktoren mehr, als die CCU nutzt.
Das macht es natürlich reizvoll, das Protokoll weiter zu dekodieren.
 

>
> > Au�erdem nutzt die ConfigSoftware BidCos als h�here
> Abstraktionsschicht.
>
> Bist Du sicher, dass dieser Schicht als "BidCos" zu bezeichnen ist? Ich
> dachte
> BidCos ist der Name des Funk-Protokolls.
>
Ok, das habe ich schlecht benannt. Ich meinte damit den BidCos-Service (von
dir rpd.exe genannt). Dieser stellt einen XMLRPC Server zur Verfügung, das
ist richtig.

Das MOdul von Olli funktioniert prima, aber es ist insofern nicht
vollständig, dass das komplexe Datenmodell nur Low-Level abgebildet ist und
es für die einzelnen Dinge natürlich in FHEM noch keine semantisch
passenden Bedeutungen gibt. Das Ding ist aber insofern vollständig, dass
man schon heute mit dem HMRPC-Modul alles erreichen kann, da man direkt
XML-Setparam und Getparam Komandos absetzen kann. Mit diesen beien
Kommendos hat man die vollständige Kontrolle und kann auch
Direktverknüpfungen anlegen usw.
 

> Die Configurations-Software benutzt das sog. XML-RPC, das muss von einem
> rpd.exe nach "Lowlevel" umgesetzt werden. rpd.exe gibt es bisher nur fuer
> Windows bzw. in der CCU fuer ARM, letzteres leider altes Byte-Endian, nicht
> einfach auf aktuelle Debians kopierbar, mit qemu klappt es aber
>
> Fuer XMLRPC existiert ein von Oliver in das fhem/contrib gestellte HMRPC
> Modul,
> weiss aber nicht wie vollstaendig es ist.
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com