HM-CC-RT-DN: motorErr communicationERR, trotzdem alles ok

[yetiman]

Hallo Martin,

konntest du damit etwas anfangen? brauchst du mehr logs?

Ingo

[martinp876]

Die logs sollten reichen. Da fehlen acks, wenn das alles ist, was geloggt wurde. Muss ich einmal testen

[Mr. P]

Hej Martin,

muss mich Ingo wohl anschließen. Vorhin noch ein FW-Update eines RTs gemacht und jetzt die selbe Fehlermeldung.
Kann jetzt nicht mehr ins Zimmer, um den RT neu zu starten, weil meine zweite Hälfte schon im Bettchen ist - aber genauso wenig, wie ich den Fehler jetzt weg bekomme, gelingt es mir auf meinen anderen RTs ihn zu reproduzieren. :-/

Im Moment läuft bei mir alles über einen CUL (COC), bis mein HM-CFG-USB-2-Stick wieder da ist, aber wenn ich auch noch mit Logs helfen kann, lass es mich bitte wissen.

Thx a lot!

[martinp876]

meinen rt kann ich ohne probleme mit einer CUL auslesen und bekomme die entsprechenden acks.
ich habe allerdings eine modifizierte CUL-FW, die mit timestamps liefert und ein 00_CUL das ein entsprechendes timing daraus errechnet.
Die FW ist seit einiger zeit bei Rudi, der sie nicht einbaut - wegen irgendwelcher Bedenken.
Könnte sein, das es die Lage verbessert (ich würde eine CUL mit HM  nur mit timing-kontrolle nutzen, alles andere geht nicht wirklich)

[Markus-L]

Hallo -

Wie ist denn der aktuelle Stand bei dem Thema?

ich habe bei meiner Homematic installation genau das selbe (Fehler)Bild.
Ein richtiger Fehler ist es ja irgendwie nicht. Es funktioniert soweit alles wie es soll. Nur habe ich bei 10 Heizkörperthermostaten und 2 Wandthermostaten meistens den "MotorErr: CommunicationErr". Wenn ich das LogFile durchgehe finde ich auch immer mal wieder einzelne "OK"s darinnen.
Dabei ist vollkommen egal wie nah, oder weit weg die Thermostate vom Server weg sind.
Meine Konfig ist folgende:
Fhem auf Raspberry Pi 2 (gestern zu letzt aktualisiert: Featurelevel: 5.7)
Homematic über CUL mit Firmware V 1.65 CUL868

Ein bisschen fuchst mich das ganze schon. Wenn ich mir sicher wäre, dass die Sache weg ist wenn ich einen HM-LAN Adapter (oder den HM-USB-Stick kaufe wäre ich schon fast am bestellen...

Wenn ich irgendwas mache kann um dem Ursprung des Problems auf die Schliche zu kommen, meldet euch gerne!

[martinp876]

die CUL version welche bei mir funktioniert habe ich angepinnt

[ambiman]

Hall zusammen,

ich hatte gestern Abend das gleiche Phänomen an einem meiner HM-CC-RT-DN.
Blinkendes Antennensymbol und das Reading motorErr stand auf communicationErr, die Funktion (also bspw. set desired-temp etc.) war davon nicht beeinträchtigt - alles funktionierte wie zuvor.

Ich habe das Thermostat heute morgen neu angelernt und alles ist wieder OK.

Weiß man zwischenzeitlich woran das liegt ?

Hier noch ein paar Infos zu meinen Versionen:

Code Auswählen Erweitern


fhem.pl          10116 2015-12-06 19:44:51Z rudolfkoenig 
00_CUL.pm        10146 2015-12-10 10:17:42Z rudolfkoenig
10_CUL_HM.pm     10166 2015-12-13 17:36:21Z martinp876


CUL:

Code Auswählen Erweitern


VERSION V 1.61 CUL868


Viele Grüße,

ambiman

[ambiman]

Heute morgen das gleiche Bild: Blinkendes Antennensymbol und das Reading motorErr steht auf communicationERR.
Interessanterweise steht auch das Reading aesCommToDev auf fail:

Code Auswählen Erweitern


     2015-12-29 11:49:15   aesCommToDev    fail
     2015-12-29 17:02:25   aesKeyNbr       02
     2015-12-29 11:49:16   aesReqTo        VCCU_0


Ich werde nun nochmals ein assignHmKey durchführen und berichten ob sich die Situation in irgendeiner Weise verändert.

[KilO76]

Hallo zusammen,

gibt es für dieses Problem mittlerweile eine Lösung?
Ich habe bei mir einen zweiten CUL im HM Mode an meinen RasPi gesteckt und einen einzelnen RT Thermostat eingerichtet. Nun tritt bei mir das selbe Problem mit dem motorErr: communicationERR und blinkendem Antennensymbol auf.
Der CUL hat die aktuelle Firmware 1.66 drauf, und FHEM ist auch auf dem neuesten Stand. Zu Beginn (direkt nach dem pairen) war alles ok, aber nach ein paar Minuten kam statt ok nur noch communicationERR bei motorERR.

Danke und Gruß,
Oliver

[Pit@Jura]

Hallo Gemeinde,
auch als Neu-User kann ich diesen Fehler bestätigen. Gestern war der Fehler nach Batterie Tausch mehrere Stunden weg. Heute Abend haben beide Heizungsregler wieder das gleiche Fehlerbild. Im Einsatz: Raspi2, fhme 5.7, CUL neue SW 1.66. Gerne nehme ich Log und sende sie an den Experten...
Gruss
Pit

[Ron87]

Hallo zusammen, hallo Pit,

da ich vor einer Woche den selben Fehler hatte bin ich auf diesen Beitrag gestoßen.
Erstmal eine kurze Zusammenfassung:
Mein Zustand Raspberry 2 Model-B mit Jessy und FHEM 5.7 mit Selbstbau CUL SW 1.66 im HM Mode. Bis jetzt habe ich nur Homematic Komponenten in FHEM integriert.
Nachdem ich meine Logs auf SQLite umstellen wollte und ein Update schief gelaufen ist, kam ich nicht mehr per SSH auf den Pi und einige Einstellungsdateien waren geschädigt. Also einmal neu aufsetzen mit Debian Jessy und alles neu anlernen, wobei die Geräte sich ja schon einmal kannten.
Dabei bekam ich ich den "communicationERR" bei mehreren Thermostaten.

Mein Vorgehen:
Ich habe das Modul HMinfo "eingerichtet" um zu prüfen ob beim Peering mit meinen Fensterkontakten etwas schief gelaufen ist.
Siehe da das Modul hat mir auch direkt die Fehler gemeldet. (Aufzurufen über: get hm peerCheck)
Ich habe dann den CUL erstmal vom Raspberry abgesteckt. Die Fensterkontakte mit den Thermostaten verbunden. Sprich
1. Thermostat auf Werkseinstellung
2. Anlernmodus am Thermostat
3. Fensterkontakte anlernen (Achtung bei meinen Kontakten HM-SEC-SCo sollten die Fenster geschlossen sein) sprich den Knopf am Fensterkontakt betätigen.
Jetzt kommunizieren die Kontakte und Thermostate schon miteinander
Bei mir war dies nur bei zwei Thermostaten nötig die restlichen Komponenten kannten sich schon.

Diese Schritte habe ich für alle Thermostate wiederholt.
4. CUL anstecken und FHEM auf den Bildschirm rufen kontrollieren ob autocreate aktiviert ist
5. Thermostat wieder in den Anlernmodus bringen und sich zum Rechner begeben
6. Kontrollieren ob das Thermostat gefunden wurde, wenn ja umbenennen und wegsortieren, der Rest kann später nachgeholt werden.
7. Prüfen ob der entsprechende Fensterkontakt auch in FHEM auftaucht und ob noch CMDs anstehen (CMDs_pending)
8. Den Knopf am Fensterkontakt kurz betätigen und aufs blinken achten.
  8a. Schnelles Blinken und eine abschließende grüne LED sind ein gutes Zeichen.
  8b. Langsames Blinken..... abwarten bis es aufhört, dann Fenster öffnen und schließen und nochmals den Knopf drücken. Jetzt sollte es auch schnell blinken
9. in FHEM kontrollieren ob alle Pairs und Peers stimmen. --> HMinfo + manuelle optische Prüfung  Siehe da selbst die korrekte Namenszuweisung passt!

Danach hatte ich nur noch bei zwei Thermostaten den communicationERR. Jedoch ließ sich einer recht schnell durch das Auswechseln der Batterien des Fenstersensors eliminieren (in FHEM noch ok, bei Betätigung des Knopfes fing die LED jedoch schon an nur noch zu glimmen)

Ich habe danach einfach ein-zwei Tage abgewartet und alles normal weitergemacht und siehe da alle Fehler weg.
Ich denke der letzte Fehler ist übrig geblieben da an diesem Tag eine Menge Traffic zustande gekommen ist (habe nicht nachgerechnet wie viel -> Siehe Suche 1%Regel) und ich mich einfach mal in Geduld üben wollte bis die Thermostate alle Anfragen/Kommandos selbst verarbeitet haben.

Vielleicht hilft dir oder jemand anderem diese Vorgehensweise ja auch. Ansonsten können wir auch gerne nochmal unsere Readings und Logs abgleichen.

Gruß
Ron