Mehrere TCM statt Repeater

[DerJens]

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.

[DerJens]

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

[Schmitzkatze]

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

[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

[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

[klaus.schauer]

Die Grenze ist genau bei 1, siehe vorstehende Diskussionsbeiträge. Am Sachverhalt hat sich in der Zwischenzeit nichts geändert!

[Schmitzkatze]

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

[klaus.schauer]

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.

[Schmitzkatze]

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)

[Schmitzkatze]

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

[klaus.schauer]

Funktion Fingerprint siehe https://forum.fhem.de/index.php/topic,75291.0.html