HM-CC-RT-DN nimmt keine Befehle mehr an

[uland2012]

Hallo,

ich habe mehrere HM-CC-RT-DN im Einsatz
System : FEHM auf Raspberry mit letzten update
RT: V1.2

Seit gestern (Samstag früh) nehmen die RT keine Befehle vom FHEM mehr an.

Die "decalcTime" habe ich auf Samstag 03.00 gesetzt. (Kann man das auch deaktivieren?)

Samstag früh nun folgender Effekt:
ALLE RT's haben eine blinkende Antenne

Nachdem ich alle neu gepaart habe, scheinbar erfolgreich, wenn ich auf die Antenne schaue,
ist im FHEM immer noch ein Dauer "Pending" und "CMDs-Processing" zu beobachten.

Einen RT habe ich komplett resetet und neu gepairt, mit offensichtlichem Erfolg.
Aber auch hier ein Dauer Pending und Processing.

Im Logfile habe ich folgenden Eintrag gefunden:
Use of uninitialized value $c[0] in regexp compilation at ./FHEM/01_FHEMWEB.pm line 1223.
(weiß nicht ob das damit zusammenhängt, ist aber ein neuer Effekt)

Den Raspberry habe ich auch schon neu gestartet.

Leider ohne Erlog.

Im Fhem werden händische Veränderungen am RT angezeigt.
Die Temperatur und Valve wird angezeigt.
Kontakt scheint zu bestehen. (?!)

Ich hoffe es gibt jemanden der eine Idee hat.

[betateilchen]

*grübel* sowas ähnliches wurde doch heute schonmal beschrieben:

http://forum.fhem.de/index.php/topic,19612.0.html

Sehr eigenartig. Bei mir funktionieren die RT aber auch nach dem heutigen fhem-Update.

[uland2012]

*grübel* sowas ähnliches wurde doch heute schonmal beschrieben:

http://forum.fhem.de/index.php/topic,19612.0.html

Sehr eigenartig. Bei mir funktionieren die RT aber auch nach dem heutigen fhem-Update.

Das ist ein nur ähnliches Verhalten.

Im anderen Fall habe ich das auch beobachtet, aber die über das GUI eingegebene Temperatur wird manchmal sehr zeitversetzt übermittelt.

Ist mit dem merkwürdigen Verhalten bei mir, aus meiner Sicht, erst einmal nicht gleich.

... heute morgen habe ich ein weiters Update der FHEM eingespielt.
Hier gab's auch ein Update für die "/FHEM/01_FHEMWEB.pm"

Leider ist der Effekt mit dem Dauer Processing und Pending nicht behoben.

[martinp876]

nun - wie immer hätte ich gerne die Messages im rohformat von den Aktionen.
Ausserdem ein List des Device.

Könnte sein, dass irgendwelche Kommandos im Stack hängen, die nicht verarbeitet werden. Das konnte dann dazu führen, dass x Versuche mit dieser Message gemacht werden (attribut gesteuert). Dann kommt die nächste.... Jeder Versuch dauert 2,5min... das dauert insgesamt mit unter sehr lange.

=> ein List, damit ich sehen kann, welche messages anstehen.
=> rohmessages, damit ich sehen kann, was das Device antwortet

++> clear protoEvents löscht den commandstack - dann könnte evtl der Mist gelöscht werden
Gruss Martin

[uland2012]

moin,

ich bin scheinbar wieder Herr über die Stellantriebe ....

Ich habe verschiedenste Infoschnipsel aus dem Forum zusammengetragen und konnte mir damit helfen.

- Antenne im Display der RT's blinkte.

- dann neu gepairt (zuerst mit hmPairForSec und boost Taste)

- später hab ich festgestellt, dass im FHEM Register der RT's die Seriennummer der RT's verschwunden war.
  ein "set xxxx pair" hat mir dann den Eintrag wieder zurück gebracht

- die im Stack aufgelaufenen Befehle (teilweise >30) habe ich dann jeweils mit "set xxxx burstXmit"
   an die RT's geschickt. Teilweise musste ich das mehrfach wieder holen.

- nachdem dann alle RT's wieder auf CMDs_done standen konnte ich wieder ordentlich mit den RT's "reden"

Wie es zu diesem Umstand kam, kann ich nicht genau sagen.
Ich vermute das hängt mit dem automatisierten "deCalc" zusammen (Vermutung)
Warum das aber bewirken soll, dass die Seriennummer der RT'S im FHEM Register gelöscht wird, weiß ich nicht.

Zumindest war am Samstag morgen (nach dem R-decalcTime um 03.00) die Verbindung unterbrochen, angezeigt durch die blinkende Antenne.

Vielleicht hilft dieser Eintrag einem weiteren User bei einem ähnlichen Fehler.

? kann man R-decalcTime oder R-decalcWeekday deaktivieren ?

Das war jetzt die 2.Woche wo ich ein Problem mit dieser Funktion habe.
Beim ersten Problem war es aber so, dass einige Stellantriebe gar nicht mehr zur Ruhe kamen und ständig auf und zu gingen.

Hier half nur Abbauen, abkühlen lassen und neu montieren.
Danach ging auch der Adaptieren wieder.

[Herr 3x]

Hallo,

ich habe das gleiche Problem: Die HM-CC-RT-DN nehmen keine Kommandos mehr über die Weboberfläche an.
Die Temperaturen/Ventilstellungen werden problemlos empfangen und geloggt.
Wenn ich die Temperatur setzte mit:

Code Auswählen Erweitern

2014.02.02 19:44:29 2: CUL_HM set HK2_ClimRT_tr desired-temp 18.5
Steht im Log:

Code Auswählen Erweitern

2014-02-02_19:44:46 HK2 battery: ok
2014-02-02_19:44:46 HK2 batteryLevel: 3 V
2014-02-02_19:44:46 HK2 measured-temp: 21.5
2014-02-02_19:44:46 HK2 desired-temp: 19
2014-02-02_19:47:22 HK2 battery: ok
2014-02-02_19:47:22 HK2 batteryLevel: 3 V
2014-02-02_19:47:22 HK2 measured-temp: 21.4
2014-02-02_19:47:22 HK2 desired-temp: 19
2014-02-02_19:47:22 HK2 actuator: 0 %
2014-02-02_19:49:44 HK2 battery: ok
2014-02-02_19:49:44 HK2 batteryLevel: 3 V
2014-02-02_19:49:44 HK2 measured-temp: 21.4
2014-02-02_19:49:44 HK2 desired-temp: 19
2014-02-02_19:49:44 HK2 actuator: 0 %
2014-02-02_19:51:51 HK2 battery: ok
2014-02-02_19:51:51 HK2 batteryLevel: 3 V
2014-02-02_19:51:51 HK2 measured-temp: 21.4
2014-02-02_19:51:51 HK2 desired-temp: 19
2014-02-02_19:51:51 HK2 actuator: 0 %
2014-02-02_19:51:54 HK2 ResndFail
2014-02-02_19:51:54 HK2 MISSING ACK

Im der Weboberfläche steht zum HK2:

Code Auswählen Erweitern

HMLAN1_MSGCNT 5
HMLAN1_RAWMSG E21DC2E,0000,2BAE5640,FF,FFB3,43861021DC2E0000000A98D60F0014
HMLAN1_RSSI -77
HMLAN1_TIME 2014-02-02 19:54:48
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 5
NAME HK2
NR 109
STATE MISSING ACK
TYPE CUL_HM
channel_01 HK2_Weather
channel_02 HK2_Climate
channel_03 HK2_WindowRec
channel_04 HK2_ClimRT_tr
channel_05 HK2_ClimaTeam
channel_06 HK2_remote
lastMsg No:43 - t:10 s:21DC2E d:000000 0A98D60F0014
protCmdDel 2
protLastRcv 2014-02-02 19:54:48
protResnd 3 last_at:2014-02-02 19:49:48
protResndFail 1 last_at:2014-02-02 19:51:54
protSnd 4 last_at:2014-02-02 19:51:51
protState CMDs_done_Errors:1
rssi_at_HMLAN1 avg:-76.59 min:-78 max:-76 lst:-77 cnt:5

Mir scheint das seit dem letzten Update so zu sein.

Nachtrag: Ein getConfig geht.

Herr 3x

[Herr 3x]

So, ich habe mal die eine Version von 10_CUL_HM.pm vom 25.01.14 aus den Backup geholt. Damit klappt die Temperaturänderung problemlos. Seitdem scheint der Bug reingekommen zu sein.

Herr 3x

[themaxx32000]

Hallo Herr 3x,

welche Version des 10_CUL_HM.pm wäre denn das? Ich habe nämlich auch ein sehr ähnliches Problem...

[sebixvi]

Moin,

wie im anderen Thread schon beschrieben, mühe ich mich ebenfalls mit einem HM-CC-RT-DN, der sich zwar pairen und auslesen lässt, den jegliche Änderungen aber kalt lassen.

Hier mal ausführliche Logs meiner Sessions mit dem HM-CC-RT-DN. Ich habe das Geräte-Logfile incl. Raw-Messages, einen Auszug aus der Log-Datei sowie den Konsolen-Mitschnitt der Debug-Ausgabe von hmland beigefügt. Wenn ich noch weitere Daten beisteuern kann, sagt Bescheid - ich bin erst seit dem Wochenende bei fhem

Ciao,
Sebi



Internals:
   DEF        <no definition>
   LASTInputDev hmusb
   MSGCNT     4
   NAME       global
   NR         1
   STATE      <no definition>
   TYPE       Global
   currentlogfile ./log/fhem-2014-02.log
   hmusb_MSGCNT 4
   hmusb_RAWMSG RF546ED01,0201,00471DBE,FF,FFDC,0E800222BBF542424200
   hmusb_RSSI -36
   hmusb_TIME 2014-02-03 02:05:02
   logfile    ./log/fhem-%Y-%m.log
Attributes:
   autoload_undefined_devices 1
   configfile fhem.cfg
   logfile    ./log/fhem-%Y-%m.log
   modpath    .
   motd       SecurityCheck:

WEB,WEBphone,WEBtablet has no basicAuth attribute.
telnetPort has no password/globalpassword attribute.
Running with root privileges.
Restart fhem for a new check if the problem is fixed,
or set the global attribute motd to none to supress this message.

   statefile  ./log/fhem.save
   updateInBackground 1
   userattr   devStateIcon devStateStyle icon sortby webCmd
   verbose    3
   version    $Id: fhem.pl 4769 2014-01-29 08:14:58Z rudolfkoenig $

[martinp876]

wegen der RT probleme -
a) welche Versionen?
b) IO device ist HM oder CUL?
c) kann einer rohmessages loggen?

Danke

p.s.
@sebixvi
dein HMUSB ist in overload - zu viele burst-versuche.

[sebixvi]

Hallo Martin,

das mit dem Overload hatte ich gesehen, aber ich dachte, das war heute Nacht um 2:00 Uhr?! Sollte er sich nicht danach wieder beruhigt haben, oder muss ich den Stick abziehen und neu starten, um das zurückzusetzen?

RT-Version ist bei mir 1.2, IO-Device ein HM-CFG-USB per hmland.

Sebi

[martinp876]

Hi Sebi,

ja, beruhigt sich nach spätestens 1h, wenn man ruhe gibt:

02:10:52 1: HMLAN_Parse: hmusb new condition Warning-HighLoad
02:40:52 1: HMLAN_Parse: hmusb new condition ok

Du arbeitest mit burstXmit - ist vorher das Register burstRx auch gesetzt worden?
kannst du einmal roh-mesages mirschneiden?
Gruss Martin

[sebixvi]

Hallo Martin,

ich werde heute Abend mal die nötigen Einstellungen vornehmen, um Rohdaten zu erhalten und entsprechende Logs posten.

Derzeit habe ich das Gefühl, als wenn der RT dem CFG-USB noch zu neu ist. In einem anderen Thread habe ich gelesen, dass die ACKs vom CFG-USB selbst generiert werden. Da das Firmwareupdate einwandfrei geklappt hat und dabei eine Menge Daten übertragen werden, dürfte die Funkstrecke in Ordnung sein. Auslesen und pairen klappt auch, nur beim Schreiben von Daten gibt´s Probleme, das aber nicht nur mit fhem, sondern auch mit der Homematic-Software. Und die sollte es ja eigenltich können...

Sebi

[Herr 3x]

Hallo Herr 3x,

welche Version des 10_CUL_HM.pm wäre denn das? Ich habe nämlich auch ein sehr ähnliches Problem...

Ich glaube, dass das die aus dem fhem 5.5 tar ist. Ich prüfe das nachher mal.

Herr 3x

[martinp876]

ok Sebi - guter Hinweis, dass auch HM-SW probleme hat.
Der Update begeht voraussichtlich über eine andere Frequenz... nicht, dass dein HMUSB ein anderes Problem mit HW hat...
Was sagen die RSSI Werte?