Kommunikation TC - VD nach update (?) gestört

locodriver · 07 Dezember 2013, 11:28:31

Habe gestern ein update gemacht. Jede Nacht um 3 Uhr 50 synchronisiere ich die Uhrzeit meiner TCs. Heute Vormittag war bei beiden TCs die Verb. zu den VDs gestört (Antenne blinkt, VDs auf Errorpos.). Ich habe alle wieder manuell synchronisiert und die VDs schlossen dann wieder. An den TCs war die Zeit auf 3 Uhr 50 eingestellt, das habe ich auch manuell korrigiert. Nach ca. 2 Min. steht die Zeit dann wieder auf 3 Uhr 50 und läuft 2 Min., dann stellen sie sich wieder auf 3 Uhr 50. Etwas später bricht die Kommunikation zu den VDs wieder ab usw.
Ein TC läuft manuell und einer auto, die RHS bleiben mit den TCs verbunden.

Es gab keine außergewöhnlichen Log-einträge, außer dass bei den VDs die Errorpos. geloggt wird.

Der HM-LAN blinkt übrigens rot, die Readings sind so:

Code Auswählen

Xmit-Events
	
ok:1
	
2013-12-07 11:13:10
cond
	
ok
	
2013-12-07 11:13:10
prot_disconnected
	
last
	
2013-12-07 11:11:31
prot_init
	
last
	
2013-12-07 11:13:09
prot_ok
	
last
	
2013-12-07 11:13:10

Und noch das:
msgLoadEst
1hour:2% 10min steps: 0/1/0/0/0/0

Sieht nach HM-LAN Problem aus, oder? Hatte ich so noch nie.
Ist es erstmal sinnvoll, downzugraden?

Uwe

Ergänzung: bin jetzt auf

$Id: 10_CUL_HM.pm 4288 2013-11-25 09:40:18Z martinp876 $

zurückgegangen und es scheint wieder zu funzen ... ich werde es beobachten.

martinp876 · 07 Dezember 2013, 13:27:45

Hallo Uwe,

Die Zeit fordern alle TCs jede Nacht automatisch an. Das musst du nicht machen.

Hast du den disconnect einmal oder öfter beobachtet?

Gruss Martin

locodriver · 07 Dezember 2013, 14:00:36

Hallo Martin,

ich synchronisiere die Zeit deshalb um 3 Uhr 50, weil dann auch in den Nächten der Sommerzeitumstellung, die Uhren umgestellt sind (etwas OT).

Disconnects, wie sie andere User hier oft beschreiben, habe ich eigentlich nur sporadisch und bisher ohne Auswirkungen auf mein System.

Nach dem Downgrade und einem neu anlernen untereinander und Uhren stellen läuft es jetzt offenbar wieder.

Komisch ist, dass ich das Upgrade gestern Mittag gemacht habe und der Fehler erst in der Nacht auftrat. Ich kontrolliere noch mal die Logs - vielleicht habe ich noch was übersehen.

Uwe

martinp876 · 07 Dezember 2013, 14:28:16

Hallo Uwe,

ich denke, die Sommerzeit Umstellung klappt mittlerweile auch automatisch. Ich habe nichts gegenteiliges mehr gehört.

Wäre gut, wenn du noch einen Hinweis finden kannst.
Wäre es ein overload gewesen würde ich es verstehen - ein einfacher disconnect....
wie viele SDs schaltest du so in der Nacht?

hast du einmal einen HMinfo probiert um zu sehen, was so los ist?

set hm msgStat

Gruss Martin

locodriver · 08 Dezember 2013, 15:05:19

Hallo Martin,

hier erstmal die msgstat:

Code Auswählen

msg statistics

                 |------------------------------------------------------------>*
  receive hour  :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
      StatCntRfresh:|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0
      HMLAN1    :|145|147|142|142|145|139|141|141|142|155|162|161|164|140|417|  7|151|163|141|152|144|139|142|143
      StatCntRfrh:|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0
  send    hour  :| 00| 01| 02| 03| 04| 05| 06| 07| 08| 09| 10| 11| 12| 13| 14| 15| 16| 17| 18| 19| 20| 21| 22| 23
      StatCntRfresh:|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0
      HMLAN1    :|  2|  2|  2|  4|  0|  0|  0|  0|  1|  9| 15| 16| 21|  0|283|  0|  6| 17|  2| 12|  0|  0|  0|  1
      StatCntRfrh:|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0|  0
                 |------------------------------------------------------------>*
  receive day   :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# tdy
      StatCntRfresh:|   0|   0|   0|   0|   0|   0|   0|#   0
      HMLAN1    :|   0|   0|   0|   0|   0|   0|2076|#3665
      StatCntRfrh:|   0|   0|   0|   0|   0|   0|   0|#   0
  send    day   :| Mon| Tue| Wed| Thu| Fri| Sat| Sun|# tdy
      StatCntRfresh:|   0|   0|   0|   0|   0|   0|   0|#   0
      HMLAN1    :|   0|   0|   0|   0|   0|   0| 406|# 393
      StatCntRfrh:|   0|   0|   0|   0|   0|   0|   0|#   0

Zum logs checken bin ich noch nicht gekommen

.

Uwe

martinp876 · 08 Dezember 2013, 15:24:56

Hallo Uwe,

nun. soweit kannst du es sicher selbst lesen:
zwischen 14:00 und 14:59 sind 283 messages gesendet worden. Das war sicher ein restart.
Ansonsten ist alles ruhig.

Die Frage ist nun, welche devices dies waren. Das ist dann in protoEvents zu sehen. Wenn es viel Burst war, kann es zu Probleme kommen.

Gruss Martin

locodriver · 09 Dezember 2013, 10:56:23

Hallo Martin,

die große Anzahl an Messages gestern hat nichts mit dem Prob. hier zu tun, ich habe in der Zeit einige andere Funktionen mit mehreren Neustarts usw. bearbeitet.

Ich habe noch mal die logs gecheckt - leider habe ich keins vom HM-LAN.

Bei den TCs ist nichts auffälliges, bei den VDs sieht es so aus:

Code Auswählen

2013-12-07_03:48:29 BD_Hk4 ValveDesired: 0 %
2013-12-07_03:48:29 BD_Hk4 0 %
2013-12-07_03:51:05 BD_Hk4 set_0 %
2013-12-07_04:03:44 BD_Hk4 ValveDesired: 0 %
2013-12-07_04:09:02 BD_Hk4 set_0 %
2013-12-07_04:18:53 BD_Hk4 ValveDesired: 0 %
2013-12-07_04:24:30 BD_Hk4 set_0 %
2013-12-07_04:34:58 BD_Hk4 ValveDesired: 0 %
2013-12-07_04:39:50 BD_Hk4 set_0 %
2013-12-07_04:55:02 BD_Hk4 set_0 %
2013-12-07_04:55:02 BD_Hk4 ValveDesired: 0 %
2013-12-07_05:04:39 BD_Hk4 ValvePosition: 7 %
2013-12-07_05:04:39 BD_Hk4 7 %
2013-12-07_05:04:39 BD_Hk4 operState: errorTargetNotMet
2013-12-07_05:04:39 BD_Hk4 operStateErrCnt: 2686
2013-12-07_05:07:31 BD_Hk4 set_0 %
2013-12-07_05:10:08 BD_Hk4 ValveDesired: 0 %
2013-12-07_05:22:52 BD_Hk4 set_0 %
2013-12-07_05:27:07 BD_Hk4 ValveDesired: 0 %
2013-12-07_05:39:57 BD_Hk4 set_0 %
2013-12-07_05:42:39 BD_Hk4 ValveDesired: 0 %
2013-12-07_05:55:45 BD_Hk4 set_0 %
2013-12-07_05:58:05 BD_Hk4 ValveDesired: 0 %
2013-12-07_06:13:23 BD_Hk4 set_0 %
2013-12-07_06:13:23 BD_Hk4 ValveDesired: 0 %
2013-12-07_06:20:59 BD_Hk4 ValvePosition: 7 %
2013-12-07_06:20:59 BD_Hk4 7 %
2013-12-07_06:20:59 BD_Hk4 operState: errorTargetNotMet
2013-12-07_06:20:59 BD_Hk4 operStateErrCnt: 2687
2013-12-07_06:23:02 BD_Hk4 set_0 %

Meine Errorpos. ist 7%.

Das gilt auch in ähnlicher Weise für die VDs, die am anderen TC hängen.
Da werden wir der Sache wohl nicht auf den Grund gehen können.
Ich bin noch auf

ZitatErgänzung: bin jetzt auf

$Id: 10_CUL_HM.pm 4288 2013-11-25 09:40:18Z martinp876 $

Da gibt es keine Probs. - ich werde mal noch meine TC-Synchronisierung abschalten.

Uwe

Ergänzung/Vermutung: evtl. hat sich die TC-Sync. irgendwie aufgehängt und dann die ganze Kommunikation zu den TCs lahm gelegt (immer wieder 3 Uhr 50!)?

martinp876 · 09 Dezember 2013, 15:02:23

Hallo Uwe,

also in diese Kommunikation ist FHEM absolut passiv.
Normal:
- der TC gibt dem VD den neuen Stellwert
- der VD antwortet mit seinem aktuellen Wert und zusatzinfo
- wiederholrate 2,5min

bei dir
- der TC sendet den stellwert (alle 15min)
- der vd sendet seinen Error (alle 100min- etwa)

Demnach stimme ich dir zu, der TC ist aus dem Tritt und sendet nicht mehr korrekt. Warum kann ich nicht sagen, konnte es noch nicht beobachten.

Gruss Martin