Hallo Silvan,
leider noch nicht…
Viele Grüße
Sathya
Hallo Sathya,
da jetzt bei ELV die Lieferzeit auf wenige Tage gesunken ist, sollte mein HM-MOD-RPI-PCB hoffentlich die Tage endlich in der Post liegen.
Gibt es da zu dem Support in Homegear schon was Neuigkeiten?
Falls du an der Stelle noch keine Zeit hattest, die Unterstützung für dieses Funkmodul einzubauen, kann ich da gerne mal mein Glück versuchen bzw. dich unterstützen. Ich würde da erstmal zusehen, dass ich mir ansehe, was die OCCU so über Serial auf das Modul schickt. Gibt es irgendwo eine “Highlevel” Protokollbeschreibung fürs Pairing und so?
EDIT: Ich hab grad im Wiki einiges gefunden. Dann bau ich mir mal was, um die Serial-Kommunikation mitzuschneiden und werd mal sehen, ob ich was aus dem Wiki bekanntes wiederfinde…
Hallo Stefan,
das wäre richtig klasse! Ich habe im Moment leider recht wenig Zeit für solche Analysen. Poste gerne, was du hast. Vielleicht kann ich dir bei der Analyse helfen. Sobald wir die Grundinformationen zusammen haben, werde ich das Teil implementieren.
Es wird folgendes in der Kommunikation geben:
[ul]
[li] Initialisierung mit Setzen der Uhrzeit und der AES-Schlüssel[/li]
[li] Senden der Peers auf welche geantwortet werden soll[/li]
[li] Das Senden und Empfangen von Paketen an sich[/li]
[li] Setzen von Parametern beim Aktivieren/Deaktivieren von AES[/li]
[li] Setzen von Parametern, wenn ein Wake-up-Paket aussteht.[/li][/ul]
Viele Grüße
Sathya
So, ich hab jetzt hier die ersten Bytes aus der seriellen Leitung. Da ich momentan ttyAMA0 per interceptty an der lxccu abgegriffen habe, fange ich anscheinend nur die Pakete, die von den Geräten an die CCU gesendet werden, ab. Das hat zur Folge, dass ich zum einen die Pakete von der CCU an die Geräte nicht sehe und dass zum anderen die CCU die Pakete der Geräte nicht bekommt.
Ist zwar schade, aber man immerhin bekomme ich überhaupt erstmal was zu sehen 
Anscheinend geht wirklich weitestgehend das Binary-Format, das du im Wiki beschrieben hast, auch über die serielle Leitung. Im meinem aktuellen Setup ist ein HM-CC-RT-DN an der lxccu angelernt. Darüber hinaus habe ich noch drei weitere HM-CC-RT-DN’s und ein HM-TC-IT-WM-W-EU (der Nachfolger vom HM-CC-TC) in Reichweite im Betrieb.
Ich habe 0x70-Pakete vom Wandthermostat dabei, die ich anhand deiner Paket-Beschreibung sauber lesen und kann und deren Werte ich auch über das Display des Thermostats verifizieren kann. Was mich nur irritiert, ist, dass die Länge im Paket-Header scheinbar falsch ist. So zum Beispiel im Folgenden 0x70-Paket:
3b 45 84 70 3c94de 000000 00d3288743fd001501ed050000Laut deiner Paket-Beschreibung sollte das 0x70 eine Länge von 12 haben, hier ist aber eine Länge von 59 angegeben und die tatsächliche Länge scheint 22 zu sein. Ich habe hier auch noch reichlich andere Pakete, bei denen die Länge scheinbar nicht wirklich passt. So ist zum Beispiel teilweise die tatsächliche Anzahl der Bytes zwischen den Paketen identisch aber die Länge im Header weicht voneinander ab oder die Pakete haben laut Header die gleiche Länge aber die tatsächliche Anzahl Bytes ist unterschiedlich. Letztendlich ist die Länge im Header aber immer deutlich größer als die tatsächliche Paketlänge 
Außerdem scheint das Controlbyte teilweise von deinen Beschreibungen des jeweiligen Messagetyps abzuweichen. So haben zum Beispiel die 0x70-Pakete das Controlbyte 0x84 statt die 0x86 aus deiner Beschreibung.
Hast du eine Ahnung, was es mit diesen Abweichungen auf sich hat?
Im Anhang habe ich mal meinen Dump der seriellen Schnittstelle angehängt. (Dump ist ungefiltert, Zeilenumbrüche an den vermuteten Paketanfängen, Paketanfänge aus den vermuteten Source-Adressen 42d81f und 3c94de und fortlaufenden Message Countern abgeleitet)
serial-dump.tgz (2.8 KB)
Hmm… aktuell sieht es nicht so doll aus. Anscheinend schickt LXCCU beim Start des rfd-Daemons eine Bit-Sequenz an den Adapter, der von den Timings her nicht sonderlich nach klassischem Serial aussieht:
LOW für 504 bis 516 µs
HIGH für 4.500.412 bis 4.500.792µs
LOW für 424 bis 452µs
HIGH für 260 bis 272µs
LOW für 256 bis 268µs
HIGH für 998.804 bis 999.608µs
LOW für 420 bis 428µs
HIGH für 256 bis 272µs
LOW für 256 bis 264µs
(Timings aus sechs rfd-Starts ermittelt)
Laut dem Error-Log beim Restart vom rfd scheint das zum einen mit dem “Start der Coprocessor Application” und dem Deaktivieren vom CSMA/CA zusammenzuhängen. Wenn ich raten müßte, ist das erste LOW der Start der “Coprocessor Application” (mit vergessenem Errorhandling) und dem anschließenden Kommando zur Deaktivierung von CSMA/CA mit Retry, da mein Arduino keine passende Bestätigung gesendet hat.
Ich werde morgen mal schauen, ab ich mal einen kompletten erfolgreichen “Handshake” zwischen rfd und dem Funkmodul und dem anschließenden Wechsel auf Serial abgreifen kann.
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.
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)
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)
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
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?
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.
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
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?
Meinst du diese hier in der Funktion sendPeer? https://github.com/Homegear/Homegear-HomeMaticBidCoS/blob/master/src/PhysicalInterfaces/Hm-Mod-Rpi-Pcb.cpp#L517
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…
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:0Homegear:
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:0Hast du da eine Idee, wie ich das weiter analysieren könnte?
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?
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
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…
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