Hilfe!! TCM 310

[AnBad]

Hallo,
ich musste gerade feststellen, dass im Device TCM_310_ESP3_0 unter Internals der Partial eine sehr lange Kombination von Zahlen/Buchstaben so auch unter rcvcounter eine Unmenge von Zeitangaben aufweist. Das Modul scheint nicht mehr zu empfangen, aber noch zu senden. Hilfe, was hat das zu bedeuten?

Internals:
  BaseID    FFCF7E80
  ChipID    051A9EFD
  DEF        ESP3 /dev/ttyAMA0@57600
  DeviceName /dev/ttyAMA0@57600
  FD        8
  FUUID      61755658-f33f-cecb-0eba-6c9eadccb07c07b6
  LastID    FFCF7EFF
  MODEL      ESP3
  MsgRcvPerDay 7070
  MsgRcvPerHour 0
  MsgRcvPerMin 0
  MsgSndPerDay 1888
  MsgSndPerHour 7
  MsgSndPerMin 1
  NAME      TCM_ESP3_0
  NOTIFYDEV  global
  NR        46
  NTFY_ORDER 45-TCM_ESP3_0
  PARTIAL   55C001000265000055000A0701EBA5648C0908FFCF7E9D810480CAA1FF68AF8DF5C5430A85A7250006FFFFFFFF4000F555000A0701EBA5644FAC0801A1A7250004FFFFFFFF40004C55000A0701EBA500002908019421610006FFFFFFFF4600AF55000A0701E und noch viel länger
  RSSI      -74
  STATE      initialized
  TYPE      TCM
  eventCount 7
  READINGS:
    2024-03-24 10:25:05  baseID          BaseID: FFCF7E80 RemainingWriteCycles: 0A
    2024-03-23 17:49:16  maturity        01
    2024-03-23 17:49:16  repeater        RepEnable: 00 RepLevel: 00
    2024-03-23 17:49:16  state          initialized
    2024-03-23 17:49:16  version        APIVersion: 02060900 APPVersion: 020F0000 ChipID: 051A9EFD ChipVersion: 454F0103 Desc: GATEWAYCTRL
  helper:
    cdmSeq    3
    init_done  1
    telegramSentTimeLast 1711672539.89423
    BaseID:
      FFCF7E80
    ChipID:
      051A9EFD
    awaitCmdResp:
      0
    rcvCounter:
      1711586177.46663
      1711586191.53879
      1711586191.53921
      1711586191.66119
      1711586199.25297
      1711586199.25338
      1711586199.33616
      1711586280.99371
      1711586280.99417
      1711586281.49025
      1711586316.85308
      1711586316.85371
      1711586316.97069
      1711586330.06837
      1711586354.28497
      1711586387.18616
und noch viele mehr...

[Flachzange]

Mir sagen die Werte nichts, aber was passiert, wenn Du FHEM neustartest? Auch mal das Log im Blick gehalten. Ggf. verbose hochsetzen.

Und was heißt

Das Modul scheint nicht mehr zu empfangen, aber noch zu senden.

?

Kannt Du Senden/Empfangen oder nicht?

[AnBad]

Heute morgen hat das TCM wieder Daten z.B. von einem Bewegungsmelder empfangen. Als ich im Modul TCM daraufhin nachschaute, war die Endlos-Kombination aus dem Internal PARTIAL gelöscht. Ich habe gestern Nacht als ersten Korrekturversuch mal das Attribut msgCounter im TCM-Modul auf 0 gestellt. Es könnte was damit zu tun gehabt haben?
Ich bin schon mal froh, dass der Server nicht ganz zusammengebrochen ist und die Hausautomatik problem heute morgen läuft. Ich hatte heute Nacht regelrecht Panik.

Ich muss auch sagen, seit drei, vier Wochen habe ich Probleme mit dem Logfile. Alle paar Stunden sind alle Daten aus dem täglichen Logfile gelöscht. Sämtliche Versuche den Fehler einzugrenzen und damit ausfindig zu machen sind bis jetzt gescheitert. Vlt. hat es was mit dem TCM Modul zu tun. Muss mal schauen.

Vor einer Woche bin ich auf die Idee gekommen, auf einem neuen Raspberry 5, aktuelles Raspbian mit extra TCM-Modul die nächste Zeit umzuziehen. Hierzu habe ich testweise den Raspberry 5 mit FHEM und TCM eingerichtet. Weiterhin habe ich die BaseID übertragen. Testweise habe ich dann festgestellt, dass auf Enocean-Signale der alte Raspberry und der Testaufbau mit neuem FHEM reagieren. Kann das einen Fehler im alten, eigentlichen FHEM/TCM-Modul ausgelöst haben oder sollten die zwei Server unabhängig schön brav nebeneinander laufen?

Vielen Dank.

[Damu]

Wenn beide Zwei FHEM Server mit zwei Enocean Controller mit der selben BaseID laufen kann das schon zu Problemen führen.

[AnBad]

Wenn beide ZweiFHEM Server mit zwei Enocean Controller mit der selben BaseID laufen kann das schon zu Problemen führen.

OK, also Probleme in dem Sinn, dass es die FHEM-Systeme untereinander hinsichtlich Fehler kaputt machen? Oder das z.B. Aktoren Schaltungen missverstehen, verschlucken usw? Letzteres wäre ja nicht so ein Problem.

Ich wollte in einer gewissen Übergangszeit, beide Raspberrys mit separatem FHEM laufen lassen. Ich habe nicht geplant, einfach ein fhem backup zu erstellen und auf das neue System des Raspberry 5 einzulesen. Ich wollte die Gelegenheit nutzen, das FHEM-System aufzuräumen, d.h. Devices und Perl-Scripte nacheinander einzeln zu übertragen (d.h. neu anlegen oder auch nicht mehr), testen und aufzuräumen.

[Flachzange]

Vielleicht dann erstmal alle möglichen Fehlerquellen ausschließen und dazu gehört auch die zweite FHEM-Instanz mit zweitem TCM abschalten. Und dann wie schon oben geschrieben: FHEM neustarten, um mal die Internals zu resetten. Dann Logs beobachten, Sensoren benutzen, Aktoren schalten und schauen was passiert. Ansonsten wird es schwierig sein Dir zu helfen.

[IPWF]

Zwei TCM-Module dürfen niemals die gleiche BaseID haben. Die BaseID ist die eindeutige Identifikationsadresse des TCM, von der auch die Sender-IDs der FHEM-EnOcean-Geräte abgeleitet werden. Wenn zwei TCM die gleiche BaseID haben, können die Nachrichten nicht mehr zugeordnet werden.
Du mußt daher dem TCM des "neuen" Servers eine eigene BaseID geben. Demzufolge müssen alle EnOcean-Geräte an diesem neu angelernt werden.
Dies könnte man theoretisch umgehen, indem man das Backup des alten Servers aufspielt und die Zuordnung aller EnOcean-Geräte zum TCM-Modul ändert. Ob das in FHEM so einfach möglich ist und damit auch alle Sender-IDs angepasst werden, weiß ich leider nicht.

[AnBad]

FHEM-Instanz mit zweitem TCM abschalten.

Das zweite TCM war nur mal kurz, vlt. 10 Minuten, in Betrieb zum Testen. Auch ca. 2, 3 Tage bevor die Probleme auftauchten.

.... können die Nachrichten nicht mehr zugeordnet werden.
Du mußt daher dem TCM des "neuen" Servers eine eigene BaseID geben. Demzufolge müssen alle EnOcean-Geräte an diesem neu angelernt werden.
Dies könnte man theoretisch umgehen, indem man das Backup des alten Servers aufspielt und die Zuordnung aller EnOcean-Geräte zum TCM-Modul ändert. Ob das in FHEM so einfach möglich ist und damit auch alle Sender-IDs angepasst werden, weiß ich leider nicht.

Na ja, bei meinem kurzem Test musste ich feststellen, dass die Nachrichten von beiden TCM empfangen wurde. Es gab da keine Probleme. Auch habe ich irgendwo im Forum gelesen, dass man genau so durch übertragen der baseID Fhem von einem Modul auf ein anderes übertragen kann z.B. im Fall eines Defekt. Das mit dem Versuch eine gewisse Zeit einfach beide laufen zu lassen, ist mein Gedanke.

[Damu]

Ich sehe bei mir auch (noch) keine Probleme wenn beide TCM mit der selben BaseID laufen.

Der Vorteil ist mann kann am Device das Gateway mit dem besseren Empfang zuortene.
Der Nachteil beim Anlernen werden IDs doppelt vergeben.

Ist es auch möglich beim anlernen die ID vorab zu bestimmen?
Wenn das ginge wäre alles ok.

Oder gibt es noch anderes das ich im Moment nicht bedacht habe?