Mehrere TCM statt Repeater

[klaus.schauer]

Ne, die remote devices senden mit ihrer SenderID und im unidirektionalen Modus mit der EmpfängerID "FFFFFFFF" (broadcast) bzw . eine def. EmpfängerID (unicast) z. B. beim MD15. Die empfangenen Telegramme werden immer von jeder Gegenstelle (Transceiver) angenommen. Die von n Transceivern insgesamt max. n empfangenen Telegramme gehen alle an die Parse-Routine, wo sie, bei passendem Device, bisher auch alle ausgewertet werden. Die SenderIDs aus dem Kontingent (BaseID + x) des oder der Transceiver ist nur beim Senden aus Fhem von Bedeutung.

[rudolfkoenig]

Ich gehe davon aus, dass in diesem Fall EnOcean_Parse nur einmal aufgerufen wird, da der vorhin erwaehnte Filter in fhem.pl zuschlaegt.

[klaus.schauer]

Wenn man sich also in der Parse-Routine darauf verlässt, dass auch bei mehreren Transceivern jeweils nur eines der n Telegramme ankommt, hat man beim teach-in ein Problem. Nachdem man einen Transceiver in den teach-Mode gesetzt hat, muss auch über diesen empfangen werden, sonst wird es derzeit verworfen. Beim unidirektionalen teach-in könnte man noch alle Transceiver in den teach-Mode setzen. Dann wird eben ein Transceiver gewinnen. Beim bidirektionalen teach-in muss man sich auf einen Transceiver beschränken, um eine eindeutige Fhem-SenderID erzeugen zu können. Jetzt hat man aber in der Parse-Routine keine Auswahlmöglichkeit zwischen mehreren Transceivern. Man kann nur hoffen, dass das Paket des "richtigen" Transceiver gewinnt. Eine Lösung wäre vielleicht, alle Transceiver mit gleichen BaseIDs zu versehen. Dann gibt es schon wieder ein neues Problem; freie SenderID müssen jetzt über alle Transceiver gesucht werden... Na ja, vielleicht gibt es in anderen Modulen für diese und weitere Überlegungen schon zuverlässige Lösungen.

[rudolfkoenig]

Ok, das ist ein Punkt, habe im Moment auch keine gute Loesung dafuer, ausser die anderen TCMs (irgendwie) zu deaktivieren.

[Stril]

Hallo!

Mich wundert, dass dieses Problem nicht viele Leute betrifft. Ich habe jetzt 2 Stunden lang meinen FHEM-Server herumgetragen (zum Glück nur ein NUC) und an verschiedenen Positionen getestet. Ohne Repeater geht da nichts...

Ich kommt auch nicht über zwei Repeater von ganz oben nach ganz unten

Mit drei TCMs wäre es wohl einfach - gerade wenn sie auf einer BaseID laufen würden.

Wisst ihr, wie man bei den TCMs den Repeater aktiviert?

Grüße
Phil

[Doggiebert]

Mich wundert, dass dieses Problem nicht viele Leute betrifft. Ich habe jetzt 2 Stunden lang meinen FHEM-Server herumgetragen (zum Glück nur ein NUC) und an verschiedenen Positionen getestet. Ohne Repeater geht da nichts...

hm,nö - ich hab' einen Enocean pi, der bei mir im Wohnzimmer steht, der reicht problemlos eine Etage rauf und runter und in die Garage.

[krikan]

Mich wundert, dass dieses Problem nicht viele Leute betrifft. Ich habe jetzt 2 Stunden lang meinen FHEM-Server herumgetragen (zum Glück nur ein NUC) und an verschiedenen Positionen getestet. Ohne Repeater geht da nichts...

Dringender Rat aus eigener Erfahrung: Gehe das bitte struktuiert an. Bringe den Server mit TCM an die gewünschte Endposition und schalte dann zielgerichtet Repeater zu und wenn es mehrere sind ist das letztlich auch egal. Beachte auch 1- und 2-Level-Modus und die von mir bereits mehrfach angeführten Infos von EnOcean zu Reichweite und Installation. Wie Du den Repeater im TCM einschaltest steht in der Commandref zu TCM.

[Stril]

Hallo!

Hab jetzt die commandref gefunden. War da irgendwie blind.

Was ich auch interessant finde ist:

BSC-BAP
und
BSC-BIER


Kennt ihr die Geräte?
BAP scheint ein Access-Point zu sein, aber mir ist nicht klar, ob zwei BAP auch als EnO<->LAN<->EnO Bridge arbeiten können.

Beim BSC-BIER finde ich folgenden Satz interessant:
---
Der BSC-BIER ist ein intelligenter Repeater für die Weiterleitung von EnOcean-Funksignalen. Die Definition einer Routing-Tabelle und eines Routing-Weges ist möglich. Es werden bis zu 128 Geräte unterstützt. Durch die intelligente Signalverarbeitung ist es möglich, eine nahezu unbegrenzte Anzahl von BSC-BIER-Repeatern einzusetzen.
----

Kennt ihr das Gerät?

Grüße
Phil

[krikan]

Zum BAP mit Kenntnisstand von 2009 (auf den aktuellen Datenblättern sehe ich aber keine Änderung):
Hat einen veralteten TCM120-Chip; funktioniert derzeit wohl nicht mit Fhem, da eine geschlossene Firmware vor den Transceiver geschaltet ist.

[DerJens]

Hallo,

also hier im Haus (KG,EG,OG) habe ich ein herzhaftes Reichweitenproblem. Ich habe mich hier für einen Raspberry Pi auf jeder Etage entschieden, den ich mit einem EnOcean USB Modul ausgestattet habe. So kann man die Logik sogar auf mehrere Geräte verteilen und mit der FHEM2FHEM Log Funktion trotzdem zentral verfügbar machen. Voraussetzung ist natürlich eine globale LAN Anbindung der RPis; ich habe dafür fast in jedem Raum eine Ethernet-Dose gelegt. Auf jeder Etage kann man dann noch bei Bedarf mit der Repeater-Funktion der EnOcean Aktoren arbeiten.

[rudolfkoenig]

Ist das als "So habe ich das geplant", oder "So funktioniert es bei mir seit laengerem" zu lesen?
Wleche Art von FHEM2FHEM ist das, RAW oder LOG?

[DerJens]

"So funktioniert es bei mir seit laengerem": Seit mehreren Monaten arbeiten hier 3 PIs, jew. einer für KG, EG und OG. Alle haben eigene, etagenbezogene Aufgaben. KG und OG liefern via FHEM2FHEM im LOG Modus an EG. So sehe ich z.B. im EG auf dem Display, was die Zentralheizung grade macht; die Erfassung und Berechnung der Werte sowie das Logging erfolgt im KG. Weiteres Beispiel: Das OG steuert seine Rolladen selbstständig, hier gelten eh andere Anforderungen als im EG.

[nobody42]

Das heißt aber, daß Du die ganzen Einstellungen/Timer/Logik logischerweise auf dem jeweiligen "Stockwerks PI" machst ?
Und FHEM2FEHM ist nur zum loggen/Status info ?

[DerJens]

Das ist richtig. Als ich in den Anfängen meiner Hausinstallation merkte, dass ich vom EG die Rollladen im OG nicht fehlerfrei erreichen konnte, musste eine Lösung her. Eltako hat eine Brücke mit Duplizierer empfohlen, was sicher auch funktioniert hätte aber ein weiterer RPi mit EnOcean USB Stick war preislich und auch vom Installationsaufwand günstiger. Eine stabile Etagensteuerung die ich zentral auswerten und visualisieren kann war/ist bislang für mich die richtige Entscheidung gewesen.

Man muss dabei ja auch immer überdenken, ob man lieber bei der Hardware ansetzt (z.B. weitere Kabel ziehen) oder bei der Software. Via Software die Etagen zusammenzuführen und dabei jeder Etage ein wenig Eigenregie zu überlassen fand ich eine sinnvolle Lösung.

Was ist bislang nicht ausprobiert habe - aber eigentlich funktionieren müsste - ist eine bidirektionale Verbindung mit FHEM2FHEM. Dann kann man ja nahezu beliebig Events auslösen und auch reagieren, es darf nur kein Zirkel entstehen. Ggf. kann hier die Filterfunktion LOG:.* helfen.

Ist ja oft eine Frage wo man anfängt: Bin ich beim Planen einer bevorstehenden Erstinstallation oder suche ich nach einer Lösung für eine bereits vorhandene Installation.

[Stril]

Hallo!

Wäre es da nicht einfacher, USB über Cat5e in die Stockwerke zu verlängern?

Gruß
Phil