Mehrere TCM statt Repeater

[Stril]

Hallo!

Ich überlege gerade, wie ich mein Haus "abdecke" (KG, EG, OG).

Variante 1:
FHEM mit TCM 310 im EG, Repeater im OG und KG

Variante 2:
FHEM mit jeweils einem TCM310 im KG,EG,OG via RJ45-USB-Verlängerung

Wie würdet ihr das machen?
Bei Variante 2 hätte ich 3 IO Devices, die ich ja theoretisch sogar auf die gleiche BaseID legen könnte. Blöd wäre es dann nur, wenn beim Teach-IN zwei der TCM310 das neue Device sehen.

Habt ihr das mal probiert?

Grüße und Danke!
Phil

[rudolfkoenig]

Ich wuerde Variante 2 vorziehen, spart Funklast und minimiert delays.
Ich wuerde auch unterschiedliche base-IDs verwenden: Gleiche base-Id sollte theoretisch funktionieren, allerdings ist Praxis nicht immer gleich Theorie.

[Doggiebert]

Schau doch erstmal, ob Du überhaupt ein Reichweitenproblem hast. Bei 3 Geschossen mit dem TCM in der Mitte stehen die Chancen ja nicht schlecht, dass das auch so funktioniert?
Aufrüsten kann man dann immer noch.

[klaus.schauer]

Na ja, die Variante 2 ist doch eher mit besonderer Vorsicht zu genießen. Z. B. muss bei bidirektionalen Aktoren wie den Heizungsaktoren (MD15) eine Fhem Sender ID automatisch generiert werden. Das geht derzeit nur mit einem Transceiver! Weiterhin würden Funktionen benötigt, die den besten und richtigen Transceiver zum Senden für das jeweilige Fhem Device ermitteln... auch nicht vorhanden. Dann ist zu klären, wie mit den über mehrere Transceiver gleichzeitig empfangenen Telegrammen umgegangen wird, insbesondere beim teach-in. Mir fallen sicher noch weitere Fallstricke ein, wenn man tiefer einsteigt.

M. E. sollte es deshalb schon sehr sehr gute Gründe gegen Variante 1 geben, wenn man die Idee weiterverfolgen wollte. Die zusätzliche Funklast ist es m. E. nicht. Für die Repeater-Funktionalität wurde das EnOcean-Protokoll ja ausgelegt.

[krikan]

Hoffe Deine Überlegungen zu Variante 2 resultieren nicht aus der (unbegründeten) "Panikmache" aus http://forum.fhem.de/index.php/topic,34562.0.html.
Würde auf jeden Fall die Variante 1 vorziehen, da das vom Aufbau einfacher und kostengünstiger ist. Wie im anderen Thread geschrieben, funktioniert bei mir diese Variante problemlos. Beschäftige Dich unbedingt mit den Einbau/Empfangs- und Reichweiteninfos von Enocean und berücksichtige sie. Schalte dann nach einem Test ohne Repeater eventuell einzelne Repeater in den Aktoren ein; Fhem bietet Dir dabei durch die RSSI-Werte mittlerweile gute Infos. Delayprobleme im EnOcean-Netz habe/hatte ich keine; noch nicht einmal als ich anfangs 3 oder 4 Repeater hatte und meine Geräteanzahl ist höher als von Dir im anderen Thread geplant. Delays kenne ich nur bei Verknüpfung zwischen EnOcean und Zwave, was aber evtl. an einem überlasteten Raspi liegt.

[rudolfkoenig]

- 10_EnOcean.pm verwendet doch IOWrite, damit wird das dazugehoerige TCM automatisch verwendet, der Benutzer kann das aber manuell ueberschreiben (IODev Attribut). D.h. ich gehe nicht von einem dynamischen sondern von einem statischen Zuordnung durch den Benutzer aus.

- Teach-In sollte kein Problem sein, wenn man nur einen der TCMs ins Teach-Modus versetzt.

- Sender-Id fuer MD15 kann doch automatisch generiert werden, man weiss ja welches Geraet die Daten empfangen hat. Ich vermute das wird auch jetzt schon so gemacht.

Nicht falsch verstehen: mir ist egal was gemacht wird, ich wollte nur wissen, ob mein Verstaendnis von EnOcean noch korrekt ist.

Wg. IOWrite und Dispatch muesste FHEM2FHEM:RAW mit EnOcean auch funktionieren, kann das jemand bestaetigen?

[nobody42]

- Repeater sollte man nur verwenden, wenn man sicher ist, nicht Verschlüsseln zu wollen (zumindest bei mir, mit Eltako/EnOcean, werden die
  secure RORG 30 Telegramme mit den Eltako FSB61NP nicht repeatet - im Standard steht zwar das es möglich ist, aber tut nicht )

- aktuell teste ich mit USBoverIP https://www.virtualhere.com/usb_client_software, was vielversprechend aussieht.
  Einen zentralen FHEM Server und dann die TCM USB Sticks pro Stockwerk z.B. mit RaspberryPI über usb-over-ip per LAN in den Sever einhängen,
  dann gibt es eine zentrale Stelle, wo die Devices ALLE drin sind. Die Raspberries sind dann nur "USB Verlängerer" und könnten auch
  noch presence machen, wenn man noch BlueTooth Dongles übrig hat...

  Dann halt pro Stockwerk mit der jeweiligen BaseID des Sticks arbeiten, das ist meiner Meinung auf jeden Fall zukunftssicherer
  und da man ja pro EnOcean Device den Stick angeben kann, sollte das auch tun (habe ich noch nicht getestet)

  Wenn mein zweiter RasPI die Tage kommt, kann ich das mal testen, einen zweiten TCM Stick habe ich schon...

Gruss
 

[krikan]

ist meiner Meinung auf jeden Fall zukunftssicherer

Was bedeutet für Dich in diesem  Zusammenhang "zukunftssicherer"?
Verschlüsselung = Zukunft??

[nobody42]

Was bedeutet für Dich in diesem  Zusammenhang "zukunftssicherer"?
Verschlüsselung = Zukunft??

ööh - ja - ich denke spätestens in ein paar Jahren hat der Einbrecher 2.0 einen LapTop im Gepäck und fährt erstmal die Rolläden hoch,
bevor er die Scheibe einschlägt [bitte nicht 100% Ernst nehmen]

und wie gesagt, wenn Du verteilte kleine Einheiten (Raspberry) im Haus hast, kannst Du daran schneller fächendeckend
auch non EnOcean Dinge einbauen. Wie z.B. JeeLink, BlueTooth oder irgendwas anderes was wir heute noch nicht kennen.
Einfach den USB Stick im entsprechenden Stockwerk rein und losgehts

[klaus.schauer]

Rudi ich sage nicht, dass es keine Lösung geben kann. Derzeit geht es auf jeden Fall nicht sauber.

- Z. B. wird in EnOcean_Parse derzeit nicht ausgewertet, von welchem TCM-Modul empfangen wird. Ist denn über den Übergabeparameter $iohash immer eindeutig auf das empfangene TCM-Modul zu schließen?

- Augenblicklich versuche ich die EnOcean Implementation eher in Richtung weniger Konfigurationsaufwand für den Anwender zu trimmen. Schon jetzt ist das "richtige" Anlernen der Aktoren und Sensoren im Forum ein Dauerbrenner, trotz der inzwischen sehr guten Anleitungen im Wiki. Mehrere Transceiver, die manuell vorgegeben werden müssen, machen die Sache nicht einfacher.

U. a. deshalb bin ich skeptisch, ob es wirklich sinnvoll und notwendig ist, die Idee weiterzuverfolgen. Kann aber auch sein, dass der typische Fhem User lieber mehr als weniger Parameter liebt. Manche Forumbeiträge lassen das vermuten. Dummerweise wird dann doch eher selten die commandref gelesen. Jedenfalls habe ich inzwischen schon meine liebe Not, halbwegs den Überblick über die inzwischen ca. 80 EnOcean-Attribute zu behalten. 

[Stril]

Hallo!

Mann sind die Leute hier aktiv. Das ist ja fabelhaft!!

Zum eigentlichen Thema:
Aktuell läuft FHEM im EG und ich kann die Rauchmelder im Keller und OG nicht zuverlässig sehen. Ohne Repeater und/oder mehrere TCM komme ich nicht hin.

Was für mich für die Repeater spricht: Wenn hier z.B. Taster in zwei Stockwerken die Treppenhausbeleuchtung steuern sollen, würde ich das nicht mit FHEM realisieren, sondern direkt. Da wäre der Repeater ja die Lösung und die "Multi-TCM-Lösung" kein Fortschritt, oder?

Gruß
Phil

[nobody42]

Wie gesagt, wenn Du nicht verschlüsseln willst, und keine dezentrale Installation brauchst, sind die Repeater
sicher das einfachste, weil dann Deine Telegramme entsprechend weitergereicht werden und
du eben grade nicht die komplexe Installation mit den multi-TCM hast.
Die blauen Eltako Akoren können meines Wissens z.B. alle auch Level-1 Repeater sein.

Gruss

[rudolfkoenig]

Ist denn über den Übergabeparameter $iohash immer eindeutig auf das empfangene TCM-Modul zu schließen

Ja, das wird auch seit langen ohne Probleme eingesetzt, ich koennte dir aus dem CUL Umfeld viele Szenarien nennen (SCC, RFR, Mehrfach-CUL, FHEM2FHEM:RAW, etc) die von diesem Feature abhaengen.

Mehrere Transceiver, die manuell vorgegeben werden müssen, machen die Sache nicht einfacher.

Stimmt, aber mAn auch nicht viel komplizierter, solange die Geraete nicht mobil sind, und man das Konzept vom IODev kapiert hat. Ich wollte nur wissen, ob sich in inzwischen im EnOcean Modul was geaendert hat, was die Unterstuetzung fuer mehrfach-TCMs verhindert, aber ich habe nicht den Eindruck.

[klaus.schauer]

Gut, dann sollte es ja bei einer statischen Zuordnung reichen, wenn in EnOcean_Parse die Verarbeitung von Telegrammen von nicht zugeordneten Transceivern unterbunden wird. Das wird nicht schwer sein.

[rudolfkoenig]

Ich verstehe nicht ganz: nicht zugeordnete Transceiver sollten gar keine Daten liefern, da sie eine andere baseID haben.
Bei gleicher baseID kann die Sache komplizierter sein, allerdings gibt es ein Filter in fhem.pl, was zuschlaegt, falls die gleichen Daten von unterschiedlichen Transceivern gemeldet werden.