Homematic UART geht nicht

[seryozhabelton]

Hallo Leute,

ich habe jetzt schon einiges mit FHEM automatisiert, bin also kein absoluter Neuling mehr. Bei der Einbindung des Homematic Systems bin ich jetzt aber an meine Grenzen gestossen und stehe auf dem Schlauch. Folgendes.

Ich habe bei ELV das (Aufsteck) Funkmodul HM-MOD-RPI-PCB für Raspberry Pi erworben und in Betrieb genommen. Um zu testen, habe ich dann die CCU2 Software auf eine Speicherkarte geschrieben, die Karte in den Raspi gesteckt und konnte das Modul ansprechen, Geräte anlernen, und damit remote schalten. Die Hardware ist also OK. Nur hätte ich das Gerät gerne unter FHEM eingebunden...

Ich habe deshalb die Speicherkarte mit meiner FHEM Installation wieder in den Raspi (V3) gesteckt und habe alle Änderungen an den config Dateien wie im Wiki empfohlen gemacht. (Taktanpassung, Gruppenanpassung, uart enable, ...), Ich bin dieser Anleitung gefolgt https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi, und habe dann, weil es nicht funktionierte, die Schritte noch mit Ottos Technik Blog abgeglichen (http://heinz-otto.blogspot.de/2016/07/raspberry-pi-homematic-modul.html)

Nach reboot des Raspberry habe ich dann die Befehle

Code Auswählen Erweitern


define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId ABCDEF

in FHEM abgesetzt. Seitdem bekomme ich im Event Log nur Abfolgen von "CONNECTED", "cond:init", "cond:disconnected".

Ein "List MyHmUART" liefert

Code Auswählen Erweitern


Internals:
   CNT        1
   DEF        /dev/ttyAMA0
   DevState   1
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         15
   LastOpen   1486714942.92914
   NAME       myHmUART
   NR         69
   PARTIAL    fd0002ff018205
   RAWMSG     004475616C436F50726F5F417070
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   Helper:
     Ackpending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     2
         time       1486714943.93153
     LastSendLen:
       3
     Log:
       IDs:
   Readings:
     2017-02-10 08:52:35   D-type          HM-MOD-UART
     2017-02-10 09:22:23   cond            init
     2017-02-10 08:52:35   loadLvl         suspended
     2017-02-10 09:22:22   state           opened
Attributes:
   hmId       ABCDEF
   room       A-Sandbox


Resultat: ich kann auf das Funkmodul von FHEM aus nicht zugreifen, weil vermutlich irgendetwas mit der Kommunikation nicht i.O. ist. Existiert da vielleicht eine Inkompatibilität mit anderen Modulen? Ich habe ein PigPiod laufen, kann das ein Problem mit dem Reset-Pin verursachen? Wie kann ich das  - eventuell außerhalb von FHEM - testen?

Wäre für Hinweise, wo ich bei der Fehlersuche anfangen kann, sehr dankbar! Ach ja, ich verwende eine aktuelle Jessie Version und habe sowohl Jessie als auch FHEM auf dem aktuellen Stand.

[mgernoth]

Hallo,

Um zu testen, habe ich dann die CCU2 Software auf eine Speicherkarte geschrieben, die Karte in den Raspi gesteckt und konnte das Modul ansprechen, Geräte anlernen, und damit remote schalten.

Ist Fhem aktuell?
Die aktuelle CCU2-Firmware flashed eine inkompatible Firmware auf das Modul, erst 00_HMUARTLGW.pm ab Version 13367 hat eine minimale Unterstützung für diese Version und erlaubt das Flashen einer anderen Version. Im Reading cond muss in diesem Fall "unsupported firmware" auftauchen.

Viele Grüße
  Michael

[seryozhabelton]

Hallo Michael,

Danke für Deinen Hinweis, der mir mehrere Stunden debugging erspart hat! In der Tat war das 00_HMUARTLGW.pm nicht auf Level 13367. Nachdem ich das gefixt hatte, konnte ich die aktuelle Firmware auf das Modul laden, und danach hat innerhalb weniger Minuten alles funktioniert. Habe das Device dann in Raum "Homekit" eingebunden, und schon war es auch vom Telefon aus schaltbar! So kann ich das Oszilloskop, das ich vorsorglich schon zum debuggen des seriellen Ports herausgeholt hatte, ja wieder wegpacken!

Vielen Dank noch mal,

Frank

[MarcelK]

Die aktuelle CCU2-Firmware flashed eine inkompatible Firmware auf das Modul

Im Source nennst Du die neue DualCoPro, sind das erste Anzeichen auf einen HM/IP Dual Stack in der Firmware?

Besten Gruß, Marcel

[mgernoth]

Hallo,

Im Source nennst Du die neue DualCoPro, sind das erste Anzeichen auf einen HM/IP Dual Stack in der Firmware?

Ja, so in der Art. Die DualCoPro-Firmware unterstützt tatsächlich HM und HM-IP, jedoch anscheinend sogar weniger gut als ein CUL (kein Ack/AES/etc. mehr in der Firmware). Das komplette Protokoll und Timing muss vom Host übernommen werden und eQ-3 hat den Kernel patchen müssen, damit das Timing überhaupt klappt. Also nichts, was man in Fhem umsetzen kann.

https://github.com/eq-3/occu/blob/master/KernelDrivers/Dual_Protocol_Linux_Drivers.pdf

Viele Grüße
  Michael

[MarcelK]

Ja, so in der Art. Die DualCoPro-Firmware unterstützt tatsächlich HM und HM-IP, jedoch anscheinend sogar weniger gut als ein CUL (kein Ack/AES/etc. mehr in der Firmware). Das komplette Protokoll und Timing muss vom Host übernommen werden und eQ-3 hat den Kernel patchen müssen, damit das Timing überhaupt klappt. Also nichts, was man in Fhem umsetzen kann.

https://github.com/eq-3/occu/blob/master/KernelDrivers/Dual_Protocol_Linux_Drivers.pdf

Wow, was für ein ekelhafter Hack. Da haben sie jetzt schon so ein schönes Modul rausgebracht und degradieren es kurze Zeit später wieder zum CC1101 runter. Wenn's wenigstens den Quellcode vom multimacd gäbe könnte man den ja z.B. noch auf einen angehängten ESP8266 packen, aber das gibt's ja sicher auch wieder nicht.

Naja, glücklicherweise funktioniert die "alte" Firmware ja sehr gut, bin gerade daran UART 3 und 4 hier in Betrieb nehmen...

Danke und Gruß, Marcel