FHEM Forum

Hallo zusammen,

über Nacht hat mein Enocean USB Stick (Future Technology Devices International, Ltd FT232 Serial (UART) IC) aufgehört zu funken, zumindest nehme ich das an.

Was ist passiert/nicht passiert:

• Stick läuft in genau dieser Konfiguration seit ca. 3 Jahren
• Stick hängt am Raspi, an FHEM im Docker via SOCAT angeschlossen
• Keine Changes in der Konfiguration seit Wochen
• Raspi ist rebootet
• FHEM ist ge-updated und ebenfalls neu gestartet
• Stick ist mit den get-Befehlen erreichbar (d.h. gibt sinnvolle Ergebnisse in FHEM zurück)
• lsusb am Raspi gibt keine seltsamen Meldungen
• TCM Device steht auf Verbose 5
• Wenn ich in FHEM ein Device schalte oder mittels z.B. eines Türkontaktes ein Telegramm provoziere erscheint kein unmittelbar zugeordneter Logevent

Was kann ich tun um das Ding wieder ans Laufen zu kriegen? Und, im Worst Case, wenn ich den Stick tauschen müsste, gibt es einen Weg dass ich mir das Anlernen von meinen ca. 30 Aktoren (zum größten Teil UP) sparen kann indem die Sender ID "irgendwie" übertragen werden würde? Danke für Eure Hilfe!



Internals:
   BaseID     FF9AD580
   ChipID     050135AB
   DEF        ESP3 192.168.178.8:3002@57600
   DeviceName 192.168.178.8:3002@57600
   FD         8
   FUUID      5c5dfce4-f33f-6fea-f599-e323abb2fe209ad7
   LastID     FF9AD5FF
   MODEL      ESP3
   NAME       TCM_ESP3_0
   NOTIFYDEV  global
   NR         18
   NTFY_ORDER 45-TCM_ESP3_0
   PARTIAL   
   STATE      initialized
   TYPE       TCM
   READINGS:
     2020-09-29 08:40:10   baseID          BaseID: FF9AD580 RemainingWriteCycles: 0A
     2020-03-13 23:56:21   dutycycleLimit  ActualSlotLeft: 0066 DutyCycle: 00 LoadAfterActual: 00 SlotPeriod: 0168 Slots: 0A
     2020-03-13 23:56:28   filter          Type:Value:
     2020-03-13 23:56:32   frequencyInfo   NOT_SUPPORTED
     2020-09-29 09:58:05   maturity        01
     2020-03-13 23:56:36   noiseThreshold  NOT_SUPPORTED
     2020-03-13 23:56:41   numSecureDevicesIn NOT_SUPPORTED
     2020-03-13 23:56:45   numSecureDevicesOut NOT_SUPPORTED
     2020-03-13 23:56:50   remanRepeating  NOT_SUPPORTED
     2020-09-29 09:58:05   repeater        RepEnable: 00 RepLevel: 00
     2020-09-29 08:26:36   smartAckLearnMode Enable: 00 Extended: 00
     2020-03-13 23:57:03   smartAckLearnedClients ClientID:CtrlID:Mailbox:
     2020-09-29 09:58:05   state           initialized
     2020-09-29 08:26:42   stepCode        NOT_SUPPORTED
     2020-09-29 09:58:05   version         APIVersion: 02060300 APPVersion: 020B0100 ChipID: 050135AB ChipVersion: 454F0103 Desc: GATEWAYCTRL
   helper:
     cdmSeq     2
     init_done  1
     telegramSentTimeLast 1601367076.79952
     awaitCmdResp:
Attributes:
   DbLogExclude .*
   alias      EnOcean Dongle (an RaspPi)
   baseID     FF9AD580
   comment    {EnOcean_CheckSenderID("getUsedID","TCM_ESP3_0","0000000")};
{EnOcean_CheckSenderID("getFreeID","TCM_ESP3_0","0000000")};

   group      Communication
   learningMode always
   room       Server
   sendInterval 0
   smartAckMailboxMax 0
   verbose    5



2020.09.29 10:11:16 5: TCM TCM_ESP3_0 RESPONSE: OK
2020.09.29 10:11:16 5: TCM TCM_ESP3_0 received ESP: 5500010002650000
2020.09.29 10:11:16 5: SW: 550007000111F670FF9AD5FE30EC
2020.09.29 10:11:16 5: TCM TCM_ESP3_0 sent ESP: 550007000111F670FF9AD5FE30EC
2020.09.29 10:11:13 5: TCM TCM_ESP3_0 RESPONSE: OK
2020.09.29 10:11:13 5: TCM TCM_ESP3_0 received ESP: 5500010002650000
2020.09.29 10:11:13 5: SW: 550007000111F650FF9AD589301E
2020.09.29 10:11:13 5: TCM TCM_ESP3_0 sent ESP: 550007000111F650FF9AD589301E
2020.09.29 10:11:11 5: TCM TCM_ESP3_0 RESPONSE: OK
2020.09.29 10:11:11 5: TCM TCM_ESP3_0 received ESP: 5500010002650000
2020.09.29 10:11:10 5: SW: 550007000111F650FF9AD5FE30D7
2020.09.29 10:11:10 5: TCM TCM_ESP3_0 sent ESP: 550007000111F650FF9AD5FE30D7
2020.09.29 10:04:13 5: TCM TCM_ESP3_0 RESPONSE: OK
2020.09.29 10:04:13 5: TCM TCM_ESP3_0 received ESP: 5500010002650000
2020.09.29 10:04:13 5: TCM TCM_ESP3_0 received ESP: 55
2020.09.29 10:04:13 5: SW: 550007000111F670FF9AD5FE30EC
2020.09.29 10:04:13 5: TCM TCM_ESP3_0 sent ESP: 550007000111F670FF9AD5FE30EC
2020.09.29 10:04:11 5: TCM TCM_ESP3_0 RESPONSE: OK
2020.09.29 10:04:11 5: TCM TCM_ESP3_0 received ESP: 5500010002650000
2020.09.29 10:04:10 5: SW: 550007000111F650FF9AD5FE30D7
2020.09.29 10:04:10 5: TCM TCM_ESP3_0 sent ESP: 550007000111F650FF9AD5FE30D7

Zitat von: eddy242 am 29 September 2020, 10:49:40
Und, im Worst Case, wenn ich den Stick tauschen müsste, gibt es einen Weg dass ich mir das Anlernen von meinen ca. 30 Aktoren (zum größten Teil UP) sparen kann indem die Sender ID "irgendwie" übertragen werden würde?

Beim neuen Stick die Basis-Id des alten Sticks mit "set <TCM> baseID <BasisID des alten Sticks>" setzen und das war es (http://fhem.de/commandref.html#TCM). Neues Anlernen ist grds. unnötig.
Bitte beachten, dass man die baseId des Sticks normalerweise nur 10x ändern kann.

Gruß, Christian

Hallo zusammen,

ich hatte mir damals s einen 2. Stick gekauft, denn wie von krikan beschrieben auf die gleiche Base ID gesetzt. Das Ergebnis war, dass sich einige Aktoren im Haus schalten ließen, andere wieder nicht. Ich habe mir dann einige Nächte um die Ohren gehauen, an 2 verschiedenen FHEM Installationen jeweils mit dem einen Stick geschaltet, mit dem anderen gehört, mit Enocean Dolphin Sniffer nach den Telegrammen geschaut, die Raspis mit den Enocean Sticks  an verschiedenen Stellen im Haus verteilt usw. Insgesamt bin ich dem Problem allerdings nicht völlig zweifelsfrei auf die Spur gekommen und am Ende bin ich auch immer noch nicht sicher, warum der Spuk nach ein paar Tagen wieder vorbei war und die Funktechnik wieder seit mittlerweile knapp 2 Monaten stabil lief (und zwar mit jeweils jedem der beiden Sticks, ist also nicht kaputt gewesen). Gestern traten die gleiche  Symptome aus heiterem Himmel wieder auf. D.h. ich muss mich jetzt durchkämpfen, bis ich den root cause gefunden habe. Mittlerweile schließe ich auch nicht mehr aus, ob vielleicht einer meiner FSR's oder FSB's mit aktivierter Repeater-Funktion nicht vielleicht defekt sein könnte.

Jedenfalls bin ich also wieder beim Debuggen und bin mal über diese Log-Zeile gestolpert.
2020.11.28 14:27:55 4: TCM TCM_ESP3_0 own telegram from FF9AD58F blocked.

Die ID im Eintrag ist die subDef im FHEM-Device. Der empfangende Aktor ist ein FSR14 mit aktivierter Quittungs-Funktion. Was kann der Umstand sein, dass so ein Eintrag kommt? Das hört sich irgendwie so an, als dass der TCM ein Telegramm sendet, was er dann selbst blockiert? Die Quittung vom Aktor hat ja dessen ID als Quelle.

Danke für Ideen!

Das TCM-Modul blockiert ein von einem Repeater zurückgesendetes Telegramm des eigenen Transceivers. Alles völlig ok und so gewollt!