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
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.
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.
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.
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.
- 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?
- 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
Zitat von: nobody42 am 16 März 2015, 19:59:47
ist meiner Meinung auf jeden Fall zukunftssicherer
Was bedeutet für Dich in diesem Zusammenhang "zukunftssicherer"?
Verschlüsselung = Zukunft??
Zitat von: krikan am 16 März 2015, 20:05:04
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 :-)
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.
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
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
ZitatIst 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.
ZitatMehrere 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.
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.
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.
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.
Ich gehe davon aus, dass in diesem Fall EnOcean_Parse nur einmal aufgerufen wird, da der vorhin erwaehnte Filter in fhem.pl zuschlaegt.
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.
Ok, das ist ein Punkt, habe im Moment auch keine gute Loesung dafuer, ausser die anderen TCMs (irgendwie) zu deaktivieren.
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
Zitat von: Stril am 17 März 2015, 22:11:59
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.
Zitat von: Stril am 17 März 2015, 22:11:59
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.
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
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.
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.
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?
"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.
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 ?
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.
Hallo!
Wäre es da nicht einfacher, USB über Cat5e in die Stockwerke zu verlängern?
Gruß
Phil
Hi,
wenn du das Netzwerkkabel als USB-Kabel "missbrauchst", dann fällt dir eine komplette Leitung für Ethernet weg. Normal legt man ja eine 2-fach Dose, aber Computer, TV & Telefon wollen ja auch bedient werden. Da müsste man dann wieder einen lokalen Switch installieren - musst du schauen, was bei dir Priorität hat. Auch spielt die Leitungslänge eine Rolle, USB kannst du nicht endlos lang passiv verlängern.
Zitat von: DerJens am 19 März 2015, 15:23:37
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.
...gerade ausprobiert mit 2 RPi's: Via FHEM2FHEM bidirektional zwei FHEM Instanzen im Modus LOG verbunden. Extrem wichtig ist, dass man einen Filter verwendet, also z.B. LOG:Eg.* auf dem einen und LOG:Og.* auf dem anderen. Sonst baut man sich einen netten Kreis. Wenn man das beachtet, kann man problemlos bidirektional arbeiten und so auf beiden Instanzen auf die Events der jeweils anderen Instanz reagieren. So könnte man auch die gesamte Logik auf einem Gerät machen... ich bin begeistert ;)
Hallo Leute
Das Thema ist zwar etwas älter, aber für mich top aktuell.
Ich habe folgendes Problem:
Statt Repeater soll ein eigenständiger TCM den Job übernehmen und eine Hauptinstanz von FHEM den Rest.
Der Einlernvorgang läuft leider nicht ganz richtig wenn der zweite auch in Reichweite ist.
Meine Daten:
FHEMstand: aktuell
Ubuntu ist die aktuelle Version 16.04.2 LTS
Hardware: orangePILite
TCM-310 sind enoceanPI und auf GPIO gesteckt.
erster TCM ist lokal auf Ubuntu:
define TCM_310 TCM ESP3 /dev/ttyS3@57600
Der zweite ist per SER2NET "reingeholt" und ist auf einer anderen Hardware ohne FHEM.
define TCM_310_1 TCM ESP3 172.20.130.52:3001@57600
Auf dem zweiten ist SER2NET so eingestellt:
BANNER:banner:\r\nser2net port \p device \d [\s] (Debian GNU/Linux)\r\n\r\n
3001:raw:0:/dev/ttyS3:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
Läuft sauber, ich kann über den zweiten alles einlernen - alles gut (erst mal).
Jetzt möchte ich einen Temperatursensor von Afriso (ohne Feuchtemessung) auf dem FHEM-System einlernen und er lernt folgendes ein:
define EnO_0180DC8E EnOcean 0180DC8E
attr EnO_0180DC8E IODev TCM_310_1
attr EnO_0180DC8E room EnOcean
attr EnO_0180DC8E subType 4BS
Da feht einiges.
Nun lösche ich zum Test den zweiten TCM_310_1 und es wird folgendes eingelernt:
attr EnO_0180DC8E IODev TCM_310
attr EnO_0180DC8E eep A5-02-05
attr EnO_0180DC8E manufID 02D
attr EnO_0180DC8E room EnOcean
attr EnO_0180DC8E subType tempSensor.05
attr EnO_0180DC8E teachMethod 4BS
Das ist sauber.
Hat jemand eine Idee?
Gruß Schmitzkatze
Kleiner zusatz - habe es gerade gesehen:
Obwohl der erste TCM im Teach-Modus ist, kommen die Daten über den zweiten rein.
Diese sind dann natürlich nicht vollständig.
Gruß Schmitzkatze
hmmm.
scheinbar hat niemand merere TCM´s oder keine Probleme damit.
Ich denke es ist ein Fehler, dass der zweite TCM der nicht im Teach-Modus ist, die Signale an FHEM weiter gibt.
Normalerweise ist die Zuordnung der TCM zum Device wichtig. Sonst sendet der falsche TCM das Signal und die Entfernung ist zu lang.
Gibt es ev. eine Ausweichslösung? z.B.
Kann man den TCM deaktivieren / aktivieren?
Habe nichts in den Einstellungen gefunden.
Dann könnte ich den einen erst deaktivieren und den anderen in den Teach-Modus setzen.
So werden die Geräte sauber einem TCM zugeordnet.
Würde mich echt freuen wenn jemand eine Lösung hat.
Ich habe nämlich vor, noch weitere TCM´s in FHEM einzubinden. Mal sehen wo die Grenze ist...
Gruß Schmitzkatze
Die Grenze ist genau bei 1, siehe vorstehende Diskussionsbeiträge. Am Sachverhalt hat sich in der Zwischenzeit nichts geändert!
Hallo Klaus
das war nicht wirklich die Antwort auf die ich gewartet habe :(
Die Beiträge sind ja aus dem 2015 und die Entwicklungen gehen weiter.
So ganz rauslesen, dass nur ein TCM möglich ist konnte ich nicht, da es eigentlich bei mir gut läuft. Es sei denn ich habe den entscheidenden Satz überlesen.
Ev. ist es ja ein Anstoß mal in diese Richtung hin zu arbeiten. (warum?)
Ich möchte es kurz mit einem WLAN vergleichen. Hier ist es immer schlecht mir Repeatern zu arbeiten und jeder der in z.B. Firmen WLAN-Umgebungen ausstattet, setzt eigene Accesspoints.
Jetzt kommt hinzu, das Hardware mittlerweile so günstig geworden ist, dass man sich dies leisten kann.
z.B. eine eigene Instanz für einen TCM (als Slave) kann man mit einem orangePI Lite / ONE erstellen. Dieser kostet zur Zeit ca. 10,- und dann kommt der TCM dazu.
Die Images gibt es fast fertig und mit leichten Einstellungen ist der Slave eingerichtet.
Ich bin gerne bereit meine konfigurationen für den Slave online zu stellen wenn gewünscht.
Rudolf König schrieb ja auch, dass doppelte Signale abgefangen werden. somit ist das auch schonmal ein guter Start.
Ich bin zusätzlich gerne bereit bei mir Tests durchzuführen, da ich sowieso an diesem Thema arbeite und die Hardware hier liegen habe.
Gruß Schmitzkatze
Nach meiner Analyse und Bewertung der EnOcean-Protokolle ist ein Mehrsender-Betrieb nicht vorgesehen und sehr problematisch. Seit der damaligen Diskussion gab es diesbezüglich keine Veränderungen im EnOcean-Protokoll. Das EnOcean-Protokoll ist nicht vergleichbar z. B. mit WLAN. Ich werde deshalb auch keine Arbeit darin investieren.
Hallo Klaus,
ich wollte nicht enocean mit WLAN vergeleichen. Es war nur ein Beispiel.
Andere Hersteller von Hausautomationssystemen die auch enocean unterstützen haben auch Gateways die sauber arbeiten. Die kosten dann aber auch 200-300 Euro.
Bedeutet aber, andere können das auch.
Ich würde aber sagen, das es nicht am enocean Protokoll liegt, sondern an der Art, wie FHEM Daten als eingelernt annimmt und speichert.
Ich habe das Gefühl, dass der Einlernvorgang bei einer bidirektionalen Kommunikation schief läuft.
Der Teach Mode wird gestartet, und die ersten Daten kommen rein. Dann wird gegengefragt um den Subtyp zu ermitteln. Das läuft dann über den falschen TCM. Damit wird der Subtyp nicht empfangen.
Ist aber nur ein Gefühl.
Es würde aus meiner Sicht reichen, wenn es möglich ist den einen TCM der gerade nicht mitspielen soll, deaktivieren könnte.
Gleich danach wird er wieder aktiviert. Wäre zwar nicht perfekt aber eine Möglichkeit.
Gibt es eine solche Möglichkeit?
Gruß Schmitzkatze (Thomas Kennert)
hmmm - ist echt schade, dass es scheinbar keine Möglichkeit gibt.
Ich werde aber nicht locker lassen, so lange daran arbeiten, bis ich es hinbekomme und werde berichten.
Meine weiteren Tests: Ich werde alle TCM´s (während des Einlernvorgangs) auf "LearningMode nearfield" setzen und schauen ob das eine Möglichkeit ist.
Nach dem Einlernen wieder zurückgesetzt.
Dann sollten keine Überschneidungen des Signals auftreten.
Gruß Schmitzkatze
Funktion Fingerprint siehe https://forum.fhem.de/index.php/topic,75291.0.html