Support für neues Funkmodul HM-MOD-RPI-PCB für Raspberry Pi

stefan · October 2, 2016, 5:19pm

Zumindest ein wenig Entwarnung: Bei den Ergebnissen von gestern waren ein paar Fehler drin…
Also es wird scheinbar doch ganz normales Serial auch für die Initialisierung verwendet.
Ich habe es nach einigen Schwierigkeiten hinbekommen, zumindest die eine Richtung der seriellen Kommunikation abzugreifen.
Hier der Mitschnitt, was beim Start von LXCCU an das Funkmodul gesendet wird:

FD 00 03 00 00 03 18 0A 
FD 00 03 00 01 03 9F 09 
FD 00 03 00 02 02 14 0C 
FD 00 04 00 03 0A 00 BD 07 
FD 00 04 00 04 09 00 37 68 
FD 00 03 00 05 21 58 FE 
FD 00 08 00 06 0E 56 CD 5A 70 02 5F FC 7C 
FD 00 04 01 07 03 00 9F 57 
FD 00 06 40 08 3D 1C 6E B5 33 
FD 00 09 00 11 06 42 D8 1F 00 00 00 4A AF 
FD 00 09 40 21 90 28 F7 04 00 00 7B A4 
FD 00 09 40 21 90 28 F7 04 00 00 6A A3 
FD 00 09 01 0C 06 42 DC 1F 00 00 00 1A B0

Kannst du da etwas dir bekanntes wiederfinden?

Hier noch ein Dump, für den ich im WebUI die Temperatur des Heizungsthermostats schrittweise von 18°C auf 21°C und zurück auf 18°C gestellt habe:

FD 00 12 01 0D 01 00 00 00 01 B0 11 3D 1C 6E 42 D8 1F 86 04 23 19 3A   (19°C)
FD 00 12 01 0E 02 00 00 00 12 B0 11 3D 1C 6E 42 D8    64 04 28 D0 5C   (20°C)
FD 00 12 01 0F 02 00 00 01 13 B0 11 3D 1E 6E 42 D8 1F 86 04 2A 92 3E   (21°C)
FD 00 12 01 10 02 00 00 01 1C B0 44 4F 8F 4B 61    1F 86 04 28 13 3E   (20°C)
FD 00 12 01 11 02 00 00 00 25 B0 11 3D 1C 6E 41 D8 1F 86 04 27 DE 87   (19°C)
FD 00 12 01 11 02 00 00 01 2E B0 11 3D 1C 6E 41 D8 1F 86 04 24 17 C9   (18°C)

Laut der XML-Datei habe ich da einen Messagetype 0x11 mit Subtype 0x86 an Channel 0x04 geschickt, die Adresse vom LXCCU scheint 0x3D1C6E (ist übrigens auch in der Initialisierung des Moduls wiederzufinden) und die des Thermostats 0x42D81F zu sein und der Messagecounter geht in diesem Block vermutlich von 0x0D bis 0x12 hoch.
Scheinbar habe ich allerdings beim Mitschnitt mit erheblichen Übertragungsfehlern zu kämpfen. Das wird vermutlich am Breadboard liegen Ich vermute, das einzige, was da hilft, ist, dass ich das anstatt über extra Hardware über sersniff o.ä. im Betriebssystem mach. Bei meinen bisherigen Versuchen bin ich da leider immer wieder an unzureichendem Wissen über Terminals und Pseudoterminals gescheitert…

Achja, als Übertragungsparameter für die serielle Verbindung habe ich 115200/8N1 angenommen. Kennst du eine Methode, wie ich das zuverlässig bestimmen kann? Wobei die obigen Ergebnisse ja auch schon nicht so schlecht aussehen.

Wie schätzt du denn basierend auf den bisherigen Protokollmitschnitten die Erfolgsaussichten ein? Ich denke, ich sollte es noch irgendwie hinbekommen, einen fehlerfreien Trace der Kommunikation zwischen LXCCU und HM-MOD-UART hinzubekommen, der auch beide Richtungen abdeckt.

stefan · October 2, 2016, 5:19pm

So, ich habe jetzt einen Dump, der keine Übertragungsfehler mehr enthält und konnte da auch schon ein paar Sachen rausziehen.

Die ganze Kommunikation mit dem HM-MOD-UART erfolgt über eine serielle Verbindung mit den Parametern 115200 Baud 8N1.

Ganz zu Anfang erfolgt eine Initialisierung des Funkmoduls. Das besteht u.a. scheinbar aus einem simplen Hello, Abfragen von Firmware-Informationen setzen (bzw. eher deaktivieren) von CSMA/CA, setzen der CCU-Adresse, …
Anschließend werden die Geräte-Adressen, die dem RFD(oder irgendwem darüber) bekannt sind, an das Funkmodul übertragen. Scheinbar übernimmt bereits das Funkmodul das Wegfiltern von “fremden” Paketen. Aus einem mir unbekannten Grund wird dem Modul dabei jede Geräteadresse gleich viermal genannt…
Danach geht das der RFD und das Modul in den normalen Betrieb über schickt die üblichen Befehle und Statusänderungen an die Geräte…

Der allgemeine Aufbau eines Kommandos an das Modul ist folgendermaßen:

"FD 00" <1 Byte Länge> "00 | 01" <1 Byte Zähler> <Payload> <2 Byte Checksumme>

[ul]
[li] Die Länge wird ohne Präfix, Länge und Checksumme gezählt[/li]
[li] Im vierten Byte steht “00” vermutlich für “SystemCommand” und “01” für “BidCosRequest”.[/li]
[li] Der Zähler wird global gezählt und nicht pro Zieladdresse.[/li]
[li] Wenn es sich um einen BidCosRequest handelt, hat das erste Byte der Payload nochmal eine qualifizierende Funktion:
[list]
[] 0x02: Die “klassischen” BidCos-Pakete [/li]
[li] 0x06: Hinzufügen einer bekannten Device-Adresse[/li]
[li] 0x04: Responses, sowohl auf 0x02 als auch auf 0x06 und sogar auf SystemCommands…[/li][/ul][/:m][/list:u]
Bei 0x02-BidCos-Requests und bei 0x04-Antworten auf die 0x02-BidCos-Requests folgt anschließend immer die feste Folge “00 00 01 01” gefolgt von Control-Byte, Message-Type, Sender- und Empfänger-Adresse und den Parametern.

Den Abschluss bildet bei allen Messages eine Checksumme mit 2 Byte Länge… Bei der bin ich noch am knobeln, wie die berechnet wird. Wenn ich die rausbekomme, kann ich mal versuchen, direkt mit dem Funkmodul oder dem RFD zu sprechen…

Ich hänge mal einen Dump mit ein paar Anmerkungen an. Falls jemand eine Idee hat, wie man den unbekannten Teilen noch auf die Spur kommen könnte oder falls mir bei der Interpretation irgendwo ein Fehler unterlaufen ist, bin ich über Feedback dankbar.
HM-MOD-UART-Analyse.txt (4.5 KB)

stefan · October 2, 2016, 5:19pm

So, die Checksumme hab ich. Es wird ein CRC-16 mit Initial-Wert 0xD77F und dem Polynom 0x8005 von der ganzen Message inkl. Präfix und Länge verwendet.
Ich werde morgen mal sehen, ob ich es hinbekomme, auf dem Raspi über ein kleines selbstgeschriebenes Programm die Temperatur meines Thermostats zu ändern. Dazu müsste ich zwar einiges an hart kodierten und nicht komplett verstandenen Byte-Sequenzen Richtung HM-MOD-UART schieben und ein paar Rückgaben des Moduls weitestgehend unverstanden ignorieren.

Ich werde dann noch versuchen, das Modul mal gezielt mit Nonsens zu beschießen, um die Fehler-Antworten des Moduls identifizieren zu können. Außerdem werde ich noch sehen, ob ich rausbekomme, in welchen Situationen OCCU die Reset-Line verwendet. Da die aber laut Doku auch auf /dev/null gesetzt werden kann, ist das vermutlich nicht ganz so wichtig…

@Sathya: Wenn das klappt, was wäre noch nötig, bevor es mal experimental in Homegear aufgenommen werden könnte?
HM-MOD-UART-Analyse.txt (5.35 KB)

sathya · October 2, 2016, 5:19pm

Hallo Stefan,

danke für deine Analyse! Das hat echt geholfen! Soweit hättest du auch gar nicht gehen müssen, die Pakete sind denen des LAN-Gateways sehr ähnlich. Ich habe den HM-MOD-RPI-PCB dann auch gleich mal implementiert . Sieht soweit alles gut aus. Auch WoR-Pakete und Firmware-Updates klappen ohne Probleme. Jetzt braucht es Tester! Das Nonsens-Log wäre noch ganz interessant. Ich vermute aber mal, das Modul gibt dann NAKs zurück?

Viele Grüße

Sathya

stefan · October 2, 2016, 5:20pm

Mit dem Nonsens-Log hatte ich bisher etwas Probleme - ich habe jetzt mehrfach versucht, über ein kleines Java-Programm das Modul zu initialisieren (00 00 03) um danach loszulegen. Dazu hab ich beim ersten Mal testweise die Reset-Leitung mal kurz auf High gezogen und dann die Initialisierung versucht, da hat das Modul leider nicht mehr drauf geantwortet. Auch ein Start von LXCCU lief nicht mehr, da das Modul auch dem dem rfd scheinbar nicht geantwortet hat (Immerhin: Das Modul hat sich mir gegenüber genauso verhalten wie dem rfd gegenüber). Mehrfache Reboots des Containers und des RasPis haben nichts gebracht. Erst das neue aufspielen des LXCCU-Images hat das Modul wieder zum Reden gebracht
Wenn ich den Container ohne LXCCU starte und mit meinem Testprogramm das Modul initialisiere, hat es den gleichen finalen Effekt.
Wenn ich den Container starte und stoppe und dann mein Programm ranhänge, die serielle Verbindung also schon steht, bekomm ich anständige Ausgaben, also sowohl die Statusmeldungen der Devices als auch Antworten auf meine Messages (interessante Details: Der Counter ist nicht so wichtig - ich kann auch immer 00 schicken, bekomme dann aber ggfs Probleme damit, die Antworten auf meine Messages zuzuordnen. Anderes Detail: Es schadet scheinbar nicht, dem bereits initialisierten Modul eine erneute Initialisierungsaufforderung zu schicken. Man bekommt zwar die sauberen Antworten aber das Modul behält seine vorherige Konfiguration und wird nicht zurückgesetzt.)

Ich vermute aber, dass meine Probleme eher damit zusammenhängen, dass ich mit meinen Verbindungsversuchen immer irgendwas mit dem Serial-Terminal und dem LXC-Container durcheinanderbringe.

Bei dir klappt auch das frische initialisieren des Moduls mit der beschriebenen Sequenz?

Wo ist denn der entsprechende Teil vom LAN-Gateway-Protokoll beschrieben? Mich würden da mal die Teile interessieren, die ich nicht rausbekommen habe.

Als Tester stehe ich sehr gerne zur Verfügung, muss mir dazu aber vermutlich erstmal OpenHAB o.ä. aufsetzen…
Allerdings wirst du sicherlich noch weitere Tester benötigen, da mein Gerätepark mit den vier Heizungs- und einem Wandthermostat sehr überschaubar ist…
Hast du die aktuelle Implementierung in Github in einem Branch?

stefan · October 2, 2016, 5:20pm

Leider ist das mit dem Nonsens-Log ein Problem: Ich habe keine Ahnung, welche Messages falsch sind und welche existieren.
Was ich aber rausbekommen habe, ist dass ungültige Messages (falscher Präfix, falsche Checksumme, viertes Byte ungleich 00 oder 01, …) einfach ignoriert werden und keine Response bekommen. Wenn ich an gültige Messages hinten (noch in die Payload) zusätzliche Bytes anhänge, scheinen die einfach ignoriert zu werden und die Message wird akzeptiert.

sathya · October 2, 2016, 5:20pm

ok, das hilft aber doch schon einmal. Die NAKs wären zwar besser als keine Antwort (weil ich auf eine Antwort warte), aber solange wir aus Homegear keinen Blödsinn senden, sollte es keine Probleme geben.

Viele Grüße

Sathya

stefan · October 2, 2016, 5:20pm

Ich werde mal schauen, was so kommt, wenn ich reguläre BidCos-Messages mit unsinnigem Inhalt schicke (Temparatur außerhalb des Wertebereichs o.ä.). Da sollte ja eigentlich das entsprechende Device das verarbeiten und da würde ich dann schon ein NACK erwarten. Ich habe jetzt halt erstmal das Problem, ein NACK vom Modul überhaupt zu erkennen. Ich glaube, da gibt es was (viele unterschiedliche Meldungen führen alle zur gleichen Antwort), bin mir aber nicht sicher.

Ich habe heute mal in deinen Code reingeschaut, dabei ist mir aufgefallen, dass du bei der Initialisierung diese Messages, um dem Modul die relevanten Device-Adressen mitzuteilen, nicht schickst. Sind die nicht notwendig oder waren die nur in deinem aktuellen Setup nicht relevant, weil du nach dem Start eh das Pairing gemacht hast oder so?

sathya · October 2, 2016, 5:20pm

Meinst du diese hier in der Funktion sendPeer? https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/src/PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp#L517

stefan · October 2, 2016, 5:20pm

Ja, genau die hatte ich gesucht

Ich bin grade dabei, den Master auf dem Raspi zu kompilieren - du hast ja irgendwo geschrieben, dass es etwas dauert, aber das dauert ja echt ewig!

Gibt es eigentlich eine Möglichkeit, dass ich meine Geräte sowohl mit Homegear als auch mit LXCCU gleichzeitg gepaired haben kann? Hintergrund ist einfach, dass ich normalerweise mein einigermaßen stabiles LXCCU regulär laufen lassen will und erstmal nur auf die Experimentier–SD-Karte mit homegear und OpenHAB wechseln will, wenn ich aktiv damit arbeite.
Ich vermute, regulär ist es nicht möglich, da die Geräte ja nur mit maximal einer Zentrale koppeln können, aber kann ich z.B. in Homegear einfach die gleiche Device-Adresse für die Zentrale setzen, die rfd auch verwendet? Also die Adresse im <01 cc 00 AD DR ES>-Kommando beeinflussen? Dann sollte es doch eigentlich klappen, beide Zentralen im Wechsel miteinander zu betreiben (sofern ich darauf achte, dass beide Zentralen immer die gleichen gepairten Geräte kennen), oder?

Mir sind gestern übrigens noch drei Kleinigkeiten aufgefallen:
1.) Die Response <00 cc 04 04> scheint wohl irgendwie ein “Unbekanntes System-Kommando” oder “Modul in falschem Modus für dieses System-Kommando” o.ä. zu sein. Zumindest wird scheinbar auf mehrere der Syntax nach System-Kommandos diese gleiche Antwort geschickt (<00 cc 00> bis <00 cc 03> und <… 0A> bis <… 0D> reagieren irgendwie individuell und die übrigen werden alle mir <04 04> beantwortet.
2.) Irgendwie scheint es möglich zu sein zumindest temporär die Firmware-Version, die von <00 cc 02> geliefert wird, zu ändern bzw. zu löschen… Auf jeden Fall hatte die bei mir nach dem wilden Durchprobieren von Kommandos in dem Kommando für die Versionsabfrage einfach gefehlt…
3.) Irgendwie scheint es möglich zu sein, das Modul dazu zu bringen, den Präfix <FD 00> nicht mehr mitzusenden… Besonders irritierende ist, dass es auch mit der anderen SD-Card nicht mehr lief. Nach dem frischen Aufsetzen der SD-Card läuft es aber wieder korrekt…

Du hattest erwähnt, dass das Protokoll für den HM-MOD-UART sehr ähnlich dem Protokoll fürs LAN-Gateway ist - wo ist denn dazu was zu finden? Mich würden da insbesondere diese System-Kommandos interessieren. Im Netz habe ich nur einen Verweis auf das Protokoll von Homematic-Wired gefunden, aber das scheint sich doch deutlich von dem hier zu unterscheiden…

stefan · October 2, 2016, 5:20pm

Leider bekomm ich Homegear nicht zum laufen… Kompilieren und Installation der DEB-Pakete (libhomegear-base, homegear und homegear-homematicbidcos) läuft weitestgehend problemlos (die Abhängigkeiten, die in der Doku beschrieben, sind stimmen nicht oder sind nicht vollständig. Folgende Pakete musste ich noch installieren bzw. über “apt-get -f install” nachinstallieren lassen: libgnutlsxx28 libenchant1c2a libltdl7 libmcrypt4 libxslt1.1 p7zip-full php5-cli libqdbm14)

Folgendes steht (mehrfach) im Error-Log drin:

03/05/16 21:15:49.583 Error in file Systems/IPhysicalInterface.cpp line 330 in function virtual void BaseLib::Systems::IPhysicalInterface::openGPIO(uint32_t, bool): Failed to open GPIO value file "/sys/class/gpio/gpio18/value": Permission denied 03/05/16 21:15:49.584 Failed to set GPIO with index "1": Device not open. 03/05/16 21:15:49.684 Failed to set GPIO with index "1": Device not open. 03/05/16 21:16:19.685 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/05/16 21:16:21.601 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...

Die Berechtigungen auf /sys/class/gpio/gpio18/value sind 770 und Owner ist root:gpio. Laut “ps -elf|grep homegear” läuft der homegear-Prozess als User homegear und root. Laut “groups homegear” hat der User die Rolle gpio. Von daher sollte eigentlich alles zueinander passen.
Auch “sudo -u homegear touch /sys/class/gpio/gpio18/value” läuft erwartungsgemäß problemlos durch.

Zu dem “No Init packet received” habe ich leider nicht so wirklich einen Anhaltspunkt. Ich vermute, es ähnelt dem Problem, das ich am 01.03 um 20:37 hier schon mal beschrieben habe. Zuerst läuft LXCCU auf der einen SD-Karte, danach Homegear auf der zweiten Karte nicht und anschließend läuft LXCCU auf der ersten Karte wieder.
Aufgefallen ist mir in dem Zusammenhang auch, dass laut stty /dev/ttyAMA0 von LXCCU anders initialisiert wird als von Homegear:
LXCCU:

pi@rpi-lxccu ~ $ stty -a -F /dev/ttyAMA0
speed 115200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
-imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke
pi@rpi-lxccu ~ $ stty -g -F /dev/ttyAMA0
0:4:1cb2:a30:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Homegear:

root@raspberrypi:/home/pi# stty -a -F /dev/ttyAMA0 
speed 115200 baud; rows 24; columns 80; line = 0;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>; rprnt = <undef>;
werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
-imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke
root@raspberrypi:/home/pi# stty -g -F /dev/ttyAMA0 
0:0:10b2:0:0:0:0:0:0:0:1:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Hast du da eine Idee, wie ich das weiter analysieren könnte?

trilu · October 2, 2016, 5:20pm

Hallo Zusammen,
würde gerne mittesten - habe mir das Modul geholt und angeschlossen und auch in der Config eingetragen.
Jetzt bekomme ich ein
03/22/16 19:15:08.377 Module HomeMatic BidCoS: HM-MOD-RPI-PCB “My-HM-MOD-RPI-PCB”: Warning: Too small packet received: 0C000000436F5F4350EAFE

03/22/16 19:16:02.311 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:16:02.312 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:16:04.247 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:16:04.248 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:16:06.250 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Connected to HM-MOD-RPI-PCB. 03/22/16 19:16:06.387 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too small packet received: 0C000000436F 03/22/16 19:16:06.388 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too small packet received: 0C000000436F 03/22/16 19:16:06.389 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too large packet received: 5F4350555F424C7251 03/22/16 19:16:06.390 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too large packet received: 5F4350555F424C7251 03/22/16 19:16:36.352 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:16:36.352 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:16:37.421 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:16:37.422 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:16:39.422 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Connected to HM-MOD-RPI-PCB. 03/22/16 19:16:39.559 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too small packet received: 0C000000436F 03/22/16 19:16:39.559 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Too small packet received: 0C000000436F 03/22/16 19:17:09.523 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:17:09.523 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 03/22/16 19:17:10.591 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:17:10.591 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:17:12.592 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Connected to HM-MOD-RPI-PCB. 03/22/16 19:17:12.729 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (3). Trying to reconnect... 03/22/16 19:17:12.729 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (3). Trying to reconnect... 03/22/16 19:17:13.729 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 03/22/16 19:17:13.729 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect...
Jemand eine Idee?

HM_Perry · October 2, 2016, 5:20pm

hallo zusammen

@Stefan
Der Fehler der Berechtigungen ist ein Grundlegendes Problem von Raspian 8
Im folgenden Beitrag ist die Lösung dazu beschrieben:
viewtopic.php?f=18&t=411#p2660

Hat bei mir geholfen.

Grüsse

Silvan

trilu · October 2, 2016, 5:20pm

Super, Danke für den Hinweis. Lag nicht an den Regeln für GPIO aber brachte mich in die richtige Richtung.
Bei mir war der serielle Port vom System belegt.
raspi-config
Advanced settings
Serielle ausgeschaltet
reboot

Jetzt mault Homegear nicht mehr und ich kann testen…

sathya · October 2, 2016, 5:20pm

Hallo Stefan,

Ja. Zum Teil musst du in Homegear die Geräte-Konfiguration auf die gleichen Werte wie auf der LXCCU setzen, damit es korrekt funktioniert.

Leider nirgendwo. Da musst du Quelltext wälzen.

Viele Grüße

Sathya

docmic · October 2, 2016, 5:20pm

Habe Dank der Anmerkungen weiter vorne (udevs) die Fehlermeldung wegen fehlender Zugriffsrechte auf GPIO wegbekommen.

Was bleibt ist das hier:

05/31/16 21:05:45.120 Debug: Sleeping 98ms before sending response. 05/31/16 21:05:45.218 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900 05/31/16 21:05:45.318 UPnP Server: Debug: Sending notify packets. 05/31/16 21:05:45.349 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received. 05/31/16 21:05:47.263 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: Connection closed (1). Trying to reconnect... 05/31/16 21:05:47.264 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Connecting to HM-MOD-RPI-PCB... 05/31/16 21:05:49.265 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Connected to HM-MOD-RPI-PCB. 05/31/16 21:05:49.265 Debug: GPIO 18 set to 0. 05/31/16 21:05:49.365 Debug: GPIO 18 set to 1. 05/31/16 21:05:51.550 Debug: checkHealth returned ok. 05/31/16 21:06:01.650 Debug: checkHealth returned ok. 05/31/16 21:06:07.873 Debug: SSDP server: Binding to address: 192.168.178.36 05/31/16 21:06:07.873 Debug: Searching for SSDP devices ... 05/31/16 21:06:11.751 Debug: checkHealth returned ok. 05/31/16 21:06:15.146 UPnP Server: Debug: Discovery packet received from 239.255.255.250:1900 05/31/16 21:06:15.167 Debug: Sleeping 152ms before sending response. 05/31/16 21:06:15.319 UPnP Server: Debug: Sending discovery response packets to 239.255.255.250 on port 1900 05/31/16 21:06:15.419 UPnP Server: Debug: Sending notify packets. 05/31/16 21:06:19.366 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Error: No init packet received.

Habe die serielle Konsole ziemlich sicher abgeschaltet.
Der Error: No init packet received bleibt.

Bin ratlos

(Hardware: Raspberry 2, Raspbian Jessie lite, HM-MOD-RPI-PCB)

shizzleslick · October 2, 2016, 5:20pm

Moin docmic,

Schau doch bitte (auch wenn Du Dir sicher bist, die serielle Konsole abgeschaltet zu haben) in die /etc/inittab und /boot/cmdline.txt. Für mich sieht Deine Fehlermeldung so aus, daß homegear ein “anderes device” “anbindet” anstatt das Funkmodul.
Nur eine Idee.

Gruß,
shizzleslick

docmic · October 2, 2016, 5:20pm

Hallo shizzleslick,

blöd halt, das das log ziemlich ausführlich ist, nur nirgendwo steht was der Grund des ein oder anderen Eintrags ist. Ich werd wohl mal Sourcode anschauen…

Mein raspbian jessie hat keine inittab, deshalb habe ich versucht die Konsole mit

[code]systemctl stop serial-getty@ttyAMA0.service[code]
abzustellen.

In der Tat war aber in der cmdline.txt noch ein

und dmesg vermeldet auch

entferne ich den console=tty Eintrag ändert das aber leider garnichts…
dmesg zeigt nach wie vor dasselbe und homegear wirft “No init packet received”

…oder muss ich wenn ich keine Konsole will hier das /dev/nul angeben??

docmic · October 2, 2016, 5:20pm

und noch ein paar “Forschungsergebnisse”

mit dem “original” homematic Image läuft das HM-MOD-RPI-PCB einwandfrei auf dem Raspberry 2
Sourcecode
da sieht die Stelle die den “init packet” Fehler wirft so aus, also ob das System am GPIO 18 einen Impuls produziert und dann wohl auf eine Art “Hallo ich bin da Paket” vom HM-MOD-RPI-PCB Controller wartet.

Und das kommt nicht.
2 mögliche Ursachen
a) der GPIO 18 macht den Impuls nicht - das checke ich am Wochenende mal mit einem Oszi
b) der Controller antwortet, der Rapsi kriegt das aber auf der ttyAMA0 nicht mit - das müsste man auch mit dem Oszi sehen

Kann ich auf dem Raspi irgendwie raufinder “wer” sonst noch auf der ttyAMA0 sitzt?
Wenn ich mincom draufsetze läuft das ohne zu murren…

docmic · October 2, 2016, 5:20pm

so…
Hier also was das Oszilloskop sagt.

Kanal 1 ist der GPIO18 der zum HM-MOD geht (Pin 12).

der macht brav ca. alle 30 Sekunden einen low-Impuls

Kanal 2 ist RX-UART vom Raspberry (Pin 10) - also das was der Raspberry vom HM-MOD hört

da ist tatsächlich eine saubere Antwort in Form eines 1500 µs langen seriellen Pakets

…das ist mit Sicherheit das ominöse “init paket” auf das homegear wartet

…aber dort nicht ankommt, weil irgendwas mit dem ttyAMA0 klemmt.

Aber was, und wie finde ich das raus???