TCM 300 geht, TCM 310 geht ... halb?

[fallenguru]

Für meine bisherigen EnOcean-Experimente habe ich einen TCM 300 mit ESP2 (BootUp USB2+Rep-EnO868) verwendet, das geht so weit ganz gut. Aus verschiedenen Gründen hätte ich für den Dauerbetrieb lieber ein TCM 310 mit ESP3 genommen (BSC EnOcean Smart Connect USB).

Code: [Auswählen]

define ufo TCM 120 /dev/ttyUSB.ufo@9600
define rocket TCM 310 /dev/ttyUSB.rocket@57600 (Die angegebenen device files sind Symlinks, die von udev automatisch auf Basis der Seriennummer etc. erstellt werden. Es ist immer nur eines der beiden Geräte tatsächlich angeschlossen.)

Dummerweise scheint der BSC-Stick auf den zweiten Blick nicht ganz hundertprozentig zu funktionieren. Es hat heute nämlich einige Versuche gebraucht, bis "get rocket idbase" das gewünschte "BaseID=FFCC5800,RemainingWriteCycles=0A" lieferte -- zuerst bekam ich nur "get idbase: Bogus answer received: 55000501" (Daten am Ende variabel.)
Lt. weiteren Tests dürfte die "Erfolgsquote" bei ~50 % liegen ... Abgesehen davon scheint alles normal zu funktionieren, zumindest scheinen ein paar testweise Taster-Betätigungen brav im Event-Log auf.

Hat jemand eine Idee, woran das liegen könnte?
Muss ich mir deshalb Sorgen machen? Ob sich die BaseID jetzt auf Anhieb auslesen lässt, ist natürlich egal, aber wenn die Kommunikation generell irgendwie gestört sein sollte, dann wüsste ich das lieber, bevor ich nächste Woche unseren Elektriker alle Aktoren auf den BSC-Stick anlernen lasse ...

[klaus.schauer]

Für meine bisherigen EnOcean-Experimente habe ich einen TCM 300 mit ESP2 (BootUp USB2+Rep-EnO868) verwendet, das geht so weit ganz gut. Aus verschiedenen Gründen hätte ich für den Dauerbetrieb lieber ein TCM 310 mit ESP3 genommen (BSC EnOcean Smart Connect USB).

Code: [Auswählen]

define ufo TCM 120 /dev/ttyUSB.ufo@9600
define rocket TCM 310 /dev/ttyUSB.rocket@57600 (Die angegebenen device files sind Symlinks, die von udev automatisch auf Basis der Seriennummer etc. erstellt werden. Es ist immer nur eines der beiden Geräte tatsächlich angeschlossen.)

Dummerweise scheint der BSC-Stick auf den zweiten Blick nicht ganz hundertprozentig zu funktionieren. Es hat heute nämlich einige Versuche gebraucht, bis "get rocket idbase" das gewünschte "BaseID=FFCC5800,RemainingWriteCycles=0A" lieferte -- zuerst bekam ich nur "get idbase: Bogus answer received: 55000501" (Daten am Ende variabel.)
Lt. weiteren Tests dürfte die "Erfolgsquote" bei ~50 % liegen ... Abgesehen davon scheint alles normal zu funktionieren, zumindest scheinen ein paar testweise Taster-Betätigungen brav im Event-Log auf.

Hat jemand eine Idee, woran das liegen könnte?
Muss ich mir deshalb Sorgen machen? Ob sich die BaseID jetzt auf Anhieb auslesen lässt, ist natürlich egal, aber wenn die Kommunikation generell irgendwie gestört sein sollte, dann wüsste ich das lieber, bevor ich nächste Woche unseren Elektriker alle Aktoren auf den BSC-Stick anlernen lasse ...

Der Fehler ist bekannt. Ich hoffe, dass wir den Fehler alsbald beseitigen können. Auch nach meiner Erfahrung wirkt sich der Fehler nur auf das Auslesen von Statusinformationen aus.

Ich würde für Neuinstallationen keine Transceiver mit TCM120 Chips einsetzen. Das ESP2 ist veraltet, unterstützt nicht alle aktuellen Protokolle und wird von EnOcean in den neueren Entwicklungstools nicht mehr unterstützt.

[fallenguru]

Auch nach meiner Erfahrung wirkt sich der Fehler nur auf das Auslesen von Statusinformationen aus.

Das ist beruhigend, danke.

Übrigens: Seit dem letzten Update (innerhalb der letzten halben Stunde) bekomme ich -- unabhängig davon, welches Interface ich verwende -- für alle Taster die "buttons: released"-Events doppelt im Event Monitor. Gestern Abend war noch alles normal.

Ich würde für Neuinstallationen keine Transceiver mit TCM120 Chips einsetzen.

Ok. Dann hoffe ich mal, dass der BSC-Stick stabil läuft und keine bösen Überraschungen bereitet.

Vielen Dank (wieder einmal)!