FHEM Forum

CUL - Entwicklung => CUL Development => Thema gestartet von: owagner am 05 Januar 2013, 12:09:27

Titel: HM485-Support und Dokumentation
Beitrag von: owagner am 05 Januar 2013, 12:09:27
Hi,

ich habe 'mal Unterstützung für das HM485-Grundprotokoll ("Homematic Wired") in culfw (bisher nur für den CUNO2) eingebaut.

Es gibt derzeit zwei brauchbare Quellen für eine Beschreibung des darauf aufsetzenden Applikationsprotokolls:

-- offizielle Dokumentation von ELV zum HS485-Protokoll. HS485 ist eine Serie von inzwischen nicht mehr weiterentwickelten Hausautomationsmodulen von ELV, welche ganz offenbar als Grundlage für die Homematic-Wired-Reihe dient. Das Protokoll ist nicht ganz identisch mit HM485, die Doku taugt aber als Grundlage:

http://www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf (//www.elv-downloads.de/downloads/programme/HS485/HS485_Protokoll.pdf)

-- Protokollanalyse eines Mitglieds des Homematic-Forums ("kc-captain"):

http://homematic-forum.de/forum/viewtopic.php?p=62373#p62373 (//homematic-forum.de/forum/viewtopic.php?p=62373#p62373)

Viele Grüße,
Olli
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: Dirk am 05 Januar 2013, 15:14:50
Hi Olli,

ich oute mich mal als "kc-captain" vom Homematic-Forum.
Wo denkst du sollten wir unsere Erkenntnisse zum Protokoll sammeln?
Hier im Forum, im Wiki oder im CUL-SVN?

Ggf. macht es auch Sinn mein begonnenes Modul für FHEM Zusammen mit deinen CUL Erweiterungen zum laufen zu bringen.
Ich hab hier auch ein FHEM Modul was mit einem RS232 / USB - RS485 Konverter zusammen arbeitet.
Die Frage währ jetzt ob ich das komplett unter den Tisch fallen lasse, oder ob es das parallel geben sollte.

Kann denn CUNO2 RF / IR und RS485 Messages parallel empfangen und senden?

Gruß
Dirk
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: owagner am 07 Januar 2013, 23:07:56
Hi,

ich wäre dafür, die Doku in einem Wiki zu bearbeiten.

Wegen eines FHEM-Moduls würde ich eher vorschlagen, dass man eine Trennung des Applikationsprotkolls und der Transportschicht macht (analog der Trennung HMLAN/CUL_HM und HMDEV für RF). So rein als RS485-Transceiver ist der CUNO2 ja totaler Overkill, und es wäre vielleicht schön, wenn man auch einfache USB/RS485-Transceiver nehmen könnte, so wie Du es machst.

Der CUNO2 kann auf jeden Fall RF und RS485 parallel. IR ist neuerdings im Default-Build auskommentiert, ich weiss aber nicht wirklich, wieso. Die verwendete IRMP-Version ist m.E. auch etwas älter.

Olli
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: tostmann am 07 Januar 2013, 23:12:48
Zitat von: owagner schrieb am Mo, 07 Januar 2013 23:07IR ist neuerdings im Default-Build auskommentiert, ich weiss aber nicht wirklich, wieso. Die verwendete IRMP-Version ist m.E. auch etwas älter.

Die verwendete Version von IRMP pollt leider den Pin was für reichlich CPU Last führt. Da IR nur wenige benutzen hab ich es erstmal per Default auf OFF gesetzt um andere, öfter genutzte Dienste ein fehlerfreies Arbeiten zu ermöglichen.
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: Dirk am 08 Januar 2013, 10:12:56
Zitat
Zitat von: owagner schrieb am Mo, 07 Januar 2013 23:07Hi,Wegen eines FHEM-Moduls würde ich eher vorschlagen, dass man eine Trennung des Applikationsprotkolls und der Transportschicht macht (analog der Trennung HMLAN/CUL_HM und HMDEV für RF).
Ja, das hab ich so schon begonnen. Derzeit gibt es bei mir ein HM485.pm und ein HM485DEV.pm. Ich werde mal noch ein CUL_HM485.pm vorereiten. Das wird vermutlich aber frühestens nächste Woche.

Da der USB-Adapter "dumm" ist muss der HS485 Code dann halt nochmal im FHEM Liegen was so grundsätzlich ja erstmal nicht schlimm ist. Dann können wir ja versuche den Code soweit wie es geht zu vereinheitlichen. Das macht das spätere Bugfixing einfacher.

Zitat von: tostmann schrieb am Mo, 07 Januar 2013 23:12Die verwendete Version von IRMP pollt leider den Pin was für reichlich CPU Last führt.
Hm, Ich hatte gehofft den CULNO2 als IR-Sender einsetzen zu können. Na mal sehen. Das wird noch eine Weile dauern bis das drann kommt. Ggf. reicht es dann aus das Pollen aususchalten. Emfangen muss der ja nix. Abgesehen davon rennt der AVR doch eh in einer Dauerschleife rum. Was braucht es beim Pollen noch so viel Rechenkapazität?. Wenn der Empfäger Pin kein geänderten Pegel hat sollte doch nix zu tun sein?
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: owagner am 08 Januar 2013, 11:02:21
IRMP macht die ganze Arbeit in einer ISR, die mit recht hoher Frequenz aufgerufen wird (Senden auch, wobei man den Timer dann beim Nichtsenden einfach deaktivieren könnte).

Ich habe es in paar Projekten "nebenbei" eingesetzt und es hat nicht gestört, allerdings dann auch eher mit 16/20 Mhz...
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: Dirk am 08 Januar 2013, 11:07:23
Aso. Na dann ist's egel ob vom IR was empfangen wurde. Alles klar.
Titel: Aw: HM485-Support und Dokumentation
Beitrag von: Dirk am 08 Januar 2013, 12:08:22
Zitat von: owagner schrieb am Mo, 07 Januar 2013 23:07ich wäre dafür, die Doku in einem Wiki zu bearbeiten.
So lange ich das nicht ins Wiki geschaft habe, ich vermute das wird einiges an Arbeit, ist hier mal die aktuellste Version. Hab jetzt auch mal eine History mit eingebaut.

Gruß
Dirk