Eltako Tastereingangsmodule FTS12 - Telegramme ins FHEM

Begonnen von CoComp, 27 August 2017, 22:25:45

Vorheriges Thema - Nächstes Thema

CoComp

Ich steuere alle Rollläden "manuell" über lokale Taster an Eltako-Tastereingangsmodulen FTS12 und den Rollladenmotoren an FSB14 - quasi als klassische Basisebene. Neben der Haustür gibt es noch zwei Doppelwippentaster zur Zentralsteuerung der Rollläden von Erdgeschoss und  Obergeschoss.

Die komplette Logik für die Beschattung (nach Zeit, Sonnenstand, etc.) läuft über FHEM und Loxone, wobei die FSB14 alle in FHEM eingebunden sind, Verbindung mit FHEM über das Funkantennenmodul FAM12  - funktioniert alles 1a. 

Nun möchte ich diese über FHEM / Loxone realisierten Komfortfunktionen automatisch deaktivieren, wenn über den klassischen Zentraltaster alle Rollläden im Erdgeschoss nach unten gefahren wurden. Dazu müsste ich aber im FHEM mitbekommen, wenn eben diese Zentraltaster betätigt wurden - was ich aber bislang nicht hinbekommen habe, da der FTS12 offenbar keine Telegramme ins FHEM überträgt.

Habe ich eine Chance, die Telegramme der FTS12 ins FHEM zu bekommen?


hexenmeister

Weiß ich nicht genau, denke aber schon. Bei mir läuft die Verbindung über FGW14 und ich kann die Eingänge des Fts14em mitlesen.
defmod DG_WZ_TA_Licht_Top_Dn EnOcean 00001004
attr DG_WZ_TA_Licht_Top_Dn IODev FGW14
attr DG_WZ_TA_Licht_Top_Dn eep F6-02-01
attr DG_WZ_TA_Licht_Top_Dn manufID 00D
attr DG_WZ_TA_Licht_Top_Dn room EnOcean
attr DG_WZ_TA_Licht_Top_Dn subType switch
attr DG_WZ_TA_Licht_Top_Dn teachMethod RPS

Direkte Verbindung über FAM14 ging meine ich auch.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Johnnyflash

Hallo,
der FSB14 müsste dir doch auf jeden fall melden, wenn er geschaltet hat. Sofern du die Laufzeiten der Rollos eingegeben hast, kannst du doch prüfen, ob position=0 ist!

hexenmeister

Wenn ich richtig verstanden habe, ist das nicht das, was gemeint war.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Winterbottom

Hallo,

Hast Du eine Drahtverbindung zum RS485-Bus, oder hast Du einen CUL, der den EnOcean Funk mithört?
Die Eingangsmodule senden das Telegramm in den Bus, aber nicht in den EnOcean Funk. Dafür bräuchtest Du ein Sendemodul, das die Telegramme des FTS in den Funk überträgt.
Den Namen oder die Nummer weiß ich gerade nicht im Kopf, wenn Du mit der Info auf der Geräteliste bei Eltako nicht fündig wirst, schreib nochmals, dann schaue ich nach.

Gruß Ulrich
RaspPi3 über FGW-USB, Eltako Gebäudefunk (FAM14) zentral für EFH mit ca 70 Aktoren und 100 Eingängen, 20x LaCrosse an JeeLink, FHEM 5.7, TabletUI

hexenmeister

FTD14 (Telegramm duplizierer). Aber, wenn ich richtig gelesen habe, hat er den Bus an Fhem über USB-Verbindung an FAM12 angebunden. Damit bekommt man, soweit ich weiß, alles auf dem Bus mit.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Winterbottom

Über USB kann man alle Telegramme mitlesen, egal ob über FGW oder FAM. Hat mir auch der Service von Eltako bestätigt. Ich habe das FGW nur, dass das Kabel nicht vorne raushängt.
Dann sollte bei Betätigung des Tasters das Autocreate auch das Device anlegen.

Auf der EnOcean Homepage gibt es ein Tool mit dem man die Telegramme auf dem Bus mitlesen kann.

Damit würde ich einmal analysieren, was passiert, wenn Du einen Taster drückst. Am besten auch einen ausprobieren, der eine sichtbare Aktion auslöst, also Rolladen oder Licht.
RaspPi3 über FGW-USB, Eltako Gebäudefunk (FAM14) zentral für EFH mit ca 70 Aktoren und 100 Eingängen, 20x LaCrosse an JeeLink, FHEM 5.7, TabletUI

hexenmeister

Zitat von: Winterbottom am 29 August 2017, 23:11:05
Ich habe das FGW nur, dass das Kabel nicht vorne raushängt.

So in etwa ;D

Ich habe gelesen, dass FAM14 bei dieser Art Verwendung nicht immer eine stabile Verbindung garantiert. Meine Tests (nicht wirklich lang, aber dennoch) haben keine Probleme aufgezeigt. Aber der Anschluss vorne war wirklich nicht optimal, daher der FGW14. Bei der Gesamtsumme der Installation fielen 50 Euronen für das Gateway nicht mehr wirklich ins Gewicht.

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

CoComp

Zu euren Fragen zu meinem Posting:
Ich betreibe am Raspi einen CUL und habe damit eine Funkverbindung zum FAM14. Über diese Verbindung kriege ich alle Daten von den 14er Aktoren und kann alle 12er und 14er Aktoren steuern. Aber ich bekomme keine Telegramme von den 12er Tastereingangsmodulen.

Zur Kopplung meiner Module der alter 12er Reihe und der neuen 14er Reihe habe ich ein FGW14 im Einsatz - aber kein FGW14USB.

Wenn ich euch richtig verstehe, kann ich aber über den Einsatz eines zusätzlichen FGW14USB und Anbindung des Raspi per USB an den FGW14USB mein Problem lösen. Korrekt?

Winterbottom

Korrekt.
Die Alternative wäre der FTD14 wobei du da für verschiedene Adressbereiche eventuell sogar mehrere bräuchtest.
Wenn möglich, würde ich das FGW14 USB nehmen.
Zum Test kannst Du auch das FAM 14 per USB an den Raspi anschließen.
Bei mir hat das stabil funktioniert, ich bin nur aufgrund des Kabels auf das FGW umgestiegen.

Gruß Ulrich
RaspPi3 über FGW-USB, Eltako Gebäudefunk (FAM14) zentral für EFH mit ca 70 Aktoren und 100 Eingängen, 20x LaCrosse an JeeLink, FHEM 5.7, TabletUI

Johnnyflash

Noch mal zur Erklärung meiner Antwort (s.o.): Mein Ansantz wäre es, die Tasterbetätigung "indirekt" auszuwerten. Sprich, wenn der Rollladen nicht in position 0 (=ganz oben) ist, wurden Sie manuell gefahren. Das hat m. E. auch den Vorteil, dass die Art der manuellen Bedienung irrelevant ist (Taster, Web-Interface,...) So mache ich es auch bei mir in den Schlafzimmern (Auszug aus einem DOIF):


([([{twilight("T","sr_indoor","08:00","9:00")}]-[00:30])] and [Bewohner:state] eq "gone") (set OG.Schlafzimmer.Rollladen.* opens) DOELSEIF ([([{twilight("T","ss_civil","17:00","22:00")}])]) (IF (([OG.Schlafzimmer.RollladenTuer:position] == 0) and ([OG.Schlafzimmer.RollladenFenster:position] == 0)) (set OG.Schlafzimmer.Rollladen.* closes))


Gruß
Philipp

CoComp

OK,

ich habe heute die Anbindung via Eonocean PI868 mit einen Eintrag in der cfg  von FHEM
define TCM_ESP3_0 TCM ESP3 /dev/ttyAMA0@57600

=> ich bekomme die Telegramme der Tastereingangsmodule nicht mit, also möchte ich zur kabelgebundenen Anbindung wechseln

Ich finde aber bis jetzt nur die Lösungen, in der Anwender ihren FAM14 direkt per USB angebunden haben
define FAM14 TCM ESP2 /dev/ttyUSB0@57600

=> Das soll aber nicht superstabil laufen, daher möchte ich einen zusätzlichen FGW14USB einsetzen und den nicht via RS485 sondern direkt per USB anbinden

Hat das schon jemand erfolgreich geschafft und ist der cfg-Eintrag identisch zu dem mit der FAM14-Anbindung?

hexenmeister

Zitat von: CoComp am 01 September 2017, 11:34:31
Hat das schon jemand erfolgreich geschafft und ist der cfg-Eintrag identisch zu dem mit der FAM14-Anbindung?
Ja, konfig ist identisch. Läuft bei mir sehr stabil genau so seit Monaten (sogar mit einer zusätzlichen Netztwerkstrecke per ser2net dazwischen).
Mit FAM14 habe ich auch getestet, über Stunden keine Instabilitäten gemerkt.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Winterbottom

Genauso bei mir.
Hätte aber einige Monate nur das FAM 14. War eigentlich immer stabil.
Hier im Forum habe ich auch mal gelesen, dass es instabil sein soll, aber auch der Eltako Support hat mir bestätigt, dass es da keinen Unterschied gibt.
Der Grund für das FGW war bei mir das Kabel und dass die Programmierschnittstelle des FAM frei bleibt und ich nicht immer umstecken muss.
Gruß Ulrich
RaspPi3 über FGW-USB, Eltako Gebäudefunk (FAM14) zentral für EFH mit ca 70 Aktoren und 100 Eingängen, 20x LaCrosse an JeeLink, FHEM 5.7, TabletUI

Flipps


hexenmeister

Zitat von: Flipps am 04 September 2017, 22:38:23
Schau mal hier, ich denke das ist die sauberste Lösung  für dein Problem:
Er hat doch ein FTS12, was kann FTS14 hier anderes bewirken?
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy


hexenmeister

Jep, hat er. Das Problem ist jedoch nicht die Taster zu erfassen, sondern zum FHEM zu senden.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Flipps


predi-ger-many

Hi,

ich habe gerade erst vor dem gleichen Problem gestanden. Ich habe es mit Eno nicht hinbekommen, aber mit Z-Wave.

Hier kurz das Szenario:


  • Somfy RTS Rollläden
  • Gira-Schalter an der Wand, welcher die Somfy bedienen soll

Meine Lösung:

Fibaro Roller Shutter 2. Ganz normal an Strom angeschlossen. An die Ausgänge nix angeschlossen. Schalter ganz normal angeschlossen.
Szenen-Modus aktiviert. Damit werden Events an die Zentrale gesendet. Diese werte ich dann aus und schalte.

So kann ich Einfachklick, Doppelklick und Co auswerten. Funktioniert perfekt. Aber kein Eno