TCM 310 Raspi-EnOcean-Board auf USB Stick tauschen ohne neu anzulernen

[vangils]

Hallo,

nachdem mein FHEM/Eltako/EnOcean-Haussteuerungs- & Monitoringprojekt wahrscheinlich die Kapazität meines Raspi Rev-B an seine Grenzen bringen wird und auch die derzeitigen Ankündigungen der nächsten Version des Raspi für den nachhaltigen Einsatz des Raspi-EnOcean-Board nichts gutes verheissen, bin ich bereits jetzt dabei auf einen TCM310 USB-Stick umzustellen. Dieser soll dann u.U. auf ein lowpower NIC-Board mit Linux und FHEM zum Einsatz kommen aber auch im Falle eines möglichen HW-Defektes in ein paar Jahren auch einfach austauschbar sein. Nun mußte ich aber feststellen, dass der Wechsel von einem Raspi-EnOcean-Board auf einen USB-Stick auch bei Nutzung der gleichen BaseID nicht möglich scheint, denn meine bestehenden Aktoren reagieren nur auf das Raspi-Board jedoch nicht auf den USB TCM 310er Stick.

Gerne wollte ich jedoch, bevor ich alle meine 8 Stück an der Aussenfassade im ersten Stock montierten Aktoren final angelernt habe, prüfen wie der Wechsel einer defekten Komponente durchführbar ist. Doch macht es auf mich den Eindruck, dass genau dies nicht möglich sein dürfte, was mein derzeit geplantes Projekt etwas zu Fall bringen würde.

Hat vielleicht jemand von Euch oder auch der (Mit)Author Rudolf Koenig sich mit dieser Thematik bereits in die Tiefe auseinandergesetzt und kann mir hierbei einen gangbaren Weg aufzeigen, oder ist die EnOcean-Schiene aufgrund der in der Architektur implementierten Sicherheiten nur ein komplexes Abstellgleis mit kaum einer Umkehrmöglichkeit ?

lG,

Mario

[klaus.schauer]

Mit set <tcm> baseID <baseID> Sendeadresse des Tranceivers ändern. Achtung geht aus Sicherheitsgründen max. 10 mal. Näheres in der commandref.

[vangils]

Hi,

dies habe ich natürlich bereits ausgetestet, war auch im Vorfeld der Grund warum ich den Schritt bereits jetzt angegangen hatte. Doch leider trotzdem beide Interfacevarianten die gleiche BaseID haben, reagieren die Aktoren nicht auf den USB-Stick.
Laut FHEM-Log werden die Telegramme über den USB-Stick ausgesendet, bloss die Aktoren (Eltako FSB61) wollen einfach diese als für sie gültige Befehle akzeptieren.
Deshalb auch die Frage hier in diesem Forum mit der Hoffnung, dass einer der Entwicker von 00_TCM.pm oder 10_EnOcean.pm es liest und seine Erfahrungen mit einem solchen Thema einbringt.
Oder vielleicht ist jemand anderer schon wirklich praktisch diesen Schritt gegangen und kann seine Erfahrungen mitteilen, so dies auch wirklich funktioniert.

lG,

Mario

[krikan]

Hallo Mario!

klaus.schauer ist der Maintainer/Entwickler von 00_TCM.pm oder 10_EnOcean.pm. Also es hat Dir schon der "Richtige" geantwortet. Als User kann ich seine Angaben nur bestätigen. Bei mir hat bereits (edit) 3 2 Mal der Austausch des Gateways ohne Neuanlernen funktioniert; nur durch anpassen der BaseId. Ich nutze auch FSB61; jedoch unidi. Variante. Daher vermute ich eher einen Fehler auf Deiner Seite beim Ändern der BaseID.

Gruß, Christian

edit: Umsetzen der BaseId habe ich aber nicht mit fhem vorgenommen.

[vangils]

Hallo Christian,

wie hast Du ausserhalb von FHEM die BaseID ausgelesen und getauscht. FHEM zeigt mir bei beiden Interfaces die gleiche BaseID, sodass die Vermutung schon sehr nahe liegt, dass der Austausch nicht 100%ig vollzogen wurde.

lG,

Mario

[krikan]

Hallo Mario,

habe ich mit der kostenpflichtigen Closed Source PEHA-Software gemacht.

Aber wenn Deine beiden Gateways die richtige BaseID zeigen, müsste es auch mit Fhem funktioniert haben. Bist Du sicher, dass Deine Gateways Funkbefehle -insb USB300- absetzen?

Gruß, Christian

[vangils]

Hallo Christian,

wie bereits anfangs erwähnt bin ich gerade am Wechseln vom Raspberry EnOcean Board welches direkt am GPIO Bus angeschlossen ist zum EnOcean USB300 USB-Stick. Beide haben laut FHEM get BaseID command gesichert die gleiche baseid. Doch kann es sein, weil es ein anderes Board ist, dass de, dass dies die Ursache sein könnte. Funktioniert ein wechsel nur innerhalb des selben Gateway EnOcean-Chips ?
Wenn dem so sein solllte, dann stelle ich mir dennoch die erweiterte Frage, was passiert wenn einmal dann mein EnOcean USB300 Stick in fünf Jahren defekt wird und es diesen Stick mit genau dem gleiche EnOcean Chip nicht mehr gibt und dann ein wieder ein geringfügiger Technologiewechsel erforderlich wird. Muß ich dann erst wieder alle Aktoren dazu bewegen den neuen Chip als Sender von EnOcean-Befehlen zu akzeptieren ? Dann würde ja erst wieder die Katze ihrem Schwanz nachlaufen um in ihn beissen zu können !!!

lG,

Mario

[krikan]

hmm, behaupte immer noch, dass Du was falsch machst. Sorry. Sendet der USB 300 tatsächlich?

USB300 und Enocean Pi haben laut Datenblatt gleichen Chip. Aber selbst mit verschiedenen Chipsätzen funktionierte es bei mit. Tcm120, Tcm300 und schliesslich Tcm310 waren kein Problem. Zukunftssicherheit bei Technik ist aber insgesamt ein diskussionswürdiges Thema.....

[vangils]

Hi,

zu meiner derzeitigen Config. Ich habe einen Raspi mit dem GPIO Board und einen zweiten Raspi mit dem USB300er. Auf beiden ist FHEM und die EnOcean Gateways sind laut FHEM nutzbar. Wenn ich auf dem Raspi mit dem GPIO Board einen Befehl absende, finde ich Einträge im Log des Raspi mit dem USB300er GW wie folgt:

2014.05.30 23:20:13 5: TCM TCM310_0 RAW: 55000A0701EB
2014.05.30 23:20:13 5: TCM TCM310_0 RAW: 55000A0701EBA500230108018554D60001FFFFFFFF2D0009
2014.05.30 23:20:13 5: TCM310_0 dispatch EnOcean:1:A5:00230108:018554D6:00:01FFFFFFFF2D00
2014.05.30 23:20:13 4: EnOcean Unknown device with ID 018554D6 and RORG sensor, activate learning mode.

Und wenn ich am Raspi mit dem USB300 den Aktor anspreche finde ich ebenfalls am gleichen Raspi im Logfile die folgenden Meldungen:

2014.05.31 21:09:04 5: TCM TCM310_0 sending 55000A000180A5002301080027AA9E00FF
2014.05.31 21:09:04 5: SW: 55000A000180A5002301080027AA9E00FF
2014.05.31 21:09:04 5: TCM TCM310_0 RAW: 5500010002650000
2014.05.31 21:09:04 5: TCM TCM310_0 RESPONSE: OK

Wenn ich gleichen Aktor am Raspi mit GPIO EnOcean-Interface absende, erhalte ich auf diesem Raspi dann folgende Logeinträge:

2014.05.30 23:48:03 5: TCM TCM310_0 sending 55000A000180A5002301080027AA9E00FF
2014.05.30 23:48:03 5: SW: 55000A000180A5002301080027AA9E00FF
2014.05.30 23:48:03 5: TCM TCM310_0 RAW: 5500010002650000
2014.05.30 23:48:03 5: TCM TCM310_0 RESPONSE: OK
2014.05.30 23:48:13 2: EnOcean set bz_Raffstore closed

Für mich sieht dies danach aus als würden die Interfaces auf beiden Boards funktionieren und laienhaft betrachtet plausible bzw. vollkommen gleiche Telegramme versenden.
Doch ist das im log enthaltende Telegramm wirklich das gesamte EnOcean Telegramm oder nur ein Teil dessen ?
Und wir kann ich feststellen was wirklich alles im Telegramm enthalten ist und ob der Inhalt die richtige BaseID enthält ?
Irgendwie fehlt mir im Moment noch der richtige Schlüssel und weiter in die Tiefe tracen scheint ja nicht wirklich möglich zu sein.

lG,

Mario

[krikan]

Bin jetzt nicht der Experte, aber liefere Dir mal ein paar Ideen:

Logs enthalten nicht die BaseId, sondern SenderId. Bitte rufe bei beiden Systemen nach einem Reboot die BaseIds ab. Sind die wirklich gleich und gebe Sie mal hier an!

gehe davon aus, das Enocean pi steuern kann! Dann liegt es am usb300 raspi.

Gibt es ein Reichweiten Problem?

Hast Du mal versucht einen Aktor am usb300 neu anzulernen und zu steuern?

Viel Erfolg!

[klaus.schauer]

Den Sonderfall, dass zwei Transceiver mit gleicher BaseID vorhanden sind, sollte es eigentlich nicht geben. Normalerweise kommen tauchen solche Adressen nur über Repeater mehrfach auf. Deshalb werden empfangene Telegramme mit eigenen SenderIDs standardmäßig unterdrückt. Falls man diese Telegramme doch sehen will: attr <iodef> blockSenderID no setzen.

BaseIDs dürfen nicht beliebig sein, sondern in 128er-Dezimalschritten: 0x300, 0x380, 0x400 ....