Hm. Da bin ich ein bisschen raus… habe selbst kein HM-MOD-RPI-PCB.
@sathya, kannst du was zu sagen?
Ich habe auch homegear 0.7.10-1397 mit dem HM-MOD-RPI-PCB im Einsatz, das Problem kenne ich nicht. Es sollte also kein grundsätzliches Problem dieser Konstellation sein. (Openhab läuft auch noch auf dem PI.)
Kann es mit anderen Einstellungen zu tun haben? Oder Stromzufuhr, Hitze, etc?
Zur Firmware, ich habe einmal ein Update gemacht, und zwar auf Version 1.4.1, danach habe ich das nicht mehr beachtet.
Je nu, was soll ich da antworten? Ja, es kann mit anderen Einstellungen zu tun. Genau genommen kann es an so ziemlich allem liegen.
Der Pi3 laeuft seit Wochen ohne Probleme, bis zum Upgrade hat homegear problemlos gearbeitet, RaspberryMatic hat keine Probleme gesehen - von daher wuerde ich jetzt erstmal davon ausgehen, dass die HW ok ist und solche Sachen wie Stromzufuhr, Hitze usw. ausschliessen.
Gar nichts, das war eine rethorische Frage. 
OK, hast Du irgendetwas Besonderes in der config.txt / cmdline.txt? Irgendwelche besondere Hardware? Ich meine nicht, dass etwas kaputt ist, sondern nur, dass es sich in der speziellen Konstellation etwas anders verhält.
Ich habe Blueetooth abgeschaltet, WLAN ist auf dem mini-UART, aber vollständig abgeschaltet, da ich über LAN verbunden bin, und mich das HM-Binding von OpenHAB immer mit der falschen IP genervt hat. IPV6 habe ich auch aus. Das sind so die Veränderungen an die ich mich aus dem Stehgreif erinnere.
Als zusätziche Hardware habe ich nur noch eine Echtzeituhr.
Meine Basis ist übrigens OpenHABian 1.3.
1 Like
Noch etwas, ich habe genau die gleichen Geräte wie Du, bis auf HM-WDS10-TH-O.
Versuch doch mal bitte, das Gerät zu entfernen. Vielleicht funktioniert in der aktuellsten Version mit diesem Gerät etwas nicht.
Ich habe auch OpenHABian, meine config sieht so aus:
cmdline.txt
dwc_otg.lpm_enable=0 root=PARTUUID=86d0c08e-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
config.txt
dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt
dtoverlay=pi3-miniuart-bt
dtparam=spi=on
dtparam=i2c_arm=on
enable_uart=1
und homematicbidcos.conf:
[HomeMatic Wireless Module for Raspberry Pi]
id = My-HM-MOD-RPI-PCB
default = true
deviceType = hm-mod-rpi-pcb
device = /dev/ttyS0
responseDelay = 95
gpio1 = 18
Der Pi ist nur fuer Openhab da, ausser dem HM-MOD-RPI-PCB ist da sonst keine Hardware dran.
HM-WDS10-TH-O ist wohl ein Wall-mounted-Thermostat. Ich glaube zwar nicht, dass es daran liegt, probiere es aber mal aus, wenn ich wieder da bin.
Wie hast du das Firmware-Update gemacht und woher weisst du, welche Firmware-Version du jetzt hast?
cmdline.txt:
dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=e23af866-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
config.txt:
dtparam=i2c_arm=on
dtparam=spi=on
dtparam=audio=on
gpu_mem=16
enable_uart=1
dtoverlay=pi3-disable-bt
dtoverlay=pi3-miniuart-wifi
homematicbidcos.conf:
id = My-HM-MOD-RPI-PCB
default = true
deviceType = hm-mod-rpi-pcb
device = /dev/ttyAMA0
responseDelay = 95
gpio1 = 18
Die Dateien sehen alle ziemlich gleich aus, ausser console=tty1. Kann es sein, dass bei deinem homegear die Konsole noch auf ttyAMA0 gemappt ist? So dass homegear dann irgendeinen Müll bekommt? Das würde auch erklären, warum dein RaspberryMatic-Image funktioniert.
Ich habe mir aus dem Internet das Tool (hmcfgusb) heruntergeladen, sowie eine Firmware HM-MOD-UART-141.eq3. Vor dem Firmware-Update ging gar nichts, daher gehe ich davon aus, jetzt die 1.4.1 zu haben.
Ok, ich glaube das wars. Fuer die passiven Mitleser:
hmcfgusb habe ich aus https://git.zerfleddert.de/hmcfgusb/ per
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb
make
installiert.
Die Firmware HM-MOD-UART-141.eq3 habe ich unter https://git.zerfleddert.de/hmcfgusb/firmware/ gefunden, runtergeladen und per
./flash-hmmoduart -U /dev/ttyAMA0 HM-MOD-UART-141.eq3
PS:
- Ich hatte irgendwo gelesen, dass die richtige Firmware unter https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3 runterzuladen waere. Diese Firmware hat bei mir nicht funktioniert. Auch der Versuch mit RaspiMatic, welche automatisch die “richtige” Firmware installiert, hat nicht funktioniert.
- Fuer die ganz aufmerksamen Leser: vor dem upgrade hat mein homegear auf ttyS0 zugegriffen, jetzt auf ttyAMA0. Ich habe so ziemlich alle moeglichen Kombinationen von config.txt und cmdline.txt durchprobiert und dabei wohl irgendwas verbastelt. Das scheint aber aber eine generelles Pi3-Problem zu sein: man weiss nie genau, welche Schnittstelle richtig ist, und so richtig testen kann man das wohl auch nicht.
PPS:
Danke job!
1 Like
Schade, so ganz war es das dann doch nicht. Remote sah alles gut, der homegear hat die Temperaturen der Thermostate ordentlich geliefert. In der Wohnung habe ich dann aber festgestellt, dass er Statusaenderungen an den Fensterkontakten nicht sieht und Temperaturbefehle an den Thermostaten nicht ankommen.
Mein Smart-Home ist momentan ziemlich passiv
Kannst du die Probleme etwas präzisieren? Eine öffnung des Fensters wird in homegear nicht gesehen? Oder geht die nicht nach OpenHAB?
Wie sendest du die Temperaturbefehle?
Ich habe z. B. alle zur Heizung gehörenden Geräte direkt verknüpft. Die Heizung läuft also größtenteils autark. Fensterkontakte senden Status an Thermostate, Wandthermostate sind mit den Heizkörpern verknüpft. Homegear/openHAB sind hier meist dokumentierend eingesetzt.
Sende ich z. B. Boost über openHAB an die Thermostate, sehe ich, dass es am Heizkörper ankommt. In openHAB nicht immer, wenn Boost an ist scheint der Heizkörper ein merkwürdiges Sendeverhalten zu haben.
Die Oeffnung eines Fensters wird in homegear nicht gesehen. Der Fensterkontakt blinkt ein paar Sekunden gelb, dann einmal rot und geht dann wieder auf gruen.
Temperatur regele ich per openhab. Ich habe keine Geraete direkt miteinander verknuepft, ich mache alles ueber openhab.
Erhoehe ich per openhab die Temp eines Heizkoerper-Thermostates, sieht das im homegear.log so aus:
11/08/17 08:57:30.719 RPC Server (Port 2001): Info: Client number 10574 is calling RPC method: setValue (2) Parameters:
(String) OEQ0659834:4
(String) SET_TEMPERATURE
(Float) 20
11/08/17 08:57:30.721 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: Sending (My-HM-MOD-RPI-PCB): 0CAAB011FD18015AC92A860428
11/08/17 08:57:33.283 RPC Server (Port 2001): Info: Connection from ::ffff:192.168.178.68:51342 accepted. Client number: 10596
11/08/17 08:57:33.284 RPC Server (Port 2001): Info: RPC server client id for client number 10596 is: 401
11/08/17 08:57:33.285 RPC Server (Port 2001): Info: Client number 10596 is calling RPC method: setValue (2) Parameters:
(String) OEQ0659834:4
(String) SET_TEMPERATURE
(Float) 20
11/08/17 08:57:34.094 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: No answer to packet 0CAAB011FD18015AC92A860428
11/08/17 08:57:35.852 RPC Server (Port 2001): Info: Client number 10596 is calling RPC method: listBidcosInterfaces (2) Parameters:
11/08/17 08:57:35.928 Module HomeMatic BidCoS: Info: Setting peer to unreachable, because the queue processing was interrupted.
11/08/17 08:57:35.929 Module HomeMatic BidCoS: Info: Queue is not finished (peer: 1). Retrying...
11/08/17 08:57:36.029 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: Sending (My-HM-MOD-RPI-PCB): 0CABB011FD18015AC92A860428
11/08/17 08:57:37.199 HomeMatic BidCoS packet received (My-HM-MOD-RPI-PCB, RSSI: -58 dBm): 0921A03F541705FDAC9A
11/08/17 08:57:39.413 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: No answer to packet 0CABB011FD18015AC92A860428
11/08/17 08:57:39.413 Module HomeMatic BidCoS: Info: Setting peer to unreachable, because the queue processing was interrupted.
11/08/17 08:57:39.413 Module HomeMatic BidCoS: Info: Queue is not finished (peer: 1). Retrying...
11/08/17 08:57:39.414 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: Sending (My-HM-MOD-RPI-PCB): 0CABB011FD18015AC92A860428
11/08/17 08:57:42.734 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: No answer to packet 0CABB011FD18015AC92A860428
11/08/17 08:57:42.734 Module HomeMatic BidCoS: Info: Setting peer to unreachable, because the queue processing was interrupted.
11/08/17 08:57:42.734 Module HomeMatic BidCoS: Info: Queue is not finished (peer: 1). Retrying...
11/08/17 08:57:42.735 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: Sending (My-HM-MOD-RPI-PCB): 0CABB011FD18015AC92A860428
11/08/17 08:57:46.185 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Info: No answer to packet 0CABB011FD18015AC92A860428
11/08/17 08:57:46.186 Module HomeMatic BidCoS: Info: Setting peer to unreachable, because the queue processing was interrupted.
11/08/17 08:57:46.186 Info: Peer 1 is unreachable.
11/08/17 08:57:47.671 Info: Peer 1 is reachable again.
11/08/17 08:57:48.327 HomeMatic BidCoS packet received (My-HM-MOD-RPI-PCB, RSSI: -59 dBm): 0C3F865A541705000000A0B634
11/08/17 08:57:48.328 Module HomeMatic BidCoS: Info: ACTUAL_HUMIDITY on channel 2 of HomeMatic BidCoS peer 4 with serial number OEQ0147562 was set to 0x34.
11/08/17 08:57:48.328 Module HomeMatic BidCoS: Info: ACTUAL_TEMPERATURE on channel 2 of HomeMatic BidCoS peer 4 with serial number OEQ0147562 was set to 0x00B6.
11/08/17 08:57:48.328 Module HomeMatic BidCoS: Info: SET_TEMPERATURE on channel 2 of HomeMatic BidCoS peer 4 with serial number OEQ0147562 was set to 0x28.Das darf nicht sein. Rot bedeutet keine Verbindung. Passiert das auch, wenn du die Anlerntaste drückst? Ist der weit entfernt?
Nicht besonders weit, auf die ganz grosse Wohnung spare ich noch. Auf jeden Fall nicht zu weit - es hat ja mal funktioniert.
Tasten druecken kann ich erst wieder naechste Woche, wenn ich wieder in der Wohnung bin…
Hallo @valpo,
die Kommunikation mit dem HM-MOD-RPI-PCB scheint nun zu klappen. ttyAMA0 ist auch korrekt. Das Mini-UART (ttyS0) sollte nicht verwendet werden. Sicherheitshalber kannst du noch folgende drei Befehle als root ausführen:
systemctl disable serial-getty@ttyAMA0.service
systemctl disable serial-getty@serial0.service
systemctl disable serial-getty@ttyS0.service
Eine Möglichkeit, warum die Kommunikation nicht will ist, dass sich die Zentralenadresse geändert hat. Von welcher Homegear-Version kommst du? Vielleicht noch 0.5? Hast du centralAddress in der homematicbidcos.conf angepasst?
Viele Grüße
Sathya
Also homegear war vorher IMHO die 0.7.9. Die homematicbidcos.conf habe ich uebernommen, die centralAddress hat sich also nicht veraendert.
Wenn ich ein Geraet nochmal paire, kommt die Meldung:
11/12/17 08:08:00.923 Module HomeMatic BidCoS: Error: Pairing packet rejected, because this peer is already paired central with address 0xFDAC9A.
0xFDAC9A ist aber nicht meine centralAddress. Was bedeutet das?
Das bedeutet, dass die Geräte aus irgendeinem Grund an eine andere Zentralenadresse angelernt wurden (z.B. an die RaspberryMatic?). Werden die Geräte in Homegear denn hier aufgeführt:
homegear -r
fs 0
ls
Falls ja, ändere einfach mal centralAddress in der homematicbidcos.conf auf FDAC9A dann sollte es klappen. Ich würde im Anschluss sicherheitshalber die Geräte noch einmal in den Werkszustand versetzen und neu anlernen.
Viele Grüße
Sathya
Ja, mit “homegear -r, fs0, ls” sehe ich alle Geraete.
Aender ich die centralAddress auf FDAC9A, kann ich auch wieder die Thermostate steuern. Nur die Fensterkontakte melden nun:
11/12/17 16:39:51.650 Module HomeMatic BidCoS: HM-MOD-RPI-PCB "My-HM-MOD-RPI-PCB": Warning: AES handshake failed for packet: 0CCEA64152C804FDAC9A01120026
Eine Statusaenderung beim Fensteroeffnen/-schliessen kommt nicht am homegear an.
Hallo @valpo,
hast du die Fensterkontakte möglicherweise an RaspberryMatic angelernt? Den AES-Schlüssel in der homematicbidcos.conf hast du vermutlich nicht zwischenzeitlich geändert? Schau mal, ab ein Werksreset am Fensterkontakt funktioniert (nach dem erfolgreichen Reset leuchtet die LED in allen drei Farben, im Fehlerfall rot). Falls das funktioniert, ist der Standardschlüssel eingestellt gewesen (RaspberryMatic, YAHM, CCU). Dann einfach neu anlernen und alles sollte wieder funktionieren. Falls es nicht funktioniert, müssten wir rekonstruieren, was passiert ist (an welche Zentrale die Kontakte angelernt wurden). Wir brauchen nämlich dann den korrekten AES-Schlüssel.
Viele Grüße
Sathya
So, ich habe die Kontakte alle resettet, genau genommen habe ich fuer jeden Kontakt folgendes gemacht:
(Vorarbeiten: im Browser openhab mit paperui und den Things aufmachen, ebenso basicui mit der Uebersichts-Sitemap, eine shell mit “tail -f auf homegear.log und homegear.err” und eine weitere shell mit “homegear -r, fs 0”, das Ganze am besten auf einem Laptop, mit dem rennt man dann durchs Haus…)
- Reset am Kontakt: Knopf 5sec gedrueckt halten, bis rote LED langsam blinkt, dann loslassen, nochmal druecken bis rote LED schnell blinkt, wieder loslassen. Homegear meldet weiter, dass er mit diesem Peer nicht reden will, wegen AES.
- Geraet aus homegear entfernen (ID im openhab nachschauen, im homegear die peer id dazu raussuchen, dann "prs "). Im homegear.log passiert gar nichts.
- “pon 60” um das Geraet neu anzulernen, am Kontakt einmal kurz den Taster druecken. Jetzt wird homegear aktiv, es kommen Meldungen wie “Pushing pending queues.” (welche queue erfaehrt man nicht) und schliesslich "Removed HomeMatic BidCoS peer ".
- Nochmal “pon 60” und Taster druecken und der homegear lernt ganz brav das “neue” Geraet kennen und vergibt eine neue peer id. Im homegear.log steht dann u.a. “Successfully changed AES key of peer . Key index now is: 1”
Gluecklicherweise erkennt openhab die Geraete anhand der SerialNo, so dass auf der Ebene alles wieder funktioniert, ohne dass man noch Anpassungen vornehmen muss.
Gefuehlt ist in den Schritten oben irgendwie Redundanz drin, aber es hat funktioniert.
Nun scheint tatsaechlich alles zu laufen, vielen Dank fuer eure Hilfe! Hoffentlich bleibt das auch so, mein Vertrauensverhaeltnis zu meinem Smart-Home ist momentan etwas gestoert
2 Likes
Die Peer-ID könntest du auch von Hand wieder umsetzen:
sudo homegear -e rc '$hg->setId(<alte-id>, <neue-id>);'
1 Like